制造企业选 AI Agent，为什么“能演示”不等于“能生产”

在制造企业的选型会议室里，有一幕几乎每周都在上演：供应商打开笔记本、投屏、点几下，屏幕上数据开始流转，单据自动填充，报表瞬间生成，会议室里响起一片“不错”。三个月后，项目立项、采购、实施，系统真正跑进财务的月末结账和车间的排产日常，问题却一个接一个冒出来——某张单据格式换了、某个系统弹出一个确认框、某批数据里多了一个空格，整条流程就停在那里，等人来救。

Gartner 曾预测，到 2025 年底至少有 30% 的生成式 AI 项目会在概念验证阶段之后被放弃，原因大多不是模型不够聪明，而是“跑不通生产”。对制造企业而言，这句话的分量更重：一次演示失败只是尴尬，一次生产事故可能意味着错发的货、算错的成本、迟交的订单。本文想聊的正是这件事——制造企业选 AI Agent，为什么“能演示”不等于“能生产”，以及该用什么标准去分辨这两者。

一、“能演示”和“能生产”，中间隔着一条工程化的鸿沟

演示与生产，本质上是两种完全不同的验证目标。演示回答的是“这条路走不走得通”，生产回答的是“这条路每天走一千遍，还能不能走得稳”。两者之间不是程度差异，而是性质差异。

1.1 演示面对的是精选样本，生产面对的是全量长尾

几乎所有的 POC 演示，都建立在一个被精心修剪过的环境之上：

• 数据是干净的：演示用的表格字段整齐、格式统一、无空值；而真实业务里，同一张物料清单可能来自三个部门、五种模板、七种命名习惯。
• 路径是标准的那一条：演示只展示“顺利情况”，真实的流程里充满分支——客户改单、物料替代、审批退回、系统弹窗。
• 没有历史包袱：演示环境是全新的，生产环境里躺着十年的老系统、没人敢动的定制字段、以及只有某位老师傅才知道的“特殊处理”。

判断标准其实很简单：让供应商在你的真实数据、真实系统、真实权限下跑一遍，而不是在他们的样例库里跑。

1.2 演示验证的是“能不能做对一次”，生产验证的是“能不能一直做对”

制造业对自动化的要求从来不是“惊艳”，而是“可预期”。一条产线的价值不在于它能生产出一件完美产品，而在于它每天都能稳定产出合格品。AI Agent 也一样。

• 单次成功率不等于稳定成功率：一次演示成功可能只是运气好，稳定运行需要的是对异常的识别、重试、上报与兜底。
• 出错了有没有人接得住：生产系统必须回答“如果 Agent 卡住了，业务会不会停摆”，这决定了人机协同的边界设计。
• 变更响应速度：业务规则一改，Agent 是当天就能调整，还是要重新训练、重新开发、等一个版本周期。

实在Agent 在交付制造客户时，通常不会把“跑通一个流程”当作交付节点，而是把“连续 N 天无人工干预完成率”作为验收指标——因为这个数字才真正对应生产环境里的稳定性。

二、制造业的特殊性：为什么这个行业对“演示型 AI”格外不宽容

如果说互联网行业可以容忍 AI 产品“先上线再迭代”，制造业几乎不具备这种宽容度。原因有三。

2.1 系统林立、口径各异，集成成本远高于模型成本

一家中等规模的制造企业，通常同时运行着 ERP、PLM、OMS、MES、WMS、财务系统、OA，以及若干张“只有某个部门在用”的 Excel 总表。数据在这些系统之间流转，靠的是人复制粘贴、邮件传递、手工核对。

• 难点不在于“AI 能不能理解这段文字”，而在于“AI 能不能登录这个系统、点对那个按钮、在弹窗出现时做出正确选择”。
• 大量存量系统没有开放 API，界面还停留在十年前的设计，Agent 必须具备真正的界面级操作能力，而不是只会在沙盒里调用接口。
• 数据口径不统一是常态：同一款产品在销售总表、生产订单、库存台账里的编码可能完全不同。

2.2 错误的代价是实物，不是点击率

电商推荐错了，用户划过去就好；制造企业算错一次用量，可能就是一批料的浪费、一次交付的延期。这决定了制造场景对 AI Agent 的要求是可追溯、可复核、可回滚：

