一家电子厂用AI Agent打通MES与ERP数据：完整的系统集成实施记录

去年秋天，一家苏州的电子线束组装厂找到了我们。工厂规模不算小——6条组装线、200多人——但管理上有个老毛病一直解决不了。

他们的车间用了一套国产MES系统（自己找人开发的，功能比较基础），但财务和库存管理用的是金蝶ERP。这两个系统之间的数据是断开的。每天，车间文员要把前一天的实际产量、物料消耗、不良品数量从MES打印出来，再逐条录入金蝶。3个人，每天花2-3小时做这件事。

听起来好像也不是大问题？但实际的情况是：产量数据经常输错（少一位数字、串行、漏行），库存账实不符是常态，每个月对账都要折腾好几天。最严重的一次，一个型号的端子库存账面显示还有5000个，实际只剩200个——生产线差点停产。

他们想找一个方案，让MES的数据自动流到ERP里。但这并不像"加一根网线"那么简单。这篇文章记录我们是怎么一步步做到的，以及中间踩了哪些坑。

一、现场情况摸底

去工厂蹲了三天，主要摸清了几个事情：

• MES现状：车间里每个工位有工控机，操作工完工后扫码记录产量。数据存储在工厂本地的一台Windows服务器上，MES系统有SQL Server数据库，但接口只有几个简单的查询存储过程——没有标准的API。
• ERP现状：金蝶K/3 Wise，运行在公司办公室的服务器上，有标准的网络API（WebAPI），但调用有频率限制（每分钟60次），部分接口还需要先通过验证逻辑才能提交。
• 人工流程：文员每天下午4点去车间拿MES打印的生产日报表→回办公室打开金蝶→逐单录入生产入库单、材料出库单、不良品记录。遇到异常情况（返工、补料、拆单）还要找车间主管确认，经常拖到第二天才能录完。
• IT人员：有一个年轻的IT专员，会写点SQL，但对ERP内部逻辑不太熟悉。金蝶的维护是外包给本地服务商的。

方案的前提条件也清楚了：不能改动金蝶的数据库（金蝶服务商不允许），不能影响MES现有的业务流程，预算有限（几万块）。

二、方案设计

我们需要一个介于MES和ERP之间的"翻译层"——读取MES的生产数据，按金蝶的业务规则转换格式，再调用金蝶的API写入。看起来简单，但实际上要处理的问题不少。

为什么用AI Agent而不是传统ETL？

一开始我们想的是标准的ETL工具——写几个Python脚本定时跑就行。但深入了解后发现，MES到ERP的数据映射不是简单的字段对字段：

• 同样的物料在MES中用"内部编码"（比如W-0012），在金蝶中用"物料代码"（比如02.01.003.0012）——需要查映射表
• 产量统计口径不同——MES记录的是"每个工位完工数量"，但ERP需要的是"成品入库数量"，两者中间有在制品、返工品、报废品的调整
• 异常场景的处理逻辑需要判断——某张工单如果MES标记为"部分返工"，ERP中需要同时创建生产入库单（良品部分）和生产返工单（返工部分）
• 金蝶API的调用顺序有严格的依赖——必须先创建生产入库单头，再添加分录明细，最后提交审核

这些逻辑如果用传统ETL硬编码，维护成本会很高。每次MES或者金蝶的版本更新，脚本就要跟着改。所以最终选择了AI Agent的方式——让大模型理解MES的数据内容和金蝶的业务规则，动态生成ERP操作指令。

架构三层

数据层（MES侧）：在MES服务器旁边部署一台边缘AI网关。网关通过ODBC直连MES的SQL Server数据库，每5分钟拉取最近的生产数据（完工记录、质检记录、物料消耗记录）。同时读入"映射表"——物料编码对照、BOM结构、仓库信息——这些作为AI Agent的知识库。

业务层（AI Agent）：在网关本地运行一套AI Agent工作流：

