新能源工厂要想真正吃下AI红利光有大模型远远不够关键在于怎么让一线工程师、工艺员、班组长也能快速用上AI能力。我在今年参与的几个项目中感受特别明显低代码平台和智能体Agent这两个东西叠加在一起正在把智能制造的门槛从“会写代码”拉低到“会描述问题”。尤其在前段时间跟进的一家新能源电池工厂里我们用低代码智能体的方式把设备告警分析、工艺参数寻优、排产辅助决策几个场景在几周内就做上了线这个速度放在以前用传统软件交付方式根本不敢想。这篇内容不聊宏大的数字化转型概念就把我们实际怎么选型、怎么设计智能体、怎么让它在车间里真正跑起来的过程拆开讲给同样在搞智能制造落地的朋友一个参照。1. 为什么这个时间点新能源工厂需要智能体1.1 车间里不缺数据缺的是把数据变成决策的人新能源工厂和其他制造工厂最大的区别在哪里我用一句话概括数据密度极高但决策链条极长。产线上的传感器、PLC、MES、ERP、QMS系统每天都在产生海量数据。拿我们做的这家电池厂举例仅一个电芯车间单日产生的工艺数据就有几千万条。但真正让人头疼的不是数据量而是当设备报警或者工艺指标出现波动时工程师要花大量时间去查数据、翻历史记录、找相关性。一个资深工艺工程师每天至少有三分之一的时间耗在“数据拉取-人工比对-经验判断”这件事上而且这种判断极度依赖个人经验。为什么说智能体在这个时间点迎来拐点因为大模型加上低代码平台第一次让“把老师傅的经验变成可复用、可交互的数字助理”成为可能。以前我们做一个专家系统要把工艺知识写成规则库费时费力还不好维护现在通过智能体可以直接把老师傅的分析思路用自然语言描述出来让大模型去调用工具、查询数据、执行分析这本质上是一种知识表达方式的革命。1.2 传统软件和纯AI方案各自的死穴过去几年制造企业在智能化上其实走过两条路但都卡住了。一条路是传统软件路线。无论是MES升级还是上APS系统实施周期动辄半年起步定制开发成本极高。尤其在新能源这样工艺迭代极快的行业今天刚上线的一个报表模块明天工艺一变又得改。牵一发动全身IT部门和业务部门互相拉扯。另一条路是纯AI路线。找算法团队做数据建模让AI工程师天天泡在车间里研究业务。结果发现业务问题千变万化——今天看设备振动明天看涂布厚度后天又看化成分容的容量一致性——算法团队疲于奔命每个场景都要重新做数据标注、特征工程、模型训练单场景落地成本高到离谱。智能体低代码为什么能破局核心在于这两者组合后把“AI应用”从项目制变成了搭积木。算法能力被封装成工具业务流程被编排成工作流知识沉淀成知识库交互界面通过低代码拖拽生成。一线人员不需要理解Transformer或者梯度下降只需要知道“我要问什么问题、给智能体配什么工具”。2. 智能体平台选型与整体架构设计2.1 低代码智能体平台怎么选从Dify、Coze到企业级方案聊到智能体开发目前行业内主流的路径无非三种基于开源框架比如LangChain、Spring AI自行开发、使用商业低代码智能体平台比如Dify、扣子Coze、或者使用头部云厂商的企业级AI平台。我们这次在新能源工厂的项目里最终选择了Dify作为核心平台主要基于三点考量。第一是私有化部署的友好度。新能源电池厂对数据安全要求极高工艺参数、配方数据绝对不能出车间。Dify社区版支持Docker Compose一键部署对GPU资源要求相对可控一套CPU机器加上一块消费级显卡就能跑起来这在车间IT环境里非常现实。第二是工作流编排能力。我们的智能体不只是纯对话很多场景需要调用外部API查询MES数据、调用Python脚本做计算、甚至触发PLC的指令下发这是后话目前仅做了只读类操作。Dify的工作流节点支持HTTP请求、代码执行、条件分支可以直接把一个复杂的业务逻辑可视化编排出来。第三是知识库管理和检索增强RAG的功能成熟度。我们把设备手册、工艺规范、历史异常处理记录灌进知识库Dify在文件解析、分段、向量化和检索这一套流程上做得比较顺手后续维护成本低。诚然像Coze这类云端平台在对话体验和插件生态上也很强但在工控网环境里的私有化部署会受限所以最终没进入我们的候选名单。如果你所在的场景对数据外传没有限制Coze上手更简单但制造业尤其是新能源这种敏感领域私有化几乎是硬门槛。2.2 智能体与现有系统的接口怎么打通智能体要在车间里产生真实价值必须能拿到实时数据。我们接的是MES数据库和部分设备采集网关的数据接口。这个环节有几个经验值得单独拿出来讲。首先不要一上来就想着直接写数据库。车间系统的数据表结构往往复杂且权限敏感智能体直接连库既危险又容易把系统拖垮。更稳妥的方式是对接MES已有的API服务让IT团队封装一层统一的数据服务接口智能体只通过这个标准化的HTTP接口去取数。其次要设计好权限边界。我给智能体配置的数据库账号只开放只读权限并且只能访问白名单内的表。涉及下发指令、修改参数等高危操作一律没有开放权限。在项目演示时对方工程师也问过“为什么不直接让智能体调PLC”我的建议是先让智能体把分析和建议做扎实控制动作留给人来确认。智能体给的不是“最终指令”而是“建议方案”这个边界在工业场景里必须守住。第三接口响应速度要有兜底。大模型调用链路的时延通常在几秒级别如果数据服务接口本身响应超过2秒用户体感会非常差。我们专门做了一个轻量级的数据缓存层高频查询的热点数据提前同步到Redis确保智能体取数为毫秒级返回。2.3 整体架构模型层、平台层、工具层、应用层把整个系统的架构理清楚后续扩展才能不乱。从底层往上看模型层用的是私有化部署的Qwen系列千问和本地Embedding模型。为什么没用更大的模型因为车间服务器的显卡资源有限用了量化版本部署推理速度大概在每秒十几token单轮对话2-5秒返回处于可接受范围。选型时也测过ChatGPT类的云端API效果确实好但数据出域这一关过不了只能放弃。平台层就是前面说的Dify负责工作流编排、知识库管理、Agent设计。这一层是整个体系的大脑所有智能体的生命周期管理都在这里完成。工具层是我们自定义的几个API工具MES数据查询工具、工艺参数统计工具、报警记录检索工具、设备档案查询工具。每个工具本质上是一个带参数的HTTP接口智能体根据用户的意图去决定调用哪个工具、传什么参数。应用层面向最终用户工艺工程师用的参数分析助手、设备维护人员用的故障排查助手、生产管理人员用的排产决策助手。这三类智能体在Dify里以独立应用的形式配置挂在企业微信和Web门户上用户直接对话就能用。这套架构的好处是每一层都解耦模型不好用随时换平台升级不影响工具层工具增删不需要改智能体逻辑。后续想加一个新场景只需要在工具层加一个API然后在平台层配置一个新的智能体应用一周内就能上线一个全新的AI助理。3. 三个典型制造场景的智能体落地拆解3.1 设备故障排查智能体从“翻手册”到“问一句”新能源工厂的设备种类繁杂从搅拌机、涂布机到卷绕机、化成分容柜每台设备的故障代码动辄几百个。以前维修工遇到一个不常见的报警要翻纸质手册或者问老师傅经常一等就是半小时。我们的设备故障排查智能体是怎么做的呢知识库层面把所有设备的操作手册、故障代码表、历史维修工单灌了进去。RAG检索让智能体能在几秒内找到相关章节。工具层面接入了设备历史报警接口智能体可以根据当前报警代码自动查询最近7天同类型报警的发生频率和处理记录。实际的交互效果大概是这样的车间维修工在手机端发一句“2号涂布机报E102怎么处理”智能体先调用报警检索工具查出E102在最近一个月的出现次数和常见处理方案再结合知识库里的维修手册生成操作步骤。当环境数据不足时它会主动追问“当前涂布速度是多少浆料粘度有没有波动”从而引导工人补充关键参数。这个场景落地的最大难点在于知识库的质量。一开始我们只是把手册PDF灌进去效果很一般回答经常张冠李戴。后来把历史维修工单整理成“故障现象处理步骤注意事项”的结构化文档再导入效果立刻好了很多。3.2 工艺参数寻优智能体给老师傅配了个AI参谋电池生产过程中涂布厚度、辊压压力、化成分容温度这些参数直接影响产品质量。以前工艺工程师调参数主要靠经验加DOE试验周期长、成本高。我们设计的工艺参数寻优智能体本质上是一个数据分析和知识检索的组合体。工程师描述问题“最近一周NCM811体系的涂布面密度波动变大了”智能体会自动调用工艺参数统计工具抓取对应产线、对应时间段的面密度数据计算均值、极差、标准差和CPK指标然后把统计结果和异常点位返回给工程师。这里面有个很关键的细节——Prompt设计。我们给智能体的系统指令中明确要求所有分析必须基于工具返回的实时数据不能凭空推断给出的建议必须区分“数据事实”和“经验参考”两个层次。为什么因为大模型有幻觉风险如果直接让它“分析原因并给出建议”它可能一本正经地编一个看起来合理的结论。但限定它先摆数据、再根据知识库中沉淀的工艺规范给出参考建议就能最大程度降低误导风险。这个场景跑通之后工艺团队从“靠记性、靠翻聊天记录”变成了“随时有一个懂工艺数据的参谋”。新入职的工艺员上手速度也明显加快以前要跟老师傅学半年的经验常识现在可以先问智能体再找老师傅确认关键判断。3.3 生产排产辅助智能体交期承诺不再拍脑袋新能源行业订单波动大、插单频繁生产计划员排产时最头疼的问题就是“这个单子到底能不能在交期内做完”。以前要么靠Excel手工估算要么听老师傅拍脑袋。我们做的排产辅助智能体核心是调用一个基于历史工时的产能预估API。计划员输入订单数量、产品型号、交付日期智能体自动计算标准工时、评估当前产线负荷、给出交期可行性判断并且引用类似订单的历史实际周期作为佐证。这个场景有意思的地方在于它没有做复杂的运筹优化模型而是先用智能体把信息聚合和初步推理做掉。为什么这么设计因为真正的排产优化涉及多目标约束——交期、产能、物料齐套、人员班次、换型时间这些变量之间的关系极其复杂现阶段数据基础还不够支撑一个完整的优化模型。智能体的价值是先让计划员能快速拿到一个相对靠谱的参考基准再结合人的经验去微调。不过在做这个智能体时踩过一个大坑产能预估API的历史数据颗粒度不够很多工序的时间记录是班组手工填的不准。后来我们要求计划员在QA环节对智能体的产出做反馈标注——“偏乐观”“偏保守”“基本准确”持续用反馈数据去校准API的修正系数。这个闭环机制目前还在运转随着标注数据积累预估准确率会逐步提高。4. 真实落地过程中的关键避坑指南4.1 别一上来就做“超级智能体”我们在项目启动时犯过一个典型错误——想做一个能回答工厂所有问题的“超级智能体”。结果发现需求范围收不住知识库庞大且混乱对话经常答非所问维护成本极高。后来调整为“一个场景一个智能体”的策略。设备相关的归设备智能体工艺相关的归工艺智能体排产相关的归排产智能体。每个智能体的知识库边界清晰、工具集合收敛、Prompt针对性强。用户知道自己面对的是什么工具提问引导也做得更容易。等到每个场景都稳定跑通了再考虑在应用层做一个统一入口做语义路由这是后话。这个教训我想重点说智能体的边界感比智能感更重要。一个什么都能聊的AI助手听起来很酷但在工业场景里边界清晰、能力可预期才是用户信任的前提。4.2 Prompt调优和知识库维护是持续活很多团队把智能体上线当成项目的终点这完全错了。智能体的效果从来不是一次配置出来的而是持续调出来的。我们维护频率最高的是两块Prompt模板和知识库内容。Prompt模板的调整通常来自两类情况。第一类是新发现的badcase比如用户用了一个方言词或者简称模型理解偏差我们就在系统指令里补充术语表。第二类是业务变化比如工艺部门修订了控制计划我们会同步调整智能体在某个场景下的分析口径。知识库的维护同样重要。设备手册会更新、工艺规范会换版历史的维修工单每天都在新增。我们定了一个机制每周拉取一次新增的维修工单清洗后增量导入知识库。如果没有这个机制智能体就只能靠静态的旧知识回答问题价值会随时间快速衰减。如果你没有专职的Prompt工程师我的建议是让懂业务的人来主导Prompt维护而不是让程序员来做。业务人员更清楚什么样的问题表述是高频的、什么样的回复是有用的。平台方负责把调整流程做成自助式让业务人员可以直接在后台编辑Prompt并发布。4.3 模型幻觉在工业场景里的危害必须正视前面提过幻觉问题这里再展开讲一下我们的应对方案。工业场景和聊天机器人最大的区别在于错误信息的代价是真实的——误导一次维修操作可能导致停机时间延长误导一次工艺调整可能造成整批产品报废。我们的三道防线是这样的。第一道防线系统指令约束。明确要求智能体在数据不足时必须说“信息不足建议补充XX数据”而不是强行给结论。第二道防线工具结果优先。智能体所有的量化结论必须来自工具返回的真实数据知识库只作为解释和建议的参考。第三道防线标注“置信度”。生成回答时将“数据依据”和“经验参考”分开展示经验建议部分明确提示“此为参考经验请根据现场情况判断”。这三道防线并不能100%消除幻觉但能极大降低错误决策的概率。我们在给管理层汇报时也反复强调智能体是副驾驶不是自动驾驶。这在理念上必须先对齐否则后续推广一定出问题。4.4 低代码平台的权限管理和审计日志最后这部分属于合规和技术债的范畴但重要性不低。车间环境里使用AI应用必须有完整的权限管理和审计机制。我们通过Dify的API扩展能力将用户体系对接了企业的统一身份认证不同岗位看到的智能体和数据范围不一样。工艺工程师能查工艺参数维修工能查故障知识库生产经理能看排产分析互不越权。所有对话记录都做了全量日志存储。为什么要存日志一方面是安全问题出事后可以追溯另一方面是数据资产问题用户在对话中暴露出的高频问题、分析思路都是未来优化智能体和沉淀业务知识的金矿。权限和审计必须在第一天就建好哪怕当时觉得“有点重”也不能等系统规模大了再补。智能体一旦被一线员工主动用起来数据流转量是巨大的事后补审计就像亡羊补牢代价远大于一开始就规划好。5. 现在的效果和下一步想做的事5.1 现实收益效率提升和组织知识固化目前这套系统在那边工厂已经稳定运行了三个多月接入用户一百多人。最直接的反馈是设备故障排查的平均用时从原来的二三十分钟缩短到几分钟工艺人员查历史参数分析原因的时间至少节省了六成以上。但我个人认为比效率数字更重要的是组织知识固化的价值。老师傅的经验以前都在脑子里人走了知识就没了。现在通过知识库和智能体的交互记录这些经验正在被系统性沉淀下来。哪怕未来有老员工退休新员工也能在AI助手的帮助下快速补位。另一个隐性收益是对IT团队能力的提升。以前他们觉得AI很远现在通过低代码平台亲手搭建了几个智能体之后对“AI能做什么、不能做什么”有了非常具体的认知。这种组织能力的转变比一个两个场景的落地更有长期价值。5.2 扩展方向多目标调度优化与更多产线复制下一步我们正在探索的方向是智能制造中的多目标调度优化。前面说过最初的排产智能体做的是信息聚合和辅助判断真正的优化计算还没有深入进去。多目标调度优化的核心挑战在于生产环境中有多个互相冲突的目标交期满足率、设备利用率、能耗成本、人员负荷均衡。传统做法是建数学模型用遗传算法、粒子群或强化学习去求Pareto最优解。但这类方案落地难在两点动态扰动太多插单、设备故障、物料延迟以及车间调度员对算法给出的结果信任度不足。我们的思路是用智能体作为“调度员与算法之间的翻译官”。算法负责生成多组候选排产方案智能体负责将每组方案的权衡关系、对关键指标的影响用自然语言解释给调度员听辅助人来做最终决策。人的经验负责处理算法考虑不到的业务约束算法负责给出全局视角的优化空间智能体负责把双向信息翻译到位。这个方向如果走通会是把运筹优化和智能体结合的一个有代表性的案例。同时这套平台架构也在往这个工厂的电极段、组装段、PACK段复制。我们的目标不是“为每一个车间各做一套新系统”而是通过低代码平台沉淀出一套可复用的智能体模板和工具链让新车间上线时只需要做参数微调即可快速落地。6. 如果你也想在工厂里做智能体6.1 给刚起步的团队四个建议第一从高价值低风险的场景切入。设备故障知识问答、工艺数据查询这类场景既能快速见效、又没有权责风险非常适合做第一个试点。不要一上来就挑战生产优化控制这类高风险场景那会让你在证明价值之前就被质疑淹没。第二业务人员全程参与。智能体不是IT部门自嗨的工具业务侧必须有人在项目组里。我们的经验是设立一个“AI应用BP”角色由懂业务又愿意尝鲜的员工担任负责梳理场景需求、参与Prompt设计、组织一线测试反馈。这个角色往往决定了一个智能体能不能从“能用”走向“好用”。第三指标定义要前置。上线前就说清楚这个场景要解决什么问题、用什么指标衡量成功。设备排查看平均故障处理时间参数分析看单次分析耗时排产辅助看交期预估准确率。有指标才能向管理层证明价值才能争取到后续的资源投入。第四不必一次性配齐高端硬件。初期用4090级别的消费级显卡跑量化模型足够支撑一个几十个人的车间试用。先把业务逻辑跑通、让用户习惯用起来再根据并发需求去扩容算力。算力成本不该是智能体落地的第一瓶颈流量和用户活跃才是真正决定项目生死的指标。6.2 关于长期主义的一点体会项目做久了我对“AI落地制造”的看法也从最初的技术崇拜逐渐变成了对组织、流程和人性的重新审视。技术层面低代码和智能体确实把AI应用的门槛压到了一个非常低的位置这个趋势是不可逆的。但真正决定一个工厂能不能吃到这波红利的不是它用了多强的模型、部署了多有排面的平台而是它有没有一套机制让一线员工愿意每天打开这个AI工具、把自己的经验通过对话贡献出来、并不断反馈修正系统的判断。这套机制很难靠一个技术项目的交付来建立它更像是组织管理层面的一次升级。我们在这家新能源工厂里能走到今天很大程度上是因为有一两个关键的车间负责人在最早期的试用阶段愿意忍受那些不完美的回答愿意反复给出修改建议。这种来自业务侧的耐心和包容在AI落地的过程中比任何参数调优都珍贵。如果你正准备在自己所在的工厂推动智能体落地我的建议是别急着追求技术上的“大而全”先找到那个愿意跟你一起打磨的业务伙伴从一个小而真、业务愿意用的场景开始跑通以后再快速复制。踩过的坑我写在上面了照着做能帮你少走很多弯路。
新能源工厂要想真正吃下AI红利光有大模型远远不够关键在于怎么让一线工程师、工艺员、班组长也能快速用上AI能力。我在今年参与的几个项目中感受特别明显低代码平台和智能体Agent这两个东西叠加在一起正在把智能制造的门槛从“会写代码”拉低到“会描述问题”。尤其在前段时间跟进的一家新能源电池工厂里我们用低代码智能体的方式把设备告警分析、工艺参数寻优、排产辅助决策几个场景在几周内就做上了线这个速度放在以前用传统软件交付方式根本不敢想。这篇内容不聊宏大的数字化转型概念就把我们实际怎么选型、怎么设计智能体、怎么让它在车间里真正跑起来的过程拆开讲给同样在搞智能制造落地的朋友一个参照。1. 为什么这个时间点新能源工厂需要智能体1.1 车间里不缺数据缺的是把数据变成决策的人新能源工厂和其他制造工厂最大的区别在哪里我用一句话概括数据密度极高但决策链条极长。产线上的传感器、PLC、MES、ERP、QMS系统每天都在产生海量数据。拿我们做的这家电池厂举例仅一个电芯车间单日产生的工艺数据就有几千万条。但真正让人头疼的不是数据量而是当设备报警或者工艺指标出现波动时工程师要花大量时间去查数据、翻历史记录、找相关性。一个资深工艺工程师每天至少有三分之一的时间耗在“数据拉取-人工比对-经验判断”这件事上而且这种判断极度依赖个人经验。为什么说智能体在这个时间点迎来拐点因为大模型加上低代码平台第一次让“把老师傅的经验变成可复用、可交互的数字助理”成为可能。以前我们做一个专家系统要把工艺知识写成规则库费时费力还不好维护现在通过智能体可以直接把老师傅的分析思路用自然语言描述出来让大模型去调用工具、查询数据、执行分析这本质上是一种知识表达方式的革命。1.2 传统软件和纯AI方案各自的死穴过去几年制造企业在智能化上其实走过两条路但都卡住了。一条路是传统软件路线。无论是MES升级还是上APS系统实施周期动辄半年起步定制开发成本极高。尤其在新能源这样工艺迭代极快的行业今天刚上线的一个报表模块明天工艺一变又得改。牵一发动全身IT部门和业务部门互相拉扯。另一条路是纯AI路线。找算法团队做数据建模让AI工程师天天泡在车间里研究业务。结果发现业务问题千变万化——今天看设备振动明天看涂布厚度后天又看化成分容的容量一致性——算法团队疲于奔命每个场景都要重新做数据标注、特征工程、模型训练单场景落地成本高到离谱。智能体低代码为什么能破局核心在于这两者组合后把“AI应用”从项目制变成了搭积木。算法能力被封装成工具业务流程被编排成工作流知识沉淀成知识库交互界面通过低代码拖拽生成。一线人员不需要理解Transformer或者梯度下降只需要知道“我要问什么问题、给智能体配什么工具”。2. 智能体平台选型与整体架构设计2.1 低代码智能体平台怎么选从Dify、Coze到企业级方案聊到智能体开发目前行业内主流的路径无非三种基于开源框架比如LangChain、Spring AI自行开发、使用商业低代码智能体平台比如Dify、扣子Coze、或者使用头部云厂商的企业级AI平台。我们这次在新能源工厂的项目里最终选择了Dify作为核心平台主要基于三点考量。第一是私有化部署的友好度。新能源电池厂对数据安全要求极高工艺参数、配方数据绝对不能出车间。Dify社区版支持Docker Compose一键部署对GPU资源要求相对可控一套CPU机器加上一块消费级显卡就能跑起来这在车间IT环境里非常现实。第二是工作流编排能力。我们的智能体不只是纯对话很多场景需要调用外部API查询MES数据、调用Python脚本做计算、甚至触发PLC的指令下发这是后话目前仅做了只读类操作。Dify的工作流节点支持HTTP请求、代码执行、条件分支可以直接把一个复杂的业务逻辑可视化编排出来。第三是知识库管理和检索增强RAG的功能成熟度。我们把设备手册、工艺规范、历史异常处理记录灌进知识库Dify在文件解析、分段、向量化和检索这一套流程上做得比较顺手后续维护成本低。诚然像Coze这类云端平台在对话体验和插件生态上也很强但在工控网环境里的私有化部署会受限所以最终没进入我们的候选名单。如果你所在的场景对数据外传没有限制Coze上手更简单但制造业尤其是新能源这种敏感领域私有化几乎是硬门槛。2.2 智能体与现有系统的接口怎么打通智能体要在车间里产生真实价值必须能拿到实时数据。我们接的是MES数据库和部分设备采集网关的数据接口。这个环节有几个经验值得单独拿出来讲。首先不要一上来就想着直接写数据库。车间系统的数据表结构往往复杂且权限敏感智能体直接连库既危险又容易把系统拖垮。更稳妥的方式是对接MES已有的API服务让IT团队封装一层统一的数据服务接口智能体只通过这个标准化的HTTP接口去取数。其次要设计好权限边界。我给智能体配置的数据库账号只开放只读权限并且只能访问白名单内的表。涉及下发指令、修改参数等高危操作一律没有开放权限。在项目演示时对方工程师也问过“为什么不直接让智能体调PLC”我的建议是先让智能体把分析和建议做扎实控制动作留给人来确认。智能体给的不是“最终指令”而是“建议方案”这个边界在工业场景里必须守住。第三接口响应速度要有兜底。大模型调用链路的时延通常在几秒级别如果数据服务接口本身响应超过2秒用户体感会非常差。我们专门做了一个轻量级的数据缓存层高频查询的热点数据提前同步到Redis确保智能体取数为毫秒级返回。2.3 整体架构模型层、平台层、工具层、应用层把整个系统的架构理清楚后续扩展才能不乱。从底层往上看模型层用的是私有化部署的Qwen系列千问和本地Embedding模型。为什么没用更大的模型因为车间服务器的显卡资源有限用了量化版本部署推理速度大概在每秒十几token单轮对话2-5秒返回处于可接受范围。选型时也测过ChatGPT类的云端API效果确实好但数据出域这一关过不了只能放弃。平台层就是前面说的Dify负责工作流编排、知识库管理、Agent设计。这一层是整个体系的大脑所有智能体的生命周期管理都在这里完成。工具层是我们自定义的几个API工具MES数据查询工具、工艺参数统计工具、报警记录检索工具、设备档案查询工具。每个工具本质上是一个带参数的HTTP接口智能体根据用户的意图去决定调用哪个工具、传什么参数。应用层面向最终用户工艺工程师用的参数分析助手、设备维护人员用的故障排查助手、生产管理人员用的排产决策助手。这三类智能体在Dify里以独立应用的形式配置挂在企业微信和Web门户上用户直接对话就能用。这套架构的好处是每一层都解耦模型不好用随时换平台升级不影响工具层工具增删不需要改智能体逻辑。后续想加一个新场景只需要在工具层加一个API然后在平台层配置一个新的智能体应用一周内就能上线一个全新的AI助理。3. 三个典型制造场景的智能体落地拆解3.1 设备故障排查智能体从“翻手册”到“问一句”新能源工厂的设备种类繁杂从搅拌机、涂布机到卷绕机、化成分容柜每台设备的故障代码动辄几百个。以前维修工遇到一个不常见的报警要翻纸质手册或者问老师傅经常一等就是半小时。我们的设备故障排查智能体是怎么做的呢知识库层面把所有设备的操作手册、故障代码表、历史维修工单灌了进去。RAG检索让智能体能在几秒内找到相关章节。工具层面接入了设备历史报警接口智能体可以根据当前报警代码自动查询最近7天同类型报警的发生频率和处理记录。实际的交互效果大概是这样的车间维修工在手机端发一句“2号涂布机报E102怎么处理”智能体先调用报警检索工具查出E102在最近一个月的出现次数和常见处理方案再结合知识库里的维修手册生成操作步骤。当环境数据不足时它会主动追问“当前涂布速度是多少浆料粘度有没有波动”从而引导工人补充关键参数。这个场景落地的最大难点在于知识库的质量。一开始我们只是把手册PDF灌进去效果很一般回答经常张冠李戴。后来把历史维修工单整理成“故障现象处理步骤注意事项”的结构化文档再导入效果立刻好了很多。3.2 工艺参数寻优智能体给老师傅配了个AI参谋电池生产过程中涂布厚度、辊压压力、化成分容温度这些参数直接影响产品质量。以前工艺工程师调参数主要靠经验加DOE试验周期长、成本高。我们设计的工艺参数寻优智能体本质上是一个数据分析和知识检索的组合体。工程师描述问题“最近一周NCM811体系的涂布面密度波动变大了”智能体会自动调用工艺参数统计工具抓取对应产线、对应时间段的面密度数据计算均值、极差、标准差和CPK指标然后把统计结果和异常点位返回给工程师。这里面有个很关键的细节——Prompt设计。我们给智能体的系统指令中明确要求所有分析必须基于工具返回的实时数据不能凭空推断给出的建议必须区分“数据事实”和“经验参考”两个层次。为什么因为大模型有幻觉风险如果直接让它“分析原因并给出建议”它可能一本正经地编一个看起来合理的结论。但限定它先摆数据、再根据知识库中沉淀的工艺规范给出参考建议就能最大程度降低误导风险。这个场景跑通之后工艺团队从“靠记性、靠翻聊天记录”变成了“随时有一个懂工艺数据的参谋”。新入职的工艺员上手速度也明显加快以前要跟老师傅学半年的经验常识现在可以先问智能体再找老师傅确认关键判断。3.3 生产排产辅助智能体交期承诺不再拍脑袋新能源行业订单波动大、插单频繁生产计划员排产时最头疼的问题就是“这个单子到底能不能在交期内做完”。以前要么靠Excel手工估算要么听老师傅拍脑袋。我们做的排产辅助智能体核心是调用一个基于历史工时的产能预估API。计划员输入订单数量、产品型号、交付日期智能体自动计算标准工时、评估当前产线负荷、给出交期可行性判断并且引用类似订单的历史实际周期作为佐证。这个场景有意思的地方在于它没有做复杂的运筹优化模型而是先用智能体把信息聚合和初步推理做掉。为什么这么设计因为真正的排产优化涉及多目标约束——交期、产能、物料齐套、人员班次、换型时间这些变量之间的关系极其复杂现阶段数据基础还不够支撑一个完整的优化模型。智能体的价值是先让计划员能快速拿到一个相对靠谱的参考基准再结合人的经验去微调。不过在做这个智能体时踩过一个大坑产能预估API的历史数据颗粒度不够很多工序的时间记录是班组手工填的不准。后来我们要求计划员在QA环节对智能体的产出做反馈标注——“偏乐观”“偏保守”“基本准确”持续用反馈数据去校准API的修正系数。这个闭环机制目前还在运转随着标注数据积累预估准确率会逐步提高。4. 真实落地过程中的关键避坑指南4.1 别一上来就做“超级智能体”我们在项目启动时犯过一个典型错误——想做一个能回答工厂所有问题的“超级智能体”。结果发现需求范围收不住知识库庞大且混乱对话经常答非所问维护成本极高。后来调整为“一个场景一个智能体”的策略。设备相关的归设备智能体工艺相关的归工艺智能体排产相关的归排产智能体。每个智能体的知识库边界清晰、工具集合收敛、Prompt针对性强。用户知道自己面对的是什么工具提问引导也做得更容易。等到每个场景都稳定跑通了再考虑在应用层做一个统一入口做语义路由这是后话。这个教训我想重点说智能体的边界感比智能感更重要。一个什么都能聊的AI助手听起来很酷但在工业场景里边界清晰、能力可预期才是用户信任的前提。4.2 Prompt调优和知识库维护是持续活很多团队把智能体上线当成项目的终点这完全错了。智能体的效果从来不是一次配置出来的而是持续调出来的。我们维护频率最高的是两块Prompt模板和知识库内容。Prompt模板的调整通常来自两类情况。第一类是新发现的badcase比如用户用了一个方言词或者简称模型理解偏差我们就在系统指令里补充术语表。第二类是业务变化比如工艺部门修订了控制计划我们会同步调整智能体在某个场景下的分析口径。知识库的维护同样重要。设备手册会更新、工艺规范会换版历史的维修工单每天都在新增。我们定了一个机制每周拉取一次新增的维修工单清洗后增量导入知识库。如果没有这个机制智能体就只能靠静态的旧知识回答问题价值会随时间快速衰减。如果你没有专职的Prompt工程师我的建议是让懂业务的人来主导Prompt维护而不是让程序员来做。业务人员更清楚什么样的问题表述是高频的、什么样的回复是有用的。平台方负责把调整流程做成自助式让业务人员可以直接在后台编辑Prompt并发布。4.3 模型幻觉在工业场景里的危害必须正视前面提过幻觉问题这里再展开讲一下我们的应对方案。工业场景和聊天机器人最大的区别在于错误信息的代价是真实的——误导一次维修操作可能导致停机时间延长误导一次工艺调整可能造成整批产品报废。我们的三道防线是这样的。第一道防线系统指令约束。明确要求智能体在数据不足时必须说“信息不足建议补充XX数据”而不是强行给结论。第二道防线工具结果优先。智能体所有的量化结论必须来自工具返回的真实数据知识库只作为解释和建议的参考。第三道防线标注“置信度”。生成回答时将“数据依据”和“经验参考”分开展示经验建议部分明确提示“此为参考经验请根据现场情况判断”。这三道防线并不能100%消除幻觉但能极大降低错误决策的概率。我们在给管理层汇报时也反复强调智能体是副驾驶不是自动驾驶。这在理念上必须先对齐否则后续推广一定出问题。4.4 低代码平台的权限管理和审计日志最后这部分属于合规和技术债的范畴但重要性不低。车间环境里使用AI应用必须有完整的权限管理和审计机制。我们通过Dify的API扩展能力将用户体系对接了企业的统一身份认证不同岗位看到的智能体和数据范围不一样。工艺工程师能查工艺参数维修工能查故障知识库生产经理能看排产分析互不越权。所有对话记录都做了全量日志存储。为什么要存日志一方面是安全问题出事后可以追溯另一方面是数据资产问题用户在对话中暴露出的高频问题、分析思路都是未来优化智能体和沉淀业务知识的金矿。权限和审计必须在第一天就建好哪怕当时觉得“有点重”也不能等系统规模大了再补。智能体一旦被一线员工主动用起来数据流转量是巨大的事后补审计就像亡羊补牢代价远大于一开始就规划好。5. 现在的效果和下一步想做的事5.1 现实收益效率提升和组织知识固化目前这套系统在那边工厂已经稳定运行了三个多月接入用户一百多人。最直接的反馈是设备故障排查的平均用时从原来的二三十分钟缩短到几分钟工艺人员查历史参数分析原因的时间至少节省了六成以上。但我个人认为比效率数字更重要的是组织知识固化的价值。老师傅的经验以前都在脑子里人走了知识就没了。现在通过知识库和智能体的交互记录这些经验正在被系统性沉淀下来。哪怕未来有老员工退休新员工也能在AI助手的帮助下快速补位。另一个隐性收益是对IT团队能力的提升。以前他们觉得AI很远现在通过低代码平台亲手搭建了几个智能体之后对“AI能做什么、不能做什么”有了非常具体的认知。这种组织能力的转变比一个两个场景的落地更有长期价值。5.2 扩展方向多目标调度优化与更多产线复制下一步我们正在探索的方向是智能制造中的多目标调度优化。前面说过最初的排产智能体做的是信息聚合和辅助判断真正的优化计算还没有深入进去。多目标调度优化的核心挑战在于生产环境中有多个互相冲突的目标交期满足率、设备利用率、能耗成本、人员负荷均衡。传统做法是建数学模型用遗传算法、粒子群或强化学习去求Pareto最优解。但这类方案落地难在两点动态扰动太多插单、设备故障、物料延迟以及车间调度员对算法给出的结果信任度不足。我们的思路是用智能体作为“调度员与算法之间的翻译官”。算法负责生成多组候选排产方案智能体负责将每组方案的权衡关系、对关键指标的影响用自然语言解释给调度员听辅助人来做最终决策。人的经验负责处理算法考虑不到的业务约束算法负责给出全局视角的优化空间智能体负责把双向信息翻译到位。这个方向如果走通会是把运筹优化和智能体结合的一个有代表性的案例。同时这套平台架构也在往这个工厂的电极段、组装段、PACK段复制。我们的目标不是“为每一个车间各做一套新系统”而是通过低代码平台沉淀出一套可复用的智能体模板和工具链让新车间上线时只需要做参数微调即可快速落地。6. 如果你也想在工厂里做智能体6.1 给刚起步的团队四个建议第一从高价值低风险的场景切入。设备故障知识问答、工艺数据查询这类场景既能快速见效、又没有权责风险非常适合做第一个试点。不要一上来就挑战生产优化控制这类高风险场景那会让你在证明价值之前就被质疑淹没。第二业务人员全程参与。智能体不是IT部门自嗨的工具业务侧必须有人在项目组里。我们的经验是设立一个“AI应用BP”角色由懂业务又愿意尝鲜的员工担任负责梳理场景需求、参与Prompt设计、组织一线测试反馈。这个角色往往决定了一个智能体能不能从“能用”走向“好用”。第三指标定义要前置。上线前就说清楚这个场景要解决什么问题、用什么指标衡量成功。设备排查看平均故障处理时间参数分析看单次分析耗时排产辅助看交期预估准确率。有指标才能向管理层证明价值才能争取到后续的资源投入。第四不必一次性配齐高端硬件。初期用4090级别的消费级显卡跑量化模型足够支撑一个几十个人的车间试用。先把业务逻辑跑通、让用户习惯用起来再根据并发需求去扩容算力。算力成本不该是智能体落地的第一瓶颈流量和用户活跃才是真正决定项目生死的指标。6.2 关于长期主义的一点体会项目做久了我对“AI落地制造”的看法也从最初的技术崇拜逐渐变成了对组织、流程和人性的重新审视。技术层面低代码和智能体确实把AI应用的门槛压到了一个非常低的位置这个趋势是不可逆的。但真正决定一个工厂能不能吃到这波红利的不是它用了多强的模型、部署了多有排面的平台而是它有没有一套机制让一线员工愿意每天打开这个AI工具、把自己的经验通过对话贡献出来、并不断反馈修正系统的判断。这套机制很难靠一个技术项目的交付来建立它更像是组织管理层面的一次升级。我们在这家新能源工厂里能走到今天很大程度上是因为有一两个关键的车间负责人在最早期的试用阶段愿意忍受那些不完美的回答愿意反复给出修改建议。这种来自业务侧的耐心和包容在AI落地的过程中比任何参数调优都珍贵。如果你正准备在自己所在的工厂推动智能体落地我的建议是别急着追求技术上的“大而全”先找到那个愿意跟你一起打磨的业务伙伴从一个小而真、业务愿意用的场景开始跑通以后再快速复制。踩过的坑我写在上面了照着做能帮你少走很多弯路。
 看懂 Go 的类型系统)
