制造业里聊AI绕不开一个话题智能体Agent。过去一年我一直在折腾怎么把大模型真正落进车间做过设备故障诊断、试过生产排程辅助、也搞过多智能体去协调质检流程前前后后踩了无数坑。最近这个制造业智能体实践项目总算跑通了我把整份实践过程整理成一份完整的Word文档内部答辩拿了满分。今天不聊虚的把核心思路、技术选型、实操过程和踩坑记录全部掰开揉碎给你看。这一篇不是纯教程更像是把一个真实项目的复盘过程摊在桌面上。如果你正准备在工厂场景里搭智能体或者想了解Agent怎么跟MES、SCADA、自建预测模型结合这篇能帮你省下不少试错时间。1. 制造业智能体的整体设计思路1.1 为什么制造业需要的是智能体而不是一个问答机器人很多人一开始的思路是把大模型接进企业微信或者网页做一个AI客服。但制造业的问题从来不是能不能聊而是能不能干活。举个例子老师傅问3号注塑机当前模温偏高是什么原因。普通问答机器人只能根据训练数据给出一堆泛泛的排查思路比如检查冷却水管、检查温度传感器但这些问题里没有实时数据支撑等于没说。智能体的思路完全不同。它能调用MES接口拉取3号机的实时模温曲线关联过去24小时的报警记录检索这台设备的维修档案再结合工艺卡上的标准温度范围最后给出一条带数据依据的诊断结论模温从14:20开始持续上升同时冷却水入口压力从0.4MPa掉到0.28MPa历史维修记录显示2025年3月更换过冷却电磁阀建议优先检查冷却水回路。这就是智能体和问答机器人的本质区别大模型做大脑工具做手脚记忆做经验。大脑负责理解意图和拆解任务手脚负责获取真实数据、执行操作经验负责在多次交互中记住上下文和偏好。制造业里有大量系统需要对接、大量实时数据需要查证、大量操作流程需要规范这些恰恰是智能体能发挥价值的地方。1.2 技术选型LangChain LangGraph Dify 到底怎么选这个项目启动前我在技术栈上做了一轮对比。市面上的智能体框架很多LangChain、LangGraph、Dify、Coze都有各自的定位。先说结论最终核心框架选的是LangChain LangGraphDify被用来做内部快速验证和原型展示。原因很简单制造业流程复杂经常有分支、循环、人工确认节点LangGraph有状态的图执行机制能精确控制节点间的流转而Dify在可视化编排上很方便但遇到复杂的车间流程调度时不够灵活。Coze我也试过搭个轻量Agent非常快但数据安全和企业私有化部署是个问题制造业的数据往往不能出内网所以放弃了。另外还要考虑一个点制造业经常有自研的业务模型比如设备剩余寿命预测模型、工艺参数优化模型、质量SPC控制模型。智能体要想调用这些模型必须能把它们封装成工具。LangChain的Tool机制对这类封装非常友好把Python函数包一层装饰器加个描述模型就能识别并调用。框架对比我整理了一个表框架优势劣势适用场景LangChain生态成熟、工具封装灵活编排复杂流程时代码量大需要深度定制、对接自建模型LangGraph有状态图编排、支持循环分支学习曲线略陡多智能体协作、生产流程编排Dify可视化、上手快复杂逻辑受限、私有化定制成本高原型验证、内部知识库问答Coze搭建简单、插件丰富数据安全受平台限制轻量场景、外部应用1.3 制造业智能体项目的核心能力拆解我在设计这个项目时没有一上来就搞一个什么都能干的超级智能体而是拆成了三个相互独立又能协作的智能体设备故障诊断智能体、生产排程辅助智能体、质量缺陷分析智能体。每个智能体都有明确的职责边界、独立的工具集和专属的知识库。比如设备故障诊断智能体对接设备维修知识库和MES数据接口生产排程辅助智能体对接订单系统、产线产能数据和排程算法。这样拆的好处是单个智能体的提示词不会太长工具调用不会混乱出了问题也容易排查。三个智能体之间通过LangGraph做顶层编排形成一个多智能体系统。订单插入、设备报警、质量异常这些事件触发时系统会自动判断应该启用哪个智能体或者是否需要多个智能体协作。2. 核心功能解构与实操要点2.1 设备故障诊断智能体从知识库到推理链设备故障诊断是制造业智能体里最容易出效果、也最容易翻车的场景。它的工作流程是这样的用户输入设备编号和故障描述智能体先做意图识别判断这是一次诊断请求然后从设备档案库和维修知识库做检索增强生成RAG拿到相关文档片段接着调用MES接口获取该设备的实时运行参数最后把检索结果和实时数据组织成推理依据输出诊断报告。实操中有几个细节非常关键。第一知识库必须分层设备手册一层、历史维修记录一层、工艺标准一层、老师傅经验一层。如果不分层检索的时候容易把不同层级的信息混在一起导致结论矛盾。第二RAG检索的top_k不能设置太大我实测下来top_k在4到6之间最稳定太大会引入噪声片段反而干扰模型判断。第三实时数据的调用结果必须显式呈现在给模型的上下文里并且标注数据采集时间否则模型可能用训练时的旧知识去解释当前状态。2.2 生产排程多智能体协作订单、产能、异常各司其职生产排程是典型的多人协作场景换成多智能体特别自然。我把整个排程流程拆成四个角色订单解析Agent负责读取订单信息和交期要求产能评估Agent负责查询各产线负荷和设备状态排程优化Agent负责调用自建的排程算法生成方案异常处理Agent负责识别插单、设备故障等异常并给出调整建议。这四个Agent通过LangGraph的StateGraph编排。订单解析Agent先跑输出结构化订单信息产能评估Agent根据订单信息并行查询多条产线的产能数据排程优化Agent拿到产能数据后调用算法包如果某个环节出现异常异常处理Agent介入。这里最值得讲的是状态设计。LangGraph里的State是所有Agent共享的数据总线。我在设计State时区分了全局状态和局部状态订单信息、产线负荷、最终排程结果是全局状态所有Agent都能读而每个Agent内部的中间推理过程只放在局部不写进全局State避免状态被互相覆盖。这个设计在下文踩坑部分还会详细说。2.3 质量缺陷分析智能体把自建模型变成智能体的工具质量分析这个方向制造业企业通常已经有自己的数据模型和判断规则比如SPC过程控制模型、缺陷分类模型。智能体要做的不是取代它们而是把它们变成自己可以调用的工具。我在项目里做了这样一个闭环质检系统拍下产品图片后视觉检测模型先跑一遍分类判断是划痕、缺料还是色差这个结果传给质量缺陷分析智能体智能体再调用SPC模型检查对应工序的过程能力指数同时检索工艺标准给出缺陷归因分析。关键点在于工具封装。我写了一个Python函数封装SPC模型函数接收工序参数历史数据返回过程能力指数和判异结论。然后给这个函数加上LangChain的tool装饰器写清楚功能描述和参数说明。这样大模型读到工具描述就知道在什么场景下调用它。自建业务模型和智能体结合这个方向价值很大。传统模型只能输出一个数值智能体能把这个数值放到整个业务上下文里解释告诉现场人员这组数据意味着什么、应该怎么处理。2.4 提示词工程和工具调用的注意细节提示词这块制造业场景和通用聊天场景完全不一样。通用场景可以允许模型自由发挥制造业必须把接口规范、输出格式、安全边界写死。我的经验是系统提示词里必须包含四层内容角色定义、可用工具清单、输出格式约束、安全红线。角色定义告诉模型它是什么岗位的助手工具清单列出它能调用哪些接口输出格式约束要求它按固定结构输出诊断报告或排程建议安全红线明确禁止它执行哪些操作比如不能直接下发设备参数修改指令。温度参数我统一设置在0.1到0.3之间。制造业场景要的是稳定输出不是创造性发挥温度太高模型容易在报告里加戏。工具调用的描述信息一定要写详细。LangChain的tool装饰器里docstring就是模型理解这个工具的唯一途径。我见过很多人写查询设备状态一句话带过模型根本不知道这个工具需要传什么参数、返回什么结构。正确写法要描述清楚工具用途、每个参数的格式和取值范围、返回结果的字段含义。3. 从零搭建核心环节实战3.1 环境准备与依赖安装我用的环境是Python 3.10框架版本以当前稳定版为准。这里给出我项目里的核心依赖langchain0.3.0 langgraph0.2.0 langchain-openai0.2.0 langchain-community0.3.0 faiss-cpu1.8.0 mem00.1.0 fastapi0.115.0 uvicorn0.30.0 requests2.32.0 pydantic2.8.0模型选型上数据不出厂是红线。所以我优先用的是私有化部署的开源模型比如Qwen系列通过vLLM或者Ollama起一个OpenAI兼容接口LangChain直接对接。如果对效果要求高、网络条件允许也可以接云端大模型API但要做好数据脱敏。3.2 用LangGraph构建带记忆的Agent工作流LangGraph的核心概念是把Agent的工作流定义成一个图节点是各种操作边是操作之间的流转条件。下面是一个简化的设备故障诊断Agent示例from typing import TypedDict, Annotated from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI from langchain_core.tools import tool class AgentState(TypedDict): device_id: str fault_desc: str knowledge_docs: list realtime_data: dict diagnosis_result: str tool def get_device_realtime_data(device_id: str) - dict: 根据设备编号从MES系统获取实时运行参数返回温度、压力、电流等指标。 # 实际项目里这里是调用MES接口的代码 return {temperature: 235, pressure: 0.28, current: 12.5} def retrieve_knowledge(state: AgentState): # 检索维修知识库 docs vector_store.similarity_search(state[fault_desc], k4) return {knowledge_docs: [d.page_content for d in docs]} def call_llm(state: AgentState): model ChatOpenAI(modelqwen2.5-72b, temperature0.2) tools [get_device_realtime_data] model_with_tools model.bind_tools(tools) # 组装上下文并调用模型 ... graph StateGraph(AgentState) graph.add_node(retrieve, retrieve_knowledge) graph.add_node(llm, call_llm) graph.set_entry_point(retrieve) graph.add_edge(retrieve, llm) graph.add_edge(llm, END) app graph.compile()为什么用StateGraph而不是传统的LangChain链式调用因为真实场景里大模型可能需要先调用一次工具根据返回结果决定是否再检索一轮知识库、再调用另一个工具这是一个动态循环过程。StateGraph允许模型在某个节点内部反复思考也可以通过条件边控制流程走向。会话记忆我用Mem0做长期记忆存储。Mem0能把历史对话里的关键输入比如用户偏好的报告格式、经常查询的设备编号提取成结构化记忆下次对话时自动注入。不然对话轮次一多上下文撑爆是迟早的事。3.3 对接MES/SCADA数据工具调用的落地姿势制造业智能体最有价值的部分是能碰到真实数据。我项目中对接MES系统时写了几个标准工具函数走的是HTTP接口加签名认证。tool def query_mes_realtime(device_id: str, params: str) - dict: 从MES系统查询设备实时数据params为逗号分隔的参数代码列表如temp,press,current。 url fhttp://mes-internal/api/v1/devices/{device_id}/realtime headers {X-Auth-Token: MES_API_TOKEN} resp requests.get(url, headersheaders, params{fields: params}, timeout10) resp.raise_for_status() data resp.json() # 字段约简只保留需要的指标 return {k: v for k, v in data.items() if k in params.split(,)}这里有两个实操要点。第一接口返回的数据必须做字段约简。MES接口经常一次返回几十个字段全部塞给模型既浪费token又容易干扰判断我一般只保留当前任务需要的3到5个字段。第二连接SCADA和PLC数据时优先走OPC UA网关不要直接让智能体去读PLC寄存器安全性和兼容性都差很多。3.4 提示词和知识库的工程化细节知识库这块我踩过不少坑最典型的是分段策略。一开始我按固定字符数切分文档结果很多跟设备相关的上下文被切断了检索出来的片段语义不完整。后来改成按语义块切分设备手册按章节切维修记录按每次维修工单切工艺标准按参数类型切。配合专门的embedding模型做向量化检索质量提升非常明显。提示词上我在系统提示词里加了几条硬性约束实测很管用你必须优先使用工具获取实时数据禁止根据常识编造设备参数。如果工具返回的数据不完整需要在报告中明确标注缺失项。最终输出必须包含数据来源和时间戳。4. 现场踩坑实录与排查思路4.1 幻觉问题设备参数瞎编怎么治这是所有智能体项目里最致命的问题。大模型在没拿到真实数据的时候会一本正经地编造设备参数比如把注塑机模温说成180度实际标准是220度。我治这个问题的三板斧第一提示词明确禁止编造数据要求没有检索到数据时明确说不知道第二关键参数强制走工具调用模型输出诊断结论前必须先调用MES工具拿实时数据第三在输出端加一层规则校验比如温度值不在合理区间就直接拦截。三管齐下之后基本杜绝了瞎编参数的问题。4.2 多智能体状态同步问题多智能体协作最头疼的问题是状态互相覆盖。刚开始跑生产排程多智能体时订单解析Agent还在跑产能评估Agent已经写入了State里的排程结果字段两个Agent同时操作全局State导致数据被覆盖。解决方式是把State拆成两层。全局State只放所有Agent都要读的公共信息比如订单ID、产线清单、最终结论每个Agent自己的中间结果放局部变量跑完确认后再往全局State里写。此外我给每个Agent加了一个独立的执行日志每次状态变更都记录快照排查问题的时候能清楚看到是哪一步覆盖了哪一步。4.3 长会话记忆丢失问题智能体跑一段时间后用户经常反馈它好像忘了之前说过的要求。原因是上下文太长被截断或者模型在长对话后对早期指令的关注度衰减。我用Mem0解决了这个问题。Mem0会在对话过程中抽取关键信息比如用户目前负责哪个车间、关注哪些指标、希望报告用什么格式存成持久化记忆。下一轮对话开始前把相关记忆注入上下文相当于给智能体装了一个长期硬盘不再依赖把全部历史对话塞进上下文。4.4 安全边界与权限控制制造业智能体连接的都是生产系统安全红线一定要划清楚。我的原则是两条读操作可以自动化写操作必须人工审批。智能体可以随意查询设备实时数据、检索知识库、生成诊断报告这些没问题。但只要涉及修改工艺参数、下发控制指令、更改订单状态智能体只能生成审批单并提交给指定的负责人由人工确认后在MES系统里执行。同时每一次工具调用都会记录审计日志包含调用时间、调用参数、输入输出摘要出问题能追溯。我个人在实际操作中的体会是制造业智能体落地最难的不是模型选型也不是框架配置而是把业务流程真正吃透、把工具接口打磨稳定。模型的聪明程度只决定天花板而工具的可靠性和流程的清晰度决定了地板。单点智能体先跑通再扩展多智能体协作这个顺序一定不要跳跳过就会像我一样在联调阶段被各种状态问题折磨。最后再分享一个小技巧给每个智能体取名要规范化比如fault-diagnosis-agent、production-scheduling-agent工具函数名也统一用动词加名词的格式。调试多智能体系统时日志里一眼就能看出问题出在哪个环节这个习惯能让你省下大量排查时间。