AI-native架构重塑制造业ERP/MES：从零重建实战复盘与踩坑指南

我先直接说结论：这套系统做下来，比我想象中的"老系统上包一层AI"要复杂得多，但也值得多。如果你也正打算用AI重做制造业核心系统，这篇复盘应该能帮你少踩几个大坑。

先说标题里那个词，AI-native架构。这个词最近被炒得厉害，很多人以为就是把ChatGPT塞进老ERP里，搞个聊天机器人问库存、查工单，那叫AI附庸，不叫AI-native。真正的AI-native是反过来，整个系统的架构设计、数据流转、业务逻辑拆解，从第一天起就是围绕"AI什么时候介入、介入多深、人类如何接管"来设计的。制造业的ERP和MES又是所有企业软件里最硬核的领域之一——牵涉物料、产能、工单、质检、设备状态，数据实时性要求高，业务规则还特别吃行业Know-how，这套东西能做成AI-native，对架构设计的要求几乎是地狱级的。

我自己动手做这件事的动机其实很简单：现在市面上的MES（制造执行系统）和ERP（企业资源计划）太重了，逻辑僵化，改一个字段要动表结构，加一个业务流程要走变更评审。制造企业的现场变化极快——临时插单、设备宕机、物料短缺、工艺参数调整——这些场景传统系统的响应速度根本跟不上。我想试试用新的架构思路把这种灵活性找回来，同时让AI直接成为业务系统里的一等公民，而不是外挂。

如果你也在做类似的事，或者正在评估要不要走这条路，这篇就当是同行之间聊聊天，把我在真实项目里拆过的模块、选过的型、填过的坑，都摊开来讲。

1. 先想清楚：AI-native不只是一个技术词，更是一种架构思维转换

1.1 传统ERP/MES为什么"重建比改造划算"

在做任何代码之前，我先花了三周时间想明白一个问题：为什么非要从零重建，而不是在现有系统上修修补补？

传统制造业系统的架构大多是00年代定型的。典型的形态是单体应用加一个关系型数据库，服务端渲染页面加若干报表。这种架构有个致命伤：所有业务逻辑都藏在服务内部，数据模型是跨模块共享的，订单、物料、生产、财务之间用强外键耦合。好处是事务一致性强，坏处是改一发动全身。

更麻烦的是，这种系统的流程是"预设"的。比如标准MES里，工单派工通常固化一键式操作：计划员排产、车间主任派工、操作工报工、质检员检验，一环扣一环，中间没有多少动态调整的空间。但在真实工厂里，排产经常被打乱。我去过一家做精密加工的企业，他们的订单经常临时加塞，还经常出现"这批料先做，因为客户在催"这种优先级倒置。老系统里这类需求，你得去改工单状态流转逻辑，改完还要测各种边界情况。

所以我的判断是：与其在僵化的老骨架上焊接AI零件，不如重新做一版架构——这一版的灵魂是"数据模型不变、流程逻辑可由AI动态编排"。

1.2 什么是真正的AI-native架构

我自己的定义比较野，不一定符合学术标准，但对实战有效：AI-native架构至少要满足三件事。

第一，AI不能是外挂接口。系统里必须有一个明确的位置，让模型推理成为业务链路里的一个可被调用的节点，和"调用一个库存服务"没有本质差别。这不是说在Controller里new一个OpenAI客户端就算完，而是要从协议层、数据层、任务编排层都设计到位。

第二，业务要能自描述。传统系统的业务逻辑散落在代码和SQL里，AI根本读不懂。AI-native要求每一种业务实体、每一个操作动作都有机器可读的语义描述，这样模型才能理解车间里正在发生什么。

第三，人机权责要清晰。系统提醒"此单建议紧急插单"，但这只是建议，执行必须走人工确认。架构上就必须区分"AI决策"和"人工决策"，并且有完整的审计链路。

我最后选了LLM+API、Agent架构、微服务、事件驱动这几种技术的组合。不是追求潮流，是因为制造业ERP/MES这摊事，信息流转的实时性和异构性都太强了，单一的同步调用根本扛不住。

2. 制造业ERP/MES的系统拆解：哪些模块值得用AI重做

2.1 核心域划分：先从业务对象开始

制造业系统无论叫什么名字，业务对象翻来覆去就是那几个：物料、BOM（物料清单）、工艺路线、工单、工序、设备、人员、质检批次、库存、供应商。这些对象在数据库里是表，在领域驱动设计里叫聚合根。

