工业 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 负责对确定数据进行概率化的解释、排序和总结。 【非确定空间 (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 ReliabilityIntelligence (理解/总结)Semantic Layer (业务建模)DSL (形式约束)Graph Governance (图转化)\boxed{\text{Industrial Reliability} \text{Intelligence (理解/总结)} \text{Semantic Layer (业务建模)} \text{DSL (形式约束)} \text{Graph Governance (图转化)}}Industrial ReliabilityIntelligence (理解/总结)Semantic Layer (业务建模)DSL (形式约束)Graph Governance (图转化)二、核心矛盾数据库语义计算层 vs 通用数据处理层工业数据不能只被看作“字段和值”它本身承载着设备、测点、状态、指标和业务规则等语义。将这些数据脱离原有语义直接抽取出来进行通用二次分析本质上是在计算过程中丢弃业务上下文。1. 业务语义层与 DSL 的分工协作业务语义层Semantic Layer定义统一的工业业务对象、指标口径、设备关系和业务规则并负责将用户意图绑定到经过治理的业务语义。它解决“业务是什么、指标怎么算、规则是什么”。DSLDomain-Specific Language将完成语义绑定的分析意图转换为结构化、形式化的表达作为校验、分析计划生成和 SQL 编译的统一输入。它解决“这次分析做什么以及如何形式化表达”用户输入自然语言例如“分析最近24小时1号泵的异常振动”系统不会让 LLM 直接拼接并执行简单 SQL-- 错误范例脱离业务语义层与 DSL 的直接 SQL 拼接SELECTavg(vibration)FROMsensor_dataWHEREdevice_idpump_1ANDtimenow()-interval24 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 Layer2. 工业算子注册与契约治理Operator Registry防止 AI 自行生成、简化或修改核心计算逻辑算子注册与强类型契约统一管理输入/输出 Schema、参数约束、适用范围、版本及认证状态Agent 只能引用已注册算子。Semantic Layer DSL3. 数据质量控制与结果可信度评估Data Reliability控制数据质量问题对分析结果的影响避免脏数据进入计算链路数据质量检查与质量状态标注对完整性、有效性、时效性等进行硬约束检查并在结果中保留数据质量状态与上下文信息。Data / Execution Layer4. DSL 编译与查询治理DSL Compiler Query Governance防止非法查询、无界扫描和不可控资源消耗静态校验、分析计划与资源约束解析和校验 DSL生成分析计划复杂任务可构建计算图并在 SQL 生成阶段注入时间范围、分区、扫描、超时和资源预算约束。DSL Compiler5. 全局语义与规则治理Global Semantic Governance防止多 Agent、跨系统分析产生业务口径和计算窗口冲突统一语义基线所有 Agent 共享统一的对象、指标、算子、规则及时间窗口定义并通过版本机制保证跨 Agent 一致性。Semantic Governance6. 版本、血缘与审计治理Version, Lineage Audit保证历史分析过程可追溯、可解释和可复现分析履历快照关联保存 Semantic Model、DSL、规则、算子、数据快照、Generated SQL 及数据库执行信息形成完整分析血缘。Governance / Audit Layer1. 业务语义与元数据治理Semantic Metamodel工业 AI Agent 首先需要解决的不是“如何生成 SQL”而是如何确定用户所说的业务对象、指标和分析规则究竟对应什么。工业数据库及其上层语义模型通常承载了设备、测点、指标、状态、拓扑关系以及相关业务规则。业务语义层将这些信息组织为统一的业务模型并向 Agent 提供稳定的语义接口使 Agent 不需要直接面对底层物理表、字段和存储结构。例如用户提出“分析最近 24 小时 1 号泵的异常振动。”LLM 首先提取候选意图{device:1号泵,metric:异常振动,time_range:24h}随后由业务语义层完成语义绑定“1号泵” ↓ pump_001 ↓ 设备实体 测点集合 拓扑关系 “异常振动” ↓ pump.vibration.anomaly ↓ 规定的振动指标 异常判定规则 “最近24小时” ↓ 统一时间范围定义这里需要特别区分LLM 负责提出候选意图业务语义层负责将候选概念绑定到经过治理的业务实体和指标定义。因此LLM 面向的不是数据库的物理结构而是经过业务语义层定义的业务对象。例如LLM 只需要理解“1号泵” “振动 RMS” “最近24小时”而不需要直接处理哪张物理表存储了 1 号泵的数据 哪个字段对应振动 RMS 数据按哪个字段进行分区 设备 ID 在数据库中具体是什么值这些物理映射由业务语义层和 DSL Compiler 负责完成。更直观的映射关系可以写成用户 / 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 │ └─────────────────────────────┘ │ ▼ SQLLLM 负责理解“分析什么”业务语义层负责确定“这些业务概念对应什么”DSL Compiler 负责将语义逻辑映射为数据库能够执行的物理查询。一句话概括就是让 LLM 面向业务语义而不是面向数据库 Schema让 Compiler 面向物理执行而不是让 LLM 直接操作物理数据结构。这样可以将自然语言理解与物理数据库 Schema 解耦降低字段错配、对象误绑定和指标口径漂移的风险。2. 工业算子注册与契约治理Operator Registry业务指标不仅需要定义名称还需要明确具体如何计算。例如“振动”可能对应 RMS、Peak、Peak-to-Peak、Kurtosis 等不同特征复杂的设备诊断还可能依赖多个特征组合、状态条件和专用算法。如果允许 LLM 自行生成这些计算公式即使 SQL 语法正确也可能产生与工业规范不一致的计算结果。因此需要建立统一的Industrial Operator Registry将经过验证的工业计算能力注册为标准算子Industrial Operator Registry ├── vibration.rms() ├── vibration.peak() ├── vibration.kurtosis() ├── bearing_fault_score() ├── energy_efficiency() ├── thermal_drift() └── leak_detection()每个算子可以维护统一的契约信息{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 不负责证明结果正确而负责控制哪些数据可以进入计算链路并为最终结果保留必要的数据质量上下文。工业现场常见的数据问题包括采样缺失数据延迟传感器漂移突发毛刺超出物理量程设备停机期间产生的无效数据启停机过程中的瞬态数据。这些问题的处理方式通常不是“给一个综合分数”而是明确的质量约束Completeness 90% ↓ 拒绝计算或者设备停机状态 ↓ 剔除该时间段数据再或者短时缺失 ↓ 允许插值这类规则应该被固化在数据治理和 DSL / Operator 定义中而不是由 LLM 临时决定。因此数据质量这一层更准确的工程描述应该是Data Reliability │ ┌────────────┼────────────┐ ↓ ↓ ↓ 数据完整性 数据有效性 数据时效性 │ │ │ └────────────┼────────────┘ ↓ 数据质量检查 │ ┌─────────┴─────────┐ ↓ ↓ 满足要求 不满足要求 │ │ ↓ ↓ 参与计算 拒绝 / 降级 / 标记 │ ↓ 计算结果 数据质量上下文这意味着硬约束数据是否满足计算前提规则处理缺失、停机、超量程、瞬态如何处理质量标注最终结果附带数据状态与质量背景而不是给出一个看起来“科学”但往往难以解释的 Trust Score。例如系统可能输出分析结果 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 优化”而是完成DSL ↓ 解析 ↓ 语法 / 类型 / 语义校验 ↓ 分析计划 ↓ SQL 生成 ↓ Query Governance ↓ Database对于简单查询分析计划可能非常直接pump_001 ↓ 24h ↓ vibration.rms() ↓ threshold_check()对于涉及多个设备、多个指标或复杂依赖关系的任务则可以进一步构建Computation Graph / DAG用于表达计算依赖、数据依赖和拓扑关系。例如泵 ├── 振动测点 │ ↓ │ vibration.rms() │ ↓ │ anomaly_check() │ └── 运行状态 ↓ state_filter()因此DAG 更适合作为复杂分析任务的内部计算表示用于描述多个计算步骤之间的数据依赖关系对于简单的 DSL 查询则可以直接进行规则解析与 SQL 生成无需显式构建 DAG。在 SQL 生成之前Compiler / Query Governance 还需要进行静态安全检查例如时间范围是否明确是否存在无界查询是否访问允许的数据域是否满足分区条件是否超过扫描规模限制是否超过 Agent 的资源预算是否存在非法算子组合是否存在循环依赖。最终生成符合 DSL 语义的 SQL。需要注意的是DSL Compiler 负责将经过语义解析和校验的 DSL转换成确定的查询逻辑数据库自身的 Optimizer 再负责根据具体数据库的统计信息、索引、分区和执行能力生成物理执行计划。对于简单查询这一过程可以直接落到一个确定的查询逻辑对于包含多个依赖计算步骤的复杂分析任务可以用DAG作为内部表示显式表达计算依赖、数据依赖和拓扑关系。因此二者职责应明确区分Industrial DSL ↓ DSL Compiler ↓ Logical Query Plan ↓ Generated SQL ↓ Database Optimizer ↓ Physical Execution Plan ↓ ExecutionDSL Compiler 把经过语义解析和校验的 DSL 转换成一个确定的逻辑查询计划复杂任务则进一步用 DAG 表示其计算依赖。这样既保留了 DSL 对查询过程的控制又不会把 DSL Compiler 与数据库 Optimizer 混为一谈。5. 全局语义与规则治理Global Semantic Governance当系统从单个 Agent 扩展到多个专业 Agent 后新的问题不再只是“某一个 Agent 算得对不对”而是不同 Agent 是否在使用同一套业务定义例如设备健康 Agent │ ├── 使用“运行时间” │ 能耗 Agent ──┤ │ └── 使用“运行功率” ↓ 是否采用相同的 状态过滤与时间窗口如果不同 Agent 各自定义指标就可能出现Agent A 平均功率 过去 1 小时所有采样点平均值 Agent B 平均功率 设备运行状态下的 5 分钟窗口平均值两者计算结果都可能在数学上正确但业务口径并不一致。因此需要建立统一的语义与规则治理机制使不同 Agent 共享统一设备与测点定义统一指标口径统一算子定义统一状态规则统一时间窗口统一数据质量规则统一规则版本。架构上可以理解为Agent A Agent B Agent C │ │ │ └──────────────┼──────────────┘ ↓ Global Semantic Governance │ ┌───────────┼───────────┐ ↓ ↓ ↓ Objects Metrics Rules │ │ │ └───────────┼───────────┘ ↓ Industrial DSL这里的核心不是简单地让所有 Agent “共享一个 DSL”而是让所有 Agent 建立在同一套经过治理的业务语义和规则基线上。这样才能保证跨 Agent 分析结果具有可比性和可组合性。6. 版本、血缘与审计治理Version, Lineage Audit工业分析不仅需要回答“这次计算结果是什么”还需要回答“这个结果当时是基于什么业务定义、什么规则、什么数据和什么计算逻辑得到的”因此每次分析都应该形成完整的分析履历而不仅仅保存最终 SQL。例如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 就能保证绝对复现。真正的历史复现依赖于多个条件同时保持一致Reproducibility f( Semantic Version, Rule Version, Operator Version, Data Snapshot, DSL, SQL, Execution Environment )因此系统真正需要保存的是分析过程的完整血缘Lineage。这样当未来出现“为什么 2026 年的诊断结论与 2025 年不同”系统可以沿着完整血缘逐层追溯业务定义是否变化 ↓ 指标口径是否变化 ↓ 规则是否变化 ↓ 算子版本是否变化 ↓ 输入数据是否变化 ↓ DSL 是否变化 ↓ Generated SQL 是否变化 ↓ 数据库执行环境是否变化最终将“一个结果”还原为一条可审计的计算链路。这也是工业 AI 与普通自然语言数据分析系统的重要区别系统不仅要给出结果还必须能够解释结果是依据什么定义、什么规则和什么数据产生的。四、AI Agent 与 Executing Pipelines 的全链路工作流程工业确定性分析依赖于概率推理意图解析 结果总结与规则计算业务语义映射、DSL 校验、图转化及 SQL 执行的分层解耦。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 6LLM Summarization (概率总结层)对确定性 SQL 执行结果进行自然语言总结、生成分析报告与业务洞察概率推理 / 自然语言输出Layer 5SQL Execution Engine (确定执行层)物理 SQL 脚本执行、结果集提取、资源隔离与性能保证确定计算Layer 4DSL Graph Compiler (图转化与编译层)DSL 语法校验、图算法DAG转换物理 SQL、Query Governance形式化约束 / 图转换Layer 3Business Semantic Layer (业务语义层)业务对象建模、指标口径规范 (Metric OS)、图拓扑关系定义业务抽象与口径固化Layer 2Agent Reasoning (意图解析层)意图解析 (Intent Parser)、任务规划 (Planner)、语义关联与 Candidate DSL 生成概率推理 / 意图生成Layer 1Industrial Data Metamodel (物理事实与元数据层)传感器时序数据、设备关系图谱、物理表模型、原始事件日志物理事实六、核心结论工业数据库 AI Agent 工程化落地的关键不在于让大模型具备直接编写复杂 SQL 的能力而在于架构上建立刚性隔离大模型仅负责前半段的意图解析与后半段的计算结果总结中段计算逻辑交由业务语义层映射、DSL 形式化与图算法转换完成。通过引入Business Semantic Layer Industrial DSL Graph Transformation SQL Execution LLM Summarization的完整闭环架构实现了概率智能与工业规则的深度协同LLM 将自然语言解析并映射到业务语义层业务语义层转化为形式化 DSL图转化引擎通过图算法将 DSL 精准转换为无误的物理 SQLSQL 引擎完成高可靠的确定性计算最终结果送回 LLM 进行业务总结呈现。这一架构将工业数据分析从“全链路概率随机”提升为“概率意图解析 语义映射 DSL 约束 图转换 SQL 确定执行 概率总结”的可控工程体系全面保障语义一致性、口径稳定性、过程可解释性与全链路可审计性为工业 AI 的规模化与可靠落地提供坚实的架构支撑。 工业 AI Agent 引入 DSL 的架构必要性：从概率生成到确定执行
工业 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 负责对确定数据进行概率化的解释、排序和总结。 【非确定空间 (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 ReliabilityIntelligence (理解/总结)Semantic Layer (业务建模)DSL (形式约束)Graph Governance (图转化)\boxed{\text{Industrial Reliability} \text{Intelligence (理解/总结)} \text{Semantic Layer (业务建模)} \text{DSL (形式约束)} \text{Graph Governance (图转化)}}Industrial ReliabilityIntelligence (理解/总结)Semantic Layer (业务建模)DSL (形式约束)Graph Governance (图转化)二、核心矛盾数据库语义计算层 vs 通用数据处理层工业数据不能只被看作“字段和值”它本身承载着设备、测点、状态、指标和业务规则等语义。将这些数据脱离原有语义直接抽取出来进行通用二次分析本质上是在计算过程中丢弃业务上下文。1. 业务语义层与 DSL 的分工协作业务语义层Semantic Layer定义统一的工业业务对象、指标口径、设备关系和业务规则并负责将用户意图绑定到经过治理的业务语义。它解决“业务是什么、指标怎么算、规则是什么”。DSLDomain-Specific Language将完成语义绑定的分析意图转换为结构化、形式化的表达作为校验、分析计划生成和 SQL 编译的统一输入。它解决“这次分析做什么以及如何形式化表达”用户输入自然语言例如“分析最近24小时1号泵的异常振动”系统不会让 LLM 直接拼接并执行简单 SQL-- 错误范例脱离业务语义层与 DSL 的直接 SQL 拼接SELECTavg(vibration)FROMsensor_dataWHEREdevice_idpump_1ANDtimenow()-interval24 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 Layer2. 工业算子注册与契约治理Operator Registry防止 AI 自行生成、简化或修改核心计算逻辑算子注册与强类型契约统一管理输入/输出 Schema、参数约束、适用范围、版本及认证状态Agent 只能引用已注册算子。Semantic Layer DSL3. 数据质量控制与结果可信度评估Data Reliability控制数据质量问题对分析结果的影响避免脏数据进入计算链路数据质量检查与质量状态标注对完整性、有效性、时效性等进行硬约束检查并在结果中保留数据质量状态与上下文信息。Data / Execution Layer4. DSL 编译与查询治理DSL Compiler Query Governance防止非法查询、无界扫描和不可控资源消耗静态校验、分析计划与资源约束解析和校验 DSL生成分析计划复杂任务可构建计算图并在 SQL 生成阶段注入时间范围、分区、扫描、超时和资源预算约束。DSL Compiler5. 全局语义与规则治理Global Semantic Governance防止多 Agent、跨系统分析产生业务口径和计算窗口冲突统一语义基线所有 Agent 共享统一的对象、指标、算子、规则及时间窗口定义并通过版本机制保证跨 Agent 一致性。Semantic Governance6. 版本、血缘与审计治理Version, Lineage Audit保证历史分析过程可追溯、可解释和可复现分析履历快照关联保存 Semantic Model、DSL、规则、算子、数据快照、Generated SQL 及数据库执行信息形成完整分析血缘。Governance / Audit Layer1. 业务语义与元数据治理Semantic Metamodel工业 AI Agent 首先需要解决的不是“如何生成 SQL”而是如何确定用户所说的业务对象、指标和分析规则究竟对应什么。工业数据库及其上层语义模型通常承载了设备、测点、指标、状态、拓扑关系以及相关业务规则。业务语义层将这些信息组织为统一的业务模型并向 Agent 提供稳定的语义接口使 Agent 不需要直接面对底层物理表、字段和存储结构。例如用户提出“分析最近 24 小时 1 号泵的异常振动。”LLM 首先提取候选意图{device:1号泵,metric:异常振动,time_range:24h}随后由业务语义层完成语义绑定“1号泵” ↓ pump_001 ↓ 设备实体 测点集合 拓扑关系 “异常振动” ↓ pump.vibration.anomaly ↓ 规定的振动指标 异常判定规则 “最近24小时” ↓ 统一时间范围定义这里需要特别区分LLM 负责提出候选意图业务语义层负责将候选概念绑定到经过治理的业务实体和指标定义。因此LLM 面向的不是数据库的物理结构而是经过业务语义层定义的业务对象。例如LLM 只需要理解“1号泵” “振动 RMS” “最近24小时”而不需要直接处理哪张物理表存储了 1 号泵的数据 哪个字段对应振动 RMS 数据按哪个字段进行分区 设备 ID 在数据库中具体是什么值这些物理映射由业务语义层和 DSL Compiler 负责完成。更直观的映射关系可以写成用户 / 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 │ └─────────────────────────────┘ │ ▼ SQLLLM 负责理解“分析什么”业务语义层负责确定“这些业务概念对应什么”DSL Compiler 负责将语义逻辑映射为数据库能够执行的物理查询。一句话概括就是让 LLM 面向业务语义而不是面向数据库 Schema让 Compiler 面向物理执行而不是让 LLM 直接操作物理数据结构。这样可以将自然语言理解与物理数据库 Schema 解耦降低字段错配、对象误绑定和指标口径漂移的风险。2. 工业算子注册与契约治理Operator Registry业务指标不仅需要定义名称还需要明确具体如何计算。例如“振动”可能对应 RMS、Peak、Peak-to-Peak、Kurtosis 等不同特征复杂的设备诊断还可能依赖多个特征组合、状态条件和专用算法。如果允许 LLM 自行生成这些计算公式即使 SQL 语法正确也可能产生与工业规范不一致的计算结果。因此需要建立统一的Industrial Operator Registry将经过验证的工业计算能力注册为标准算子Industrial Operator Registry ├── vibration.rms() ├── vibration.peak() ├── vibration.kurtosis() ├── bearing_fault_score() ├── energy_efficiency() ├── thermal_drift() └── leak_detection()每个算子可以维护统一的契约信息{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 不负责证明结果正确而负责控制哪些数据可以进入计算链路并为最终结果保留必要的数据质量上下文。工业现场常见的数据问题包括采样缺失数据延迟传感器漂移突发毛刺超出物理量程设备停机期间产生的无效数据启停机过程中的瞬态数据。这些问题的处理方式通常不是“给一个综合分数”而是明确的质量约束Completeness 90% ↓ 拒绝计算或者设备停机状态 ↓ 剔除该时间段数据再或者短时缺失 ↓ 允许插值这类规则应该被固化在数据治理和 DSL / Operator 定义中而不是由 LLM 临时决定。因此数据质量这一层更准确的工程描述应该是Data Reliability │ ┌────────────┼────────────┐ ↓ ↓ ↓ 数据完整性 数据有效性 数据时效性 │ │ │ └────────────┼────────────┘ ↓ 数据质量检查 │ ┌─────────┴─────────┐ ↓ ↓ 满足要求 不满足要求 │ │ ↓ ↓ 参与计算 拒绝 / 降级 / 标记 │ ↓ 计算结果 数据质量上下文这意味着硬约束数据是否满足计算前提规则处理缺失、停机、超量程、瞬态如何处理质量标注最终结果附带数据状态与质量背景而不是给出一个看起来“科学”但往往难以解释的 Trust Score。例如系统可能输出分析结果 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 优化”而是完成DSL ↓ 解析 ↓ 语法 / 类型 / 语义校验 ↓ 分析计划 ↓ SQL 生成 ↓ Query Governance ↓ Database对于简单查询分析计划可能非常直接pump_001 ↓ 24h ↓ vibration.rms() ↓ threshold_check()对于涉及多个设备、多个指标或复杂依赖关系的任务则可以进一步构建Computation Graph / DAG用于表达计算依赖、数据依赖和拓扑关系。例如泵 ├── 振动测点 │ ↓ │ vibration.rms() │ ↓ │ anomaly_check() │ └── 运行状态 ↓ state_filter()因此DAG 更适合作为复杂分析任务的内部计算表示用于描述多个计算步骤之间的数据依赖关系对于简单的 DSL 查询则可以直接进行规则解析与 SQL 生成无需显式构建 DAG。在 SQL 生成之前Compiler / Query Governance 还需要进行静态安全检查例如时间范围是否明确是否存在无界查询是否访问允许的数据域是否满足分区条件是否超过扫描规模限制是否超过 Agent 的资源预算是否存在非法算子组合是否存在循环依赖。最终生成符合 DSL 语义的 SQL。需要注意的是DSL Compiler 负责将经过语义解析和校验的 DSL转换成确定的查询逻辑数据库自身的 Optimizer 再负责根据具体数据库的统计信息、索引、分区和执行能力生成物理执行计划。对于简单查询这一过程可以直接落到一个确定的查询逻辑对于包含多个依赖计算步骤的复杂分析任务可以用DAG作为内部表示显式表达计算依赖、数据依赖和拓扑关系。因此二者职责应明确区分Industrial DSL ↓ DSL Compiler ↓ Logical Query Plan ↓ Generated SQL ↓ Database Optimizer ↓ Physical Execution Plan ↓ ExecutionDSL Compiler 把经过语义解析和校验的 DSL 转换成一个确定的逻辑查询计划复杂任务则进一步用 DAG 表示其计算依赖。这样既保留了 DSL 对查询过程的控制又不会把 DSL Compiler 与数据库 Optimizer 混为一谈。5. 全局语义与规则治理Global Semantic Governance当系统从单个 Agent 扩展到多个专业 Agent 后新的问题不再只是“某一个 Agent 算得对不对”而是不同 Agent 是否在使用同一套业务定义例如设备健康 Agent │ ├── 使用“运行时间” │ 能耗 Agent ──┤ │ └── 使用“运行功率” ↓ 是否采用相同的 状态过滤与时间窗口如果不同 Agent 各自定义指标就可能出现Agent A 平均功率 过去 1 小时所有采样点平均值 Agent B 平均功率 设备运行状态下的 5 分钟窗口平均值两者计算结果都可能在数学上正确但业务口径并不一致。因此需要建立统一的语义与规则治理机制使不同 Agent 共享统一设备与测点定义统一指标口径统一算子定义统一状态规则统一时间窗口统一数据质量规则统一规则版本。架构上可以理解为Agent A Agent B Agent C │ │ │ └──────────────┼──────────────┘ ↓ Global Semantic Governance │ ┌───────────┼───────────┐ ↓ ↓ ↓ Objects Metrics Rules │ │ │ └───────────┼───────────┘ ↓ Industrial DSL这里的核心不是简单地让所有 Agent “共享一个 DSL”而是让所有 Agent 建立在同一套经过治理的业务语义和规则基线上。这样才能保证跨 Agent 分析结果具有可比性和可组合性。6. 版本、血缘与审计治理Version, Lineage Audit工业分析不仅需要回答“这次计算结果是什么”还需要回答“这个结果当时是基于什么业务定义、什么规则、什么数据和什么计算逻辑得到的”因此每次分析都应该形成完整的分析履历而不仅仅保存最终 SQL。例如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 就能保证绝对复现。真正的历史复现依赖于多个条件同时保持一致Reproducibility f( Semantic Version, Rule Version, Operator Version, Data Snapshot, DSL, SQL, Execution Environment )因此系统真正需要保存的是分析过程的完整血缘Lineage。这样当未来出现“为什么 2026 年的诊断结论与 2025 年不同”系统可以沿着完整血缘逐层追溯业务定义是否变化 ↓ 指标口径是否变化 ↓ 规则是否变化 ↓ 算子版本是否变化 ↓ 输入数据是否变化 ↓ DSL 是否变化 ↓ Generated SQL 是否变化 ↓ 数据库执行环境是否变化最终将“一个结果”还原为一条可审计的计算链路。这也是工业 AI 与普通自然语言数据分析系统的重要区别系统不仅要给出结果还必须能够解释结果是依据什么定义、什么规则和什么数据产生的。四、AI Agent 与 Executing Pipelines 的全链路工作流程工业确定性分析依赖于概率推理意图解析 结果总结与规则计算业务语义映射、DSL 校验、图转化及 SQL 执行的分层解耦。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 6LLM Summarization (概率总结层)对确定性 SQL 执行结果进行自然语言总结、生成分析报告与业务洞察概率推理 / 自然语言输出Layer 5SQL Execution Engine (确定执行层)物理 SQL 脚本执行、结果集提取、资源隔离与性能保证确定计算Layer 4DSL Graph Compiler (图转化与编译层)DSL 语法校验、图算法DAG转换物理 SQL、Query Governance形式化约束 / 图转换Layer 3Business Semantic Layer (业务语义层)业务对象建模、指标口径规范 (Metric OS)、图拓扑关系定义业务抽象与口径固化Layer 2Agent Reasoning (意图解析层)意图解析 (Intent Parser)、任务规划 (Planner)、语义关联与 Candidate DSL 生成概率推理 / 意图生成Layer 1Industrial Data Metamodel (物理事实与元数据层)传感器时序数据、设备关系图谱、物理表模型、原始事件日志物理事实六、核心结论工业数据库 AI Agent 工程化落地的关键不在于让大模型具备直接编写复杂 SQL 的能力而在于架构上建立刚性隔离大模型仅负责前半段的意图解析与后半段的计算结果总结中段计算逻辑交由业务语义层映射、DSL 形式化与图算法转换完成。通过引入Business Semantic Layer Industrial DSL Graph Transformation SQL Execution LLM Summarization的完整闭环架构实现了概率智能与工业规则的深度协同LLM 将自然语言解析并映射到业务语义层业务语义层转化为形式化 DSL图转化引擎通过图算法将 DSL 精准转换为无误的物理 SQLSQL 引擎完成高可靠的确定性计算最终结果送回 LLM 进行业务总结呈现。这一架构将工业数据分析从“全链路概率随机”提升为“概率意图解析 语义映射 DSL 约束 图转换 SQL 确定执行 概率总结”的可控工程体系全面保障语义一致性、口径稳定性、过程可解释性与全链路可审计性为工业 AI 的规模化与可靠落地提供坚实的架构支撑。