低代码+AI智能体：新能源工厂智能制造落地的实战路线

新能源工厂的产线数据每天都在膨胀，但真正能把数据变成决策的人没几个。今年我带着团队把一个智能体系统直接架到了车间级的低代码平台上，不是搞论文，也不是做Demo，而是让一线的工艺员、设备工程师能自己拖拽节点、改逻辑、调参数。这轮折腾下来，我的结论很明确：以AI大模型为“大脑”、低代码为“骨架”的智能体方案，正在成为新能源智能制造落地最现实的一条路径。这篇文章就围绕我们在电池PACK、光伏组件车间的实际项目，把从0到1的思路、架构拆解、实施细节和踩坑记录完整写出来。

1. 为什么是新能源工厂，为什么是这个时间点

1.1 新能源制造的“三高”困境

新能源工厂和传统汽车、3C制造最大的区别，在于“三高”：高工艺复杂度、高数据密度、高成本压力。

以电池PACK线为例，一台电池包的装配涉及电芯分选、模组堆叠、激光焊接、气密性检测、EOL测试等十几个工序，每个工序都有几十个工艺参数，温度、压力、扭矩、焊深、电压、内阻，数据量级一天下来就是几百GB。更麻烦的是，这些数据分散在PLC、传感器、MES、ERP里，彼此之间几乎没有打通。

高工艺复杂度带来的直接问题，是异常根因定位极其困难。一台焊接设备报警，可能的原因包括焊头磨损、来料批次波动、环境温湿度变化、参数漂移，甚至前一道工序的分选逻辑发生变化。传统做法是老师傅凭经验排查，快则半小时，慢则一两天，期间的停机损失和报废风险都很大。

高数据密度则考验了现有IT系统的处理能力。很多工厂上了BI报表，但BI只是把数据变成了图表，并没有解决问题。它告诉你“OEE下降了8%”，但不会告诉你“OEE下降是因为三号线的激光焊接功率在下午三点到五点出现了异常波动，推测与冷却水温度升高有关”。这类跨系统、带推理的自动化分析，传统BI完全做不到。

高成本压力就更直接了。新能源行业从2023年开始进入价格战阶段，电池成本、组件成本、度电成本都要降，工厂必须从“低成本扩张”转向“精细化运营”。一边是降本指标层层加码，一边是工艺和设备的复杂度非但没有降低，反而因为新配方、新结构不断升级，这对制造系统提出了前所未有的要求。

1.2 智能体为什么能补上传统自动化的短板

过去五年，制造企业上了很多自动化系统，MES、WMS、QMS、EAM，但大部分系统的自动化能力是“僵化”的。规则引擎只能处理“如果A就B”的确定性逻辑，一旦遇到跨系统、非结构化的复杂问题就无能为力。

智能体的核心价值，在于它把“感知—决策—执行”拉通成了一条链。大模型作为推理中枢，能够理解自然语言描述的问题，读得懂设备日志、工艺文件和班报表，然后根据预设的工具调用来触发系统动作。低代码平台则提供了可视化的流程编排环境，让这种能力不再依赖算法工程师的代码实现，普通工程师也能根据现场情况调整Agent的行为逻辑。

把这两者叠加在新能源工厂场景里，正好破开了“懂数据的人不懂业务，懂业务的人不会写代码”的死结。工艺员不需要写Python，他只需要在低代码画布上拖一个“异常检测”节点，再拖一个“查询工艺参数”节点，连上“调用大模型分析”节点，最后接一个“生成处置建议”节点，一条智能产线巡检与预警的流程就搭起来了。

1.3 低代码在其中的角色不是“简化编程”

很多人一听到低代码，就以为是给不会写代码的人用的玩具。在我们这次落地里，低代码的核心价值完全不是“省写代码”，而是提供了人与智能体之间的可控接口。

智能体如果完全自动跑，工厂是不敢用的。因为生产系统容不得半点模糊，一条错误的指令可能导致整批产品报废。低代码平台在这里起到的是“人机共识层”的作用：每个AI决策节点之间的流转逻辑、审批动作、回退策略都是显性的、可修改的。产线工人看得到一条自动化链路怎么走，可以在关键节点插入“人工确认”步骤，这消除了智能体上线的最大阻力——信任问题。

2. 系统架构与工具选型：我们是如何把AI和低代码黏在一起的

2.1 整体架构分四层

