LLM 应该加在工业系统的哪一层？

工业系统最怕的不是模型不够聪明，而是把不确定性放错位置。PLC、SIS、SCADA、MES 和专用算法承担的是确定性控制、实时响应与稳定运行；LLM 更适合进入它们之上的语义、认知与协同层：理解人的问题，检索现场知识，调用受控工具，编排跨系统流程，并在高风险动作前停下来等待审批。

核心结论｜传统工业 AI 不会被 LLM 替换。真正可落地的架构，是保留底层专用模型和业务系统，再向上叠加 Ontology、RAG、Tool Calling、Workflow、Eval、Observability 与 Human-in-the-loop，形成“数据 → 语义 → 认知 → 行动”的闭环。

一、先选场景，再选模型

工业 AI 项目经常从一句“我们也上个大模型”开始，但真正能产生 ROI 的项目，往往从一个非常具体的业务动词开始：识别缺陷、预测故障、推荐参数、优化负荷、重排订单。模型只是实现手段，场景决定数据、部署位置、容错方式和成功指标。

图 1：五类典型工业 AI 场景必须同时看目标、数据、算法、部署、KPI 与失败原因

1. 智能质检：最容易看见效果，也最容易被现场环境击穿

智能质检的业务目标通常是降低漏检、降低误判、减少人工复核，数据来自工业相机、线扫相机、光源控制器、产品批次、设备参数和人工判定记录。传统算法以目标检测、图像分类、分割与无监督异常检测为主，常见模型包括 YOLO、DETR、ViT、PatchCore、PaDiM。

部署位置通常在产线边缘侧：工业 PC、Jetson 或带 GPU 的边缘节点负责低延迟推理，PLC 根据确定性信号完成剔除。LLM 不应该进入毫秒级剔除回路，它更适合解释缺陷趋势、检索检验规范、汇总批次差异、生成复核建议。

核心 KPI｜不要只看离线 mAP。生产侧更关心相对人工基线的漏检率、误判率、复检工时、报废成本，以及换光源、换产品、换班次之后是否仍然稳定。

常见失败并不是模型训练失败，而是现场光照变化、镜头污染、产品外观漂移、正负样本比例极端、缺陷定义在不同质检员之间不一致。视觉模型需要持续监控，LLM 只能帮助解释和协作，不能替代确定性判定与质量规则。

2. 预测性维护：不是“预测会坏”，而是“提前多久、谁来处理”

预测性维护的数据来自振动、温度、电流、声学、润滑、报警、维修工单和备件记录。传统算法包括时序异常检测、故障分类和剩余寿命 RUL 预测。真正有价值的结果，不是模型给出一个异常分数，而是能回答：哪台设备、哪个部件、在多长时间窗口内、以什么风险等级需要检查。

部署通常跨越边缘与平台：边缘侧完成信号处理和快速异常判断，平台侧做跨周期分析、工单关联和资产健康管理。LLM Agent 可以检索维修手册、读取历史工单、解释波形摘要、生成工单初稿，但最后的停机决定和维修优先级仍应由维护人员确认。Siemens 的工业 AI 与 Industrial Copilot 资料也把生成式 AI 放在维修周期的辅助、解释和协同位置，而不是直接替代安全控制。[8]

核心 KPI 包括非计划停机小时数、告警提前量、误报率、故障捕获率和维修资源利用率。这个场景最怕误报：如果系统连续几次“狼来了”，操作员会直接关闭告警。

3. 工艺优化：最有价值，也最需要克制

工艺优化希望提高良率、降低能耗、稳定 Cpk，并减少对少数老师傅经验的依赖。数据来自设定参数、过程曲线、环境、原料批次、设备状态和最终质量。传统方法包括响应面、贝叶斯优化、高斯过程、模型预测控制 MPC 和数字孪生。

工业现场通常接受“推荐 → 仿真或规则校验 → 人工确认 → 下发”，很少接受“LLM 自主调参”。因为工艺参数之间存在强耦合，数据中有大量混淆变量，且错误动作可能造成整批报废、设备损伤甚至安全风险。LLM 的合理位置是解释模型建议、引用工艺依据、组织试验计划和审批材料。

