当工业 AI 遇上 LLM Agent：RAG、MCP 与多 Agent 如何进入生产现场

LLM 应该加在工业系统的哪一层工业系统最怕的不是模型不够聪明而是把不确定性放错位置。PLC、SIS、SCADA、MES 和专用算法承担的是确定性控制、实时响应与稳定运行LLM 更适合进入它们之上的语义、认知与协同层理解人的问题检索现场知识调用受控工具编排跨系统流程并在高风险动作前停下来等待审批。核心结论传统工业 AI 不会被 LLM 替换。真正可落地的架构是保留底层专用模型和业务系统再向上叠加 Ontology、RAG、Tool Calling、Workflow、Eval、Observability 与 Human-in-the-loop形成“数据 → 语义 → 认知 → 行动”的闭环。一、先选场景再选模型工业 AI 项目经常从一句“我们也上个大模型”开始但真正能产生 ROI 的项目往往从一个非常具体的业务动词开始识别缺陷、预测故障、推荐参数、优化负荷、重排订单。模型只是实现手段场景决定数据、部署位置、容错方式和成功指标。图 1五类典型工业 AI 场景必须同时看目标、数据、算法、部署、KPI 与失败原因智能质检最容易看见效果也最容易被现场环境击穿智能质检的业务目标通常是降低漏检、降低误判、减少人工复核数据来自工业相机、线扫相机、光源控制器、产品批次、设备参数和人工判定记录。传统算法以目标检测、图像分类、分割与无监督异常检测为主常见模型包括 YOLO、DETR、ViT、PatchCore、PaDiM。部署位置通常在产线边缘侧工业 PC、Jetson 或带 GPU 的边缘节点负责低延迟推理PLC 根据确定性信号完成剔除。LLM 不应该进入毫秒级剔除回路它更适合解释缺陷趋势、检索检验规范、汇总批次差异、生成复核建议。核心 KPI不要只看离线 mAP。生产侧更关心相对人工基线的漏检率、误判率、复检工时、报废成本以及换光源、换产品、换班次之后是否仍然稳定。常见失败并不是模型训练失败而是现场光照变化、镜头污染、产品外观漂移、正负样本比例极端、缺陷定义在不同质检员之间不一致。视觉模型需要持续监控LLM 只能帮助解释和协作不能替代确定性判定与质量规则。预测性维护不是“预测会坏”而是“提前多久、谁来处理”预测性维护的数据来自振动、温度、电流、声学、润滑、报警、维修工单和备件记录。传统算法包括时序异常检测、故障分类和剩余寿命 RUL 预测。真正有价值的结果不是模型给出一个异常分数而是能回答哪台设备、哪个部件、在多长时间窗口内、以什么风险等级需要检查。部署通常跨越边缘与平台边缘侧完成信号处理和快速异常判断平台侧做跨周期分析、工单关联和资产健康管理。LLM Agent 可以检索维修手册、读取历史工单、解释波形摘要、生成工单初稿但最后的停机决定和维修优先级仍应由维护人员确认。Siemens 的工业 AI 与 Industrial Copilot 资料也把生成式 AI 放在维修周期的辅助、解释和协同位置而不是直接替代安全控制。[8]核心 KPI 包括非计划停机小时数、告警提前量、误报率、故障捕获率和维修资源利用率。这个场景最怕误报如果系统连续几次“狼来了”操作员会直接关闭告警。工艺优化最有价值也最需要克制工艺优化希望提高良率、降低能耗、稳定 Cpk并减少对少数老师傅经验的依赖。数据来自设定参数、过程曲线、环境、原料批次、设备状态和最终质量。传统方法包括响应面、贝叶斯优化、高斯过程、模型预测控制 MPC 和数字孪生。工业现场通常接受“推荐 → 仿真或规则校验 → 人工确认 → 下发”很少接受“LLM 自主调参”。因为工艺参数之间存在强耦合数据中有大量混淆变量且错误动作可能造成整批报废、设备损伤甚至安全风险。LLM 的合理位置是解释模型建议、引用工艺依据、组织试验计划和审批材料。能效优化不能只省电还要保证产量能效优化覆盖电、气、蒸汽、压缩空气与冷却系统数据来自智能电表、EMS、生产计划、设备负荷和峰谷电价。传统算法通常是负荷预测、混合整数规划 MILP、优化调度或强化学习。部署需要与 EMS 和排产系统联动但动作必须尊重生产约束。核心 KPI 是单位产量能耗、需量电费、峰值负荷和碳排强度。常见失败是只优化能源曲线却忽略插单、换型和产能目标。Agent 适合协调“生产计划—能源价格—设备能力”之间的信息不适合绕过能源管理规则直接控制关键设备。供应链协同算法问题经常被数据主权问题盖住供应链协同涉及需求预测、库存优化、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。每一块都不是新名词但工业项目的难点在于这些组件必须围绕权限、实时性、追溯、回滚和责任边界重新设计。图 3LLM Agent 进入生产所需的八块工程拼图RAG不是把文档塞进向量库RAG 把模型的参数化知识与外部可更新知识结合起来原始论文强调了外部非参数记忆对知识更新与来源追溯的价值。[2] 在工业场景里知识源不仅是 PDF还包括 SOP、故障手册、图纸属性、维修记录、质量规范、工艺变更单和设备档案。工程上至少要解决四件事按章节、设备、故障码和版本切片关键词与向量混合检索对候选结果重排答案必须带来源、文档版本和有效期。一个检索到旧版 SOP 的“正确回答”在现场可能比拒答更危险。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 }}Workflow先显式流程再谨慎增加自主性工业任务往往有明确 SOP。最稳的做法是用确定性 DAG 或状态机管理关键步骤只把“意图理解、证据归纳、计划候选”交给 LLM。这样每一步都能回放、暂停、重试和审计。例如“分析产线变慢”可以固定为确认时间范围 → 查询 OEE 与停机 → 检查设备告警 → 检查换型与订单 → 检查不良率 → 汇总证据。LLM 可以决定哪些分支需要深入但不能跳过权限检查和结果校验。Memory记忆不是无限保存聊天记录短期记忆用于当前任务上下文长期记忆可以保存设备档案、班次状态、用户偏好和历史决策。但工业记忆必须有写入条件、有效期、版本、权限和遗忘策略。尤其要避免把模型推断当成事实写入长期记忆。更稳的做法是区分“已确认事实、系统状态、人工结论、模型假设”只有经过验证的内容才能成为下一次任务的可信上下文。Reasoning推理越长不代表越可靠Agent 可以采用 ReAct、Plan-then-Execute 等模式拆解任务但生产系统必须设置最大步数、最大工具调用次数、最大执行时间和失败回退。长链路会放大延迟、成本和错误累积。不要要求模型输出内部思考过程。工程上更有价值的是结构化计划、每一步使用的证据、工具结果和最终判断让系统可以复现和审计。Eval没有 Gold Set就没有工程工业 Eval 不能只测“回答像不像”。需要建立真实业务问句、标准 SQL、标准答案、允许误差范围、工具调用路径和拒答条件。评测指标至少覆盖答案正确率、执行成功率、工具调用成功率、引用准确率、越权率和高风险动作拦截率。线上失败样本要回流到 Gold Set。每次更换模型、Prompt、Schema、索引或工具版本都必须跑回归测试。OpenAI 的 Agent 工程指南同样强调先从简单架构开始通过真实失败和评测逐步增加复杂度。[7]Observability必须看见一条任务如何走完可观测不只是记录最终答案还要记录 Router 决策、检索 query、命中文档、重排分数、Prompt 版本、模型版本、工具参数、工具结果、审批、延迟、Token 和错误。OpenTelemetry 正在用 Trace、Metrics 和 Logs 统一生成式 AI 的观测语义核心价值是把一次复杂 Agent 任务还原为可分析的完整轨迹。[10]Human-in-the-loop人在环不是补丁而是架构高风险、不可逆、影响安全、影响产能或涉及外部承诺的动作必须进入审批。审批界面要展示动作、参数、证据、风险、预期影响和回滚方案而不是只弹出一句“是否确认”。人的采纳、拒绝和修改也要成为训练与评测数据。NIST 的 AI 风险管理资料强调人类监督、记录与责任Agent 工程指南也把高风险动作和失败阈值视为人工介入的典型触发条件。[7][9]四、为什么工业 Agent 必须建立在 Ontology 上没有 Ontology 时Agent 看到的是数据库字段、接口参数和文档片段。MES 里叫 MCH_STASCADA 里叫 EQUIP_STATE维修系统里叫 AssetStatus但现场人员说的是“设备状态”。如果每个 Agent 和每个工具都使用不同语言系统越做越复杂。Ontology 的作用是把工厂抽象为稳定的业务对象、关系和动作Machine 是设备对象WorkOrder 是工单对象Batch 是批次对象produced_on 表示批次在哪台设备生产createMaintenanceTicket 是经过授权的业务动作。图 4Ontology 驱动的 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 建立 ClientServer 对外暴露 Tools、Resources 和 Prompts。官方文档将其定义为连接 AI 应用与外部系统的开放标准。[3]图 6MCP 把 N×M 定制接口收敛为 Host—Client—Server 标准连接在工厂里可以把 MES、CMMS、ERP、QMS、时序数据库和文档系统分别封装成 MCP ServerTools查询设备状态、创建工单草稿、运行仿真、查询库存。ResourcesSOP、设备档案、Schema、指标定义、维修记录。Prompts标准排障模板、8D 分析模板、交接班检查流程。MCP 解决的是“怎样发现和调用能力”不自动解决“谁有权限、动作是否安全、结果是否可信”。官方安全最佳实践专门讨论授权、攻击面和实现责任。[4] 工业落地仍需在 Server 和业务网关层实现身份认证、最小权限、网络隔离、参数校验、审计、审批和回滚。一个关键原则MCP Server 不应直接暴露低层、危险、无边界的通用能力。例如不要给模型一个“执行任意 SQL”或“写任意 PLC 地址”的工具应该暴露语义明确、范围受限、可审计的业务动作。七、ChatBI / RAG / Agent 参考架构ChatBI 是观察工业 Agent 架构的好窗口。用户用自然语言提问系统需要完成意图判断、Schema 检索、计划生成、SQL 或工具执行、结果校验、答案生成和引用。把数据源换成 MES、SCADA、CMMS 和知识库这条链就是工业问答与决策支持的通用蓝图。图 7ChatBI / 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:0008:00”, “to”: “2026-07-30T08:00:0008: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 和安全。工业项目最终买单的是“能被信任的答案和动作”而不是模型排行榜。Schema让模型看懂业务而不是只看 DDL原始 DDL 只能告诉模型字段类型无法告诉它“合格率”和“直通率”是否同义、“停机时间”是否排除计划保养、“产量”按班次还是自然日统计。Schema 层需要包含字段字典、指标定义、单位、时间口径、主外键、业务别名、数据新鲜度和权限标签。推荐先做 Schema Linking根据用户问题检索相关表、字段和指标再把小范围上下文交给 SQL 生成。Few-shot 也不是堆几十条示例而是按业务意图检索最接近的“问题 → SQL → 校验规则”。Prompt结构化而不是追求一句神奇咒语系统提示要写清角色、数据范围、方言、禁止事项、工具规则、引用规则和失败处理用户上下文包含问题、检索到的 Schema、业务规则和权限。输出应使用 JSON Schema 或工具调用而不是任由模型自由发挥。推荐采用“一次计划、一次校验、一次执行”的节奏模型先输出问题理解与计划程序校验后再执行执行结果返回模型做解释但数字和单位要经过程序验证。Eval真实 Gold Set 是项目的地基Gold Set 应来自真实用户问题和历史故障不要只让模型生成“看起来合理”的测试题。每条样本需要标注意图、标准查询、标准答案、允许误差、应引用来源、允许工具和风险级别。指标要分层Router 准确率、Schema 召回率、SQL 语法合法率、执行成功率、结果正确率、工具成功率、引用准确率、拒答准确率、高风险拦截率。执行成功不代表答案正确答案正确也不代表引用和权限正确。安全默认只读逐级开放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 进入生产现场的正确姿势不抢控制权不绕过系统不迷信模型把复杂信息翻译成可理解的证据把跨系统协作变成可审计的流程把每一个高风险动作留给确定性规则和责任人。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】