前阵子到一家做汽车零配件的工厂聊数字化项目，他们刚上线了一套企业AI助手，汇报材料里已经写了“覆盖研发、生产、采购、供应链”几个大字。接待我的信息部门负责人，问的第一个问题很直接：“AI助手都上了，为什么你还要提什么Operation Agent Brain？”

我没有急着讲概念，而是反问了三个现场问题：这套AI助手能不能在夜班缺料预警后，直接重新生成一张明天的排产计划？能不能在设备异常报警时，主动通知当班调度并给出带依据的复位建议？能不能把这半年处理过的五个典型案例，沉淀成一套新的标准动作流？

对方沉默了几秒，答案意料之中：都不能。它能做的，是基于知识库回答员工提问，偶尔帮忙翻翻手册、查查流程，碰到复杂的跨系统任务，就只能把问题原样转回给人工。

这个场景不是个例。几乎每家有点数字化基础的制造企业，都在经历同一个阶段：先装了ERP、MES、WMS，后来接了大屏、上了BI，再后来部署了AI助手，发现它答题很聪明，但并没有真正让产线变“聪明”。这中间的断层，就是制造企业在用了AI助手之后，还需要一套Operation Agent Brain的根本原因。

这篇文章不打算讲花哨概念，而是想把这套东西背后的逻辑、落地路径，以及那些文档里不会写的坑，尽量完整地讲清楚。给正在搭建制造AI体系、或者正在犹豫“要不要再加一层”的同行做个参考。

1. 先搞清楚：工厂里的AI助手到底做了什么

1.1 三种典型形态：问答、知识检索与流程陪跑

制造企业现在常说的AI助手，大致能分成三类。第一类是知识库问答型，企业把制度手册、设备说明书、工艺文件、安全规程喂给大模型或RAG系统，员工用自然语言提问，系统从文档里检索出答案。这类助手最普及，因为门槛低、见效快，本质上是把静态文件变成了可对话的入口。

第二类是数据对话型，连上BI报表或实时数据库，支持“上个月A产线OEE是多少”这类问题，背后通常是NL2SQL或者语义层映射。它比第一类动了真数据，但范围仍然局限于查询类任务，不会产生任何业务动作。

第三类是流程陪跑型，常见于客服系统和一部分现场作业辅助，系统能根据SOP逐步指导员工完成点检、报工、异常提单等操作。它开始有流程概念，但每一步基本由预设脚本驱动，遇到规则之外的场景只能中断并转人工。

这三种形态有一个共同点：它们都在“回答”或“辅助”，而不是在“执行”。换句话说，AI助手解决的问题，是把信息送到人面前；而真正决定信息下一步怎么走、由谁处理、用什么资源处理的环节，依然完全依赖人的经验。

1.2 AI助手在制造业的四个天花板

结合我在工厂现场见到的实际情况，AI助手在制造业有四条明显的边界。

第一，被动响应。所有能力都需要人来发起提问，系统不会主动监控产线状态，也不会在凌晨三点缺料时抢先去调度。制造现场的不确定性恰恰高发在“没人想到要问”的时候。

第二，数据粒度不够。很多AI助手接入的是事后同步的交易数据，比如ERP的日结数据、MES的班次报工数据，而不是设备层秒级或毫秒级的实时信号。用这种数据做出来的排产建议、质量预警，精度天然受限。

第三，知识是静态的。助手能给的建议，来自当时录入的文档和经验。但制造现场每天都在产生新异常、新处理方案，如果没有人专门把案例沉淀回知识库，助手的能力不会有任何成长。

第四，没有动作闭环。它无法把决策写回业务系统，更不可能控制自动化设备。很多企业上完AI助手后发现，所有结论还是要靠人手动录入到MES或ERP里，等于中间多了一步成本，而不是省了一步成本。

这四条边界，恰好是一个运营执行层必须补的功课。而Operation Agent Brain，从设计目标上看就是在补这门功课。

2. Operation Agent Brain到底是什么，它和AI助手差在哪

2.1 一个更直白的理解：运营代理大脑是一套“能干活”的智能运营层

Operation Agent Brain这个词在国内制造圈还不是特別普及，先给它一个好理解的定义：它是面向生产运营场景的代理式智能体编排层，由若干具备特定职能的AI代理（Agent）组成，负责感知业务状态、拆解运营目标、调用业务系统和设备接口，并自主或半自主地完成执行与反馈。

如果觉得这句话太绕，可以把它类比成一个车间调度室。AI助手相当于调度室里那台可以查资料、查报表的电脑；而Operation Agent Brain相当于坐在电脑对面的那个调度长。调度长不只是把问题查出来，他要决定用什么方案解决，要协调物料、设备、人员，要下指令，要追踪结果，还要把这次的应对方式记录下来，下次遇到类似情况反应更快。

