《AI原生生产运营系统白皮书》|第二章 从 Object System 到 Subject System

2.1 企业软件的核心抽象正在发生变化

本章回答的是生产运营软件的基本抽象为何需要扩展：对象系统能够表达什么，数字主体又新增了承担什么责任。主体如何被设计、运行、治理和验收，则分别由第六章、第九章和第十三章展开。

软件工程的发展，本质上是人类持续寻找更有效的方式描述、控制和改进现实世界。过去几十年，企业软件形成了一套极其成熟的方法：把现实业务抽象为对象，把对象的变化表达为状态，把稳定经验固化为规则，再把规则组织为能够被系统推进的流程。

这一方法支撑了 ERP、MES、APS、EAM、WMS、QMS 和大量行业系统的发展。它让企业可以用统一的对象模型管理订单、产品、物料、设备、人员、批次、仓位、质量记录和财务责任；也让审批、领料、报工、检验、入库、发运和维护等活动具备一致、可追溯的执行方式。

在这一体系中，软件最基本的单元是：

对象（Object）。

对象代表现实世界中被系统管理的实体。它有属性、有状态、有生命周期，也会受到规则与流程约束。传统企业软件正是通过维护大量对象的正确状态，来维持企业运行的秩序。

这种体系可以称为 Object System（对象系统）。它并不是落后的设计，而是工业数字化的确定性底座。问题在于，当业务的关键难题从“如何准确记录和执行既定流程”转向“如何在持续变化中协调多个目标”时，仅由对象、规则和流程构成的抽象开始出现边界。

AI 原生系统的变化，并不是放弃对象系统，而是在其之上引入新的基本单元：

主体（Subject）。

主体不是被动地拥有状态，而是围绕目标理解环境、调用能力、提出行动、接受反馈并承担责任。Object System 让现实世界可被数字化管理；Subject System 则让数字系统能够以受治理方式参与复杂生产运营。

2.2 Object System：数字世界对生产现实的第一次抽象

传统系统最重要的贡献，在于第一次让复杂生产过程成为可计算、可审计的对象网络。

以一个制造订单为例，现实中的订单不仅包含客户需求，还隐含交付承诺、产品配置、工艺要求、资源占用、质量责任和变更历史。系统会将这些信息抽象为订单对象：

Production Order
{    Order_ID,    Product,    Quantity,    Due_Date,    Routing,    Priority,    Status}

同样，物料会被抽象为库存、批次、质量状态和可用性；设备会被抽象为能力、位置、运行状态、维护计划和告警；质量对象会保存检验规范、结果、偏差、隔离与放行记录。

Material Lot
{    Material_ID,    Lot_ID,    Quantity,    Location,    Quality_Status,    Expiry_Date}
Equipment Asset
{    Asset_ID,    Capability,    Current_State,    Health_Status,    Maintenance_Window}

当这些对象被建立并持续更新后，企业就能够回答大量关键的确定性问题：

• 某订单是否已经下达、开工、完工或发运？
• 某批物料是否在正确库位、满足质量要求并可被领用？
• 某设备是否可用、处于何种维护状态、是否存在禁止作业的告警？
• 某产品的质量放行是否完成，某次操作是否满足工艺和人员资质要求？

从系统视角看，生产运营就是对象状态不断变化的过程。状态变化由事件触发，受业务规则校验，并通过工作流与事务被写入系统。

事件发生   ↓对象状态更新   ↓规则校验   ↓流程推进   ↓事务确认与记录

例如，一批物料到货后，仓储系统接收收货事件；物料对象从“在途”变为“待检”；质量系统完成检验后，将质量状态改为“可用”或“隔离”；当生产订单申请领料时，系统依据批次、先进先出、有效期、质量状态和库存规则进行校验，再创建相应的领料事务。

这种机制的优势非常明确：它稳定、可靠、可预测，并且能够在高并发业务中保持记录与责任的一致性。对于任何涉及库存、质量、成本、合规、设备控制和安全联锁的生产活动，Object System 仍然是不可缺少的基础。

2.3 Object System 的能力边界：状态正确不等于决策正确

对象系统能够精确回答“现在是什么”，但复杂生产常常需要回答“接下来应该做什么”。这两类问题并不相同。

假设系统已经知道：