• 每一步操作要留痕，出问题能定位到具体哪一行数据、哪一个判断；
• 关键节点要有人工复核位，而不是全权交给机器；
• 涉及金额、库存、交期的写操作，必须有校验与回退机制。

2.3 场景极度分散，一个“通用大脑”解决不了几十件具体活

制造业的智能化需求不是一个大场景，而是几十个小场景的集合。仅从公开的场景实践来看，一家制造企业的智能化需求清单可能同时包含：产品研发部的 CBOM 表与模具清单比对、PLM 系统自动新增料号、共享盘同步最新图纸；计划与生产部的 PMC 生产派工与交期回复、MRP 请购单批量修改、未质检订单风险排查；财务部的应付发票提取匹配入库、银企智能对账、增值税申报；采购部的原材料价格每日获取、物料到货计划拆分……一个行业汇总下来，轻松超过四十个细分场景。

通用大模型能回答“什么是 MRP”，但回答不了“这张请购单上第 37 行的用量该不该改”。

这正是实在Agent 这类面向企业场景的智能体产品的价值所在：它不是提供一个万能对话框，而是把每一类具体业务动作拆解成可配置、可复用、可运维的数字员工能力。

三、判断一个 AI Agent 能否进生产，看这四道关

那么，制造企业该如何在选型阶段就把“演示型选手”筛掉？建议从下面四个维度逐项追问。

3.1 系统关：能不能真的“进得去、改得动”

• 是否支持对无 API 的老系统进行界面级操作，并且能处理弹窗、验证码、加载延迟等真实干扰；
• 是否具备跨系统串联能力，比如从 ERP 导出订单、计算完工日期、再写回系统；
• 权限体系是否与企业现有账号体系打通，而不是让每个人共享一个“超级账号”。

以 PMC 生产派工场景为例：销售订单进来后，需要结合成品库存与产线产能计算生产计划，再回到系统中修改计划完工日期。这个动作看似简单，但涉及多系统读取、规则计算、批量写回三个环节，任何一环在真实环境里都可能出岔子。

3.2 异常关：出问题了谁兜底

• Agent 遇到无法识别的界面或数据时，是静默失败、胡乱猜测，还是准确上报并转人工；
• 是否有明确的“人工接管”入口，接管后流程能否从断点继续；
• 异常处理规则是否可由业务人员自行配置，而不是每次都要找厂商改代码。

3.3 数据关：脏数据、缺字段、口径不一，怎么接

• 对格式不规范的输入（合并单元格、错别字、单位混用）是否有容错与清洗能力；
• 比对类任务能否定位到“第几行第几列差了什么”，而不是只给一个“不一致”的结论；
• 处理结果能否自动生成差异标注，供人工二次确认。

在 CBOM 表与模具清单比对这类场景里，一份 CBOM 动辄几百行明细，人工逐条核对产品名称、计算差量、核对用量，既慢又容易出错。真正能上生产的 Agent，不只是“比对出来”，而是要清楚标出差异项、给出可读的差异说明，让工程师花五分钟确认，而不是花两小时复核。

3.4 运维关：上线之后谁来管、怎么扩

• 是否有统一的调度中心，能看到每个 Agent 每天跑了多少次、成功多少、失败多少；
• 业务规则变更时，调整周期是小时级还是月级；
• 一个新场景的复制成本有多高——是从零开发，还是基于既有能力拼装。

这四道关里，前三道决定“能不能用”，第四道决定“能不能长久用下去”。很多演示很漂亮的产品，恰恰卡在第四道。

四、把“演示”做成“生产”，实在Agent 的三条实践路径

理念说再多，不如看具体怎么落地。结合制造企业的实际交付经验，实在Agent 通常沿着三条路径把 POC 推进到生产。

4.1 从最痛的单点切入，先拿到可度量的价值

不建议一上来就做“全流程智能化”，而是选一个高频、规则清晰、痛感明确的场景先跑通。比如：

• 财务侧：应付发票提取与匹配入库、银企智能对账，这类场景规则明确、数据量大、人工耗时久，收益容易量化；
• 研发侧：销售总表按产品线分表，人工操作约需两小时，Agent 处理后压缩到五分钟级别，效率提升明显；
• 计划侧：延期订单查询跟进、MRP 请购单批量修改，重复度高、逻辑稳定，适合作为自动化起点。

