制造企业上马AI智能体前，先把“感知—决策—执行”闭环做对

制造企业上马AI智能体，真正难的不是选一个更大的模型，而是让现场数据、业务规则和执行系统形成一条可追踪的链路。设备出现异常后，系统能否判断影响、生成维护任务并核验结果？质检发现缺陷后，能否追溯批次、隔离风险并触发复检？供应链发生波动时，能否在权限范围内调整计划，而不是只生成一份分析报告？这些问题决定了AI是“预警工具”，还是能够参与经营的业务系统。

对制造企业而言，所谓“感知—决策—执行”闭环，至少包括四个可验证环节：采集现场和经营数据，基于规则与模型形成判断，调用ERP、MES、WMS等系统执行动作，再把执行结果和人工反馈回写，形成下一轮判断。任何一个环节断开，智能体就可能退化为一个反应更快的看板或聊天助手。

先看经营矛盾：预警很多，真正解决问题的动作很少

许多企业已经部署了设备监控、质量分析、供应链预警或经营驾驶舱，但管理者仍会遇到三个矛盾。

第一，数据越来越多，责任却没有同步落到具体岗位。设备系统可以提示温度、振动或能耗异常，质量系统可以识别缺陷，供应链系统可以预测缺料，但谁来确认优先级、谁来下达工单、谁来承担误判责任，往往仍依赖人工协调。

第二，系统之间“看得见”，却“接不上”。数据可能分散在传感器、PLC、MES、ERP、仓储系统、质量系统和协同平台中。智能体即使能读懂某个系统的数据，也未必能安全调用另一个系统执行任务。

第三，项目容易用技术指标替代经营指标。模型准确率、调用次数和问答响应时间并不能直接证明项目创造了价值。企业更关心的是非计划停机是否减少、一次交验合格率是否提高、排产调整时间是否缩短、库存和加急采购成本是否下降。

因此，AI智能体项目的起点不应是“我们要部署几个Agent”，而应是明确一条业务链路：什么问题需要被感知，什么判断需要被辅助或自动完成，什么动作可以授权执行，执行后用什么指标验证结果。

三类场景拆解：从建议到动作，差别在哪里

预测性维护：从发现异常到闭环派工

传统设备监控往往停留在“异常提醒”层面。例如，系统发现某台设备温度升高，向维修人员发送通知，但后续仍需人工查阅维修手册、确认备件库存、判断停机窗口并创建工单。

更完整的维护智能体可以按以下链路工作：

1. 采集设备传感器、运行日志、历史维修和工艺参数；
2. 判断异常是否达到预警阈值，并区分偶发波动与持续性风险；
3. 查询设备档案、维修手册、历史故障和备件库存；
4. 生成维护建议，评估停机影响和备件需求；
5. 在授权范围内创建维修工单或采购申请；
6. 由维修人员复核后执行；
7. 回写维修结果、替换部件和故障原因，验证预警是否准确。

搜索资料中提到的一则案例称，某重工企业将传感器数据、维修手册、库存备件与采购工单连接起来，并宣称停机时间减少19%。这一结果来自企业服务方的案例材料，适合作为场景线索，不宜直接视为所有制造企业都能复制的平均效果。企业在评估时，应进一步核验统计周期、设备范围、停机定义、改造前基线以及是否存在同期工艺变化。

预测性维护尤其需要设置人工复核。涉及设备停机、关键部件更换和安全风险的动作，不宜由模型直接下达。智能体可以自动收集证据、计算影响、生成工单草案，但最终执行权限应与设备等级、故障等级和岗位责任绑定。

智能质检：从识别缺陷到控制批次风险

智能质检的价值也不在于“看见缺陷”本身，而在于缺陷被发现后能否推动后续动作。

一个可执行的质检闭环通常包括：

• 视觉、尺寸、工艺参数和检验结果统一关联；
• 缺陷与产品批次、设备、班组、工艺参数建立追溯关系；
• 根据缺陷等级触发复检、隔离、返工或放行流程；
• 将异常反馈给工艺、设备和生产部门；
• 对参数调整设置上下限、审批人和回滚机制；
• 记录每一次判断依据与处置结果。

搜索摘录中有一则锂电池制造质量管理案例，描述了系统从数据库和协同表格提取数据，调用专业软件生成分析结果，再回写并通知相关人员，宣称将质量预警响应周期从小时级压缩到分钟级。这个案例更明确地说明了跨系统自动化的价值，但“响应周期缩短”并不等于“误判率下降”或“质量成本降低”。企业还需要关注漏检率、误报率、复检比例、批次隔离时间和客户投诉变化。

对于高风险产品，智能体不应直接修改关键工艺参数。更稳妥的方式是先输出参数调整建议，并说明依据、影响范围和回滚方案；由工艺工程师确认后执行，再将结果写回系统。只有在低风险、边界清晰且经过充分验证的参数范围内，才考虑有限度的自动调整。

供应链协同：从波动监测到计划调整

供应链智能体面对的不是单一数据源，而是需求、库存、订单、采购、物流、供应商交付和外部环境的组合变化。

