生产异常闭环 Agent就是把“发现异常、分析原因、推动整改、确认关闭”这一整条链路交给智能体去跑而不是靠班组长翻报警记录、打电话催人、再手工补一份整改报告。格创东智推出的生产异常闭环 Agent核心定位就是把 Agent 推进制造现场让生产问题从人工跟踪变成智能闭环。这类方案现在讨论度很高但不少人把它理解成“一个更智能的报警机器人”这个理解并不完整。它真正要解决的是异常从发现到关闭之间那些断掉的环节。下面按实际落地顺序拆一遍它改变了什么、四个核心动作、上线前要准备什么、最小闭环怎么跑、用哪些指标判断效果好以及闭环卡住时先查哪里。1. 生产异常闭环 Agent 到底改变了什么从“人追着问题跑”到“系统推着问题走”1.1 传统异常处理为什么总是断在中间制造现场的异常处理表面上不缺流程。设备报警了MES 里会有一条异常记录班组长在群里发消息工艺去看参数设备科去查机台质量去判定批次。问题在于流程只存在于人的脑子里每个环节都可能断。最常见的断点有三个。第一个是识别靠人报警信息散在各系统里白天靠交接班晚上靠值班人员盯屏漏掉一条异常很常见。第二个是分析靠人猜异常发生后往往只有报警代码和几个实时值要查历史趋势、查同机台过往记录、查工艺标准得一个人一个人去问。第三个是整改靠人催异常原因写完了整改措施却可能停在某个人的待办里超时了也没人知道。这不是某一个系统不好用的问题。设备数据在 IoT 平台生产工单在 MES质量判定在 QMS维修记录在 EAM各系统都有自己的数据但没有人把这些串成一条闭环链。生产异常闭环 Agent 要补的正是这条链。1.2 它与传统报警系统存在本质差异传统报警系统的能力边界是“通知”触发条件满足系统生成报警推送给人然后处理流程靠人工。Agent 闭环的差异在于异常出现后它还会继续往下走。我用一个比较直接的说法这个 Agent 像一个数字班组长。它不只告诉你“设备报警了”还会去查这台设备的档案、最近的工艺参数、同类异常的历史处置记录然后把可能原因和证据链整理出来通知给对应责任人创建整改任务超时自动催办升级最后根据复测结果判断能不能关闭。这个能力背后就是 Agent 区别于普通规则引擎的几个要素它会调用外部系统工具去查询数据和创建工单它有记忆可以去检索历史案例它在分析时会结合上下文做推理。也就是说它比传统报警系统多了“归因、行动、跟踪”三层能力。复杂场景下甚至需要采用多 Agent 设计主 Agent 负责协调子 Agent 分别承担查询、分析和建单本质上就是把不同能力封装成可调用的工具。当然这里要澄清一个边界它不是替工程师拍板。根因判断、工艺调整、设备维护这些专业决策仍然需要人工确认Agent 做的是把信息准备齐、把路径跑到位、把节点盯到底。2. 先拆闭环 Agent 的四个核心动作识别、归因、整改、验证2.1 识别异常所有报警不等于真实异常闭环的第一步是识别。这里最容易踩的坑是把所有报警都当成异常推给 Agent 分析。真实产线里误报比漏报更消耗现场人员的信任。识别来源一般有三类设备采集数据触发比如温度超限、压力波动、振动异常MES 生产过程数据触发比如节拍异常、批次追溯信息不完整、报工比例偏离质量系统数据触发比如某检测项连续不合格。单个来源触发的信号可以叫报警多个来源在同一时间窗口内同时出现才更值得作为异常事件进入闭环。这也是为什么闭环 Agent 不适合只靠单一阈值规则。同一台设备生产不同产品时参数区间完全不同同一个温度值在夏季和冬季、在开机和稳态工况下的含义也不一样。所以落地时常见做法是“规则初筛 模型判断 上下文确认”先用规则把明显异常筛出来再让 Agent 关联其他系统数据确认最后进入归因环节。2.2 分析原因知识库、历史案例和上下文是关键归因是整个闭环里最像“智能”的一步但它不是靠大模型凭空推理出来的。比较务实的做法是把归因拆成两条线并行。一条是结构化查询Agent 利用工具去查询设备台账、工艺参数、最近维保记录、同类机台对比数据这里面会用到数据库查询、API 调用等通道。另一条是非结构化检索从历史异常案例库、SOP、设备手册中检索相似问题把当时的处理方案找出来。两条线汇合后Agent 再输出一个带证据链的根因分析建议。这里要强调知识库的重要性。没有历史案例支撑的 Agent分析结果会非常泛比如“建议检查设备状态”这种正确但没有用的结论。更好的输出应该类似“最近 3 小时内该机台主轴温度连续超过 85 度频率曲线出现周期性波动过去两次相同模式分别在 5 月和 8 月出现原因是主轴润滑不足处理后需关注润滑压力是否稳定。”这种输出才有决策价值。Agent 记忆在这里的作用也值得单独说。生产异常通常不是一次性事件同一设备的同一个异常模式可能在多个班次反复出现。如果 Agent 能记住上一次的处置方案和验证结果下一次就能更快给出建议这就是闭环之后反哺知识库的价值。2.3 推动整改工单、责任人和升级机制要提前接好很多系统走到“分析出原因”就停了但闭环的真正难点在后面谁来改、什么时候改完、没改完怎么办。推动整改这一步Agent 需要做几件事根据异常类型和预先配置的责任矩阵找到对应的责任人和审批人在工单系统里创建整改任务写明异常现象、分析结论、建议措施和期望完成时间通过企业微信、钉钉或短信通知责任人超时未完成时自动催办再超时则按升级路径推给更高一级管理者。为什么必须把升级机制提前配好因为生产现场最常见的闭环失败原因不是没人知道异常而是异常停留在某个人的待办里没人跟进。人工跟进靠自觉Agent 跟进靠配置。配置到位后每一个未关闭的工单都会按时间被推送出来。2.4 验证关闭闭环不能由 Agent 自己说了算整改完成后异常是否能关闭要有验证逻辑不能 Agent 说“已处理”就结束。一般验证包含三个条件同时满足在规定观察期内异常没有再次触发相关设备或质量参数恢复到目标区间责任人对整改措施进行确认。三项都满足闭环才正式关闭。关闭后这个案例会归档成一条新的知识包含异常现象、根因、措施、验证结果下一次同类问题可以直接复用。这样一来闭环就不只是处理完一个异常而是在不断积累处理经验。越跑越准是闭环 Agent 相比一次性项目最值得长期关注的地方。3. 落地前先盘清环境数据、流程、权限、知识库缺一不可3.1 数据接入决定闭环价值的上限生产异常闭环 Agent 能处理什么取决于接入了什么数据。如果只接了一个 IoT 平台的报警数据它就只能做设备报警闭环如果同时接了 MES、QMS、EAM它才能做跨系统的综合分析。我建议先做一次数据盘点设备数据能不能读到实时值MES 里有没有异常工单和派工记录质量系统能不能查到批次检测结果维修系统有没有历史维保计划。每个系统的数据有没有 API 或数据库只读账号数据保留多长时间字段是否齐全这些都要在试点前确认。数据质量比数据量更重要。很多现场的设备数据有缺失比如某个传感器经常断点某个机台的工艺参数没有归档。如果源头数据断断续续Agent 后续关联分析就会出现误判。所以试点前常见动作是抽一段历史数据做完整性检查。3.2 责任矩阵和权限边界要提前定义Agent 不是一个人但它在系统中扮演的是“跨部门协调者”。它需要知道异常该推给谁、谁有权利确认、超时升级到哪个层级。责任矩阵通常按设备和异常类型两个维度维护设备 1 的某类报警默认推给工艺工程师 A设备 2 的同类报警默认推给设备工程师 B。这个矩阵在建的时候可能很繁琐但它决定了整改环节能不能跑通。矩阵不完整Agent 就会在“找不到责任人”这一步停下闭环立刻断掉。权限边界同样重要。Agent 能查哪些数据、能创建哪些工单、能不能直接改参数、需不需要审批后执行都属于 Agent 安全的范畴。稳妥原则是只读查询尽量放开写操作必须走审批和审计任何影响生产参数的操作都要留日志。Agent 负责发起和跟踪最终确认和控制权仍然在人手上。3.3 知识库和历史案例可以从小规模起步知识库是归因质量的地基但不需要一开始就追求大而全。几十个有代表性的历史案例只要覆盖了试点场景的主要异常模式就可以先跑起来。历史案例整理可以按照固定模板异常现象描述、发生设备或工序、触发的数据特征、根因分类、处理措施、验证结果。重点不是格式花哨而是工程师能看懂、Agent 能检索。如果企业有过去一年的异常处理记录哪怕是 Excel 汇总也可以整理成最初的知识库。知识库建成后不是一成不变。每个闭环关闭的案例都会追加进去时间越长Agent 对现场模式的理解越接近真实。4. 试点阶段怎么把一个最小闭环跑通4.1 选择试点场景高频、可采集、责任清晰第一次上生产异常闭环 Agent不要贪多。我建议选一类高频但原因相对集中的异常作为试点比如某条产线设备温度报警或者某个质量检测项连续不合格。选择标准可以按三条来判断异常发生频率高这样短期内就能验证闭环效果异常相关数据能自动化采集不需要人工录入手工单据异常处理责任清晰涉及部门和人员边界明确。满足这三条的场景试错成本最低闭环最容易跑通。4.2 配置识别规则和触发条件试点阶段的识别规则不需要复杂。可以先写最直接的阈值规则比如温度超过某个区间、压力波动超过设定范围、连续 N 个批次不合格。规则配置成类似下面的结构anomaly_rule: name: 主轴温度超限 source: iot_equipment device_group: 精加工车间主轴设备 condition: metric: spindle_temperature operator: threshold: 85 duration_seconds: 300 deduplication_window: 30 severity: high这里的 duration_seconds 表示持续多长时间才触发deduplication_window 表示多长时间内不重复触发。这两个参数很关键时长太短会误报太多太长又会漏掉快速波动。配完之后先做离线回放把历史一段时间的异常数据灌进去看规则能不能还原出当时的报警。等规则稳定了再切到实时模式。4.3 单条异常闭环试跑跑通一条再跑一批实时模式开通后先观察单条异常事件的完整闭环。从触发开始看 Agent 是否关联到了设备档案是否产出了根因分析建议是否成功创建了整改工单责任人和超时配置是否生效验证环节是否能正常关闭。这一步的重点是盯日志。每到一个环节Agent 应该留下可读的执行记录查询了什么数据、调用了什么工具、为什么给出这个原因、工单创建结果是什么。看不到日志就无法判断闭环断在哪里。4.4 从单条到批量去重、排序和并发都要重新考虑单条跑通之后不要急着把所有异常都接入。先做批量模拟一次喂入多条异常看 Agent 是否会重复分析同一事件、是否会按照优先级处理、并发请求会不会拖垮接口。批量场景最容易暴露问题的是接口超时和任务排队。Agent 同时发起多个查询或工单创建请求时下游系统不一定扛得住。稳妥做法是先设一个比较低的并发数比如同时处理 3 到 5 条异常后续根据接口响应时间慢慢调。此时也需要配置失败重试机制某一次工单创建失败不能导致整个任务丢失应该重试或进入人工介入队列。5. 核心指标和判断标准别只盯着“能不能跑起来”5.1 闭环效果看六个核心指标评估生产异常闭环 Agent不能只看演示效果要用指标来衡量。指标含义参考判断异常识别准确率正确识别的异常事件占全部识别事件的比重初期先看是否明显优于人工报警记录误报率实际不构成异常的报警占比过高会消耗现场信任需要调整阈值和确认逻辑根因分析采纳率工程师采纳 Agent 建议作为处理依据的比例低于 50% 时先补知识库和上下文平均闭环时长从异常触发到关闭的耗时对比试点前人工闭环时长重点看下降幅度按时闭环率在规定时限内关闭的异常占比建议设置 80% 以上的目标未及时关闭的要升级异常复发率同类异常在关闭后一段时间内再次出现复发率过高说明整改措施没有真正治本这些指标要按周或按月看趋势。单次跑通不代表有效连续一段时间闭环率和复发率在改善才说明 Agent 真正进入了工作状态。5.2 响应时间和资源占用低配环境先降并发很多工厂的服务器资源并不宽裕Agent 的归因分析如果依赖大模型推理响应时间和计算成本都要实测。通常需要关注单次完整分析耗时、批量并发下的吞吐量以及推理服务的内存和显存占用。低配环境下我的建议是先把并发数降下来同时控制输入上下文的长度。Agent 检索到的历史案例不需要全部塞进提示词可以只保留相似度最高的几条。另外可以把耗时的根因分析做成异步任务避免前端等待过长时间也避免资源峰值叠加。5.3 根因分析质量怎么验证根因分析的质量不能只看“说的话像不像专家”。更靠谱的验证方式是用历史已确认的异常做回测把当时的数据和现象喂给 Agent看它给出的根因和处理建议是否与人工结论接近。另一个验证点是证据链完整性。一份好的分析结果应该包含数据依据、关联记录和建议措施。如果分析结果只有结论没有证据工程师基本不会采纳。所以上线初期我会建议让有经验的工艺或设备工程师每周抽几条 Agent 的归档案例打一次分同时反馈哪些证据缺失、哪些建议不执行。这些反馈就是优化知识库的直接依据。6. 闭环卡住时按这个顺序排查6.1 识别不到异常先查数据源再查规则异常没有触发时不要先怀疑模型。按顺序排查数据源是否在持续推送、字段名和单位是否对得上、时间窗口是否正确、阈值是否偏离当前工况。很多时候是源数据断点或者字段解析错了。如果误报过多优先看 duration_seconds 是否太短再看 deduplication_window 是否没生效。规则确认后仍然误报就需要引入更多上下文做二次确认。6.2 根因分析不准先看知识库再看检索结果分析结果泛泛而谈、每次都给差不多的建议根因大概率是知识库太薄。先确认试点异常类型在历史案例库里有没有覆盖再确认 Agent 是否真的检索到了相关案例。可以看日志里的检索命中情况如果检索结果为空或相似度太低说明问题不在模型而在知识库。还有一种情况是上下文不全。比如 Agent 只知道当前报警值不知道最近维保记录和工艺参数变化分析自然不准。这时要补充数据源授权或调整查询逻辑。6.3 整改环节不闭环先查责任矩阵再查工单接口异常分析完了工单也创建了但迟迟没人处理优先检查责任矩阵是否完整。责任人字段为空或者推送消息没有发出去都会卡住整改环节。这里要查三方工单系统接口是否返回成功、通知渠道是否被拦截、升级任务是否在队列里等待。如果一个异常已经变成“死循环”一直在重复催办但没有人接那大概率是责任配置问题而不是 Agent 的问题。6.4 Agent 本身不稳定先看日志、队列和资源占用批量跑的时候Agent 偶尔会出现分析任务堆积或超时。这时先看日志里卡在哪个环节再看并发数是否超过下游接口承受能力最后看服务器 CPU、内存、磁盘是否有瓶颈。这类问题的通用处理顺序是降低并发、增加失败重试、把长任务改成队列异步执行。注意不要一上来就把超时时间调很大那样只会让问题堆积得更隐蔽。先让一个任务能跑完再逐步放开并发。6.5 现场踩坑后的一些建议以我观察到的落地经验来看生产异常闭环 Agent 项目成功与否很多时候不取决于模型能力而取决于基础工作数据接没接全、责任矩阵清不清晰、知识库有没有沉淀、工单接口稳不稳定。这些基础工作越扎实Agent 的表现越稳定。刚开始不用追求所有异常都智能分析。可以先让规则把明显的异常识别出来Agent 负责关联信息和建单跟踪再逐步把根因分析做深入。这种渐进路线比一次性上大而全的方案稳妥得多。真正跑顺之后你会发现受益最大的不是某一个部门而是整个现场处理问题的节奏。