前几天和一个做汽车零部件生产的客户聊AI智能体，对方上来就说：“我们也想搞一套智能体，能不能让车间主任直接问一句，就知道今天哪个订单要延期？”我说能，但接下来一个问题把我问住了：“你准备拿哪台设备的OEE数据当判断依据？”他说还没想好。这个场景很典型，制造业想用AI智能体，但到底拿它解决什么问题、数据从哪来、结果错了谁负责，多数人并没有想清楚。把通用Agent套到工厂场景里，不是“换个行业知识包”那么轻松。这篇文章就结合我这些年在一线跑项目的所见所闻，聊聊AI智能体在制造业落地的难点，以及什么样的解决方案商，才有能力真正把这件事做透。

1. 制造业引入AI智能体：先搞清楚“要的是什么”

1.1 对话机器人、RPA和智能体到底差在哪

很多制造业客户来谈智能体，我第一件事是把概念掰开。目前容易被混淆的有三类：对话机器人、RPA和AI智能体。对话机器人基于知识库和检索，你问它答，不会主动做事，适合查个制度、问个流程；RPA按脚本执行固定流程，比如自动录入工单、抓取系统数据，稳定但死板，流程一变就废；AI智能体则是在理解任务的基础上做规划、调用工具、执行动作，并根据反馈修正，具备目标导向和一定自主性。

用一个制造场景来说明：设备报警了，对话机器人会告诉你“查报警手册第12条”；RPA会把报警信息抓取后记录到Excel；智能体会结合设备历史数据和当前工艺参数，推理出可能的异常原因，并调用工单系统给出排修建议、通知对应工程师。后面这种才是企业真正想要的，但难度也完全不同。我见过太多把智能体做成“语音播报知识库”的项目，上线半年没人用，原因就是它没有参与业务流程，只给了一个“更聪明的搜索引擎”。

要落地，先得把目标定义为“一个会干活、能担责的数字员工”，而不是“会聊天的大脑”。

1.2 制造业里真正有回报的场景长什么样

聊完概念，就要看场景。按我这几年的观察，制造业智能体的高价值场景都有共同特征：业务目标清晰、数据可获取、执行动作明确、结果能闭环。

• 工艺参数寻优：智能体根据原料批次、机台状态、质量反馈，推荐下一批的注塑温度、压力、保压时间。这类场景在注塑、冲压、热处理环节都很有效。
• 设备预测性维护：智能体融合振动、温度、电流等时序信号，做异常识别和剩余寿命预测，再自动生成维修工单。
• 供应链异常处置：智能体盯采购订单、库存、交期，发现异常主动模拟替代方案，比如切换供应商或调整排产。
• 质量归因：当不良率超标，智能体自动关联批次、设备、刀具、操作员工等维度，输出最可能的根因排序。

这些场景有一个共同特点：它们都是“决策密集型”业务——过去靠老法师拍脑袋，现在可以把经验模型化、流程化。相反，如果某个场景只是“查数据、看报表”，那不要上智能体，上一套BI就够。

1.3 流程型工厂和离散型工厂，落地难度差距很大

制造业内部差异极大，我通常把产线分为两类来看。流程型制造，比如化工、钢铁、制药，物料连续流动，温度压力流量传感器完备，生产节奏稳定，本质上是个“连续系统”，智能体容易找到规律，数据采集也相对规范。离散型制造，比如汽车零部件、3C电子，物料要经过多道工序，批次混杂、返工频繁，现场信息靠人工报工，设备新旧品牌不一，数据链条经常断。

在离散型车间做智能体，数据治理的工作量往往占整个项目80%以上。方案商如果说“我们有通用工业智能体平台”，却不先问你是流程型还是离散型，这种话要打个问号。不同行业的生产逻辑都不一样，不可能一套配置打天下。

2. 车间级落地会迎面撞上的五大真实阻力

2.1 数据问题比“脏乱差”更麻烦：缺失、错位、假数据

常听到“制造业数据底子差”，但实际接触下来，问题主要不是脏，而是三种更隐蔽的情况。一是缺失，很多关键工艺参数没有在线采集，老师傅靠经验看火候，设备没有联网，记录靠纸本；二是错位，MES里的工单时间和PLC事件时间没有统一基准，甚至同一个产品在不同系统里的批次号对不上；三是假数据，“假”不一定有人故意造假，而是现场报工的工人会填不准确的数字，比如为了赶产量提前报工，数据表面上漂漂亮亮，实际上和真实物理过程对不齐。

