生产异常闭环Agent：从异常识别到整改闭环的智能体设计

生产车间里最让人头疼的往往不是设备故障本身而是故障发生之后那一连串“人肉追踪”现场报障、群里人、电话催促、Excel记录整改进度、隔天还要追着问“到底处理完没有”。一旦异常信息散落在不同系统、不同群聊里分析和解决效率就会变得非常低。格创东智提出的生产异常闭环Agent正是为了解决这个场景而出现的。它不是简单的告警推送工具也不是传统BI报表而是利用大模型、知识图谱和自动化流程把“异常识别—原因分析—整改闭环”串成一个可以自动运转的智能体系统。本文将从技术侧拆解这套系统的核心设计思路包括异常识别规则、根因分析链路、整改流程闭环以及落地过程中的常见坑点适合制造企业的IT人员、MES相关的工程师、AI应用开发者参考。1. 从“人工跟异常”到“Agent管异常”1.1 传统生产异常处理流程的问题制造现场每天会产生大量异常设备停机、质量超标、物料短缺、工艺参数波动、环境指标异常。传统处理流程大致是这样的现场作业人员发现异常后手工填写报修单或异常记录表然后在企业微信、钉钉群或者邮件里通知相关责任人。设备工程师或工艺工程师收到消息后先翻阅MES、SCADA、ERP等系统的历史数据判断异常原因再制定临时对策和长期整改措施。整个过程依赖人的经验异常响应速度、原因分析准确度、整改闭环率都因人而异。这里有几个比较典型的痛点异常识别滞后。很多异常是等到产品报废、设备停机之后才被发现的缺少提前预判能力。原因分析依赖老师傅。同一个异常不同的人分析出来的原因可能差异很大。整改动作难以追踪。责任人在线下执行整改管理者无法实时掌握进度。经验资产流失。老师傅的分析逻辑没有沉淀到系统里换人之后一切从零开始。1.2 Agent在这里解决什么问题生产异常闭环Agent并不是要取代工程师而是把工程师从重复、低效的“信息搬运”中解放出来。它的核心能力可以概括为三个闭环第一个闭环是感知闭环。Agent通过API采集设备数据、MES工单、质量检测、环境监测等多源信号在异常刚有苗头时就能触发预警。第二个闭环是认知闭环。Agent把当前异常与知识图谱里的历史案例、SOP文档、工艺参数规则进行匹配再借助大模型的推理能力输出根因分析报告。第三个闭环是执行闭环。Agent根据分析结论自动生成整改任务并跟踪任务从“待处理”到“已关闭”的全过程。也就是说Agent做的是“发现问题—分析问题—分配任务—追踪整改”的端到端管理人只需要在关键节点审核确认。1.3 生产异常闭环Agent的技术定位从技术架构上看这类Agent通常位于MES、SCADA等工业系统之上属于一种面向业务场景的智能应用层。它既要有传统自动化脚本的流程控制能力也要有大模型的理解推理能力还要有知识图谱的结构化查询能力。更准确地说它是一个复合型AI Agent系统。现在很多关于Agent的讨论都聚焦在聊天机器人、代码辅助工具上但工业场景的Agent有一个明显差异它必须对结果负责。聊错了可以重来生产异常分析错了耽误的是产线和订单。因此工业Agent更强调可控性、可追溯性、审核机制和权限边界。2. 生产异常闭环Agent的总体架构2.1 先分清楚几个容易混淆的概念在展开架构之前先把几个概念边界讲清楚避免后续理解偏差。RPA机器人流程自动化擅长按固定规则操作软件界面比如自动登录系统、自动复制粘贴数据但本身不具备理解能力和推理能力。规则引擎如Drools根据预设的if-then规则做出判断适合条件明确的场景但面对模糊、跨系统、非结构化的异常信息时规则维护成本非常高。Agent智能体相比之下多了一个“理解和规划”的层次。它可以接收自然语言指令或非结构化信息结合知识库和工具API自己规划下一步动作并在动作过程中根据反馈动态调整。在生产异常场景里三者的关系可以这样理解RPA负责“手脚”规则引擎负责“条件反射”Agent负责“思考和指挥”。2.2 整体架构分层一个生产异常闭环Agent在逻辑上可以分成四层第一层是接入层。负责连接MES、SCADA、QMS、ERP、IoT平台等系统通过API、数据库连接、消息队列等方式采集数据和事件。第二层是感知与决策层。这是Agent的核心。它把采集到的数据转换成标准化异常事件然后通过异常判定引擎、知识图谱匹配、大模型推理形成根因分析结论。第三层是执行与协同层。Agent把分析结论转换成整改任务通过消息平台或API分发给相关责任人并持续跟踪任务状态必要时自动催办、逐级上报。第四层是知识沉淀层。每一次异常的处理过程、根因标签、解决措施都会被记录到案例库中反哺后续的分析能力。下面用一个简单的流程来概括异常处理的主链路信号采集 - 异常判定 - 事件标准化 - 根因分析 - 整改任务生成 - 责任人处理 - 结果审核 - 案例归档2.3 为什么选择Agent架构而不是传统系统制造业过去也尝试过“异常管理模块”把异常上报、审批流、统计分析做成一套软件。但这类软件最大的问题是它只解决“流程记录”不解决“分析和决策”。Agent架构带来的变化在于异常识别从“人上报”变为“系统主动发现”。根因分析从“翻文档问老师傅”变为“知识图谱大模型辅助推理”。整改跟踪从“人催人”变为“系统自动催办异常上报”。经验传承从“老员工脑子里”变为“结构化案例库”。所以Agent的生产异常闭环本质上是用AI把传统异常管理系统中“最需要人动脑”的部分补上了。3. 环境准备与基础技术选型在进入具体实现之前先把环境和技术选型说明一下。生产异常闭环Agent的落地方式有很多种既有像格创东智这类工业平台提供的产品化方案也有企业基于开源框架自行搭建的路线。本文以自行搭建的核心逻辑为例演示关键模块的设计思路。3.1 运行环境建议操作系统使用Linux如CentOS 7.x或Ubuntu 20.04比较稳妥因为后续部署Python服务、向量数据库、大模型推理服务都更顺手。如果企业内网环境已经存在Docker或Kubernetes优先以容器化方式部署。Java服务端可以跑在JDK 8或JDK 11以上版本Python服务推荐3.9以上版本。3.2 推荐技术栈模块推荐方案说明Agent框架LangChain / 自研Agent编排负责Agent的规划、工具调用、记忆管理大模型推理企业内部已部署的LLM或云端API用于根因分析和报告生成注意数据不出厂知识存储Neo4j ElasticsearchNeo4j存知识图谱ES存历史案例和文档消息中间件Kafka / RabbitMQ采集层和Agent服务间异步解耦业务流程编排Camunda / Flowable负责整改任务的状态流转和审批数据采集自研采集器 MES开放API对接SCADA、IoT平台等数据源这里需要特别强调版本需要根据你的项目实际情况调整。不同企业的工业系统接口差异很大本文示例以常见环境为例重点演示配置思路。3.3 示例项目结构为了便于理解后面章节的示例代码会采用Python为主、Java为辅的方式。目录结构大致如下production-agent/ ├── agent-core/ # Agent核心编排逻辑 ├── agent-knowledge/ # 知识图谱和案例库操作 ├── agent-plugins/ # 各类工具插件MES、SCADA、消息推送 ├── collector/ # 数据采集服务 ├── workflow/ # 整改闭环流程引擎 ├── prompts/ # 大模型提示词模板 └── config/ # 配置文件4. 异常自动识别把现场信号变成结构化事件4.1 多源信号接入生产异常闭环的第一步是把分散在多个系统中的“信号”汇聚起来。数据源通常包括SCADA系统的设备运行参数如温度、压力、转速、振动。MES系统的工单状态、报工数据、不良品记录。QMS系统的检验数据和SPC判异结果。ERP系统的物料齐套状态、在途库存。环境监测系统的温湿度、粉尘、有害气体浓度。接入方式常见有三种第一种是API轮询。调用第三方系统的开放接口按固定频率拉取数据。简单直接但对接口性能有要求而且存在延迟。第二种是消息订阅。在生产系统侧配置Webhook或消息队列监听实时接收事件数据延迟最低。第三种是数据库直连。读取业务库的表结构。这种方式有侵入性而且容易对生产库造成压力建议只读、低频、放业务低峰期执行。4.2 异常判定引擎设计异常判定可以先用规则引擎兜底再用模型识别补充。规则的优点是解释性强、容易收敛。制作规则时通常会参考设备厂商手册、工艺规范、SPC控制上下限和历史告警记录。下面是一个设备数据异常判定的Python示例# 文件路径collector/rule_engine.py # 说明核心示例代码需根据实际设备和工艺参数调整 def judge_device_anomaly(device_id: str, metric: str, value: float, threshold: dict) - dict: 根据阈值规则判定设备数据是否异常 :param device_id: 设备编号 :param metric: 指标名称如 temperature :param value: 当前指标值 :param threshold: 阈值配置如 {low: 10, high: 80, duration: 5} :return: 异常事件字典 high threshold.get(high) low threshold.get(low) is_anomaly False level normal if high is not None and value high: is_anomaly True level high if value high * 1.2 else warning if low is not None and value low: is_anomaly True level low if value low * 0.8 else warning if not is_anomaly: return {device_id: device_id, metric: metric, value: value, result: normal} return { device_id: device_id, metric: metric, value: value, result: anomaly, level: level, suggest_action: check_device }这套规则的逻辑很简单数值超过阈值上限或低于下限就判定异常超过严重程度阈值再进一步升级告警级别。但规则引擎有一个明显短板静态规则很难覆盖复杂动态场景。比如同一台设备在不同工艺阶段允许的温度波动范围是不同的。这时候就需要结合上下文信息来做判定。改进方案是引入“工况识别”模块根据当前工单类型、工艺工序和设备运行状态动态加载对应的阈值配置。4.3 异常事件标准化各系统上报的数据格式五花八门Agent在做后续分析之前必须先把它们统一成标准化事件结构。一个推荐的事件模型看起来像这样{ event_id: EVT-20250607-001243, event_type: 设备异常, event_source: SCADA, occur_time: 2025-06-07 10:23:15, device_id: DEV-ETCH-03, device_name: 蚀刻机3号, metric_data: { temperature: 92.5, pressure: 4.2, vibration: 6.8 }, alarm_level: high, status: pending, raw_message: 设备温度超限已触发停机保护 }事件标准化的好处是让后面的Agent可以统一处理不需要关心上游系统是数据库、接口还是人工上报。同时event_id作为唯一标识贯穿整个异常分析、整改闭环的生命周期。5. 根因分析从“知道异常”到“知道为什么异常”异常事件产生之后最关键的一步是分析。5.1 基于知识图谱的历史案例匹配根因分析不能完全依赖大模型“凭空推理”。生产现场的很多异常是重复发生的历史案例里已经沉淀了成熟的解决思路。因此第一步应该做知识检索。知识图谱在这里的典型建模方式是节点设备、部件、工艺参数、原料批次、异常类型、根因类型、解决方案。关系设备包含部件、部件影响参数、参数触发异常、异常对应根因、根因对应解决方案。当新的异常事件到来时系统把异常特征转换成查询条件到Neo4j中检索相似历史案例。下面是一个Cypher查询示例// 文件路径agent-knowledge/query_case.cql // 说明根据异常类型和设备查询历史根因与解决方案 MATCH (d:Device {device_id: $device_id})-[:HAS_PART]-(p:Part) MATCH (p)-[:CAUSES]-(e:AnomalyType {type: $event_type}) MATCH (e)-[:HAS_ANOMALY]-(c:Case) MATCH (c)-[:HAS_ROOT_CAUSE]-(r:RootCause) MATCH (c)-[:HAS_SOLUTION]-(s:Solution) RETURN c.case_id, r.cause_name, s.solution_desc, c.success_times ORDER BY c.success_times DESC LIMIT 5每条返回的历史案例都可以作为根因分析的候选答案。5.2 多Agent协作分析模式单一的Agent在处理跨系统、跨专业领域的异常时往往会力不从心。一个设备异常可能涉及机械、电气、工艺、物料等多个专业方向。更合理的做法是采用主从模式Supervisor SubAgent这也是当前多Agent设计里比较主流的架构。核心思想是一个主Agent负责整体规划把分析任务拆分成多个子任务分发给不同的专业Agent去执行专业Agent再把结果返回给主Agent由主Agent汇总生成最终结论。这种设计本质上和“把SubAgent当作另类的Tool进行调用”是一致的主Agent并不直接执行所有操作而是根据任务需要选择合适的工具或子Agent。下面用一个简化的事务流程来表达主Agent收到温度超限异常事件 - 调用设备数据Agent查询该设备最近2小时运行参数和报警记录 - 调用工艺知识Agent匹配工艺规范中温度超限对应的标准处置流程 - 调用历史案例Agent检索同类设备历史异常根因统计 - 汇总各Agent结果生成根因分析报告这种模式的好处很明显每个专业Agent只负责自己擅长的领域知识边界清晰模型幻觉概率也会降低。5.3 大模型提示词工程示例在生产环境中根因分析Agent的提示词设计非常关键。这里给出一个用于汇总分析的提示词模板示例# 文件路径prompts/root_cause_analysis.py # 说明核心示例代码需根据实际模型和业务场景调整 ROOT_CAUSE_ANALYSIS_PROMPT 你是一名资深制造现场异常分析专家。请根据以下信息分析本次异常的可能根因并给出排查建议。 设备信息{device_info} 异常现象{event_description} 实时参数{metric_data} 知识图谱匹配到的历史案例 {similar_cases} 专业Agent分析结果 - 设备数据分析{device_agent_output} - 工艺知识检索{process_agent_output} - 历史案例统计{case_agent_output} 要求 1. 基于以上材料输出不要编造不存在的数据。 2. 按可能性从高到低列出3个根因假设。 3. 每个根因需要说明判断依据。 4. 给出可操作的排查步骤和整改建议。 5. 如果信息不足明确列出需要补充的数据项。 这里有一个重要原则让大模型先看证据、再下结论而不是让它凭空猜测。所有根因假设都必须能够回溯到具体的设备参数、历史案例或工艺文档。5.4 分析报告的生成与人工审核Agent分析完成后输出一份结构化报告。报告内容通常包括异常概述、数据证据、候选根因、排查建议和补充信息需求。但这里必须强调生产环境的Agent分析结果只能作为辅助决策不能完全替代人工判断。推荐做法是对于高频、低风险、已有明确历史案例支撑的异常可以自动生成整改任务。对于首次出现、影响面大、证据不充分的异常必须走人工审核由经验丰富的工程师确认后再进入整改环节。这既是对生产的负责也是Agent系统避免“过度自信”的必要手段。6. 整改闭环从分析结论到执行落地6.1 整改任务生成根因分析完成后Agent要根据分析报告自动生成整改任务。任务类型通常包括设备维修、工艺参数调整、物料更换、SOP修订、人员培训等。任务生成的关键是做到“责任到人、时限到天、标准到项”。下面是一个整改任务的数据结构示例{ rectification_id: RF-20250607-001, event_id: EVT-20250607-001243, task_type: 设备维修, assignee: 设备科-张工, deadline: 2025-06-08 18:00:00, priority: 高, content: 检查蚀刻机3号加热器工作状态更换老化热电偶, source_solution_id: SOL-0102, status: pending, audit_required: true }6.2 状态流转与自动催办整改任务生成之后需要进入流程引擎进行状态管理。一个常见的状态机如下待处理 - 处理中 - 待验收 - 已关闭 \ | | \ v v - 已逾期 - 已驳回状态流转过程中Agent会持续监听每个任务的状态。如果在规定时间内没有更新系统会自动向责任人发送催办消息如果逾期时间过长还会自动上报给一线主管。状态流转建议使用Camunda、Flowable这类成熟的流程引擎而不是自己在代码里用if-else硬写状态判断。因为在线审批、驳回、追加减员、超时升级这些场景流程引擎已经做到了足够成熟直接复用能减少很多开发量和踩坑风险。下面给出一段简化的流程控制示例便于理解状态更新逻辑// 文件路径workflow/RectificationWorkflow.java // 说明核心示例代码演示状态流转的关键逻辑 public class RectificationWorkflow { public void updateStatus(String rectificationId, String fromStatus, String toStatus) { // 参数校验 if (!isValidTransition(fromStatus, toStatus)) { throw new IllegalStateException(非法的状态流转: fromStatus - toStatus); } // 更新任务状态示例省略数据库操作 System.out.println(任务 rectificationId 状态更新: fromStatus - toStatus); // 状态变化后的动作触发 if (待验收.equals(toStatus)) { // 通知质量工程师验收 notifyQualityEngineer(rectificationId); } if (已逾期.equals(fromStatus) || 已逾期.equals(toStatus)) { // 通知直属主管 notifySupervisor(rectificationId); } } private boolean isValidTransition(String from, String to) { // 这里应该根据流程引擎配置或数据库中的状态机定义进行校验 return true; } private void notifyQualityEngineer(String rectificationId) { // 调用消息平台API发送通知 } private void notifySupervisor(String rectificationId) { // 调用消息平台API发送升级通知 } }6.3 权限与安全边界整改闭环系统涉及生产指令的下发和责任人的变更权限控制必须非常严格。这里有几个原则最小权限原则。每个用户只能看到自己负责范围内的异常事件和任务。生产主管可以看全厂设备工程师只能看设备类异常工艺工程师只能看工艺类异常。操作留痕。所有审核、驳回、改派操作都要记录到审计日志中保证追责链条完整。数字签名与审批。涉及重大设备停机、工艺参数变更的任务必须经过相关负责人审批后方可下发到现场执行系统。数据不出厂。大模型如果部署在云端需要确保设备参数、工艺数据脱敏后才能发送敏感数据优先使用私有化部署模型。7. 常见问题与排查思路在生产异常闭环Agent的落地过程中团队经常会遇到下面这些问题。问题现象常见原因解决思路异常事件大量重复推送采集层没有做事件去重在事件标准化阶段增加基于event_id/设备/指标/时间的去重窗口根因分析结果不准确知识图谱中历史案例不足或大模型未绑定检索结果增加历史案例标注量改进知识检索逻辑让模型先推理再回答Agent分析超时多个子Agent串行调用导致响应时间过长将可以并行的子Agent改为并行调用设置合理的超时和熔断整改任务没有触达责任人消息通道权限未配置或责任人信息同步不及时对接企业组织架构定期同步通讯录支持多渠道消息触达状态流转卡住不更新流程引擎与业务系统状态不同步增加定时对账任务以业务系统实际状态为准进行修复大模型幻觉导致结论错误提示词缺少约束或知识输入不完整在提示词中强调“仅基于输入材料分析”并人工审核高风险任务接下来重点展开两个最常见的坑。第一个坑是“事件重复告警”。生产数据采集频率很高如果每5秒采集一次设备温度连续10次超过阈值就会生成10条告警。如果Agent把每条告警都当作独立事件处理知识图谱会被大量重复案例污染。解决方案是在采集端做“抑制窗口”同一个设备同一个指标在5-10分钟内只生成一条有效事件。第二个坑是“知识图谱与业务系统的冷启动”。项目刚上线时历史案例库里可能只有几十条数据Agent的根因分析效果会明显不足。这个阶段不要急着考核准确率而是先让系统把每个用户确认过的案例自动归档快速积累有效案例。同时可以借助大模型离线抽取历史异常工单中的根因信息辅助冷启动。8. 最佳实践与工程建议8.1 先跑通一个场景再横向复制生产异常闭环Agent的落地忌讳一开始就铺全场景。建议选择一个高频、影响大、数据基础较好的工序先试点比如“蚀刻设备温度异常”或“注塑车间尺寸超差”。在一个场景上把异常识别、知识检索、大模型推理、整改闭环全部跑通再逐步复制到其他设备和工艺环节。8.2 将人在环中的审核机制作为必备设计即使Agent的准确率已经很高也不能在生产环境中设置成“全自动改参、全自动下指令”。正确的做法是区分风险等级低风险任务Agent直接下发人工抽查确认。中风险任务Agent给出建议人工审核后下发。高风险任务Agent只输出分析报告由专家委员会决策。这种设计既保留了Agent的效率优势又规避了不可控风险。8.3 异常知识体系要和Agent一起生长很多企业做了第一版知识图谱之后就不再更新结果Agent的推理能力迅速衰退。异常知识体系是持续迭代的。每次异常处理完毕后系统应自动记录异常的表现形式、确认的根因、采取的整改措施、处置效果。这里面有几个关键设计采用半自动化知识抽取。人工抽核心信息大模型辅助补全描述避免全自动抽取时混入幻觉内容。给案例打上置信度标签。成功处理多次的方案在检索结果中排名靠前被驳回的方案自动降权。定期清理过期知识。设备改造、工艺更新之后老知识点要及时失效避免误导Agent。8.4 日志和可观测性是Agent系统的生命线Agent系统最容易出问题的不是某个单独组件的代码逻辑而是多模块协作时的状态不一致。因此日志记录必须做到完整。Agent每次调用工具、每次大模型输出、每次状态变化都应有结构化日志。生产环境的Agent系统建议增加全链路追踪ID同一个事件从采集到整改归档全部携带同一个追踪ID这样才能快速定位问题。8.5 安全与合规底线最后再强调一遍安全边界。生产环境数据的敏感性比互联网应用高得多。涉及设备参数、工艺配方、客户订单的数据必须遵守企业的数据安全规范。如果是和外部平台集成要做必要的脱敏、加密、权限隔离。涉及大模型外部调用时要严格审查传输数据的内容和范围必要时采用私有化部署方案。不要为了体验最新大模型功能而忽略数据出场的风险。9. 总结与Agent开发学习路线生产异常闭环Agent本质上是把制造现场最宝贵的“老师傅经验”和“历史处置记录”转化为可复用、可推理、可执行的数字资产。它解决的不只是“发现异常提醒人”这个表面问题而是把异常识别、根因分析、整改闭环连成了一个完整的智能闭环。对于刚开始接触这个方向的开发者建议按照以下路径逐步深入第一步理解制造业务。先搞清楚MES、SCADA、QMS、ERP这些系统分别管理什么数据异常事件在业务上会横跨哪些环节。不懂业务Agent设计得再花哨也没有用。第二步掌握Agent基础框架。了解Agent是什么、Agent架构、Agent记忆、Agent技能这些核心概念并动手构建一个最小Agent能够调用外部API完成简单任务。第三步学习知识图谱与检索增强生成RAG。异常根因分析非常依赖历史案例和文档知识如何把知识组织成图谱结构、如何做相似案例检索是根因分析准确率的关键。第四步实践多Agent编排。一个生产异常闭环Agent的落地往往不是单个Agent能完成的。掌握主从模式、工具调用、SubAgent的拆分方式对于处理复杂业务场景至关重要。第五步结合业务落地闭环。把Agent接入真实的MES或SCADA系统先把“异常识别消息通知”跑通再逐步叠加“根因分析”“整改任务生成”“闭环流转”等能力。生产现场的问题永远比文档里写的复杂。Agent不是万能钥匙但它确实能把工程师从大量重复的“找人、翻记录、催进度”工作中解放出来让人把更多精力放在真正需要经验和判断的事情上。如果你是制造企业IT团队或正在学习Agent开发的工程师可以先用一个具体设备、一个高频异常场景做试点快速验证这个思路在你们工厂是否可行。