过去一年我泡在制造业客户现场一个很深的感受是大模型Demo人人会做智能体在PPT里能解决一切问题可真要让它在车间“上岗”十个项目有八个卡在同一处——不是模型不够聪明而是企业根本没给它准备好工位。那份制造业实践白皮书里有一句话特别扎心智能体的效果上限往往在正式开发之前就已经被数据质量和组织流程决定了。这篇文章我想把智能体在制造业落地这条路上真正会遇到的事拆开讲从环境差异、试点场景选择到知识库搭建、工作流编排、内网部署再到上岗之后的考核机制。服务对象是制造业企业的数字化负责人、IT工程师还有那些正准备把Agent推进生产环境的AI应用开发者。我会结合白皮书里的核心观点加上我在项目里实际踩过的坑尽量让每个环节都能直接落地参考。1. 制造业智能体和互联网Agent开局思路就不一样1.1 给车间用和给办公室用是两个物种我见过不少团队拿互联网Agent的思路直接套到制造业结果惨不忍睹。互联网Agent的用户是C端消费者问错一次顶多被吐槽几句但制造业智能体的用户是设备维护师傅、产线班组长、工艺工程师他们问的是“这台机床报AL-217报警按哪个流程处理”回答错了可能导致停线甚至引发安全事故。两者对答案的预期也完全不同。互联网Agent追求“自然、流畅、像人”制造业智能体第一条要求是“可追溯、有依据”。老师傅看到答案后会追问一句“你凭什么是这个结论”所以制造业Agent的回复必须带知识来源编号、对应手册章节、历史故障单号。这个差异从第一天就会影响产品设计——不是一个Prompt能解决的。1.2 制造业的四个硬约束白皮书分析了大量案例后总结了几个制造业环境独有的约束条件我在项目里逐一验证过完全成立数据不出内网。工艺参数、产品BOM、设备维修记录都属于核心资产。绝大多数制造企业接受不了把数据传到外部API去处理这直接决定了模型部署和知识库建设方案。准确率要求远高于常识场景。互联网场景里70分答案可接受制造业里90分都不能放行。因为错误信息的边际成本极高一次误判可能导致批量返工。存量系统集成困难。相当多工厂的核心系统是十几年前上的MES、ERP、PLM各管一摊接口文档残缺数据库表结构只有老开发心里清楚。智能体要“办事”第一步就是和这些老古董打交道。组织内缺少AI人才。制造业IT团队通常擅长网络、服务器和业务系统运维对Prompt工程、RAG调优、模型评测这些事普遍陌生。这意味着技术方案必须考虑“普通人能不能维护”不能搞成只有算法工程师能碰的科研项目。这四个约束加在一起决定了制造业智能体项目本质上是一个“数据工程 系统集成 组织变革”项目模型只是其中一小块。2. 试点选型让智能体先干一件能干好的事2.1 四把尺子筛掉99%的伪需求制造业里能想到的Agent场景非常多设备运维问答、排产优化建议、工艺参数推荐、销售报价辅助、HR入职答疑、质量缺陷分析……如果全都想做项目必死。我建议用四把尺子去筛每把都过得了再谈试点需求频次是不是高频重复性提问低频场景不值得第一轮做。数据密度有没有足够的历史数据和文档支撑没数据RAG就是无米之炊。容错空间答错了的代价可控吗是否需要人在回路兜底闭环难度从提问到拿到结果涉及多少个系统涉及越少越容易先跑通。用这四把尺子一筛很多热门场景马上现原形。2.2 几个典型候选场景的对比我把制造企业最常提的几个场景摆在一起做过评估结果非常清晰候选场景需求频次数据密度容错空间闭环难度是否适合首期设备运维问答高高中可复核低查资料给答案强烈推荐HR制度问答高中高低推荐销售报价辅助中中中高多系统联动暂缓排产优化建议中低低高不推荐智能质检高高视觉低中需模型训练暂缓这张表我建议每个企业根据自己的数据现状重新填一遍因为同样是“设备运维”有的工厂设备台账电子化程度很高有的还是纸质记录结论完全不同。2.3 设备运维问答为什么是最佳突破口我们在多个现场最终都把首个智能体落在“设备运维知识问答”上。原因很朴素它有明确的知识边界答错了有人复核失败了不会影响生产。以一家汽车零部件工厂为例现场设备种类有上百种操作手册、故障代码表、保养计划、历史维修案例加起来有几千份文档。新员工培训期要六个月才能独立处理常见故障老师傅经验全在脑子里。智能体把知识库建起来之后新员工遇到报警先问Agent拿到处理步骤和对应手册条文再找老师傅确认。这个场景里Agent不是取代老师傅而是把老师傅的经验“外挂”到了每个工位上。一个值得注意的细节白皮书里提到运维问答类Agent的成功指标不是“回答得有多聪明”而是“能不能把答案稳定地锚定在正确文档上”。这意味着在场景设计阶段就要规划好“标准答案从哪来、谁审核、怎么更新”而不是先把机器人挂上线再说。3. 知识库这关过不去其他都是空中楼阁3.1 制造业的存量文档是RAG工程的噩梦如果说互联网公司的RAG面对的是结构良好的网页和Markdown文档制造业RAG面对的则是扫描版PDF图纸、繁体中文操作手册、Excel参数表、老师傅口述整理的txt笔记。我见过最典型的翻车现场某团队拿通用工具把一本200页的设备手册按固定token长度硬切手册里关键的操作步骤表格被拦腰切断检索召回后返回的内容全是残缺数字。用这种知识库做出来的Agent答非所问是必然的。正确做法是先做文档分级再决定处理策略高价值结构化文档操作规程、故障代码表优先转为结构化数据最好抽成KV键值对或数据库表不要让模型去理解表格。中价值半结构化文档设备手册、培训教材按章节标题先做层级切分再结合段落长度二次切片尽量保住“章节—小节—段落”的语义边界。低价值非结构化资料聊天记录、散装笔记先清洗、去重、人工标注主题质量太差的宁可不入库垃圾进垃圾出。切片参数也别迷信固定值。我在实际项目里通常先把chunk_size定在300到500个中文字符overlap设50左右但每个知识库都要用真实问题去回测调到检索命中率最高为止。没有通用的最优参数只有针对你的文档集和问题集测出来的局部最优值。3.2 向量数据库与Embedding模型的内网选型很多企业问“AI智能体的企业知识库是不是必须放向量数据库”答案是如果要做RAG向量索引基本是标配。问题在于选什么。制造业普遍要求私有化部署所以云上向量库基本不考虑。开源方案里Milvus综合能力强适合数据量大、并发高的场景Qdrant部署简单、API友好如果你只想先跑几百份文档的轻量场景PostgreSQL加pgvector插件就够了IT团队有现成的PG运维经验能少踩很多坑。Embedding模型方面我推荐优先试开源的BGE系列中文向量模型。它本身对中文长文本支持不错可以完全内网运行。要注意的是通用Embedding模型对制造业专有名词的理解往往不够。像“主轴温升”“抱闸间隙”“洛氏硬度”这类词如果模型没见过足够多上下文检索效果会明显打折。解决办法是用真实语料做小规模微调或者至少准备几百条领域内的“检索测试题”逐个验证Top5召回里有没有正确答案。这一步千万不能省省了后面全是坑。3.3 知识更新机制技术之外的组织问题知识库上线三个月后最常见的局面是工艺部门改了操作参数但知识库里还是旧版文档一线工人按Agent给的步骤操作结果和现场SOP不一致。这不是技术Bug而是知识所有权没有落到具体部门头上。我的建议是搭建一个最简“知识入库审批流”业务部门设一个知识专员负责把变更文档交给IT团队入库IT团队负责格式转换和向量索引更新每次更新都记录版本号在Agent回复里标注“知识版本日期”。这套机制不复杂但没有它知识库一定会慢慢腐烂Agent的可信度也会随之崩塌。4. 从“能答”到“能办”工作流编排与老系统对接4.1 跑通问答之后业务部门会立刻提出新要求问答上线两周左右业务方一定会问同一个问题“它能告诉我故障代码是什么了能不能直接帮我开一张报修工单”到这个节点智能体就要从“能答”走向“能办”工作流编排正式登场。我一般建议用可视化平台先做原型比如Dify或Coze扣子。第一步把“查询设备档案”“生成故障描述”“创建工单”拆成独立节点第二步让智能体先识别用户意图判断该走“知识问答”流程还是“报修工单”流程第三步在关键环节插入人工审批节点工单生成前让班组长点一下“确认”。这样跑一到两个月等业务方信任度上来了再把人工审批逐步改成异常上报。工作流的真正价值不在于炫技而在于把智能体的不确定性关进笼子里。每个节点都有输入输出约束每一步都有日志可追溯出了问题能定位是模型理解错了、参数传错了还是接口超时了。4.2 老系统没有API也有办法接进来制造业最现实的问题是你要对接的MES系统是2010年上线的当初找外包公司开发外包公司都倒闭了API文档基本等于没有。这种情况下有三级处理方案代价从低到高排列第一级只读数据库。和IT部门申请一个只读账号直接查业务表。设备信息、工单状态、备件库存这类数据通常都在数据库里躺着。要注意的是先搞清楚哪些表是核心生产表查询语句务必走索引别因为Agent的并发查询把生产库拖垮。我见过某团队写了个全表扫描的SQL把老库CPU跑满差点酿成事故。第二级逆向封装API。如果老系统有前后端交互抓包分析接口路径和参数格式在外面包一层标准API服务再给Agent调用。这个方案可行但一定要拉上熟悉系统的老IT一起评估风险。第三级RPA模拟人工操作。系统完全封闭、没有数据库权限也抓不到包的时候用RPA工具模拟鼠标键盘操作。这是最后的兜底方案稳定性一般遇到系统升级就要重新调能不用尽量不用。4.3 MCP会成为制造业Agent的“标准插座”2025年以来MCP模型上下文协议慢慢成为打通Agent和外部工具的通用协议。简单理解它定义了一套“工具插座”标准模型需要调用某个系统时通过MCP Server暴露的标准接口去请求而不用为每家系统写一套私有对接逻辑。现在不少主流的ERP、MES厂商都在提供或规划MCP Server这对制造业是重大利好。但我的建议是现阶段不要把架构完全押在MCP上更不要为了用MCP而去改造核心生产系统。先让MCP作为API网关后的一层标准协议做试点验证稳定性和安全性等生态更成熟再慢慢扩大范围。制造业求稳新东西先在边缘场景试别动主干。5. 内网私有化部署模型、平台与多智能体框架怎么选5.1 模型选型不是越大越好而是够用就好制造业数据不出内网的硬约束决定了大多数项目要走私有化部署路线。国内开源模型里通义千问Qwen系列目前是实践中最稳妥的选择中文能力强、社区活跃、从0.5B到72B各个尺寸都有能根据硬件预算灵活选型。我实测下来的选型逻辑是这样的模型规模硬件参考适用场景7B~8B单张24GB显卡知识问答、文档摘要、意图识别14B两张24GB显卡或单张48GB复杂指令遵循、多轮推理32B及以上四卡以上或更高配置长文本分析、复杂规划做知识问答和工单流转7B到14B完全够用配上量化部署还能进一步降低显存占用。很多团队一上来就追求大参数量模型结果推理延迟高得离谱一线工人等十秒钟不出结果直接放弃使用。记住制造业现场最在意的是“快”和“稳”“聪明”排在后面。5.2 Agent编排平台Dify、Coze与自研框架的取舍几个热搜词反复提到Dify和Coze扣子这里集中说下选型思路。Dify是开源的可以完全内网部署工作流可视化做得好对RAG的支持也比较成熟。我倾向把它作为制造业Agent落地的第一选择因为IT团队能掌握全部数据流不会被平台绑定后续要迁移到自研框架也有基础。Coze上手快字节生态的插件和工具很丰富适合快速做Demo和验证场景。但如果企业业务要求私有化、数据不出内网用Coze就要格外谨慎先确认清楚平台的部署形态和数据流向别等上线了才发现合规过不了关。自研多智能体框架比如LangGraph、AgentScope这类适合场景复杂度明显上升、需要精细控制智能体协作逻辑的时候。但自研绝不应该是第一步的选择。我见过一个团队上来就用LangGraph搭了五个Agent协作的系统两周后没人说得清状态流转哪里出了bug。复杂度这种东西晚一天引入就多省一天命。5.3 多智能体制造业主流场景大概率用不到关于“多智能体框架到底用哪个”自媒体吵得很热闹但回到制造业现场我的判断很直接主流场景里“单智能体工作流RAG”就解决了八成问题不需要上多智能体。多智能体适合的是多个专业角色并行协作、各自持有不同数据源、需要博弈或投票决策的场景。制造业里真正能体现多智能体价值的是销售报价这类综合任务一线销售问“客户要500件45天交付给什么价”一个Agent去查库存一个Agent去查产能另一个Agent去算成本最后由汇总Agent给出报价区间。这类场景值得做但前提是先把库存、产能、成本这几个系统的数据全部打通。数据没通之前上多智能体只会让多个Agent一起犯错、互相传染。6. 上岗之后的考核用KPI证明智能体没有白上6.1 关键指标别拿“对话次数”糊弄老板Agent上线后如果只汇报“月对话量突破一万次”老板听一次还行听两次就会问“然后呢解决了多少问题省了多少时间”所以第一周就要把评测体系建起来。我的做法是从历史工单和一线提问里收集几百个真实问题整理成评测集并给每个问题配上标准答案和知识来源。每次升级模型版本、调整切片参数、修改Prompt都用同一套评测集跑回归算“检索命中率”和“答案正确率”。再配合线上指标有效解决率用户没有再追问或转人工的比例、平均处理时长、工单转化率。有了这套组合拳Agent的价值才能用数据说话后续要资源、要预算才有底气。6.2 人在回路制造业不能容忍错误答案自由传播在制造业环境里任何一个错误答案都有可能顺着屏幕被截图转发到整个车间。所以我在几乎所有项目里都保留了“人在回路”的兜底设计当答案置信度低于阈值或用户连续两次对回答点“不是我要的”Agent自动建议“转人工处理”而不是强行编一个答案。白皮书里把这称为“有尊严的失败”。智能体不知道答案时应该承认不知道而不是胡编。这一点在制造业尤其重要——一个坦白说“需要老师傅确认”的Agent比一个经常自信满满给出错误方案的Agent更容易赢得一线员工的信任。6.3 每周复盘Bad Case驱动持续迭代项目上线后我建议运维人员每周做一次Bad Case复盘。把本周回答错误、用户不满意的问题拉出来分类标记是知识库里没有覆盖检索没召回模型理解错还是Prompt表达有歧义四类问题对应完全不同的修法一个月下来准确率会肉眼可见地往上走。这套复盘机制跑三个月你还会发现一个意外收获评测集本身会越来越完善。每周新增的Bad Case都会沉淀回评测集里下个版本升级时回归测试会越来越严格Agent的能力基线也越来越高。我个人的体会是制造业智能体项目最难的从来不是把模型跑起来而是愿意用一个季度的时间把知识治理、场景边界、评测闭环这些“脏活累活”扎扎实实做完。智能体“上岗”看起来是一个技术事件本质上是一场围绕知识、流程和责任边界的小型组织变革。谁先把这件事想清楚谁的Agent就能真正在车间里站住脚而不是停留在发布会Demo里。