这些情况让智能体的“输入”就不可靠。我的建议是，项目启动前必须做数据可用性盘点：有没有、准不准、通不通、能不能按时更新，四关都过了再谈建模。否则智能体推理得再漂亮，车间主任也不敢照着执行——一次错误判断就足以摧毁信任。

2.2 老系统的API、网段隔离，集成成本超出预想

第二个阻力来自系统集成。很多工厂的产线设备是十年前的PLC，跑着OPC DA协议，车间局域网和办公网物理隔离，设备数据出不了厂区。有些老MES是单机版，连文档都没有，更别提API。

如果方案商只懂云端API调用，到现场会发现连数据都取不出来。合理做法是部署边缘网关，在车间局域网内做协议解析、数据清洗，再把脱敏后的结果通过单向网闸送到服务器。这一套集成工作既考验工控经验，也考验对安全规范的敬畏。我在项目里吃过亏，原以为设备有OPC UA接口，结果到了现场发现只开放了MODBUS，而且寄存器地址表缺失一半，最后靠抓协议报文反推，整整多花了三周。

2.3 操作工、老师傅的信任问题不是培训能解决的

智能体推下去，第一个阻力往往不是技术，是人。车间老师傅有几十年经验，你让他听一个“算法”的？表面上他点头，实际他敢不敢按智能体建议调参数？很难。

我见过一个调试点：智能体根据数据判断某台注塑机的保压压力需要上调8%，但老师傅认为“这种材料不能这么调”。两边争执，最后虽让老师傅主要做判断，但智能体现在已经根据反馈纠正了置信度。这给我们一个教训：智能体在车间不是“取代经验”，而是“和老师傅对齐经验”。落地时要有机制让它先当徒弟，建议只做参考，师傅确认后才执行；经过一段时间积累，再把经过验证的高置信度建议升级为自动执行。人机权限的动态调整，比算法准确率更决定成败。

2.4 安全责任、兜底机制和权限边界

制造业不像互联网，智能体犯错的代价可能是停机、报废甚至安全事故。这里说的安全不只是网络安全，还有“决策安全”。

我们在设计系统时借鉴了L1至L5的智能体分级思路：L1是纯建议，人看人批；L2是建议加默认选项；L3是在限定参数域内自动执行；L4是跨系统自动执行并事后报告；L5几乎自主应对未知场景。制造业目前绝大多数场景应该卡在L1到L3，设备联锁、急停回路、安全工艺边界绝不能交给模型自由发挥。

每个智能体动作都要有“权限清单”，比如“允许调整温度范围上下限是多少”“哪些操作必须二次确认”“一旦结果异常，降级到人工的规则是什么”。更关键的是，异常兜底流程要演练，不能只在PPT里写。之前有方案商做过智能体，但现场操作员完全不知道失控时该按哪个按钮恢复手动，这是非常危险的。

2.5 ROI测算在制造业很难：效果滞后且收益分散

最后是钱的问题。智能体项目不像采购一台机床，买了就能算产能提升。它的收益往往分散在质量、交期、能耗、人效几条线上，且需要经过几个月的运行才显现。比如一个排产优化智能体，可能让某条产线的换型次数从12次降到9次，但折算成金额时，财务会追问“另外3次为什么不能完全消除”，这种问题很难回答。

方案商这时候不能只谈技术，要有耐心帮客户算清账：列出优化前后的关键指标基线，约定评估周期，用统计方法排除干扰因素。如果方案商连一套ROI模型都给不出来，客户很难为“可能性”买单，项目连立项都过不了。这也是为什么制造业智能体的销售周期那么长，不是销售能力问题，是信任建立需要过程。

3. 解决方案商能力拆解：从做PPT到交付产线

3.1 有没有垂直行业know-how，是分水岭

聊完阻力，再回到标题里“解决方案商能力”这部分。我见过太多通用型技术公司冲进制造业，擅长演示“智能体写周报、做会议纪要”，一谈到工艺参数寻优就露馅。

垂直行业know-how不是听说过几个专业词，而是能把老师傅的经验拆成规则、变量、边界。比如做压铸质量预测，方案商要懂模具温度、浇注速度、真空度怎么影响气孔率，才能设计出有意义的数据特征。现在行业里流行“工作流搭建”，本质就是把这种经验流程化：把“如果铸件气孔率超标，先查模具温度，再查脱模剂喷涂量，然后对比历史批次”变成智能体可执行的决策链路。有行业经验的方案商，才能搭出这样的工作流；没有的，只能搭出通用客服问答流。

3.2 技术栈的成色：数据、模型、工程化、集成缺一不可

