制造业AI智能体落地：五道门槛与选型复制指南

去年年底参加一场制造业数字化转型的交流会，茶歇时有位汽车零部件厂的IT负责人对我说了句印象很深的话：朋友圈里别人的AI智能体都能写代码、自动做报表了，我们车间里连设备报工还得靠人工录，这差距是不是已经追不上了？我当时没直接回答，因为这个问题背后其实藏着一层更真实的行业状态——AI智能体（AI Agent）这个概念在软件圈确实热了好几年，各种Demo演示一个比一个漂亮，可真正能在制造业车间里持续跑起来、让一线人员愿意天天用的，少之又少。

这篇文章想聊的，就是AI智能体在制造业落地这件事本身。我会从实际项目和选型经验出发，把制造业落地AI智能体绕不过去的难点拆开讲清楚，也会把解决方案商的能力到底该怎么评估、从试点到规模化应该怎么走，一条一条梳理成可操作的方法。不吹概念，不讲宏大叙事，只讲那些在车间、会议室、招标现场真实发生的事。适合制造业的数字化转型负责人、IT与工艺团队，以及所有正在评估AI智能体供应商、准备立项的同行参考。

1. 演示很惊艳，产线很沉默：制造业AI智能体的真实起点

先承认一件事：AI智能体在制造业的热度是真的热。从公开动态看，有大模型厂商直接开源了智能体训练方法，有低代码平台让业务人员拖拽就能搭建智能体工作流，也有垂直厂商推出面向研发和软件质量的代码检视修复智能体，官方宣称缺陷召回率能做到90%以上。这些产品有一个共同点：在演示环境里，效果都非常好。PPT上写着"让每个工厂都有一个智能体"，Demo里AI流畅地回答问题、自动生成报告、输出维修建议，台下观众看得热血沸腾。

但问题恰恰就在这一层。

制造业和互联网是两种完全不同的土壤。互联网领域的智能体，回答错了一个问题，用户刷新一下页面就完了，损失几乎可以忽略。制造业的智能体呢？如果给设备维护人员推荐了一个错误的维修方案，或者给质检员推荐了一个错误的质量判定，后果可能是直接停线、批量报废，甚至出现安全问题。这种容错空间的差异，决定了AI智能体在制造业的落地逻辑不可能照搬互联网的思路。

具体有三大结构性差距，做项目的人越早认清越好。

第一个差距是运行环境。互联网智能体活在云上，算力是弹性的，数据是数字原生的。制造业智能体要面对的，是PLC（可编程逻辑控制器）、SCADA（数据采集与监控系统）、DCS（集散控制系统）、各类传感器网关，以及几十种甚至上百种设备通讯协议。这些系统里有很多是服役了十几二十年的老设备，有的连标准数据接口都不开放，有的数据采集频率以毫秒计，有的以小时计，同一家供应商不同型号的设备通讯协议都可能不兼容。把一个通用智能体框架塞进这种环境，就像把一台精密服务器搬进粉尘车间，设备本身再先进，环境不匹配就跑不起来。

第二个差距是评价体系。互联网产品讲日活、转化率、留存；制造业讲的是OEE（设备综合效率）、良率、一次通过率、平均修复时间、计划外停机时长。评价体系不同，决定了系统优化什么、用什么数据优化、怎么向老板证明价值。很多项目做着做着就散掉了，不是因为技术不行，而是因为上线三个月后，业务负责人问"你给我带来了什么"，技术团队只能拿出准确率指标，双方根本对不上话。

第三个差距是决策责任。互联网智能体的决策损失是几分钱几毛钱的事，制造业智能体的一个建议可能对应几十万的原材料、一整条产线的停产、甚至人员安全。决策责任的不对等，导致制造业用户对AI智能体的信任门槛极高。一套系统哪怕错一次，都可能让整个工厂对它关上大门。

1.1 同一张"智能体"名片，两套不同的生存法则

我常说，互联网智能体和制造业智能体虽然都叫AI Agent，但本质上是两套生存法则。互联网的逻辑是"尽可能自主、快速迭代、错了再改"；制造业的逻辑是"先证明可靠、再谈效率、三思而后行"。