单点跑通的意义不只是省了多少工时，更在于让业务团队建立起“敢把活交出去”的信任。

4.2 用工程底座承接规模化，而不是靠堆人力

当场景从一个变成十个，考验的就不再是单点能力，而是底座：

• 统一调度：哪些任务几点跑、跑多久、超时怎么办，需要有集中视图；
• 权限与审计：谁授权了哪个 Agent 操作哪个系统的哪些字段，操作记录能否回溯；
• 知识沉淀：把业务规则、异常处理经验沉淀为可复用配置，新场景上线时不必从零开始。

实在Agent 在制造集团的跨系统订单智能分发、流程异常自适应处理等场景中，验证的正是这种“一个底座支撑多个数字员工”的模式。

4.3 设计好人机协同边界：例外交给专家，规则交给 Agent

生产环境里最忌讳两种极端：一是全自动、出了问题没人管；二是事事都要人点确认、Agent 沦为摆设。合理的做法是把流程切成“规则段”和“例外段”：

• 规则明确、可校验的环节，交由 Agent 全自动完成；
• 涉及金额异常、数据冲突、客户特殊要求的环节，Agent 主动挂起并推送给人；
• 人的处理结果反哺为新的规则样本，让 Agent 下一次更少打扰人。

五、给制造企业的一份选型自查清单

在最终决策前，不妨用下面这八个问题去“拷问”每一个候选方案：

• 能否在我们自己的真实数据和真实系统权限下完成验证，而不是在厂商的演示环境里？
• 面对没有 API 的老系统，能否完成界面级操作并稳定处理弹窗、延迟等干扰？
• 处理脏数据和格式异常时，失败率与人工干预率分别是多少？
• 出现异常时，Agent 是静默失败、错误猜测，还是准确上报并支持断点续跑？
• 业务规则变更，调整周期是几小时、几天，还是需要等一个版本？
• 是否有统一的调度、监控与审计视图，能回答“昨天哪个任务失败了”？
• 从第一个场景扩展到第五个、第十个场景，边际成本是递减还是持平？
• 供应商是否愿意把“连续稳定运行天数”和“人工干预率”写进验收条款？

能把这些问题回答清楚的方案，才配得上“能生产”三个字。

制造企业选 AI Agent，本质上不是在选一个更聪明的模型，而是在选一个能长期共事的数字同事。演示看的是它聪不聪明，生产看的是它靠不靠谱——而靠谱，是可以被拆解、被验证、被写进合同里的。实在Agent 在制造场景上的持续投入，也正是围绕这条主线展开：把每一个看似简单的业务动作，做成经得起全量数据、真实系统、长期运行的工程化能力。下一次坐在选型会议室里，不妨少看几分钟炫目的演示，多问几句关于异常、关于运维、关于三个月后的问题。

常见问题解答

演示跑通了，POC 也过了，为什么上线还是会出问题？

因为 POC 通常只覆盖“主路径”，而生产环境里 20% 的例外情况消耗了 80% 的维护精力。建议在 POC 阶段就引入真实数据的全量样本，并把异常处理能力列为验收项，而不是上线后再补。

制造企业应该从哪个场景开始做第一个 AI Agent？

优先选三个条件同时满足的场景：高频重复、规则相对清晰、错误后果可控。财务发票核对、销售总表分表、订单信息录入都属于这一类。先在这些场景上跑出可度量收益，再向上下游延伸。

老系统没有 API，是不是就做不了自动化？

不是。具备界面级操作能力的智能体可以在没有 API 的情况下完成读写操作，这也是制造业落地中最常见的方式。关键要看它能否稳定处理弹窗、加载延迟、界面变动等情况。

上线之后业务规则变了怎么办？

这考验的是产品的可配置性。理想状态下，规则调整由业务或 IT 人员在配置界面完成，当天生效；如果需要厂商改代码、走版本发布，说明它还没有真正进入生产级。

怎么衡量一个 AI Agent 是不是真的“在生产”？

看三个指标：连续运行天数、人工干预率、异常自愈比例。如果这三项能稳定达标，并纳入日常运维看板，才算是真正跑在生产里，而不只是跑在演示里。

实在Agent