《AI原生生产运营系统白皮书》|第六章 Digital Subject:让软件承担业务责任

6.1 从概念模型到生产级责任单元

第二章已说明为什么软件需要从对象管理扩展到主体责任；本章只解决一个设计问题：如何把这一概念落实为可定义、可评测、可降级的生产级责任单元。多主体之间如何组织和通信，见第七章与第十章。

第二章提出，Digital Subject 由 Goal、Belief、Memory、Skill、Action 和 Reflection 构成。这一模型说明数字主体为什么不同于对象、模块或聊天机器人。但在生产环境中，仅有六项概念还不够：企业还必须决定哪些责任应被主体化、一个主体能看到什么、能调用什么、能影响什么，以及它在何种情况下必须停止、升级或由人接管。

生产级数字主体不是“替某岗位回答问题”的虚拟助手，而是围绕稳定责任域长期运行的业务单元。它应当能够解释：我对什么目标负责；我依据哪些事实形成判断；我使用了哪些经过批准的能力；我提出或执行了什么行动；谁授权、谁批准；结果是否证明我的判断有效。

如果这些问题无法回答，主体就可能退化为三种风险形态：

• 只有角色提示词的聊天入口，能够描述业务，却没有稳定责任和证据；
• 只有工具调用权限的自动化脚本，能够执行接口，却不知道何时不应行动；
• 只有局部优化指标的算法服务，能够产生结果，却无法解释其对交付、质量、安全和其他主体的影响。

Digital Subject 的设计目标，是把业务责任、专业能力和治理边界整合为可运行、可审计的主体，而不是制造更多孤立的 Agent。

6.2 哪些生产责任域应当成为数字主体

并非每一个对象、报表或流程都需要独立主体。主体化的判断标准，不是数据量大小或界面数量，而是某个责任域是否同时具有持续目标、动态环境、跨域影响和需要反复判断的例外。

适合主体化的典型责任域包括：

相反，单一字段维护、固定报表生成、简单审批转发或一次性数据转换，通常更适合保留为确定性服务或工作流能力。主体可以调用它们，但不必为每个功能建立一个“Agent”。

主体边界也不应完全照搬组织部门边界。一个部门可能承担多类稳定责任，一个责任域也可能跨越多个部门。主体划分的关键是：它是否能够对一个清晰目标、观察范围和行动边界负责，并在与其他主体交互时形成可解释的承诺。

6.3 生产级 Digital Subject 的设计蓝图

每个主体都应有一份可审查的“主体定义”。它不是一段角色提示词，而是对业务责任和技术边界的正式说明。

这份定义应经过业务、技术、安全和治理责任人的共同确认。只有当责任、事实、能力和权限彼此匹配时，主体才可能安全进入运行环境。

6.4 目标设计：从单点 KPI 到有边界的业务责任

主体的 Goal 不能只写成“最大化效率”或“降低成本”。单点 KPI 往往会诱导局部最优：订单主体若只追求准时交付，可能会过度挤占其他订单资源；设备主体若只追求利用率，可能会压缩必要维护；物料主体若只追求库存降低，可能会削弱供应韧性。

生产级目标应至少包含四部分：

1. 服务目标。 主体要改善什么业务结果，例如订单承诺、齐套、设备能力、质量合格或能耗平衡；
2. 硬约束。 绝不能以优化为名突破的安全、质量、法规、工艺、库存和控制边界；
3. 权衡原则。 当多个合法目标冲突时，主体依据何种经营优先级、资源配额或升级规则处理；
4. 责任边界。 主体可以影响哪些对象和时间范围，何时必须让渡给其他主体或人类责任人。

例如，设备主体的目标可表述为：在不违反安全、维护和工艺约束的前提下，维持关键设备能力并降低未计划停机对订单承诺的影响；当维护延期超过规定阈值、健康预测不确定性过高或影响多个关键订单时，必须升级给设备责任人和生产协调机制。

这种目标设计使主体知道何时应行动，也知道何时不应以局部效率为理由继续推进。

6.5 观察与认知：主体只能基于被授权、带质量标识的现实行动

主体的 Belief 必须建立在世界模型提供的、经过授权的观察范围之上。它不应任意读取所有企业数据，也不应把搜索到的文档、历史对话或模型生成内容视为事实。

每个主体的观察范围应明确：

• 可读取哪些实体、关系和状态；
• 哪些信息是事实，哪些是预测或情景；
• 数据的来源、更新时间、质量等级和访问权限；
• 哪些缺失、冲突或过期条件会使其只能建议、必须核验或必须暂停；
• 哪些敏感数据只能以聚合、脱敏或审批后的方式被使用。

例如，质量主体可以读取与批次、工艺、检验、偏差和人员资质有关的事实，但不应因持有质量责任就无边界访问所有客户商业信息。订单主体可以读取交付承诺和相关资源状态，却不应自行将未经批准的质量预测解释为放行结论。

主体形成的认知还应附带证据引用。它应能说明：“这个判断基于哪些事实版本、哪些预测、哪些经验和哪个 Skill 的输出；其中哪些假设尚未被确认。”这既是可解释性的要求，也是后续协同与审计的基础。

