工业 AI Agent 引入 DSL 的架构必要性：从概率生成到确定执行

工业数据分析对一致性、可复现性、可审计性的要求极高。原生大模型的概率生成特性，会导致语义漂移、口径不稳、执行逻辑分化等工程问题。工业数据库 AI Agent 引入 DSL（领域专用语言）的核心价值，不在于让大模型更聪明，而在于通过架构隔离，将 LLM 的不确定性限制在意图理解与概率推理层，把工业分析流程转化为规则确定、过程可验证、结果可复现的执行体系。

需要明确：DSL 无法消除元数据、阈值、业务规则、数据质量规则本身的错误；如果这些规则建模错误，DSL 仍会稳定输出错误结果。请注意区分两类"不确定性"：

计算过程的不确定性（computational uncertainty）------这是 DSL 能够控制的范围：同一输入、同一规则、同一编译器会产生相同的执行路径与相同的输出；
业务真值的不确定性（business correctness）------这是 DSL 无法自动保证的：若上游的业务定义、口径或规则本身有误，DSL 只会把错误以可复现的方式固化下来。

因此，需要明确：DSL 保证的是计算过程的确定性（computational determinism），而不是业务规则和语义定义本身的正确性。在工程落地过程中，必须首先完成业务语义层建设，对设备对象、指标定义、设备关系和分析规则进行统一建模与确认。否则，即使 DSL、Compiler 和 SQL 执行链路完全正确，也可能将错误的业务逻辑固化为确定性计算结果。

一、核心范式与分层架构

在构建工业智能分析 Agent 时，业务语义与 DSL 应当承担不同职责。业务语义层负责定义"分析对象是什么、指标怎么算、业务规则是什么" ；DSL 则负责将这些已经明确的业务定义转化为结构化、可校验、可执行的形式化表达。这样可以避免让 LLM 直接从自然语言跳到 SQL，将业务理解与实际执行过程进行隔离。

如果要用更简洁的表达，可以概括为：

业务语义层：定义工业业务"是什么、怎么算、遵循什么规则"。
DSL：将这些业务定义转化为机器可理解、可校验、可编译的形式化规则。

LLM 与各层的交互应遵循明确的职责边界：LLM 负责将自然语言解析为候选意图（Candidate Intent），业务语义层负责将候选意图绑定到经过治理的业务对象、指标与规则，DSL 则负责对分析意图进行形式化表达与约束。经过校验的 DSL 由编译引擎转换为 SQL 并交由数据库执行，得到确定性结果，最终由 LLM 对结果进行解释、总结与呈现。

典型工程链路可概括为：

LLM 意图解析→业务语义层→DSL→DSL 编译引擎→SQL→数据库执行→确定性结果→LLM 结果总结 \text{LLM 意图解析} \rightarrow \text{业务语义层} \rightarrow \text{DSL} \rightarrow \text{DSL 编译引擎} \rightarrow \text{SQL} \rightarrow \text{数据库执行} \rightarrow \text{确定性结果} \rightarrow \text{LLM 结果总结} LLM 意图解析→业务语义层→DSL→DSL 编译引擎→SQL→数据库执行→确定性结果→LLM 结果总结

其中，业务语义层定义"对象、指标与规则"，DSL 定义"本次分析如何形式化表达"，编译引擎负责解析、校验、分析计划生成与 SQL 生成；数据库自身负责查询优化与物理执行。对于复杂分析任务，编译引擎内部可进一步构建分析计划或计算图（Computation Graph / DAG），但这属于编译实现细节，而非主架构链路。

需要强调的是，DSL 与编译引擎保证的是计算过程的确定性与可验证性，而不是业务定义本身的正确性。"什么是业务真值"仍需由业务专家与治理流程确认。

执行后由确定性 SQL 引擎产出结果，LLM 负责对确定数据进行概率化的解释、排序和总结。

text 复制代码

   ===================================================================================================
                       【非确定空间 (Probabilistic)】
  • 允许概率性与泛化表达
  • 负责自然语言意图提取与计算结果的自然语言总结
  
   用户自然语言
        │
        ▼
 ┌─────────────┐
 │  LLM Agent  │ (意图抽取 / 概率推理)
 └──────┬──────┘
        │ 提取 Candidate Intent