这不是保守，是行业属性决定的。互联网追求的是覆盖广度和响应速度，制造业追求的是过程可控和结果确定。你在互联网产品里可以把新功能灰度给1%的用户，出了问题快速回滚；在工厂里，智能体接入的是真正的物理设备，一条指令发出去就没有"灰度回滚"这回事了。所以在制造业做智能体，指导思想应该是"辅助人，而不是取代人；提建议，而不是做决定；缩小范围，而不是大包大揽"。

1.2 制造业的"自主性悖论"：既要它自主，又要它可控

AI智能体与传统工业软件最大的不同，在于"自主性"。传统软件的逻辑是写死的：如果条件A，就执行动作B。智能体不一样，它可以自己理解目标、拆解任务、调用工具、规划执行路径，甚至根据中间结果调整策略。这种自主性带来了巨大的效率想象空间，但同时也和工业系统的确定性要求产生了根本性的紧张关系——我们既要它足够聪明，能自主处理复杂问题；又要它足够乖，绝对不能越界。

这个"自主性悖论"，是所有落地难点的总根源。也正因为如此，制造业AI智能体的系统架构，从来不是"把大模型接进去就行"，而是要在自主和可控之间找到工业级的平衡点。后面几章讲的难点、方案、路径，本质都是在回答这一个问题。

2. 五道绕不开的落地门槛，每一个都在项目里反复出现

如果把AI智能体在制造业的落地比作修一条路，技术模型是路上的车，数据、场景、知识、可靠性、组织这五样东西就是路基。路基不牢，车再好也跑不起来。下面这五道门槛，我在几乎每个真实项目里都撞到过，一个比一个硬。

2.1 数据问题：不是没有数据，是"没法用"的数据

制造业从来不缺数据，缺的是干净、统一、可用的数据。

一个中等规模的工厂，我见过最典型的数据现状是这样的：MES系统里有生产工单和报工数据，ERP里有物料和计划数据，设备层有PLC里的实时参数，质量系统里有检验数据，此外还有一堆Excel表和纸质巡检单。这些数据分散在不同系统、不同数据库、不同格式里。设备数据的格式千奇百怪，同一家设备供应商不同型号的协议都不一致，更别谈跨品牌统一了。数据的时间粒度也各不相同：设备数据可能是秒级甚至毫秒级，质量数据按批次记录，工单数据按天统计。要把这些数据合并成一个智能体能够理解、调用的统一知识底座，工作量远比训练模型本身要大得多。

这还只是数据"有没有"的问题。更麻烦的是数据质量。制造业现场数据有多脏？设备报警记录里大量重复报警，传感器偶尔出现坏值，操作员手工录入的报工数据经常有空值、错值，甚至时间戳都是乱的。我自己遇到过最夸张的一个案例：某工厂的OEE算出来长期超过100%，原因很简单，设备运行时间的统计口径在三个系统里各不相同，一个把换型时间算进去了，一个没算，第三套系统的口径又是另一套。这种数据基础之上，任何AI智能体的"智能判断"都是沙滩上盖楼——看着挺美，潮水一来就塌了。

很多厂商的套路是先用漂亮的Demo吸引你，合同签完、数据一接，才发现真实数据远没有演示数据那么干净。所以评估解决方案商的时候，请把数据接入和治理能力排在算法能力前面。算法再强，接不上数据、洗不净数据，一切都等于零。

2.2 场景碎片化：处处都能用，处处都难标准化

互联网智能体和制造业智能体的场景逻辑，有一个根本区别：前者可以集中资源打磨一两个超级场景，比如一个客服智能体服务几亿用户；后者面对的是无数个"看起来差不多、但就是不一样"的小场景。

制造业的典型场景有哪些？设备预测性维护、工艺参数优化、质量缺陷根因分析、生产排程优化、供应链协同、设备故障问答、安全巡检、合规文档生成、新员工培训助手……听起来每个都能做，但每个场景背后都是一套完全不同的知识、数据、流程和组织配合方式。更头痛的是，同一个场景在不同工厂里差异也极大。同样是设备维护，注塑机和数控机床的维护逻辑不同，大型流水线和柔性产线的维护逻辑也不同；同样是质量分析，冲压件的缺陷类型和电子元件的缺陷类型完全不搭界。