6.6 Skill、Memory 与 Action：能力不是权限

主体拥有某项 Skill，不等于它拥有相应行动权限。排程优化 Skill 可以计算一套更优计划，设备诊断 Skill 可以预测故障风险，质量分析 Skill 可以发现异常模式；但这些结果都只是决策材料，不能自动改变订单、设备或质量状态。

主体应把能力与权限分开设计：

Memory 也不能成为绕过治理的捷径。主体从记忆中检索到的历史案例，只能作为带适用条件的参考；当当前事实、产品、设备状态或法规环境不同，主体必须明确差异而非机械复用。经验更新需要经过 Reflection、评测和批准，不能由一次成功或失败自动固化为新规则。

6.7 主体的运行闭环

生产级主体应在 Runtime 管理下经历一个可观察的闭环，而不是无休止地“思考和调用工具”。一个典型闭环如下：

事件或目标触发        ↓读取事实、约束、预测与历史证据        ↓形成带不确定性的 Belief        ↓调用 Skill 生成并比较候选方案        ↓与相关主体交换条件、资源请求和承诺        ↓按权限生成建议、审批申请或事务意图        ↓事务执行、现场确认或人工接管        ↓比较结果与预期，进入 Reflection 与经验治理

闭环中的每一步都应有停止条件。例如，事实质量不足时不应进入高影响方案比较；Skill 超出适用范围时不应将结果作为结论；协同冲突未解决时不应提交事务；下游系统不可用时应冻结意图而不是无限重试；实际结果偏离预期时应触发复盘而不是静默结束。

Runtime 负责保存这些状态和证据，使主体可以被暂停、恢复、转交或审计。主体不需要始终在线运行，但其责任、上下文和未完成承诺必须可被恢复和追踪。

6.8 场景：设备主体如何在维护与交付冲突中运行

设备主体收到两类事件：设备 D 的健康诊断显示故障风险上升，EAM 中存在两天后的预防维护工单；同时订单主体提出请求，希望为重点订单 A 暂时增加该设备的可用产能。

设备主体先读取事实：当前告警、维护工单、设备负荷、备件状态、操作资格、相关订单和安全阈值。它还读取预测：不同负荷下的健康风险、维护延期后可能的故障影响，以及替代设备的可用性。若关键传感器数据缺失或告警状态冲突，它应先请求核验，而不是继续给出“可以延期维护”的建议。

在事实充分的前提下，设备主体调用健康诊断、维护优化和产能影响评估 Skill，形成候选路径：

设备主体把每条路径的事实版本、风险、适用条件和有效期发送给计划、订单、质量和安全主体。若企业政策规定维护延期超过某阈值必须由设备负责人和生产负责人共同批准，主体只能发起审批；若健康风险接近安全边界，则它必须拒绝延期维护建议，并将系统降级到人工处置。

最终，Transaction Execution Engine 只会接收已获批准且仍基于有效事实的意图。EAM 负责真正创建、修改或关闭维护工单；SCADA、PLC 和安全联锁继续控制设备状态。实际维护结果、故障情况与订单影响随后进入 Reflection，帮助企业评估诊断模型和维护策略是否需要修订。

6.9 主体的验收、降级与淘汰

数字主体上线不是一次性的“部署完成”。它需要持续验证其是否在预期范围内创造价值，并在不满足条件时缩小权限、暂停或淘汰。

主体验收至少包括：

• 责任清晰度： 主体的目标、观察范围、协同对象、权限与升级人是否可被业务负责人明确确认；
• 认知质量： 其引用事实是否准确、及时、可追溯，是否能正确暴露预测与不确定性；
• 方案质量： 候选方案是否完整考虑硬约束、局部与全局影响，是否能被专家复现或解释；
• 执行安全： 是否从未绕过权限、事务、控制与安全边界，失败时是否正确冻结、补偿或升级；
• 组织价值： 是否在交付、质量、设备可靠性、异常恢复、人工决策耗时或经验复用上形成可验证改善；
• 学习治理： Memory、Skill 和策略更新是否经过评测、批准、版本化与回退。

当数据质量持续低于门槛、模型明显漂移、人工否决率异常、下游系统不稳定或出现越权风险时，主体应自动从 L2/L3 降级为 L1 或 L0；在高风险情况下，必须停止受控执行，只保留态势展示和人工接管。主体不是永久存在的数字员工，而是需要被持续评估和治理的组织能力。

6.10 本章结论

Digital Subject 是 AI 原生生产运营系统中承担稳定业务责任的基本单元。它不是提示词、接口封装或算法服务，而是将目标、观察范围、专业能力、行动权限、协同关系、审计证据和结果反思组织为一个受治理闭环。

主体化的核心不在于把所有功能做成 Agent，而在于把真正需要持续判断、跨域协同和责任追溯的生产责任域明确化。下一章将进一步讨论，当多个主体围绕共同目标和共享世界模型运行时，如何设计 Multi-Agent Organization 的分工、协调与冲突裁决机制。