================───────────────────────────────────────────────────────────────────────────────────
                       【语义桥接与校验层 (Transition & Guardrail)】
  • 将概率性意图转换为受约束的形式化表达
  • 完成业务概念强绑定与拦截非法指令
  
        │
        ▼
 ┌─────────────┐
 │ 业务语义层  │ (Business Semantic Layer / 语义对象与指标口径映射)
 └──────┬──────┘
        │ 生成 Candidate DSL
        ▼
 ┌─────────────┐
 │ Guardrail / │
 │ Validation  │ (Schema 校验 / 算子与测点合法性检查)
 └──────┬──────┘
        │
   ┌────┴────────────────────────┐
[校验失败]                     [校验通过]
   │                             │
   ▼                             │
熔断 / 退回 LLM 重试              │
================─────────────────┼─────────────────────────────────────────────────────────────────
                       【确定空间 (Deterministic)】
  • 绝对零随机、过程可严格推导、结果 100% 可复现
  • LLM 完全退出计算，由确定性引擎编译与执行 SQL
  
                                 │
                                 ▼
                       ┌──────────────────┐
                       │ Industrial DSL   │ (形式化规则)
                       └─────────┬────────┘
                                 │ 解析 / 校验
                                 ▼
                       ┌──────────────────┐
                       │ DSL Compiler     │ (编译与执行计划生成)
                       └─────────┬────────┘
                                 │ 生成标准 SQL
                                 ▼
                       ┌──────────────────┐
                       │    SQL Engine    │ (确定性计算与结果集提取)
                       └─────────┬────────┘
                                 │ 确定性数据集 + Trust Score
================─────────────────┼─────────────────────────────────────────────────────────────────
                       【非确定空间 (Probabilistic)】
                                 │
                                 ▼
                       ┌──────────────────┐
                       │  LLM Agent       │ (概率总结与洞察呈现)
                       └──────────────────┘

工业 AI 可靠性并非仅来源于模型能力的提升，而是来源于：

Industrial Reliability=Intelligence (理解/总结)+Semantic Layer (业务建模)+DSL (形式约束)+Graph Governance (图转化)\boxed{\text{Industrial Reliability} = \text{Intelligence (理解/总结)} + \text{Semantic Layer (业务建模)} + \text{DSL (形式约束)} + \text{Graph Governance (图转化)}}Industrial Reliability=Intelligence (理解/总结)+Semantic Layer (业务建模)+DSL (形式约束)+Graph Governance (图转化)

二、核心矛盾：数据库语义计算层 vs 通用数据处理层

工业数据不能只被看作"字段和值"，它本身承载着设备、测点、状态、指标和业务规则等语义。将这些数据脱离原有语义直接抽取出来进行通用二次分析，本质上是在计算过程中丢弃业务上下文。

1. 业务语义层与 DSL 的分工协作

业务语义层（Semantic Layer）：定义统一的工业业务对象、指标口径、设备关系和业务规则，并负责将用户意图绑定到经过治理的业务语义。它解决"业务是什么、指标怎么算、规则是什么"。
DSL（Domain-Specific Language）：将完成语义绑定的分析意图转换为结构化、形式化的表达，作为校验、分析计划生成和 SQL 编译的统一输入。它解决"这次分析做什么，以及如何形式化表达"

用户输入自然语言（例如"分析最近24小时1号泵的异常振动"），系统不会让 LLM 直接拼接并执行简单 SQL：

sql 复制代码

-- 错误范例：脱离业务语义层与 DSL 的直接 SQL 拼接
SELECT avg(vibration) FROM sensor_data WHERE device_id = 'pump_1' AND time > now() - interval '24 hours';

上述拼接丢失了关键的业务事实与拓扑关系：指代哪台泵？上下游设备测点拓扑如何？指标是 RMS 还是 Peak？是否过滤停机状态？是否排除启停机瞬态？异常持续时间阈值是多少？