4. 能效优化：不能只省电，还要保证产量

能效优化覆盖电、气、蒸汽、压缩空气与冷却系统，数据来自智能电表、EMS、生产计划、设备负荷和峰谷电价。传统算法通常是负荷预测、混合整数规划 MILP、优化调度或强化学习。

部署需要与 EMS 和排产系统联动，但动作必须尊重生产约束。核心 KPI 是单位产量能耗、需量电费、峰值负荷和碳排强度。常见失败是只优化能源曲线，却忽略插单、换型和产能目标。Agent 适合协调“生产计划—能源价格—设备能力”之间的信息，不适合绕过能源管理规则直接控制关键设备。

5. 供应链协同：算法问题经常被数据主权问题盖住

供应链协同涉及需求预测、库存优化、APS 排产、运输与交付，数据分散在 ERP、APS、WMS、SRM 和 CRM。传统算法包括时序与概率预测、运筹优化、启发式排产。

这类系统必须输出可解释的约束与原因：为什么延后某订单、为什么增加安全库存、哪个物料成为瓶颈。LLM Agent 可以把自然语言需求转成查询与计划，汇总跨部门约束，但预测偏差、指标口径和权限边界仍需要确定性系统承担。

场景选择原则｜先找数据存在、Owner 明确、Baseline 可测、风险可控的场景。不要因为大模型热门，就把一个本来适合规则、统计模型或看板的问题强行改造成 Agent。

二、LLM 不会替代传统工业 AI

传统工业 AI 栈通常是：PLC / Sensors / SCADA / MES / ERP 提供数据，数据平台完成采集与治理，专用模型负责视觉、时序或表格任务，最终通过看板、告警和工单交付结果。这个架构的优势是确定性强、边界清楚、延迟可控。

LLM Agent 不是把这条链推倒重来，而是在上面增加三类能力：把字段和系统翻译成业务语义；把文档、经验和实时数据组合成上下文；把跨系统任务编排为受控动作。

图 2：传统工业 AI 栈与 LLM Agent 增强栈

可以把两套栈的分工理解成四层：

数据层负责“发生了什么”：传感器、设备状态、订单、批次、工单和质量记录。

语义层负责“这些数据在业务里代表什么”：设备、工单、批次、缺陷、班次以及它们之间的关系。

认知层负责“如何理解和组合证据”：RAG、LLM、工具选择、推理与计划。

行动层负责“如何安全地把建议变成业务动作”：Workflow、审批、幂等、审计与回滚。

位置判断｜只要一个环节要求毫秒级响应、数学确定性、硬实时、安全联锁或强一致，就不应让 LLM 成为最终执行者。LLM 更适合处理语言、非结构化知识、跨系统协作和异常情形。

三、LLM Agent 落地需要的八块拼图

讲义把 Agent 技术栈拆成 RAG、Tool、Workflow、Memory、Reasoning、Eval、Observability 和 Human-in-the-loop。每一块都不是新名词，但工业项目的难点在于：这些组件必须围绕权限、实时性、追溯、回滚和责任边界重新设计。

图 3：LLM Agent 进入生产所需的八块工程拼图

1. RAG：不是把文档塞进向量库

RAG 把模型的参数化知识与外部可更新知识结合起来，原始论文强调了外部非参数记忆对知识更新与来源追溯的价值。[2] 在工业场景里，知识源不仅是 PDF，还包括 SOP、故障手册、图纸属性、维修记录、质量规范、工艺变更单和设备档案。

工程上至少要解决四件事：按章节、设备、故障码和版本切片；关键词与向量混合检索；对候选结果重排；答案必须带来源、文档版本和有效期。一个检索到旧版 SOP 的“正确回答”，在现场可能比拒答更危险。

2. Tool Calling：模型决定调用，程序负责执行

工具调用把数据库查询、工单创建、模型推理、仿真和业务 API 封装成模型可选择的结构化能力。模型只能生成调用意图，真正执行必须由后端完成。

鉴权：工具使用发起人的身份与权限，不能使用万能管理员账户。

幂等：重复调用同一 requestId 不应创建两张工单或重复下发动作。

超时与重试：查询工具可以重试，写操作重试必须结合幂等键。

