我在制造业信息化这条路上摸爬滚打了十多年从早期单体 ERP 到后来微服务改造再到这两年接触的各种智能工厂项目见得太多了。今年年初我给自己定了一个有点疯狂的目标用 AI-native 架构从零重建一套面向制造业的 ERP/MES 系统。不是给老系统挂个AI 助手而是把大模型当作运行时的一部分把排产、报工、异常处理、质量判定这些核心业务全部改写成可被 AI 调度、可被大模型理解的形态。这篇文章是我目前已经完成的整体思路、架构决策、实操路径和踩坑记录的完整复盘。如果你正在做制造业信息化、工业软件或者单纯想看看 AI 怎么真正落到车间这篇内容应该对你有用。1. 为什么传统 ERP/MES 非改不可1.1 传统架构的四个死穴先别急着谈技术选型我得先说说为什么要动手重建。传统 ERP/MES 这套东西在制造业里跑了三十年底子非常扎实但也把一些结构性毛病固化下来了。第一个死穴是计划与执行断层。ERP 里的计划员排完产得到的结果是一张张工单和交期承诺但车间里真实情况是设备随时可能故障、人员可能请假、物料可能晚到。MES 系统接收执行结果后只会把报工数据回传计划员还是靠 Excel 手动调整。两个系统各干各的数据永远差半天。这个问题我在三个工厂都见过几乎没有例外。第二个死穴是数据孤岛。ERP 管订单、采购、库存MES 管工单、工序、质检两套系统的物料编码、工序编码、工作日历都各有一套。我见过最夸张的案例同一个物料在 ERP 里叫CNC-01-0023在 MES 里叫数控件A-23Excel 映射表有三百多行。这种数据基础后面的统计分析全都不靠谱。第三个死穴是交互反人类。操作工在工控机上完成一次报工要填工单号、工序号、数量、合格数、不良数、设备号、班次十来个字段一轮下来三分钟。老师傅宁可手写在小本子上也不愿意碰那个界面。质检员就更痛苦了一套来料检流程要跳五六个页面填十几张表。第四个死穴是变化响应慢。制造业最怕什么插单、缺料、设备宕机。传统系统面对这些突发情况只能事后记录一笔异常工单然后等计划员第二天早上开会协调。现场决策完全依赖人的经验系统本身是一个哑巴盒子。这四个死穴不是靠修修补补能解决的它们根植于过去的架构假设系统是记录工具人是决策主体数据是事后资产。要改变这个局面必须把决策能力搬进系统本身而这正好是 AI-native 架构能做的事。1.2 AI-native 到底指什么这几年 AI-native 这个词被用滥了很多厂商把老系统接个 ChatGPT 接口就说自己是 AI-native这是很误导人的。我自己对 AI-native 的定义有四个硬性条件。第一模型在架构中是一等公民而不是外部调用。传统集成是业务代码里偶尔调一次大模型 APIAI-native 则是模型通过 Agent 运行时参与业务编排。排产、异常处置、质量判定这样的事件触发之后可以交给模型分析、生成方案、调用工具执行。第二业务对象必须有语义层。系统里的物料、BOM、工艺路线、工单、报工记录不仅要有数据库字段还要用结构化描述告诉模型这些概念的层级关系、约束条件、业务含义。模型不是靠猜来理解工单 W001 的第 3 道工序报工 50 件而是通过领域模型和工具契约来准确理解。第三交互方式从表单驱动变成意图驱动。操作工可以对着系统说3号设备加工完成 50 个系统解析之后自动匹配工单、工序、设备生成报工记录并校验。这种交互不是把表单搬到聊天框里而是让系统理解上下文后主动完成一系列动作。第四决策链路必须是可回滚、可审计、可校验的。AI 给出的任何排产建议、质量判定、异常处置方案都要有决策记录表标明输入参数、模型输出、执行结果。允许 AI 犯错但不允许它犯完错不留痕迹。搞清楚了这四点就明白为什么我说不能直接把旧系统包一层壳就完事。旧系统的核心流程是固定写死的模型插不进去。重建不是为了追热点是为了换一种系统组织方式。1.3 这套系统解决什么问题、适合谁参考这套系统的目标用户我定位在中小型制造企业。大型集团早就自建了完整信息化体系很难推倒重来但中小工厂恰恰是传统 ERP/MES 渗透率低、痛感最强的群体。他们没有几百人的 IT 团队需要一套更轻、更聪明、能小步快跑落地的东西。它解决的问题说白了三句话让排产计划贴近车间真实状态让现场报工和异常处理不再依赖纸质和 Excel让管理层随时能用自然语言问出这个月哪条产线拖期最严重并且拿到实时答案。如果你正在做制造业信息化相关的项目或者你是独立开发者想切入工业软件市场又或者你只是对 AI Agent 在垂直行业落地感兴趣这篇文章里的取舍思路应该都能给你一些参考。我后面写的所有东西都是基于真实编码踩坑得出的结论不是从 PPT 里抄来的概念。2. 整体架构设计与技术选型2.1 六边形架构 DDD 的分层拆分整个系统我采用了**六边形架构 领域驱动设计DDD**的组合。这套组合在互联网行业已经非常成熟但在传统工业软件里见得不多原因是工业软件之前的交互模式太固定不需要这么灵活的分层。六边形架构的核心思想是把业务逻辑放在最内层把数据库、外部接口、AI 模型、消息队列这些技术细节全部放在外层的适配器里。举个例子排产引擎是内层核心它可以接收来自 Excel 导入的数据、来自 MES 接口的工单、来自 AI Agent 的指令但它本身不关心这些指令从哪里来。这种设计带来的最大好处就是领域逻辑不会被技术栈绑架。选型时我做过一次对比测试用传统三层架构写排产模块用了两周代码和 SQL 强耦合后来按照六边形重构多花了三天拆层但后面新增 AI 接入的时候我只写了三个适配器类没有动任何核心代码。这个账长期看非常划算。DDD 的部分我重点用在了领域建模上。物料、BOM、工艺路线、工单、报工、质量任务这些概念如果只是建表后面所有业务逻辑都会变形。我花了三周时间做事件风暴把十来个核心实体的行为、状态、事件梳理清楚。比如工单这个实体不是一张表而是一组状态机创建、下达、开工、完工、关闭、重开。每一次状态变更都会产生领域事件供其他模块响应。2.2 把大模型当运行时组件而不是外部工具这个设计决策是整个 AI-native 架构最核心的部分我要单独拿出来说。刚开始我也犯过很多团队的毛病把大模型当成了高级查询接口后来我彻底改掉了这个思路把它当作一个运行时组件。所谓运行时组件意思是模型被编织进业务事件循环里。当系统检测到设备故障信号会触发一个设备异常处置事件这个事件既可以被规则引擎处理如果规则明确比如停机超过 30 分钟自动通知主管也可以被 AI Agent 接管。Agent 拿到事件上下文后会调用工具去查询当前这个设备上的在制工单、物料准备情况、替代设备产能然后生成一套处置方案。方案经过人确认后执行执行结果回写系统。为了让模型能调用业务方法我把核心业务能力全部暴露成结构化工具。比如query_capacity(work_order_id, date_range)、report_progress(operation_id, qty, defect_qty, equipment_id)、suggest_reschedule(work_order_id, priority)这类的。每个工具都有严格的入参出参描述系统在模型返回 JSON 指令后做参数校验和权限校验再真正执行。这才是 AI-native 和接个大模型 API的本质区别模型不是问一句答一句的聊天对象它是业务流程里一个可以调度资源、执行动作的参与者。2.3 核心模块拆解整个系统我拆分成了八个核心模块每个模块之间通过事件和消息通信不搞大一统的数据库级耦合。这八个模块是主数据服务物料、BOM、工艺路线、设备、设备组、班组、工作日历这一层是所有业务的底座。订单协同销售订单、预测、变更管理承接商机到计划的需求输入。计划与排产引擎粗能力平衡、精细化排产、插单模拟、交期承诺。车间执行任务派工、工单流转、报工、工时归集、异常上报。质量体系来料检、过程检、终检、不良品处理、质量追溯。设备管理点检、保养计划、故障申报、维修记录、OEE 计算。追溯与批次批次档案、序列号管理、正向反向追溯。报表与分析面向管理者的实时看板、经营分析、AI 问答报表。模块划分的标准并不是按页面切而是按业务生命周期切。比如质量追溯模块为什么独立因为质量数据的生命周期产生、流转、判定、闭环和工单生命周期不一样混在一起会让两边都很难改。2.4 技术栈选型与实际落地清单技术栈方面我一开始就走了比较务实的路线没盲目追新。后端用Java 21 Spring Boot 3.2 Kotlin 混合开发。Java 的生态和人才储备是制造业场景最稳的Kotlin 则让核心领域逻辑的表达简洁很多。数据库选了PostgreSQL 16业务数据全放这时序类数据设备采样、温度、功率、振动用 TimescaleDB 扩展。消息中间件用了 RabbitMQ够用、易维护不引入 Kafka 这种重量级组件。前端是 React TypeScript Tailwind CSS。我不是前端出身选了最保守的组件库组合没有搞花活。部署方面单机先用 Docker Compose后续多节点再迁到 Kubernetes。这一步很多团队会一步到位上 K8s结果运维成本直接把小团队拖垮。AI 层面的选型要特别说明。我没有只依赖云端大模型 API因为制造业车间对数据私密性和离线连续性的要求非常高。我的方案是双通道模型路由常规查询和辅助建议走本地部署的 Qwen2.5-72B用 Ollama 和 vLLM 跑复杂推理、跨模块综合分析走云端的大模型通道。业务层做了一层模型网关当一个通道不可用时自动降级到另一个。2.5 为什么不用现成低代码平台这个事我必须展开说因为好多朋友听说我要从零做都会问我一句为啥不用低代码平台我认真评估过结论很明确——低代码平台撑不起 AI-native 这种架构需求。低代码平台的核心能力是表单 流程 报表这对行政管理类应用很够用但对制造业 ERP/MES 来说远远不够。排产引擎需要复杂的约束求解算法低代码平台没有这种编辑器设备数据采集需要协议适配层低代码平台通常只提供数据库读写AI-native 要求模型能和业务方法自由组合调用低代码平台的扩展插件机制根本接不住这种复杂度。更关键的是低代码平台会把你锁在一个别人的抽象层里。等你做到第三年想改它的底层架构会发现改不动只能推倒重来。制造业系统的生命周期动辄十年起这个锁死风险我承受不起。3. 核心引擎实现从排产到执行的闭环3.1 产能模型与排产算法的设计思路排产引擎是 ERP/MES 里最难啃的骨头也是最容易翻车的模块。我的设计原则是先用规则引擎兜底再用启发式算法优化最后让 AI 在边缘场景做决策三个层次逐级递进。产能模型的底层数据很简单设备、设备组、工作日历、工序标准工时、物料可用量。每个工序有一个标准时间再乘以设备效率系数得到实际加工时间。工作日历定义了设备每天的工作时段比如三班倒、倒班规则、节假日。这些都是基础数据结构但百分之八十的项目死在它们没建好。排产算法我用了两层。第一层是约束满足把一个工单分解成若干工序每个工序匹配到可用设备组检查物料是否齐套、设备日历是否可用。这层必须保证产出的是可行排产方案。第二层才是优化用遗传算法目标函数是交期达成率、设备负荷均衡度、换型次数加权求和。遗传算法的种群规模设 100迭代 200 代在单条生产线上十来个工单的规模跑一次大概五秒完全够用。AI 在排产里的角色我限定在插单模拟和异常重排。当临时订单进来规则引擎先给一版排产结果AI Agent 会分析这版结果对现有工单的影响给出优先插单 A、推迟工单 B 两天这样带理由的建议。排产结果一定要可解释不能是黑盒否则车间根本不接受。3.2 AI 助手的接入方式Function Calling 与 MCPAI 助手不是我后来加的它从一开始就是系统的一部分。为了让模型具备调用业务方法的能力我采用了Function Calling MCPModel Context Protocol的标准组合。MCP 主要用来管理上下文和工具定义。我把系统的领域模型、常见业务流程、工具清单都通过 MCP 暴露给模型模型每次运行时能感知到当前有哪些工具可用、每个工具的参数要求是什么、哪些动作被允许。这样模型不会凭空编造一个不存在的接口。下面是我给 AI 助手注册工具的一段核心代码用 Spring Boot 的 Bean 方式暴露Component public class WorkOrderTools { private final WorkOrderService workOrderService; public WorkOrderTools(WorkOrderService workOrderService) { this.workOrderService workOrderService; } McpTool(description 根据工单号查询工单当前状态、工序进度和剩余数量) public WorkOrderStatusVO queryWorkOrderStatus(McpParam(name workOrderId, description 工单编号) String workOrderId) { return workOrderService.getStatus(workOrderId); } McpTool(description 为指定工单的指定工序提交完工数量可选填不良数) public ReportResult reportOperationProgress( McpParam(name operationId) Long operationId, McpParam(name completedQty) BigDecimal completedQty, McpParam(name defectQty) BigDecimal defectQty) { return workOrderService.reportProgress(operationId, completedQty, defectQty); } }这里的关键是工具描述必须写清楚业务语义。比如提交完工数量工具如果不说明提交后该工序状态变为已完工不可重复提交模型就可能在同一道工序上报两次。为了规避这类问题我在每个工具的实现里都加了状态机校验防止模型产生非法操作。模型返回的是结构化 JSON 指令比如{tool: reportOperationProgress, params: {operationId: 123, completedQty: 50, defectQty: 2}}。我的执行引擎会先做参数合法性校验、权限校验然后才真正调用业务方法。任何一次调用都会写入审计日志。3.3 数据模型设计要点与字段级细节数据模型设计上我把主数据和单据数据、实时数据严格分开。主数据表有 material、bom、route、equipment、device_group、calendar单据表有 sales_order、work_order、operation_record、quality_task实时表有 equipment_status、temp_log、power_log。我踩过的一个大坑是时间字段类型。传统系统里很多人用本地时间跨班次、跨时区一算就乱。我从一开始就统一用timestamptz所有接口传 ISO 8601 带时区格式。另一个坑是批次字段我之前偷懒用自增 ID后来发现做批次追溯时根本没法定位唯一记录强烈建议用 UUID 或雪花 ID。工单表的设计我额外加了一个字段snapshot_json每次工单状态变更时把当前的完整上下文工艺路线、已完工序、在制数量、设备分配序列化存进去。这样追溯的时候不需要回放所有历史日志直接读快照就行。代价是多了点存储但换来的是追溯查询从秒级变成毫秒级这个取舍非常值。3.4 让 AI 理解车间语义提示词与领域模型设计这一步是最容易被忽略、但实际效果差异最大的部分。我发现直接给模型一本操作手册它是不会用的真正有效的方式是给它一个领域词典 工具契约 少量示例。领域词典里我会定义工单生产任务包含多道工序工序在特定设备组上的加工步骤报工对某道工序完成输入的操作。模型需要理解这些词的关系才能把3号机干完了这句话正确映射到设备编号 E003 对应的工序完成报工。Few-shot 示例也非常重要。我写了三五个真实场景比如客户电话要求插单 500 件最迟周五应该触发什么工具、输出什么格式。示例不需要写很多三五个高质量的就够让模型进入正确的工作模式。还有一个细节不可见上下文不参与决策。我给模型传的业务数据是定了白名单的涉及成本和利润的敏感字段默认不传。不是说模型不可信而是这个系统使用场景是车间有些数据确实不属于 AI 决策范围。4. 实操过程与踩坑记录4.1 从零搭建第一步领域建模不要先画界面很多开发者的第一反应是画界面、建数据库表我这次完全反着来。项目启动后的头三周我几乎没有写代码全程在做事件风暴。我用一面白板加便利贴把订单录入、计划评审、工单下达、开工、报工、质检、入库、异常处理这些业务流程全部推演了一遍。我强烈建议你在这个阶段千万别着急开发。我的原因是制造业业务流程每个厂都不一样你如果按某个厂的习惯建了表换一个厂就死了。事件风暴帮你把业务里恒定不变的那些核心概念挖出来这些概念才是系统的地基。具体做法是找三个业务专家在工厂里就是生产经理、计划员、车间主任各聊一下午把事件的顺序理出来再把每个事件关联的数据和决策点标出来。这个投入一点都不浪费后面写代码可以快一倍。4.2 大模型接入的三种模式对比我先后试了大模型接入的三种模式这里列个表给你参考模式适用场景优点踩坑点API 直调简单问答、文本生成实现最快无法控制模型输出质量业务集成弱RAG 检索增强知识库问答、文档查询回答有据可查召回不准语义割裂维护成本高Agent 编排排产建议、异常处置、跨模块协同真正参与业务流程调试复杂需要严格的容错和校验机制我最终的方案是第三种为主、第二种补充。RAG 主要用于设备维修知识库的问答Agent 编排用于计划、执行、质量的核心闭环。如果你一开始就上 Agent大概率会被各种意外输出折磨到崩溃所以我建议先从 API 直调跑通流程再逐步切到 Agent。4.3 数据同步与工业协议对接车间层的数据采集是 MES 的根基对接协议基本绕不开 OPC-UA、MQTT 和 Modbus TCP。老设备大部分用 Modbus新设备基本都有 OPC-UA 或者 MQTT 网关。我在系统里做了一层统一采集适配器不管底层是啥协议数据到了系统里都是一个统一结构设备 ID、参数名、时间戳、数值、质量戳。这个设计看似简单实际帮我省了非常多麻烦。原来对接每台新设备都要写一整套逻辑现在只需要配置设备参数映射表。比如 Modbus 的寄存器地址 40001 对应主轴电流在映射表里配一条记录数据就自动入库了。一个两百多台设备的车间用了不到两周就把主要产线接完了。这里有个提醒设备数据的质量戳quality flag一定要保留。很多数据采集项目把这个字段丢了结果系统显示主轴当前转速 9000谁知道是真值还是传感器坏了带质量戳才能区分有效值和异常值。4.4 性能与成本控制不让 AI 拖垮系统AI-native 最现实的问题是成本和延迟。如果每个操作都要经过大模型系统会又慢又贵。我做了两个重要决策。第一个决策是高频场景不走模型。设备报工这件事是车间里最高频的操作一天可能几千次。这种场景用规则引擎直接处理两毫秒完成。AI 只处理那些需要判断、需要整合信息的低频场景比如异常分析、插单影响评估、质量趋势归因。第二个决策是语义缓存。同一个业务问题比如上月 A 线 OEE 是多少很多人会反复问我做了查询结果的语义缓存命中后直接返回不再调模型。同时模型调用全部走流式响应用户在界面先看到正在分析的占位实际响应体感快很多。最终测算下来每千次调用的成本比全量直调低了七成。4.5 权限与安全车间数据不能乱给 AIAI-native 架构下安全和权限模型必须重新设计。传统系统的权限是页面级、按钮级的AI 系统里模型可能通过工具访问任意数据所以权限控制必须下沉到工具调用和数据访问层。我用了 ABAC基于属性访问控制每个请求都携带主体属性用户、角色、所属车间、班组、资源属性数据所属产品线、密级、环境属性时间、地点。比如质检员小王只能查看自己班组的数据只能触发质量判定相关工具不能调用排产修改工具。还有一个铁律AI 没有删除和批量修改的权限。模型返回的指令里如果包含 drop、delete、batchUpdate 这类操作执行引擎直接拒绝并记录告警。AI 只能做建议和执行可逆操作不可逆操作必须人工确认。这个约束让我后面的测试阶段少了很多惊吓。审计上我建了一张 ai_audit_log 表每条 AI 调用至少记录触发场景、输入上下文摘要、模型输出、调用了哪些工具、执行结果、耗时。这张表在系统的每一天都在增长但它是我排查问题最重要的依据。5. 常见问题与排查技巧实录5.1 常见问题速查表这个项目开发到中期我攒了一批典型问题列成速查表放在开发文档里现在直接分享给你问题可能原因排查方向LLM 上下文爆掉传了过多历史对话或超大业务对象压缩上下文做业务摘要替代原始数据排产结果不收敛约束冲突无可行解把硬约束转软约束允许松弛并记录模型乱传参数工具描述不清晰加强工具 schema 校验和状态机保护设备数据断线网络波动或协议网关故障加边缘缓存断线重连补偿报工重复提交状态机未校验工序状态加唯一约束防重幂等5.2 LLM 上下文爆掉怎么办这个问题出现过好几次症状是模型忽然开始胡言乱语或者返回空结果。原因基本都是上下文塞太多不相关的东西。我后来定了上下文管理规范每个请求最多携带最近十轮消息和当前业务对象的精简视图长文档走 RAG不直接塞进 prompt。还有一个有效做法是定期摘要。如果一轮对话超过二十轮系统会把前面的内容压缩成一个结构化摘要比如已完成 3 号工单的排产分析建议推迟 B 工单等待确认。这样模型在后续对话里不会丢掉关键信息也不会被冗余细节淹没。5.3 排产结果不收敛的排查思路排产引擎跑不出可行解是排产模块开发期最容易遇到的事。我排查下来百分之八十的原因是约束建模太死。比如一台设备日历里被写死了不可用时段而某个工序只能在这台设备上加工时间窗口完全重叠就必然无解。解决思路是引入松弛变量。把必须本周完成改成建议本周完成每延迟一天扣 10 分然后在优化目标里加惩罚项。这样即使没有完美解算法也能给一个代价最小的次优解。AI 这时候再上场解释这个次优解为什么产生、以及可能的补救动作。5.4 车间网络不稳定的容错机制制造业车间的网络环境比写字楼恶劣太多。我遇到过 Wi-Fi 信号死角、交换机被叉车撞断、PLC 网关内存溢出各种情况。容错设计必须从第一版就做。我给系统加了三层保护。第一层是边缘缓存报工数据本地先存一份网络恢复后自动同步第二层是断线重连补偿消息队列里未确认的消息会自动重发第三层是降级模式云端大模型不可用时自动切到本地模型或者规则引擎核心业务不停摆。还有个小技巧我在每台工控机上部署了一个轻量本地代理即使中心服务器挂了操作工也能在本地完成报工和查看今天的任务清单。这个设计在真实车间里救过我好几次。5.5 测试策略双模校验AI 系统最让人揪心的是它偶尔不按常理出牌。我的测试策略是双模校验同一个业务场景同时跑规则引擎和 AI 通道两边输出对比差异超过阈值就触发告警并记录。在排产模块我导入了过去一年的历史生产数据用 AI 通道生成排产方案再和当年实际排产方案对比。如果 AI 方案比实际方案总提前量更高而且约束不冲突说明排产逻辑是靠谱的。在质量模块我准备了一千条历史质检记录让 AI 做判定和当年质检员判定对比算准确率和召回率。这套双模校验机制帮我提前发现了两处提示词设计和工具描述的问题非常值。6. 后续扩展与个人体会6.1 从 MES 走向数字孪生系统核心跑通之后我接下来的扩展方向是数字孪生。MES 掌握了实时生产数据只要把这些数据映射到三维车间模型上就能做虚拟车间漫游、设备状态可视化、瓶颈分析。AI-native 架构在这里又有一个优势数字孪生里所有查询都可以通过自然语言完成比如把 A 线当前瓶颈设备标红或者回放昨天下午 3 点的设备温度变化模型直接调用孪生查询工具返回结果。但要提醒一句数字孪生是个无底洞别一上来就追求全厂三维高精度建模。先做单条产线的设备三维模型接到实时数据跑通一个场景再逐步扩展。否则建模成本会让你心态崩掉。6.2 AI-native 团队的组建建议最后聊几个团队相关的实操体会。AI-native 项目跟传统软件开发对团队能力要求很不一样最核心的变化是团队里必须有人懂制造业业务流程又必须有懂 LLM 工程的人两边不能各干各的。这个跨界角色我称为业务智能工程师他能把车间里一个老师傅的自然语言指令翻译成系统的工具调用链这种能力非常稀缺。另外我在项目里做过一个很管用的动作每周让车间主任带着当前版本的测试账号在产线上跑半个小时看他哪里卡住、哪里不敢点。这一个小时的反馈比我在办公室看三小时日志都有用。制造业软件是给人用的不是给电脑用的这个道理越到后面越深刻。我自己从年初开始做这套系统到写完这篇文章时排产、报工、质量闭环已经在一个试点车间跑通了每天进出几千条报工记录AI 助手承担了大约百分之三十的异常分析和插单建议。说实话距离我理想中的完整 AI-native ERP/MES 还有很大距离但至少起点是对的。如果你也想做类似的事我给你的最大建议就是别把 AI 当外挂把它当成系统里一个真正干活的角色一切设计围绕这个角色展开其他顺势而为。