在引入业务语义层与 DSL 的体系下，分析链路如下：

Natural Language⟶Business Semantic Layer⟶DSL⟶DAG / Graph Transformation⟶Target SQL⟶SQL Execution⟶LLM Summarization\text{Natural Language} \longrightarrow \text{Business Semantic Layer} \longrightarrow \text{DSL} \longrightarrow \text{DAG / Graph Transformation} \longrightarrow \text{Target SQL} \longrightarrow \text{SQL Execution} \longrightarrow \text{LLM Summarization}Natural Language⟶Business Semantic Layer⟶DSL⟶DAG / Graph Transformation⟶Target SQL⟶SQL Execution⟶LLM Summarization

业务语义层先将"1号泵"映射为全局唯一的设备语义节点，将"异常振动"绑定到具体的算法指标标准；
DSL 将其固化为形式化的分析语法；
图转化引擎通过图算法（拓扑排序、有向无环图 DAG 计算、拓扑寻路、子图匹配等）将工业对象关系与计算算子转换为精准的物理 SQL 语句；
送入 SQL 引擎执行，将计算得出的确定性结果集送回 LLM 进行业务总结。

在这条链路中，AI 在前半段负责自然语言理解与意图拆解，在后半段负责计算结果的自然语言总结，完全不参与物理 SQL 的拼接与确定性计算过程。

2. 通用数据处理：显式工业语义丢失导致系统性偏差

脱离业务语义层与 DSL 的通用分析模式，常见链路为：

工业数据库⟶通用 SQL 查询⟶通用结构化数据表⟶LLM 生成通用计算逻辑⟶无业务约束计算⟶偏差分析结果\text{工业数据库} \longrightarrow \text{通用 SQL 查询} \longrightarrow \text{通用结构化数据表} \longrightarrow \text{LLM 生成通用计算逻辑} \longrightarrow \text{无业务约束计算} \longrightarrow \text{偏差分析结果}工业数据库⟶通用 SQL 查询⟶通用结构化数据表⟶LLM 生成通用计算逻辑⟶无业务约束计算⟶偏差分析结果

虽然原始字段如设备 ID、时间戳、监测数值仍被保留，但工业上下文语义不再作为计算约束。通用分析工具无法绑定核心业务规则：不能区分同名字段对应的设备测点属性、不知道时序统计是否需要补齐缺失点、无法过滤设备停机无效数据、不识别报警持续时间要求、不会按设备类型差异化执行统计规则。

通用分析模式分析的是"数据表象"，而业务语义层 + DSL 分析的是"完整的工业业务对象与业务事实"。

三、工业 AI Agent 的六类确定性控制机制

业务语义层与 DSL 将 LLM 的概率性意图转化为受业务规则和形式化约束控制的分析逻辑，并通过算子治理、数据质量、编译执行和审计机制，将关键计算过程纳入确定性执行链路，实现跨平台、跨 Agent 的语义一致、规则一致与过程可追溯。

控制机制	核心解决问题	主要控制手段	控制归属
1. 业务语义与元数据治理 Semantic & Metamodel	消除业务概念歧义、对象错配与指标口径漂移	业务语义抽象与物理 Schema 隔离：统一设备、测点、指标、状态和拓扑模型，仅向 Agent 暴露经过治理的业务对象与语义接口。	Business Semantic Layer
2. 工业算子注册与契约治理 Operator Registry	防止 AI 自行生成、简化或修改核心计算逻辑	算子注册与强类型契约：统一管理输入/输出 Schema、参数约束、适用范围、版本及认证状态，Agent 只能引用已注册算子。	Semantic Layer + DSL
3. 数据质量控制与结果可信度评估 Data Reliability	控制数据质量问题对分析结果的影响，避免脏数据进入计算链路	数据质量检查与质量状态标注：对完整性、有效性、时效性等进行硬约束检查，并在结果中保留数据质量状态与上下文信息。	Data / Execution Layer
4. DSL 编译与查询治理 DSL Compiler & Query Governance	防止非法查询、无界扫描和不可控资源消耗	静态校验、分析计划与资源约束：解析和校验 DSL，生成分析计划；复杂任务可构建计算图，并在 SQL 生成阶段注入时间范围、分区、扫描、超时和资源预算约束。	DSL Compiler
5. 全局语义与规则治理 Global Semantic Governance	防止多 Agent、跨系统分析产生业务口径和计算窗口冲突	统一语义基线：所有 Agent 共享统一的对象、指标、算子、规则及时间窗口定义，并通过版本机制保证跨 Agent 一致性。	Semantic Governance
6. 版本、血缘与审计治理 Version, Lineage & Audit	保证历史分析过程可追溯、可解释和可复现	分析履历快照：关联保存 Semantic Model、DSL、规则、算子、数据快照、Generated SQL 及数据库执行信息，形成完整分析血缘。	Governance / Audit Layer