这个方案的整体架构，我习惯分为四层来说，每一层解决一类问题。

数据接入层是地基。新能源工厂里的数据源特别杂，有OPC UA协议从PLC采上来的实时数据，有MES里的工序数据，有ERP里的工单和物料数据，还有大量PDF版的作业指导书、设备手册。这一层要解决的是“多源异构数据的统一接入和语义对齐”问题。我们用了物联网平台做时序数据采集，再用低代码平台内置的ETL节点把业务系统的接口数据拉通，大模型需要阅读文档时，就挂一个文档解析组件。

模型服务层是大脑。这一层包括大语言模型、视觉模型、预测模型、优化模型。大模型负责自然语言理解、根因推理、文本生成，视觉模型负责产品外观检测和数据报表图像识别，预测模型负责设备健康度预测和能耗预测，优化模型负责产线排程等数学规划问题。低代码平台通过“模型配置节点”统一接入这些模型，对外暴露的是标准化的接口。

智能体编排层是神经中枢。这个层把“感知—决策—执行”串起来。一个Agent由若干节点组成，节点之间通过数据流和控制流连接。低代码平台在这一层的核心能力是做状态管理和分支逻辑处理。例如，一个设备预警Agent先判断报警级别，如果是低级报警就只记录并通知，如果是高级报警就触发大模型分析根因，分析结果再进入人工确认节点。

应用交互层是人与系统交互的窗口。我们做了三端：PC端的管理看板、移动端的值班助手、车间大屏的实时监控。这三端共用同一套Agent逻辑，只是展示的粒度不同。值班人员可以在企业微信里直接向Agent提问“昨晚三线停机的原因是什么”，Agent会自动调度相关工具，检索MES日志、设备报警记录、班次排班数据，然后用自然语言回答。

2.2 工具选型的三条原则

在这次项目选型里，我们对比了市面上的低代码平台、智能体开发框架和工控软件，最终确定下来的选型原则有三条。

第一条，看生态联通能力，不看单点功能。新能源工厂的IT环境不是空白，是既有系统林立的场景。平台必须开箱即用地支持OPC UA、Modbus TCP、HTTP API、消息队列、数据库连接等常见协议。很多功能华丽的低代码平台，一接工厂数据就卡壳，原因就是协议适配层太薄了。

第二条，看模型管控粒度，不看模型数量。平台里能不能对不同场景设置不同的大模型？能不能对模型输出的长度、温度、安全规则做细粒度控制？新能源工厂的质量场景要求强确定性，而日报总结场景要求发散性，两者对模型参数的需求是冲突的。平台要能支持在同一工作流中调用多个模型实例，并且按节点做参数隔离。

第三条，看权限与审计能力，不看部署形态。产线系统的任何改动都涉及质量追溯。智能体的每次自动执行、每次参数修改都要留痕。选低代码平台时必须确认它有完整的操作审计日志，审计粒度要精确到节点级别，而不是只有“谁在什么时候登录了系统”这种粗颗粒日志。

3. 智能体从0到1的完整落地过程

3.1 场景选择：怎么找到第一个能“打样”的Agent

智能体在制造业落地最大的忌讳，是贪大求全。我们一开始就明确了第一期的目标不是建一个“万能系统”，而是做三到五个能看得见效益的垂类Agent，跑通之后再做横向复制。

场景选择有三个筛选条件：数据可得性高、决策链路短、效益可量化。

以“涂布机参数自优化Agent”为例。涂布是电池极片生产的关键工序，涂布面密度一致性直接影响电池容量和寿命。过去这个参数调整完全依赖工艺工程师的经验，每次换型需要反复试跑，材料浪费很大。

这个场景满足三个条件：涂布机的传感器数据完整，PLC和MES里的历史数据都有；决策链路短，调整的就是涂布间隙、走带速度、浆料流量这几个参数；效益可量化，材料浪费的降低和良率提升可以直接算成金额。

另一个打样场景是“设备运维问答Agent”。工厂里的设备手册有几百份PDF，工程师排查故障时翻手册非常低效。我们把这些文档向量化后存入知识库，再让Agent具备调用MES接口查询设备状态的能力，工人遇到报警时直接在对话界面提问，Agent会先查手册的相关章节，再结合设备的实时数据给出初步判断。

3.2 数据接入的“卡脖子”问题

数据接入是整个项目里耗时最长、最容易翻车的环节。我们第一个月几乎全在跟数据搏斗。