• Step 1 - 数据校验：读取MES数据后，先做合理性检查——比如产量不能为负数、完工时间不能晚于当前时间、数量不能超出工单总量
• Step 2 - 业务分类：判断这批数据属于什么业务类型——正常入库、返工入库、报废处理、补料出库
• Step 3 - 数据转换：根据映射表把MES的字段转成金蝶要求的格式，计算单位换算（MES用"个"，金蝶用"件"，1件=1000个这种）
• Step 4 - API调用：按金蝶API要求的顺序，生成JSON请求体，调用对应的接口写入
• Step 5 - 异常处理：如果API返回错误，记录异常信息并挂起该条记录，等待人工处理

监控层：一个轻量级的Web看板，展示：

• 今天的同步状态（成功/失败/待处理）
• 异常记录列表（什么数据、什么错误、谁处理的）
• 数据追溯（一笔金蝶入库单对应的MES原始记录是什么）
• 手工补录入口（当AI Agent判断不了的时候，文员可以手动确认并提交）

关键的实现细节

AI Agent的提示词（Prompt）设计花了挺多功夫。最核心的是两点：

业务规则注入：把金蝶的业务规则写进提示词的System Prompt里。比如"金蝶的生产入库单要求：单据头必须包含日期、工单号、仓库、部门；分录明细必须包含物料代码、数量、单价来源为移动平均"。这些规则是从金蝶的用户手册和现场调研中提取的，写成了结构化的条款。

异常兜底策略：如果AI Agent遇到判断不了的情况（比如一条MES记录的质检结果标记为"待判定"但质检员还没签字），不抛出错误，而是把这条记录放到"待处理"队列里，在看板上高亮显示，由文员手工确认后再继续。

踩坑小插曲：第一个版本的Agent遇到任何不确定就直接拒绝执行，把全部数据丢到异常队列。结果运营第一天下午3点，异常队列里堆了80多条记录——文员崩溃了。后来改成"能处理的自动处理，不确定的挂起"，异常比例降到约5%。

三、实施过程

第一周：数据摸底和映射表整理

这是最花时间的一步。要搞清楚MES里的每个字段对应金蝶的什么字段，中间需要什么转换。

具体做了几件事：

• 导出MES数据库的所有表结构，找出和产量、物料、库存相关的12张表
• 和金蝶的服务商一起理清金蝶API能支持的业务场景（不是所有MES的业务都能自动映射到金蝶）
• 整理了物料编码映射表——MES有4200多个物料编码，金蝶有3800多个，其中有不少是一对多或代码逻辑完全不同的
• 写了一个对照脚本，自动匹配了约80%的编码，剩下20%手工确认

还发现了一个意料之外的问题：MES里有17个物料编码在金蝶中找不到对应记录。后来查明，这些是试验性的新物料号，只在MES里开了还没来得及在金蝶中创建。要么补创建，要么在Agent里加一条规则——找不到映射时跳过该记录并告警。

第二周：MES数据读取和校验

部署边缘网关，配置ODBC连接到MES的SQL Server。写了一套数据校验规则：

• 空值检查：关键字段（工单号、物料代码、完工数量）不能为空
• 范围检查：产量不能小于0，温度/湿度这类数据在合理范围内
• 逻辑检查：完工时间不能早于工单开工时间，质检时间不能早于完工时间
• 重复检查：如果一条MES记录已经同步过，跳过

这些规则看起来基础，但在第一轮跑数据时，发现了30多条异常数据——有的是MES里的脏数据（操作工没填完就提交了），有的是系统Bug（重复生成了相同的完工记录）。这些数据如果直接灌进金蝶，后果很严重。

第三到四周：AI Agent开发和调优

这是最核心的开发阶段。用了一个轻量级的LLM模型在本地运行（量化版本，不需要GPU），主要是为了数据主权——工厂的数据不允许传到外部API。

开发过程中迭代了3个版本：

V1 - 全自动模式：Agent直接读取MES数据→转换成金蝶API请求→调用→返回结果。结果：正确率约70%。主要问题：Agent对金蝶API的字段格式理解有偏差（比如日期格式要求"YYYY-MM-dd"但Agent输出了"YYYY/MM/dd"），还有一些业务规则没覆盖到（比如返工品需要创建单独的单据类型）。

V2 - 半自动+人工复核：Agent处理完成后，在推送到金蝶前先经过看板预览，由文员点击确认后再推送。结果：正确率提升到约90%，但文员每天还是要花20-30分钟审核。虽然不是理想的全自动，但比之前3个人2-3小时好太多了。