1. 业务语义与元数据治理（Semantic & Metamodel）

工业 AI Agent 首先需要解决的不是"如何生成 SQL"，而是如何确定用户所说的业务对象、指标和分析规则究竟对应什么。

工业数据库及其上层语义模型通常承载了设备、测点、指标、状态、拓扑关系以及相关业务规则。业务语义层将这些信息组织为统一的业务模型，并向 Agent 提供稳定的语义接口，使 Agent 不需要直接面对底层物理表、字段和存储结构。

例如，用户提出：

"分析最近 24 小时 1 号泵的异常振动。"

LLM 首先提取候选意图：

json 复制代码

{
  "device": "1号泵",
  "metric": "异常振动",
  "time_range": "24h"
}

随后由业务语义层完成语义绑定：

text 复制代码

"1号泵"
    ↓
pump_001
    ↓
设备实体 + 测点集合 + 拓扑关系

"异常振动"
    ↓
pump.vibration.anomaly
    ↓
规定的振动指标 + 异常判定规则

"最近24小时"
    ↓
统一时间范围定义

这里需要特别区分：

LLM 负责提出候选意图，业务语义层负责将候选概念绑定到经过治理的业务实体和指标定义。

因此，LLM 面向的不是数据库的物理结构，而是经过业务语义层定义的业务对象。

例如，LLM 只需要理解：

text 复制代码

"1号泵"
"振动 RMS"
"最近24小时"

而不需要直接处理：

text 复制代码

哪张物理表存储了 1 号泵的数据？
哪个字段对应振动 RMS？
数据按哪个字段进行分区？
设备 ID 在数据库中具体是什么值？

这些物理映射由业务语义层和 DSL Compiler 负责完成。

更直观的映射关系可以写成：

text 复制代码

用户 / LLM 理解的业务概念
        │
        ▼
┌─────────────────────┐
│  1号泵               │
│  振动 RMS            │
│  最近24小时           │
└──────────┬──────────┘
           │
           ▼
   Business Semantic Layer
           │
           │ 语义映射
           ▼
┌─────────────────────────────┐
│ pump_001                    │
│ pump.vibration.rms          │
│ time_range = 24h            │
└──────────┬──────────────────┘
           │
           ▼
      DSL Compiler
           │
           │ 物理映射
           ▼
┌─────────────────────────────┐
│ physical table              │
│ physical columns            │
│ partition / index           │
│ JOIN / WINDOW / FILTER      │
└─────────────────────────────┘
           │
           ▼
          SQL

LLM 负责理解"分析什么"，业务语义层负责确定"这些业务概念对应什么"，DSL Compiler 负责将语义逻辑映射为数据库能够执行的物理查询。

一句话概括就是：

让 LLM 面向业务语义，而不是面向数据库 Schema；让 Compiler 面向物理执行，而不是让 LLM 直接操作物理数据结构。

这样可以将自然语言理解与物理数据库 Schema 解耦，降低字段错配、对象误绑定和指标口径漂移的风险。

2. 工业算子注册与契约治理（Operator Registry）

业务指标不仅需要定义名称，还需要明确具体如何计算。

例如，"振动"可能对应 RMS、Peak、Peak-to-Peak、Kurtosis 等不同特征；复杂的设备诊断还可能依赖多个特征组合、状态条件和专用算法。如果允许 LLM 自行生成这些计算公式，即使 SQL 语法正确，也可能产生与工业规范不一致的计算结果。

