《AI原生生产运营系统白皮书》|第四章 AI 原生生产运营系统总体架构

4.1 架构问题：为什么“接入模型”不足以形成生产级系统

当企业尝试把 AI 引入生产运营时，最常见的做法是把模型接入报表、知识库、工单或某个业务界面。这类能力可以改善查询、总结、文档理解和局部分析，却无法自动形成生产级系统。

原因在于，生产运营中的行动具有真实后果。一次计划调整会改变资源占用与客户承诺；一次物料替代会影响质量责任与追溯；一次维护窗口变更会影响设备可靠性和现场安全。模型可以帮助理解问题、生成方案和解释取舍，但不能天然证明它读取的是正确事实，也不能天然保证其行动符合权限、硬约束和事务一致性。

因此，AI 原生生产运营系统必须回答的不是“模型放在哪里”，而是：

• 业务目标由谁设定，风险由谁接受？
• 多个数字主体基于什么共同事实协同？
• 主体调用哪些能力、受到哪些权限和安全约束？
• 候选方案如何变为被批准的行动意图？
• 哪一层重新校验事实、规则与并发冲突，并决定是否提交事务？
• 既有 ERP、MES、APS、EAM、WMS、QMS、SCADA、PLC 与安全联锁如何被继承，而非被绕过？

这些问题共同决定了系统架构。AI 原生系统不是传统系统旁边的一层“智能应用”，而是把目标、认知、协同、能力、事务和现场执行重新组织为一个受治理闭环。

4.2 六层总体架构

本白皮书采用六层架构。它们并非自上而下的单向控制链，而是在“目标—认知—行动—反馈”循环中承担不同责任。

图中的事件与数据采集不构成独立的“第七层”。它们通过工业连接平台进入世界模型，并以来源、时间、质量和版本信息被纳入共同事实。没有可靠的事实输入，主体只能基于不确定上下文生成建议；没有事务与控制边界，建议又无法安全影响现实。

为避免把该图误读为“上层命令下层”的单向堆栈，还应区分四条横向流：事实流从既有系统和现场经连接平台进入世界模型；能力流由 Skill、Memory 和工具目录按授权提供给主体；意图流从主体经 Runtime、协同与审批形成受治理意图；事务与反馈流由执行引擎提交至既有系统，再将实际确认、失败和补偿结果回写世界模型与治理层。世界模型为所有主体提供共同引用，而不是位于能力资产之下的被动数据库；事务引擎是进入现实前的校验边界，而不是替代下游系统的业务库。

六层的主要职责如下：

4.3 人类治理与价值目标：架构的起点与上限

任何生产运营系统都在执行某种价值取舍。提高交付速度可能增加加急成本或设备风险；降低库存可能损害供应韧性；提高设备利用率可能与维护、质量和能耗目标冲突。模型不能自行决定这些取舍的正当性。

因此，人类治理层是架构的起点。它至少要明确：

• 企业在安全、质量、交付、成本、能耗、韧性和公平性之间的优先级；
• 哪些规则属于绝对禁止，哪些属于可在授权下权衡的软约束；
• 哪类主体可以建议、可以在审批后执行、可以在限定条件下自动提交事务；
• 哪些异常必须升级给质量负责人、设备负责人、生产负责人或经营管理者；
• 当事实不足、模型失准、系统异常或现场风险上升时，如何暂停、接管和复盘。

人类治理不等于在每个按钮前人工确认。对于低风险、可逆、规则充分且证据完整的动作，频繁人工确认反而会把系统重新退化为手工工作流。治理的目标是把人的责任转化为明确的目标、规则、授权和升级条件，使系统能够在边界内稳定运行，并在边界外可靠地停止和求助。

4.4 数字智能组织层：谁对业务目标负责

数字智能组织层由多个 Digital Subject 构成。它们不按软件菜单划分，而按稳定的业务责任域划分。例如：

• 订单主体对交付承诺、客户优先级和订单风险负责；
• 计划主体对产能、工艺路线、资源窗口和计划可执行性负责；
• 物料主体对齐套、批次、库存、供应风险和领用约束负责；
• 设备主体对设备能力、健康、维护兑现和安全约束负责；
• 质量主体对合格性、偏差、放行、隔离和追溯负责；
• 能源与安全主体对能源约束、现场风险和不可突破的运行边界负责。

主体的责任并不意味着主体拥有全部权力。订单主体可以提出保交付方案，却不能自行修改质量放行；设备主体可以提出维护窗口调整，却不能绕过安全联锁；质量主体可以冻结不合格批次，却不能独自决定经营层面的客户承诺。主体之间需要依靠世界模型、协同协议和治理规则形成共同方案。

这一层的产物不是直接控制指令，而是带有目标、事实依据、约束、候选方案、风险、有效期和责任归属的受治理行动意图。它构成从智能认知进入确定性执行的桥梁。

4.5 Industrial World Model：系统如何形成共同认知

数字组织若没有共同现实，就无法可靠协同。订单主体、设备主体和质量主体各自拥有不同上下文时，可能分别给出合理却彼此冲突的建议。Industrial World Model 的任务，是将生产事实、关系、约束、事件、预测与情景组织为可追溯的共同认知。

世界模型至少要表达：

• 实体与状态：订单、产品、物料、批次、工艺、设备、人员、任务、能耗和质量记录当前是什么；
• 关系与约束：哪些订单依赖哪些物料和设备，哪些批次可替代，哪些工艺、质量、安全和法规规则不可违反；
• 事件与时间：什么变化发生在何时、来自何处、影响哪些对象，当前事实是否仍然新鲜；
• 预测与情景：未来可能发生什么、某候选行动可能造成什么影响，以及该判断的模型、假设和置信度；
• 证据与版本：任何事实、预测、方案和结果都能回溯到来源、版本、质量和责任。