V3 - 基于规则的Agent：在V2的基础上，把最常见的错误模式写成了硬编码规则（类似"如果物料编码以S-开头，金蝶端对应的是半成品类"）。AI Agent负责处理模糊判断（比如判断业务类型），精确转换由规则层执行。结果：正确率约95%，每日需要人工干预的记录降到5条以内。

我的体会：在这个场景里，AI Agent最大的价值不是替代规则，而是处理"规则写不清楚但人一看就懂"的判断。几类典型的业务场景（正常入库、返工、报废、补料）之间有一些模糊地带——MES里的"部分报废部分返工"这样的情况，写if-else会陷入组合爆炸，但Agent能准确判断。而精确的字段格式转换和数据校验，还是规则更可靠。

第五周：金蝶API对接和测试

金蝶K/3 Wise的WebAPI有几个让人头疼的地方：

• API限频：每分钟最多60次调用。乍一看够用，但实际上一张生产入库单需要3次API调用（创建单据头→创建分录→提交审核），如果同时处理20张单子就是60次——刚好卡线。后来加了队列调度，每批处理，API调用间隔1秒以上。
• 验证逻辑：金蝶在提交审核时会做内部业务校验——比如"物料代码是否存在"、"仓库是否允许该物料入库"、"数量是否在合理范围内"——这些校验失败会返回错误码，但错误信息有时候很模糊（"操作失败，请联系管理员"这种级别的提示）。调试阶段花了不少时间靠猜。
• 事务一致性：金蝶没有提供批量事务接口。如果一套流程中前两步成功了、第三步失败，已经创建的数据不会自动回滚。需要Agent自己来做补偿——检测到失败后，反向调用删除接口把之前的记录清掉。

这周主要就是和金蝶的WebAPI"搏斗"——处理各种边界情况。金蝶服务商的态度还算不错，配合修改了部分校验逻辑（比如允许负库存暂估入库的配置）。

第六周：试运行和调优

试运行两周，文员那边的反馈主要集中在这几个点：

• "能不能在推送给金蝶之前让我看一眼？"——虽然V3已经自动化了，但文员需要安全感，尤其是刚上线那周。所以加了"预览模式"：Agent跑完但先不提交，文员确认后再批量提交。
• "异常提示看不懂"——Agent有时候返回"ERP API调用失败：error_code=50027"。这种信息对文员来说没用。后来改成了中文的异常描述："金蝶仓库编号WH-01不存在该物料，请联系ERP管理员核对"。文员可以截图转发给金蝶服务商。
• "能不能回退最近一次的操作？"——有一次Agent误把一批返工品当做正常入库品推到了金蝶。虽然及时发现并手动回退了，但推动了后续我们加了"一键回退"功能，可以回退最近N分钟内的所有操作。

这两周的调优很关键。到第二周结束时，人工干预量从一开始的每天10条降到了3条左右。文员的工作从"录入数据"变成了"审核异常"——工作强度明显下降。

四、实际效果

系统上线稳定运行3个月后，我们统计了几个数据：

还有一些不太好量化的改善：

• 老板终于能看到当天的真实产能了——以前报表滞后1-2天，有些问题等到发现已经过了最佳处理窗口
• 产销会议上，销售和生产的"数字争吵"少了很多——大家看到的数据是同一套
• 仓库的物料周转效率有改善——库存数据实时更新后，采购能更准确地安排补货时间

五、遇到的问题和解决办法

坑1：物料编码不一致

MES中有4200个物料编码，金蝶中3800多个。一对多的情况有40多组——同一个物料在MES中拆成了多个编码（按规格细分），但在金蝶中是同一个物料代码。还有12个MES物料在金蝶中完全没有对应记录。解决方案：建立完整的映射表，并设计了"未映射物料"的处理规则——Agent跳过并告警。

坑2：金蝶API的事务缺失

金蝶的API是一口一个调用的，没有批量事务。如果创建单据头成功但添加分录失败，没有自动回滚。Agent需要自己检测失败并调用删除接口清理。这个补偿逻辑花了不少精力调试——因为删除接口本身也可能失败（比如单据已经被人为审核了）。

坑3：MES中的脏数据

