制造业的 ERP 和 MES 这两套系统做过的人都知道它们是典型的历史包袱重、定制程度高、数据割裂严重的三高系统。我在工厂信息化这个圈子里摸爬滚打了十来年从最早的 Delphi 单机版 ERP到后来基于若依框架二次开发的 MES再到微服务化改造几乎每一代技术栈都踩过一遍。最近这一年我一直在琢磨一件事如果把 AI 当成系统的一等公民而不是事后挂一个智能助手的壳从零重建一套制造业 ERP/MES架构上到底应该长什么样这篇文章就是我这段时间思考和实践的完整记录包括架构选型的逻辑、核心模块的拆解、实操落地的步骤以及那些只有真正动过手才会知道的坑。不管你是正在做 ERP/MES 的技术负责人还是想了解 AI-native 架构到底怎么落地的开发者相信都能从中拿到一些可以直接抄作业的东西。1. 为什么传统 ERP/MES 架构撑不住 AI 时代的需求1.1 传统架构的三个致命伤先说清楚问题才能讲明白方案。传统 ERP/MES 的架构不管是基于 Oracle ERP 那种重型单体还是基于若依框架快速搭起来的 MES本质上都是表单驱动 流程引擎的模式。这个模式在过去的二十年里没什么大问题因为制造业的核心诉求就是记录准确、流程可控、报表能出。但到了今天这套架构暴露出了三个绕不过去的硬伤。第一个硬伤是数据模型僵化。传统 ERP 的表结构是围绕单据设计的——采购单、销售单、工单、领料单每张单据的字段在开发阶段就定死了。你想加一个根据历史数据预测的物料损耗率字段对不起得改表、改代码、改报表一套流程走下来两周起步。而 AI 模型需要的是灵活的特征输入它不关心你的单据长什么样它关心的是这个工单在当前设备状态、当前人员排班、当前物料批次下预计良率是多少。这种需求在传统表结构里根本无处安放。第二个硬伤是决策逻辑硬编码。传统 MES 里的排产逻辑、质量判定逻辑、异常处理逻辑全都是 if-else 写死的。比如当检测值超过上限时触发报警这个阈值是工程师拍脑袋定的定完之后就再也没变过。但实际上不同批次物料、不同设备磨损状态下的合理阈值应该是动态变化的。AI-native 的思路是让模型从历史数据里学出这个阈值而不是靠人拍脑袋。第三个硬伤是系统间数据割裂。ERP 管财务和供应链MES 管生产执行QMS 管质量WMS 管仓库每个系统一套数据库靠接口同步。同步延迟、数据不一致、对账困难这些问题在传统架构里是常态。AI 模型要做出准确预测需要的是跨系统的全量数据视图而不是通过接口拼凑出来的碎片。1.2 AI-native 到底native在哪里很多人把AI-native理解成用了 AI 的系统这个理解太浅了。我理解的 AI-native核心是三条数据模型为 AI 设计、决策逻辑由模型驱动、系统架构支持模型全生命周期管理。数据模型为 AI 设计意味着表结构不能只考虑业务单据还要考虑特征存储。比如工单表里除了常规字段还要有特征向量字段或者单独建一张特征表把设备状态、环境参数、人员技能等维度都结构化存储。决策逻辑由模型驱动意味着排产、质检、预警这些环节不再是写死的规则而是调用模型推理服务模型输出结果后再由业务逻辑做兜底。系统架构支持模型全生命周期管理意味着要有模型训练、版本管理、A/B 测试、灰度发布、效果监控这一整套基础设施。这三条听起来简单但落地的时候会发现它要求整个系统的分层方式、数据流向、部署模式都要重新设计。这也是为什么我说从零重建比在现有系统上改造更靠谱——改造的话你永远在跟历史包袱做斗争。1.3 重建 vs 改造一个务实的判断当然从零重建的成本是巨大的。我在决定重建之前认真评估过改造方案。改造的核心思路是在现有系统旁边挂一个AI 中台通过数据同步把业务数据抽到中台在中台里做模型训练和推理再把结果写回业务系统。这个方案的问题是数据同步有延迟模型拿到的永远是过去时的数据写回结果又要走一遍业务校验链路太长而且业务系统的表结构不支持特征存储很多有价值的原始数据在录入阶段就丢失了。所以我的判断是如果企业规模不大业务逻辑相对标准改造方案可以接受但如果是要做一套支撑未来五到十年发展的核心系统而且 AI 应用是战略级的那从零重建更划算。重建的关键是先把架构设计对再动手写代码否则重建出来的东西过两年又变成新的历史包袱。2. AI-native 制造业 ERP/MES 的整体架构设计2.1 分层架构从五层到四层 一个平面传统企业级架构一般分五层表现层、应用层、服务层、数据层、基础设施层。我在设计这套系统的时候把它改成了四层 一个平面交互层、智能决策层、业务服务层、数据层加上一个贯穿所有层的 AI 基础设施平面。为什么这么分因为 AI-native 系统里模型推理不是一个独立的服务而是渗透在每一层的。交互层需要自然语言理解业务服务层需要智能排产数据层需要向量检索这些都需要 AI 基础设施的支撑。如果按传统五层分AI 能力会被割裂到各个层里没法统一管理。AI 基础设施平面包含的东西很多特征存储、模型仓库、推理服务、向量数据库、模型监控、实验管理。这些东西不是某一层专属的而是所有层都可以调用的公共能力。这个设计思路借鉴了微服务架构里服务网格的概念——把横切关注点抽出来做成一个独立的平面。2.2 核心模块划分与职责边界模块划分上我把它分成了六大核心模块主数据管理、供应链协同、生产执行、质量管理、设备管理、经营分析。每个模块的职责边界要划清楚否则又会变成传统 ERP 那种什么都在一个模块里的混乱局面。主数据管理负责物料、BOM、工艺路线、供应商、客户这些基础数据的维护。这个模块的特殊之处在于它要为 AI 模型提供标准化的特征源。比如物料主数据里除了常规属性还要有物料的物理特性、历史质量表现、供应商交付表现等特征字段。供应链协同负责采购、销售、库存、物流。这个模块的 AI 应用场景主要是需求预测、库存优化、供应商风险评估。生产执行负责工单、排产、报工、追溯。AI 应用场景是智能排产、异常预警、良率预测。质量管理负责检验、SPC、不合格品处理。AI 应用场景是缺陷检测、质量预测、根因分析。设备管理负责设备台账、点检、维修。AI 应用场景是预测性维护、故障诊断。经营分析负责报表、看板、决策支持。AI 应用场景是自然语言查询、智能归因。2.3 技术选型为什么选这些而不是那些技术选型这块我纠结了很久。后端语言上Java 和 Python 之间我最终选了Java 做业务服务 Python 做 AI 服务的混合方案。Java 生态在企业级应用上成熟度更高事务管理、权限控制、分布式协调这些都有现成的轮子Python 在 AI 生态上是绝对优势PyTorch、scikit-learn、pandas 这些库没法替代。两者之间通过 gRPC 通信性能比 REST 好而且支持流式传输。数据库选型上我用了PostgreSQL TimescaleDB Milvus的组合。PostgreSQL 做业务数据的主库它的 JSONB 类型对半结构化数据支持很好适合存特征。TimescaleDB 是 PostgreSQL 的时序扩展用来存设备传感器数据、生产节拍数据这些时序数据。Milvus 做向量检索用来支持相似案例检索、语义搜索这些场景。消息队列用了 Kafka主要是看中它的吞吐量和持久化能力。制造业现场的数据量很大一个中型工厂一天产生的传感器数据可能就有几个 GBKafka 扛得住。缓存用了 Redis这个没什么好说的标配。前端框架选了 React TypeScriptUI 库用了 Ant Design。这个组合在制造业管理系统里很常见组件丰富开发效率高。移动端用了 React Native一套代码同时支持 Android 和 iOS工厂现场用平板和手机的场景越来越多这个投入是值得的。3. 数据层设计让数据为 AI 服务3.1 业务数据与特征数据的分离存储数据层设计是整套系统的地基这块如果设计错了后面全是坑。我的核心思路是业务数据和特征数据分离存储。业务数据就是传统的单据数据存在 PostgreSQL 里保证 ACID。特征数据是从业务数据里抽取出来的、面向模型训练和推理的数据存在专门的特征存储里。为什么要分离因为两者的访问模式完全不同。业务数据的访问是按单据 ID 查单条记录特征是按时间窗口批量拉取某个实体的所有特征。如果混在一起存查询性能会互相影响。而且特征数据需要频繁地做批量计算和更新业务数据则要求强一致性两者的运维策略也不一样。特征存储我选的是 Feast 这个开源框架它支持离线存储和在线存储两套。离线存储用 Parquet 文件存在对象存储上用于模型训练在线存储用 Redis用于推理时的实时特征读取。Feast 的好处是它把特征定义、特征计算、特征服务这三件事统一管理起来了避免了训练时用的特征和推理时用的特征不一致这个经典问题。3.2 时序数据的处理策略制造业现场最不缺的就是时序数据。设备传感器每秒上报一次温度、压力、振动一条产线几十台设备一天下来就是几千万条记录。这些数据的处理策略直接决定了系统能不能扛住。我的方案是三级存储热数据存 TimescaleDB保留最近 7 天支持实时查询温数据存对象存储的 Parquet 文件保留最近 1 年支持批量分析冷数据归档到低成本存储保留 3 年以上只在需要时拉取。TimescaleDB 的使用有几个关键点。第一是分区策略我按设备 ID 做哈希分区按时间做范围分区这样查询单台设备的历史数据时只需要扫描一个分区。第二是压缩策略超过 7 天的数据自动压缩压缩率能到 10 倍以上。第三是连续聚合把原始数据按分钟、小时、天做预聚合查询聚合指标时直接查聚合表不用扫原始数据。注意TimescaleDB 的压缩是不可逆的压缩前一定要确认数据已经不需要做细粒度的更新操作。我踩过一次坑压缩之后发现有个字段的解析逻辑写错了想改都改不了只能重新导入。3.3 向量数据库的引入与使用场景向量数据库是 AI-native 架构里比较新的东西很多人不清楚它到底用来干什么。在我的设计里Milvus 主要承担三个场景相似案例检索、语义搜索、推荐。相似案例检索是质量管理和设备管理里的刚需。比如某个工单出现了质量问题工程师想知道历史上有没有类似的案例当时是怎么解决的。传统做法是按关键词搜但关键词搜不准。用向量检索把每个历史案例的文本描述、工艺参数、设备状态都编码成向量查询时把当前问题也编码成向量算余弦相似度就能找到真正相似的案例。语义搜索用在知识库和文档管理上。工厂里有大量的作业指导书、设备手册、工艺文件传统搜索只能按文件名或标签搜用向量检索可以做到用自然语言描述你要找什么系统帮你找出来。推荐用在两个地方一是给操作工推荐最优的工艺参数二是给采购推荐替代供应商。这两个场景本质上都是根据历史数据找最相似的场景然后推荐当时的最优选择。Milvus 的部署我选的是单机版因为制造业的数据量还没到需要分布式集群的程度。索引类型用了 HNSW查询速度快召回率也够用。向量维度是 768用的是开源的文本编码模型具体哪个模型可以根据实际效果调。4. 智能决策层模型怎么嵌入业务流程4.1 模型服务化的三种模式模型要嵌入业务流程有三种模式同步调用、异步调用、批量计算。这三种模式适用的场景完全不同选错了会严重影响系统性能。同步调用适合实时性要求高、模型推理快的场景比如质量判定。工单报工时系统需要立刻判断这个产品是合格还是不合格这时候就同步调用质量预测模型模型在 100 毫秒内返回结果业务逻辑根据结果决定下一步操作。同步调用的关键是超时兜底模型服务如果挂了或者超时了业务逻辑必须有降级方案不能因为模型不可用导致产线停线。异步调用适合实时性要求不高、模型推理慢的场景比如排产优化。排产是一个复杂的组合优化问题模型可能需要几秒钟甚至几分钟才能算出结果。这种场景下业务系统提交排产请求后不等待结果而是通过消息队列异步通知。模型算完后把结果写回数据库前端轮询或者通过 WebSocket 推送。批量计算适合周期性执行、数据量大的场景比如需求预测。每天晚上跑一次把未来一个月的需求预测算出来存到数据库里供第二天使用。批量计算用 Spark 或者 Python 脚本都可以关键是任务调度和失败重试要做好。4.2 排产模型的落地实践排产是 MES 里最核心也最复杂的模块我在这块花的时间最多。传统排产靠人工经验或者简单的规则引擎AI-native 的排产要综合考虑交期、产能、物料、人员、设备状态等多个约束目标函数可以是最小化总延迟或者最大化设备利用率。我的实现方案是**规则引擎 强化学习的混合架构**。规则引擎负责处理硬约束比如某台设备今天必须停机保养、某个订单必须优先生产这些是绝对不能违反的。强化学习模型负责在满足硬约束的前提下优化软目标比如尽量减少换型次数、尽量均衡各设备负载。强化学习模型的训练环境是自己搭的仿真器把历史工单数据、设备状态数据、工艺参数数据都灌进去让模型在仿真环境里反复试错。训练好的模型部署成推理服务排产时调用。这里有个关键点模型输出的排产方案必须经过规则引擎校验确保不违反硬约束。我见过有团队直接拿模型输出就用结果排出来的计划违反了安全规程这是绝对不能接受的。排产效果的评估指标我用了三个订单准时交付率、设备平均利用率、平均换型次数。上线后对比人工排产准时交付率提升了 8 个百分点设备利用率提升了 5 个百分点换型次数减少了 15%。这个提升幅度不算惊艳但考虑到制造业的基数大换算成经济效益是很可观的。4.3 质量预测与根因分析质量预测是另一个核心场景。传统 MES 的质量管理是事后检验产品做完了再检不合格就返工或报废。AI-native 的质量管理要做到事前预测、事中控制。事前预测是在工单开始前根据物料批次、设备状态、工艺参数、人员技能等特征预测这个工单的良率。如果预测良率低于阈值系统会提前预警让工程师介入调整。事中控制是在生产过程中实时监控关键参数一旦发现偏离正常范围立刻调整或者停机。根因分析是质量管理的难点。产品出现缺陷后要找出是哪个环节、哪个参数导致的。传统做法是靠工程师经验一个个排查。AI 的做法是用因果推断模型从历史数据里学出哪些参数的异常会导致缺陷。这里要注意相关性不等于因果性直接用相关性分析会得出很多误导性的结论。我用的是 DoWhy 这个因果推断框架它能区分相关关系和因果关系给出的根因更可靠。5. 业务服务层的微服务拆分与治理5.1 服务拆分的粒度怎么把握微服务拆分最怕两件事拆得太细服务间调用复杂运维成本高拆得太粗又变成了分布式单体。我的经验是按业务能力拆分而不是按技术分层拆分。具体来说我拆了这些服务主数据服务、采购服务、销售服务、库存服务、工单服务、排产服务、报工服务、质量服务、设备服务、报表服务。每个服务对应一个业务能力有自己的数据库通过 API 对外暴露能力。拆分的粒度判断标准是如果一个功能的变化频率和另一个功能差异很大就应该拆开。比如排产逻辑经常调整而库存管理相对稳定这两个就应该拆成独立服务。反过来如果两个功能总是一起变化那就不应该拆开否则每次改动都要同时发布两个服务反而麻烦。5.2 服务间通信与数据一致性服务拆开之后数据一致性就成了大问题。传统单体应用里一个事务能搞定的事拆成微服务后就要用分布式事务。我的原则是尽量避免跨服务的事务如果避免不了用最终一致性而不是强一致性。具体做法是核心业务操作只在一个服务内完成跨服务的操作通过事件驱动的方式异步处理。比如报工服务完成报工后发一个工单已完成的事件到 Kafka库存服务消费这个事件后扣减库存质量服务消费后触发检验任务。这样每个服务只关心自己的事务通过事件来协调。这里的关键是事件要可靠投递。我用的是 Kafka 的事务生产者保证事件发送和本地事务的原子性。消费端用幂等消费防止重复处理。这套机制搭起来有点复杂但一旦搭好后面加新服务就很方便了。5.3 服务治理限流、熔断、降级微服务架构下一个服务挂了可能引发雪崩。服务治理是必须做的我用的是 Sentinel 做限流和熔断用 Nacos 做服务注册和配置管理。限流策略上我按服务的重要程度分了三级。核心服务比如报工、质量判定限流阈值设得很高保证产线不停非核心服务比如报表、分析限流阈值设得低一些高峰期可以降级。熔断策略上我设置了慢调用比例和异常比例两个指标任何一个超过阈值就熔断熔断后走降级逻辑。降级逻辑要提前设计好。比如排产服务不可用时降级到按交期先后顺序排产的简单规则质量预测服务不可用时降级到按固定阈值判定。降级不是失败而是用次优方案保证业务继续。6. 实操落地从零搭建的关键步骤6.1 环境准备与基础设施搭建动手之前先把基础设施搭好。我用的是 Docker Compose 做本地开发环境Kubernetes 做生产环境。本地环境包含 PostgreSQL、TimescaleDB、Milvus、Redis、Kafka、Nacos 这些组件用 Docker Compose 一键启动。生产环境的 Kubernetes 集群我建议至少三个节点每个节点 16 核 64G 起步。制造业的数据量和计算量都不小配置太低跑不动。存储用 NFS 或者 Ceph数据库用云厂商的托管服务更省心如果自建的话要做好备份和容灾。部署顺序上先部署基础设施数据库、消息队列、注册中心再部署 AI 基础设施特征存储、模型仓库、推理服务最后部署业务服务。每部署一层都要做健康检查确保下层可用后再部署上层。6.2 核心服务的开发与调试开发顺序上我建议先做主数据服务和工单服务这两个是其他服务的基础。主数据服务提供物料、BOM、工艺路线这些基础数据工单服务提供生产任务的管理。这两个服务跑通了其他服务才有数据可用。调试的时候我强烈建议先写集成测试再写单元测试。微服务架构下单个服务的逻辑往往很简单复杂的是服务间的交互。集成测试用 Testcontainers 启动真实的依赖组件能发现很多单元测试发现不了的问题。接口调试用 Postman 或者 Apifox把常用接口做成集合方便回归测试。日志用 ELK 收集每个服务打日志时带上 traceId方便追踪一个请求跨多个服务的完整链路。6.3 模型训练与部署的工程化模型训练不是跑个 notebook 就完事了要工程化。我用的是 MLflow 做实验管理和模型注册用 Airflow 做训练任务调度用 ONNX Runtime 做推理加速。训练流程是这样的Airflow 定时触发训练任务任务从特征存储拉取训练数据用 PyTorch 训练模型训练完成后把模型和指标记录到 MLflow如果指标超过当前生产模型就注册为新版本。部署时推理服务从 MLflow 拉取指定版本的模型加载到内存中提供服务。模型更新要灰度发布。新模型上线后先切 10% 的流量观察一周指标没问题再逐步扩大。如果指标下降立刻回滚到旧版本。这套机制听起来简单但真正做起来模型版本管理、流量切换、指标监控这些都要有配套工具不然全靠人工操作迟早出问题。7. 常见问题与排查技巧实录7.1 数据一致性问题的排查微服务架构下数据不一致是最常见的问题。我遇到过一个典型案例报工服务显示工单已完成但库存服务显示物料还没扣减。排查下来发现是 Kafka 消息积压库存服务的消费速度跟不上生产速度。排查这类问题的思路是先看消息队列的积压情况再看消费端的处理日志最后看数据库的实际状态。如果消息积压要么是消费端处理太慢要么是消费端挂了。处理太慢的话可以增加消费者实例或者优化消费逻辑。消费端挂了的话看日志找原因重启后要注意幂等处理防止重复消费。预防这类问题的办法是做好监控和告警。Kafka 的 lag 超过阈值就告警消费失败的消息进死信队列人工介入处理。数据库层面定期做对账发现不一致及时修复。7.2 模型推理性能优化模型推理慢是另一个常见问题。我遇到过一个质量预测模型单次推理要 500 毫秒产线根本等不了。优化下来发现瓶颈在特征读取上每次推理都要从 Redis 拉几十个特征网络往返时间占了大头。优化方案是批量读取特征 本地缓存。把同一个工单需要的所有特征一次性拉取减少网络往返。对于变化不频繁的特征缓存在推理服务本地设置合理的过期时间。优化后单次推理降到了 50 毫秒以内。另一个优化方向是模型量化。把 FP32 的模型量化成 INT8推理速度能提升 2 到 4 倍精度损失通常在 1% 以内。用 ONNX Runtime 做量化很方便几行代码就能搞定。但要注意量化后的模型要重新做精度验证确保业务指标没有明显下降。7.3 常见问题速查表问题现象可能原因排查方法解决方案服务间调用超时网络问题、下游服务慢、线程池满看链路追踪、看下游服务指标加超时、加熔断、扩容数据不一致消息丢失、消费失败、并发冲突看消息队列 lag、看消费日志幂等消费、对账修复、加锁模型推理慢特征读取慢、模型太大、并发高看推理耗时分布、看资源使用批量读取、模型量化、扩容排产结果不合理约束没配全、模型训练不足看约束配置、看模型指标补约束、重新训练、加规则校验数据库慢查询索引缺失、数据量大、锁竞争看慢查询日志、看执行计划加索引、分区、读写分离提示这张表是我从实际运维中总结出来的覆盖了 80% 的常见问题。遇到新问题时先对照这张表排查能省不少时间。8. 我在这套架构上踩过的坑与经验总结8.1 不要过早引入 AI这是我踩过的最大的坑。项目刚开始的时候我雄心勃勃想把所有环节都 AI 化结果发现很多场景根本不需要 AI。比如物料编码的生成用规则就能搞定非要上模型纯属给自己找麻烦。我的经验是先用规则跑通业务再逐步用 AI 替换规则。规则的好处是透明、可控、好调试业务跑通之后你才知道哪些环节是真正的瓶颈哪些环节 AI 能带来最大价值。一上来就全 AI往往是既没跑通业务也没做好 AI。8.2 数据质量比模型算法重要另一个深刻的体会是数据质量决定了 AI 效果的上限。我见过太多团队模型换了一个又一个效果就是上不去最后发现是数据的问题。制造业的数据质量普遍不高传感器数据有噪声人工录入的数据有错误历史数据有缺失。解决数据质量问题没有捷径就是老老实实做数据治理。建立数据标准做数据清洗补全缺失值剔除异常值。这个过程很枯燥但省不得。我的做法是在数据层加一个数据质量监控模块实时监控关键数据的完整性、准确性、及时性发现问题及时告警。8.3 组织变革比技术变革更难最后说一个非技术的问题。AI-native 系统上线后最大的阻力往往不是技术而是人。操作工习惯了按按钮你让他看 AI 推荐的参数他不信任工程师习惯了拍脑袋定阈值你让他看模型算出来的阈值他觉得不靠谱。解决这个问题关键是让 AI 的结果可解释、可干预。模型给出推荐时要同时给出推荐的理由比如推荐这个参数是因为历史上类似工况下这个参数的良率最高。同时要允许人工覆盖 AI 的决策并且把人工覆盖的数据收集起来用于后续的模型优化。这样既尊重了人的经验又让模型能持续学习。这套系统从设计到上线前后花了我将近一年的时间。中间经历过推倒重来也经历过上线后回滚。但回头看这套架构的方向是对的AI-native 不是噱头而是制造业系统演进的必然趋势。如果你也在做类似的事情我的建议是架构设计要激进落地实施要保守。架构上要敢于为 AI 留出空间实施上要一步一步来先把基础打牢再逐步叠加 AI 能力。