参数校验：设备 ID、时间范围、参数上下限和枚举值必须由程序校验。

审计与回滚：记录谁、何时、基于什么证据、调用了什么动作；可逆动作必须有补偿路径。

下面是一份简化的工业工具定义。代码的重点不在语法，而在于把权限、风险等级和幂等要求写进接口契约：

{  "name": "create_maintenance_ticket",  "description": "为指定设备创建维修工单草稿，不直接提交",  "input_schema": {    "type": "object",    "properties": {      "machine_id": {"type": "string"},      "reason": {"type": "string"},      "priority": {"enum": ["LOW", "MEDIUM", "HIGH"]},      "evidence_ids": {"type": "array", "items": {"type": "string"}},      "idempotency_key": {"type": "string"}    },    "required": ["machine_id", "reason", "evidence_ids", "idempotency_key"]  },  "policy": {    "mode": "DRAFT_ONLY",    "required_role": "MAINTENANCE_PLANNER",    "human_approval": true  }}

3. Workflow：先显式流程，再谨慎增加自主性

工业任务往往有明确 SOP。最稳的做法是用确定性 DAG 或状态机管理关键步骤，只把“意图理解、证据归纳、计划候选”交给 LLM。这样每一步都能回放、暂停、重试和审计。

例如“分析产线变慢”可以固定为：确认时间范围 → 查询 OEE 与停机 → 检查设备告警 → 检查换型与订单 → 检查不良率 → 汇总证据。LLM 可以决定哪些分支需要深入，但不能跳过权限检查和结果校验。

4. Memory：记忆不是无限保存聊天记录

短期记忆用于当前任务上下文，长期记忆可以保存设备档案、班次状态、用户偏好和历史决策。但工业记忆必须有写入条件、有效期、版本、权限和遗忘策略。

尤其要避免把模型推断当成事实写入长期记忆。更稳的做法是区分“已确认事实、系统状态、人工结论、模型假设”，只有经过验证的内容才能成为下一次任务的可信上下文。

5. Reasoning：推理越长，不代表越可靠

Agent 可以采用 ReAct、Plan-then-Execute 等模式拆解任务，但生产系统必须设置最大步数、最大工具调用次数、最大执行时间和失败回退。长链路会放大延迟、成本和错误累积。

不要要求模型输出内部思考过程。工程上更有价值的是结构化计划、每一步使用的证据、工具结果和最终判断，让系统可以复现和审计。

6. Eval：没有 Gold Set，就没有工程

工业 Eval 不能只测“回答像不像”。需要建立真实业务问句、标准 SQL、标准答案、允许误差范围、工具调用路径和拒答条件。评测指标至少覆盖答案正确率、执行成功率、工具调用成功率、引用准确率、越权率和高风险动作拦截率。

线上失败样本要回流到 Gold Set。每次更换模型、Prompt、Schema、索引或工具版本，都必须跑回归测试。OpenAI 的 Agent 工程指南同样强调：先从简单架构开始，通过真实失败和评测逐步增加复杂度。[7]

7. Observability：必须看见一条任务如何走完

可观测不只是记录最终答案，还要记录 Router 决策、检索 query、命中文档、重排分数、Prompt 版本、模型版本、工具参数、工具结果、审批、延迟、Token 和错误。OpenTelemetry 正在用 Trace、Metrics 和 Logs 统一生成式 AI 的观测语义，核心价值是把一次复杂 Agent 任务还原为可分析的完整轨迹。[10]

8. Human-in-the-loop：人在环不是补丁，而是架构

高风险、不可逆、影响安全、影响产能或涉及外部承诺的动作必须进入审批。审批界面要展示动作、参数、证据、风险、预期影响和回滚方案，而不是只弹出一句“是否确认”。

人的采纳、拒绝和修改也要成为训练与评测数据。NIST 的 AI 风险管理资料强调人类监督、记录与责任；Agent 工程指南也把高风险动作和失败阈值视为人工介入的典型触发条件。[7][9]

四、为什么工业 Agent 必须建立在 Ontology 上