它可以帮助企业完成：

• 识别订单变化、库存下降和交付延迟；
• 计算缺料风险及其对生产计划的影响；
• 比较替代供应商、替代物料和不同交付方案；
• 模拟加急采购、调整排产或改变运输方式的成本；
• 生成采购、计划和供应商沟通任务；
• 跟踪任务是否完成，并更新风险等级。

但供应链场景的自动化边界更复杂。调整采购数量可能影响现金流，替换物料可能影响质量认证，改变交付方案可能引发客户承诺风险。因此，智能体可以先做风险排序和方案比较，再根据金额、物料等级、客户等级和交付紧急度决定是否需要审批。

搜索资料提到，部分制造案例将工艺优化、排产调度和执行监控等多个智能体放入同一闭环，并报告准备时间、排产达成率和计划调整时间出现明显改善。此类结果可以用于说明“多Agent协同”的设计方向，但企业必须核实案例主体、实施范围、指标口径和持续时间，不能仅凭宣传材料推导出普遍结论。

架构设计：不是接入一个模型，而是连接四层能力

制造企业部署AI智能体，建议将架构拆成四层，而不是把所有能力都放进一个大模型。

第一层：现场感知层

包括传感器、PLC、SCADA、机器视觉、设备日志、质量检测数据、仓储数据和人员操作记录。这一层首先要解决数据是否连续、时间戳是否统一、设备编码是否一致、异常是否可追溯。

如果同一台设备在不同系统中使用不同名称，或者批次、工单、物料编码无法关联，模型再强也难以形成可靠判断。数据治理应优先处理与目标场景直接相关的关键字段，而不是一开始追求全企业数据统一。

第二层：业务语义与知识层

这一层负责把数据转换为业务可以理解的对象，包括设备档案、工艺规程、质量标准、物料关系、供应商规则、维修记录和审批制度。

知识库不能只保存文档，还应保留版本、生效时间、适用范围和责任人。例如，一份工艺参数标准已经更新，但系统仍引用旧版本，就可能导致看似合理、实际过期的建议。对于生产和质量场景，知识检索必须带有来源标记，方便工程师复核。

第三层：模型与智能体编排层

模型负责识别、推理、总结和生成方案，智能体编排则负责任务拆解、工具调用、状态管理和异常处理。两者不能混为一谈。

企业需要明确：

• 哪些判断使用固定规则；
• 哪些判断使用统计模型或机器学习模型；
• 哪些任务需要大语言模型理解文本和流程；
• 哪些动作只能生成草案；
• 哪些动作可以在授权条件下自动执行；
• 模型不确定时如何转人工。

在高风险环节，规则引擎、阈值控制和审批流通常比完全依赖自然语言推理更可靠。模型应成为系统的一部分，而不是替代所有既有控制逻辑。

第四层：执行与反馈层

执行层通过ERP、MES、WMS、QMS、SRM等系统的API、消息队列或经过控制的自动化接口，完成工单创建、库存查询、排产建议、质检通知和采购申请等动作。

接口设计应遵循“可读、可写、可回滚、可审计”原则。对于写入类动作，系统需要记录调用人、调用时间、输入参数、模型版本、审批结果和最终状态。无法回滚的动作，应设置更高审批等级，必要时先采用模拟执行。

反馈不仅是“任务已完成”，还应包括执行结果、异常原因和人工修正。只有这些信息持续回流，企业才能判断智能体是否真的改善了业务，而不是把问题从一个系统转移到另一个系统。

治理风险：最需要防范的不是模型不会回答

权限过大，可能把建议变成错误动作

智能体不应共享一个覆盖全系统的万能账号。权限至少要按人员、岗位、系统、数据范围、动作类型和金额或风险等级拆分。

查询设备数据的权限，不等于修改工艺参数的权限；生成采购申请的权限，也不等于批准采购订单的权限。企业可以采用分级授权：

• 低风险查询和报表生成，可自动执行；
• 工单草拟、异常通知和方案推荐，需要业务人员确认；
• 生产计划、采购金额、关键参数和批次放行，需要审批；
• 涉及安全、合规或客户承诺的动作，原则上保留人工最终决策权。

数据质量不足，可能放大错误判断

传感器漂移、数据缺失、重复工单、错误编码和延迟回传都会影响判断。项目上线前，应建立数据质量检查，包括完整性、及时性、一致性、准确性和异常值处理。

对于每个场景，至少要回答三个问题：关键数据来自哪里，多久更新一次，出现缺失或冲突时系统怎么做。不能把所有数据问题都交给模型“自行理解”。

结果不可解释，业务部门就不会真正使用

制造现场需要知道“为什么这样判断”。维护建议应关联设备信号和历史记录，质检判断应关联图像、标准和批次，供应链方案应展示库存、交付和成本依据。

解释不意味着展示复杂的模型参数，而是让责任人能够复核证据、判断是否合理，并在错误时追溯原因。对关键动作，还应保留决策前后的状态快照。

供应商宣传数据，不等于企业实际收益