典型问题有三个。第一，时区和对表问题。Mes里的时间是车间本地时间，时序数据库存的是UTC时间，两者默认差了8小时，很多数据分析结论一开始全部错位。第二，数据粒度问题。PLC采集是毫秒级，MES记录是分钟级，做关联分析时必须先做对齐和降采样。第三个问题最隐蔽，是数据会话问题——不同批次的物料数据如果不在代码里显式区分，模型很容易学到错误规律。

我们的解决方式，是标准化建立了三层数据模型：物理层按设备ID和时间戳存储原始时序数据；业务层按工单号、批次号组织工序数据；指标层则把上述两层映射成OEE、良率、能耗等标准化指标。智能体在上层调用数据时，不直接面对物理层的原始表，而是通过指标层的统一接口去读，这保证了语义的一致性。

3.3 在低代码画布上搭智能体：一个实例拆解

下面用“质量异常根因分析Agent”作为实例，完整拆解在低代码画布上搭建的过程。

这个Agent的业务逻辑是：某工序不良率突增时，自动收集相关信息，综合分析原因，给出建议动作。流程共分五个节点。

节点A是事件触发器。我们设置了两种触发方式：定时触发，每天早中晚各跑一次；异常触发，当MES里检测到不良率超过设定的阈值（比如高于正常值1.5个标准差）时实时启动。触发器节点里设置了冷却时间，防止同一个异常反复触发。

节点B是数据采集器。这里通过可视化配置，把不良产品涉及的工单号、设备号、物料批次、工艺参数全部查询出来。这个节点最需要细心的地方是时间范围窗口。我们默认取异常发生前15分钟到异常发生后5分钟的数据，这个窗口设定经过了多次反复验证。窗口太短会漏掉根因，窗口太长会引入大量无关噪声。

节点C是大模型分析节点。所有采集到的数据，包括结构化参数和MES日志文本，拼接成上下文后发送给大模型。提示词（Prompt）分三层组织：第一层是系统设定，告诉模型“你是新能源电池车间的质量分析专家”；第二层是背景信息，给出产线正常参数区间和已知的相关性规律；第三层是待分析数据。这里最重要的是在提示词末尾加上“只根据提供的数据分析，不要推测未提供的信息”，这是为了防止大模型凭借训练时的记忆胡编参数。

节点D是决策分支节点。根据大模型输出的结论置信度和原因类别，决定后续动作路径。如果大模型给出“设备参数偏移类”的结论，就进入参数调整建议模块；如果是“来料批次问题”，则自动生成来料隔离工单；无论哪种情况，最终都必须进入人工确认环节。

节点E是人工确认与执行节点。系统生成建议后，在企业微信里推送给工艺工程师，工程师可以一键采纳、驳回或修改。采纳后系统才真正向MES发送参数调整指令，同时把整个过程写入审计日志。

从搭建时间来看，这个Agent从画布拖拽到逻辑测试通过，大约花了一个星期。这在传统开发模式下是不可想象的，传统模式下至少需要两个月的需求调研和代码开发周期。

3.4 多目标调度优化：让Agent从“会分析”到“会决策”

新能源工厂的调度是一个典型多目标优化问题。以光伏组件车间为例，排产时同时要满足交期、设备利用率最大化、能耗最小化、换型次数最少化这几个目标。而且这几个目标之间常常互相冲突，例如追求设备利用率最大化就会增加换型次数，进而增加人工投入和物料消耗。

传统排产系统大多用线性规划或启发式算法，但真正落地效果差强人意。原因在于，传统模型的实际排产过程中大量隐性约束无法建模，比如某台设备只适合生产规格偏厚的组件、某条线夜班人员技能不足暂时不能承担精密工序。

我们的方案是把大模型和传统优化算法结合。低代码平台里的“调度Agent”先通过自然语言接口，向计划员收集当天交期、物料到货情况、人员出勤等实时信息，再把这些信息转化为结构化约束条件，传给底层求解器。

求解器的核心用了带精英策略的NSGA-II多目标优化算法。算法的种群规模设为200，迭代次数设为300，交叉概率0.8，变异概率0.1，这三个参数是在历史数据上做了几组对照实验后确定的。优化完成后，求解器会输出Pareto前沿的多个可行排产方案，每个方案都有交期、能耗、利用率、换型次数的详细指标说明。

