让 Agent 进入企业，而不是让企业重新造一套系统
过去十几年，工业企业数字化做了一件非常重要的事情：把业务搬进系统。
订单进入 ERP，生产进入 MES，库存进入 WMS，质量进入 QMS，供应商进入 SRM，设备状态进入 IoT 平台。
所以今天很多大型制造企业并不是“没有系统”。恰恰相反，它们往往拥有非常庞大、复杂的信息化基础设施。
但一个很有意思的问题也随之出现了：系统越来越多，业务人员却没有因此变得越来越轻松。
原因并不难理解。真正复杂的工业业务，很少只发生在一个系统里。
一笔 72 小时紧急订单
假设一家汽车零部件企业，已经完成了比较完整的数字化建设。
某个周一上午 9 点，销售突然带来一个消息：一个核心客户追加 20,000 件订单，要求 72 小时内交付。
从业务人员的角度看，这可能只是一个订单。但到了生产经理这里，问题完全变了。
ERP 里已经有一批正常订单；MES 显示主要产线处于高负荷状态；WMS 显示部分关键原材料库存不足；SRM 显示一批物料正在运输；QMS 刚好有一个批次存在质量风险；IoT 数据又显示某条产线最近的实际产能低于理论产能。
所以生产经理真正需要回答的问题并不是“怎么把这张订单录进 ERP”，而是：“这 20,000 件到底能不能接？”
如果必须 72 小时交付：“需要调整哪些订单？需要增加什么资源？有什么风险？”
过去，这类问题通常依靠一个经验丰富的生产经理，甚至一个团队来解决。他们打开 ERP，再打开 MES，再查 WMS，再找采购、质量，最后把数据导入 Excel，开会、讨论、制定方案。
数字化系统已经记录了大量事实，但真正把这些事实串联起来形成业务判断的，仍然是人。
这恰恰是工业 Agent 最值得进入的地方。
一、先解决业务目标，再谈 Agent 平台
工业企业最容易走入的误区，是先建设一个庞大的 Agent Platform，再去寻找业务场景。更合理的路径恰恰相反：先选择一个真实业务闭环，再从闭环中抽象平台能力。
在这笔紧急订单里，第一阶段只做一个“订单交付保障 Agent”。它的目标非常明确：判断 20,000 件订单能否在 72 小时内交付，并给出可执行方案。
这样一来，Agent 从第一天面对的就不是一个 Demo，而是一个真实的 Business Objective。它必须综合订单、生产、库存、供应链、质量和设备状态，最终对一个业务问题给出判断。
二、现有 ERP、MES 不动：先在系统之上增加智能层
工业企业已经拥有大量成熟的信息化基础设施。ERP、MES、WMS、QMS、SRM 和 IoT 中保存着企业事实、业务规则与执行能力。Agent 没有必要重新发明这些系统。
在这笔订单中，ERP 提供订单与交付信息，MES 提供生产进度与产能，WMS 提供库存与齐套情况，SRM 提供供应商与在途信息，QMS 提供质量状态，IoT 提供设备运行状态。
因此，第一阶段不是替换 ERP/MES，而是在它们之上增加 Agent 智能层。原有系统继续承担 System of Record 和 System of Execution 的角色，Agent 则负责理解业务目标、组织上下文并进行决策。核心架构可以概括为：ERP / MES / WMS / QMS / SRM / IoT → Agent 智能层。
三、从 API 到 Business Capability：Agent 应该理解企业能做什么
仅仅把大量 API 接给 Agent 还不够。如果 Agent 看到的是 getOrder、getInventory、getProductionStatus、updateProductionPlan 等技术接口，它获得的只是“工具”，并没有真正理解企业业务
因此，需要在 Agent 与现有系统之间建立 Business Capability Layer。让 Agent 面向的是“查询生产能力”“判断物料是否齐套”“评估交付风险”“模拟生产方案”等业务能力，而不是底层数据库表和技术 API。
MCP 可以成为标准化的能力接入方式，但 MCP 本身不是工业 Agent 架构的核心。真正应该沉淀的是 Business Capability：企业究竟能够为 Agent 提供什么业务能力，以及这些能力具有什么业务规则、权限和风险边界。
四、让 Agent 理解流程：Workflow 管边界，Agent 做动态决策
订单交付保障通常包含订单评估、产能检查、物料检查、质量检查、供应链检查、交付风险评估、方案生成、审批、执行和结果验证。这些关键节点不能完全交给模型自由发挥，因此需要 Workflow 负责定义业务骨架、必经节点、审批节点和不可跳过的规则。
但 Workflow 也不能把所有情况写死。例如发现 M01 物料不足后，到底应该查询其他仓库、寻找替代物料、等待在途物料，还是重新计算交付时间，需要 Agent 根据实时上下文进行判断。
因此可以形成一个核心原则：Workflow 管边界，Agent 在边界内进行动态决策。
五、Data、Knowledge 与 Memory：Agent 到底在理解什么
Agent 分析这笔订单时，需要的不只是一个数据库，而是一组与当前业务任务相关的上下文。Business Data 告诉 Agent 企业现在和过去发生了什么；Knowledge 告诉 Agent 企业允许怎么做；Memory 保存当前任务的运行状态；Experience 则来自历史任务中经过验证的经验。
例如，Data 告诉 Agent 当前库存只够 8,000 件，Knowledge 告诉 Agent M01-A 可以作为替代物料但必须经过质量确认，Memory 则记录 Agent 已经完成库存分析、正在进行产能评估。
因此，工业 Agent 不应该把事实、规则、运行上下文和经验全部混进一个 RAG 知识库。它们需要在架构上被区分。
六、第一次真正完成业务判断：从“回答问题”到“给出方案”
综合 ERP、MES、WMS、SRM、QMS、IoT 和企业知识后，Agent 最终可以形成多个候选方案：方案 A，72 小时交付，但需要调整 3 张既有订单；方案 B，84 小时交付，不影响现有订单；方案 C，72 小时交付，但需要紧急采购并增加生产资源。
此时 Agent 已经不再只是回答“库存还有多少”，而是在回答：“为了实现业务目标，现在有哪些可行路径？”这就是 Agentic Decision Making 真正进入工业业务的时刻。
但问题也随之出现：Agent 已经知道应该怎么做，它有资格做吗？这将成为下篇《从“会判断”到“能执行”：Agent 如何走向 Enterprise Agent OS》的起点。
