企智社 
我在制造业做数字化服务有七八年。这两年“智能体”从概念变成了客户问得最多的词。但真正落地时，我发现大多数企业对它的期待还停留在“一个更聪明的聊天框”。直到我们帮几家工厂把一个会聊的机器人改造成会执行任务的智能体，我才摸清问题的本质：制造业缺的不是一个更会说话的模型，而是一个能把分散知识变成动作、把动作变成结果的管理工具。下面是我从零开始推进一个制造业智能体项目时的完整复盘，里面没有神奇捷径，只有踩过的坑和重新爬出来的过程。
问题不是“没人懂AI”，而是“知识都在老师傅脑子里”
项目启动的第一天，我们没有写一行代码，而是跟着车间主任走了三圈产线。客户是一家典型的零部件制造企业，有完善的ERP和MES，但工人们遇到异常时最常做的动作还是“打电话给师傅”。比如数控机床报警，操作工拍了张照片发到群里，组长再打电话问工艺员，工艺员远程猜半天，最后还得跑到现场。设备维修手册散落在三个文件夹里，最新版本在谁电脑上没人说得清。老师傅能听声音判断主轴轴承的问题，但他明年就退休了。
我们最初想做“知识库问答智能体”，把文档全部喂进去，让工人随时提问。测试时发现，工人问“这台机怎么老报警”，智能体能洋洋洒洒列出十几种可能。操作工看完更懵了：“我知道这么多原因有啥用？我要的是现在怎么办！”那一刻我意识到，制造业的知识如果不和流程绑定，就只是电子垃圾。工人要的不是“答案”，而是“下一步动作”。所以后来的智能体设计一切围绕“可执行”展开：每一步回答必须对应一个可以点击、确认、触发流程的动作，或者一句话就能复述的处置指令。
让智能体学会“看现场”和“懂流程”，是两个不同的战场
我们当时把项目拆成两条线：一条线是理解物理世界的状态，另一条线是连接业务流程。先讲第一条。工厂里有很多即时信息不在系统里，比如油品颜色、皮带松紧、机器异响。我们给现场管理加了一层“感知描述”入口——工人用手机拍照、录语音，智能体识别后自动分类和抽取关键信息。有个很典型的功能：工人说“液压站有嘶嘶声，压力表波动到7.8附近”，智能体不是简单回复“请检查油路”，而是结合当前设备的保养记录和最近点检数据，判断出这可能是某个滤芯堵塞的前兆，并直接生成一张临时点检任务卡片，推送给对应责任人。这里的核心不是多聪明的模型，而是我们把老师傅的判断逻辑拆成了规则树，嵌进了智能体的工作流里。
第二条线更难。因为业务流程经常是“嘴上有一套，系统另一套”。我们卡在“巡检发现漏油”这个场景里。最初设计智能体自动创建维修工单、通知班长、锁定备件库存，结果上线第二天就被车间抗议了——原来现场跑冒滴漏很常见，如果每个都触发完整流程，维修班一天要接四十个工单，根本干不完。于是我们改成分级处理：智能体先让工人拍一张漏油区域照片，自动识别面积和滴漏频率。小渗漏直接记录到台账，等周末集中处理；中等漏油生成工单并提醒当班维修工；大漏油才触发停机流程并通知值班经理。这个改动看着简单，但实际上是把老师傅脑子里“这事急不急”的判断标准，逐渐“翻译”成了智能体能自己决策的阈值。这才是制造业智能体的真正价值——不是替代人，而是把人的经验变成可以持续迭代的流程。
试运行阶段让人崩溃，也把所有隐藏问题逼了出来
试运行第一天，我的手机被车间群炸了一下午。问题千奇百怪，但归纳起来就三类：不会用、不敢相信、不乐意用。第一类很快解决，我们把界面改成了“问答+按钮”的极简模式，每个回答下面放几个大按钮，比如“执行点检”“生成工单”“联系工艺员”，没有按钮的领域就把答案控制在三句话以内。第二类“不敢相信”更棘手。有一回智能体准确预测了一台空压机的故障，提前两小时报警，结果工人半信半疑，还是按旧习惯汇报了。后来我们发现，问题出在智能体没有显示“推理依据”。于是我们加了一个“依据”折叠区，列出故障概率最高的三个原因以及对应数据，比如“电流曲线上升5%、排气温度偏高2℃”，工人一看就懂了。这件事让我明白，制造业智能体首先要“可解释”，然后才是“可智能”。
最难受的是第三类“不乐意用”。有老师傅明确说：“你给我弄个机器人，是不是想让我走人？”我们后来采取了一个很笨的方法：把所有老师傅的口头禅和经典处置办法整理成“经验卡片”，在智能体回答里标注对应的贡献者姓名。比如当智能体提示“检查叶片是否有积碳”时，页面下方会显示“此建议来源于张师傅的现场处置记录”。没想到这个细节激起了大家的好胜心，老师傅们开始主动修正智能体里的表述，年轻人也愿意给师傅“打下手”，因为智能体能帮他们快速找到师傅说过的好办法。这里我想强调一个容易被忽略的教训：制造业智能体的成败，七成在组织沟通，三成在技术。
从“单点任务”到“跨部门协同”，智能体的边界在哪儿
项目进行到第四周，我们开始让智能体介入跨部门流程。最典型的场景是“工艺变更”。以前工艺部改一个参数，需要发邮件、群里通知、下道工序的人不一定看。现在他们直接在智能体里提交变更申请，系统自动识别受影响的产品批次和设备，并生成每个人的待办确认项。操作工在设备终端上看到“下一批加工温度从180度调到175度，请确认是否已知悉”，点确认之后，智能体才会开放后续的工序放行。这套流程跑通后，我们发现质量部的客诉响应也顺了。因为客诉信息进入系统后，智能体自动关联历史工艺数据和维修记录，生成一份初步原因分析，质量工程师只需要补充判断即可。
但边界也很清晰。智能体做不了真正的设备维修，也做不了判断“这台设备要不要报废”。它只能负责把信息、责任、动作和时间表整理清楚。有一次智能体建议“更换电机轴承”，但维修主管坚决反对，因为他知道这台设备下个月就要大修。这个信息不在系统里，智能体永远想不到。所以我们后来给智能体加了一个“否决权”机制——当人的决策和智能体建议不一致时，系统不会强制阻拦，而是记录理由并在周会上复盘。这既保护了人的判断，又让智能体不断学习新的规则。
很多人问制造业智能体和普通AI助手有什么本质区别。我的理解是：普通助手给你答案，而真正的智能体给你结果。答案只是起点，能不能触发责任、分配任务、追踪闭环，才是制造业关心的重点。
常见问题 FAQ
问：制造业智能体需要多大算力？是必须私有化部署吗？
这不是一个单纯的技术问题，而是一个数据敏感性和响应速度的权衡。如果只是处理内部文档和工艺知识，使用云端API配合私有知识库就足够了。但涉及到设备实时数据的接入，比如通过OPC-UA读取PLC状态，或者需要毫秒级响应的场景，那就必须进行一定程度的本地化部署。我们项目最终采用“混合架构”：核心推理在本地工控机，处理速度和安全性有保障；非敏感的问答走云端大模型，降低成本。但要注意，设备数据一旦出了工厂，即使脱敏，法务那关也很难过。所以我建议企业先梳理哪些数据绝对不出门，再决定部署方式。
问：智能体回答错了怎么办？会不会造成安全事故？
会，而且我们差一点就出事。有次智能体把两种外观相似的润滑油型号搞混了，如果在加注环节执行了错误指令，后果不堪设想。所以我们后来的设计原则是“智能体永远不做不可逆的操作”。所有能上锁的设备，必须在操作前二次验证：要么扫操作工胸牌，要么输入主管授权码。另外，推荐动作必须附带“反向提示”，比如“请确认当前设备处于停机状态，且总阀门已关闭”，哪怕这句话看起来很啰嗦。更重要的是建立反馈闭环：每一条被工人标记为“错误”的回答，都要进入周复盘。制造业容不得“概率正确”，必须做到可追溯、可回滚、可人工接管。
问：打造一个制造业智能体，通常需要多久才能看到效果？
如果只做知识问答，一两个星期就能上线Demo，但那不是智能体，只是文档搜索。真正进入可执行阶段，比如自动生成工单、关联备件库存、触发质检流程，至少要两到三个月时间。关键瓶颈不在模型，而在你已经存在的业务数据是否干净、负责人是否明确、流程是否有断点。我们项目前两周几乎都在梳理工单状态码和异常分类标准。只要这些“地基”能夯实，后面的智能体就像流水线上拧好了所有螺丝的机器，随时可以转起来。建议制造业企业不要一步到位，先从单一车间的一个高频场景（比如设备点检或异常上报）开始，跑通后再复制到其他产线，效果会更稳。