因此，需要建立统一的 Industrial Operator Registry，将经过验证的工业计算能力注册为标准算子：

text 复制代码

Industrial Operator Registry
├── vibration.rms()
├── vibration.peak()
├── vibration.kurtosis()
├── bearing_fault_score()
├── energy_efficiency()
├── thermal_drift()
└── leak_detection()

每个算子可以维护统一的契约信息：

json 复制代码

{
  "operator_name": "vibration.kurtosis",
  "version": "2.1.0",
  "input_schema": {
    "signal": "timeseries",
    "window": "duration"
  },
  "output_schema": {
    "kurtosis": "float"
  },
  "parameter_constraints": {
    "window_min": "10s",
    "window_max": "24h"
  },
  "owner": "Reliability_Engineering_Team",
  "certification": "approved"
}

因此，LLM 可以选择和组合已经注册的算子，但不应自行重新定义核心工业算法。

换句话说：

LLM 决定"使用哪个已经定义好的能力"，而不是重新发明这个能力的计算公式。

这样可以将工业算法从概率生成过程转化为受版本和契约约束的确定性组件。

3. 数据质量控制与结果可信度评估（Data Reliability）

即使业务语义和计算逻辑完全正确，如果进入计算链路的数据本身存在严重问题，最终结果仍然可能失去业务意义。

但工业场景中的"数据质量"不能被简化为一个统一的数学评分问题。数据质量问题通常分为三类：

数据能否参与计算：例如缺失率过高、时间戳异常、数值越界、设备停机状态数据等；
数据应如何处理：例如删除停机数据、剔除启停机瞬态、对短时缺失做插值、对长时缺失直接拒绝计算；
最终结果附带什么质量上下文：例如采样完整率、时效性、有效率、状态过滤范围等。

因此，这一层更适合写成：

Data Reliability 不负责证明结果正确，而负责控制哪些数据可以进入计算链路，并为最终结果保留必要的数据质量上下文。

工业现场常见的数据问题包括：

采样缺失；
数据延迟；
传感器漂移；
突发毛刺；
超出物理量程；
设备停机期间产生的无效数据；
启停机过程中的瞬态数据。

这些问题的处理方式通常不是"给一个综合分数"，而是明确的质量约束：

text 复制代码

Completeness < 90%
        ↓
拒绝计算

或者：

text 复制代码

设备停机状态
    ↓
剔除该时间段数据

再或者：

text 复制代码

短时缺失
   ↓
允许插值

这类规则应该被固化在数据治理和 DSL / Operator 定义中，而不是由 LLM 临时决定。

因此，数据质量这一层更准确的工程描述应该是：

text 复制代码

                 Data Reliability
                       │
          ┌────────────┼────────────┐
          ↓            ↓            ↓
      数据完整性     数据有效性     数据时效性
          │            │            │
          └────────────┼────────────┘
                       ↓
                 数据质量检查
                       │
             ┌─────────┴─────────┐
             ↓                   ↓
          满足要求             不满足要求
             │                   │
             ↓                   ↓
          参与计算          拒绝 / 降级 / 标记
             │
             ↓
       计算结果 + 数据质量上下文

这意味着：

硬约束：数据是否满足计算前提；
规则处理：缺失、停机、超量程、瞬态如何处理；
质量标注：最终结果附带数据状态与质量背景，而不是给出一个看起来"科学"但往往难以解释的 Trust Score。

例如，系统可能输出：

text 复制代码

分析结果：
1号轴承存在早期异常风险

计算依据：
Kurtosis = 4.8
异常阈值 = 3.5

Data Quality Status = DEGRADED
Completeness = 98.2%
Validity = 99.1%
Freshness = 99.5%
备注：停机期间数据已剔除；短时缺失已按规则插值；异常时间段数据覆盖完整。

这里的关键不在于"计算一个统一的可信分数"，而在于：

数据质量层负责确保进入计算链路的数据满足预定义要求，并将数据质量状态作为最终结果的上下文信息。