场景碎片化的直接后果，是难以做出一个"标准品"智能体。每个项目实际都是一个定制项目，定制项目的成本高、周期长、复制性差。这才是AI智能体在制造业规模化落地的真正瓶颈。解决方案商如果说"我们的平台开箱即用，什么场景都能覆盖"，基本可以判断为不了解制造业。真正靠谱的做法是"平台+场景包"的模式：底层是通用的智能体框架和工作流编排工具，上层必须有按行业、按产线类型精雕细琢的场景包。平台解决通用问题，场景包解决行业深度问题，两者缺一不可。

2.3 老师傅的隐性经验，到底能不能教给机器

制造业里最有价值的资产之一，是老师傅的经验。设备发出异常异响，老师傅路过听一耳朵就知道问题大概出在哪个环节；产品质量出现微小波动，老工艺工程师瞄一眼趋势曲线就能判断是哪个参数在漂。这些经验活在老师傅的脑子里，不在任何文档里。

AI智能体要成为真正有用的助手，首先就要把这些隐性知识显性化。这个过程的困难程度，怎么强调都不过分。难点在于，老师傅很多时候不是不想教，是他自己也没法说清楚判断依据。很多专家决策是"模式识别"式的——看到A和B同时出现，脑子里直接跳到结论C，但你要他写出完整的推理规则，他写不出来。就像让一个骑车高手写一本《如何保持平衡》的教程，他可以列出几十条原则，但真正的平衡感永远没法用规则完全表达。

现在行业里常见的做法，是从设备故障记录、维修工单、历史参数、检验报告里提取知识，交给大模型做RAG（检索增强生成），把显性文档喂给智能体。这只能覆盖"已经写在纸面上"的部分，覆盖不了那些"从来没写下来，甚至永远没人写下来"的经验。我见过比较靠谱的实践是双轨并行：高频且有数据支撑的场景，用数据驱动建模，比如基于振动、电流、温度数据做故障预测；低频但决策复杂的场景，用知识图谱加老师傅评审的方式把经验逐步规则化，再让智能体把这些工具串起来。整个过程需要工艺专家、设备专家、数据工程师坐在一起反复磨，没有任何捷径可走。

2.4 工业级可靠性、安全性与实时性，容不下"概率正确"

互联网产品的可靠性标准是99.9%，听起来已经很硬了，但放在制造业，这个级别远远不够。关键产线的控制环节要求的是99.99%甚至更高，因为一次意外宕机的直接和间接损失，可能就是以百万为单位计算的。

AI智能体比传统软件更复杂，也意味着更脆弱。传统工业软件的逻辑是可预判的，只要输入确定，输出必然确定。智能体基于大模型推理，大模型的输出本身带有随机性，再加上工具调用、任务规划的中间环节，整个系统的行为边界很难完全预测。这个"随机性"和工业系统追求的"确定性"之间，存在天然矛盾。

解决这个矛盾，不是靠祈祷大模型永远不犯错，而是要在架构设计上做防护。成熟的工业智能体系统通常有三层保护：第一层，在智能体输出入口设置人工审核或规则引擎校验，只有通过确定性检查的输出才会真正被执行；第二层，权限与沙箱机制，智能体只能调用授权范围内且可回滚的操作，碰不到核心控制系统的红区；第三层，完整日志和审计追溯，一旦出问题，能精确定位到是哪一步决策、哪一次工具调用、谁批准执行的。这些防护机制会明显增加系统复杂度，但对制造业来说是必选项，不是可选项。

此外，还有一个容易被忽略的时效性问题。很多智能体应用部署在云端，数据传到云端走一圈推理再回来，延迟可能达到几百毫秒甚至几秒。用于处理非实时性任务还可以，真的涉及到设备实时纠偏、工艺实时优化，这种延迟就是致命的。所以制造业智能体的部署架构必须提前设计，哪些模块放边缘、哪些放厂内私有化机房、哪些可以走云端，每个场景都要单独论证，不能一把梭。

2.5 组织与人的阻力：决定项目死活的那道软门槛