• 订单 A 的交付日期是本周五；
• 关键物料 B 还差一批，预计明日到货；
• 瓶颈设备 C 当前可用，但将在两天后进入维护窗口；
• 替代物料 D 存在，但尚需质量确认；
• 另一订单 E 也占用了同一设备和工艺路线。

这些信息都可以被传统系统准确记录。真正困难的问题却是：在订单 A、订单 E、设备维护、物料到货和质量验证相互制约时，企业应当如何行动？

一种做法是维持原计划，等待物料到货；另一种是调整订单顺序；第三种是申请替代物料验证；第四种是重新协调设备维护窗口。每种方案都可能在局部看来合理，却在交付、成本、设备风险、质量和后续订单上产生不同后果。

对象本身没有目标，也不会对这些目标进行权衡。订单对象知道交付日期，但不会天然理解“在不突破质量与安全边界的条件下，应优先保护哪一项承诺”；设备对象知道维护窗口，但不会天然理解“延期维护是否会对全局风险产生不可接受的影响”；物料对象知道库存数量，但不会天然判断“把这批料分给哪个订单能够降低整体违约风险”。

传统软件当然可以配置规则、优化算法、预警和工作流。它们在确定场景中非常有效。但复杂生产中的关键判断通常包含以下要素：

因此，Object System 的边界并不意味着对象模型错误，而是说明对象模型无法独自承担组织责任。系统需要一个能够围绕目标运行、理解上下文、调用专业能力和接受反馈的责任单元。

2.4 人类组织为什么天然具有 Subject 属性

在没有数字智能组织的生产现场，真正承担“下一步怎么办”责任的始终是人。人不是对象；人是主体。

以计划主管为例。他的职责不是简单执行排程结果，而是在交付、产能、物料、设备和质量约束之间维持整体生产承诺。他拥有一个明确目标：在不突破质量、安全和资源边界的前提下，保障订单交付和生产连续性。

当重点订单出现缺料风险时，他会读取来自各部门的事实，形成态势判断：订单是否真的会延误？物料到货预测是否可信？设备维护是否可调整？替代方案是否已经获得质量认可？另一订单是否存在更大的违约风险？

他会基于经验和专业工具提出方案，向物料、设备、质量和生产团队请求资源或确认约束；在权限不足时，他会上报生产负责人或经营管理者；方案执行后，他还会根据实际结果修正下一次计划判断。

这构成了一个完整闭环：

目标  ↓对环境的认知  ↓判断与方案  ↓协同与行动  ↓结果反馈  ↓经验修正

人类主体与业务对象的根本差异在于：对象主要拥有状态；主体拥有目标、认知、行动能力和责任边界。主体不会因此脱离规则，相反，专业主体的价值正体现在理解规则为何存在、何时必须遵守、何时需要请求例外，以及如何对后果负责。

AI 原生系统并不是试图把人简化为一个可被替代的“Agent”。它要做的是为软件提供承载主体能力的技术结构，使已经存在于计划、物料、设备、质量和安全组织中的部分认知、协同与经验，能够被清晰表达、验证和复用。

2.5 Subject System：以数字主体承载业务责任

Subject System 的基本单元不是功能模块，而是数字主体。一个数字主体围绕特定责任域长期运行：它有明确目标，能在授权范围内观察世界模型，调用已批准的 Skill、工具和规则，向其他主体提出请求或承诺，并把行动结果留在可审计的证据链中。

例如，订单主体不等于“订单查询模块”。它对订单承诺风险负责，需要理解订单的交付目标、当前计划、物料齐套、设备能力、质量限制和客户优先级；它能够请求计划主体重新比较排程方案、请求物料主体评估齐套与替代方案、请求设备主体评估维护风险，并将获得的方案提交给有权决策者或事务引擎。

同样，设备主体不等于“设备状态接口”。它对设备能力、健康、维护兑现和安全约束负责。它可以解释一项设备风险如何影响订单计划，提出维护窗口方案或资源替代建议；但它不能自行绕过 EAM、SCADA、PLC 或安全联锁改变设备控制状态。

因此，Subject System 的关键不是让所有对象都变成会对话的 Agent，而是明确：哪些责任域需要一个能够持续认知、判断、协同和受治理行动的数字主体；哪些事务仍应由传统对象与确定性系统承载。