也就是说：

这一层不负责判断业务结论是否正确，而负责控制哪些数据可以进入计算，以及在必要时拒绝、降级或标记数据。

这样定义更符合工程落地现实，也和全文的核心思想保持一致：

LLM 不负责判断数据是否可信，规则系统负责约束数据，计算引擎负责确定性执行，最终结果同时携带计算结果和数据质量上下文。

4. DSL 编译与查询治理（DSL Compiler & Query Governance）

经过业务语义绑定和算子确定后，分析意图需要进一步转换为可以被机器验证和执行的 DSL。

DSL Compiler 的核心职责不是"替数据库做 SQL 优化"，而是完成：

text 复制代码

DSL
 ↓
解析
 ↓
语法 / 类型 / 语义校验
 ↓
分析计划
 ↓
SQL 生成
 ↓
Query Governance
 ↓
Database

对于简单查询，分析计划可能非常直接：

text 复制代码

pump_001
    ↓
24h
    ↓
vibration.rms()
    ↓
threshold_check()

对于涉及多个设备、多个指标或复杂依赖关系的任务，则可以进一步构建 Computation Graph / DAG，用于表达计算依赖、数据依赖和拓扑关系。

例如：

text 复制代码

泵
├── 振动测点
│      ↓
│   vibration.rms()
│      ↓
│   anomaly_check()
│
└── 运行状态
       ↓
    state_filter()

因此，DAG 更适合作为复杂分析任务的内部计算表示，用于描述多个计算步骤之间的数据依赖关系；对于简单的 DSL 查询，则可以直接进行规则解析与 SQL 生成，无需显式构建 DAG。

在 SQL 生成之前，Compiler / Query Governance 还需要进行静态安全检查，例如：

时间范围是否明确；
是否存在无界查询；
是否访问允许的数据域；
是否满足分区条件；
是否超过扫描规模限制；
是否超过 Agent 的资源预算；
是否存在非法算子组合；
是否存在循环依赖。

最终生成符合 DSL 语义的 SQL。

需要注意的是：

DSL Compiler 负责将经过语义解析和校验的 DSL，转换成确定的查询逻辑；数据库自身的 Optimizer 再负责根据具体数据库的统计信息、索引、分区和执行能力生成物理执行计划。

对于简单查询，这一过程可以直接落到一个确定的查询逻辑；对于包含多个依赖计算步骤的复杂分析任务，可以用 DAG 作为内部表示，显式表达计算依赖、数据依赖和拓扑关系。

因此，二者职责应明确区分：

text 复制代码

Industrial DSL
      ↓
DSL Compiler
      ↓
Logical Query Plan
      ↓
Generated SQL
      ↓
Database Optimizer
      ↓
Physical Execution Plan
      ↓
Execution

DSL Compiler 把经过语义解析和校验的 DSL 转换成一个确定的逻辑查询计划；复杂任务则进一步用 DAG 表示其计算依赖。

这样既保留了 DSL 对查询过程的控制，又不会把 DSL Compiler 与数据库 Optimizer 混为一谈。

5. 全局语义与规则治理（Global Semantic Governance）

当系统从单个 Agent 扩展到多个专业 Agent 后，新的问题不再只是"某一个 Agent 算得对不对"，而是：

不同 Agent 是否在使用同一套业务定义？

例如：

text 复制代码

设备健康 Agent
        │
        ├── 使用"运行时间"
        │
能耗 Agent ──┤
        │
        └── 使用"运行功率"
             ↓
        是否采用相同的
        状态过滤与时间窗口？

如果不同 Agent 各自定义指标，就可能出现：

text 复制代码

Agent A：
平均功率 = 过去 1 小时所有采样点平均值

Agent B：
平均功率 = 设备运行状态下的 5 分钟窗口平均值

两者计算结果都可能在数学上正确，但业务口径并不一致。

因此，需要建立统一的语义与规则治理机制，使不同 Agent 共享：

统一设备与测点定义；
统一指标口径；
统一算子定义；
统一状态规则；
统一时间窗口；
统一数据质量规则；
统一规则版本。