最后关键一步，是让大模型把每个方案解读成业务人员容易理解的决策语言：“方案A比方案B交期缩短5小时，但能耗增加3%，且明早需要加班两小时。如果明天物料到货确认无误，建议选方案A。”这一层自然语言解释，才是调度Agent实际能被车间主管接受的关键。因为过去求解器给出的排产结果太抽象，计划员看不懂、不敢相信，自然就不会采用。

3.5 人机协同回退机制的设计

智能体上线必须设计好回退机制。我见过太多智能系统因为一次错误判断就彻底失去了现场信任，之后就再也推不动了。

我们的做法是“三层回退”：第一层，模型输出置信度低于某阈值时，自动走人工确认，不让系统自行决策；第二层，每个自动执行动作后面跟一个撤销按钮，操作人员可以在五分钟内一键回滚；第三层，系统级控制开关，车间的值班长可以一键把Agent切换到“只读分析”模式，此时Agent只输出建议、不执行任何写操作。

这个三层回退机制，在特斯拉生产方式里叫“自动化以人为本”。让自动化的每一步都置于人的监管和可干预范围之内，系ySTEM推进阻力会成倍减少。这条经验应该排在所有技术细节前面。

4. 实施过程中的高频问题与排查技巧实录

4.1 数据断层：为什么AI经常“一本正经地胡说八道”

这是整个项目中出现最频繁的问题。Agent分析出来的结论看起来很合理，但实际一核查，发现数据链路上存在着断裂。

一次“焊接飞溅异常分析Agent”给出了错误结论，我们排查了半天才发现问题出在数据集成任务上。焊接设备的飞溅级别由视觉系统判定，视觉系统的数据先写入一套独立数据库，再由定时任务抽取到数据仓库。那个定时任务在当天凌晨失败了，导致Agent分析时使用的是视觉系统前一天的数据，自然得出了错误回归。

排查这类问题的核心技巧，是在Agent每个数据采集节点后面加一个“数据新鲜度检查”子节点。如果数据的时间戳与当前时间的差值超过某设定阈值，就中断流程并告警，而不是把陈旧数据直接喂给大模型。

同时，我们还在监控大屏上专门做了一个“数据血缘图”的可视化面板，把每个Agent节点用到的数据来源、采集任务、最近更新时间全部展示出来。一旦Agent结论可疑，优先看数据血缘图，80%的问题都能在那里找到原因。

4.2 模型幻觉在工业场景下的“刑罚”级后果

大模型的幻觉问题，在写周报时无伤大雅，在工业场景里却是致命的。有一次“设备保养提醒Agent”在分析某台空压机运行数据时，杜撰了一个“空气过滤器压差超标”的结论，结果差点触发一次不必要的停产保养。

后来我们在所有涉及安全阈值的Agent节点上加了三层防护。第一层，参数级防护：建立关键参数的“硬边界”白名单，大模型的输出如果超出白名单设定的物理范围，直接判定无效。比如空压机压差的高报警值是60kPa，模型说80kPa就自动拦截。第二层，逻辑级防护：增加“因果一致性校验”。模型说“因为A所以B”，系统会检查A和B之间在历史数据里是否有统计相关性，如果完全没有相关性就标记为可疑。第三层，人工抽检机制：每周随机抽取几个Agent决策记录，由工艺专家评估质量。

这三层防护下来，大模型的输出可信度从开始的85%提升到了98%以上——虽然还有2%的误判空间，但已经进入了“人工复检成本可接受”的范围。

4.3 IT/OT网络隔离：智能体的“最后一公里”难题

新能源工厂的OT网络和IT网络通常是物理隔离的，这是出于生产安全和网络安全的考虑。但智能体要发挥作用，必须打通IT系统（大模型部署环境）和OT网络（PLC、SCADA）之间的数据通道。

我们的方案是在DMZ区部署一套工业数据网关。网关通过OPC UA与OT侧设备通信，只允许单向数据写入，从OT侧采集的数据先经过协议解析和合法性校验，再经安全审计后转发到IT侧的AI平台。反向的控制指令则需要经过双重审批，而且所有控制指令都必须是低代码平台里预定义的模板，禁止自由文本直接下发给设备。

这个设计让网络安全的红线没有破，同时又把AI能力送过了“最后一公里”。这是整个项目里在架构层面最值得自豪的决策。

4.4 组织阻力：一线工人和管理层的信任缺口