操作工有时候会误操作——比如扫错了工单号、数量多输了一个0、或者提交了重复记录。这些脏数据如果不加校验直接推给金蝶，入库单就错了。最终在Agent里加了多层数据校验——包括和BOM标准用量做对比、和工单总量做对比、和同工位历史产量做对比——偏差超过设定阈值就挂起等待人工确认。

坑4：业务场景的无限多样性

"正常完工入库"只占约70%的业务量。剩下的30%包括：部分报废加部分返工、跨月工单、紧急插单补料、模具试模入库、委外加工回库……每种场景在MES和金蝶之间的数据映射逻辑都不同。Agent不可能覆盖全部，所以设计了一个"处理不了的交给文员手工补录"的兜底机制——不是所有问题都能用自动化解决。

坑5：文员的信任建立

上线第一周，文员非常紧张。每次Agent自动提交后，她都要打开金蝶去查一遍，确认数据真的进去了。这种"手工验证自动化"其实抵消了自动化的效率提升。解决办法是把"预览+确认"模式延长了一周，并且在看板上加了"同步历史"（每一笔同步记录都可以追溯到MES原始数据），让文员能随时核验。约两周后，她开始信任Agent了，预览时间明显减少。

信任曲线：第一周全程疑心→第二周抽查→第三周开始接受→一个月后完全依赖。跟工厂IoT项目的运维信任曲线一模一样。

六、个人的思考

MES-ERP集成是个被低估的痛点。以前我们主要做设备层的IoT项目（传感器、数据采集、预测维护），但发现更让工厂老板头疼的往往是系统层面的数据孤岛。设备数据能不能用是"锦上添花"，但库存账能不能对上是"燃眉之急"。后者的付费意愿比前者强很多。

AI Agent在这个场景里的定位有点特别。它不是替代了某个岗位，而是改变了工作方式——从"录入数据"变成了"审核数据"。文员的角色没有消失（也不需要消失），但她的工作体验完全不同了。我觉得这是AI在制造业主业中比较理想的落地方向——不是取代人，而是让人的工作更有价值。

数据标准化比技术选型重要得多。整个项目最花时间的环节不是开发Agent，而是整理物料编码映射和业务规则。这个环节没有捷径——有多少物料就要对多少条，有多少种业务场景就要梳理多少种。技术方案可以复用，但业务数据的清理必须每个客户重新做一遍。

ERP厂商的开放性差异很大。金蝶的WebAPI本身还算标准，但文档质量参差不齐、错误信息不够友好。如果是用SAP或者Oracle，可能接口更完善但成本更高。如果是用自研的老旧ERP系统，可能连API都没有。方案的可迁移性取决于目标ERP的系统架构——中大型企业用SAP的、小微企业用Excel的、中间段用金蝶用友的——每个层次的方案都不一样。

最有价值的倒不一定是自动化本身。项目做完后，财务主管说了一句让我印象很深的话："以前月底对账是'吵架时间'——车间说账不对是财务的问题，财务说账不对是车间的问题。现在数据都是自动同步的，谁也别甩锅了。" 自动化带来的流程透明化，有时候比效率提升本身更有意义。

七、给你的建议

如果你也在考虑做MES和ERP的数据打通，几点实际的建议：

1. 先从最痛的点开始——不要想着一次把所有业务场景都自动化。生产入库和物料消耗通常是最容易出问题的两个环节，先做这两个。
2. 物料编码映射是地基——这个环节至少预留一周时间，让熟悉两边系统的人参与。不要试图用AI自动匹配所有编码，错误成本太高。
3. 接受"不全自动"——MES→ERP的流程中一定会有10-20%的异常场景无法自动化。设计一个清晰的人工处理流程，比硬撑着100%自动化靠谱。
4. 前两周做"预览模式"——让最终用户（文员、会计）有时间建立对系统的信任。强制全自动反而会让他们抵触。
5. 选对ERP接口方式——如果ERP有标准API（如金蝶、用友的WebAPI），用API调用。如果没有，考虑通过数据库中间表或者文件导入的方式（CSV/Excel导入）。后者虽然不优雅，但可行。
6. 保留审计追踪——每一笔从MES同步到金蝶的数据都要能追溯到原始记录。这不仅是为了对账，也是出了问题时能定位原因。