从零重建制造业ERP/MES：AI-native架构的设计与落地

我一直觉得制造业软件是信息化领域里最难啃的骨头。ERP/MES这些系统数据量不算特别大技术上也不追求什么极限性能但它的难点在于业务场景太复杂、现场变量太多、组织边界太模糊。传统架构下我们花了大量时间在适配人和流程上而不是解决真正的问题。所以当AI-native这个概念出来的时候我有一个很强烈的直觉——这套沿用了几十年的软件架构到了该换一换底层逻辑的时候了。这篇文章不是给你讲概念是想认真分享一下如果我要从零开始用AI-native的思路重建一套制造业ERP/MES我会怎么搭、怎么拆、怎么落地以及这一路上可能遇到的真实麻烦。1. 为什么要动这个念头传统ERP/MES的痛点已经不只是“难用”这么简单1.1 信息孤岛永远建不完数据永远对不齐做过制造信息化的人都知道一个词叫“集成”。ERP里建一张生产订单要同步到MESMES报完工了要回传到ERP设备数据要传到SCADASCADA再往上一层做分析。听起来数据是通的可实际做起来每个系统的字段规则不一样编码规则不一样对“完工”的定义也不一样接口联调周期按周算。我在车间里见过最典型的一幕生产报表的统计员每天上午要花一个半小时把MES导出的Excel和ERP导出的Excel手工合在一起再核对一遍才能给领导出昨天的产量数据。企业买了ERP、MES、APS、QMS结果所有人最信任的还是Excel。这不是软件不行而是架构的假设出了问题——传统架构把每个系统当成独立的自治王国靠接口去对齐而不是把数据当成统一底座来设计。AI-native架构的一个核心思路恰恰是先统一数据语义层再谈业务功能。1.2 业务规则是写死的现场变化全靠人扛MES里最核心的一个功能是工序流转工单下发到产线按工艺路线一步步走报工、质检、入库。听起来很标准但实际车间里每天都会出现各种“例外”设备临时故障要跳工序、客户紧急插单要压缩交期、物料晚到要调整排产顺序、现场加工发现工艺参数不合适要临时改工艺。传统MES怎么做提前把规则写进流程里遇到规则覆盖不了的情况就只能人机交互——找IT部门改配置、调逻辑。改一次要审批、要测试、要发布等改完了产线又变了。我见过最夸张的一次一家电子装配厂的MES工序配置一年改了三百多次每一次都是“打补丁式”修改。到最后没人说得清系统里哪些规则是生效的哪些已经被覆盖掉了。1.3 系统里的数据变成了“僵尸资产”决策还是靠人拍脑袋很多制造企业上了ERP/MES之后积累了大量数据报工记录、质检数据、设备参数、物料消耗。但是这些数据在传统架构下是分散的、静态的基本只用来出月报季报。真正遇到生产异常的时候车间主任还是靠经验判断品质经理还是开评审会拍板。为什么数据不能用起来因为传统架构把数据加工和业务决策完全割裂了——数据分析是BI的活儿业务决策是ERP/MES的活儿AI模型开发又是另一个团队的事。数据流转的链条断掉了智能就无从谈起。2. AI-native到底意味着什么先把这个词掰开揉碎在展开架构设计之前我觉得有必要先聊聊AI-native这个词到底指什么。很多人以为系统里接入一个API调用、能自动生成报表就是AI-native那是“AI增强”不是AI-native。2.1 不是调用式AI而是AI成为系统的第一公民传统的做法是系统里先有业务流程、数据库、功能模块然后再在外面包一层AI能力比如做个智能问答、做个预测模型。这种方式的本质是“系统有了AI外挂”。真正AI-native的架构是把AI能力当作基础设施像数据库、消息队列一样内嵌在系统的每一层里。业务规则可以由AI实时生成和修正异常处理可以由AIAgent主动介入数据流动本身由AI驱动完成而不是靠人写死的流程脚本触发。举个例子传统MES里“工单逾期预警”是一个定时任务每天上午9点扫一次数据库把超期的工单列出来推给计划员。AI-native的系统里“逾期预警”不是定时任务而是一个Agent持续感知生产进度结合实时设备状态、物料齐套情况、历史同期产能主动判断哪些工单存在逾期风险不但列出清单还能给出干预建议。2.2 智能体不是“聊天机器人”而是业务流程的执行者AI-native架构里Agent是真正干活的角色。它调用工具、查数据库、发指令、触发流程、与人协作全程自主完成。这需要系统为Agent提供完整的工具链和安全边界。我举一个工业场景生产调度。传统排产靠APS引擎跑算法或者计划员在Excel里人工排。AI-native的调度Agent可以做到感知订单变更、读取当前产线负荷、查询物料齐套率、模拟多套排产方案并评估风险最后把建议方案推给计划员确认确认后直接更新排产结果。整个过程Agent不是被动响应指令而是在持续运行、主动发现问题、推进闭环。2.3 判断一个系统是不是AI-native就看这三点我自己总结了一套判断标准不复杂第一个标准数据是不是活的AI是不是能实时取数、立刻反馈传统系统跑批分析要滞后一天AI-native系统要求秒级响应。第二个标准业务规则是不是可演化的传统系统改规则靠代码发布AI-native系统让规则通过模型推理动态生成人的角色变成审核和干预。第三个标准交互是不是自然语言优先的使用者可以直接用日常语言提问、下达指令系统理解意图并调用对应能力。按这三个标准去衡量市面上绝大多数号称AI制造应用的产品其实都达不到AI-native的阶段。真正能做到的都在架构层面做了彻底的重新设计。3. 从零重建的核心骨架领域模型、事件驱动和统一语言既然决定从零开始就得先搭地基。AI-native架构并不是要抛弃过去所有的软件工程积累恰恰相反它非常依赖一套清晰的领域模型和边界划分——因为AI再聪明也得知道业务上下文是什么。3.1 数据模型怎么定主数据、业务过程、事件流三层分开我设计的第一版数据模型把所有制造数据分成三层第一层是主数据层包括物料主档、BOM、工艺路线、设备台账、供应商/客户档案。这一层是“静态事实”变化频率低是所有业务推算的基石。值得强调的是主数据的治理在AI时代更重要了——模型推理所依赖的特征全部来自这一层如果主数据是脏的再强的智能也白搭。第二层是业务过程层包括工单、工序任务、报工记录、质检单、领料单、入库单。这一层是“动态业务”覆盖制造过程的全生命周期。传统MES在这一层只有“状态流转”而AI-native会让每个业务对象附带完整的上下文向量——比如这张工单的物料来源、设备历史故障率、客户催货优先级这些上下文让Agent能准确判断该怎么处理。第三层是事件流层包括设备实时数据、传感器数据、操作日志、系统交互记录。事件流不只为报表服务它会被持续地分析和消费驱动实时决策。没有事件流所有的智能都只是“事后诸葛亮”。3.2 业务域怎么拆按“能力”而非“部门”划分微服务传统ERP/MES拆微服务常常按部门来采购一摊、生产一摊、库存一摊、质检一摊。表面上边界清晰实际上业务流转要跨好几个服务一次报价到出货的链路要经过六七个系统的接口。AI-native架构下我建议按“业务能力域”来切分每个域自带完整的数据和行为边界订单履约域从客户下单到交付的全链路包含销售、计划、发运。生产执行域从工单下达到完工入库包含排产、派工、报工、工序流转。质量管控域从来料检验到过程检验到出货检验包含缺陷管理、不良处理、追溯。物料供应域从需求计算到采购入库到齐套核验包含供应商协同和库存管理。资源保障域设备维保、刀具管理、模具管理、能耗管理核心是让生产资源处于可用状态。每个域之间有明确的领域事件交互。比如生产执行域发出“物料需求”事件物料供应域接收到事件后自动触发齐套检查和采购申请。域与域之间不直接调用彼此的数据库AI编排层统一调度。3.3 AI编排层的两面读侧补全和写侧受控这是我最核心的设计思路。整个系统的AI编排层分成两个方向读侧叫补全就是从现有数据中补齐决策所需的上下文。比如一个计划员问“为什么3号产线的这个工单延期了”AI读取工单流转历史、设备报警记录、物料到场记录用自然语言总结出延期的完整原因链而不是简单抛出一个状态“已延期”。写侧叫受控就是AIAgent可以产生业务动作但必须经过控制策略。控制策略分三层第一层是规则校验比如发料的仓库、数量必须符合工单要求第二层是人工确认高风险操作必须由有权限的人点击确认第三层是审计留痕每个AI动作都有完整的操作日志和决策理由出问题可以回溯。坦白说写侧的“受控”设计决定了这套系统能不能在企业里真正落地。车间主任可以接受AI给出建议但不会接受AI在不打招呼的情况下直接修改工艺参数。AI-native不是要取代人的判断而是要把人从重复劳动里解放出来去做更高层级的决策。4. 让Agent真正落地制造现场需要的几类AI角色如果架构搭好了Agent就是这栋楼里干活的“员工”。我梳理了制造业ERP/MES里最值得优先落地的几类智能体每一类对应的技术难点和业务价值都不一样。4.1 生产调度Agent把“经验排产”变成“推演排产”排产是制造管理最复杂的工作之一。要满足交期、要考虑产能、要分配物料、要平衡设备还要处理随时出现的异常插单。调度Agent的核心能力是“快速推演”接收到订单变更后同时考虑当前所有产线的并行情况快速演算未来一周的产能负荷曲线找出瓶颈工序给出多套可选的插单方案每套方案附带风险评级——比如插单会影响哪些已有订单的交期、需要哪些物料、预计何时能够消化。这里有一个容易被忽略的问题传统APS排产引擎已经能做到线性规划优化为什么还要用Agent因为APS只解决“排得好不好”不解决“排不出来怎么办”和“客户等不了怎么办”。Agent能理解上下文在无解的情况下灵活变通同时把变通方案的风险讲清楚这是传统优化引擎做不到的。人机协同也很关键。我认为调度Agent不应该自动发布排产结果而应该先提交方案给计划员做一次“模拟验收”计划员可以修改参数反复演算确认后再发布。这种“人定界、机优化”的模式在实际推行时阻力最小。4.2 质量判定Agent从“依赖质检员经验”到“依赖标准化智能”质量判定是制造业里经验沉淀最多的环节。一个缺陷属于可接受还是不可接受很多时候取决于客户要求、产品批次、后续工序的返工能力——这些上下文质检员脑子里有系统里没有。质量判定Agent的设计思路是把质量检验标准、历史缺陷样本、客户反馈记录、工艺参数全部纳入上下文收到质检数据后自动判定缺陷等级和处理建议。比如某个注塑件的表面有轻微熔接线单看缺陷图谱可能判定为“OK”但Agent结合这个产品是出口汽车件、客户对表面质量要求极高就会给出“转人工评审”的建议并附带同批次产品的同类缺陷统计。这套能力不需要一步到位可以从“辅助质检员”开始起步——Agent给出判定建议质检员确认系统记录每个人的判定倾向并持续校正模型。做上两三个月的沉淀之后Agent的判定准确率就能非常可观。4.3 设备诊断Agent让预测性维护真正跑起来设备维护是传统MES里的一个边缘模块大多数企业还是“坏了再修”或者“定期保养”。真正让设备管理智能化的关键是打通“实时数据—故障预判—维护动作”这条链路。设备诊断Agent持续接收设备实时数据比对正常工况基线识别异常趋势。一旦发现潜在故障Agent会读取设备的历史维修记录、备件库存、同类设备故障特征生成诊断报告和维护建议再结合生产计划给出“最佳维护窗口”——比如建议下周二上午9点到12点做保养因为那段时间该产线订单最少。这里面最难的不是算法建模而是如何把设备信号知识沉淀成结构化知识库。不同品牌设备的传感器点位、报警码、参数含义都不同。我建议用三层知识结构来管理设备说明书层、历史维修案例层、实时运行特征层每一层都标注好置信度Agent做推理时分层引用。4.4 自然语言交互把ERP/MES从“录入系统”变成“对话系统”传统ERP/MES的交互逻辑是“人适应表单”——会用的人效率很高不会用的人一年半载都摸不清流程。AI-native的最大改变是把系统变成“对话任务”双通道。一方面一线工人可以对着系统直接说“帮我把这70件产品从工序20报到工序30”系统自动解析身份、工单、数量、工艺路线生成报工单让人确认另一方面管理者可以问“二季度哪个型号的毛利率最低”系统自动跨数据域聚合给出可解释的答案并标注数据来源。这里要提醒一点自然语言交互的“入口”并不一定是语音对话。我实际做下来在噪音很大的车间里语音识别效果很不稳定反而是“对话式的表单交互”——界面保持表单形态但每个字段都支持自然语言填表或者由AI自动根据上下文预填这种方式更可靠工人的接受度也更高。可以叫它“静默AI交互”这才是制造业场景里最务实的落地方式。5. 实时数据链路从PLC到LLM的每一跳都不能断AI-native的制造系统里数据链路是生命线。大模型再聪明如果喂给它的数据是昨天还没更新的那它就是“聪明的瞎子”。这条链路我从底往上分成五段每一段的选型和设计都有坑。5.1 边缘采集层协议碎片化是第一个拦路虎设备数据的采集是制造业里最碎、最烦的事情。西门子走S7协议三菱走Melsec发那科走FOCAS施耐德走Modbus还有一堆老设备连网口都没有得靠PLC加装采集模块。我的经验是不要自己开发协议驱动除非团队有十几年工控背景。更务实的方案是用成熟的边缘网关支持主流协议解析和断点续传在一台边缘设备上做协议转换、数据清洗、本地缓存然后再上传到中心。在边缘侧必须解决的一个问题是时区对齐。不同设备的时间可能相差几分钟导致历史数据排序错乱。我建议在采集网关里统一做时间戳校正以网关时间为基准设备时间偏差记录下来之后补偿不然到了做时序分析那一步会非常痛苦。5.2 流式处理层事件驱动与状态推导设备数据传到中心后不能直接落库就完事了必须经过流式处理层做实时状态推导。什么是状态推导原始数据是“主轴转速4500转每分钟进给速度800毫米每分钟”这些都是测量值系统需要把它们推导成业务状态“2号机床当前处于高速切削状态良品率预期较高”。这里我用的是“流式计算引擎在线推导状态机”的思路每台设备定义成一组状态机事件触发状态迁移状态变化再上抛到业务层。这样做的好处是AIAgent拿到的不是海量原始点位而是带有语义的状态事件推理成本大大降低。流式处理层的技术选型建议重点关注两个能力一是背压处理能力设备数据在订单高峰时会瞬时暴涨不能因为数据尖峰导致链路阻塞二是状态持久化能力流式结果必须幂等落库保证重启后状态能恢复不然一次宕机整条产线的状态就全乱了。5.3 特征服务层给大模型喂“压缩饼干”而非“原始面粉”大模型不擅长直接消费海量原始日志。一个大模型如果直接把每台设备每分钟十条原始数据都塞进上下文不到十分钟就超过模型上下文窗口了。所以在数据链路里必须加一层特征服务层。特征服务层负责把原始数据加工成模型能直接使用的语义化特征。比如一台注塑机的原始数据是模温、注塑压力、保压时间、冷却时间特征服务层加工后输出的是“当前批次合格率为94%模温波动比历史均值偏高3摄氏度与上一批不合格批次的开局特征相似度较高”。特征的时效性也很重要。预测类特征可能需要历史一年的数据做训练但实时决策特征只能取最近几分钟的数据。所以特征服务层要做冷热分离热特征实时计算冷特征离线预聚合推理时合并取用。5.4 推理与动作反馈层模型代理与工具调用链路的最上层就是AI模型与业务系统交互的地方。我的设计里大模型不直接读库而是通过“模型代理”间接查数据、执行动作。模型代理本质上是一层API服务把业务能力封装成模型可调用的“工具”每个工具都有清晰的入参、出参、权限和审计日志。比如调度Agent要查“当前所有执行中工单的剩余数量”模型代理提供工具get_running_order_progress要发起一次转工序审批模型代理提供工具submit_transfer_request。每一项工具的调用都记录到审计系统作为AI动作的“黑匣子”。模型代理还必须做一件事请求合并与限流。多个Agent并发时报同一个特征、查同一张表不能每次都去数据库刷一遍要有一层缓存同时做好令牌桶限流防止大模型恶意调用把核心业务库打挂。6. 想踩的坑和真正能落地的路径从零重建ERP/MES技术方案说再多真正推进的时候都是坑连着坑。我把实践中踩过比较多的问题梳理了一下也写一下我认为务实的实施路线。6.1 AI幻觉在工业场景里的危害是被低估的AI幻觉在通用办公场景里最多让人哭笑不得在制造现场可能直接导致停工停线或批量不良。最典型的风险是Agent“一本正经地胡说八道”——它根据模糊的记忆而不是系统实时数据给出结论而且表达非常自信。我自己定的治理框架有三个抓手。第一是数据锁任何业务数据结论必须有数据源引用Agent不能凭空输出库存量、合格率、设备开机率第二是逻辑锁业务动作用规则引擎前置校验不满足条件的动作直接拦截第三是人审岗关键决策必须有人确认Agent负责把决策材料和推演逻辑准备好人类只做选择和yes/no。这套抓手写起来简单落地时最难的是“让Agent承认自己不确定”。为了逼出不确定性我在Prompt里强制要求Agent对每个结论附带置信度分数置信度低于阈值时必须发起知识检索或转人工。这招虽然增加了一点算力成本但大幅提高了AI结论的可信度值得推荐。6.2 不要一股脑全上大模型该用规则用规则该用模型用模型AI-native不意味着所有环节都用大模型。工业场景里大量的确定性业务必须用传统规则和算法来处理又快又稳还没有幻觉。一个典型的例子是BOM展开和物料齐套计算这类运算用确定性算法做毫秒级完成让大模型去做反而可能算错。我的架构原则是确定性逻辑用规则引擎和算法库非结构化理解和复杂推理交给大模型中间态用机器学习模型补充。三个引擎在模型代理层统一编排由Agent决定哪个环节调用哪个引擎。这里也要提醒一点很多团队容易高估大模型的“推理能力”。让大模型做简单的加减法都可能算错更别指望它精确计算产能数据。凡是涉及精确计算的地方一律调用算法服务大模型只负责意图理解、方案生成和结果解释。6.3 渐进式替换路线图先生存后优化再智能化虽然标题是从零重建但我不建议任何制造企业做“大爆炸式”替换——把所有旧系统推倒一次性切换新系统。ERP/MES涉及财务、生产、质量、库存一旦中途失败恢复的成本极高。我更推荐的路线分三步走第一步搭数据底座和实时链路。在旧系统旁边并行搭建主数据管理平台、事件流平台、统一指标库先把数据资产梳理清楚。这时候AI只做读侧分析比如智能报表、异常检测、预测预警不动核心业务流程。第二步在1到2个业务域深度试点。比如选择计划排产和质量管理这两个域上线调度Agent和质量判定Agent让业务人员真实使用并沉淀使用反馈。这一步的目标是验证AI-native架构的业务价值建立团队和业务侧的信心。第三步逐步扩大覆盖面把采购、库存、生产执行逐步迁到新框架里最后再替换旧系统的核心交易模块。整个过程可能持续一到两年但对制造企业来说稳比快重要得多。6.4 团队构成会彻底变化农业时代需要“懂制造的AI工程师”最后说团队。传统ERP/MES项目团队构成是实施顾问加JAVA/C#开发加数据库管理员核心技术活在表单和SQL里。AI-native架构的团队构成完全不同既要有懂制造工艺流程的行业专家又要有懂大模型和Agent编排的AI工程师还要有负责数据链条的数据工程师和数据治理专员。我见过太多AI项目死在“懂AI的人不懂制造业懂制造业的人不懂AI”的断层上。化解的办法是互相“翻译”——行业专家要把工艺规则拆解成AI能理解的任务AI工程师要把模型输出解释成业务能接受的语言。两个角色必须高频配合不能各做各的。还有一个容易忽略的岗位知识工程师。制造企业里有大量隐性的工艺知识、经验规则、异常处置方法散落在老师傅脑子里。知识工程师要系统性地把这些知识结构化、沉淀成知识库供Agent检索推理。没有这个岗位AI系统的上限就只能停留在通用水平。最后讲点实在的体会这个项目如果真要做成我最大的体会是AI-native从来不是一个技术目标而是组织能力和数据基础到了一定阶段之后的自然结果。技术骨架都是公开的领域模型划分、事件驱动架构、Agent编排、数据链路设计每一点都有成熟方案可参考。真正拉开的差距在数据治理的深度、知识沉淀的厚度、以及业务人员对AI介入的接受度。如果让我给后来者一个建议我会说先别急着写代码先去车间蹲一个月。去理解计划员为什么宁愿信Excel也不信MES去理解质检员为什么能一眼看出某个缺陷是设备故障还是来料问题去理解物料员为什么在系统显示齐套之后还是打电话催供应商。这些在现场浸泡出来的理解才是这套系统最有价值的部分。AI-native给了制造业一次重构信息架构的机会但能不能抓住取决于我们能不能真正听懂车间的声音。