我在一家做制造业 AI PoC 的公司，主要负责 BSP Agent 的开发。入行两年，打交道的都是工厂客户。这两年里我被客户问得最多的问题，不是技术问题，而是钱的问题：“你们做一个 Agent 多少钱？”

一开始我觉得这问题挺正常，采购嘛，总要有个价。但经历了一个又一个项目从 PoC 演示到落地卡住的全过程之后，我越来越确信：这个问题本身就是错的，而且它背后藏着大多数制造业 AI 项目死在 PoC 之后的原因。

这篇就聊聊我作为一线工程师的观察，都是自己的亲身感受。

PoC 是 Agent 落地最大的滤镜

先说一个我这行心照不宣的事实：PoC 演示和真实落地之间，隔着一条数据链。

PoC 怎么做？客户给一批整理好的设备手册、几十条清洗过的维修记录，我们喂进去，调一调，演示的时候 Agent 对答如流，老板看了很满意。但只要一上真环境，问题就一个接一个冒出来：

它要回答设备问题，需要完整的设备资料——可工厂的手册散落在一堆 PDF、Excel 和老师傅的电脑里，型号还对不上；

它要参考历史维修经验，需要维修工单——可工单上写的都是"已处理""正常"这种废话，真正值钱的过程记录在老班长脑子里；

它要判断能不能停机、备件有没有货，就得对接 MES 和 ERP——外采的系统开不开接口？自研的系统有没有人能给 Agent 封一套查询层？车间的网络环境让不让这么调？

看到没有，到这里一个字的 prompt 都还没写，工作量已经非常可观了。我自己的粗估是：一个能真正在厂里干活的 Agent，本体开发只占两三成，剩下七八成是数据、接口、权限这些看不见的基建。

所以"一个设备维修 Agent 多少钱"没有答案。只会读手册答问题的 Agent，和能查工单、判备件、联动 MES、每步留痕的 Agent，是两个物种。按"个"报价的，要么不懂行，要么赌你不懂行。PoC 恰恰是这个误会最大的放大器——它用喂好的干净数据，给老板演了一个数据链不存在的幻觉。

比数据更要命的，是业务根本"冻"不住

数据问题还能靠堆人堆时间解决，第二个问题更本质。

我们做交付，验收要求把需求冻结成确定的流程。但产线上的真实情况是流动的。同样一个设备报警，这批料和上批料不一样、白班和夜班不一样、赶交付期和正常排产不一样，处理方式本来就该不一样。有经验的工艺工程师靠的是判断，而流程只能覆盖判断被穷举完的那部分。

结果就是很多项目验收时跑得很好，上线一两个月后使用率掉下来。一线师傅的反馈出奇一致："真的情况比你们的流程复杂。"这不是谁做错了，而是一个结构性矛盾：客户想要的是一个灵活的判断者，而交付出来的只能是一条刚性的流水线。

更别说工厂的 SOP 自己也在变。工艺在改进、产线在改造、质量体系在更新，流程就得跟着改。而定制交付的东西，改一次就是一次成本。上一代进厂的自动化系统和低代码平台，很多就倒在同一个地方——技术没毛病，毛病在于它们假设"业务可以被固化"，而产线上大量有价值的环节恰恰固化不了。Agent 在柔性理解上比它们强得多，但交付思路不换，结局不会有什么不同。

我自己现在的做法是，画方案时先把流程分成两类：**涉及安全联锁、质量判定、追溯合规的部分，越刚性越好，必须留人工确认；涉及异常分析、经验查询、沟通判断的部分，才交给模型柔性处理。**什么都想固化，或者什么都让模型自由发挥，都会翻车——在制造业，翻车的代价可比电商大得多。

老师傅退休那天，Agent 才开始贬值

第三个观察，制造业的朋友应该最有体感：工厂最怕的不是没有系统，是经验在人脑里。

一个只做一次性交付的 Agent，上线那天就是它最聪明的那天，之后只会变差。业务在变，底层模型在升级，一个不迭代的系统处在一直变化的环境里，表现不漂移才怪。我们甚至遇到过底层模型版本更新后，原来调好的环节莫名其妙变差的情况——为了补旧模型短板写的那些补丁，新模型来了反而成了拖累。

那怎么让 Agent 越用越聪明？我的理解是，真正值钱的不是 Agent，而是让它能变聪明的那套机制：

每一次处理都留痕——报警怎么判的、依据的哪份资料、哪步判错了、班长接手后是怎么改的；

定期拿这些记录做评估，把老师傅的正确做法沉淀下来；

再用这些数据去优化提示词、调整流程，甚至未来做训练。

这件事在制造业有额外的意义：这些记录本质上是在把老师傅脑子里几十年的判断，变成公司能留下来的资产。老师傅会退休，但"什么情况下他是怎么处理的"这些数据留下了。模型谁都能调，框架谁都能抄，唯独这份数据抄不走。

说句实话，这套东西说起来容易做起来难。评估标准谁定、线上表现怎么监测，我也在摸索。但方向我确信：从项目第一天就把留痕和评估埋进去，而不是等出了问题再补。

所以工厂该从哪开始？我的答案可能反常识

按常理，做 AI 转型应该先规划、再立项、找供应商开发。但基于上面这些，我越来越倾向于一条反常识的路：先别急着做"公司的 Agent"，先让每个工程师有自己的 Agent。

厂里大量的提效需求，其实是低频、低风险、变化快的——查一份标准、改一版报告、翻译一份外文手册、整理会议纪要。这类需求不值得立项，但特别消耗人。如果工程师自己会用 Agent，搭个小工具就解决了，成本低，还贴合自己的习惯。这部分加起来，很可能就是一家工厂日常提效需求的大头。

等大家真用起来，攒下几个月真实的使用记录，有价值的事情就发生了：**哪些需求是高频的、共性的、值得公司级投入的，数据自己会说话。**这时候再做统一知识库、打通 MES 和 ERP、收权限、上监控，每一步都踩在被验证过的需求上，而不是踩在汇报 PPT 的想象上。

传统的工业软件思路是自上而下：把流程定成系统，让人适应系统。Agent 这波，我更相信反过来：先让人具备用 AI 改造工作的能力，再让有价值的流程从日常使用里长出来。

最后，说给同行

写这些不是想说定制开发不能做——我自己就是干这个的。我想说的是，这行的门槛从来不在"会不会调模型"，而在能不能看清一家工厂的业务：哪些数据是烂的、哪些流程是活的、哪些环节碰了安全就不能乱来。

所以如果你也是刚入行的 Agent 工程师，我的经验是：接到需求先别问要几个 Agent，先问四件事——数据在哪？干不干净？系统有没有接口？规则冲突了谁说了算？

问得出这四个问题，才算真正开始干活。