2.2 从“单轮问答”到“目标驱动”的能力跃迁

AI助手的使用模式是“人问，机器答”，一轮交互结束任务就算完了。Operation Agent Brain的模式是“人给目标，机器拆解并执行”。举一个插单的例子：业务员提出“明天有一个紧急订单要插进去”，AI助手能做的最大贡献是告诉你“当前计划确实排满了，可以考虑优化瓶颈工序”，最后怎么改还得人来。而基于Operation Agent Brain的系统，会把“完成插单”拆成一系列步骤：先读取当前排程，再查询可用的设备产能和物料库存，然后跑一遍排产仿真，给出调整后的计划并做冲突校验，最后把方案推送到MES计划模块，等人工确认后生效。整个过程中，人是给出目标、审核结果的角色，而不是每一步的具体执行者。

再举一个设备异常的例子。传统AI助手在“主轴温度超过85度”这个问题面前，只能把设备手册里“检查冷却系统”这一段内容翻出来给你看。而设备运维代理会在几分钟内完成：调取该设备最近一个小时的温度曲线、关联正在加工的工单号、对比同类设备同期数据、判断可能原因，然后生成一份建议处置动作并推送给当班维修工。如果判断是刀具磨损导致负载升高，它还会顺带请求排产代理评估是否调整加工参数或切换备用刀具。

2.3 和RPA、工作流、中台的关系，别混为一谈

制造企业接触过不少自动化工具，容易把Operation Agent Brain和它们搞混。RPA适合规则完全确定、按键位置固定的重复操作，它是“手”；工作流引擎适合流程节点和审批路径预先画好的场景，它是“轨道”；数据中台负责统一数据和复用数据资产，它是“仓库”。Operation Agent Brain更接近“调度大脑”：它根据目标决定调用谁、按什么顺序、判断什么条件，并且能接受模糊和动态变化的目标。

我做过一张简单的对比表格，可以用来直观感受差异：

3. 制造场景里，Operation Agent Brain必须解决的四个核心问题

聊完概念，回到实操视角：一套真正值得做的Operation Agent Brain，至少要覆盖四个核心问题，否则只是一个加了Agent外壳的增强版RPA。

3.1 实时感知：把“人找事”变成“事找人”

制造现场的问题，永远是从数据异常开始的。设备综合效率掉点、温度曲线漂移、BOM变更未同步、库存低于安全水位、订单交期风险……这些信号如果等人在上班后主动去查，损失早就发生了。

Operation Agent Brain的感知层应该连接设备层的PLC、DCS、传感器网关，连接系统层的MES、ERP、WMS、QMS，再叠加时间维度，形成一个个“业务快照”。感知不是为了存数，而是为了做状态判断：哪个环节已经越过了正常区间，哪个指标正在向下恶化，哪个流程卡住超过了两小时。判断结果会进入事件中心，再结合规则和模型决定是否触发某个代理。

判断形成事件的逻辑可以讲细一点。比如设备温度连续5分钟超过阈值，传统做法是写死一条报警规则，超过就发消息。在Agent体系里，我们可以让感知层同时采集上下文，包括当前正在生产的工单、机床主轴负载、最近一次保养时间、同型号设备当日平均温度。这样代理不仅能判断“温度超了”，还能判断“超温是否影响当前工单交期”“是否可能是刀具磨损导致”，然后决定推送给设备维修代理、排产代理还是质量代理。这个差异，就是“报警”和“运营决策”的区别。

3.2 目标拆解：从“能不能办”到“办完后是个什么结果”

代理的大脑需要处理的目标，往往不是一句清晰指令，而是模糊的、多约束的业务诉求。比如前面说的插单，就会牵扯产能约束、物料齐套、交期优先级、换型成本多个维度。因此，各类代理必须有一个统一的“目标拆解器”或规划模块，把大目标分解成一组可执行、可验证的小任务。

过程大致是：分析目标可行性→列出依赖条件→生成动作序列→预估结果指标→交给执行层。每一步都要有明确的数据支撑，而不是模型自由发挥。例如排产代理在生成“调整后的计划”之前，应该先查询瓶颈工序负荷、未结工单列表、物料在库量和采购在途量；在给出计划之后，要附带一个预估结果指标，比如“交期满足率预计从82%提升到95%，但A线产能利用率下降6%”，让人工决策时有依据。