架构上可以理解为：

text 复制代码

        Agent A        Agent B        Agent C
           │              │              │
           └──────────────┼──────────────┘
                          ↓
              Global Semantic Governance
                          │
              ┌───────────┼───────────┐
              ↓           ↓           ↓
           Objects      Metrics     Rules
              │           │           │
              └───────────┼───────────┘
                          ↓
                    Industrial DSL

这里的核心不是简单地让所有 Agent "共享一个 DSL"，而是：

让所有 Agent 建立在同一套经过治理的业务语义和规则基线上。

这样才能保证跨 Agent 分析结果具有可比性和可组合性。

6. 版本、血缘与审计治理（Version, Lineage & Audit）

工业分析不仅需要回答：

"这次计算结果是什么？"

还需要回答：

"这个结果当时是基于什么业务定义、什么规则、什么数据和什么计算逻辑得到的？"

因此，每次分析都应该形成完整的分析履历，而不仅仅保存最终 SQL。

例如：

text 复制代码

Analysis Result
│
├── Semantic Model Version
│      └── v2.0.0
│
├── DSL Version
│      └── v1.4.0
│
├── Rule Version
│      └── pump_vibration_rule_v2.1
│
├── Operator Version
│      └── vibration.kurtosis:v2.1.0
│
├── Data Snapshot
│      └── snap_20260726_001
│
├── Generated SQL
│      └── SQL Hash: 7c9a12e
│
└── Execution Metadata
       ├── Query ID
       ├── Database Version
       └── Execution Plan / Plan Hash（如可获取）

这里需要注意，可追溯不等于仅保存 SQL 就能保证绝对复现。

真正的历史复现依赖于多个条件同时保持一致：

text 复制代码

Reproducibility = f(
  Semantic Version,
  Rule Version,
  Operator Version,
  Data Snapshot,
  DSL,
  SQL,
  Execution Environment
)

因此，系统真正需要保存的是分析过程的完整血缘（Lineage）。

这样，当未来出现：

"为什么 2026 年的诊断结论与 2025 年不同？"

系统可以沿着完整血缘逐层追溯：

text 复制代码

业务定义是否变化？
        ↓
指标口径是否变化？
        ↓
规则是否变化？
        ↓
算子版本是否变化？
        ↓
输入数据是否变化？
        ↓
DSL 是否变化？
        ↓
Generated SQL 是否变化？
        ↓
数据库执行环境是否变化？

最终将"一个结果"还原为一条可审计的计算链路。

这也是工业 AI 与普通自然语言数据分析系统的重要区别：系统不仅要给出结果，还必须能够解释结果是依据什么定义、什么规则和什么数据产生的。

四、AI Agent 与 Executing Pipelines 的全链路工作流程

工业确定性分析依赖于概率推理（意图解析 + 结果总结）与规则计算（业务语义映射、DSL 校验、图转化及 SQL 执行）的分层解耦。

text 复制代码

                               AI Agent 架构

                   ┌──────────────────────────────────┐
                   │          Intent Parser           │ (自然语言 -> 意图拆解/概率)
                   └────────────────┬─────────────────┘
                                    │
                                    ▼
                   ┌──────────────────────────────────┐
                   │     Business Semantic Layer      │ (映射工业业务对象与指标口径)
                   └────────────────┬─────────────────┘
                                    │
                                    ▼
                   ┌──────────────────────────────────┐
                   │           DSL Generator          │ (生成形式化 Candidate Intent DSL)
                   └────────────────┬─────────────────┘
                                    │
                                    ▼
                         Candidate Intent DSL
                                    │
                                    ▼
                     ┌──────────────────────────────┐
                     │   Schema & Metamodel Validation
                     └──────────────┬───────────────┘
                                    │ (校验失败则拒绝/拦截)
                                    ▼
                             Industrial DSL
                                    │
                                    ▼
                     ┌──────────────────────────────┐
                     │ Graph Transformation Engine  │ (图算法转换为物理 SQL)
                     └──────────────┬───────────────┘
                                    │
                                    ▼
                              Generated SQL
                                    │
                                    ▼
                     ┌──────────────────────────────┐
                     │         SQL Engine           │ (执行 SQL 获取确定性数据)
                     └──────────────┬───────────────┘
                                    │
                                    ▼
                          Deterministic Result
                                    │
                                    ▼
                   ┌──────────────────────────────────┐
                   │      LLM Summarization Agent     │ (概率总结/自然语言输出)
                   └──────────────────────────────────┘

