过去几年我一直在制造业做信息化从传统ERP实施到MES现场落地都碰过不少。说实话每次面对客户“系统怎么又卡了”“报表能不能灵活一点”“这个数据要重新录一遍吗”这类问题心里都很清楚根源在哪里——不是硬件不够也不是现场同事不会用而是这套软件从诞生那天起它的逻辑骨架就是照着三十年前的业务流程刻的。所以当我最近认真研究AI-native架构再回头看工厂里那些跑了几十年的ERP/MES系统时越看越觉得这条路真的到了该推倒重来的时候。这篇文章不是讲PPT上的概念是我想认真拆解一下——如果让我用AI-native的思路从零重建一套制造业ERP/MES我会怎么做、为什么会这么做、第一步该踩在哪里。1. 为什么传统ERP/MES必须被重建我从现场看到的四大病根先花点篇幅讲讲“为什么”因为如果没有这个前提后面所有架构设计都是空中楼阁。1.1 业务逻辑被固化成了代码改流程比换系统还难传统ERP的核心思想是“把业务流程固化到软件里”。听起来没问题但制造业的业务流程从来不是静态的。我见过一家做汽配的工厂客户要求每周一变的生产计划调整结果ERP里的主生产计划模块光改一个排产规则乙方实施团队改了三周才交付收费还不低。原因很简单——流程被写死在了模块结构里任何变动都要动底层代码。MES更夸张。我曾在现场见过一个SMT车间的MES连换线记录这种基础功能因为当初实施时没考虑多品种小批次的情况代码里到处是硬编码的工单判断逻辑。后来想改成按工单池动态取数几乎等于重写。这在传统架构里是常态不是个案。1.2 数据是“存”起来的不是“流”起来的传统ERP/MES的核心是“单据账本”采购单、领料单、入库单、生产工单、报工单所有的数据都是“记录”下来的。这种设计的潜台词是——数据只要落库就完成了使命。但今天制造业需要的恰恰相反同一个数据要在计划、执行、质量、成本多个维度被实时消费数据是流动的血不是仓库里的货。举个例子。一个在制品工位上的完工数传统认知里它是“报工单上的一个数字”用于月底结算。但在现代精益工厂里这个数字要实时驱动物料拉动、设备排程、质量追溯、计件工资计算。传统架构里这些模块各存各的数据库表之间靠批处理对账等到月底发现数字对不上追查起来能让人绝望。1.3 交互方式停留在“人找系统”传统ERP/MES的交互模式基本是“人找系统”你要查一个订单状态打开菜单输入查询条件看列表点进详情。一个班组长一天可能要发起几十次这种查询每次都是重复劳动。而AI-native架构下的交互应该是“系统找人”异常主动报警、下一步动作主动推荐、数据变化主动推送。这不是锦上添花的体验优化是生产现场实实在在的效率来源。我和很多车间主任聊过他们要的从来不是更多报表而是“别让我去翻系统直接告诉我哪里有异常、该怎么处理”。1.4 个性化需求无法满足每个工厂都有自己的生产特点、管理颗粒度、考核方式。传统软件通过“参数配置”来应对但参数化程度有限超过一定边界就只能定制开发。定制开发的后果是系统升级困难、维护成本飙升、厂商越绑越牢。AI-native的架构优势在于——系统的行为可以动态生成而非静态编码这让个性化从“改代码”变成了“调模型”。2. 我对AI-native ERP/MES的定义不是加个AI按钮而是从底层换血很多人提到AI-native想到的是“在传统系统上放几个AI功能”比如智能预测、智能排产、自然语言查询。我觉得这还停留在“AI增强”的层面真正的AI-native是从系统的认知方式、数据结构、交互形态都彻底改变。2.1 核心不是“自动化”而是“认知化”传统系统是“规则驱动”的如果A那么B否则C。规则能处理标准化场景但制造业最大的特点就是不确定性——插单、缺料、设备故障、质量异常每天都有意外。规则永远列不完所有场景。AI-native的系统应该是“认知驱动”的系统不只执行规则而是通过AI模型理解当前状态、预测风险、生成应对策略。不是替代人去决策而是帮人看到人看不到的维度提供人可能想不到的选项。举个例子一个生产主管看到的是“3号线今天产出比计划少了20%”传统系统只能呈现这个事实。AI-native系统可以综合分析人员出勤、设备运行数据、物料齐套率、工艺参数趋势告诉他“3号线今天瓶颈在回流焊工序温度曲线偏移导致良率下降建议调整参数并补排夜班2小时。”这才是认知化。2.2 核心不是“数据库”而是“知识库数据湖”传统系统的核心是事务数据库存储的是结构化业务数据。AI-native架构需要两层数据基础一层是数据湖——汇集设备IoT数据、手工填报数据、外部系统数据、文档资料格式不限保留原始粒度另一层是知识库——把工艺规则、质量标准、异常处理经验、人员技能沉淀成可查询、可推理的结构化知识。这两层配合才能支撑上层AI应用。没有数据湖模型没有素材没有知识库模型没有业务约束和判断依据。2.3 核心不是“流程引擎”而是“Agent协调层”传统BPM流程引擎本质是“提前画好流程然后照着走”。AI-native系统需要一个Agent层——它不是一个固定的流程执行器而是能够感知环境、拆解目标、调用服务、自主决策的智能体群。每个Agent负责一个领域计划、物料、质量、设备、成本它们之间通过消息通信像一个高度自治的团队在业务目标约束下自行协调。这个说法听起来有点抽象后面我会具体讲架构。简单说流程引擎是“轨道上的火车”Agent协调层是“十字路口的智能调度”。3. 我认为可行的AI-native ERP/MES参考架构四个平面一个中心参考业界普遍的AI系统分层思想加上制造业特定的业务复杂度我设计了一个四平面一中心的参考架构。3.1 数据平面物理世界到数字镜像的映射这一层解决的是“数据从哪来、怎么存、怎么保证可信”。具体拆分为三个子层接入层支持OPC UA、Modbus TCP、MQTT等工业协议对接PLC、传感器、扫码枪、AGV、质检设备同时提供REST/API接入对接上下游系统、Excel导入等人工数据源。存储层采用湖仓一体架构。实时数据用流式管道进入Kafka冷数据落到数据湖Iceberg或Hudi经清洗加工后进入数仓Doris或ClickHouse供BI和ML使用。事务性数据工单、物料账用PostgreSQL或TiDB保证强一致。数据治理层这层最容易被忽略但实际最要命。数据的“唯一身份”我们称之为业务主数据必须在这里统一——物料编码、BOM版本、工艺路线、设备编号、人员工号全厂一套字典。没有这层上面AI分析得出的结论就是垃圾进垃圾出。我常说一句话AI-native系统能不能跑起来七成取决于数据平面干不干净三成才看算法高不高级。3.2 计算平面从描述性分析到决策性分析的递进这一层解决的是“数据怎么变成洞察和决策”。我理解的AI-native计算能力分四档L1 描述性分析发生了什么实时生产看板、OEE统计、质量SPC控制图——传统BI就够L2 诊断性分析为什么发生根因分析、关联追溯、异常归因——需要数据挖掘和交互式分析L3 预测性分析将会发生什么设备剩余寿命预测、需求预测、产能瓶颈预测——需要时间序列、机器学习模型L4 决策性分析该怎么办排产优化、补料建议、工艺参数推荐——需要运筹优化和Agent决策四档能力不是一次性全部落地后文落地路线我会给出分阶段路径。3.3 智能平面Agent群与模型治理这层是AI-native架构和传统架构最显著的差异点。整体形态是一个Agent Orchestrator智能体协调器/主管Agent总控全局下面挂多个专业Agent子群每个子群对应一个业务域计划Agent接收销售预测与订单输出主生产计划初稿物料Agent监控齐套率、库存水位触发采购或调拨建议排产Agent结合设备状态、模具、人员技能生成车间级排程质量Agent监控SPC异常追溯不良品路径推荐纠正措施设备Agent分析点检数据、震动频谱、温度曲线预警潜在故障成本Agent实时归集工单成本偏差预警与构成分析每个Agent内部是一个“工具编排”的模式LLM负责语义理解和任务拆解周边挂接确定性工具排产求解器、质量分析算法、数据查询API。用LLM做“大脑”、用专业算法做“肌肉”这种混合架构实际落地时比纯LLM可靠得多。3.4 交互平面对话式、主动式、沉浸式这一层解决的是“人怎么和系统打交道”。我设想三个层次的交互变革移动端对话入口班组长可以用自然语言问“3号线夜班良率怎么样”系统返回结论并附带追溯链接仓库人员可以对系统说“A2025工单的物料齐套了吗”系统直接给出缺口明细。主动推送引擎系统不再是“等待被查”而是监控异常事件通过企微/钉钉/邮件把预警和处置建议推送给责任人。例如“B线配料区即将断料建议30分钟内触发调拨”。AR/数字孪生重要工位如装配线关键工位叠加AR指示显示每个螺孔的目标扭矩区间车间级数字孪生支持三维视角查看产线运行状态。这部分投入较大中小工厂可以从第一步和第二步入局。3.5 知识中心统一上下文与业务记忆知识中心是整个架构里最容易说得玄乎但必须落地的部分。它承担三个职责统一业务词汇表让“订单号”“工单号”“物料编码”“批次号”在所有Agent和模块里是同一个含义同一个取值标准。沉淀推理和决策依据之前Agent做的排产为什么这样选质量异常为什么判定为A类知识中心需要把决策链路的上下文存下来。这样当业务人员质疑“为什么这么排”的时候系统能给出可追溯的解释而不是一个黑盒答案。持续学习与个性化针对特定产线特点如某台老设备参数漂移特性、特定管理者偏好比如喜欢看“按班组拆分的不良率”而不是“整体不良率”知识中心在交互中持续学习和调整输出。4. 领域模型怎么设计以计划、执行、质量、物料四个核心域为例说完了整体架构再往下一层看——AI-native ERP/MES的领域模型应该长什么样。我选择了四个最核心的领域来做示例拆解这四块也是制造业现场最痛、最需要AI能力介入的地方。4.1 计划域由“计划排程”升级为“计划推演”传统ERP的MRP逻辑是“需求汇总—库存扣减—生成计划”本质是算数。AI-native计划域更像“推演”基于不确定性的多种情景模拟然后比较方案。我设计的计划域模型包含三个抽象类DemandForecast需求预测聚合销售线索、历史出货、季节性因子输出概率分布而非单点值CapacityProfile产能档案结合设备OEE历史、维护日历、人员技能矩阵动态刻画每个工作中心的“真实可用产能”PlanSimulation计划仿真“如果下周A客户加单20%同时B线设备需停机保养2天计划如何变动物料能否支撑”系统自动仿真运行输出可行计划及各环节风险提示这套模型的意义在于计划员手里的工具从“排程计算器”变成了“沙盘推演器”可以在风险发生前多问几个“what-if”。4.2 执行域从“记录报工”升级为“实时感知自主调度”传统MES的核心是“报工”AI-native的执行域核心是“感知与调度”。执行域模型包含ExecutionContext执行上下文实时汇聚当前工单、设备状态、在制品位置、物料到位情况、人员当前位置构建整个车间的动态快照DeviationDetector偏差检测器将实际执行与计划基线做实时对比偏差超过阈值如节拍时间偏离15%即触发异常对象ActionAdvisor行动建议器基于异常类型和专家知识库输出处置建议——是调整节拍、换人、还是启用备用工艺一个典型的场景是计划要求某工位节拍40秒/件实际跑到48秒。传统MES只是在看板上跳红字。AI-native执行域会立刻分析是设备老化工况、物料摆放不当还是人员熟练度问题并给班长推送可操作建议。4.3 质量域从“事后检验”升级为“过程预防根因推理”质量在制造业的分量不用多说。传统质量模块的核心是检验记录和不良统计不坏不知道坏了找原因。AI-native质量域设计的核心对象QualityKnowledgeGraph质量知识图谱把物料、工艺参数、设备状态、环境条件、检验结果连接成图谱形成“数据—因素—质量结果”的关联网络AnomalySignature异常特征库沉淀已知异常模式的“签名”比如特定设备的温度曲线形态对应某种焊接不良RootCauseReasoner根因推理器当出现新的不良模式时系统自动在图谱上做多跳检索结合贝叶斯推理给出可能原因排序和验证建议举个例子。某天注塑车间出现一批产品表面银纹传统做法是老师傅凭经验排查料温、模温、原料干燥情况。AI-native系统直接对近期几千模次参数做关联分析锁定“原料干燥时间不足”是首要嫌疑同时按数据支持程度给出原因排序排查效率完全不是一个量级。4.4 物料域从“安全库存”升级为“动态拉动”传统物料管理依赖安全库存和再订货点本质是“拍脑袋加统计”。AI-native物料域的核心是动态拉动。物料域模型的关键对象MaterialFlowGraph物料流图把物料从供应商到工位的移动路径、环节耗时、库存缓冲点建模成一张图ReplenishmentAgent补货智能体实时监控各节点物料消耗速率结合采购提前期、供应商交付可靠度动态计算补货时机和批量RippleEffectSimulator涟漪效应模拟器预测某物料到货延迟对整个生产计划和交付承诺的“涟漪影响”提前预警销售端和客户一个直接的效果是物料不再依靠“月底看到库存低了再下单”而是系统基于实时消耗和计划变化持续调整。插单不再是物料噩梦因为系统在当天就自动评估了新订单对物料需求峰值的冲击并给出采购或替代建议。5. 从零开始的落地路径我建议的六步实施路线图理想架构画得再漂亮落地才是真章。制造业最大的现实约束是产线不能停、业务不能断、团队技能有限。所以我强烈建议采用“基建先行、能力渐进、新旧共存”的六步路线。5.1 第一步统一数据底座与主数据治理第13个月这一步不产生任何炫酷的AI功能但决定了整个项目的成败。具体动作盘点所有数据源ERP里的物料/供应商/客户主数据、PLC/DCS里的设备数据、MES里的工单/报工数据、手工Excel里的工艺卡和点检表全部入湖制定主数据标准物料编码唯一、设备编号唯一、工序代码唯一、人员工号唯一并建立映射表处理历史数据里的“一物多码”“一码多物”搭建数据质量看板每周跟踪主数据完整率、唯一率、及时性让“数据治理”变成一个可量化的持续过程这个阶段最容易犯的错是“等完美了再开始”。千万别等先入湖、先标定、先跑起来后面靠数据治理看板持续清欠。5.2 第二步上线实时数据集成与轻量级数字看板第35个月数据底座有了第一层让用户直接感知价值的是实时看板。具体动作完成设备协议接入优先选择OEE影响最大的前20台关键设备接入PLC/传感器数据建设车间级实时看板包括计划达成率、设备OEE、当前在制品缓存、质量缺陷Top项、物料呼叫历史配置异常事件订阅当关键指标突破阈值例如OEE低于75%自动推送给车间主任和对应班组长看板不要贪多先做3-5个最核心的。这个阶段的目标是让车间第一次体验到“系统主动告诉我出了问题”而不是“我去系统里翻出了问题”。5.3 第三步构建领域Agent的MVP——从计划与物料开始第58个月数据在流动、用户在感知这时候可以上第一个Agent。我的建议是选择计划与物料域作为MVP原因有二这两个域数据相对规整、规则相对清晰、业务价值立竿见影同时它们联动影响极大做好了后面的质量/设备Agent容易顺势推进。具体动作搭建Agent Orchestrator框架定义Agent通信协议、任务分发策略、人审退路机制开发计划Agent初版输入订单和产能档案输出主计划初稿交计划员在界面确认或修改开发物料Agent初版监控齐套率触发缺料预警和补货建议这里有一个关键原则Agent的“建议权”先行、“决定权”后置。AI先做参谋人做决策积累足够信任和准确率后再逐步放权。5.4 第四步扩展Agent矩阵并建立闭环优化第812个月计划/物料Agent稳定运转后开始扩展上排产Agent从单线排程起步再扩展到跨线协同上质量Agent先接入SPC监控再接入质量知识图谱做根因推理上设备Agent从点检数据接入到预测性维护告警同时建立闭环优化机制每次Agent的建议被采纳或拒绝都作为反馈样本记录下来。系统定期两周或一个月做一次效果复盘校准模型和规则。这一步是AI-native系统“越用越聪明”的关键也是和传统软件“上线即巅峰”最大的区别。5.5 第五步对话式交互全面接入第1215个月底层Agent群稳定后开始升级交互层全员移动端对话入口让班组长、计划员、仓库员通过自然语言查询业务数据自然语言生成汇报一键生成“车间生产日报”“质量异常周报”内容组织、重点提炼、排版全自动这个阶段的挑战不是技术而是用户习惯的迁移。我的经验是找一个积极性高的车间做“灯塔”“灯塔”跑顺了其它车间会主动求着接入。5.6 第六步向决策自动化演进第15个月后最后一步才谈得上“自主决策”。选择容错度高、影响面可控的场景先行自动排产约束条件齐全、目标函数清晰可以先从单车间试点补货单自动下达当AI物料Agent连续三个月建议采纳率达到95%以上才允许自动下单质量停线建议达到特定风险分值时系统自动推送“建议停线”指令仍需产线负责人确认这一步的本质是人和AI之间信任关系的演进不能靠口号只能靠数据说话——采纳率、准确率、业务收益每一项都要跑在明面上。6. 这场重构里最难的从来不是技术组织、人才与演进节奏写到这里我想说一个可能让技术人不太舒服的结论用AI-native重构ERP/MES真正的瓶颈不是AI模型能力不是架构设计而是组织愿不愿意把“决策权”逐步交给一个成长中的智能系统。这不是技术问题是治理和管理变革。我在项目推进中最大的体会是必须先和业务领导达成共识——AI-native系统的落地是一个“信任爬坡”的过程前几个月系统会犯错会有很蠢的建议但每一次纠错都是系统成长的数据养分。如果没有这个心理预期项目很容易在第一个不完美时刻就遭否定。对团队结构我建议最小组件是“业务专家数据工程师ML工程师全栈工程师”的四角组合外加一个既懂制造又懂AI的架构负责人。业务专家不是需求传话筒而是Agent的知识来源——把“老师傅的脑内经验”显性化成知识库规则这件事的价值比任何算法调优都高。还有一点特别重要不要试图一步到位替换现有ERP/MES。AI-native的新系统和传统系统必然长期共存。老系统继续承担财务核算、合规追溯等强规则事务新系统逐步接管计划、调度、质量管理、物料协同等强决策事务。通过API网关做双向数据同步两边并行演进这才是务实的态度。选择合作伙伴时我会非常谨慎既懂工业现场、又有自研AI能力的团队太稀缺。很多号称“AI制造”的服务商只是把报表加了层对话外壳千万不要被这种伪AI-native系统迷惑。判断方法很简单——看他能不能说出你的一个典型异常场景并现场演示系统从感知、分析到建议的完整链路。最后分享一个我正在坚持的判断未来五年制造业软件的核心竞争力不会是功能的“全”而是对不确定性的“聪明响应”。AI-native架构的最终形态是一套能让工厂在插单、缺料、断线、异常这些每天都在发生的“意外”面前依然从容运转的“操作系统”。这个目标值得所有制造业信息化从业者认真投入一把。