这也决定了两种系统的关系：

Subject System 不取代 Object System 的确定性职责。数字主体不能凭借“更合理的推理”修改库存、绕过质量放行、覆盖主数据、改变控制参数或忽略安全联锁。它只能在已定义的业务目标、事实范围、权限和工具边界内形成行动意图，并通过事务与控制链路使意图获得验证和执行。

2.6 Digital Subject：生产级数字主体的六要素

一个生产级数字主体不能只包含提示词和工具列表。它必须形成完整的业务闭环。本白皮书采用以下模型：

Digital Subject =Goal + Belief + Memory + Skill + Action + Reflection

六个要素应作为同一模型连续设计，任何一个要素缺失，主体都会退化为临时分析工具或不可治理的自动化脚本。

Goal：业务目标与责任边界。

Goal 定义主体为什么存在。订单主体的目标不是“尽快完成订单”，而是“在质量、安全、资源和授权边界内，保障经确认的交付承诺”。设备主体的目标不是“最大化设备利用率”，而是“在安全和维护约束内维持设备能力，并把设备风险对生产承诺的影响透明化”。

目标必须同时包含优化方向和不可突破的边界。否则，主体可能为了局部指标而牺牲质量、安全、长期设备健康或其他订单的公平性。目标还必须有责任归属、适用范围和优先级来源，不能由模型在运行中自行发明。

Belief：基于证据的态势认知。

Belief 不是对数据的简单读取，而是主体基于事实、关系、约束、预测和上下文形成的、可被质询的工作判断。

例如，数据可能显示“某关键物料库存为零，预计明日到货”；订单主体的认知则可能是“若该到货预测未实现，订单 A 将在瓶颈工序前发生缺料；当前仍存在调整订单 E、验证替代批次或重排维护窗口三类可行路径”。

生产级 Belief 必须区分已确认事实与预测或假设，并携带来源、时间、置信度和适用条件。它不能覆盖世界模型的事实层，也不能把一次推演结果伪装成现场状态。证据不足、数据过期或事实冲突时，主体应降低建议置信度、请求核验或暂停推进高风险行动。

Memory：可追溯的组织经验。

Memory 解决的是“主体从哪些已验证经验中学习”。它包括经过治理的历史案例、已批准策略、专家判断、执行结果、异常模式和复盘结论，而不是把所有对话记录或历史日志无差别塞入检索库。

一条可复用的经验至少应保留：产生场景、当时事实与约束、采用方案、实际结果、适用条件、反例、来源角色、批准状态和有效期。例如，“在某类产品、某设备健康等级与某交付窗口下，允许先完成替代物料验证再调整计划”只能作为带条件的经验，不能被误用为所有缺料场景的普遍规则。

Memory 的新增、发布和淘汰都需要治理。现场人员的临时处置可以被记录为候选经验；只有经业务与技术评审、通过评测并定义适用边界后，才能进入主体的正式记忆或策略资产。当实际结果持续偏离预期时，该经验必须被降级、修订或撤销。

Skill：可评估的专业能力。

Skill 回答“主体能够用什么方法解决问题”。它可以是排程优化、物料齐套分析、设备健康诊断、质量风险评估、仿真模型、规则校验、SOP 查询或受控工具调用。

Skill 与大模型能力不同。前者必须具有明确输入、输出、适用范围、版本、性能评估和失败处理。一个“订单风险评估 Skill”应说明读取哪些经过授权的事实、使用何种规则或模型、给出何种风险解释和候选方案、在哪些数据质量或业务条件下不应使用。主体不能仅因一个 Skill 可被调用，就把结果视为可执行结论。

Action：受治理的行动能力。

Action 使主体能够影响业务，但行动并不等同于直接操作生产现实。主体可以查询系统、创建分析任务、发起协商请求、生成计划草案、提交审批、请求仿真、创建受治理的事务意图，或在已授权的低风险场景中调用确定性执行接口。

所有影响订单、库存、计划、质量状态、设备安排或现场资源的行动，都必须经过权限、规则、事实版本和事务边界校验。涉及设备控制、安全联锁、质量放行或不可逆责任的动作，必须由对应的专用系统和人类授权链路执行。没有这些边界的 Action，只会把分析工具错误地包装为生产系统。

Reflection：结果复盘与能力修正。

