1. 制造业智能体的需求拆解从“做个demo”到“解决真问题”大约在半年前我被领导叫去谈话说要“研究一下智能体看看车间能用上什么”。当时智能体这个词在公司里还特别模糊有人觉得是聊天机器人有人觉得是自动化脚本还有人觉得就是大模型套了个壳。为了把这件事做实我给车间跑了几趟跟设备工程师、质量工程师、班组长聊了一圈最后用两周时间搭完两个试点智能体又花了一周把整套过程整理成一份完整的落地方案文档打印出来厚厚一沓领导看完直接给了满分。这篇就针对这次“制造业智能体实践”做个完整复盘。如果你是制造企业的数字化部门、IT工程师、工艺工程师或者负责设备管理、质量管理、生产管理的人建议认真看完。我会把需求怎么拆、框架怎么选、工作流怎么搭、多智能体怎么配、踩了哪些坑全部摊开讲。内容不绕弯子都是可以直接照做的经验。1.1 为什么制造业才是智能体最合适的试验田很多人一聊智能体就想到客服、写作、代码生成但真正让智能体发挥价值的场景往往在制造业这类知识密集、规则复杂、流程固定的行业里。制造业有一个天然优势业务边界清晰知识资产密集。设备点检规范、工艺参数表、质量异常记录、安全操作规程、历史故障报告这些知识多年沉淀下来存在各种Excel、Word、PDF、OA系统里面平时根本没人能全部翻一遍但又是实打实的“业务大脑”。另一个原因是制造业的容错边界允许“人机协作”。智能体不是要替代人而是给现场工程师一个“知识助手”。老师傅退休之后经验会流失新员工上手慢班组长每天被重复问题轰炸——这些问题用传统软件系统解决不了恰好是智能体的主战场。我调研时发现车间里问得最多的问题翻来覆去就那么几十类比如“三号压机报警代码E-214是什么意思”“这批铸件表面气孔率超标该查哪些环节”都是高重复、高确定性、高知识密度的问题。所以第一个结论是做智能体之前先想清楚你的知识在哪里问题在哪里。如果这两个问题没有答案后面技术选型再花哨也是白搭。1.2 四个候选场景怎么选我把车间里收集到的需求归成了四类做了个对比表候选场景典型问题业务痛点智能体形态落地难度设备点检辅助报警代码含义、点检步骤、维保周期老师傅不在场时没人说得清知识库问答智能体低质量异常根因分析某个缺陷反复出现原因难定位质量工程师反复查历史记录多智能体协同分析高工单与排产问答订单状态、交期预估、物料齐套情况信息分散在MES/ERP里工具调用型智能体中安全规范培训新员工问操作规程、危险源识别培训成本高、效果难追踪问答考试智能体低最后我选了第一个和第二个作为试点。原因很直接设备点检辅助场景见效快、风险低适合让项目跑起来质量异常根因分析场景价值大、技术含量高适合证明智能体不是“玩具”。这两类合在一起既有面子又有里子后面写汇报材料的时候也好看。选场景还有一个原则要记住先选“知识问答型”的练手再碰“决策分析型”的硬骨头。一上来就做排产优化、设备预测性维护这类跟实时控制系统挂钩的项目智能体一旦出错就是安全事故风险完全不可控。我见过不少团队上来就挑战高难度结果半年过去连POC都没过反而是先从问答场景切入的团队三个月内就做出了业务方愿意用的东西。1.3 让领导满意的“满分Word”是怎么组织出来的这里必须说说“满分Word”这件事。很多工程师技术做得漂亮但汇报材料写得稀烂导致项目被否、预算被砍。我这次能把文档写成领导主动打满分核心就六个字痛点在前数字说话。文档结构我是这样安排的第一页放核心摘要用三句话讲清楚智能体是什么、能解决什么问题、试点效果如何第二部分放场景调研用真实对话截图和调研记录展示“业务方确实在痛”第三部分放技术方案包括整体架构图、框架选型对比、工作流设计第四部分放试点数据对比使用前后的人均答疑时间、问题解决率、知识检索准确率第五部分放推广计划和风险控制。每一部分都用表格和截图说话绝不用大段空话。有一点要特别提醒写文档的时候不要把技术实现细节铺太多。领导关心的是投入产出比不是LangGraph的节点怎么连接。我在技术选型部分只用了两页讲清楚“为什么选这套方案”剩下的篇幅全部留给业务效果、推广路径和风险预案。文档写完那份以后凡是再有人问我“智能体能干啥”我直接把这文档发过去沟通效率高了一倍。2. 技术选型复盘Dify、Coze、LangChainLangGraph怎么选智能体现在的框架五花八门选型本身就能写几千字论文。但落到制造业实际环境里我的判断标准非常简单能不能私有化部署、能不能对接内部知识库、能不能灵活编排多智能体逻辑、团队能不能长期维护。2.1 三家框架横向对比当时市面上主流的三条路线我都试了分别是Dify、Coze、LangChainLangGraph。先说结论三者不是替代关系而是适用不同阶段和场景。Dify是最适合起步的。它的最大优势是“开箱即用”可视化编排工作流、内置知识库管理、支持多种模型接入。我搭设备点检辅助智能体的时候从Dify后台创建应用绑定知识库到能回答问题总共用了不到半天。Dify自带的Prompt编排、数据集管理、日志追踪功能在制造业场景里完全够用最关键的是它支持Docker私有化部署对数据敏感的企业非常友好。Coze的优点是上手更快、插件生态丰富尤其是字节系出来的默认就带一堆工具。但Coze的问题在于偏云端SaaS私有化能力弱企业数据要过别人的服务器这在很多制造企业里是红线。我的建议是Coze适合个人快速验证想法或者做产品Demo不适合直接进车间。除非你们公司对数据合规要求不高否则别拿Coze做正式生产系统。LangChainLangGraph则是真正做重活的地方。它灵活、代码可控、擅长编排复杂多智能体逻辑但学习曲线陡需要团队写代码。我的质量异常根因分析智能体最终就是用LangGraph搭建的。LangGraph的节点编排机制非常清晰特别适合做“主管-专家”这种多智能体协作模式每个专家节点又可以独立调用模型、工具、知识库整个结构在代码里一目了然。2.2 制造业的私有化硬约束为什么私有化部署这么重要我给你讲个真实案例。我们工厂的工艺参数、设备图纸、质量缺陷数据都属于公司内部机密。任何一个员工把数据传到外部平台都直接违反公司信息安全制度。而智能体想发挥作用必须把内部知识库喂给它这就形成了天然矛盾数据越丰富智能体越智能但泄露风险也越高。解决方式只有一个全部本地化部署数据不出厂。选型的时候凡是不能私有化部署的方案一律一票否决。Dify和LangGraph都支持完整本地部署大模型可以接本地部署的开源模型或者通过内部API网关访问云端模型API但数据链路全程在公司内网。嵌入模型我选的是BGE-M3完全本地跑不用调外部接口。另外还要考虑系统的可维护性。制造企业的IT团队通常不会太大如果选一个特别冷门的框架后面员工离职了没人会运维项目就烂尾了。Dify因为是可视化操作普通IT人员培训两周就能上手LangGraph写Java和Python的都能接人才培养成本相对可控。2.3 我最终选用的组合最终我的选型方案是双轨并行设备点检辅助智能体用Dify快速交付质量异常根因分析智能体用LangChainLangGraph做深度定制两个系统的底层知识库和模型服务统一共用。具体配置是Dify用Docker Compose部署在内网服务器上模型接本地部署通义千问Qwen2.5-72B-Instruct嵌入模型用BGE-M3向量数据库用Dify内置的Weaviate。LangGraph这边Python环境跑一个FastAPI服务同样接Qwen模型工具调用通过内部API网关访问MES系统接口。整套系统从模型到向量库到业务接口全部在内网环境运行。这套组合有一个隐藏优势Dify高效率交付简单场景LangGraph做复杂场景两者互不干扰。当企业后续有更多人机交互需求时可以直接在Dify里复制应用不需要重新开发而复杂智能体则可以在LangGraph上不断加节点、加工具。3. 核心实操两个智能体从零到一落地现在进入正题把两个智能体的实现过程完整过一遍。这部分是最多干货的我会把关键配置、参数选择、注意事项一次性讲清楚。3.1 设备点检辅助智能体知识库问答型设备点检辅助智能体的核心是一个高质量的知识库问答系统。它的业务价值在于把分散在各处的设备手册、点检表、故障记录集中起来让现场操作工通过自然语言就能快速获取答案。知识库建设是第一步也是最花时间的一步。我搜集了三个车间的设备点检卡、历年故障维修记录大概800多份Excel、重点设备的操作手册PDF、安全操作规程全部转成文本后统一清洗格式。数据总量大约400MB原始文件清洗后有效文本约80万字。这步千万别省智能体的回答质量本质上取决于知识库质量垃圾进垃圾出。第二步是分块和向量化。Dify里的知识库可以设置分块长度我最终选的是每块300个字符、重叠50个字符。这个参数是调了好久试出来的分块太小会导致检索出的片段上下文不完整分块太大会稀释语义相似度。嵌入模型选择本地部署的BGE-M3维度1024检索时设置top_k5召回后直接拼进Prompt。要说明的是这个参数在不同领域的知识库并不通用要根据你的文档类型多试几组对比。一般来说如果文档里以短段落、条目式内容为主分块可以小一些如果是长篇说明书分块可以适当拉大。第三步是配置系统提示词。Dify里的System Prompt我这样写的你是一名制造业设备点检专家精通机械、电气、液压设备的日常点检和常见故障处理。回答问题时只依据知识库提供的信息如果知识库中没有相关内容必须明确回答“暂无相关信息”严禁编造。回答要简洁、步骤明确适合现场操作人员快速执行。这版提示词相当重要它把智能体的“人设”和边界都定义清楚了。很多智能体效果差不是模型不行而是Prompt没写好角色定位模糊、回答范围无边无际。第四步是设置“开场问题”和“推荐问题”方便现场员工快速体验。Dify支持配置推荐问题我把车间问得最多的几个问题如“E-214报警怎么处理”“液压油更换周期是多少”直接放上去员工点一下就能问。3.2 质量异常根因分析智能体多智能体协同型这个项目比知识库问答复杂得多也更能说明“多智能体”的价值。需求来自质量部门某型号铸件近一个月气孔率超标质量工程师每次都要翻历史记录、查工艺参数、对比设备状态一套流程下来至少半天而且经常漏掉关键信息。我设计的多智能体流程分为三层。第一层是“情报收集智能体”负责接收质量异常描述比如“3号线铸件气孔率连续三天超标主要集中在上表面”然后自动去MES系统、质量检测系统、设备管理系统里拉取相关数据包括机床编号、加工时间、操作人员、当天气温湿度、原材料批次、最近一次设备维保时间。这一层本质是工具调用需要给智能体定义好API接口文档。第二层是“根因分析智能体”拿到情报后先分解异常特征再结合知识库里的历史故障案例进行匹配输出可能的根因清单按概率排序。这里要特别设计分析框架否则智能体容易天马行空。我给它预设了一个分析维度表人、机、料、法、环、测六维因素每个维度下挂对应的数据字段和分析规则。这相当于把质量工程师的思考方法论“教给”了智能体。第三层是“措施建议智能体”针对根因清单给出可执行的排查动作和纠正措施。比如系统判断是原材料批次问题就建议“立即封锁同批次砂芯送检化学成分启用备用供应商批次”。这层的知识来自操作规程和工艺文件。三个智能体由LangGraph统一编排。LangGraph的核心是定义状态图每个节点是一个Agent或者一个工具调用节点之间通过状态传递数据。我在图里设了5个节点接收输入、情报收集、根因分析、措施生成、汇总输出中间加了一个条件分支如果情报收集阶段发现数据缺失自动回到人工确认环节不强行分析。3.3 工作流里最重要的三个细节工作流搭建的技术含量不在“拖拽节点”而在细节设计。我在实践过程中总结了三个影响成败的细节这里特意强调一下。第一个细节是“工具调用的参数补全”。Dify和LangGraph调用工具的时候智能体可能无法从当前对话中获取全部必填参数。比如查询MES工单系统需要“工单号”但员工可能只说“帮我看看昨天三号线的生产情况”。这种情况要在工具定义里设置参数追问规则让智能体主动追问缺的参数“请问您需要查询哪个工单号可以告诉我生产线或具体时间段。”这个设计直接决定了实际可用性因为真实业务场景下的用户很少会一次性把参数给全。第二个细节是“知识库检索结果的引用标注”。回答里必须标注信息来源这个看似简单的要求实际操作中需要把检索到的文档ID和片段ID原样带回。制造业的工程师非常看重“依据”如果一个智能体说“轴承温度不能超过75度”却不告诉出处没人敢信。标注引用既是对知识库的背书也是出错时追溯的依据。我在Prompt里明确要求“每条关键结论后用【来源文件名-页码】的格式标注出处。”第三个细节是“兜底话术”。一定要设计好当知识库检索不出相关内容时怎么办。不能让智能体硬编造也不能让员工觉得这系统没用。我的处理方式是分两种情况如果问题和设备点检相关但知识库没有智能体回复“该问题暂无标准答案已上报至工程师处理”同时把这条问题记录写入日志定期人工补录知识库如果问题和业务完全无关智能体直接回复“超出我的知识范围请联系相关部门”。这个兜底机制让系统在落地初期就显得很“懂事”大大降低了业务方的反感。4. 多智能体协同配置与编排实战多智能体是当前智能体开发里最热的方向也是踩坑最多的地方。很多团队上来就搞了个十个Agent的大型协作系统结果跑起来不是死循环就是上下文爆炸最后整个项目黄掉。制造业场景里多智能体的正确打开方式是“够用就行按需编排”。4.1 制造业为什么需要多智能体一个单智能体处理不了所有事情吗能但效果会差很多。简单的知识问答当然可以但遇到质量根因分析这类复杂任务单智能体就显得力不从心。原因在于不同环节需要不同的系统提示词、不同的知识库、不同的工具权限。如果全塞进一个智能体里Prompt会变得无比庞大模型既要做情报收集又要做分析还要给建议顾此失彼。对话历史一长前面的关键信息很容易丢失。多智能体的思路是“把专业的事交给专业的Agent”每个Agent只负责一段职责上下文短、指令清晰、工具单一反而更容易用好。我总结的规律是当任务链条超过3个步骤或需要调用3种以上工具或需要不同领域的知识库时就要考虑拆分成多智能体。千万不要为了“技术炫酷”强行拆拆得越多协调成本越高。4.2 主管-专家模式的完整配置多智能体最常见的架构就是“主管-专家Supervisor-Worker”我在质量异常分析项目里用的就是这种。主管Agent负责理解用户请求、规划步骤、分发任务、汇总结果专家Agent负责具体干活。LangGraph实现里我先定义了一个State对象用来存放整个任务的共享数据包括原始输入、情报数据、中间分析结果、最终回复。主管节点、情报节点、分析节点、措施节点都读写这个State。节点和节点之间用边连接边上可以加条件判断比如“情报节点执行完成后必须检查State里是否包含必要数据缺失则跳转到人工确认节点”。配置过程中最需要注意的是“上下文的裁剪”。多个Agent协作时每个Agent收到的输入要精准控制只给当前节点需要的字段不要把所有历史数据全部塞给它。我在State里设计了一个current_topic字段每次分支判断都基于这个字段走不同路径这样各个Agent的输入输出都清晰排查问题也方便。这里放一段LangGraph的核心配置代码供参考from langgraph.graph import StateGraph, END # 定义状态 class QualityAnalysisState(TypedDict): query: str intelligence: dict root_causes: list measures: list final_reply: str # 定义节点函数 def supervisor_node(state: QualityAnalysisState): # 主管理解意图、规划任务 return {analysis_type: root_cause} def intelligence_node(state: QualityAnalysisState): # 情报收集调用MES/质量系统API data call_mes_api(state[query]) return {intelligence: data} def root_cause_node(state: QualityAnalysisState): # 根因分析基于情报知识库 causes analyze(state[intelligence]) return {root_causes: causes} def measure_node(state: QualityAnalysisState): # 措施建议基于根因输出动作 measures suggest(state[root_causes]) return {measures: measures} # 构建图 graph StateGraph(QualityAnalysisState) graph.add_node(supervisor, supervisor_node) graph.add_node(intelligence, intelligence_node) graph.add_node(root_cause, root_cause_node) graph.add_node(measure, measure_node) graph.set_entry_point(supervisor) graph.add_edge(supervisor, intelligence) graph.add_edge(intelligence, root_cause) graph.add_edge(root_cause, measure) graph.add_edge(measure, END)实际的工程代码会比这个复杂加进了条件判断、异常重试、超时取消但核心骨架就是这样。LangGraph的优势是它天然支持状态管理和条件分支很适合做这种需要严格流程控制的多智能体应用。4.3 记忆与会话压缩的工程化处理多智能体跑起来以后大家就会面对一个新的问题记忆怎么管。一个质检员可能连续问七八个问题如果每次都从头开始理解上下文智能体就变得“健忘”但如果不加限制地保留所有历史对话上下文越来越长推理速度变慢费用变高效果也变差。热词里提到的Mem0就是这个场景下的一个解决方案。Mem0是一个智能记忆管理工具可以把对话里的关键信息抽取出来存储按需注入给智能体。比如质检员前面提到了“3号线”“这批订单是B-2024-089”后面再提问时Mem0会自动把这两个上下文带出来不用用户重复描述。不过我这里得说句实在话制造业场景里记忆不需要太复杂。因为多数业务问题都是“单点查询”前后关联并不深。我的建议是优先用传统方式管理会话比如按照会话ID存Redis保留最近20轮原始消息超长就截断。只有当业务确实需要跨会话记住用户偏好或项目上下文时再考虑引入Mem0这类工具。别为了用新词而引入新组件多一个组件就多一个故障点。如果真要上Mem0部署可以这样它支持通过Docker本地运行数据存储用向量数据库API比较简洁docker run -p 8000:8000 mem0ai/mem0-server:latest然后通过API往里面写入和提取记忆import requests # 添加记忆 requests.post(http://localhost:8000/mem0, json{ user_id: quality_engineer_01, content: 用户负责3号线铸件质量关注气孔率指标 }) # 提取记忆 res requests.get(http://localhost:8000/mem0, params{ user_id: quality_engineer_01, query: 当前关注什么缺陷指标 })5. 落地过程中的典型问题排查实录到这里方案和代码都聊得差不多了但真正让一个智能体项目从“能跑demo”走向“能进车间”中间有大量问题要排查。我把自己踩过的坑整理成了一份问题速查表希望能帮你少走弯路。5.1 检索不准分块策略和重排第一个实现版本跑出来以后我发现一个明显问题回答经常引用不相关的知识片段明明知识库里有点检标准却检索出设备说明书里的一句话。排查下来分块和检索策略都有问题。解决方案有两条。第一分块不能无脑按字数切要尊重文档结构。我后来改成按语义段落分块优先按照Markdown标题、表格、列表边界切分实在没有结构的长文本再按字数切。第二加一个Rerank重排序模型。Dify支持配置Rerank模型对召回的前50个候选片段做精排保留下Top5给大模型。加入重排之后知识检索准确率从78%提升到了92%效果非常明显。5.2 幻觉控制业务规则怎么绑定大模型幻觉问题在制造业是致命的。设备工程师如果根据幻觉回答做操作轻则误判重则出安全事故。我把幻觉控制拆成两道防线。第一道防线是数据源隔离。给智能体设定强约束只能基于检索到的知识库片段回答不能使用模型的“内在知识”来补充。如果知识库片段信息不够必须明确回答“信息不足”。这个约束通过在Prompt里加负面指令实现严禁编造任何数据、严禁使用知识库之外的信息。第二道防线是业务规则校验。我在LangGraph里加了一个“校验节点”检查最终输出是否包含危险词和不安全建议。比如“可以短接”“不用防护”“跳过点检”这类词一旦出现直接拦截并提示“该建议可能违反安全操作规程请人工复核”。这个校验词表是设备安全主管帮我逐条写的非常实用。建议制造业的智能体项目都做一层这样的安全过滤。5.3 性能成本模型、缓存和内网部署制造业不像互联网公司IT预算有限服务器配置也不算豪华。我在实践过程中对性能成本做了几个优化。第一别看72B模型效果最好就无脑用实际测试中Qwen2.5-14B在知识问答场景的效果足够推理速度快一倍显存占用降一半。第二给高频问题加缓存完全一样的问法直接返回历史答案不走模型推理节省算力也提升响应速度。最终我部署了两套模型小模型Qwen2.5-14B应对常规问答大模型Qwen2.5-72B只用于质量根因分析这种高难度任务。把模型服务放在内网GPU服务器上用vLLM做推理加速整体成本可控响应速度也能维持在3到5秒内。5.4 与MES/ERP系统集成的坑智能体要对接MES、ERP系统最大的坑是API文档不完整很多老旧系统连个正经Restful接口都没有。我遇到的情况是MES系统提供的是SOAP接口参数格式复杂返回的XML解析还老出错。我的处理办法是写一层“适配器服务”把这套老接口封装成统一的RESTful API再喂给智能体调用。同时做超时控制和错误重试单次调用超过5秒直接报错返回可读提示避免智能体一直等导致整个工作流卡死。此外还要关注数据权限。MES、ERP里的数据很多是敏感的智能体调用数据之后必须在日志里完整记录谁在什么时间查了什么数据这个审计要求必须提前设计好否则上生产环境要返工。6. 收尾的意义文档既是技术实践更是组织方式的变化这套智能体实践做下来给我最大的感受不是技术多复杂而是“智能体”在制造企业里要想落地真正的瓶颈往往是组织和流程的适配。文档拿到满分只是开端更关键的是它让不同部门开始理解智能体的能力边界知道它能帮知识型员工省出大量重复劳动的时间也知道它哪些事做不了必须由人来兜底。后面我们已经在规划把设备点检智能体推广到更多车间同时把质量异常分析智能体从一个产品扩展到整条产品线。现在的效果比预期好不少但仍然要说句实在话智能体不是万能的它不会自动让工厂变聪明它只是把人的经验数字化、结构化了真正的判断决策还是要靠一线的工程师来完成。如果你也准备在制造企业里推智能体我的建议是从最小场景切入先让业务方用起来再去想那些宏大的“数字员工”愿景。另外一定留出足够的精力去维护知识库知识库不更新智能体就会慢慢变蠢。把更新机制和责任人定好比多买一台GPU服务器更有价值。