没有 Ontology 时，Agent 看到的是数据库字段、接口参数和文档片段。MES 里叫 MCH_STA，SCADA 里叫 EQUIP_STATE，维修系统里叫 AssetStatus，但现场人员说的是“设备状态”。如果每个 Agent 和每个工具都使用不同语言，系统越做越复杂。

Ontology 的作用，是把工厂抽象为稳定的业务对象、关系和动作：Machine 是设备对象，WorkOrder 是工单对象，Batch 是批次对象；produced_on 表示批次在哪台设备生产；createMaintenanceTicket 是经过授权的业务动作。

图 4：Ontology 驱动的 Agent 工具层

Palantir 的架构文档强调，Ontology 表达的是企业相互关联的决策，而不只是数据；其产品页面进一步把 Ontology 描述为面向人和 Agent 的“工具工厂”，工具可以查询数据、调用模型或逻辑、执行受安全治理的动作。[5][6]

对工业 Agent 来说，Ontology 带来四个直接收益：

1. 统一语言：Agent、应用、模型和人都围绕同一套业务对象交流。

2. 统一权限：权限可以绑定对象、属性和 Action，而不是散落在每个接口里。

3. 统一审计：系统可以记录“谁对哪台 Machine 执行了什么 Action”，而不是只有一条模糊 API 日志。

4. 统一复用：新 Agent 不必重新理解几十张表，只需使用已经治理过的对象与动作。

Ontology 不是大而全知识图谱｜先围绕首个场景建最小对象集：设备、产线、批次、工单、缺陷和班次。对象必须有 Owner、唯一 ID、数据来源、刷新频率、权限与版本。随着场景扩展再逐步增加。

五、五类 Industrial Agent：把现场角色映射成软件职责

多 Agent 的价值不是让多个模型互相讨论，而是把现场原本存在的职责边界映射为软件实体。每个 Agent 只拥有必要的上下文、工具和权限，由 Supervisor 负责路由、冲突仲裁与结果汇总。生产环境通常优先采用中心化 Supervisor 模式，因为它更容易控制状态、权限、成本和失败回退。[7]

图 5：五类 Industrial Agent 围绕“3 号线为什么变慢”协同

Operator Agent：现场操作员的第二双眼

读取设备状态、OEE、告警、换型和当前工单，回答“现在发生了什么”。默认只读，只提供建议和关联 SOP，不直接下发设备动作。

Maintenance Agent：维修班的作战参谋

关联时序异常、维修历史、图纸、备件和故障手册，形成根因候选与工单草稿。它可以创建草稿，但提交 CMMS 必须人工确认。

Planner Agent：把干扰事件映射到计划影响

查询订单优先级、产能、物料与换型约束，评估设备降速对交付的影响，生成重排建议。任何改变正式排产的动作都要进入审批。

Quality Agent：把质量变化与过程证据连起来

查询批次不良率、缺陷分布、视觉模型输出、物料和工艺参数，生成候选根因与 8D 报告初稿。它依赖 Ontology 把 Batch、Machine、Material 和 Defect 连接起来。

Supervisor Agent：系统的安全阀门

识别问题、选择 Agent、控制并发、合并证据、处理冲突、检查权限，并判断是否进入人工审批。Supervisor 不应该拥有所有底层权限，它只负责编排，真正动作仍由受控工具执行。

贯穿案例：“3 号线为什么变慢？”

1. Supervisor 把“变慢”解释为产能/OEE 异常，确认时间范围和对比基线。

2. Operator Agent 查询速度、微停、告警与换型，发现 02:10 后频繁短停。

3. Maintenance Agent 检索同设备维修记录，发现上周更换的传感器在高温班次曾出现抖动。

4. Planner Agent 检查订单与排产，确认昨晚插入了小批量多规格订单，换型次数增加。

5. Quality Agent 查询不良率，发现为了控制尺寸偏差，操作员主动降低了速度。

6. Supervisor 汇总：降速不是单一故障，而是“换型增加 + 传感器抖动 + 质量保护动作”的叠加。

7. 系统建议检查传感器安装、复核质量阈值，并评估将两张小单合并排产。创建维修工单和修改排产均进入人工审批。

多 Agent 的真实成本｜每拆出一个 Agent，就增加一套 Prompt、工具权限、状态、评测、Trace 和错误处理。没有明确的专业边界、并行价值或上下文隔离需求时，优先使用单 Agent + 多工具。