系统上线过程中，最大的阻力往往不是技术，而是人。一线工人最开始很抵触，他们的第一反应是“系统要替代我”；中层管理者则担心“数据越来越透明，自己的话语权会下降”。

我们的破局方式是分几步走的。第一，不叫“智能系统”，叫“数据助手”，从名字上弱化“替代”的恐惧感。第二，先小范围试点，选择积极配合的班组，不搞一刀切强制推广。第三，把“使用Agent处理异常案例”计入班组绩效考核的加分项，让积极的班组得到实际的实惠。第四，也是最重要的一步，经理层的开放日——每两周让员工来反馈AI系统的不合理处，真正采纳其中一部分建议。

这个过程中让我感受最深的，是智能体落地的本质不是技术导入，而是组织学习和信任重建。凡是忽略这个规律的，无论技术多先进最后都会哑火。

5. 效果复盘与横向复制经验

5.1 用数据说话：三个月试点后的指标变化

项目在试点车间运行三个月后，我们收集了完整的数据。涂布机参数自优化Agent上线后，换型时间平均缩短了37%，换型过程中的极片材料浪费降低了约22%。质量异常根因分析Agent将异常定位的平均耗时从原来的4小时以上缩短到40分钟以内，而且分析报告的完整度明显高于以往人工书写的报告。多目标调度Agent上线后，排产方案的生成时间从半天缩短到半小时，且计划员对方案的采纳率达到70%以上，远高于过去优化算法的不到四成。

能耗方面的收益同样可圈可点。调度Agent在排产时动态考虑了峰谷电价因素，把高能耗工序尽量安排在谷电时段，试点车间每月的电费支出下降了大约6%。别小看这6%，在电池和光伏这种高能耗制造场景里，电费是仅次于材料的大额成本项。

5.2 什么类型的场景适合先做智能体

基于这三四个月的折腾，我总结出了新能源工厂里“适合智能体”的四个特征：

• 重复性高且依赖老师傅经验的场景，如参数调整、故障排查，经验可以被大模型学习并沉淀。
• 跨系统数据综合分析的场景，如质量异常定位，传统单系统分析无法覆盖全局。
• 决策结果需要被解释的场景，如排产建议，大模型能把复杂优化结果翻译成业务语言。
• 知识密集型但写作/分析负担重的场景，如设备运维问答、报表自动生成，释放工程师精力去处理更重要的事情。

反过来，纯高频刚性控制类动作，如设备启停、安全联锁，不适合智能体直接决策，必须留在PLC硬逻辑里。智能体的价值在辅助决策，不在替代安全控制。

5.3 从试点到规模化：平台化路径怎么走

试点跑通后，问题就从“能不能做”转向了“怎么做大”。我们发现，只有把能力沉淀成“可复用的组件”和“可配置的模板”，才能真正规模化复制。

具体做三件事。第一，把一期项目的Agent流程拆成通用节点模块，如数据查询节点、异常检测节点、大模型处理节点、人工审批节点，做成低代码平台上的标准化组件，新场景直接复用。第二，建立“场景模板库”，例如“设备健康管理模板”“质量追溯模板”“能耗优化模板”，新工厂上线时先导入模板，再根据产线差异做微调。第三，建立模型运营机制，针对每个场景定期评估模型准确率，把新数据进行标注后回流到微调循环中。

这套打法之下，团队已经把智能体方案从最初的电芯车间，复制到了模组PACK、光伏组件、储能系统集成等不同产线上。复制周期从首个场景的三个月，缩短到了新场景的两到三周，边际成本明显低于传统定制开发。

写在最后的一点个人心得

项目做下来，我最深的一个感受是：智能制造发展到今天，瓶颈早就不是算法精度或者算力不够了，而是“技术有没有被业务真正用起来”。AI低代码加智能体的组合，最大的贡献是打破了“业务人员提需求，IT部门写代码”的传统瀑布式协作，让懂工艺的人第一次有了亲手定义“智能”的能力。

如果你也在新能源工厂环境里准备推智能体，我的建议是：从最便宜、最易见效、最不影响主线生产的单点场景切入，把组织信任建立起来，比一次性铺开十多个场景重要得多。同时，永远给人工干预留一个物理开关，这不是技术妥协，而是让智能系统在真实生产方式里活下来的最低成本。透明、可控、可回退，才是智能制造智能体应用真正走向拐点的底气所在。