这里有一个特别容易踩的坑：目标拆解得太细，系统反复确认，执行效率反而更低。我建议把拆解层级控制在三到五层，关键决策点设置确认阀门，其余步骤允许代理自治，这样既保留了大模型应对复杂度的能力，又不会因为全自动带来失控风险。

3.3 跨系统执行闭环：MES、WMS、PLC不是你想连就连

制造企业做过系统集成的朋友都知道，打通系统比训练模型辛苦十倍。MES的工单状态字段、ERP的物料预留逻辑、WMS的库位属性、PLC的寄存器地址，每个系统的接口协议、数据结构、操作权限都不一样。要让Agent真正把决策落到系统里，必须建一个统一的执行层，也就是工具层。

常规做法是给每个业务系统封装标准化工具接口，例如：MES工单更新工具、WMS库存查询工具、ERP采购建议工具、设备参数下发工具。Agent不直接面对各家系统的私有协议，而是只调用工具函数。这样设计的好处是，模型不需要记住几十种接口规范，只需要会“选工具、填参数”；接口变动时，也只改适配层代码，不需要重训模型。

执行层还必须考虑安全边界。写操作要有审批，工业控制类操作要有二次确认。我见过一个做得很稳的方案：所有工具接口按影响范围分成只读、写业务数据、写控制参数三个等级，Agent调用高等级接口时，系统强制进入人工审批流，而且审批人能看到Agent给出的依据和预估影响，而不是让审批人打开一堆系统自己核对。

3.4 记忆与自纠错：把老师傅的经验变成系统资产

制造业最宝贵的知识，大量存在于老师傅脑子里。一件事如何处理，他们知道，但系统不知道，新人更不知道。Operation Agent Brain比传统AI助手多出来的一个关键能力，是“记忆体”。

记忆体至少分三层：短期记忆是每个任务执行过程中的上下文；长期记忆是历史案例、决策记录、成功与失败的经验；工作记忆是当前正在处理的多任务协同状态。当一个新的异常发生，代理会先检索历史案例，看有没有相似场景，有就直接参照执行，没有才进入推理生成。任务结束后，系统会做一次复盘：这个方案执行后结果如何，哪些环节和预期有偏差，能否固化成新规则。坚持这个闭环跑两三个月，系统对常见异常的响应速度和准确率会明显上升。

这里有个细节值得注意：案例沉淀不要只存结论，要存“当时的输入条件、决策依据、执行动作、结果反馈”四要素。否则模型复盘时缺少上下文，很容易把偶然成功当成普遍经验。

4. 为什么“本地模型 + Agent”是制造企业更稳的组合

最近业内讨论很多的“AI代理助手加本地模型”这个组合，放在制造现场，不是一个概念噱头，而是安全和效率共同作用下的必然选择。

4.1 数据不出厂，是制造企业的底线

制造企业拥有的工艺参数、配方、BOM结构、排产逻辑、设备运行数据，是竞争力的重要组成。把这类数据送到公网上的大模型，哪怕做脱敏，也很难让企业完全放心。法律层面有数据安全与合规要求，业务层面更担心的是竞争对手和供应链伙伴拿到自己的工艺细节。

本地化部署的模型，从系统架构上保证数据不离开工厂边界。模型推理发生在企业内部服务器或边缘节点，知识库文件存在企业内部存储，日志和案例库同样留在内网，加上权限控制，就构成了相对完整的数据闭环。这一点对军工、医药、新能源等敏感行业尤其重要。

4.2 确定性优先：工业现场不需要“创造性回答”

工业执行场景和办公场景有一个本质区别：办公场景里的回答偏差可以容忍，AI助手说错一句可以重新问一次；但工业场景里，排产结果错一个时间点、质量参数错一个数值，可能直接带来材料损失、交期违约甚至安全事故。因此工业级模型追求的从来不是“有创造性”，而是“在约束内保持稳定”。

本地小模型通过量化、领域微调、知识注入，可以在很多垂直任务上达到接近云端大模型的效果，同时把响应时间控制在几十毫秒到一秒以内，不依赖公网带宽，也不受网络波动影响。遇到断网、协议中断的极端情况，本地Agent还能降级运行，至少保证核心监控和基础任务不中断，这种容错性是云端方案很难提供的。

4.3 混合架构：不是非此即彼，是按任务分派

我的习惯做法是搭一套混合架构：本地部署一个7B到14B左右的中小参数模型，负责设备助手、工位问答、表单解析、模板生成、规则提取这类高频、低风险任务；云端保留一个更强的大模型，负责复杂推理、多目标优化、自然语言生成等高难度任务。代理层根据任务的风险等级、时延要求和数据敏感度，自动决定路由到本地还是云端。