六、MCP 在工业系统中的位置

传统方式下，N 个 Agent 接入 M 个工厂系统，容易形成 N × M 套定制接口。每个 Agent 都要重新理解接口、参数、返回结构和认证方式，维护成本迅速上升。

MCP 采用 Host—Client—Server 架构：Host 是承载 LLM、用户界面和编排逻辑的 Agent 应用；Host 内部为每个 Server 建立 Client；Server 对外暴露 Tools、Resources 和 Prompts。官方文档将其定义为连接 AI 应用与外部系统的开放标准。[3]

图 6：MCP 把 N×M 定制接口收敛为 Host—Client—Server 标准连接

在工厂里，可以把 MES、CMMS、ERP、QMS、时序数据库和文档系统分别封装成 MCP Server：

Tools：查询设备状态、创建工单草稿、运行仿真、查询库存。

Resources：SOP、设备档案、Schema、指标定义、维修记录。

Prompts：标准排障模板、8D 分析模板、交接班检查流程。

MCP 解决的是“怎样发现和调用能力”，不自动解决“谁有权限、动作是否安全、结果是否可信”。官方安全最佳实践专门讨论授权、攻击面和实现责任。[4] 工业落地仍需在 Server 和业务网关层实现身份认证、最小权限、网络隔离、参数校验、审计、审批和回滚。

一个关键原则｜MCP Server 不应直接暴露低层、危险、无边界的通用能力。例如不要给模型一个“执行任意 SQL”或“写任意 PLC 地址”的工具；应该暴露语义明确、范围受限、可审计的业务动作。

七、ChatBI / RAG / Agent 参考架构

ChatBI 是观察工业 Agent 架构的好窗口。用户用自然语言提问，系统需要完成意图判断、Schema 检索、计划生成、SQL 或工具执行、结果校验、答案生成和引用。把数据源换成 MES、SCADA、CMMS 和知识库，这条链就是工业问答与决策支持的通用蓝图。

图 7：ChatBI / RAG / Agent 从问题到答案的端到端执行链路

完整链路可以拆成八步：

1. 用户提出自然语言问题，系统补齐时间范围、产线、指标或设备等必要条件。

2. Router 判断这是知识问答、数据分析、模型推理还是业务动作。

3. 检索 Schema、字段字典、指标口径、表关系、业务规则、Few-shot 和相关文档。

4. 生成结构化执行计划，明确每一步使用的数据、工具、预期输出和失败处理。

5. 在沙箱或受控服务中执行只读 SQL、模型推理或 MCP 工具。

6. 校验结果：权限、时间范围、单位、口径、空值、异常值和数据新鲜度。

7. 生成答案，必须给出数字、原因、建议、限制和引用。

8. 高风险动作进入审批；用户反馈与执行结果回流到评测集。

一个生产化执行计划，不应该只是自然语言段落，而应是可校验的结构：

{  "intent": "ROOT_CAUSE_ANALYSIS",  "scope": {"line_id": "LINE_03", "from": "2026-07-29T20:00:00+08:00", "to": "2026-07-30T08:00:00+08:00"},  "steps": [    {"tool": "query_oee", "mode": "READ_ONLY"},    {"tool": "query_alarm_events", "mode": "READ_ONLY"},    {"tool": "search_maintenance_records", "mode": "READ_ONLY"},    {"tool": "query_quality_trend", "mode": "READ_ONLY"}  ],  "validation": ["time_range", "metric_definition", "permission", "data_freshness"],  "final_output": {"format": "evidence_based_report", "citations_required": true}}

这类结构化计划让系统在执行前做权限与风险检查，也方便在失败后定位是 Router、检索、SQL、工具还是数据本身出了问题。

八、四个真正决定项目成败的技术点

很多团队花大量时间换模型，却忽略 Schema、Prompt、Eval 和安全。工业项目最终买单的是“能被信任的答案和动作”，而不是模型排行榜。

1. Schema：让模型看懂业务，而不是只看 DDL