制造业AI案例中常见“效率提升”“成本下降”“响应时间缩短”等表述，但这些数字必须结合基线和口径判断。项目团队在验收时，应区分：

• 公开资料可验证的案例结果；
• 企业内部试运行结果；
• 供应商预测或宣传数据；
• 尚待核实的行业推算。

例如，某案例宣称排产计划达成率从50%提升至90%，企业需要核对统计周期、订单复杂度、计划达成定义和同期人员或设备变化。没有这些信息，数字只能作为待验证线索，不能直接写入投资回报测算。

投入产出评估：先算闭环价值，再算模型成本

AI智能体项目的收益测算，应围绕业务损失和可执行动作展开。

可以建立一套基础指标框架：

评估维度	重点指标	需要核实的问题
设备维护	非计划停机时长、平均维修时间、备件周转	预警是否提前，误报是否增加维修负担
质量管理	一次交验合格率、漏检率、误报率、批次隔离时间	缺陷识别是否带动了根因处理
生产计划	计划调整时间、达成率、换线时间、在制品水平	改善是否来自智能体，还是来自订单结构变化
供应链	缺料次数、加急采购金额、库存周转、交付达成率	方案是否考虑质量、认证和现金流约束
组织效率	人工处理时长、跨部门等待时间、审批周期	节省的时间是否转化为产能或管理改善
风险控制	越权调用次数、人工驳回率、异常回滚次数	自动化是否引入新的运营风险

投资回报不能只计算软件许可和模型调用费用，还要包括数据治理、接口改造、现场改造、流程重构、培训、运维和安全审计成本。

更稳妥的计算方式，是先建立四到八周的基线，再进行小范围试点。试点期间同时记录智能体建议被采纳、修改、驳回和造成返工的情况。只有当业务指标改善、风险指标不恶化、人工复核负担可接受时，才适合扩大范围。

分阶段实施：从低复杂度场景走向跨流程协同

第一阶段：选择可控试点

优先选择数据较完整、流程边界清晰、失败代价可控且有明确责任人的场景，例如质量预警汇总、设备维修工单草拟、供应商交付异常提醒、库存和订单对账。

这一阶段的目标不是证明模型无所不能，而是跑通“数据进入—判断生成—人工确认—系统执行—结果回写”的最小闭环。

第二阶段：打通核心系统接口

在试点稳定后，逐步连接ERP、MES、QMS、WMS或SRM。接口建设应优先满足关键业务动作，不宜一开始追求全系统贯通。

项目团队需要建立接口清单，明确每个接口的读写权限、字段定义、失败重试、日志保留和回滚机制。对于没有标准API的旧系统，可以先使用受控的自动化方式，但必须避免依赖个人电脑和不可审计的脚本。

第三阶段：扩大人工协同范围

当单一场景能够稳定运行后，再把相关流程连接起来。例如，将设备异常、备件库存、维修工单和采购申请关联，或将质检缺陷、批次追溯、工艺调整和复检流程关联。

此时要重点管理跨部门责任：设备部门负责什么，质量部门确认什么，计划部门如何调整，采购部门何时介入。智能体协同不能替代组织协同，反而会把原本隐藏的流程冲突更快暴露出来。

第四阶段：建设多智能体协同

多智能体并不等于同时上线多个机器人，而是让不同职责的智能体围绕同一生产目标协作。工艺优化、排产调度、执行监控可以分别负责不同任务，但必须共享工单、计划、状态和约束条件。

进入这一阶段前，应先验证三个条件：单场景指标稳定，系统接口可靠，异常和人工接管机制成熟。否则，多智能体只会把局部错误更快地传递到其他流程。

项目落地清单：上线前先问清楚五件事

管理者可以在立项和验收时逐项检查：

1. 场景是否对应明确经营损失？

是否有可量化的停机、返工、缺料、延期或人工处理成本？

1. 数据是否足以支持判断？

设备、工单、批次、物料和人员记录能否关联？数据是否连续、及时、可追溯？

1. 系统是否允许安全执行？

ERP、MES及相关系统是否具备可控接口？哪些动作只读，哪些动作可写，哪些动作必须审批？

1. 人工复核是否嵌入流程？

谁负责确认，什么情况下必须接管，错误动作如何撤销，异常是否会自动升级？

1. 收益和风险是否同时验收？

除了效率提升，还是否考察误报、漏报、越权、回滚、投诉和返工等指标？

制造企业的AI智能体建设，本质上是一次业务流程重构，而不是单纯的软件采购。预测性维护、智能质检和供应链协同都可以成为入口，但只有当感知数据能够进入正确的业务语境，决策能够被责任人复核，执行能够安全调用企业系统，结果能够持续回写，项目才真正形成闭环。

因此，制造业数字化转型进入智能体阶段后，竞争重点不会只是模型规模，而是企业能否把现场数据、业务规则、系统接口和组织责任连接起来。先从低复杂度、可衡量的场景做出一个可靠闭环，再逐步扩展到跨流程协同，通常比一开始建设“大而全”的工厂级智能体更稳健。