这一条看起来最"软"，实际上却是很多项目死得最惨的地方。我见过不止一个智能体项目，技术方案没什么大问题，数据基础也说得过去，试点效果也不错，但就是推广不下去。原因不在技术，在人。

一线操作工觉得智能体是来监控自己工作状态的，心理上天然抵触；质量工程师担心智能体会替代自己的岗位，配合度很低；车间主任觉得智能体建议"不接地气"，不符合现场实际情况；IT部门担心数据安全边界；工艺部门怕智能体改变原有话语体系。一套系统在还没真正运行之前，就已经被各方团队用脚投票否决了。

所以制造业AI智能体的落地，本质上是组织变革项目，不是纯技术项目。解决方案商如果没有推动组织变革的意识和能力，或者至少懂得配合甲方做这件事，项目大概率走不到规模化阶段。这里有几条实战经验：项目启动初期就要让一线关键用户深度参与，把他变成"种子用户"，而不是最后才让他当测试员；智能体的定位要讲清楚，它是"顾问"和"辅助工具"，不是"决策者"，关键决策权永远在人类手里；效果要可视化，让一线看到智能体确实能帮他们减少重复劳动、降低犯错率，而不是增加额外工作量。记住一句话：智能体的第一个用户，永远是人。

3. 解决方案商的真功夫，得从四个维度现场拷问

评估解决方案商的能力，不能只看PPT讲得好不好、案例封面漂不漂亮。我的经验是，把评估拆成四个维度，每个维度去现场较真，选型基本不会出大偏差。

3.1 行业Know-How：去车间走一圈，三句话见真章

行业Know-How怎么评估？不需要听冗长的产品介绍，直接问具体问题就行。你的团队里有几位具备十年以上制造业现场经验的人？做过哪些细分行业的真实案例？你的设备健康管理智能体里，故障知识库是从公开文献来的，还是从工厂真实故障记录加老师傅访谈里沉淀的？你的工艺参数优化智能体，能直接对接我们的PLC吗？协议层面怎么解决？数据采集频率能达到多少？

这些问题的答案，基本能帮你判断出对面这个团队是"真下过车间"，还是"在大城市的写字楼里想象车间"。有一个更简单也更好用的检验办法：让对方到你车间里实地走一圈。真懂制造业的人和只会讲通用大模型的顾问，在产线旁边站半个小时就暴露了。懂行的人会问：这套设备的OEE现在多少？六大损失里最大的一项是什么？报工数据是谁录的、什么时间点录的？换型时间是系统自动计算还是人工填的？这些问题才是真正影响智能体落地效果的细节，能问出这些问题的团队，至少说明他理解工厂是怎么运转的。

3.2 数据接入与治理：OT和IT打不通，一切智能都是空谈

前面说过，数据是智能体质量的下限。所以第二个评估重点，直接看数据能力。

具体看三样东西。第一，现场数据接入能力。你的工厂里如果有西门子S7系列、三菱、欧姆龙、罗克韦尔这些主流PLC品牌，对方是否都能接？Modbus、OPC UA、Profinet这些协议是否都能处理？对老设备的串口、485总线有没有解决方案？第二，数据处理能力。脏数据清洗、量纲转换是基本功，关键是时间戳对齐、产品批次对齐、统计口径统一这些细节，能不能拿出一个成熟的方法论。第三，数据资产管理能力。能不能把分散在MES、ERP、SCADA、质量系统里的数据统一建模，形成一个供智能体按需调用的数据服务层，而不是每次做项目都从零开始捞数据。

这里还要特别留意一个点：他是不是把数据存到他的平台里就算完事。如果是，你一定要追问数据主权和后续迁移的可行性，这直接关系到你未来会不会被供应商"绑架"。一个架构设计合理的解决方案，数据应该沉淀在你自己可掌控的数据层里，供应商只是数据的使用者，而不是数据的所有者。

3.3 智能体工程化与工作流编排：不止是接一个大模型API

AI智能体和普通聊天机器人最大的区别，在于工作流。智能体要自己拆解任务、规划步骤、调用工具、执行动作、复盘结果，多智能体之间还能协作。在制造业场景里，这个"工程化"能力体现在几个具体层面。