这样设计最大的好处是成本可控。高频任务的模型完全本地跑，只产生电费和硬件折旧；低频复杂任务才调用云端大模型，费用有限。同时，敏感数据全部留在本地模型处理，只有脱敏后的非敏感数据有机会流出，安全与效果兼得。

我遇到过一家企业，一开始因为担心安全，坚持所有推理都走本地小模型，结果效果确实跟不上，某些复杂异常案例的推理逻辑明显单薄。后来改成混合架构，避开敏感字段的调用走云端，立刻把复杂场景的准确率拉了起来，成本增加却不到每月两千块。所以混合架构不是一个妥协方案，而是一个更聪明的分层方案。

4.4 算力与成本：不要一上来就买超大卡

很多企业一听本地模型，第一反应是上H100、A100，其实没必要。3B到8B参数级别的模型，经过量化后在一张消费级显卡或者中低端专业卡上就能跑得不错，计算资源需求大概在16GB到48GB显存之间。如果并发量不高，甚至可以用CPU推理撑起大部分问答和工具调用场景，推理速度虽有差距，但对部分非实时任务完全够用。

先跑起来、再扩容是更现实的路径。初期上线，一台GPU服务器加上几个轻量API网关就能支撑试点产线；验证效果后再逐步增加推理节点、引入分布式推理和模型路由。制造业数字化项目最忌讳一上来就买一堆大算力，最后模型没调好，硬件先积灰。

5. 如果让我搭，一套最小可用的Operation Agent Brain长什么样

理论聊完，落到工程。我目前认为一套值得投入的轻量级方案，大概分成五层。

5.1 分层架构：感知、代理、工具、模型、反馈

感知层负责数据接入。建议先把MES、ERP这两套系统打通，再接入一到两个关键设备的PLC或传感器网关。数据通过消息总线实时更新，同时保留一份时序数据库用于回放和分析。

代理层是核心，先不要贪多，做三个代理就够：排产代理、设备运维代理、质量异常代理。每个代理内部包含提示模板、思维链策略、工具调用列表、案例记忆库。代理之间通过事件总线通信，比如设备代理发现异常，可以请求排产代理评估影响。

工具层按照前面说的思路，封装统一API。第一版先做查询类工具和低风险写操作，比如查询工单、查询库存、读取设备状态、生成异常工单，暂不做控制类写操作。

模型层按混合架构部署，本地一个7B左右微调模型，云端按需调用更强模型。所有请求都经过模型网关，网关负责路由、限流、审计。

反馈层负责把执行结果、人工审批意见、案例复盘数据写回知识库和案例库，形成记忆。这一层容易被忽略，但恰恰是系统能否自进化的关键。

我整理了一份最小可用版本的组件清单，供参考：

5.2 一个核心流程：插单排产的代理实现

下面用伪代码演示排产代理处理“插单”任务的完整调用链。代码简化了细节，但能看清整体逻辑。

# 目标：把紧急订单插入明日排产计划 agent = ScheduleAgent(model_gateway="local/7b", memory=case_db) # Step1: 理解目标，提取约束 intent = agent.parse_intent("明天上午加一个紧急工单，型号AX-102，数量500件") constraints = agent.extract_constraints(intent) # 输出: {delivery_date:"明天12点", qty:500, type:"AX-102", priority:"high"} # Step2: 查询现场状态 orders = agent.call_tool("mes.query_orders", date="tomorrow") materials = agent.call_tool("wms.query_material", item="AX-102") equipment = agent.call_tool("em.query_equipment_status", line="line_3") # Step3: 检索历史相似案例 similar_case = agent.retrieve_memory(features=constraints, top_k=3) # Step4: 生成初步插入方案 + 跑仿真 plan = agent.reason( constraints=constraints, current_plan=orders, material_status=materials, equipment_status=equipment, similar_case=similar_case, ) plan = agent.run_simulation(plan) # 模拟冲突与交期 # Step5: 校验并输出 check_result = agent.validate(plan, safe_rules=["bottleneck_load<=0.9"]) if check_result.pass: agent.call_tool("mes.create_mutation_ticket", payload=plan, require_approval=True) agent.notify("schedule_board", f"已生成插单方案，等待计划员确认，预计交期影响：{plan.kpi_text}") else: agent.call_tool("mes.create_exception_order", payload=check_result.reasons) agent.ask_human("排产冲突无法自动解决，原因已生成，请审阅处理")

这个流程的关键点在于：代理不会直接写正式计划，而是先创建一个审批工单，把方案、依据、预计影响一起发给计划员；计划员确认后，代理再执行正式写操作。实操里我会再加一道刚才提到的安全阀：任何影响正式单据的动作，都必须经过审批工具，代理只能生成“待生效”的数据版本。