我第一版设计时，没有一上来就分微服务，而是先做了领域划分。因为制造业这些域之间的耦合度极高，硬拆会很痛。比如一个简单的报工操作，要同时影响工单进度、工序在制量、设备运行时长、员工工时、质检验证状态——这五个领域如果拆成五个微服务，事务一致性立刻成了大问题。

所以我的思路是"域内强一致、域间异步化"。比如生产域内部，工单、工序、报工、质检放同一个服务；但生产域与库存域之间通过事件通信，而不是同步锁。

2.2 AI融进去的位置：计划、调度、执行、质检

我规划了四个核心切入点。

第一个是需求预测与计划排程。传统MRP（物料需求计划）是基于固定提前期的刚性计算，实际现场一大半时间都在应对异常。AI在这里的价值是"动态修正提前期"——比如某个供应商最近三个月老是延期，模型应该自动把这个供应商的物料提前期拉长，在爆仓之前就预警。

第二个是智能派工调度。这是MES最核心也最难的环节。车间里可能有几十台设备、上百个工单、不同的工序约束，传统做法是排程算法跑一个确定性模型。AI在这里不是要替代算法，而是要做"调度建议+"：根据历史数据推荐最合适的设备、给出瓶颈预警。

第三个是工艺参数推荐。比如数控加工，不同材质、刀具、机床状态组合下，合理的转速进给完全不同。老师傅凭经验，AI可以根据历史加工记录给出参考工艺参数。这一块是最能落地出效果的，因为见效快、价值直接。

第四个是质量异常根因分析。质检不合格后，传统系统就是记录一下然后走返工流程，但AI可以发现"这一批不合格的工件都是夜班2号机床加工的，且当天湿度偏高"这种隐藏相关性，帮助质量工程师快速锁定根因。

3. 从零重建的实操路径：架构、数据、AI能力落地

3.1 技术选型：我最终选了什么样的基座

我这套系统的技术栈如下，不一定是最优解，但经过实战验证是稳定的：

这里有个关键的决策点：为什么用LangChain4j而不是自己写一堆Prompt模板？因为制造业系统的业务流程是一环扣一环的，Agent需要记忆上下文、还需要调用多个工具（查库存、查BOM、算工时），没有框架的话，这些是你自己写Prompt也要重复发明轮子。

3.2 分层架构设计：AI在中间层，而不是在边缘

我最后的设计是这样的，分层很清楚：

接入层：Web管理后台 + 移动端（车间平板/手机） ↓ 编排层：AI Agent编排中心（这是AI-native的核心位置） ├── 意图识别 ├── 任务规划 ├── 工具调用（查库存、查工单、算提前期） └── 决策建议生成与审计 ↓ 业务服务层：生产域、物料域、质量域、设备域、人员域（微服务） ↓ 数据层：PostgreSQL + ClickHouse + OpenSearch

很多人在设计AI系统时会犯一个错误：让AI直接访问数据库或者直接操控业务服务。这很危险，因为大模型的输出有概率性，不可控。我在中间加了编排层，它做的事情是：把用户的自然语言或者系统自动触发的任务，转化成一个规范的工具调用序列，每个工具调用都有严格入参出参结构，AI没有自由发挥的空间。

流程触发的入口也分两类：一类是人主动触发，比如车间主任说"帮我看看明天有哪些设备最忙"；另一类是系统事件触发，比如工单报工时发现缺料，自动触发补料建议Agent。这两类走同一条编排链路，只是触发源不同。

3.3 领域事件与模型设计：让数据能够"雨后春笋"般长出业务

有了分层还不够，关键在于数据流怎么设计。我把制造业系统里所有状态变更抽象成"事件"，比如：工单已下发、报工已完成、质检已判定、物料已入库。每个事件都发到RabbitMQ，由对应的订阅方去消费更新自己的状态。这样做的好处是，当我要加一个新功能时，不需要改老服务，只需要新写一个服务订阅旧事件即可。

举个例子。传统系统里，工艺参数优化服务要读取加工记录的报工数据，那它就必须去调生产域服务的接口，还要自己评估字段变化的影响。但在我这套事件驱动架构里，加工记录上报事件发出来，参数优化服务自己维护一份"历史加工记录表"，字段不够了再扩展自己的表结构，完全不和生产域打架。

