Articles
从 MES 到 Manufacturing Agent Runtime：当生产系统开始自己做决策
SHEIN 式制造的关键不是给 MES 加一个 Copilot，而是把高频、动态、组合复杂的生产决策变成 Agent Runtime 的持续闭环。
这篇文章来自我对 SHEIN 式制造模式、MES 和 Agent Runtime 的连续思考。这里并不是试图还原某一家公司的内部系统，而是把一种高频数字化供应链闭环抽象出来，再问：如果 Agent 真正进入制造系统，业务架构应该发生什么变化？
不要替代岗位，要替代决策单元。
本文会区分三种表达：
- 已观察事实：来自现有业务系统、生产实践或可复现数据的描述。
- 工程判断：基于这些事实提出的架构判断或设计建议。
- 未来推测：对行业和系统形态可能如何演化的假设。
后文的架构图和 Agent 分工主要属于工程判断，不等同于某一家企业已经采用的内部事实。
真正的变化不是“给 MES 加一个 AI Copilot”，而是生产系统从“执行已经确定的流程”，逐渐变成“持续观察现实、做出决策、执行、验证并重新规划”的 Manufacturing Agent Runtime。
1. 传统 MES 与 Agent 化制造的区别
传统 MES 可以抽象成：
订单
↓
生产计划
↓
排产
↓
工单
↓
生产
↓
质检
↓
入库它解决的核心问题是：如何把已经确定的生产计划数字化、透明化，并稳定执行。在本文的抽象中，MES 主要承担生产执行、过程追踪、状态记录和约束落地；跨订单、跨工厂、跨供应链的动态决策，通常还需要 APS、SCM、ERP 等系统共同参与。
但当制造模式变成高频、小批量、快速反馈时，生产计划本身不再是一次性确定的输入，而变成动态决策问题：
用户需求
↓
小批量测试
↓
真实销售反馈
↓
重新判断需求
↓
追加生产
↓
再次反馈2. 为什么这种制造模式天然适合 Agent
已观察事实：在高频、小批量、快速反馈的制造模式中，需求、库存、产能和订单状态会持续变化，生产计划通常需要反复调整。
工程判断：因此真正需要 Agent 化的，不是 MES 的所有功能，而是 MES 上方那些不断变化、需要重新组合资源的决策过程。
如果抽象掉具体公司的业务细节，会发现它具有几个典型特征：
大量 SKU
+
大量供应商
+
大量小订单
+
快速生产
+
快速市场反馈
+
快速重新生产一个订单表面上只是“生产 10,000 件”，但真正的决策可能同时涉及供应商、生产线、材料、工艺、质量、交期、价格、库存、在制品、已有订单和机器状态。
真正的问题变成：
10,000 件
↓
怎么拆？
↓
给谁？
↓
什么时候做？
↓
用什么材料？
↓
走哪条产线？
↓
如果出现延迟怎么办？这已经不是简单 Workflow，而是 Combinatorial Optimization + Dynamic Decision Making。组合一多，规则数量会膨胀；状态变化一快，固定流程又容易失效。
3. Agent 化 MES：不是替代 MES，而是增加决策层
Business Goal
│
┌─────────▼─────────┐
│ Control Plane │
│ Goal / Policy / │
│ Approval / Plan │
└─────────┬─────────┘
↓
┌──────────────────┐
│ Agent Runtime │
│ Planner / │
│ Executor / │
│ Verifier / │
│ Optimizer │
└────────┬─────────┘
↓
Event Bus
┌───────────────┼───────────────┐
↓ ↓ ↓
Demand Agent Production Agent Supplier Agent
└───────────────┼───────────────┘
↓
MES / WMS / SCM / ERP
↓
Factory / IoT / PLCAgent 不应该取代 MES。 MES 继续负责确定性执行、状态记录、工艺与生产过程管理；Agent 在其上方负责动态决策。
4. 不应该先设计“岗位 Agent”，而应该先设计“决策 Agent”
一个容易走偏的方式是设计“供应商经理 Agent”“生产经理 Agent”“仓库经理 Agent”。但岗位实际上包含：
Routine
Decision
Communication
Judgement
ResponsibilityAgent 最先适合接管的是 Routine + Decision，而责任、重大判断和高风险授权并不会自动消失。
所以更好的拆法是：
Supplier Manager
├── 找供应商
├── 比较供应商
├── 判断交期
├── 监控质量
├── 处理异常
└── 调整订单
↓
Supplier Discovery Agent
Supplier Matching Agent
Supplier Monitoring Agent
Supplier Recovery Agent不是替代一个职位，而是拆解一个职位中的决策单元。
5. 哪些工作最值得 Agent 化？
| 工作类型 | 随机性 | 组合复杂度 | 可验证性 | 更适合的形态 |
|---|---|---|---|---|
| 数据录入 | 低 | 低 | 高 | Automation |
| 固定工艺流程 | 低 | 低 | 高 | Workflow |
| 生产排产 | 中 | 高 | 高 | Agent |
| 供应商匹配 | 高 | 高 | 中高 | Agent |
| 物料调度 | 高 | 高 | 高 | Agent |
| 异常恢复 | 高 | 高 | 中高 | Agent |
| 质量分析 | 中高 | 高 | 高 | Agent + Model |
| 需求预测 | 高 | 高 | 中 | Agent + Model |
| 重大采购/安全决策 | 高 | 高 | 低 | Human + Agent |
最应该 Agent 化的，不一定是人数最多的岗位，而是“决策密度最高”的岗位。
6. 随机性与组合复杂度，是两个重要坐标轴
前面的判断还需要补充部署条件：状态必须可观测，系统必须提供可执行接口，结果必须能够归因，权限和风险必须可控，预期收益还要覆盖模型、集成、错误补偿与治理成本。高复杂度只是必要线索，不是充分条件。
Decision Complexity
↑
Human │ Agent + Human
│
战略决策 │ 高风险异常
重大采购 │ 新产品
安全 │ 重大质量
│
───────────────────────────┼────────────────────→ Randomness
│
Workflow │ Agent
│
数据录入 │ 排产
固定审批 │ 调度
固定工艺 │ 异常处理
│ 供应商匹配
│ 库存优化最适合 Agent 的，不是简单的高随机性，而是：高随机性 + 高组合复杂度 + 快速反馈 + 可验证结果 + 可观测、可执行且风险可控。
可以把 Agent 化的经济边界粗略写成：
可获得的决策收益
+ 响应速度收益
+ 反馈闭环收益
>
模型成本
+ 集成成本
+ 错误与补偿成本
+ 治理成本这不是精确的财务模型，但可以提醒我们：规则很多并不自动意味着 Agent 更经济。
7. Agent 最有价值的地方：处理异常
现实生产中，正常路径往往并不难。真正昂贵的是订单延迟、材料缺货、机器故障、质量下降、供应商拒单、物流延迟、需求突然上涨。
Normal
↓
Event
↓
Re-plan
↓
Execute
↓
Verify
↓
Continue因此 Exception Agent 可能比“MES Copilot”更接近制造 Agent 的核心价值。
8. Event Bus 会成为 Agent Manufacturing 的神经系统
Event Bus
│
┌───────────────┼───────────────┐
↓ ↓ ↓
Demand Agent Production Agent Supply Agent
│ │ │
└───────────────┼───────────────┘
↓
Decision
↓
Action
↓
Verification
↓
New Event事件可以是 DemandChanged、OrderCreated、MaterialDelayed、FactoryCapacityChanged、QualityDegraded、ShipmentDelayed、InventoryLow。
Event → Agent → Action → Verification → Event
但生产系统不能只靠事件触发和 Agent 自由协作。Runtime 还必须提供状态存储、事件溯源、幂等执行、任务优先级、权限审批、超时处理、补偿事务和决策审计，否则多个 Agent 可能重复执行、互相覆盖，甚至形成事件循环。事件总线负责传播变化，Control Plane 负责决定谁可以在什么条件下采取什么动作，Execution Plane 负责把获批动作可靠地落到业务系统。
9. Demand Agent：决定“应该生产多少”
Demand Agent 持续观察销量、点击、收藏、搜索、转化率、库存、历史数据、季节和营销活动。预测结果不应该只有一个数字，还应该有置信度和验证方式：
forecast: 3000
confidence: 0.83
verification:
- future_sales
- inventory_turnoverAgent 的判断不仅要有结果，还应该有置信度和验证方式。预测不是事实，后续反馈能否证明它才重要。
10. Production Agent：决定“怎么生产”
假设需求是 3000 件，系统存在多个供应商、产能、质量、交期和成本约束。Agent 可以生成候选方案，再交给确定性的工具验证：
LLM
↓
生成 Plan
↓
Simulator
↓
Constraint Checker
↓
Business Rules
↓
Optimizer
↓
ExecuteAgent 是 Planner，而不是最终真相。
11. Supplier Agent：从供应商管理走向供应商智能网络
传统系统记录供应商；Agent 可以持续维护 capacity、quality、delivery、price、response speed、historical success、current workload、machine capability，从“有哪些供应商”进一步变成“当前这个订单，在当前约束下，谁最适合生产”。
12. 人机分工：风险越高，越需要 Approval Gate
Low Risk
Agent → Execute
Medium Risk
Agent → Verify → Execute
High Risk
Agent → Proposal → Human Approval → Execute重大质量事故、重大采购、重大供应商变更、安全相关操作和高额不可逆操作，不应该因为 Agent 出现就取消人工责任。
13. Manufacturing Agent Runtime：最终业务架构
Business Goal
│
↓
┌──────────────────┐
│ Control Plane │
│ Demand │
│ Production │
│ Supply │
│ Inventory │
│ Policy │
│ Approval │
└────────┬─────────┘
↓
┌──────────────────┐
│ Agent Runtime │
│ Planner │
│ Executor │
│ Verifier │
│ Optimizer │
│ Memory │
└────────┬─────────┘
↓
Event Bus
│
┌──────────────────┼──────────────────┐
↓ ↓ ↓
Demand Agent Production Agent Supplier Agent
↓ ↓ ↓
Inventory Agent Quality Agent Logistics Agent
└──────────────────┼──────────────────┘
↓
┌──────────────────┐
│ Execution Plane │
│ MES / WMS / ERP │
│ SCM │
└────────┬─────────┘
↓
Factory / IoT / PLC
│
└──── Event ────→工程判断：在这套目标架构中，MES 的位置发生变化：它仍然非常重要，但不再是整个业务决策系统的最高层。它更像 Execution Plane；Agent Runtime 成为 Decision + Reconciliation Plane。
14. K8s 类比：制造系统也可以拥有 Desired State
Production Target
↓
Factory Reality
↓
Gap
↓
Agent Controller
↓
Re-plan
↓
Execute
↓
Verify
↓
Gap例如一个生产目标可以表达为 SKU、数量、deadline、quality、cost 等约束。现实世界不断变化，因此制造 Agent 的核心能力之一，可以理解为持续把现实生产状态向业务目标收敛。
15. 但制造世界比 K8s 更复杂：重试不等于重启
K8s 可以重启 Pod，但生产系统里的动作可能产生不可逆副作用：已经发货、已经采购、已经投料、已经生产、已经付款。此时 Agent 发现目标没有达成，不能简单 retry，而可能需要补偿、审批升级、重新排产、回滚业务状态或停止执行。
Manufacturing Agent 的 Reconciliation 必须理解业务副作用。
16. 三条环：Execute / Eval / Learn
Execute Loop
秒 → 小时
Goal → Plan → Act → Observe → Adjust
Eval Loop
小时 → 天
Trajectory → Outcome → Evaluation → Gate
Learn Loop
天 → 周
Evidence → Policy → Optimization → RolloutExecute Loop 解决当前订单怎么完成；Eval Loop 判断方案到底有没有真的成功；Learn Loop 把历史失败和成功证据沉淀为下一轮策略。
17. 真正值得讨论的，不是“AI 替代多少人”
如果只从岗位出发，我们会问“生产经理会不会被 Agent 替代”。更有架构意义的问题应该是：生产经理今天到底在做哪些决策？哪些决策可以被结构化？哪些决策可以被验证？哪些决策的组合空间正在爆炸？哪些决策的反馈周期足够短？
岗位
↓
工作
↓
决策单元
↓
Decision Agent
↓
Policy
↓
Tool
↓
VerificationAgent 不一定直接“替代一个人”，而可能先替代一个人的一部分决策循环。随着验证能力越来越强，这些决策循环逐渐扩大。
18. 一个暂时结论
Agent
= Manufacturing Decision Controller
MES
= Execution System
Event Bus
= Nervous System
IoT
= Sensors
Factory
= Actuators
Control Plane
= Business Goal + Policy + Scheduling
Agent Runtime
= Observe → Decide → Act → Verify → Reconcile这里的 Controller 指制造业务的动态决策控制层，而不是 PLC、DCS 或安全联锁意义上的实时设备控制器。实时控制和安全边界仍应由确定性的工业控制系统负责。
因此未来的 Manufacturing Agent 不应该只是：
MES + LLM更可能是：
MES
+
Event System
+
Agent Runtime
+
Optimization
+
Verification
+
Human Approval不要替代岗位，要替代决策单元。
真正决定 Agent 是否有价值的，不是“它像不像一个人”，而是：它能不能在高频、随机、组合复杂的现实环境中，持续做出决策，并通过真实结果验证自己，再进入下一轮。
开放问题
- 哪些制造决策的反馈周期足够短，可以形成真正的 Agent Loop？
- 排产、供应商匹配、库存、物流之间的 Agent 应该独立运行，还是共享一个 Planner？
- 什么样的 Simulator / Constraint Checker 才能成为 Agent 的“现实世界测试”？
- 哪些 Outcome 可以机器验证，哪些必须保留人工验收？
- 当一个 Agent 可以处理越来越大的决策空间时，岗位边界会如何重新组织？
- Manufacturing Agent Runtime 是否最终会像 Kubernetes 一样形成自己的 Control Plane、Runtime、Scheduler、Policy、Event 与 Reconciliation 体系？