评估方案商的技术能力，不能只看大模型效果。我习惯把技术栈拆成四层：

• 数据层：能不能接各种工业协议，能不能做时序对齐、数据补全。
• 模型层：能不能让通用大模型结合企业私有知识而不“胡编”，这一点很考验微调和检索增强设计。
• 工程层：智能体工作流健不健壮，工具调用失败怎么重试，并发请求怎么处理。
• 集成层：能不能和一线的MES、ERP、工单系统顺畅打通，而不是让对方改造接口。

很多智能体服务商在第一层和第四层特别弱。他们擅长做演示Demo时连的是官方API，一到客户现场面对杂牌PLC和旧数据库就抓瞎。所以我会建议客户要求方案商提供“同类行业、同类型设备”的落地案例，并找该案例的项目经理做一次电话访谈，问清楚“数据接入用了多久”“哪块超出工时”。

3.3 实施团队不是算法工程师，而是复合型团队

还有很重要的点：智能体项目成功与否，和团队配置强相关。方案商至少要有四类人：懂业务的行业顾问、懂数据的数据工程师、懂工程化交付的软件工程师、懂现场协调的实施经理。只有算法工程师，做科研项目可以，做交付不行。因为智能体现场上线调试，需要有人能跟班生产，和老师傅讨论工艺逻辑，这一点程序员很难短时间补齐。

我在合作过的团队中发现一个规律：配置“业务分析师+实施工程师”全程驻场的项目，成功率明显高于纯远程交付。智能体需要不断看现场反馈来调优，没有驻场工程师，问题响应拖一周，热乎劲就凉了。所以合同里应该写清楚驻场人天，这也是一笔必须花的钱。

3.4 安全分级与多智能体协同能力：评估方案商的新维度

前面提到分级安全，这里想单独把“方案商是否把分级想清楚”作为选型指标。好的方案商在项目启动时就应该给出一张“智能体权限分级表”，明确哪些环节由人决策、哪些由智能体决策、哪些是混合决策，并且说明每种分级对应的安全测试方案。如果方案商只会说“我们的智能体很聪明”，但要什么权限、怎么兜底一概没想过，这项目最好别签。

另外，方案商如果还具备多智能体协同能力，在制造业会更有潜力。现在工厂正在出现“设备智能体+排产智能体+质量智能体”的格局，它们之间需要通信和冲突仲裁。比如排产智能体为了赶交期想压缩某种工艺时间，质量智能体却提示会提升不良率，这时系统怎么协商？有没有优先级机制？这需要一套架构设计，不是两个模型拼在一起就能干活的。评估时可以问方案商对多智能体协同是否有成熟方案，哪怕还没有项目落地，至少要有清晰思路。

4. 选型评估的一线方法：别被“大而全”忽悠

4.1 案例考察：去车间看数据流，而不是发布会看Demo

制造业客户选型时最容易被发布会上的Demo打动。画面很炫，识别很准，但大家要明白：Demo是精心准备过的“考试”，真实场景是“开卷但不知道考题”。我建议客户一定要去两个地方看案例。

一是看已经上线的车间现场，让实施负责人带路，问“智能体从哪个系统取数？多久更新一次？模型多久重训？出过错没有？出错之后怎么兜底？”这些细节最能反映真伪。二是看对方的研发和测试环境，了解一下他们有没有工业现场的设备模拟器、有没有历史故障数据集，而不是只有一个空荡荡的大模型API调用界面。有几个项目我就靠这一步避了雷——其中一家号称“服务过某大型车企”，结果对方连OPC UA为何物都答不上来，考察回来后客户果断换了一家。

4.2 用“21项核心商业诊断”思路拆解需求

选型前，客户和方案商最好一起做一轮业务诊断。最近“构建懂生意的AI智能体：21项核心商业诊断”这个说法很流行，我觉得方法值得借鉴，就是不要先问“哪个系统用什么模型”，而是先围绕企业的关键经营指标进行扫描。在制造业，我建议优先诊断七个维度：

• 质量：一次合格率、返修率、客户投诉成本
• 成本：带料损耗、能耗单耗、备件库存资金
• 交付：订单按期交付率、换型时间、在制品积压
• 设备：OEE、平均故障间隔、故障修复时间
• 安全：隐患闭环周期、违规操作次数
• 效率：人均产出、自动化覆盖率
• 异常响应：从异常发生到处置完成的平均时间