这个设计对AI尤其重要。因为AI模型训练需要的数据往往是跨域的，事件驱动天然提供了数据分发总线。比如一个质量分析模型要关联"工件生产参数"和"质检结果"，这两份数据来自不同域，但都能通过事件流汇聚到模型的训练集里。

3.4 AI模块具体怎么落地：Agent工具调用的完整样例

我在项目里最先落地的一个AI功能是"智能下单助手"，让计划员在开生产订单时，可以直接用自然语言描述需求，系统自动检查物料齐套、产能是否足够，再生成草稿订单。

这个功能的实现，核心就是三个部分：意图识别、工具调用、结果组装。

用一个简化的代码示例来说明（实际项目里更复杂，但核心逻辑相同）：

// 这是LangChain4j中定义Agent可用工具的示例 @Tool("查询库存") public class InventoryTool { @ToolMethod public String queryStockLevel(String materialCode) { // 实际调用库存服务 StockLevel level = inventoryClient.getCurrentStock(materialCode); if (level == null) { return "物料不存在"; } return String.format("当前库存为%d，可用库存%d，安全库存%d，账存时间%s", level.getTotal(), level.getAvailable(), level.getSafety(), level.getLastUpdated()); } } // 这是当用户说"查一下 A-1005 的库存和它的BOM子件缺不缺"时 // Agent会先解析出两个任务：查询主件库存、查询BOM子件库存 // 然后分别调用InventoryTool的两次 // 这是生成订单的Action @Tool("生成生产订单草稿") public class OrderTool { @ToolMethod public String createDraftOrder(String productCode, int quantity, String dueDate) { // 校验BOM是否存在、校验提前期、调用工单服务生成草稿 String orderNo = orderClient.createDraft(productCode, quantity, dueDate); return "生产订单草稿已创建，单号:" + orderNo; } }

这个环节我踩了一个很重要的坑：Tool的参数越少越好。一开始我把工具定义得特别细，十来个参数，结果模型经常传错，需要反复重试。后来把所有需要内部查询的参数统统在服务端预组装好，Agent需要传的参数只保留"是什么、多少、何时"这种最基础的信息，准确率一下就上去了。

3.5 MES核心流程改造：报工、质检、设备状态采集

说完了全局架构，再来聊MES里最重的三条线——报工、质检、设备状态。

报工是MES的心脏。传统MES给操作工的任务就是"扫码→填写数量→提交"。我的AI-native版本里，报工变得更聪明：操作工可以语音输入"这批工件加工完了，做了32件，废了1件"，系统自动识别工件号、工序号、数量，填入工单再触发异常判定——这一批报废率超过了3%的阈值，系统会自动生成质检预警工单。

质检这块，我在老系统里经常看到的问题是质检记录就是一个"合格/不合格"的结果表，根本不够AI分析用。所以我把质检拆成了两层：第一层是结果采集（合格、返修、报废），第二层是缺陷现象描述（毛刺、磕碰、尺寸超差、表面粗糙度），后者用自由文本加标签两种方式记录。这样AI根因分析才有数据可用，不能只给个红绿灯。

设备状态采集更麻烦，因为车间里有大量老旧设备根本没有数字化接口。我的方案是加装低成本传感器采集电流和振动信号，用边缘计算网关做简单的数据滤波和特征提取，然后把特征数据传到ClickHouse。这套东西不是AI-native架构本身，但我把所有采集上来的数据都打上了标准的资产ID和时间戳，为后面做预测性维护留好了接口。

4. 踩坑实录与排查技巧：三个月实战填出来的坑

4.1 最大的坑：AI响应延迟在制造现场不可接受

第一个版本上线时，车间主任跟我反馈："你这个AI靠谱是靠谱，但是太慢了，问一句要等3秒才出结果，我现场等不及。"

这个反馈其实暴露了一个架构级问题：我最初让所有AI功能都同步走大模型推理，但生产系统里很多操作是需要毫秒级响应的。后来我把AI应用场景分成两类：一类是"离线辅助"，比如班次开始前的排程建议、质量分析报告，这些可以接受10秒内的延迟；另一类是"在线查询"，比如扫码报工时的语音识别和自动填充，这个必须快。

解决方案是：在线场景用轻量级模型做意图识别和信息抽取，大模型只做兜底。我直接在车间本地部署了一个7B参数的小模型做实体抽取，响应时间压缩到300毫秒内。复杂任务才转发到大模型处理。这个"分级推理"的设计，是AI-native系统落地时几乎必然要走的一步。

4.2 数据质量：做AI之前，先花60%的时间洗数据

