制造业智能体落地实践：从设备点检到质量根因分析的完整复盘

1. 制造业智能体的需求拆解：从“做个demo”到“解决真问题”

大约在半年前，我被领导叫去谈话，说要“研究一下智能体，看看车间能用上什么”。当时智能体这个词在公司里还特别模糊，有人觉得是聊天机器人，有人觉得是自动化脚本，还有人觉得就是大模型套了个壳。为了把这件事做实，我给车间跑了几趟，跟设备工程师、质量工程师、班组长聊了一圈，最后用两周时间搭完两个试点智能体，又花了一周把整套过程整理成一份完整的落地方案文档，打印出来厚厚一沓，领导看完直接给了满分。

这篇就针对这次“制造业智能体实践”做个完整复盘。如果你是制造企业的数字化部门、IT工程师、工艺工程师，或者负责设备管理、质量管理、生产管理的人，建议认真看完。我会把需求怎么拆、框架怎么选、工作流怎么搭、多智能体怎么配、踩了哪些坑全部摊开讲。内容不绕弯子，都是可以直接照做的经验。

1.1 为什么制造业才是智能体最合适的试验田

很多人一聊智能体就想到客服、写作、代码生成，但真正让智能体发挥价值的场景，往往在制造业这类知识密集、规则复杂、流程固定的行业里。制造业有一个天然优势：业务边界清晰，知识资产密集。设备点检规范、工艺参数表、质量异常记录、安全操作规程、历史故障报告，这些知识多年沉淀下来，存在各种Excel、Word、PDF、OA系统里面，平时根本没人能全部翻一遍，但又是实打实的“业务大脑”。

另一个原因是制造业的容错边界允许“人机协作”。智能体不是要替代人，而是给现场工程师一个“知识助手”。老师傅退休之后经验会流失，新员工上手慢，班组长每天被重复问题轰炸——这些问题用传统软件系统解决不了，恰好是智能体的主战场。我调研时发现，车间里问得最多的问题翻来覆去就那么几十类，比如“三号压机报警代码E-214是什么意思”“这批铸件表面气孔率超标该查哪些环节”，都是高重复、高确定性、高知识密度的问题。

所以第一个结论是：做智能体之前，先想清楚你的知识在哪里，问题在哪里。如果这两个问题没有答案，后面技术选型再花哨也是白搭。

1.2 四个候选场景怎么选

我把车间里收集到的需求归成了四类，做了个对比表：

最后我选了第一个和第二个作为试点。原因很直接：设备点检辅助场景见效快、风险低，适合让项目跑起来；质量异常根因分析场景价值大、技术含量高，适合证明智能体不是“玩具”。这两类合在一起，既有面子又有里子，后面写汇报材料的时候也好看。

选场景还有一个原则要记住：先选“知识问答型”的练手，再碰“决策分析型”的硬骨头。一上来就做排产优化、设备预测性维护这类跟实时控制系统挂钩的项目，智能体一旦出错就是安全事故，风险完全不可控。我见过不少团队上来就挑战高难度，结果半年过去连POC都没过，反而是先从问答场景切入的团队，三个月内就做出了业务方愿意用的东西。

1.3 让领导满意的“满分Word”是怎么组织出来的

这里必须说说“满分Word”这件事。很多工程师技术做得漂亮，但汇报材料写得稀烂，导致项目被否、预算被砍。我这次能把文档写成领导主动打满分，核心就六个字：痛点在前，数字说话。

文档结构我是这样安排的：第一页放核心摘要，用三句话讲清楚智能体是什么、能解决什么问题、试点效果如何；第二部分放场景调研，用真实对话截图和调研记录展示“业务方确实在痛”；第三部分放技术方案，包括整体架构图、框架选型对比、工作流设计；第四部分放试点数据，对比使用前后的人均答疑时间、问题解决率、知识检索准确率；第五部分放推广计划和风险控制。每一部分都用表格和截图说话，绝不用大段空话。

有一点要特别提醒：写文档的时候，不要把技术实现细节铺太多。领导关心的是投入产出比，不是LangGraph的节点怎么连接。我在技术选型部分只用了两页讲清楚“为什么选这套方案”，剩下的篇幅全部留给业务效果、推广路径和风险预案。文档写完那份以后，凡是再有人问我“智能体能干啥”，我直接把这文档发过去，沟通效率高了一倍。

2. 技术选型复盘：Dify、Coze、LangChain+LangGraph怎么选

智能体现在的框架五花八门，选型本身就能写几千字论文。但落到制造业实际环境里，我的判断标准非常简单：能不能私有化部署、能不能对接内部知识库、能不能灵活编排多智能体逻辑、团队能不能长期维护。

2.1 三家框架横向对比

当时市面上主流的三条路线我都试了，分别是Dify、Coze、LangChain+LangGraph。先说结论：三者不是替代关系，而是适用不同阶段和场景。

Dify是最适合起步的。它的最大优势是“开箱即用”，可视化编排工作流、内置知识库管理、支持多种模型接入。我搭设备点检辅助智能体的时候，从Dify后台创建应用绑定知识库到能回答问题，总共用了不到半天。Dify自带的Prompt编排、数据集管理、日志追踪功能在制造业场景里完全够用，最关键的是它支持Docker私有化部署，对数据敏感的企业非常友好。

Coze的优点是上手更快、插件生态丰富，尤其是字节系出来的，默认就带一堆工具。但Coze的问题在于偏云端SaaS，私有化能力弱，企业数据要过别人的服务器，这在很多制造企业里是红线。我的建议是：Coze适合个人快速验证想法或者做产品Demo，不适合直接进车间。除非你们公司对数据合规要求不高，否则别拿Coze做正式生产系统。

LangChain+LangGraph则是真正做重活的地方。它灵活、代码可控、擅长编排复杂多智能体逻辑，但学习曲线陡，需要团队写代码。我的质量异常根因分析智能体最终就是用LangGraph搭建的。LangGraph的节点编排机制非常清晰，特别适合做“主管-专家”这种多智能体协作模式，每个专家节点又可以独立调用模型、工具、知识库，整个结构在代码里一目了然。

2.2 制造业的私有化硬约束

为什么私有化部署这么重要？我给你讲个真实案例。我们工厂的工艺参数、设备图纸、质量缺陷数据，都属于公司内部机密。任何一个员工把数据传到外部平台，都直接违反公司信息安全制度。而智能体想发挥作用，必须把内部知识库喂给它，这就形成了天然矛盾：数据越丰富，智能体越智能，但泄露风险也越高。

解决方式只有一个：全部本地化部署，数据不出厂。选型的时候，凡是不能私有化部署的方案，一律一票否决。Dify和LangGraph都支持完整本地部署，大模型可以接本地部署的开源模型，或者通过内部API网关访问云端模型API，但数据链路全程在公司内网。嵌入模型我选的是BGE-M3，完全本地跑，不用调外部接口。

另外还要考虑系统的可维护性。制造企业的IT团队通常不会太大，如果选一个特别冷门的框架，后面员工离职了没人会运维，项目就烂尾了。Dify因为是可视化操作，普通IT人员培训两周就能上手；LangGraph写Java和Python的都能接，人才培养成本相对可控。

2.3 我最终选用的组合

最终我的选型方案是双轨并行：设备点检辅助智能体用Dify快速交付，质量异常根因分析智能体用LangChain+LangGraph做深度定制，两个系统的底层知识库和模型服务统一共用。

具体配置是：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_k=5，召回后直接拼进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服务器更有价值。