Reflection 让主体不只执行，还能判断执行结果是否达到目标。它会比较预测与真实结果、方案与实际约束、自动建议与人工修正，识别偏差来自数据质量、模型失准、规则遗漏、协同失败还是外部变化。

反思的输出不是立即修改策略，而是形成可审查的改进候选：可能需要补充一条数据质量规则、调整 Skill 的适用范围、更新 Memory、修订授权阈值，或把某类动作从 L2 降级为只能建议的 L1。只有经过相应评估和批准，改进才可发布。这样，主体的学习才是可控的组织学习，而不是不可追踪的自我变化。

2.7 场景：订单主体如何从对象状态走向受治理行动

继续以重点订单缺料风险为例。传统订单对象能够记录交付日期、数量、工艺路线和当前状态；订单主体则围绕交付承诺运行一个更完整的闭环。

首先，订单主体从世界模型读取已确认事实：订单状态、物料齐套、设备可用时段、质量状态、当前计划和客户承诺。它同时读取带条件的预测：到料时间预测、设备健康风险、替代物料验证周期和不同排程方案的预期影响。

其次，它形成一个可解释的 Belief：如果物料未按预测到货，订单将错过瓶颈工序窗口；若推迟设备维护，交付风险可能下降，但设备故障与安全风险上升；若使用替代批次，交付可以被保护，但必须先完成质量验证。

随后，订单主体调用已批准的 Skill，形成至少两个候选方案：

主体不会自动选择方案。它把方案、事实版本、假设、风险、权限需求和有效期提交给相关主体与人类责任人。质量主体可以声明替代批次的不可违反条件；设备主体可以说明维护延期的最大允许范围；计划主体可以评估对其他订单的连锁影响。经过协商、仿真或审批后，获批方案才成为可提交给 Transaction Execution Engine 的行动意图。

执行完成后，订单主体比较实际到料、质量验证、设备状态和交付结果与原有情景。如果人工否决了其建议，或预测与结果偏差显著，该差异会进入 Reflection 流程，而不是被简单忽略。经过审核后，相关经验才可能更新为新的 Skill 评测、Memory 条目或策略参数。

这个场景说明，订单对象仍然存在并承担状态与事务责任；订单主体则承担围绕订单承诺进行认知、协同和受治理行动的责任。二者缺一不可。

2.8 从模块化软件到数字组织的转变

传统生产运营系统通常按功能模块组织：订单管理、排程、物料管理、设备维护、质量管理、仓储管理等。这种划分描述的是“系统提供哪些功能”。

AI 原生系统增加了另一种组织方式：订单主体、计划主体、物料主体、设备主体、质量主体、能源主体和安全主体等。这种划分描述的是“谁对哪一类目标、约束和行动负责”。

两者不应被简单对立。功能模块继续提供数据、规则、算法、事务和接口；数字主体把这些能力组织为围绕目标运行的责任闭环。主体调用模块，但不等同于模块；模块可被多个主体使用，但不承担主体的业务责任。

这种变化带来三项设计要求：

1. 责任必须先于 Agent 数量。 企业不应先决定要部署多少 Agent，而应先识别哪些生产责任域需要持续的态势理解、跨域协同和可审计行动；
2. 目标必须先于提示词。 每个主体都需要明确目标、约束、权限、升级路径和验收口径，不能只以自然语言角色描述替代业务设计；
3. 事务边界必须先于自动化。 主体能够形成更好的方案，并不意味着它可以直接写入任何生产系统。所有现实影响都需要被确定性边界重新校验。

2.9 本章结论

Object System 使生产对象、状态、规则和流程成为可管理的数字资产，是生产运营不可替代的确定性底座；但它无法独自表达围绕目标进行认知、权衡、协同、行动和复盘的组织责任。

Subject System 在对象系统之上引入 Digital Subject，使订单、计划、物料、设备、质量等责任域拥有可解释、可治理的数字主体。数字主体不取代传统系统，也不获得无边界自主权。它以 Goal、Belief、Memory、Skill、Action、Reflection 构成受治理闭环，并通过事务、审批与工业控制链路把行动保持在可验证的生产边界内。

第三章将进一步讨论，当多个数字主体围绕共同目标、局部约束和共享事实协同运行时，为什么它们会形成一种新的软件组织形态：数字智能组织。