这两年跑了不少新能源工厂从锂电池前段的涂布、辊压到光伏组件的串焊、层压再到储能PACK的模组装配产线上被问到最多的问题已经从“要不要上AI”变成了“AI到底怎么用才能不白上”。行业对AI的态度早就过了炫技期大家真正关心的是有没有一种方式能让不懂算法的工艺员、设备工程师、质量主管也把AI用起来而不是永远排队等IT部门写代码。低代码加上智能体恰好在这个节点走进了工厂。我这里说的智能体不是只能陪你聊天的机器人而是能替人做判断、跑流程、盯异常的数字员工。低代码解决的是“让普通人也能搭建应用”的问题智能体解决的是“让应用具备自主决策能力”的问题两者叠在一起才真正有机会在新能源制造这种工艺复杂、节拍快、数据量大的场景里落地。这篇文章我会从背景、选型、实操、踩坑这几个维度把我看到的智能体拐点讲清楚希望能给正在做智能制造转型的朋友一些可参考的思路。1. 从自动化到智能化的现实瓶颈新能源工厂缺的到底是什么1.1 智能体在制造业语境下的定义和边界很多制造企业的负责人对智能体的理解还停留在“一个对话框”的阶段。但在工厂场景里智能体不应该是一个悬浮窗而应该是一个能够独立完成“感知—决策—执行”闭环的数字角色。感知指的是从PLC、MES、ERP、传感器、质检设备中获取数据决策指的是基于预设规则、优化算法以及大模型推理能力在具体业务场景中给出判断执行指的是通过调用低代码平台里的动作组件自动下发指令、创建工单、推送异常消息或者生成分析报告。边界在哪里智能体不是要取代人类工程师而是把重复性、规则性强的判断工作接过去。比如电池产线上电压内阻测试数据出现异常波动传统做法是工程师打开报表慢慢筛查现在可以让智能体实时盯着数据流一旦发现连续三条数据超限立刻追溯当天来料批次、设备参数、环境温湿度并给出可能的根因排序。这种“读数据—找关联—给结论”的能力正是智能体在制造现场最核心的价值。1.2 新能源产线为什么率先撞上“智能化拐点”新能源制造和传统离散制造有个明显差别工艺窗口特别窄扩产速度又特别快。锂电池极片涂布的面密度偏差正极材料混料的一致性波动化成分容环节的容量异常这些参数稍微偏离设定位就可能导致整批电芯降级甚至报废。而产线一旦开起来节拍非常快靠人工盯数据根本盯不过来。另一个现实问题是新能源行业的人才结构很年轻但工艺工程师和设备工程师的精力被大量琐事占满。一个电池厂的工艺主管上午在解决极片段厚度异常下午要分析化成分容的容量分布晚上还要写良率改善报告。他们缺的不是专业知识而是能把知识快速地转化成可执行工具的通道。我举个例子广东一家动力电池工厂前年上线了一套设备数据采集系统每天产生上千万条数据点。IT团队忙了几个星期搭建BI报表结果业务部门发现报表只能做“事后展示”没法做“事前预警”。后来通过低代码平台接上智能体工艺员自己就能拖拽配置一个预警智能体当某台涂布机当天的面密度标准差连续一个小时超过阈值智能体自动计算相关性把异常区间和可能的刮刀磨损判断一起推送到工位机。从搭建到上线一个完全没有代码基础的工程师只花了两天。所以说新能源产线率先撞上智能化拐点不是因为它技术最先进而是因为它痛点最集中、数据最丰富、回报最明显。谁先把智能体用起来谁就能在良率、效率和成本上拉开差距。2. 低代码平台智能体落地的“生产线”2.1 为什么智能体不能全部靠大模型原生开发过去一年我见过不少团队尝试直接调用大模型API来做制造辅助工具方向是对的但真正走到生产线上的少之又少。原因很简单大模型本身不解决“工厂级”的问题。一是数据集成难。大模型API是独立的服务它不会自己连接你的MES数据库不会自己读PLC点位更不会自动处理车间复杂的网络分区问题。你需要在外面写一大堆接口代码做数据搬运。二是界面和交互缺失。工人不可能在对话框里慢慢提问产线上需要的是工位机上的一键式入口或是异常发生时自动弹到手机上的结构化通知。三是权限和审计问题。制造业对数据安全要求高谁的账号调的接口、看了哪些数据、改了哪条参数都要留痕原生大模型应用很难覆盖这部分。四是维护成本高。业务一调整代码就要跟着改最终又把所有变更压力压到IT团队身上。低代码平台的价值在于它把数据连接、界面搭建、流程编排、权限管理这些“房子框架”都做好了智能体的角色则相当于给这个房子装上“大脑和手脚”。业务人员用可视化方式把触发条件、模型调用、动作执行串起来形成了真正可落地的闭环。2.2 选型低代码平台的几个关键维度市面上的低代码平台非常多从通用办公类到偏数据集成类各有侧重。制造现场选型不能只看宣传的“拖拉拽”要在真实场景里验证这几个维度第一连接器生态丰富程度。平台是否已经支持你要对接的MES、ERP、OPC UA、Modbus TCP、数据库类型是否有标准连接器还是需要自己写插件扩展。这个直接影响上线周期。第二工作流编排能力。除了简单的审批流能不能支持复杂的分支判断、循环处理、并行任务以及能不能在节点中嵌入HTTP请求和AI模型调用。很多办公型低代码平台在这一步就卡住了。第三数据权限与审计机制。制造数据敏感平台能不能做到角色级的字段权限控制能不能把每一步操作和模型调用记录到日志里。第四部署形态。工厂网络通常分为办公网和工业网平台是否支持私有化部署、容器化部署能不能灵活地跑在边缘服务器上。第五易用性门槛。这里说的易用不等于“什么都能拖”而是业务人员经过半天培训后能否独立搭建出一个小场景。你可以让厂商拿一套真实脱敏数据现场试看看他们的学习曲线。我整理了一张选型对照表方便大家参考评估维度关键检查项主要风险点连接器是否支持PLC协议、主流数据库、REST API只支持公有云API无法连接工业内网工作流分支、循环、并行、人工审批节点只支持简单表单流程权限审计RBAC权限模型、操作日志、模型调用审计无细粒度权限控制私有化支持Docker/K8s部署离线可用强绑定云服务断网即停AI能力可编排调用大模型API或本地模型不具备AI集成能力或配置极复杂易用性新手半天培训是否能搭建首个应用学习成本过高最终变成IT专用工具2.3 低代码智能体的典型架构在我参与落地的新能源项目中低代码和智能体合在一起通常会形成这样一个分层结构最底层是数据接入层。统一对接MES、SCADA、PLC、能耗表、品质系统把结构化数据和设备时序数据抽取到统一的数据池中。有些工序数据适合实时读取比如注液机压力传感器有些适合定时批量抽取比如化成分容柜的容量曲线。接在数据层之上的是服务编排层。低代码平台负责把“数据读取—条件判断—模型调用—动作执行”串成一个完整的工作流。比如检测到某个电芯的K值异常先查生产批次的主数据再查对应工位的工艺参数然后调用一个本地部署的AI模型做根因排序最后生成一张包含置信度标签的分析卡片推送到责任人。再往上是智能体能力层。这里的智能体会被赋予不同的角色设备预警智能体、质量分析智能体、排产建议智能体。每个智能体有自己的任务范围、需调用的数据权限、可执行的指令集合避免出现“一个智能体啥都管啥都管不好”的情况。最上面是应用交互层。车间大屏、工位机、手机企业微信、Web端都可以作为入口。智能体的输出不是一堆原始数据而是带结论、带建议、带操作按钮的任务卡片。这种架构的好处是边界清晰任何一个环节出问题都能快速定位。更重要的是业务人员可以在低代码平台上直接调整流程节点不需要改动底层系统真正实现“业务主导”的快速迭代。3. 实战搭建新能源工厂里的智能体怎么一步步落地3.1 第一步确认高价值场景很多团队一上来就想做“覆盖全厂区的智能中枢”这种项目往往半年都出不来成果。我建议先从一两个高价值、低风险、数据质量好的场景切入。什么样的场景适合打头阵可以按三个标准筛选业务痛点够痛、数据已经采集到了、决策动作相对明确。拿一个储能PACK工厂举例电芯配对阶段需要确保同一PACK内的电芯电压、内阻、容量差异尽量小。过去靠工程师每天从MES里导出几千条电芯数据再用Excel做差值计算费时费力而且容易漏掉异常。这就是一个非常典型的智能体切入点。如果选设备预测维护可以考虑光伏组件车间的层压机。层压机一旦温度分布不均整版组件都可能报废损失很大。它的温度传感器数据已经实时采集到SCADA系统里只要把历史温度曲线和故障记录关联起来智能体就能学习温度场异常的前兆特征。这个场景落地后的收益直观老板也愿意继续投入。3.2 第二步数据接入与指标定义选好场景后下一步是数据治理这一步看起来不性感但决定了智能体能不能“吃饱饭”。我见过不少项目模型算法调得很漂亮结果一到现场就因为数据字段名不一致、时间戳时区错乱、缺失值过多而翻车。具体做三件事一是字段梳理。对照MES里的批次号、设备编号、工位编号、产品BOM确认和PLC点位数据的对应关系。很多工厂存在同一个设备在MES里叫“涂布机3号”在SCADA里叫“COATER_L3”的情况必须先做映射。二是数据质量检查。统计关键字段的缺失率、重复率、单位是否统一。比如温度数据传感器有时候回传的是℃有时候回传的是℉这种问题在现场真实存在。还需要注意设备偶尔断网导致的时间戳跳变如果不对这些数据做清洗智能体的判断就会忽好忽坏。三是指标定义。和业务人员一起确定“什么算异常”“什么算预警”。用电池化成分容来举例可以定义三条规则单支电芯容量低于C10标称容量2%为不合格连续三支电芯容量趋势性下降启动预警整柜有效率低于98.5%触发批次追溯。这些规则本身不需要写代码在低代码平台里用可视化条件配置出来就行但必须是和业务人员一起敲定的而不是IT部门自己拍脑袋。3.3 第三步编排智能体工作流数据准备好之后就可以在低代码平台上搭建智能体工作流了。我以某锂电池隔膜车间的“厚度缺陷分析智能体”为例说明整个编排过程。这个场景的需求是在线测厚仪每分钟产生上百个厚度值一旦偏差超限需要快速判断是来料问题还是设备问题。人工排查通常要花半小时智能体的目标是把这个时间压缩到5分钟以内。在低代码平台里工作流被拆成这样几个节点第一个节点数据触发。设置定时任务每两分钟从测厚仪数据库中拉取最新一批厚度数据同时从MES中取到对应的产品批次号和机台参数。第二个节点条件判断。用可视化规则判断数据是否在规格范围内。如果所有厚度值都在范围流程直接结束如果出现超限进入下一个节点。第三个节点AI分析。调用智能体的根因判别提示词把超限区间的厚度波形、同时段的刀压力、线速度、材料批次信息组装成上下文让大模型输出可能的原因排序并附上置信度。第四个节点动作执行。根据AI分析结果智能体在低代码平台上自动创建一张异常工单分派给对应的工艺工程师同时把分析卡片推到车间看板和负责人的企业微信上。第五个节点反馈闭环。工艺工程师处理完问题后在工单里填写真实根因这个反馈会回写到平台成为后续优化提示词的样本。整个工作流里真正需要写代码的环节几乎为零但每一步都需要想清楚“谁触发、谁判断、谁执行、谁确认”。3.4 第四步测试、上线与运营迭代工作流搭好后不要马上一把梭地上线。我的习惯是先做两周的“影子模式”也就是智能体照常跑分析、照常生成结果但不自动执行动作推送到一个测试群里让业务人员每天看一眼看它的判断准不准、有没有误报。影子模式非常重要。大模型的输出通常带有一定的不确定性如果直接让它自动创建工单、自动停线万一判断错了业务人员对这个系统的信任就会崩塌。影子模式相当于给智能体安排了一个“实习期”观察期没问题再开放真正的执行权限。上线之后还要持续运营。建议每周拉一次智能体的命中率数据看看有多少次预警是准确的有多少次是误报。同时把业务人员反馈的“这个根因排序不对”“漏了来料因素”等意见收集起来定期优化提示词和规则阈值。智能体本质上是一个需要喂养和训练的数字员工它不是一次开发完成就一劳永逸的。4. 技术细节与核心实现解析4.1 PLC与MES数据接入方式新能源工厂里设备层和数据层的通讯协议非常杂主流的有OPC UA、Modbus TCP、S7comm还有一些厂商自有的协议。低代码平台接入这些数据一般有几种思路第一种通过边缘网关中转。在车间侧部署一个边缘网关用KEPServerEX之类的软件把各种协议统一转换成OPC UA或MQTT再推送到低代码平台的数据接入层。优点是适配性好设备的点位修改可以在网关侧完成不用频繁改应用。缺点是会增加一套硬件和维护成本。第二种直接对接数据库。很多设备供应商的软件系统底层是SQL Server或MySQLMES系统也大多基于关系型数据库。低代码平台可以直接配置数据源通过定时任务读取业务表。这种方式实现最快但要注意只做只读访问避免影响生产系统的性能。第三种文件导入。部分老设备只支持导出CSV或Excel这时候可以通过文件上传或FTP目录监控的方式定期把数据文件导入低代码平台的数据模型中。适合数据量不大、实时性要求不高的场景。这里有一个建议不要把实时精确到秒级的数据需求都放在低代码平台上处理尤其是高频振动信号、瞬时电流波形这类数据低代码平台处理起来很吃力。低代码平台应该负责的是“准实时”的业务闭环高频数据可以先用边缘端的时序数据库做预处理再让低代码平台取结果。4.2 质检智能体、能耗预测智能体、设备预测维护智能体跑通了第一组场景后工厂通常会把智能体往更多方向复制。我梳理三个在新能源工厂里最容易见效的智能体方向。第一个是质检智能体。以锂电池外观检测为例设备端的工业相机完成图像采集后会将NG图片传到低代码平台的存储服务。质检智能体可以读取NG图片对应的产线位置、设备编号、检测时间再结合当天该设备合格率趋势自动判断是否存在系统性偏移。如果合格率呈持续下降趋势智能体会建议设备工程师检查相机光源强度或软件参数而这一判断以前通常依赖产线带班长的个人经验。第二个是能耗预测智能体。新能源工厂是耗能大户尤其是化成分容环节充放电设备的电力负载曲线直接影响电费账单。智能体可以基于生产计划、历史能耗数据、天气温度变化对接下来一周的工厂用电负荷做预测。低代码平台把这个预测结果生成透明的排产看板和能源管理部门的考核指标联动。这个场景的好处是与产量绑定紧密落地后能直接看到吨产品能耗下降容易获得管理层的支持。第三个是设备预测维护智能体。光伏组件工厂的层压机、锂电池工厂的涂布机、储能产线的激光焊接机都适合做。思路是一样的把设备历史故障记录、维修工单、运行参数结合起来让智能体识别出“故障发生前若干小时”的特征模式。当实时数据匹配到这些特征时提前发出维护建议把被动维修变成计划性维护。4.3 人机协同让一线人员愿意用起来智能体搭建得再好如果一线人员不用项目就等于白做。我复盘过多个项目发现影响一线使用意愿的往往不是功能强弱而是交互细节。一个细节是信息推送的“距离感”。工艺员不可能一直坐在电脑前刷新页面他需要在工位附近就能收到关键信息。我看到比较成功的案例是把智能体输出接入了企业微信或钉钉机器人异常信息实时推送到人员手机上点开就是一张摘要卡片不需要再登录系统。另一个细节是“可解释性”。现场工程师对智能体的质疑通常集中在“为什么它会给出这个结论”。如果智能体只是丢出一个判断结果没有给出依据没人敢信。所以在设计提示词和展示页面时我会要求智能体把推理依据一并输出它是基于哪些参数、哪些历史案例、哪些规则得出的结论以结构化列表的形式展示。还有一个细节是反馈入口要足够轻。在智能体生成的分析卡片下直接提供“认可”“不认可原因”两个按钮让业务人员一键反馈。这些反馈数据会沉淀下来成为后续优化智能体的重要样本。反馈闭环做得越轻数据积累越快智能体才会真的越用越聪明。5. 现场实施中的坑与排查技巧5.1 数据不一致导致智能体判断漂移我踩过最大的一个坑是智能体上线初期经常出现“同样的异常有时报警有时不报警”。查来查去发现根本不是模型问题而是数据源里的时间粒度不一致。MES里的产量数据是按车间聚合的PLC里的运行数据是按秒收集的两个数据join的时候时间对不上导致智能体每次抽取的上下文长度和数据窗口都不同判断自然不稳定。解决方式很简单在低代码平台的数据接入层先定义标准的时间聚合粒度比如统一到分钟级或小时级。所有数据进到智能体之前必须先做一次“对齐清洗”字段重命名、缺失值填充、时间戳对齐统统在这一步完成。宁可损失一点实时性也要保证数据口径一致。另一个常见问题是设备维护后点位地址发生变更。工厂的自动化部门调整了PLC程序增加了一个点位导致原有数据采集映射错位。建议在低代码平台里为每个智能体绑定的数据源建立一个“血缘地图”每次采集任务跑完都校验字段数量和类型一旦发现异常立即发消息给管理员确认。5.2 智能体“太笨”或“太灵活”的问题智能体上线初期容易走向两个极端。一个极端是规则设得太硬所有判断都按照固定阈值来结果就是系统的行为和传统的自动化告警没区别完全没有体现出智能体的优势。另一个极端是提示词写得过于开放智能体什么因素都考虑输出一堆模棱两可的“可能性”业务人员看完更糊涂。我的做法是采取“规则模型”的双层结构。第一层用规则把明确异常筛掉比如超过硬性工艺标准就直接预警这类问题不需要模型参与第二层才轮到智能体发挥作用针对规则无法判定的模糊场景做根因分析。提示词方面我一般会在系统提示里明确约束输出格式要求智能体只能给出三点以内的可能原因每条原因必须标注依据没有依据的推测一律不写。这样既保留了大模型的推理能力又限制了它的“自由发挥”。5.3 边缘端与云端部署取舍新能源工厂的网络环境通常分办公网和工业网两部分工业网内的设备数据不能直接上公网这在部署智能体时是一个绕不开的问题。如果工厂介意数据出园区或者车间到云端的网络不稳定建议把低代码运行环境、大模型推理服务都部署在厂区内部的边缘服务器上。现在很多低代码平台已经支持Docker/Kubernetes私有化部署大模型也可以通过vLLM或Ollama部署在本地的GPU服务器上满足离线推理需求。如果工厂有多个基地希望总部统一管理各工厂的智能体实例可以在总部云端部署一套管理面在各分厂部署运行面。运行面离线也能正常工作等网络恢复后再把数据和结果同步到管理面。这种混合部署方式灵活性比较高但需要确保各分厂的网络运维水平跟得上。我个人的建议是新能源工厂的智能体至少要把“执行”放在边缘端云端可以拉取非敏感的数据做模型迭代。如果所有判断和执行都放在云端一旦网络抖动整个产线就会变成“睁眼瞎”这是制造业绝对不能接受的。5.4 常见问题速查表现象可能原因排查与解决思路智能体预警结果时好时坏训练数据时间窗口不一致在数据接入层统一粒度重新抽取历史数据测试模型输出格式乱无法结构化解析提示词约束不足增加输出JSON格式要求并在低代码流程中做解析异常兜底系统上线后没人使用信息推不到一线人员终端对接企业微信/钉钉机器人简化反馈按钮先让场景形成习惯低代码流程偶尔卡住某个数据源连接超时设置超时重试和异常告警超时自动切换备用数据源操作记录出现越权操作权限模型未细化到字段使用RBAC权限模型按角色、工位、产线层级控制数据访问6. 从试点走向全面落地的推进建议6.1 组织准备与人才梯队制造业的数字化转型人才比技术更重要。智能体落地过程中最好建立一支“懂业务又懂AI应用”的骨干队伍。这支队伍不一定是算法专家但要会使用低代码平台了解数据从哪里来、判断逻辑怎么配、提示词怎么优化。我的经验是每一条产线至少培养一名“数字化工艺员”他就是这条产线的智能体运营负责人。遇到异常数据他能自己上手排查业务需求有变化他能自己修改流程。IT部门负责平台运维和权限管理不再沦为业务需求的“翻译官”和“代码搬运工”。从组织上还要明确业务部门在智能化项目中的责任。如果只靠IT部门推业务部门不参与指标定义那做出来的智能体大概率是“有功能但是没业务价值”。建议在项目启动时就让工艺、设备、质量的负责人担任场景责任人他们需要对结果负责而不是当甩手掌柜。6.2 分阶段落地路线智能体在工厂里的推进适合走“点—线—面”的路线。第一阶段1个月左右重点是把基础跑通。选定一条产线、一个场景完成低代码平台部署、数据接入、一个智能体上线。这个阶段的目标不是效益最大化而是要验证“数据的质量是否可用”“团队的配合是否顺畅”“平台的性能是否达标”。第二阶段3个月左右开始横向扩展。当第一个智能体稳定运行后把它复用到同类产线再开发两到三个新场景的智能体。这时候要建立起统一的命名规范、提示词管理、模型调用日志等运营体系。第三阶段半年以上实现跨环节协同。比如把质量智能体、设备预测智能体、能耗智能体打通当质量异常时智能体之间可以自动联动一个智能体发现异常另一个智能体立即去查关联的设备数据。这一步才是“智能体网络”真正发挥价值的时候。6.3 智能体运营让业务人员当“主人”最后想特别强调一点智能体上线只是起点运营才是关键。很多公司项目立项时轰轰烈烈上线后一个月就开始冷落最终又退回手工操作的老路。要避免这个问题可以把智能体的运营情况纳入产线管理团队的日常考核。比如每周开一个“智能体运营周会”内容包括各智能体本周触发次数、预警准确率、业务人员反馈处理情况、模型提示词更新记录。这些数据可以通过低代码平台的运营看板直接导出不用人工统计。同时鼓励一线业务人员提出新的智能体需求。我在项目里通常设置一个“业务金点子”机制每条产线每个月可以提一个智能化改进建议评审通过后由数字化工艺员在低代码平台上快速搭出原型。这种全员参与的氛围一旦形成智能体在工厂里的生命力才会持续下去。我个人在实际操作中的体会是新能源工厂的智能化转型最怕的不是技术不成熟而是“过度规划”和“迟迟不动”。低代码加智能体这条路难不在技术难在能不能找到一个真正懂业务的场景沉下去跑通一个闭环。只要你肯把一个细小的痛点到智能体里去让团队看到实实在在的效率提升后面的复制和扩展就只是时间问题。先把手里的数据用起来把第一个智能体跑起来拐点自然就会出现。