每个维度打分后，再圈出两三个“痛点最集中、数据相对可用、一旦改善收益明显”的场景，作为智能体试点。这样做出的方案是“从业务长出来的”，而不是“从模型库里挑的”。方案商如果一上来就给你推“智能体平台”，却不跟你做业务诊断，基本可以判断他在卖货，而不是解决你的问题。

4.3 用PoC验证三个关键指标

圈定场景后，先做小范围试点。我建议PoC只盯三个指标。

一是决策准确率或建议采纳率。这个指标看智能体给出的建议是否靠谱，但注意“准确”不等于“让老师傅点头”，还要看它对异常边界是否敏感。二是数据接入周期。从项目启动到第一版可以试运行，中间数据链路是否打通。如果连这个都拖三个月，说明工程能力有问题。三是失控恢复时间。人为制造一次异常情况，看智能体怎么应对，运维人员能否快速干预。这个指标直接反映兜底设计水平。

PoC设计还有两个原则：选真实场景，别选理想场景；设定量化通过标准，别用“效果不错”这种话糊弄。比如我们可以约定“建议采纳率≥70%，且不出现安全边界违规，即为通过”。这样双方都有清晰预期。

4.4 合同条款里的坑：SLA、数据资产与迭代费用

等到签约阶段，商务条款里还有几个容易忽略的坑。第一是SLA，智能体系统能否正常运行，要写清楚可用性指标和响应恢复时间，比如“月度可用性≥99%，故障响应≤4小时”。第二是数据资产归属，智能体在运行中积累的标注数据、调优日志、工艺配方数据，到底属于谁，必须事先约定，否则后期更换方案商时会被卡住。第三是迭代费用，智能体不是一次性交付，模型会漂移、工艺会变化，到底一年包含多少次迭代，超出如何计费，要白纸黑字写清楚。我朋友签过一个合同，只谈了开发费，没谈迭代费，结果半年后每次调优都被按“定制开发”收费，成本翻倍，这就是大家常说的“智能体是服务不是项目”的深意。

5. 从单点试点到多智能体协同：我见到的几条实践路径

5.1 失败项目的共同点：把智能体当项目做，而不是当能力做

我复盘过几个制造业智能体项目，发现它们失败原因惊人的一致：上线那一刻就是衰落的开始。项目组撤场后，没有专人维护数据管道和提示词，模型半年不更新，准确率越来越差，一线操作员发现它“只会说废话”，就再也不用了。

智能体在制造业的本质是一个持续运营的数字员工。你需要有人像带徒弟一样持续给它喂数据、校准规则、更新知识库。国内很多企业轻视了这一点，觉得买套软件就完了。如果你所在企业准备上智能体，建议拨一个“智能体运营”岗位，哪怕由IT兼着，也要有明确预算和责任。这个投入，至少要在项目预算里占20%到30%。

5.2 作为方案商，我推荐补的四个能力

如果你也是做解决方案的，想让制造业客户认可你的能力，我的建议是往四个方向补。

一是现场工程师梯队。懂算法的年轻人很多，能蹲车间和老师傅聊清楚工艺的人才稀缺，这种能力很难短期招聘，要靠长期培养。二是边缘部署标准化。把边缘网关、数据采集、安全隔离做成标准交付件，项目毛利和施工周期都会大幅改善。三是行业知识库封装。把某个细分行业，哪怕只是注塑行业的工艺经验、故障案例、常见误区，沉淀成结构化知识，让模型基于“自家词典”推理，而不是靠通用常识胡编。四是协同机制设计。提前思考设备、计划、质量等多个智能体在一条产线上怎么协作，冲突怎么调解。这套架构能力，会在两三年后成为重要门槛。

5.3 下一步可以尝试的事

最后说两个可以马上做的事。一个是用智能体辅助开发提效。我们团队现在内部就用类似“多智能体协作开发规范”的玩法，让一个智能体负责写代码，另一个智能体负责审查规范，第三个负责生成测试用例，效率提升明显。制造业智能体的交付压力大，这种方法值得方案商采用。另一个是关注AI行业公开的一些智能体训练新方法，比如DeepSeek对外发布的智能体训练新方法，强调整体流程设计，对于制造业多步推理场景也有参考价值。但我始终认为，方法再先进，落到工厂里，还是要回归到“数据可靠、边界清楚、人机互信”三个基本功，这些基本功没有人替你补齐，只有你自己一点点磨。

做制造业AI智能体这些年，我最大的感受是：它不像互联网产品，可以靠一个酷炫功能快速起量，它更像是在工厂里慢慢养一个能干的助手。谁先接受这个“慢”，谁反而能走得更远。