第一，能否把你的业务SOP转成智能体可执行的流程。以设备点检为例，正常点检、异常上报、维修工单生成、备件查询、维修方案推荐、维修结果归档——这一整条链路，能不能用智能体完整串起来，还是只能做其中某一环的问答？这是"玩具Demo"和"可用系统"之间的分水岭。

第二，是否具备多智能体协作机制。比如设备监控智能体发现异常，自动触发维修知识检索智能体获取方案，再把方案推给人机协同审批智能体，由相关责任人确认后生成工单。这种编排能力决定了系统的智能化上限，而不是简单的单点问答。

第三，是否天然支持"人机协同"的审批模式。制造业不需要一个全自动甩手的智能体，需要的是"智能体提议、人来确认、智能体执行、人来监督"的半自主闭环。系统原生支持这种模式，和后期靠二次开发勉强加出来，效果天差地别。

第四，大模型底座是否可以替换。大模型技术迭代太快，如果解决方案商把应用层和某个模型深度绑定，将来你想升级模型，就得把整个系统重做一遍。好的架构应该是应用层、智能体框架层、模型层三层解耦，模型随时可以替换。这一点，在选型时必须白纸黑字确认。

3.4 运营陪跑体系：交付不是结束，而是开始

制造业AI智能体项目最大的特点，是没有明确的"终点"。模型需要用新数据持续微调，知识库需要随业务变化不断更新，工作流也要跟着组织流程调整。供应商如果交付完就消失，系统最多稳定运行三个月，之后就开始"劣化"，越用越不准。

所以评估供应商时，持续运营能力甚至比首次交付能力更重要。看四件事：第一，有没有本地化实施团队，制造业项目大概率需要现场支持，远程支持在关键时候根本不顶用；第二，有没有建立数据回流和模型持续优化机制，智能体运行中产生的调用日志、用户反馈、纠错信息，会不会自动回流成训练知识，多久更新一次模型，这些要具体问清楚；第三，SLA服务等级协议怎么写，响应时间、问题升级路径、知识库更新频率，都要落实在合同里；第四，客户成功团队懂不懂制造业语言，如果只会讲通用AI概念，连"换型时间""首件检验"这种基本词都要你解释，后面合作会很累。

4. 从POC到规模复制：一条我自己验证过的实施路径

难点和能力框架聊清楚了，落到具体操作。以下这条路径，我至少在四五个制造业项目里走过，每一步都踩过坑，写出来给大家参考。

4.1 第一个场景怎么挑：价值高、风险低、数据ready

制造业AI智能体落地最常犯的错误，是第一个场景选得太大。一上来就想做"全厂级生产决策智能体"，十有八九会翻车。正确的姿势是选一个价值高、风险低、数据基础好的窄场景，先打透。

我一般用四要素框架选场景：

基于这个框架，制造业里比较适合作为首批切入点的场景，通常是这几类：质量缺陷根因分析辅助、设备维修知识问答、工艺参数推荐（人工确认后执行）、设备预测性维护（输出预警建议）。它们的共同特点是：价值可量化，决策权在人手里，数据相对容易获取，而且不涉及直接控制设备。从这些场景做起，技术压力和组织阻力都相对小，也更容易拿到业务部门的信任票。

4.2 搭知识库和编排工作流：让智能体学会"工厂语言"

场景选好之后，就进入最核心的工程环节：搭知识库、编工作流。这一步做得好不好，直接决定智能体是"聪明助手"还是"高级玩具"。这里有三个我反复踩过的坑。

第一个坑，知识库只放文档。正确的做法是把知识结构化，分成设备档案、工艺规范、质量检验标准、故障案例库、维修记录、人员技能档案等不同模块，建立统一的字段规范和标签体系。为什么？因为智能体做检索时，结构化的知识召回准确率远高于非结构化文本。一堆PDF扔进去，看似也能回答，但回答质量忽高忽低，很难压住工业场景的高标准要求。