这可能是最不值钱但也最没人愿意写的经验：AI-native系统拼的是数据，不是模型。

我们接了一家压铸厂的MES改造，最开始的模型评估准确率只有一半，排查发现不是因为模型不行，而是老系统里的报工时间字段经常是错的——操作工习惯了整批提交，有些订单完工时间是空着或者乱填的。我把这些脏数据喂给模型，当然是垃圾进垃圾出。

后来我专门写了一个数据质量巡检Agent，定期扫描系统里的异常数据模式，比如"报工时间早于工单下发时间"、"质检结果与工序逻辑矛盾"、"物料批次号重复"等等，扫出来变成数据质量工单，让专人处理。这个Agent本身不贵，但对整个系统价值的提升，比任何模型调优都大。

4.3 微服务拆分的教训：过度拆分导致查询性能暴跌

我一开始把微服务拆得很细，物理域一个服务、逻辑域一个服务、质检一个服务、设备一个服务。等联调时发现一个严重的性能问题：报表要跨四五个服务join数据，每个join都是一次网络调用，一个本来单库查询2毫秒的接口，变成了200毫秒以上。

后来我按前面说的四个大域重新收敛为五个服务：生产域（工单+工序+报工+质检）、物料域（物料+BOM+库存）、资源域（设备+人员）、计划域（排产+计划）、审计域（操作日志+数据质量）。这里想分享一个经验：微服务拆分时不要按"数据库表"拆，要按"业务生命周期"拆。一个工单从生到死的所有状态都归生产域管理，这样才能尽量做到域内自包含。

4.4 人机协作的边界问题：什么时候不能听AI的

最后这个坑是关于权限的——很多AI系统容易出现"AI建议直接执行"的倾向。在制造业里这是绝对不能接受的。我定了一条强制规矩：AI只能生成建议，不能直接下发指令。所有计划变更、工单修改，必须有人的确认动作。但为了不让人负担太重，我给每种建议定了置信度级别：高置信度建议通过弹窗确认一键确认；低置信度建议推送给对应的业务负责人，由他们安排时间处理。

这个设计背后有深刻教训。有一次，AI因为设备历史数据异常，建议把某台设备标记为"计划外维护"，如果自动执行了，会影响当天该设备上的所有在制订单交期。因为影响了太多下游环节，这个动作必须走人工审批流程。系统可以提示"有3个已下发的工单可能会延期8小时"，但审批权必须抓在人手里。

4.5 常见问题速查表

整理一份我项目里最常被问到的排查清单：

5. 这趟重建下来，我对AI-native架构的最终理解

项目走到现在，我对AI-native这件事有了比刚开始清晰得多的判断。它不是什么魔法，也不是什么银弹。它更像是一种"系统设计的前置觉悟"——你在画数据模型的时候，就要想到这些数据会作为上下文喂给模型；你在定义工具接口的时候，就要想到这些接口会被模型调用；你在设计权限体系的时候，就要想到如何让AI的建议权和人的决定权相互咬合。

这套系统目前已经在一家小规模机加工厂跑了大半年，核心生产域的报工和质检流程稳定运行，AI辅助的排程建议大约每周能帮计划员省出半天的手工计算时间。说实话，和那些全自动化黑灯工厂比起来，这个成绩不算惊艳，但对一个现金流吃紧、设备老旧的中小制造企业来说，这是最现实的进步方式。

我记得有一次去车间回访，计划员老张跟我说了一句话，让我觉得这套架构算是成了。他说："以前我最烦的就是天天接电话问货期，现在这个系统自己会算，还会提前提醒我哪几个单危险，我只要决定是先保大客户还是先保准时交付就行。"

这句话点醒了我：AI-native的最终目的从来不是让AI面面俱到，而是把人的精力从繁琐的计算和排查中解放出来，让人专注在真正需要判断力的事情上。架构再怎么花哨，到最后，好用、能解决问题、人还愿意用，才是硬道理。

最后再分享一个我个人的小习惯：每次迭代新功能，我都会去做一次"假如AI不存在，这个功能还成立吗"的自检。如果成立，说明AI只是点缀；如果不成立，说明AI真的进入了链路的核心。我推荐你也试试这个方法，它能帮你保持清醒，不至于为了AI而AI。

这套系统的路还很长，预测性维护、供应链协同、跨工厂调度，每一块都还有大量提升空间。但第一步既然走通了，接下来就靠一步一步踩出来。