5.3 兜底与确认机制：宁可要慢一点，不要错一点

做一个面向真实产线的Agent系统，可靠性设计永远大于智能化指标。我总结出三条铁律。

第一，置信度低于阈值就转人工。代理在生成方案时，需要同步输出一个自评估的置信度分数。低于设定阈值时，不得自动执行，只能生成“建议方案”并转交人工。阈值根据场景调整，排产类建议可以设在75%，控制类指令必须95%以上。

第二，所有新增的自动动作，都要能一键撤回。制造系统里写错单的后果很重，所以执行层的每个写操作都要能生成反向冲销工单，或者至少在业务系统留有完整的审计日志，能在五分钟内还原现场。

第三，日志要全链路可追溯。每一次Agent的思考过程、工具调用参数、返回结果、人工确认动作，都要结构化落日志。出问题时不至于对着黑盒瞎猜，也能拿这些日志不断优化提示词和决策逻辑。

6. 落地路上最常见的坑，以及我的排查记录

6.1 接口集成比算法难三倍

我一个项目里，排产代理开发用了两周，MES接口联调用了一个月。原因是MES供应商只开放了部分查询接口，写操作需要单独申请权限，前后拖了两轮流程；ERP那边的接口文档版本和实际版本对不上，字段名不一致；设备PLC的OPC UA服务器只部署在一台老旧工控机上，带回传延迟。

排查经验是：项目启动的第一天就把“系统接口清单”和“权限申请责任表”做出来，让IT、OT、供应商三方坐在一起过一遍。不要假设数据都能拿到，先把接口能拿到的字段、频率、延迟、权限全部列出来，再倒推Agent的功能边界，这样能避开大量返工。

6.2 模型幻觉在工业场景里会闯祸

大模型天生会“一本正经地胡说八道”，在工业场景，这种幻觉的后果是灾难性的。我遇过一个例子，模型建议某台设备的冷却液温度可以上调5度以提升效率，但实际该设备的安全上限只允许调1度。这种问题靠提示词是压不住的，必须在推理链路里加一道工程硬约束检查器。

我现在每个代理背后都挂一组校验规则，用代码写死，不走模型判断。比如生产参数范围校验、工序交期约束、物料齐套校验、工位操作权限校验，全部由确定性规则引擎完成。模型只负责生成候选方案，校验必须由规则引擎把关，两层各司其职，基本能堵住大部分幻觉风险。

6.3 一线不用系统，再智能也白搭

大部分Agent系统死掉，不是技术不行，是没人用。一线计划员、调度员、班组长用不习惯，要么觉得建议不靠谱，要么觉得操作界面太复杂，干脆回到Excel时代。我们当初的解法是“影子模式”上线：Agent先只出建议，不碰正式单，同时把建议的准确率用报表公示。连续跑了三周，准确率上来了，一线开始主动看建议；再跑两周，他们才会放心让Agent生成待确认单据。

还有一点经验：不要一上来追求全自动化。哪怕技术上能做到自动，也要保留人工确认按钮，让员工觉得“系统是我的工具，而不是抢我饭碗的东西”。等信任建立起来，再逐步放开权限，这才是稳的路子。

6.4 运维指标：不要只看准确率

衡量Operation Agent Brain好不好，我建议用四组指标：执行成功率（自动执行的任务中，最终被人认可的比例）、转人工率（Agent把任务抛给人工的比例）、异常漏报率（现场异常但Agent未识别的比例）、平均处置时长（从事件发生到闭环的时间）。这四个指标能比较全面地反映一个运营智能体的价值。

每周固定花半小时复盘指标变化，重点看不达标案例属于感知问题、推理问题、执行问题还是记忆缺失，对应去优化数据采集、提示词、工具接口和案例库。这才是Agent系统持续变好的唯一路径。

最后说点我自己的体会。在工厂里跑Agent系统，和做互联网产品完全是两种节奏：不能追求“越自动越爽”，要接受“慢一点的可靠”。Operation Agent Brain不是来替代你现有AI助手的，它是在AI助手基础上，把感知、决策和闭环执行能力补上之后，形成的那层真正敢碰业务系统的运营层。本地模型加代理治理这套组合，我跑了快一年，最大的感受是：系统不是一夜之间变聪明的，而是每天通过案例沉淀悄悄变强的。如果你正卡在“AI助手有了但产线还是老样子”这个阶段，不妨从一个最小场景开始跑，比如一个设备的异常处置闭环。跑通了，你自然会理解这一层的作用。