第二个坑，工作流一上来就设计成全自动化大循环。正确的做法是先设计成人机协同模式。比如设备异常告警触发后，第一步智能体基于故障树和知识库生成候选诊断；第二步把诊断推给设备工程师确认，工程师可以修改或否决；第三步智能体根据确认后的诊断自动生成维修工单和备件需求清单；第四步维修完成后结果回流知识库。每一步都保留人的兜底权限，等系统跑熟了、信任度累积够了，再逐步扩大自动执行的范围。一上来就全自动，出一次错，前面的信任建设就前功尽弃。

第三个坑，不重视反馈闭环。智能体输出对不对，必须设计一个反馈收集机制，每个推荐都让用户评价"有用、没用、修正后的答案是什么"。这些反馈数据是后续模型微调和知识库更新的核心燃料。很多项目忽视了这个环节，导致智能体越用越不贴合现场实际。记住，没有反馈闭环的智能体系统，本质上是单向广播，不是真正的智能。

4.3 试点期怎么评估：别只盯着召回率和准确率

试点阶段怎么评估智能体效果？很多人习惯盯技术指标：答案准确率、召回率、F1分数、推理延迟。这些当然要看，但只看这些远远不够。高技术指标不等于业务可用，这两者之间经常隔着一条巨大的鸿沟。

我建议试点期建三套指标并行评估：

• 技术指标：召回率、准确率、响应时间等。横向参考一下行业里做得较好的产品，比如华为云码道检视修复智能体在代码缺陷场景能做到召回率91.3%，这个水平可以作为技术指标上的参考线。制造业场景虽然场景不同，但至少能判断出"优于行业均值"和"远低于及格线"的差别。
• 使用与信任指标：智能体建议被实际采纳的比例、用户对输出内容的修正率、日活跃用户数、关键用户使用频次。这些指标反映的是"人到底信不信任它"。
• 业务量化指标：设备维护场景看平均修复时间有没有下降、计划外停机时长有没有缩短；质量场景看一次通过率、缺陷漏检率；排程场景看交期达成率。

三套指标缺一个都不完整。技术指标很好但业务指标没变化，说明要么场景选偏了，要么系统根本没被真正用起来；业务指标在变好但使用率很低，就要警惕这是不是试点期团队"人为倾斜"跑出来的好看数字，推广后很可能原形毕露。

试点周期多长合适？我的经验是8到12周。太短，业务指标还没稳定形成对照；太长，资源消耗大，业务侧团队容易疲劳。期间最好每两周做一次复盘会，所有关键用户聚在一起过一遍数据、反馈问题、当场排优先级、快速迭代，不要攒到最后一次性算总账。

4.4 规模复制阶段：标准化是唯一的杠杆

试点成功只是万里长征第一步，真正的挑战在于怎么复制到更多车间、更多产线。这里我有三条建议。

第一，先做"标准化复制包"，再谈复制。试点效果往往是靠试点团队的特殊能力和投入堆出来的。要把试点中的经验沉淀成标准化手册、参数模板、配置清单，把单个场景的智能体应用模板化。很多解决方案商在这一步就暴露了短板：做一个项目靠一个资深团队手搓，交接给新团队就完全跑不动。"把单个项目的成功，抽象成可复制的产品"，是衡量团队成熟度的关键标志。

第二，按"场景乘以产线类型"的矩阵规划扩张路线。同一家工厂里，注塑车间的质量场景和冲压车间的质量场景，看起来都是质量，但数据、知识、工艺、流程完全不同，别指望一个通用智能体通吃。稳妥的节奏应当是一个场景在一个产线类型上打透，验证完标准化程度，再横向挪到下一个产线类型。一次最多推进两到三个新场景，留足组织适配的时间，避免业务团队消化不了。

第三，组织配套必须跟上。每推进一个场景，都要明确业务侧有负责人、IT侧有接口人。同时设立一个AI运营岗，这个人可以是厂内员工，也可以由供应商派驻，专职负责日常维护知识库、监控智能体效果、收集用户反馈、推进迭代。没有这个角色，任何智能体系统用三个月都会开始"劣化"——知识库陈旧、模型漂移、用户信任流失，最终还是逃不掉被弃用的结局。

5. 选型与签约的实务细节：合同里写清楚，后面少吵十次架

最后聊点实际的商务层面内容。选型、签约阶段看起来跟"技术落地"关系不大，但合同条款和合作模式，往往决定了项目后续的生死。这些话我不太见别人系统性讲，今天一起说了。

