一个有意思的现象很多新能源工厂的MES、SCADA、设备管理系统买了一堆设备联网率也早就过了90%但走进车间调度员面前仍然放着一张手写的排产表质检班长靠手机拍下SPC曲线再发到微信群里问“这个趋势正不正常”。设备数据是有了可数据到决策之间始终隔着一层“没人愿意写、也写不明白”的逻辑。这层逻辑恰恰是智能制造喊了很多年但没有真正落地的原因。过去两年我做新能源电池、光伏组件工厂的数字化项目越来越明显地感觉到低代码开发平台和AI智能体Agent正在把这条路补上。低代码让工艺、设备、质量的人能自己搭应用智能体让系统具备了“看懂数据、给出建议、调用工具”的能力两个东西叠加在一起解决的不再是采集问题而是车间里最难啃的“决策问题”。这篇文章就围绕我在新能源工厂里的落地经验把这套打法从头拆一遍包括选型、步骤、踩坑和边界。1. 新能源车间里真正缺的不是自动而是决策1.1 设备联网率再高MES旁边还是那张手写排产表我先说一个大多数工厂数字化项目的共性问题大家习惯性地把精力花在“采”和“存”上花在“用”上的资源少得可怜。很多项目团队一进场就忙着接PLC、接传感器、上采集网关费了很大劲把几千个点位的数据汇到了实时数据库里。这项工作有没有价值有价值但做完之后你会发现车间该乱还是乱。设备OEE掉了系统能在趋势图上看到一个明显的下降但没人告诉你为什么降、先查哪里、这个变化和昨天换了哪种来料批次有没有关系。MES里有工单、有报工、有检验记录可那都是事后录入的结果真正发生调度冲突、设备报警、质量波动时现场还是靠班长喊、靠老师傅猜。这不是一家的问题。新能源行业前几年扩产太快产能爬坡的压力下车间里的管理系统基本都是“应付上线”的状态。上线归上线日常运作还是那套经验驱动的老路子。我经常跟客户说一句话你的工厂不是没有数字化是没有“决策数字化”。1.2 新能源制造的特殊性迭代快、卡点多、追溯长新能源工厂比传统制造业更迫切地需要决策层的智能化原因是这三个特点第一工艺迭代快。电池配方调整、极片厚度变更、焊接参数优化这些改动频率远高于传统零部件工厂。每次工艺变更都会连带影响排产、质检标准和设备参数靠纸质通知或会议纪要往下传必然出现信息衰减。第二工艺卡点多。以电池PACK线为例电芯来料分选、模组焊接、拧紧扭矩、气密性测试、EOL测试每一个环节都有大量需要靠经验判断的“隐性标准”。老师傅知道某个焊接飞溅声音听起来不对就该停机但这种知识很难写进SOP也没法用传统报表系统表达。第三质量追溯链条长。从电芯到模组到PACK再到整车或储能电站追溯粒度要求到单电芯级。一旦出问题需要快速定位是哪一批、哪台设备、哪个参数窗口出了问题。没有智能化的分析能力纯靠人去数据库里翻效率极低。这些特点决定了新能源工厂需要的不是又一个报表工具而是一个能理解上下文、能定位问题、能给出行动建议的“数字助手”。这就是智能体能派上用场的地方。1.3 为什么说智能体是拐点它不再是报表工具而是“代办的助手”我理解很多工厂对AI的印象还停留在“智能客服”水平。你问它一个问题它给一段回答就这样。这种AI在车间里毫无价值因为工厂要的不是回答是结果。智能体不同。智能体的核心是“能干活”你告诉它“帮我看一下今天A线产能为什么掉了”它不是给你一段包含各种可能性的分析报告而是自动去查生产工单、设备报警记录、停机日志对比历史数据最后告诉你“大概率是下午2点到4点涂布机频繁报警导致报警代码E210对应的是涂布头温度波动和昨天更换的浆料批次可能有关建议优先排查”。能说出这句话靠的不是一个大模型而是一整套系统低代码平台里沉淀的业务流程、数据平台里的统一数据、RAG知识库里的历史处理记录、Agent框架里编排好的工具调用链。把这套东西搭起来之后工厂里那些高频、重复、又有一定判断复杂度的决策才真正找到了替代方案。2. 低代码平台与智能体在智能制造里怎么分工2.1 低代码擅长的事让业务人员把流程“搭”出来先冷静说一句低代码不是新鲜词在制造领域也谈不上颠覆但它在智能体时代重新有了价值。低代码擅长解决的是“业务应用快速交付”的问题。传统方式下车间想上一个异常提报流程IT排期两个月需求评审两轮等系统上线问题早变样了。低代码平台里设备工程师自己拖拖拽拽半天就能搭出一个“异常上报自动通知闭环确认”的应用。它不完美但它能跑、能用、能解决问题。更重要的一点是低代码应用会成为智能体的“手和脚”。Agent读懂了数据、得出了判断最终要把结果落到业务流程里比如创建一张异常工单、更新一条设备状态、通知到对应负责人。这些动作如果靠Agent直接对接MES开发量巨大但落在低代码平台的开放接口上就简单很多。我在项目里的习惯是流程编排全放低代码平台Agent只负责“判断”和“发起”执行交给低代码里的流程去处理。低代码还有一个容易被忽视的价值可编辑、可调试。低代码平台里的ECharts图表配置、表单字段、审批链都是即改即生效的这让业务人员和Agent之间的“对齐成本”变得很低。2.2 智能体擅长的事让系统具备解读和执行能力我把工厂里适用的智能体分成三类先看一张表。类型典型能力适用场景技术底座知识问答型智能体检索SOP、工艺文件、异常处理记录回答自然语言问题新人培训、标准查询RAG向量库任务执行型智能体理解指令调用系统API完成任务自动生成质检报告、创建维修工单Agent框架低代码API分析决策型智能体分析数据、定位根因、给出建议设备告警诊断、排产建议、能耗调优大模型数据分析组件第一类最容易做价值也相对有限第二类和第三类是智能制造里真正的增量。它们不是“问答机器人”而是“会干活的数字员工”。以设备告警诊断为例。传统系统只能做到“报警弹窗”好一点的能做规则联动比如温度连续三次超限就停机。但工程师接到报警后依然要自己翻历史曲线、查同型号设备此前的处理记录、对照工艺规范判断严重程度。这个“翻找判断”的过程正是分析决策型智能体能替代的。2.3 被忽略的数据连接层没有这一层两个都白搭低代码和应用层再强数据不打通就是空中楼阁。我做项目的时候强制要求在架构层面先明确数据流向设备层PLC、传感器、检测仪通过OPC-UA或MQTT协议接入采集网关网关把数据清洗后写入实时数据库或时序数据库MES、ERP、QMS这些系统的数据则通过API或数据库同步汇聚到数据中台。低代码平台连的是数据中台的视图和APIAgent连的也是同一套数据服务。这么做最大的好处是业务人员和Agent看到的是同一份数据、同一个数据口径避免了“报表上数据打架”“Agent结论和现场对不上”这类尴尬问题。很多智能体项目失败不是模型不行是连接层没做好。Agent想查一个工单状态数据库连不上想调设备参数接口没授权想读工艺文件文档散落在各人电脑里。这些连接问题不解决模型再聪明也白搭。3. 落地实操以新能源电池PACK线为例的完整步骤3.1 场景筛选不是所有工序都适合先上智能体我先说一个大概率会踩的坑项目组一上来就想做“车间大脑”想用一个Agent管整条线。这种想法在现阶段基本做不成。智能体的可靠性是逐步提升的你要让它先从一个小闭环开始。我在PACK线上的场景筛选逻辑主要看三个维度数据完整度这个工序有没有稳定的自动化数据采集如果还要人工抄数先不上Agent先把数据补上。规则明确度这个判断的边界是否清晰如果连老师傅都说不清判据Agent更学不会。人工经验依赖度这个环节是不是虽然有经验成分但经验相对稳定、可以被沉淀按这个标准选出来的候选场景通常是电芯来料分选参数复核、设备常见故障诊断、能耗异常检测、质检报告解读。这些场景规则相对清晰、数据质量够用、经验可以沉淀适合作为智能体的第一个落地场景。而那些还在频繁试验新工艺、参数窗口本身不稳定、行业里都没有标准答案的环节不要急着上Agent。原因很简单没有人能对“连专家都不确定的问题”给出稳定的智能体输出。3.2 打通底层数据先把数据变成“事件”选定场景之后下一步不是训练模型而是把数据工程做好。以“设备故障诊断”这个Agent为例它需要消费哪些数据不是几千个原始点位而是能被理解的事件和对象。我把数据清洗加工成几张“事件表”设备报警事件表报警代码、发生时间、恢复时间、所属工段。工单执行事件表工单号、产品型号、计划数量、实际产出、开始/结束时间。质检异常事件表异常类型、不良数、工位/设备、发现时间。停机事件表停机类型、时长、操作人员备注。这些表是低代码看板和Agent共同的数据源。清洗逻辑不复杂核心是“把传感器数据变成业务语言”把时间戳对齐、把点位映射到设备对象、把报警代码翻译成工段术语。这一步工作量不小但决定了后面所有工作的质量。我在项目里通常还会做一件事把历史异常处理记录整理成结构化知识。比如“E210报警涂布头温度波动浆料批次变更”这条经验老师傅知道但没写下来。我们把这类记录补录进知识库并且标注好对应的设备、现象、原因、处理动作后面Agent回答问题时才能引用到真正的经验。3.3 用低代码搭出执行层看板、工单、流程闭环数据就绪之后先用低代码平台搭一套“能跑起来”的执行层应用。我习惯按三个模块来搭生产驾驶舱PC端车间大屏展示当班产量、设备OEE、在制品状态、质量缺陷帕累托图、能耗趋势。图表用低代码平台里的ECharts组件配置基本不用写代码拖拽绑定数据源就行。关键是可以随时改今天车间想看“各线一次良率对比”明天想看“不同班次生产效率差异”在平台里调一下维度就出来了不用再走开发排期。异常闭环模块扫码报异常、拍照上传、自动通知责任班组、处理结果回填、超时升级。这个流程用低代码的表单审批链就能搭完。它的价值在于每一条异常最后都会沉淀为一条带处理结果的结构化记录这些记录以后就是Agent的知识来源。质量追溯查询输入电芯条码或工单号能一路查到原材料批次、对应设备参数、质检数据。这个模块的数据来自MES和检测设备低代码平台通过API对接把原本要IT协助才能查的东西变成业务人员自己就能点出来的功能。这三块搭完之后工厂就已经有了一个“数字化运营骨架”。这个时候再上智能体你会发现它不再是飘在真空里的东西而是长在这个骨架上、能真正干活的帮手。3.4 部署智能体先处理高频但重复的“判断”执行层跑通之后我开始部署智能体优先级是先处理高频但重复的判断。三个典型示例第一个是“设备告警分诊Agent”。它订阅报警事件表对每一条报警判断严重级别、可能原因、建议处置动作然后把结果推送到低代码异常闭环模块自动生成带AI建议的工单。老师傅只需要确认或修改而不是从零开始排查。第二个是“排产建议Agent”。它在每天早晨根据当日工单、设备状态、人员出勤、物料齐套情况给出一个排产建议顺序和换线时间建议。传统排产依赖计划员人工盯Excel现在Agent可以几秒钟给出版本A/B方案计划员直接决策或者微调。第三个是“质检报告解读Agent”。SPC图、CPK值这些数据已经有很多系统在做但系统不会告诉你“这个趋势说明什么”。Agent自动拉取最近一周的检测数据输出一份自然语言版的趋势判断哪个参数在恶化、可能和哪台设备的哪个参数联动、建议排查方向。这三个Agent的共同特点是不直接产生动作而是生成“建议”并落到低代码平台里。建议必须经过责任人的确认才会真正执行这个设计非常关键。3.5 闭环设计建议、审批、执行、回库智能体落地的成败最终看闭环。没有闭环Agent分析得再准也只是个高级报警器。闭环的流程是Agent生成建议后通过API调用低代码平台的接口创建待办任务责任人在低代码应用里看到建议、确认或修改确认后的动作触发低代码流程执行创建工单、修改排程、通知相关人员执行结果回到数据平台Agent下一次分析时就会把“上一轮结果”当成上下文参考。这个闭环里有一个人机分工的原则Agent负责“提建议”人负责“做决策”。不是人不信任Agent而是工业场景里责任主体必须是人的角色。后面我会再展开讲这个边界怎么守。4. 智能体在工厂落地的关键工程点模型、知识库与验证4.1 大模型怎么选云端API、私有化部署还是轻量本地模型选模型是很多团队容易卡住的第一关。我给一个简化但实用的选型逻辑对比如下方案优点缺点适用情况云端大模型API效果最好、开发最快、无需运维数据出园区合规风险、时延、调用费数据不敏感、验证期跑通流程私有化部署大模型数据安全、可控GPU成本高、运维复杂、模型版本更新慢有合规要求、长期规模使用轻量本地模型部署简单、响应快、成本低推理能力弱、复杂任务效果一般任务简单、响应实时性要求高我的建议很直接初期验证阶段优先用云端API目的是快速验证场景价值和业务效果别上来就花几十万买GPU服务器跑通之后再根据数据合规要求评估是否私有化。如果确实有数据出厂限制也可以从一开始就在私有化环境里做但要准备好工程投入。还有一个容易被忽略的细节边缘侧的轻量模型和云端大模型可以搭配使用。比如用轻量模型做现场的低时延判断例如对异常描述做意图识别用云端大模型做复杂的根因分析。这种混合架构在产线上更实用。4.2 工厂知识库把老师傅的经验变成可检索的资产大模型出厂时不懂你工厂的SOP、不懂你设备的报警代码、不懂你这个车间的生产节奏所以知识库几乎决定了一个工厂智能体好不好用。我梳理下来的知识库内容至少包括四类工艺类SOP文件、工艺参数规范、配方变更记录。设备类设备手册、故障排除指南、历史报警处理记录。质量类缺陷判定标准、客户质量标准、历史质量分析报告。管理类异常上报流程、交接班制度、应急预案。知识库建设不要追求“大而全”要围绕你选定的智能体场景来组织。比如设备诊断Agent需要的是设备手册和故障处理案例排产Agent需要的是产能模型和约束规则。每个Agent接一个小而专的知识库效果比一个大而杂的库好得多查询精准度也更高。RAG检索增强生成是实现知识库问答的主流方式先把文档切块、向量化存进向量库Agent收到问题时先从向量库检索相关片段再让大模型基于检索结果生成回答。关键词是“带引用回答”答案下面必须附上来源文档方便人去核实这一点在工业场景里是刚需。4.3 提示词与行动层让Agent不仅会说话还会办事很多团队把Agent做成了“只会打字的秘书”核心问题是没给它接行动层。Agent框架比如Dify这类平台上直接用或者用开源的Agent框架自建里都有一个工具调用机制你可以给Agent注册一批“工具”每个工具就是一个可执行的函数或API接口。Agent在推理过程中会判断“我需要查一下工单状态”然后调用一个低代码平台提供的“查询工单详情”接口拿到结果后继续推理最后生成结论。我给一个简化示意假设Agent需要调用低代码平台的API创建异常工单POST /api/agent/tasks { title: AI建议涂布头温度波动异常排查, priority: high, type: 设备诊断, description: Agent分析发现E210报警频次升高建议优先检查涂布头加热模块..., suggestedAction: check_heating_module, suggestedOwner: 设备二组, source: agent_recommendation, confidence: 0.87 }真正的关键点在于接口是低代码平台提供的流程是低代码平台编排的Agent只是“决策大脑”。两套系统通过API衔接边界清晰低代码管流程和数据Agent管理解和建议。这个架构的好处是即使Agent出错了也不会绕过流程不会直接动设备风险可控。当然非常底层的“AI直接生成PLC代码”目前也开始有人尝试了。比如根据工艺需求生成某个控制逻辑的PLC程序再用仿真环境验证。这个方向很有意思但离大规模生产应用还有距离我的态度是“可以关注、别急着上产线”。4.4 验证体系从“演示不错”到“产线敢用”需要经历的几个阶段智能体项目最忌讳的就是Demo阶段看起来很好、一上产线就没人用。我从实践中总结了一套分阶段的验证方法第一阶段叫“影子模式”。Agent在后台运行它的判断和建议不出现在生产流程里只是同步存一份记录。这个阶段的作用是积累真实数据用来评估Agent的判断准确率。拿故障诊断Agent来说它会生成建议但建议不发给任何人等人工处理完毕后我们再比对Agent建议和处理结果的一致性。这个阶段持续两周到一个月。第二阶段叫“建议模式”。Agent的建议开始推送到低代码应用里但只作为参考责任人可以不采纳。这时要统计建议采纳率、建议有效率。如果采纳率高说明Agent的判断已经靠谱了如果低就回头看知识库和数据链路。第三阶段叫“授权模式”。对特定场景和特定Agent允许自动执行低风险动作比如自动创建巡检工单、自动发送通知。仍然不允许Agent触碰高风险动作比如直接修改设备参数、直接停线。整个验证过程中最核心的指标不是技术指标而是“业务端的采纳率”。一个Agent再智能只要业务人员不愿意用价值就是零。5. 踩过的坑与必须守住的底线5.1 坑一低代码系统和MES做成两座孤岛下面这条是我踩了不止一次的坑。低代码平台开发快业务人员用得开心但它如果不受控地膨胀就会在MES之外长出一套“影子系统”。部门间数据口径不一致同一台设备的OEE在MES里是85%、在低代码看板里是79%两边都查得到谁都不知道该信谁。解决的办法是在一开始就约定数据模型和同步机制。低代码平台里凡是涉及核心指标的字段必须使用数据中台里的统一字典凡是业务结果数据必须双向回写。简单说低代码平台可以快速建应用但不能自成一套数据体系。5.2 坑二智能体一本正经地胡说八道大模型幻觉在任何领域都是风险但工业领域这个问题会被放大。在办公室里聊天答错了无非是重说一遍在车间里一句话给错参数可能直接影响产品质量。我遇到过一个小案例某个质检解读Agent在生成报告时把“极片厚度公差±0.02mm”写成了“±0.2mm”大概是把上下文里的单位搞混了。这个错误从技术上看很典型但如果不被检查出来后果不堪设想。应对幻觉我总结了几条硬规则数值型结论必须做规则校验Agent输出里的每个关键数值都要和来源数据比对不一致就报错。必须附引用来源回答里的每一条判断都要给出数据出处或文档来源方便人核实。关键决策必须有人审批建议好自动执行不行。让责任人做最终确认。对低置信度场景主动说“不知道”让Agent在不确定性高的时候明确说出“该结论置信度较低需人工复核”而不是硬编一个看似合理的答案。5.3 底线设备控制和安全绝不能松这是整个体系里最不能妥协的地方也是我在每次启动会都会反复讲的一条原则Agent和低代码应用可以碰数据层和应用层但绝对不能直接碰设备控制层。设备安全回路、急停逻辑、联动保护这些依然由PLC硬逻辑实现Agent永远没有权限、也没有接口去修改这些逻辑。即使未来技术更成熟这条边界也建议保留。工业场景的安全性靠的不是AI的“聪明”而是工程的“冗余”。AI可以是辅助决策的工具但不该成为安全链路上的一环。数据安全也需要分级管理。不同岗位的人能看到的Agent结果、能调用的工具权限都要分开。最低权限原则在数字系统里和物理安全同等重要。5.4 组织上的坑AI项目不能只靠IT和算法团队我见过太多AI项目死于“IT和算法团队自嗨”。大模型能力再强如果工艺工程师不参与、设备工程师不买账、一线操作工不会用项目就是做成了PPT里的亮点也落不了地。低代码平台在这里有一个隐性的巨大价值它把业务人员从“使用者”变成了“共建者”。工艺工程师能自己在低代码平台上调整看板、修改流程这让他觉得系统是自己的工具而不是IT强加的系统。参与感直接影响采纳度这是组织层面我最深的感受。6. 从单个智能体到智能体协同开启新能源工厂的下一步6.1 多智能体协同的一个示例场景单个Agent跑通之后自然会走向多Agent协同。以PACK线换型为例我设想并验证过的协同场景大致是这样产线从A型号切换到B型号时排产Agent自动计算最优换型时间点、输出新排程建议排程变更的消息转发给物流Agent物流Agent重新调度AGV的配料顺序质检Agent收到换型信号后自动切换抽检规则和质量控制计划设备Agent结合新工艺参数提醒产线工程师调整涂布/焊接参数窗口。这个协同不是靠一个“超级大脑”完成的而是多个Agent各管一段、通过事件消息机制配合。低代码平台在这里又起到中心枢纽作用Agent之间不直接点对点通信而是通过低代码平台的消息中心/事件总线传递指令这样每一个动作都可追溯、可撤回、可审计。6.2 组织与人才智能体工程师和场景分析师会成为新岗位智能化转型必然会改变工厂的岗位结构。我的观察是第一批受益的是那些掌握工艺经验又愿意学新工具的人。以后工厂里会出现一个“场景分析师”的角色他不一定是编程高手但要懂业务逻辑、懂数据字段、会配置智能体、会用低代码搭流程。这种人比单纯的AI工程师更稀缺也更值钱。这个角色培养之所以可行正是因为低代码和成熟智能体平台已经把技术门槛压得很低了。以前要造一个能处理业务的软件可能需要一个K人的开发团队现在一个人加上一个好的平台就能搞定过去需要IT、算法、业务三方协作的事。6.3 我对后续演进的个人看法做了这么多新能源工厂项目后我越来越深的感受是智能体的价值不在“智能”本身而在“被信任”。被信任的前提是稳定、可解释、并且尊重人类的决策权。所以我不建议一上来就追求全自动化而是把智能体定位成一个“越用越好的助手”最初它帮你查资料、做分析慢慢地你愿意把更多重复判断交给它等它在大量真实反馈中沉淀得足够好你再给它授权执行一些低风险动作。这条路不会像宣传片里那样激进但每一步都扎实。对于还在观望的工厂我的建议也很简单把手上的数字化基础先打牢把数据治理、流程梳理、知识沉淀这几件事做好。智能体拐点来临的时候只有数据基础扎实的工厂能接得住。现在开始做已经不算早了。再补一句个人体会这个方向最有成就感的一刻不是看板跑通的时候也不是Agent给出正确诊断的时候而是车间老师傅在用了半年之后私下跟我说“这个AI偶尔还真能帮上忙”。团队和数字系统之间建立起那种信任感才是整个项目真正跑通的标志。 低代码+AI智能体：打通新能源工厂的“决策最后一公里”
一个有意思的现象很多新能源工厂的MES、SCADA、设备管理系统买了一堆设备联网率也早就过了90%但走进车间调度员面前仍然放着一张手写的排产表质检班长靠手机拍下SPC曲线再发到微信群里问“这个趋势正不正常”。设备数据是有了可数据到决策之间始终隔着一层“没人愿意写、也写不明白”的逻辑。这层逻辑恰恰是智能制造喊了很多年但没有真正落地的原因。过去两年我做新能源电池、光伏组件工厂的数字化项目越来越明显地感觉到低代码开发平台和AI智能体Agent正在把这条路补上。低代码让工艺、设备、质量的人能自己搭应用智能体让系统具备了“看懂数据、给出建议、调用工具”的能力两个东西叠加在一起解决的不再是采集问题而是车间里最难啃的“决策问题”。这篇文章就围绕我在新能源工厂里的落地经验把这套打法从头拆一遍包括选型、步骤、踩坑和边界。1. 新能源车间里真正缺的不是自动而是决策1.1 设备联网率再高MES旁边还是那张手写排产表我先说一个大多数工厂数字化项目的共性问题大家习惯性地把精力花在“采”和“存”上花在“用”上的资源少得可怜。很多项目团队一进场就忙着接PLC、接传感器、上采集网关费了很大劲把几千个点位的数据汇到了实时数据库里。这项工作有没有价值有价值但做完之后你会发现车间该乱还是乱。设备OEE掉了系统能在趋势图上看到一个明显的下降但没人告诉你为什么降、先查哪里、这个变化和昨天换了哪种来料批次有没有关系。MES里有工单、有报工、有检验记录可那都是事后录入的结果真正发生调度冲突、设备报警、质量波动时现场还是靠班长喊、靠老师傅猜。这不是一家的问题。新能源行业前几年扩产太快产能爬坡的压力下车间里的管理系统基本都是“应付上线”的状态。上线归上线日常运作还是那套经验驱动的老路子。我经常跟客户说一句话你的工厂不是没有数字化是没有“决策数字化”。1.2 新能源制造的特殊性迭代快、卡点多、追溯长新能源工厂比传统制造业更迫切地需要决策层的智能化原因是这三个特点第一工艺迭代快。电池配方调整、极片厚度变更、焊接参数优化这些改动频率远高于传统零部件工厂。每次工艺变更都会连带影响排产、质检标准和设备参数靠纸质通知或会议纪要往下传必然出现信息衰减。第二工艺卡点多。以电池PACK线为例电芯来料分选、模组焊接、拧紧扭矩、气密性测试、EOL测试每一个环节都有大量需要靠经验判断的“隐性标准”。老师傅知道某个焊接飞溅声音听起来不对就该停机但这种知识很难写进SOP也没法用传统报表系统表达。第三质量追溯链条长。从电芯到模组到PACK再到整车或储能电站追溯粒度要求到单电芯级。一旦出问题需要快速定位是哪一批、哪台设备、哪个参数窗口出了问题。没有智能化的分析能力纯靠人去数据库里翻效率极低。这些特点决定了新能源工厂需要的不是又一个报表工具而是一个能理解上下文、能定位问题、能给出行动建议的“数字助手”。这就是智能体能派上用场的地方。1.3 为什么说智能体是拐点它不再是报表工具而是“代办的助手”我理解很多工厂对AI的印象还停留在“智能客服”水平。你问它一个问题它给一段回答就这样。这种AI在车间里毫无价值因为工厂要的不是回答是结果。智能体不同。智能体的核心是“能干活”你告诉它“帮我看一下今天A线产能为什么掉了”它不是给你一段包含各种可能性的分析报告而是自动去查生产工单、设备报警记录、停机日志对比历史数据最后告诉你“大概率是下午2点到4点涂布机频繁报警导致报警代码E210对应的是涂布头温度波动和昨天更换的浆料批次可能有关建议优先排查”。能说出这句话靠的不是一个大模型而是一整套系统低代码平台里沉淀的业务流程、数据平台里的统一数据、RAG知识库里的历史处理记录、Agent框架里编排好的工具调用链。把这套东西搭起来之后工厂里那些高频、重复、又有一定判断复杂度的决策才真正找到了替代方案。2. 低代码平台与智能体在智能制造里怎么分工2.1 低代码擅长的事让业务人员把流程“搭”出来先冷静说一句低代码不是新鲜词在制造领域也谈不上颠覆但它在智能体时代重新有了价值。低代码擅长解决的是“业务应用快速交付”的问题。传统方式下车间想上一个异常提报流程IT排期两个月需求评审两轮等系统上线问题早变样了。低代码平台里设备工程师自己拖拖拽拽半天就能搭出一个“异常上报自动通知闭环确认”的应用。它不完美但它能跑、能用、能解决问题。更重要的一点是低代码应用会成为智能体的“手和脚”。Agent读懂了数据、得出了判断最终要把结果落到业务流程里比如创建一张异常工单、更新一条设备状态、通知到对应负责人。这些动作如果靠Agent直接对接MES开发量巨大但落在低代码平台的开放接口上就简单很多。我在项目里的习惯是流程编排全放低代码平台Agent只负责“判断”和“发起”执行交给低代码里的流程去处理。低代码还有一个容易被忽视的价值可编辑、可调试。低代码平台里的ECharts图表配置、表单字段、审批链都是即改即生效的这让业务人员和Agent之间的“对齐成本”变得很低。2.2 智能体擅长的事让系统具备解读和执行能力我把工厂里适用的智能体分成三类先看一张表。类型典型能力适用场景技术底座知识问答型智能体检索SOP、工艺文件、异常处理记录回答自然语言问题新人培训、标准查询RAG向量库任务执行型智能体理解指令调用系统API完成任务自动生成质检报告、创建维修工单Agent框架低代码API分析决策型智能体分析数据、定位根因、给出建议设备告警诊断、排产建议、能耗调优大模型数据分析组件第一类最容易做价值也相对有限第二类和第三类是智能制造里真正的增量。它们不是“问答机器人”而是“会干活的数字员工”。以设备告警诊断为例。传统系统只能做到“报警弹窗”好一点的能做规则联动比如温度连续三次超限就停机。但工程师接到报警后依然要自己翻历史曲线、查同型号设备此前的处理记录、对照工艺规范判断严重程度。这个“翻找判断”的过程正是分析决策型智能体能替代的。2.3 被忽略的数据连接层没有这一层两个都白搭低代码和应用层再强数据不打通就是空中楼阁。我做项目的时候强制要求在架构层面先明确数据流向设备层PLC、传感器、检测仪通过OPC-UA或MQTT协议接入采集网关网关把数据清洗后写入实时数据库或时序数据库MES、ERP、QMS这些系统的数据则通过API或数据库同步汇聚到数据中台。低代码平台连的是数据中台的视图和APIAgent连的也是同一套数据服务。这么做最大的好处是业务人员和Agent看到的是同一份数据、同一个数据口径避免了“报表上数据打架”“Agent结论和现场对不上”这类尴尬问题。很多智能体项目失败不是模型不行是连接层没做好。Agent想查一个工单状态数据库连不上想调设备参数接口没授权想读工艺文件文档散落在各人电脑里。这些连接问题不解决模型再聪明也白搭。3. 落地实操以新能源电池PACK线为例的完整步骤3.1 场景筛选不是所有工序都适合先上智能体我先说一个大概率会踩的坑项目组一上来就想做“车间大脑”想用一个Agent管整条线。这种想法在现阶段基本做不成。智能体的可靠性是逐步提升的你要让它先从一个小闭环开始。我在PACK线上的场景筛选逻辑主要看三个维度数据完整度这个工序有没有稳定的自动化数据采集如果还要人工抄数先不上Agent先把数据补上。规则明确度这个判断的边界是否清晰如果连老师傅都说不清判据Agent更学不会。人工经验依赖度这个环节是不是虽然有经验成分但经验相对稳定、可以被沉淀按这个标准选出来的候选场景通常是电芯来料分选参数复核、设备常见故障诊断、能耗异常检测、质检报告解读。这些场景规则相对清晰、数据质量够用、经验可以沉淀适合作为智能体的第一个落地场景。而那些还在频繁试验新工艺、参数窗口本身不稳定、行业里都没有标准答案的环节不要急着上Agent。原因很简单没有人能对“连专家都不确定的问题”给出稳定的智能体输出。3.2 打通底层数据先把数据变成“事件”选定场景之后下一步不是训练模型而是把数据工程做好。以“设备故障诊断”这个Agent为例它需要消费哪些数据不是几千个原始点位而是能被理解的事件和对象。我把数据清洗加工成几张“事件表”设备报警事件表报警代码、发生时间、恢复时间、所属工段。工单执行事件表工单号、产品型号、计划数量、实际产出、开始/结束时间。质检异常事件表异常类型、不良数、工位/设备、发现时间。停机事件表停机类型、时长、操作人员备注。这些表是低代码看板和Agent共同的数据源。清洗逻辑不复杂核心是“把传感器数据变成业务语言”把时间戳对齐、把点位映射到设备对象、把报警代码翻译成工段术语。这一步工作量不小但决定了后面所有工作的质量。我在项目里通常还会做一件事把历史异常处理记录整理成结构化知识。比如“E210报警涂布头温度波动浆料批次变更”这条经验老师傅知道但没写下来。我们把这类记录补录进知识库并且标注好对应的设备、现象、原因、处理动作后面Agent回答问题时才能引用到真正的经验。3.3 用低代码搭出执行层看板、工单、流程闭环数据就绪之后先用低代码平台搭一套“能跑起来”的执行层应用。我习惯按三个模块来搭生产驾驶舱PC端车间大屏展示当班产量、设备OEE、在制品状态、质量缺陷帕累托图、能耗趋势。图表用低代码平台里的ECharts组件配置基本不用写代码拖拽绑定数据源就行。关键是可以随时改今天车间想看“各线一次良率对比”明天想看“不同班次生产效率差异”在平台里调一下维度就出来了不用再走开发排期。异常闭环模块扫码报异常、拍照上传、自动通知责任班组、处理结果回填、超时升级。这个流程用低代码的表单审批链就能搭完。它的价值在于每一条异常最后都会沉淀为一条带处理结果的结构化记录这些记录以后就是Agent的知识来源。质量追溯查询输入电芯条码或工单号能一路查到原材料批次、对应设备参数、质检数据。这个模块的数据来自MES和检测设备低代码平台通过API对接把原本要IT协助才能查的东西变成业务人员自己就能点出来的功能。这三块搭完之后工厂就已经有了一个“数字化运营骨架”。这个时候再上智能体你会发现它不再是飘在真空里的东西而是长在这个骨架上、能真正干活的帮手。3.4 部署智能体先处理高频但重复的“判断”执行层跑通之后我开始部署智能体优先级是先处理高频但重复的判断。三个典型示例第一个是“设备告警分诊Agent”。它订阅报警事件表对每一条报警判断严重级别、可能原因、建议处置动作然后把结果推送到低代码异常闭环模块自动生成带AI建议的工单。老师傅只需要确认或修改而不是从零开始排查。第二个是“排产建议Agent”。它在每天早晨根据当日工单、设备状态、人员出勤、物料齐套情况给出一个排产建议顺序和换线时间建议。传统排产依赖计划员人工盯Excel现在Agent可以几秒钟给出版本A/B方案计划员直接决策或者微调。第三个是“质检报告解读Agent”。SPC图、CPK值这些数据已经有很多系统在做但系统不会告诉你“这个趋势说明什么”。Agent自动拉取最近一周的检测数据输出一份自然语言版的趋势判断哪个参数在恶化、可能和哪台设备的哪个参数联动、建议排查方向。这三个Agent的共同特点是不直接产生动作而是生成“建议”并落到低代码平台里。建议必须经过责任人的确认才会真正执行这个设计非常关键。3.5 闭环设计建议、审批、执行、回库智能体落地的成败最终看闭环。没有闭环Agent分析得再准也只是个高级报警器。闭环的流程是Agent生成建议后通过API调用低代码平台的接口创建待办任务责任人在低代码应用里看到建议、确认或修改确认后的动作触发低代码流程执行创建工单、修改排程、通知相关人员执行结果回到数据平台Agent下一次分析时就会把“上一轮结果”当成上下文参考。这个闭环里有一个人机分工的原则Agent负责“提建议”人负责“做决策”。不是人不信任Agent而是工业场景里责任主体必须是人的角色。后面我会再展开讲这个边界怎么守。4. 智能体在工厂落地的关键工程点模型、知识库与验证4.1 大模型怎么选云端API、私有化部署还是轻量本地模型选模型是很多团队容易卡住的第一关。我给一个简化但实用的选型逻辑对比如下方案优点缺点适用情况云端大模型API效果最好、开发最快、无需运维数据出园区合规风险、时延、调用费数据不敏感、验证期跑通流程私有化部署大模型数据安全、可控GPU成本高、运维复杂、模型版本更新慢有合规要求、长期规模使用轻量本地模型部署简单、响应快、成本低推理能力弱、复杂任务效果一般任务简单、响应实时性要求高我的建议很直接初期验证阶段优先用云端API目的是快速验证场景价值和业务效果别上来就花几十万买GPU服务器跑通之后再根据数据合规要求评估是否私有化。如果确实有数据出厂限制也可以从一开始就在私有化环境里做但要准备好工程投入。还有一个容易被忽略的细节边缘侧的轻量模型和云端大模型可以搭配使用。比如用轻量模型做现场的低时延判断例如对异常描述做意图识别用云端大模型做复杂的根因分析。这种混合架构在产线上更实用。4.2 工厂知识库把老师傅的经验变成可检索的资产大模型出厂时不懂你工厂的SOP、不懂你设备的报警代码、不懂你这个车间的生产节奏所以知识库几乎决定了一个工厂智能体好不好用。我梳理下来的知识库内容至少包括四类工艺类SOP文件、工艺参数规范、配方变更记录。设备类设备手册、故障排除指南、历史报警处理记录。质量类缺陷判定标准、客户质量标准、历史质量分析报告。管理类异常上报流程、交接班制度、应急预案。知识库建设不要追求“大而全”要围绕你选定的智能体场景来组织。比如设备诊断Agent需要的是设备手册和故障处理案例排产Agent需要的是产能模型和约束规则。每个Agent接一个小而专的知识库效果比一个大而杂的库好得多查询精准度也更高。RAG检索增强生成是实现知识库问答的主流方式先把文档切块、向量化存进向量库Agent收到问题时先从向量库检索相关片段再让大模型基于检索结果生成回答。关键词是“带引用回答”答案下面必须附上来源文档方便人去核实这一点在工业场景里是刚需。4.3 提示词与行动层让Agent不仅会说话还会办事很多团队把Agent做成了“只会打字的秘书”核心问题是没给它接行动层。Agent框架比如Dify这类平台上直接用或者用开源的Agent框架自建里都有一个工具调用机制你可以给Agent注册一批“工具”每个工具就是一个可执行的函数或API接口。Agent在推理过程中会判断“我需要查一下工单状态”然后调用一个低代码平台提供的“查询工单详情”接口拿到结果后继续推理最后生成结论。我给一个简化示意假设Agent需要调用低代码平台的API创建异常工单POST /api/agent/tasks { title: AI建议涂布头温度波动异常排查, priority: high, type: 设备诊断, description: Agent分析发现E210报警频次升高建议优先检查涂布头加热模块..., suggestedAction: check_heating_module, suggestedOwner: 设备二组, source: agent_recommendation, confidence: 0.87 }真正的关键点在于接口是低代码平台提供的流程是低代码平台编排的Agent只是“决策大脑”。两套系统通过API衔接边界清晰低代码管流程和数据Agent管理解和建议。这个架构的好处是即使Agent出错了也不会绕过流程不会直接动设备风险可控。当然非常底层的“AI直接生成PLC代码”目前也开始有人尝试了。比如根据工艺需求生成某个控制逻辑的PLC程序再用仿真环境验证。这个方向很有意思但离大规模生产应用还有距离我的态度是“可以关注、别急着上产线”。4.4 验证体系从“演示不错”到“产线敢用”需要经历的几个阶段智能体项目最忌讳的就是Demo阶段看起来很好、一上产线就没人用。我从实践中总结了一套分阶段的验证方法第一阶段叫“影子模式”。Agent在后台运行它的判断和建议不出现在生产流程里只是同步存一份记录。这个阶段的作用是积累真实数据用来评估Agent的判断准确率。拿故障诊断Agent来说它会生成建议但建议不发给任何人等人工处理完毕后我们再比对Agent建议和处理结果的一致性。这个阶段持续两周到一个月。第二阶段叫“建议模式”。Agent的建议开始推送到低代码应用里但只作为参考责任人可以不采纳。这时要统计建议采纳率、建议有效率。如果采纳率高说明Agent的判断已经靠谱了如果低就回头看知识库和数据链路。第三阶段叫“授权模式”。对特定场景和特定Agent允许自动执行低风险动作比如自动创建巡检工单、自动发送通知。仍然不允许Agent触碰高风险动作比如直接修改设备参数、直接停线。整个验证过程中最核心的指标不是技术指标而是“业务端的采纳率”。一个Agent再智能只要业务人员不愿意用价值就是零。5. 踩过的坑与必须守住的底线5.1 坑一低代码系统和MES做成两座孤岛下面这条是我踩了不止一次的坑。低代码平台开发快业务人员用得开心但它如果不受控地膨胀就会在MES之外长出一套“影子系统”。部门间数据口径不一致同一台设备的OEE在MES里是85%、在低代码看板里是79%两边都查得到谁都不知道该信谁。解决的办法是在一开始就约定数据模型和同步机制。低代码平台里凡是涉及核心指标的字段必须使用数据中台里的统一字典凡是业务结果数据必须双向回写。简单说低代码平台可以快速建应用但不能自成一套数据体系。5.2 坑二智能体一本正经地胡说八道大模型幻觉在任何领域都是风险但工业领域这个问题会被放大。在办公室里聊天答错了无非是重说一遍在车间里一句话给错参数可能直接影响产品质量。我遇到过一个小案例某个质检解读Agent在生成报告时把“极片厚度公差±0.02mm”写成了“±0.2mm”大概是把上下文里的单位搞混了。这个错误从技术上看很典型但如果不被检查出来后果不堪设想。应对幻觉我总结了几条硬规则数值型结论必须做规则校验Agent输出里的每个关键数值都要和来源数据比对不一致就报错。必须附引用来源回答里的每一条判断都要给出数据出处或文档来源方便人核实。关键决策必须有人审批建议好自动执行不行。让责任人做最终确认。对低置信度场景主动说“不知道”让Agent在不确定性高的时候明确说出“该结论置信度较低需人工复核”而不是硬编一个看似合理的答案。5.3 底线设备控制和安全绝不能松这是整个体系里最不能妥协的地方也是我在每次启动会都会反复讲的一条原则Agent和低代码应用可以碰数据层和应用层但绝对不能直接碰设备控制层。设备安全回路、急停逻辑、联动保护这些依然由PLC硬逻辑实现Agent永远没有权限、也没有接口去修改这些逻辑。即使未来技术更成熟这条边界也建议保留。工业场景的安全性靠的不是AI的“聪明”而是工程的“冗余”。AI可以是辅助决策的工具但不该成为安全链路上的一环。数据安全也需要分级管理。不同岗位的人能看到的Agent结果、能调用的工具权限都要分开。最低权限原则在数字系统里和物理安全同等重要。5.4 组织上的坑AI项目不能只靠IT和算法团队我见过太多AI项目死于“IT和算法团队自嗨”。大模型能力再强如果工艺工程师不参与、设备工程师不买账、一线操作工不会用项目就是做成了PPT里的亮点也落不了地。低代码平台在这里有一个隐性的巨大价值它把业务人员从“使用者”变成了“共建者”。工艺工程师能自己在低代码平台上调整看板、修改流程这让他觉得系统是自己的工具而不是IT强加的系统。参与感直接影响采纳度这是组织层面我最深的感受。6. 从单个智能体到智能体协同开启新能源工厂的下一步6.1 多智能体协同的一个示例场景单个Agent跑通之后自然会走向多Agent协同。以PACK线换型为例我设想并验证过的协同场景大致是这样产线从A型号切换到B型号时排产Agent自动计算最优换型时间点、输出新排程建议排程变更的消息转发给物流Agent物流Agent重新调度AGV的配料顺序质检Agent收到换型信号后自动切换抽检规则和质量控制计划设备Agent结合新工艺参数提醒产线工程师调整涂布/焊接参数窗口。这个协同不是靠一个“超级大脑”完成的而是多个Agent各管一段、通过事件消息机制配合。低代码平台在这里又起到中心枢纽作用Agent之间不直接点对点通信而是通过低代码平台的消息中心/事件总线传递指令这样每一个动作都可追溯、可撤回、可审计。6.2 组织与人才智能体工程师和场景分析师会成为新岗位智能化转型必然会改变工厂的岗位结构。我的观察是第一批受益的是那些掌握工艺经验又愿意学新工具的人。以后工厂里会出现一个“场景分析师”的角色他不一定是编程高手但要懂业务逻辑、懂数据字段、会配置智能体、会用低代码搭流程。这种人比单纯的AI工程师更稀缺也更值钱。这个角色培养之所以可行正是因为低代码和成熟智能体平台已经把技术门槛压得很低了。以前要造一个能处理业务的软件可能需要一个K人的开发团队现在一个人加上一个好的平台就能搞定过去需要IT、算法、业务三方协作的事。6.3 我对后续演进的个人看法做了这么多新能源工厂项目后我越来越深的感受是智能体的价值不在“智能”本身而在“被信任”。被信任的前提是稳定、可解释、并且尊重人类的决策权。所以我不建议一上来就追求全自动化而是把智能体定位成一个“越用越好的助手”最初它帮你查资料、做分析慢慢地你愿意把更多重复判断交给它等它在大量真实反馈中沉淀得足够好你再给它授权执行一些低风险动作。这条路不会像宣传片里那样激进但每一步都扎实。对于还在观望的工厂我的建议也很简单把手上的数字化基础先打牢把数据治理、流程梳理、知识沉淀这几件事做好。智能体拐点来临的时候只有数据基础扎实的工厂能接得住。现在开始做已经不算早了。再补一句个人体会这个方向最有成就感的一刻不是看板跑通的时候也不是Agent给出正确诊断的时候而是车间老师傅在用了半年之后私下跟我说“这个AI偶尔还真能帮上忙”。团队和数字系统之间建立起那种信任感才是整个项目真正跑通的标志。