我先直接说结论这套系统做下来比我想象中的老系统上包一层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决策和人工决策并且有完整的审计链路。我最后选了LLMAPI、Agent架构、微服务、事件驱动这几种技术的组合。不是追求潮流是因为制造业ERP/MES这摊事信息流转的实时性和异构性都太强了单一的同步调用根本扛不住。2. 制造业ERP/MES的系统拆解哪些模块值得用AI重做2.1 核心域划分先从业务对象开始制造业系统无论叫什么名字业务对象翻来覆去就是那几个物料、BOM物料清单、工艺路线、工单、工序、设备、人员、质检批次、库存、供应商。这些对象在数据库里是表在领域驱动设计里叫聚合根。我第一版设计时没有一上来就分微服务而是先做了领域划分。因为制造业这些域之间的耦合度极高硬拆会很痛。比如一个简单的报工操作要同时影响工单进度、工序在制量、设备运行时长、员工工时、质检验证状态——这五个领域如果拆成五个微服务事务一致性立刻成了大问题。所以我的思路是域内强一致、域间异步化。比如生产域内部工单、工序、报工、质检放同一个服务但生产域与库存域之间通过事件通信而不是同步锁。2.2 AI融进去的位置计划、调度、执行、质检我规划了四个核心切入点。第一个是需求预测与计划排程。传统MRP物料需求计划是基于固定提前期的刚性计算实际现场一大半时间都在应对异常。AI在这里的价值是动态修正提前期——比如某个供应商最近三个月老是延期模型应该自动把这个供应商的物料提前期拉长在爆仓之前就预警。第二个是智能派工调度。这是MES最核心也最难的环节。车间里可能有几十台设备、上百个工单、不同的工序约束传统做法是排程算法跑一个确定性模型。AI在这里不是要替代算法而是要做调度建议根据历史数据推荐最合适的设备、给出瓶颈预警。第三个是工艺参数推荐。比如数控加工不同材质、刀具、机床状态组合下合理的转速进给完全不同。老师傅凭经验AI可以根据历史加工记录给出参考工艺参数。这一块是最能落地出效果的因为见效快、价值直接。第四个是质量异常根因分析。质检不合格后传统系统就是记录一下然后走返工流程但AI可以发现这一批不合格的工件都是夜班2号机床加工的且当天湿度偏高这种隐藏相关性帮助质量工程师快速锁定根因。3. 从零重建的实操路径架构、数据、AI能力落地3.1 技术选型我最终选了什么样的基座我这套系统的技术栈如下不一定是最优解但经过实战验证是稳定的层级选型选型理由核心语言Java 17 Spring Boot 3制造业系统长生命周期Java的人才储备、生态稳定性最好前端Vue 3 TypeScript生态成熟适合复杂的表单和流程交互数据库PostgreSQL数据一致性要求高PG的约束、事务、JSONB都能用上缓存/消息Redis RabbitMQRedis做缓存和分布式锁RMQ做域间事件通信搜索OpenSearch工单检索、日志检索、以及后面向量检索的底座AI集成LangChain4j Ollama(本地部署) OpenAI API小模型本地处理敏感数据大模型做复杂推理数据分析ClickHouseMES里大量时序数据设备参数在线采集列式存储查询快这里有个关键的决策点为什么用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 常见问题速查表整理一份我项目里最常被问到的排查清单问题表现可能原因解决思路AI回答经常答非所问Tool参数定义太复杂信息过载精简Tool来去参数预组装服务端查询条件车间报工延迟高同步调用大模型推理本地部署轻量模型做实时场景大模型降级为异步查询报表越来越慢微服务拆太碎、join跨库按业务生命周期收敛服务必要时做CQRS读写分离Agent经常误解意图领域词汇没有录入到系统给模型配一份制造术语表作为上游Prompt上下文数据不准导致模型效果差老系统垃圾字段太多先跑数据质量巡检人工修数后再训练微调事件消费重复报错消费端没有做幂等处理所有消费者必须基于唯一业务键做幂等5. 这趟重建下来我对AI-native架构的最终理解项目走到现在我对AI-native这件事有了比刚开始清晰得多的判断。它不是什么魔法也不是什么银弹。它更像是一种系统设计的前置觉悟——你在画数据模型的时候就要想到这些数据会作为上下文喂给模型你在定义工具接口的时候就要想到这些接口会被模型调用你在设计权限体系的时候就要想到如何让AI的建议权和人的决定权相互咬合。这套系统目前已经在一家小规模机加工厂跑了大半年核心生产域的报工和质检流程稳定运行AI辅助的排程建议大约每周能帮计划员省出半天的手工计算时间。说实话和那些全自动化黑灯工厂比起来这个成绩不算惊艳但对一个现金流吃紧、设备老旧的中小制造企业来说这是最现实的进步方式。我记得有一次去车间回访计划员老张跟我说了一句话让我觉得这套架构算是成了。他说以前我最烦的就是天天接电话问货期现在这个系统自己会算还会提前提醒我哪几个单危险我只要决定是先保大客户还是先保准时交付就行。这句话点醒了我AI-native的最终目的从来不是让AI面面俱到而是把人的精力从繁琐的计算和排查中解放出来让人专注在真正需要判断力的事情上。架构再怎么花哨到最后好用、能解决问题、人还愿意用才是硬道理。最后再分享一个我个人的小习惯每次迭代新功能我都会去做一次假如AI不存在这个功能还成立吗的自检。如果成立说明AI只是点缀如果不成立说明AI真的进入了链路的核心。我推荐你也试试这个方法它能帮你保持清醒不至于为了AI而AI。这套系统的路还很长预测性维护、供应链协同、跨工厂调度每一块都还有大量提升空间。但第一步既然走通了接下来就靠一步一步踩出来。