全链路职责拆分

AI Agent (意图解析阶段) ：意图解析器（Intent Parser）解析自然语言需求，与业务语义层交互，将语言绑定到明确的业务对象与指标定义上。
DSL Generator (DSL 表达阶段) ：将语义映射结果输出为结构化的 Candidate Intent DSL。禁止 Agent 直接感知物理数据库表结构、禁止自行拼接 SQL、禁止自行编写算法公式。
Schema Validation & Metamodel：对 Candidate Intent DSL 进行严格的类型检查、测点存在性校验、算子合法性校验。校验不通过时直接熔断返回，阻断不确定性下沉。
Graph Transformation Engine (图转化引擎)：将校验通过的 DSL 转化为逻辑计算图，利用图算法（拓扑分析、子图匹配、依赖关系推导等）将其编译转换为最优化物理 SQL 语句，并注入安全配额与资源限制。
SQL Engine (SQL 执行阶段)：物理 SQL 提交至数据库（SQL/TSDB/关系型数据库）执行，得到精准、可复现的确定性数据集（Data Dataset）。
LLM Summarization Agent (结果总结阶段)：确定的数据结果集与数据可信度指标（Trust Score）送入大模型，由 LLM 进行语言组织、上下文润色、异常原因解释与业务总结报告输出。

五、工业 AI Agent 六层架构原则

引入业务语义层后，工业数据库 AI Agent 落地应遵循如下六层架构原则：

架构层级	层级名称	核心职责	性质
Layer 6	LLM Summarization (概率总结层)	对确定性 SQL 执行结果进行自然语言总结、生成分析报告与业务洞察	概率推理 / 自然语言输出
Layer 5	SQL Execution Engine (确定执行层)	物理 SQL 脚本执行、结果集提取、资源隔离与性能保证	确定计算
Layer 4	DSL & Graph Compiler (图转化与编译层)	DSL 语法校验、图算法（DAG）转换物理 SQL、Query Governance	形式化约束 / 图转换
Layer 3	Business Semantic Layer (业务语义层)	业务对象建模、指标口径规范 (Metric OS)、图拓扑关系定义	业务抽象与口径固化
Layer 2	Agent Reasoning (意图解析层)	意图解析 (Intent Parser)、任务规划 (Planner)、语义关联与 Candidate DSL 生成	概率推理 / 意图生成
Layer 1	Industrial Data & Metamodel (物理事实与元数据层)	传感器时序数据、设备关系图谱、物理表模型、原始事件日志	物理事实

六、核心结论

工业数据库 AI Agent 工程化落地的关键，不在于让大模型具备直接编写复杂 SQL 的能力，而在于架构上建立刚性隔离：大模型仅负责前半段的意图解析与后半段的计算结果总结，中段计算逻辑交由业务语义层映射、DSL 形式化与图算法转换完成。

通过引入 Business Semantic Layer + Industrial DSL + Graph Transformation + SQL Execution + LLM Summarization 的完整闭环，架构实现了概率智能与工业规则的深度协同：

LLM 将自然语言解析并映射到业务语义层；
业务语义层转化为形式化 DSL；
图转化引擎通过图算法将 DSL 精准转换为无误的物理 SQL；
SQL 引擎完成高可靠的确定性计算；
最终结果送回 LLM 进行业务总结呈现。

这一架构将工业数据分析从"全链路概率随机"提升为"概率意图解析 + 语义映射 + DSL 约束 + 图转换 SQL + 确定执行 + 概率总结"的可控工程体系，全面保障语义一致性、口径稳定性、过程可解释性与全链路可审计性，为工业 AI 的规模化与可靠落地提供坚实的架构支撑。