5.1 自建、外购还是混合：先判断自己站在哪

很多制造企业一上来就问"我们要不要自建智能体平台"。我的回答通常是：先别问要不要，先看你站在哪个位置。不同基础的企业，正确路径完全不同，我按三类情况给建议。

第一类，数字化基础薄弱，没有统一数据平台，数据质量也比较低。这种情况建议不要自建，应该优先找能做数据治理加场景落地的解决方案商。自建的前提是技术栈和数据基建到位，基础没有，自建就是把坑越挖越深。

第二类，已有较好的数据中台和成建制的IT团队。这种情况适合自建一部分加外购工具链的混合路线。外购智能体框架、大模型底座、工作流编排工具，自建上层场景应用。这种模式下，解决方案商的核心价值在于场景设计、知识库构建和工艺理解，而不是卖一个黑盒系统给你。

第三类，细分行业内已有成熟的垂直智能体产品。比如面向代码质量的检视修复智能体、面向特定设备品牌的预测维护智能体，这类产品可以直接采购。但要用试点的态度对待它，先在一个场景一个车间验证它跟你的产线是否真的适配，不要被Demo效果冲昏头直接全厂铺开。

5.2 合同里的三个关键条款：数据、模型、效果指标

签合同的时候，有三组条款最容易出问题，处理不好后面十次吵架都解决不了。

第一组是数据归属权。必须写明工厂数据归企业所有，解决方案商不能拿你的生产数据去做其他项目的训练或模型深化，除非你另行签署明确的数据授权协议，而且授权范围要写清楚。这个条款在AI时代比在传统软件时代重要得多，因为数据就是训练AI的材料，你不想让自家数据变成竞争对手家智能体的养料吧？

第二组是模型可替换性。上面讲过，好的架构应该模型层解耦。合同里要写明，大模型底座允许企业后续替换，供应商不得用商业条款锁定模型提供商。否则半年后你有更合适的模型想切换，却发现合同里写死了只能用某一家，整个系统都得推翻重来。

第三组是效果指标怎么写。我强烈建议写成"业务效果+技术效果"双指标。技术指标容易调口径，"准确率达到90%"这种承诺含金量有限；业务指标相对不好糊弄，比如"试点车间计划外停机周时长相对基线下降15%""智能体回答采纳率达到70%以上"。写业务指标的时候，记得把计算口径和数据来源也一并写清楚，防止验收时各说各话。

5.3 一轮现场实战考核，比十份案例集都有用

我的最后一条实操建议，是无论如何都要给候选供应商安排一轮现场实战考核。

形式是给对方一小批真实但已脱敏的数据，限定一到两周，交付一个可运行的最小原型，基于你们的真实场景出一版能跑的通Demo。制造业场景的复杂度只有真实数据才能检验，大家同样说"我能做设备预测维护"，给真实数据和给公开数据集做出来的结果，差别天壤之别。

如果商务流程上不方便安排完整原型，也可以压缩成一个"技术验证日"：让供应商工程师带着笔记本到你的测试环境，现场接入一个数据源，现场做一个问答型智能体，现场调通。这一个动作就能当场筛掉一批"只会放录像"的厂商。我自己的经验是，真正有实力的解决方案商接到这种验证要求通常是欢迎的，因为产品经得起现场看；反而那些靠包装撑门面的厂商，一听要现场实测，各种推托理由就来了。这个信号本身，就比一百页PPT都有参考价值。

最后说一点个人体会。AI智能体在制造业的落地，与其说是个技术命题，不如说是个"技术加业务加组织"的系统工程。技术难度确实存在，但更大的难度在于怎样把一个技术的可能性，变成一线工人、工艺工程师、车间主任都愿意接纳、愿意日常使用的工具。不要再问"AI智能体能不能落地制造业"这类问题了——答案是可以，但它大概率不会以你设想中"全自动无所不能"的形态出现，而是以"边界清晰、需要人确认、隐藏在业务流程里"的智能助手的形态出现。那些在制造业里真正活下来的项目，基本都长这样。想明白这一点，再回头去看解决方案商，很多疑问都会迎刃而解。