原始 DDL 只能告诉模型字段类型，无法告诉它“合格率”和“直通率”是否同义、“停机时间”是否排除计划保养、“产量”按班次还是自然日统计。Schema 层需要包含字段字典、指标定义、单位、时间口径、主外键、业务别名、数据新鲜度和权限标签。

推荐先做 Schema Linking：根据用户问题检索相关表、字段和指标，再把小范围上下文交给 SQL 生成。Few-shot 也不是堆几十条示例，而是按业务意图检索最接近的“问题 → SQL → 校验规则”。

2. Prompt：结构化，而不是追求一句神奇咒语

系统提示要写清角色、数据范围、方言、禁止事项、工具规则、引用规则和失败处理；用户上下文包含问题、检索到的 Schema、业务规则和权限。输出应使用 JSON Schema 或工具调用，而不是任由模型自由发挥。

推荐采用“一次计划、一次校验、一次执行”的节奏：模型先输出问题理解与计划，程序校验后再执行；执行结果返回模型做解释，但数字和单位要经过程序验证。

3. Eval：真实 Gold Set 是项目的地基

Gold Set 应来自真实用户问题和历史故障，不要只让模型生成“看起来合理”的测试题。每条样本需要标注意图、标准查询、标准答案、允许误差、应引用来源、允许工具和风险级别。

指标要分层：Router 准确率、Schema 召回率、SQL 语法合法率、执行成功率、结果正确率、工具成功率、引用准确率、拒答准确率、高风险拦截率。执行成功不代表答案正确，答案正确也不代表引用和权限正确。

4. 安全：默认只读，逐级开放

Agent 访问数据库时应默认只读，使用表和工具白名单，实施行列级权限与敏感字段脱敏。SQL 执行前进行 AST 解析和危险模式检测；写操作必须通过语义化工具，而不是开放任意 DML。

OWASP 将“过度代理能力”视为关键风险：过多功能、过大权限和过高自主性会让错误或被操纵的模型产生真实破坏。[11] 因此要限制工具能力、权限范围和自主执行级别，并使用审批、沙箱和审计形成纵深防御。

九、工业 Agent 的能力边界

工业 Agent 的核心价值是辅助理解、检索证据、生成建议和编排受控流程。能力边界越清楚，系统越容易被现场接受。

以下事情不应直接交给 LLM：

直接控制安全仪表系统 SIS、急停回路、安全 PLC 或联锁逻辑。

未经过审批修改关键工艺参数、质量阈值、设备速度和能源调度约束。

自动执行不可逆动作，例如删除生产数据、释放不合格批次、关闭安全告警。

绕过操作员、维修负责人和现有 SOP，以“模型判断”代替责任流程。

用自然语言解释代替确定性校验，例如让模型自行计算财务结算、质量放行或安全阈值。

更稳妥的落地方式，是按风险逐级开放：先做只读检索，再做分析建议，再做草稿和可逆动作，关键参数只在双人审批与受控窗口中执行，安全联锁永久留在确定性系统里。

最终边界｜LLM 可以提出“建议检查 3 号线传感器并复核质量阈值”，但不能直接改 PLC 地址、绕过联锁或释放批次。它可以帮助人更快地做决定，不能替人承担安全责任。

结语：把 LLM 放在正确的位置

工业 AI 的下一阶段，不是用一个大模型替换所有专用模型和业务系统，而是让 LLM 成为整套系统的语义与协同接口。底层继续由 PLC、SCADA、MES、ERP、专用模型和规则保证确定性；上层通过 Ontology 统一业务对象，通过 RAG 获取证据，通过 Tool Calling 连接能力，通过 Workflow 和 Multi-Agent 分工，通过 Eval 与 Observability 持续验证，再用 Human-in-the-loop 守住责任边界。

当这条链真正跑通，用户问“3 号线为什么变慢”时，系统不再只给一句泛泛解释，而是能够找到数据、关联工单、检查排产、对比质量、给出带引用的原因与建议，并把需要执行的动作送到正确的人手里。

这才是 LLM Agent 进入生产现场的正确姿势：不抢控制权，不绕过系统，不迷信模型；把复杂信息翻译成可理解的证据，把跨系统协作变成可审计的流程，把每一个高风险动作留给确定性规则和责任人。