世界模型不等于数据湖、数据仓库或数字孪生看板。后者可以提供数据集成和可视化，但不必支持事实与情景的隔离、约束关系的计算、影响传播或面向行动的证据链。第五章将专门展开其设计与运行方式。

4.6 Skill、Memory 与工业连接平台：主体凭什么解决问题

主体要承担业务责任，不能只依赖通用模型的语言能力。它需要调用经过验证的专业能力、利用可追溯的组织经验，并以受控方式连接既有系统和现场工具。

Skill 承载排程优化、物料齐套分析、设备诊断、质量风险评估、仿真推演、规则校验、SOP 查询和数据分析等可评估能力。Memory 承载经过治理的案例、策略、历史结果和专家经验。工业连接平台则连接 ERP、MES、APS、EAM、WMS、QMS、数据服务、设备系统和外部生态工具，并提供身份、凭证隔离、最小权限、调用审计、限流、重试和故障降级。

这三类能力都必须服务于主体的授权目标，而不是成为无边界工具库。一个主体调用某项 Skill 前，应当知道该 Skill 的输入、输出、适用条件、版本和失败处理；调用系统接口时，应当受到范围、凭证、频率和结果验证的约束。

MCP 可以作为主体发现和受控调用工具的一种机制，但它不等同于企业集成总线、ESB 或工业控制协议。ESB 与集成平台继续承担企业系统之间稳定的数据与服务连接；工业协议与控制系统继续承担设备通信和现场安全；MCP 只解决主体如何在既有边界内识别、选择和调用被授权工具。

4.7 Agent Operating Runtime：主体如何持续运行

如果没有运行时，Agent 往往只是被某个页面、工作流或 API 临时触发的一段功能。它缺少长期身份、生命周期、受控上下文、策略执行、故障恢复与协同状态，也难以在异常后解释“它曾经依据什么、尝试过什么、现在能否继续”。

Agent Operating Runtime 是数字组织的运行底座。它负责：

• 创建、调度、暂停、恢复、终止与转交数字主体；
• 维护主体的任务状态、事实版本、上下文、预算、时限和工具调用记录；
• 将权限、策略、自治等级、人工确认和安全规则落实为运行时拦截条件；
• 支持主体间委派、协商、冲突检测、撤销与升级；
• 在工具失败、数据过期、模型异常或下游系统不可用时冻结、降级或恢复；
• 生成贯穿主体、Skill、事实、方案、审批和事务的审计证据。

Runtime 不取代世界模型或事务引擎。它不负责宣称某个事实为真，也不负责绕过业务系统写入生产状态；它负责让主体在既定的事实、能力和治理条件下稳定、可观察地运行。第九章将讨论这一层的状态机与故障处理机制。

4.8 Transaction Execution Engine：智能如何保持确定性

从数字组织到生产现实之间必须存在可信边界。主体形成的只是一项受治理意图，例如“在某事实版本下，将订单 A 的一项工序调整到资源 R，并为替代批次创建验证任务”。该意图不能因为来自模型或高优先级主体，就被直接写入 MES、APS、EAM 或其他系统。

Transaction Execution Engine 在提交时重新执行确定性校验：

1. 行动意图是否仍基于有效的事实版本？
2. 发起主体和批准者是否拥有相应权限？
3. 是否违反质量、安全、库存、工艺、法规或资源硬约束？
4. 是否与其他已提交或正在执行的事务发生并发冲突？
5. 下游系统是否可用，所需操作是否支持幂等、确认、补偿与回退？

只有通过这些检查，意图才能转化为确定的生产事务。若校验失败，引擎应拒绝、冻结、请求重新规划或发起人工升级；若下游执行失败，应记录实际状态并按预定补偿或回退机制处置。

事务执行引擎并不取代 MES、ERP、EAM 等系统的内部事务能力，而是将智能协同产生的意图纳入一致的企业级执行边界。它也绝不能替代 PLC、安全联锁或实时控制逻辑。第十一章将进一步展开其运行机制。

4.9 一次生产行动如何穿过六层架构

以“重点订单缺料并面临设备维护窗口”为例，完整闭环如下：

这个闭环体现了架构的基本原则：智能层负责把复杂变化转化为可解释方案；确定性层负责验证、记录和提交行动；控制层负责安全、实时地作用于物理世界；人类治理层负责定义目标、授权例外和处理超出系统边界的风险。

4.10 与既有系统的关系：继承、重构而非旁路替换

AI 原生生产运营系统的建设不应导致原有系统“被架空”。相反，既有系统的能力应在新的架构中获得更清晰的定位：

因此，架构重构的重点不是另建一套影子业务系统，而是把既有系统的权威事实、专业能力和确定性执行能力纳入数字组织的共同闭环。任何绕过这些系统的“快速自动化”都可能造成状态不一致、责任不清或现场风险。

4.11 本章结论

AI 原生生产运营系统以六层架构组织目标、责任、共同认知、专业能力、运行时控制和确定性执行。其核心不是增加一个大模型层，而是建立从人类目标到数字主体协同、再到受治理事务和现场反馈的完整链路。

在这套架构中，Industrial World Model 解决共同现实问题，Digital Subject 与多主体组织解决责任和协同问题，Skill、Memory 与连接平台解决能力与复用问题，Runtime 解决持续运行问题，Transaction Execution Engine 解决安全进入现实的问题。第五章将从共同现实出发，进一步展开 Industrial World Model 的具体设计。