From Single-Agent OS to Constitutional Runtime

Why I Rebuilt My AI System

Chapter 2 — 问题不是能力，而是组织结构：为什么长期 AI 工作需要任务归属、权限关系、证据门与合法结案

本章接续第一章的失稳诊断。第一章已经列出 single-agent OS 在长期任务中暴露的八类结构性问题；本章不再重复缺陷清单，而是把问题压缩到一个更窄、更可检验的判断：在长期、多节点、可审计、可能产生状态变更的 AI 工作中，execution capability 本身不会自动生成 mission ownership、authority relation、evidence admissibility、state transition boundary 与 closure condition。

本文使用的 Constitutional Runtime、Constitutional Kernel、Mission Kernel、mission object、receipt、state delta、lawful closure 等术语，是本文为当前工程提出的治理抽象，不是行业统一标准。本文中的 lawful / legitimate 也不是外部法律意义，而是 runtime-internal legitimacy：一个 action、evidence item、state transition 或 closure 是否满足当前 runtime contract。

本章不主张 CR / CK / MK 与 typed receipt 是唯一可能解。更准确地说，本文先界定一个问题域，再承认 RBAC、workflow state machine、issue / PR lifecycle、audit log 等竞争路径都可以承接其中一部分问题；本文选择 receipt-bearing runtime objects，是因为它们能让关键治理断言脱离 LLM 自我说明，被机器独立检查、回放、拒绝和审计。

2.0 Opening：从执行能力到组织结构

From execution capability to governance structure

现有 agent runtime 已经具备实质工程能力。它们已经覆盖长期记忆、工具调用、provider routing、workflow、gateway、sub-agent delegation、task queue、background execution、session persistence、sandbox、trace 与 eval harness 等执行能力。Anthropic 把 agentic system 区分为 predefined workflow 与更自主的 agent，并总结了 prompt chaining、routing、parallelization、orchestrator-workers、evaluator-optimizer 等常见模式 [R1]；其 context engineering 与 long-running harness 的讨论也说明，长任务需要 compaction、结构化进度记录、环境初始化、测试与逐步推进，而不是单纯扩大上下文窗口 [R2][R3]。OpenAI 的 agent guide 将 agent 的基础构成压缩为 model、tools 与 instructions，并把 orchestration、guardrails 与 human intervention 视为真实部署中的关键机制 [R5]。Hugging Face 的 smolagents 课程则把 multi-agent system 描述为由 specialized agents 在 orchestrator 下协作的结构 [R7]。

这些工作表明，能力层已经可以承担真实的执行负载。Springdrift 进一步展示了 persistent、auditable、self-observing 的 long-lived agent runtime：append-only memory、cycle-level logs、sensorium、自我状态注入和 normative safety [R9]。Agent-Kernel 展示了 society-centric microkernel 在大规模 social simulation 中的价值，把 Agent / Environment / Action / Controller / System 解耦，并在大规模社会模拟中验证其可扩展性 [R10]。

因此，本文并不否定 agent runtime OS，也不否定 multi-agent framework。这些 execution substrate 是必要条件。若缺少工具调用、provider routing、memory、session continuity、sub-agent delegation、task queue 和 sandbox，agent system 会退化为具备更强文本生成能力的模型接口。问题在于，execution substrate 主要回答“系统能做什么”。它并不自动回答“谁有权让系统这样做”“哪条记忆能成为证据”“哪个状态面可以被改写”“哪个节点只是 support”“任务何时可以关闭”。当长期任务进入多轮压缩、多节点交接、多次工具调用和多阶段审计时，能力层本身不足以维持任务秩序。

缺失的层不是 intelligence，而是 governance。

Figure 2.1 治理边界与可替换执行适配层。 Constitutional Runtime architecture 不替代既有 agent runtime，而是治理它们如何参与长期 mission execution。Execution adapter layer 可以替换；governance boundary 也不是天然免疫漂移，而是必须通过更严格的 governance-change path、versioned contract update 与 receipt 受治理。

表 2-1：现有能力层与本文治理层问题的边界

接下来几节会把这些“不能自动解决的问题”拆成一组结构性不等式。但这些不等式本身并不自动推出本文方案。它们只说明：在长期、多节点、可审计、可能产生状态变更的任务中，如果系统不能稳定区分 capability / ownership、role / authority、memory / evidence、done / closure，那么局部执行会逐渐污染任务状态。本文的桥接前提是：当某个区分会影响未来任务状态、权限判断或结案条件，并且混淆该区分的代价——状态污染、误授权、虚假结案或不可复盘——超过显式建模成本时，它就不应只保存在自然语言上下文里，而应被表示为可检查的 runtime object。

2.1 能执行，不等于有权拥有任务

Capability is not ownership

本文中的 capability 使用工程口语义，指一个节点可执行的动作表面；它不同于 object-capability security 中作为授权令牌的 capability。这里讨论的正是：当 capability 仅被作为 execution surface 使用时，它不能自动替代 mission ownership。

Capability 说明一个节点能执行什么动作；ownership 说明一个节点是否有权改变某个 mission 的状态。一个 runtime endpoint 能连接外部服务、搜索资料、写文件、调用 shell、维护会话或调度子任务，只能说明它具备行动表面。它不能因此自动拥有任务。一个 search-capable 节点能返回 briefing，不代表它有权改变任务方向；一个 execution 节点能生成 patch，不代表 patch 可以进入 canonical state；一个 gateway 能路由请求，不代表它是 sovereign center；一个 plugin 能写文件，不代表它有权写入 current truth。

Figure 2.2 Capability ≠ Ownership。 采用 v6 横向对照视觉结构；从 can 到 may 必须经过治理层裁决。

这条边界在短任务中不明显。用户提出请求，agent 执行，工具返回结果，系统输出答案。owner、执行者、证据来源和结束条件几乎都被压在同一个会话上下文里，不需要额外拆开。但长期任务会经过补充、压缩、转交、修订、侦查、执行、审计和再总结。如果系统只记录“哪个节点能做什么”，而不记录“哪个节点有权改变什么”，任务归属就会开始漂移。

这种漂移通常不是显眼的越权，而是由一连串看似合理的推进累积而成。一组本应只是 support 的动作会累积成 ownership 的事实。一个 research node 最初只是负责检索，后来它的 briefing 被当成任务方向；一个 support node 原本只是补充材料，后来它的建议被当成 owner-level decision；一个 routing node 起初只是选择处理路径，后来系统开始把 route 当成 sovereignty transfer；一个 execution plugin 原本只是落地某个 patch，后来它的输出被直接视作 canonical update。表面看，这些都是协作；从治理层看，权限边界已经被静默改写。

因此，capability 属于 execution layer；ownership 属于 mission law。前者可以由不同 agent runtime、tool layer、gateway、provider router 或 plugin adapter 提供；后者必须由更高层的 authority relation 和 mission lifecycle 裁决。在上述代价判断下，一个长期任务系统应要求关键能力调用绑定 mission_id、current_owner、authority_relation、evidence_basis 和 receipt。缺少这些字段，系统会把“能做”误读成“有权做”，并进一步把“执行了某一步”误读成“拥有整个任务”。

Agent runtime OS provides can. Constitutional Kernel adjudicates may. Mission Kernel records who owns what, under which authority, with what evidence, until what closure.

2.2 角色不是权限，协作不是组织

Role is not authority; collaboration is not organization

多个 agent 同时存在，不等于系统已经形成组织结构。多个端口可以接入同一个系统，也不等于系统已经形成任务社会。它们只能说明系统中有更多可调用节点、更多可路由 endpoint、更多可参与执行的角色。它们不能自动回答：谁拥有当前 mission？谁只是 support？谁可以 route？谁可以 audit？谁可以改变任务定义？谁可以写入 state？谁可以关闭任务？

很多 early multi-agent system 容易把问题理解成“角色不够多”或“角色描述不够鲜明”。于是系统开始给每个 agent 写更复杂的 role prompt、更长的 persona profile、更细致的 backstory、更明确的口吻和职责描述。这些做法有使用价值。它们可以降低人类操作者的理解成本，让系统更容易被记住、被调用、被调度。一个节点被标成 planner、reviewer、researcher、executor 或 coordinator，确实比一组无名函数更容易操作。

但 role 不是 authority。Role 说明一个节点被期待承担什么工作；authority 说明这个节点在某个 mission 中有权改变什么。一个 reviewer 不因为被称为 reviewer 就有权夺取 owner；一个 coordinator 不因为负责 routing 就拥有 sovereignty；一个 synthesis node 不因为负责总结就能改写 canonical truth；一个 active agent 不因为当前被 handoff 就自动成为 current owner。角色是人类理解系统的界面，权限是系统裁决行动合法性的结构。两者不能混在一起。

Collaboration 也不是 organization。Collaboration 只说明多个 agent 同时或先后参与了任务。Organization 则要求系统知道每个参与者为什么入场、在哪个阶段入场、拥有哪种权限、产出哪种证据、何时退出。没有 organization 的 collaboration，往往只是多节点并发发言；它可能产生更多观点，但不一定产生更好的任务秩序。Anthropic 的 multi-agent research system 采用 orchestrator-worker 模式，并强调 subagent 需要明确 objective、output format、tool/source guidance 与 task boundaries [R4]。这个经验本身就在说明，多 agent 协作不能只靠“让更多 agent 加入”，还要靠边界、分解、观察和评估。

一段具象的漂移轨迹

设 mission 是“评估这家公司的财务风险”。Step 0，用户在 chat 里下达请求；系统按 agent-centered 习惯，把请求直接交给一个 active research node。Step 1，research node 调用搜索工具，返回一份 briefing。Step 2，下一轮 synthesis 把 briefing 压缩进 summary，过程中丢掉了 briefing 标注的 confidence、source 和 mission link，只留下“该公司现金流稳定”这类结论。Step 3，后续 synthesis 直接复用这份已经失去 provenance 的 summary，把其中的旧判断当作 current truth。Step 4，一个 review node 阅读 summary，没有看到原始 briefing 的边界，于是基于 summary 给出 “looks good”。Step 5，系统读到 review，宣告 mission done。

表面上每一步都合理；放到 mission lifecycle 中看，漂移已经发生。下表把这条链路拆成可审计对象：

示例：财务风险评估任务中的隐性权限漂移

没有任何一步显式“夺权”。关键风险在于：漂移不是单点事故，而是在局部合规动作中累积。类似的越权、工具滥用与代理边界风险也出现在 AI agent security checklist 中 [R11]；本文把这类风险进一步压成 mission-bound authority relation 与 receipt-bearing adjudication。

要让这条轨迹可裁决，每一步都必须留下可复核的 receipt。Briefing 必须留下带 mission_id 与 evidence_type 的 support 受理记录；compaction 必须保留 confidence 与 source 字段不被静默丢弃；audit 必须显式标注 audit-only / non-owner status；closure 必须由 closure_authority 签名，而不是由 reviewer 的自然语言断言触发。

表 2-2：多 agent 系统中的概念边界

更稳的多 agent 协作结构，不是 global chat，而是 mission-scoped route。任务进入系统后，Mission Kernel 不应默认选择 temporary council，而应根据任务类型、风险等级、所需能力、证据缺口和权限边界选择 route mode：single_authorized_actor、bounded_mandate_route、recon_or_hold_route、embedded_audit_route，或者在跨域、高风险、需要会审时组建 temporary_council。Council 只是一种 route mode，不是所有任务的默认路径。

Role 是功能标识，不是权限来源。Collaboration 是参与事实，不是组织结构。Endpoint 是传输表面，不是任务主权。Handoff 是转交流程，不是 owner transfer。Council 是 mission-scoped runtime structure，不是永久聊天室。

2.3 记忆解决连续性，证据解决可采信性

Memory is not evidence

Constitutional Runtime architecture 不是另一个 agent OS。它不替代 memory、tools、gateway、workflow、provider routing 或 sub-agent session。相反，本文把这些能力视为必要的执行基础：memory 负责保留历史，tools 负责连接外部能力，gateway 负责入口与出口，workflow 负责阶段推进，provider routing 负责在配置或策略范围内选择模型和服务，sub-agent session 负责隔离不同执行线程。

但这些能力本身并不回答一个更高层的问题：它们产生的内容是否有权改变当前任务状态？一个系统可以记住很多东西，可以调用很多工具，可以把任务路由给多个 agent，也可以让多个 session 并行运行。只要它不能稳定判断哪些记忆可以成为证据、谁有权改写任务、什么状态变更是合法的、任务什么时候可以结案，它仍然只是执行系统，而不是可治理的长期任务系统。

Memory 解决 continuity；Evidence 解决 admissibility。

Memory 让系统跨 session 保留信息。它可以保存用户偏好、任务历史、失败经验、工具输出、旧判断、上下文摘要和过去的工作材料。没有 memory，长期任务无法持续。但 continuity 不是 legitimacy。一个 memory item 被检索出来，只说明它曾经存在于系统历史中，不说明它仍然有效，也不说明它有资格改写当前任务状态。它可能是旧背景、临时假设、过期判断、模型推测、support note，也可能是一次错误压缩后的残留。

长期任务中，这个问题会被 context anxiety 放大。这里的 context anxiety 不是说模型有情绪，而是指系统在担心遗漏关键背景时，倾向于保留、重装、压缩、再展开越来越多的历史材料。随着任务轮次增加，context 会不断变厚，然后被 compact，再次变厚，再次 compact。每次压缩都会做取舍；如果系统没有记录来源、时间、权限和证据等级，压缩就不是结构化整理，而只是把不同性质的信息压进更短的自然语言摘要里。

即使未来上下文窗口继续扩大，这个问题也不会自然消失。更长的上下文窗口可以缓解信息丢失，但不能自动解决信息合法性。随着上下文成本下降，系统会倾向于装入更多历史、更多材料和更复杂的任务流。真正的问题不是“能不能记更多”，而是“记住的东西以什么身份重新进入任务”。

因此，memory item 至少需要被标注几个字段：

memory_item:                   # illustrative fragment, not full schema
  memory_id: mem_<id>
  source: actor_or_system_ref
  time: utc_timestamp
  scope: mission_id | project_scope | global_profile
  type: fact | assumption | recon_note | support_note | preference | summary
  confidence: low | medium | high | numeric_score
  authority: none | context_only | evidence_candidate | state_changing

Evidence 的要求更高。Evidence 不只是“被记住的内容”，而是经过当前任务语境、来源、时间、权限和验证状态过滤后，被允许参与任务裁决的材料。它必须回答：这条信息从哪里来？属于哪个 mission？是否仍然有效？是否经过验证？是否只是背景？是否足以改变当前 canonical state？

这里也需要正面定义 canonical state。Canonical state 指当前被治理层承认的权威运行状态。下游 mission routing、authority adjudication、evidence admission 与 closure check 只能在这个状态基础上继续执行。 Memory 可以提示它，evidence 可以支持它的更新，projection 可以展示它，archive 可以解释它的历史；但这些都不等于 canonical state 本身。

因此，Constitutional Runtime 不能只维护 memory continuity；它还必须维护 evidence gate。记忆可以进入系统，但只有通过来源、时间、作用域、类型、验证状态、confidence 与 authority 的裁决之后，才可以参与改写 current truth。

Memory is recall. Evidence is admissibility.

2.4 完成、状态更新与合法结案不是同一件事

Completion is not state update; done is not closure

Done 是执行层信号；state update 是受控状态面的合法写入；closure 是 mission lifecycle 的合法关闭。

长期任务系统如果只保留 done / not done 的二分，就会把局部完成误认为系统状态已经改变，也会把状态改变误认为任务已经结案。

Anthropic 在 agent evals 中区分 transcript 与 outcome：transcript 是完整轨迹，包含输出、工具调用与中间结果；outcome 是 trial 结束时环境中的最终状态 [R3]。这一区分支持 execution trace 与 environmental outcome 的分离。本文在此基础上再加入第三层：mission closure。Closure 不是外部文献直接给出的概念，而是本文为长期 mission lifecycle 引入的治理对象。

例如，一个 execution node 可以说 patch done，但如果没有 state_delta_receipt，它不能证明系统状态已经合法改变。一个 synthesis node 可以说 report done，但如果没有 closure authority，它不能关闭 mission。一个 workflow 可以走到最后一步，但如果中间发生 owner 漂移、support 升级、audit 未处理或 evidence 不完整，它仍然不能 lawful closure。

Figure 2.3 Canonical mission lifecycle。 采用 v6 清晰横向流程结构，但语义已对齐 v7.3：CR truth check、CK authority adjudication、route mode decision、conditional routing / council / participant binding、evidence、state transition 与 closure 都被拆开。

因此，长期任务系统需要将 completion、state update 与 closure 分开落库。Completion 记录局部动作结束；state update 记录已批准的状态变化；closure receipt 记录任务原始目标、current owner、执行路径、采信 evidence、写入 state delta 或 non-promotion、未解决问题、closure authority 与停止理由。Closure 不是“系统不再说话”，而是“mission 已证明自己可以停止”。

下面是 closure_receipt 的说明性最小字段集合。它不是声称当前工程已经完成全部 closure schema；它说明 closure 需要承载的语义负载。

closure_receipt:                       # illustrative fragment
  receipt_id: "rcp_<16-hex>"
  receipt_kind: "mission_closure"
  mission_id: <mission_ref>
  closed_by: <closure_authority_ref>   # 不可由 reviewer 顶替
  closure_basis: [<receipt_id>, ...]
  required_receipts_met:
    mission_intake_receipt: true
    cr_current_truth_check_receipt: true
    authority_decision_receipt: true
    route_mode_decision_receipt: true
    routing_receipt: true | not_required
    council_assembly_receipt: true | not_required
    participant_binding_receipt: true | not_required
    execution_receipt: true | not_required
    evidence_admission_receipt: true | not_required
    audit_receipt: true | not_required
  state_transition_policy: no_mutation | proposed | accepted | rejected
  state_delta_receipt: <receipt_ref_or_null>
  non_promotion_receipt: <receipt_ref_or_null>
  unresolved_issues: []
  next_responsibility: <ref_or_null>
  signed_at: <utc_timestamp>

每个 mission 都必须经过 route_mode_decision；但只有跨 participant、跨 runtime 或跨 scope 的任务才需要 routing_receipt。single_authorized_actor 路径记录 route mode 裁决，而不是伪造一个并不存在的多节点 routing。状态转移也由四态 policy 承载：accepted 表示必须有 state_delta_receipt；rejected 表示必须有 non_promotion_receipt；no_mutation 表示两者皆为空；proposed 表示状态变更尚未完成，除非任务以 honest_stop 或 partial_handoff 形式终止并记录 unresolved issues，否则不得作为 final closure。

这些字段不是文档装饰。它们对应一个具体不变量：closure 不是由任何 agent 的自然语言断言触发的，而是由 closure_authority 在 prior receipts 满足时签名触发的。任务不是在某个节点说 done 时结束，而是在 Mission Kernel 能够证明 owner / route mode / conditional routing / conditional council assembly / participant binding / evidence / state transition policy / audit / closure authority 都满足时结束。

2.5 Agent runtime OS 应作为可插拔 execution adapter 接入

Agent runtime OS as pluggable execution adapters

Gateway ≠ Sovereign Center

本文在此限定一个边界：如果 Constitutional Runtime architecture 要维护 current truth、evidence gate、authority boundary、state delta、audit receipt 与 lawful closure，它是否会替代已有的 agent runtime OS？

本文采用的架构边界是：不替代。Constitutional Runtime architecture 不重新实现 OpenClaw、Hermes、Springdrift、Agent-Kernel 或其他 agent runtime、harness、framework，也不重新实现 gateway、memory、tools、provider routing、workflow engine、daemon persistence 与 sub-agent session。更准确的关系是：这些系统可以作为可插拔 runtime plugin 或 execution adapter 接入 Constitutional Runtime architecture。其能力强弱不改变其治理位置：它们仍不应自动拥有 mission authority。

Gateway 可以接收输入，但 Gateway 不拥有 mission。一个 gateway 可以连接 CLI、Web UI、本地桌面端、WebSocket、消息平台或其他 channel。它可以管理 ingress / egress，也可以负责把外部消息转成系统可处理的请求。但它只是入口，不是主权中心。用户从某个 gateway 发起任务，不代表这个 gateway 有权决定任务归属。某个 runtime 从 gateway 收到请求，也不代表这个 runtime 自动成为 mission owner。某个 channel 能把消息送进系统，也不代表它可以改写 canonical truth。

因此，gateway 的职责应该限定于：接收输入、标准化输入、传递输入、返回输出、记录 transport-level receipt。它不应负责决定 mission ownership、裁决 authority relation、接受或拒绝 evidence、写入 canonical state、关闭 mission lifecycle。这些属于 CR、CK 与 MK 的治理裁决范围。

Capability Plane ≠ Mission Authority

Capability plane 不等于 mission authority。Tool registry 可以暴露能力，但 tool registry 不授予权限。Provider router 可以按配置、成本、延迟、兼容性或 fallback 策略选择模型与服务端点，但它不决定任务主权。Sub-agent session 可以执行子任务，但 session 本身不拥有 closure authority。Daemon runtime 可以持久运行任务，但 persistence 不等于 lawful ownership。Workflow engine 可以跑完步骤，但 workflow completion 不等于 mission closure。

本文采用的架构关系，是让不同 agent runtime OS 作为可替换的 execution adapter 接入。一个 runtime 可以擅长 gateway；一个 runtime 可以擅长 prompt assembly；一个 runtime 可以擅长 daemon persistence；一个 runtime 可以擅长 local tool execution；一个 runtime 可以擅长 sub-agent sessions；一个 runtime 可以擅长大规模 simulation。工程上，这类 execution adapter 可以表现为 SDK-level handoff、custom subagent、agents API 或 provider-routing surface；OpenAI Agents SDK、Claude Code subagents 与 smolagents API 文档可作为这类 capability-plane 接入面的近邻参考 [R6][R15][R16]。这些能力都可以被保留，也都可以被接入。但接入时必须经过同一套治理边界。

Typed Task Packet 与 Agent Runtime Plugin Contract

接入 Constitutional Runtime architecture 之后，runtime 不应直接接收自由自然语言任务并自行扩大解释权。它应接收 Mission Kernel 下发的 typed task packet。换言之，runtime 执行的对象不应是由自身自由解释出的用户意图，而应是已经经过 CR boundary check、CK authority adjudication 与 MK route mode decision 的 mission slice。

mission_slice:                         # illustrative fragment
  mission_id: <mission_ref>
  slice_act: recon | synthesis | execution | audit | review | closure_check
  requester: <actor_ref>
  current_owner: <actor_ref>
  assigned_runtime: <runtime_ref>
  authority_scope:
    relation: support | consult | recon | execution | audit | routing | closure_authority
    allowed_acts: [observe, request, route, support, audit_flag, report, propose_state_delta, close_if_closure_authority]
  allowed_capabilities: [<capability_ref>, ...]
  required_output: <artifact_or_receipt_spec>
  required_receipts:
    - execution_receipt
  conditional_receipts:
    - audit_receipt if audit_required
    - state_delta_receipt if state_mutation_policy == allowed_with_state_delta_receipt
    - closure_receipt if closure_policy == allowed_with_closure_receipt
  state_mutation_policy: deny_by_default | proposal_only | allowed_with_state_delta_receipt
  audit_visibility: full_trace | summarized_trace | external_attestation
  closure_policy: not_allowed | closure_check_only | allowed_with_closure_receipt

任何 agent runtime OS 接入时，都应声明一份 adapter contract。本文称之为 Agent Runtime Plugin Contract。下表是 proposed contract：它用于把“runtime 该作为 plugin 接入”这一架构主张具象化为后续 schema 可以固化的字段集。

表 2-3：Agent Runtime Plugin Contract 的最小字段

没有 contract 的 runtime 只是外部执行器；有 contract 的 runtime 才是 Constitutional Runtime architecture 可以调度、审计、复核和回收权限的 plugin。

Agent runtime OS provides capability. Constitutional Runtime governs legitimacy.

2.6 把组织结构落在 mission 上

Mission-centered organization

长期 multi-agent system 的基本治理单位不应该是 agent，而应该是 mission。这里需要先澄清：这不是要求用户改变交互方式。用户仍然可以用自然语言提出请求，仍然可以通过 chat、CLI、Web UI、GitHub issue / PR lifecycle 或任务面板发起工作 [R13]。改变的是系统内部的记账单位。面向用户的界面仍然是 conversational；面向 runtime 的表示则变成 mission-centered。

在 agent-centered system 中，系统通常先定义 agent：它是谁、有什么 persona、能调用哪些工具、在哪个 session 中 active、是否接到 handoff。然后系统再让这些 agent 协作完成任务。这种方式在短任务和演示系统中自然，但在长期任务中会把注意力过度拉向执行节点。系统不断追问“哪个 agent 正在处理”，却不一定能回答“这个任务归谁、谁有权改变它、谁只是 support、什么证据能改变状态、什么时候可以结案”。

Mission-centered organization 则反过来。Root Owner input 进入系统后，不直接变成某个 agent 的自由任务，而是先生成 mission object。这个 object 至少包含任务目标、请求来源、current owner、authority graph、约束、预期 state transition policy、route mode decision、required support、audit policy、receipt requirements 与 closure conditions。Agent 仍然重要，但它只是 mission lifecycle 中的 typed participant。

mission_instance:                      # illustrative fragment
  mission_id: <mission_ref>
  requester: <actor_ref>
  current_owner: <actor_ref>
  mission_domain: research | writing | implementation | audit | planning
  authority_scope: <authority_relation_ref>
  route_mode: single_authorized_actor | bounded_mandate_route | recon_or_hold_route | embedded_audit_route | temporary_council
  support_nodes: [<actor_or_runtime_ref>, ...]
  audit_nodes: [<actor_or_runtime_ref>, ...]
  allowed_capabilities: [<capability_ref>, ...]
  required_receipts:
    - mission_intake_receipt
    - CR_current_truth_check_receipt
    - authority_decision_receipt
    - route_mode_decision_receipt
  conditional_receipts:
    - routing_receipt if participant_boundary_crossed
    - council_assembly_receipt if route_mode == temporary_council
    - participant_binding_receipt if participant_binding_required
    - execution_receipt if execution_required
    - evidence_admission_receipt if evidence_required
    - state_delta_receipt if state_transition_policy == accepted
    - non_promotion_receipt if state_transition_policy == rejected
    - closure_receipt if closure_requested
  state_transition_policy: no_mutation | proposed | accepted | rejected
  closure_condition: <closure_condition_ref>

这里需要区分两个字段层级：mission_instance.mission_domain 标注整条 mission 属于哪个任务领域；mission_slice.slice_act 标注下发给某个 runtime 的执行片段是哪一类运行时动作。一条 research 领域的 mission，可能被拆成 recon、synthesis、review 等多个 slice_act。因此，plugin contract 也拆成 supported_mission_domains 与 supported_slice_acts：前者描述 runtime 可以参与哪些 mission 领域，后者描述它可以执行哪些 mission slice 动作。

本文采用的边界是：Mission owns lifecycle. Authority graph owns permissions. Route mode owns coordination shape. Receipts own evidence. Closure authority owns termination. Agents own execution slices.

Figure 2.4 Mission-centered organization 与 route mode lifecycle。 Council 不是常驻聊天室，也不是默认路径；任务触发后由 MK 选择 single actor、bounded mandate、recon/hold、embedded audit 或 temporary council；receipt chain 显式保留 CR truth check、conditional council assembly 与 participant binding。

Mission-centered organization 的另一个结果，是系统不需要让所有 agent 永久处在同一个 global chat 里。长期多 agent 系统如果把所有节点放进同一个频道自由讨论，很快会出现噪音、上下文膨胀、权限混淆和责任漂移。更稳的方式是任务触发相应 route mode。固定、低风险、单域、read-only 或明确落在某个预定义 operational scope / mandate 内的任务，可以走 single actor 或 bounded mandate route；跨域、模糊、高风险、需要会审或特殊审计时，才组建 temporary council。

一个 council 只获得与当前 mission 相关的有限权限。一个节点被邀请进入 council，不代表它获得全局 authority。一个 support node 可以提供材料和建议，但不能静默升级成 owner；一个 audit node 可以冻结、质询或上卷风险，但不能直接夺取 mission ownership；一个 routing node 可以决定任务流向，但 routing 不等于 sovereignty；一个 synthesis node 可以组织输出，但不能绕过 evidence gate 改写 canonical state。

Mission-centered organization 的正常流转不应该只是一段对话历史，而应该是一条 receipt chain：

mission_intake_receipt
  -> CR_current_truth_check_receipt
    -> authority_decision_receipt
      -> route_mode_decision_receipt
        -> routing_receipt | not_required
          -> council_assembly_receipt | not_required
            -> participant_binding_receipt | not_required
              -> execution_receipt | not_required
                -> evidence_admission_receipt | not_required
                  -> audit_receipt | not_required
                    -> state_delta_receipt | non_promotion_receipt | not_required
                      -> mission_closure_receipt | honest_stop_receipt | partial_handoff_receipt

2.6 的 receipt chain 是 2.7 canonical lifecycle 的回执投影。Envelope 编译阶段（sidecar / draft / governed envelope）可以包含在 mission_intake_receipt 中，而不一定单独产生 receipt；所有涉及裁决、route mode、conditional routing、council assembly、参与者绑定、能力调用、证据准入、状态影响和终止语义的阶段，则必须产生明确 receipt kind 或明确的 not_required 说明。

除 lawful closure 外，本文承认两条非理想但合法的终止路径：honest_stop 指任务在证据不足、权限不足或前置条件未满足时被诚实停止，不伪装成结案；partial_handoff 指任务的一部分被移交给新的 owner 或后续 mission。二者各自带来进一步的处置问题：honest_stop 下既有 state transition proposal 的去留与 authority 释放，partial_handoff 下新 owner 的 authority 是继承还是重新接地于 Root Owner。这些属于 Mission Kernel 的终止语义，将在后续章节展开。本章只确立：这两条路径同样必须留下可独立核验的 receipt，而不能由自然语言宣布。

这条链并不只是“日志更结构化”。它是一组可被机器独立验证的断言：每一步发生时，谁有权这么做、它满足了哪些前置条件、它写入了什么、它能否被撤销，都不依赖 LLM 输出的自我说明，而落在 receipt graph 里。

2.7 CR / CK / MK：从能力堆叠到任务社会结构

From capability stack to governed mission structure

前文讨论的问题可以重新表述为五个误读：capability 被误读成 ownership，role 被误读成 authority，collaboration 被误读成 organization，memory 被误读成 evidence，completion 被误读成 closure。这五个误读不是彼此孤立的 bug，而是长期、多节点、可审计任务在缺少治理层时的系统性失稳。

承认“缺治理层”之后，仍有多条实现路径。至少可以区分三类：

本文选择第三条，并非主张前两条不可行，而是基于一个明确的设计判断：在长期、多节点、可审计的任务流中，治理的最小可复核单位应当是可以脱离 LLM 自我说明而被机器独立检查的 runtime assertion。RBAC 和 workflow 可以承接一部分问题；但当它们需要进一步证明“谁在什么 mission 下基于什么 evidence 改变了什么 state，并为何 closure”时，就会逐渐接近 receipt-bearing runtime objects 的形态。本文不主张 typed receipt 是唯一可能解，而主张它是本文选择的一条可审计、可比较、可验证的设计路径。

基于上述选择，本文采用三个核心结构：Constitutional Runtime、Constitutional Kernel、Mission Kernel。它们不是三个更具修辞性的模块名，而是三个不同层级的裁决面。简化地说：CR 决定系统现在合法地站在哪里；CK 决定谁有权做什么、什么算越权；MK 决定每个 mission 是什么、归谁、如何流转、如何结束。

这里需要一个术语说明。本文中 “Constitutional Runtime” 有两个用法。广义上，它指整个 governed persistent multi-agent runtime architecture；狭义上，CR 指该架构中的 current-truth / lawful-transition axis。为避免混淆，后文在讨论三层 kernel 时，使用 CR 指狭义轴；使用 Constitutional Runtime architecture 指整体系统。

Figure 2.5 CR / CK / MK 是嵌套的治理层。 它们不是三个并列模块，而是三层运行时责任：CR 给出 current-state ground，CK 在该 ground 上裁决 authority，MK 在二者之上管理 mission lifecycle。

Constitutional Runtime（CR / current-truth axis）

CR 负责维护系统当前的合法运行位置。它关心的不是“哪个 agent 正在说话”，而是当前 canonical state 是什么、哪些内容只是 side evidence、哪些 projection 不能改写 truth、哪些 historical archive 只能作为背景、当前 stage 或 frontier 是否已经关闭、下一步 transition 是否被允许、哪些 receipt 足以改变 current truth。可以将其形式化定义为：

CR is the current-truth and lawful-transition axis that maintains canonical state, evidence boundaries, lawful transition gates, and auditable state updates for a persistent multi-agent system.

CR 不是“系统永不漂移”的魔法边界。治理层本身也会漂移，因此它必须有更严格的变更路径：authority graph、CK invariant、receipt kind、closure rule 的修改，必须经过 Root Owner 授权、versioned contract update、migration note 与 governance-change receipt。换言之，governance layer is also governed。

Constitutional Kernel（CK / authority-law axis）

CK 负责权限关系本身。它不是 prompt，也不是 persona，也不是某个 agent 的自我描述。它是一套 typed authority relation layer。它关心的是：谁是 current owner，谁只是 support，谁可以 consult，谁可以 recon，谁可以 route，谁可以 audit，谁可以 escalate，谁可以 hold threshold，谁负责 execution，谁可以确认 closure，谁不能改写 canonical state。requester 是 mission 的请求来源，不是一种 authority relation。形式化定义为：

CK is the executable authority-relation axis that encodes ownership, support, consultation, recon, routing, audit, escalation, threshold holding, execution, and closure authority as typed relations rather than persona assumptions.

所谓 executable authority relation，不是指 YAML 本身会执行任务，而是指 runtime adjudicator 可以读取 relation、mission scope、requested act 与 receipt basis，并返回 ALLOW / DENY / HOLD / ESCALATE。未声明的 act 不应静默放行，而应进入 HOLD 或 ESCALATE。

CK 必须压住几条核心 invariant：

所有派生 authority relation 都必须最终接地到一个非派生授权源。本文称之为 Root Owner。Root Owner 可以是人类操作者，也可以是制度上定义的最终责任主体。没有根、或存在不可接地循环的 authority graph，不应被治理层承认为有效。

Mission Kernel（MK / mission-lifecycle axis）

MK 负责 mission lifecycle。它不是普通 task queue。Task queue 通常只回答“有哪些任务、谁来执行、执行到哪一步”。MK 需要回答更完整的问题：这个 request 是否已经成为 mission？mission envelope 是什么？current owner 是谁？authority graph 如何绑定？route mode decision 是什么？是否需要跨 participant 的 routing？需要哪些 support node？需要哪些 audit node？是否需要 temporary council？执行产生了什么 state delta？哪些 receipt 支撑状态变化？什么时候可以 lawful closure？形式化定义为：

MK is the governed work-object axis that converts requests into mission instances and manages their route-mode adjudication, conditional routing, conditional council assembly, participant binding, execution receipts, audit receipts, state-delta or non-promotion receipts, and closure receipts.

MK 的 canonical lifecycle 可以表示如下。为降低阅读负荷，可以把这条链分三段读：入账与对真（raw_request -> CR_current_truth_check -> governed_mission_envelope）、裁决与路由（CK_authority_adjudication -> route_mode_decision -> conditional_routing -> council_assembly -> participant_binding）、执行与结案（execution -> evidence -> audit -> state_delta / non-promotion -> closure / honest_stop / partial_handoff）。标为 not_required 的节点是条件路径，不是所有 mission 的必经路径。

raw_request
  -> raw_request_sidecar
    -> draft_mission_envelope
      -> CR_current_truth_check
        -> governed_mission_envelope
          -> CK_authority_adjudication
            -> MK_route_mode_decision
              -> conditional_routing_receipt | not_required
                -> council_assembly_receipt | not_required
                  -> participant_binding | not_required
                    -> capability_binding / invocation
                      -> execution_receipt | not_required
                        -> evidence_admission_receipt | not_required
                          -> audit_receipt | not_required
                            -> state_delta_receipt | non_promotion_receipt | not_required
                              -> mission_closure_receipt | honest_stop_receipt | partial_handoff_receipt

其中，raw_request_sidecar 保存原始请求的未删改副本与入口元数据，包括来源 channel、时间和原文。它与被编译、被治理的 mission envelope 分离，确保后续任何裁决都能回溯到“用户究竟说了什么”，而不是只能看到被解释后的版本。这里的 draft_mission_envelope 用来解决一个常见顺序问题：自然语言输入先被编译成草案；CR 检查当前 truth；通过后才成为 governed mission envelope。这样，CK 和 MK 的裁决始终建立在当前合法 state 上，而不是建立在旧 summary、side evidence 或 projection 上。

三层 kernel 的职责划分

三个 v0 typed schema 速览

为避免本文被读作纯哲学论证，下面给出三个 v0 typed schema 的关键片段。它们是 illustrative fragments，用来表达治理层如何从隐喻转化为可被测试、可被审计的对象；完整 contract 应放入 Chapter 4 Runtime Contract。

authority_relation_v0:
  relation:
    - owner
    - support
    - consult
    - recon
    - audit
    - routing
    - escalation
    - threshold_holder
    - execution
    - closure_authority
  bearer_role: <typed_role>           # 不是 persona
  bound_mission: <mission_id>
  allowed_acts: [observe, request, route, assign, support, audit_flag, escalate, report, decide, close]
  denied_acts: []
  unspecified_act_policy: hold_or_escalate
  scope_constraint: <scope_rule>
  evidence_requirement: <evidence_spec>
  granted_by: <root_or_derived_authority_ref>
  revocation_rule: <revocation_spec>

receipt_v0:
  receipt_kinds:
    - mission_intake
    - cr_current_truth_check
    - authority_decision
    - route_mode_decision
    - routing
    - participant_binding
    - council_assembly
    - execution
    - evidence_admission
    - audit
    - state_delta
    - non_promotion
    - closure
    - honest_stop
    - partial_handoff

mission_ir_v0:
  semantic_parse: <structured_request>
  epistemics:
    confidence: <score>
    unknowns: [<uncertainty>, ...]
  constitutional:
    authority_relations: [<authority_relation_ref>, ...]
    route_mode: single_authorized_actor | bounded_mandate_route | recon_or_hold_route | embedded_audit_route | temporary_council
  validation:
    closure_acceptance_conditions: [<condition>, ...]
  acts:
    - observe
    - request
    - route
    - assign
    - support
    - audit_flag
    - escalate
    - report
    - decide
    - close

Schema validation 只能证明对象在结构上符合 contract；它不能单独证明行为已经发生，也不能单独证明行为被授权。语义层面的 enforcement 需要 adjudicator 对 authority decision、route mode decision、conditional routing、conditional council assembly、participant binding、execution receipt、evidence admission receipt、state transition policy、state_delta / non-promotion 和 closure receipt 进行交叉核验。因此，一个 fork 或 mission trace 是否可被治理层承认，不取决于自然语言是否顺畅，也不只取决于单个 JSON 是否通过 schema。真正的 runtime enforcement 来自 adjudicator 对 receipt graph 的跨对象核验。

2.8 文献坐标：与最近邻的边界

Positioning against adjacent work

为避免与近邻工作产生命名碰撞或主张重叠，本节明确本文的论证边界。本文不以“首创”或“替代”为论证策略；本文讨论的是在既有 agent runtime、persistent runtime、multi-agent framework、RBAC、provenance 与 constitutional 命名空间之上，如何把长期任务中的 authority、evidence、state delta 与 closure 固化为 typed runtime objects。

本文的核心可声明主张可以压缩为四条：

1. Constitutional Runtime architecture 是长期多 agent 任务系统之上的治理型 runtime architecture，用来维护 current truth、authority boundary、evidence gate、state delta、audit receipt 与 lawful closure。
2. CK 提供 executable authority relations，区分 ownership、support、consult、recon、routing、audit、escalation、threshold holding、execution 与 closure authority。
3. MK 把自然语言请求定义为经过 mission envelope、route-mode decision、conditional routing、conditional council assembly、participant binding、execution / audit / state-delta / non-promotion / closure receipts 的可治理对象。
4. Agent、runtime endpoint、plugin 与 gateway 都是 capability surfaces；它们可以执行任务片段，但不会自动成为 mission owner、law source 或 sovereign center。

因此，本文后续将以 typed-receipt governance for persistent multi-agent mission execution 作为主要分析标签；Constitutional Runtime architecture 则指这一治理路径在长期任务系统中的架构化表达。这个定位避开与 Agent-OS / AgentOS 等命名空间上的直接竞拼，同时保留本文的实际差异点：typed receipts as first-class enforcement objects, not metaphors.

2.9 本章收束：从缺陷诊断进入系统结构

From diagnosis to architecture

本章的结论可以更审慎地表述为：长期 multi-agent 系统不会因为增加 agent 数量而自然可靠。只有当任务、权限、证据、状态变更与结案都成为可执行、可审计、可撤销的 runtime objects 时，系统才具备进入长期工作的结构条件。

这不是唯一可能解。强化 RBAC、状态机、workflow policy、issue / PR lifecycle、audit log 都可以承接部分问题。本文的差异主张不在于“必须使用这些对象”，而在于：当治理对象被做成 typed、versioned、receipt-bearing runtime object 时，系统可以在不依赖自然语言自我解释的情况下进行独立复核。

我们并不否定 agent runtime OS，也不否定 single-agent system 的工程价值。相反，本文承认 memory、tools、workflow、gateway、handoff、daemon 与 sub-agent sessions 都是必要能力。问题在于，这些能力本身不构成组织结构。真正需要补上的，是让能力在长期任务中受治理地进入、行动、留证、复核与退出的 runtime structure。

结构对照表

由此，第二章完成了从缺陷诊断到系统结构的转换。长期 multi-agent 系统不能只依赖 capability stack；它还需要一组 mission-bound governance boundaries：authority、evidence、state transition、coordination shape、participant binding 与 closure。第三部分将不再继续放大问题诊断，而是把这些边界压缩成八轴系统：CR、CK、MK、AG、CP、SM、DG 与 EP。换言之，本章的作用是证明“能力不等于组织”；第三部分要回答“组织如何被编译成 runtime”。

References

[R1] Anthropic. “Building effective agents.” https://www.anthropic.com/engineering/building-effective-agents
[R2] Anthropic. “Effective context engineering for AI agents.” https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
[R3] Anthropic. “Effective harnesses for long-running agents.” https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents ; “Demystifying evals for AI agents.” https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
[R4] Anthropic. “How we built our multi-agent research system.” https://www.anthropic.com/engineering/multi-agent-research-system
[R5] OpenAI. “A practical guide to building AI agents.” https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
[R6] OpenAI Agents SDK. “Models / MultiProvider / tracing / handoffs / guardrails.” https://openai.github.io/openai-agents-python/
[R7] Hugging Face Agents Course. “Multi-Agent Systems.” https://huggingface.co/learn/agents-course/unit2/smolagents/multi_agent_systems
[R8] W3C. “PROV-DM: The PROV Data Model.” https://www.w3.org/TR/prov-dm/
[R9] Seamus Brady. “Springdrift: An Auditable Persistent Runtime for LLM Agents with Case-Based Memory, Normative Safety, and Ambient Self-Perception.” arXiv:2604.04660v1.
[R10] Yuren Mao et al. “Agent-Kernel: A MicroKernel Multi-Agent System Framework for Adaptive Social Simulation Powered by LLMs.” arXiv:2512.01610v1.
[R11] OWASP. “AI Agent Security Cheat Sheet.” https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
[R12] NIST. “Role-Based Access Control: Features and Motivations.” https://www.nist.gov/publications/role-based-access-control-rbac-features-and-motivations
[R13] GitHub Docs. “About GitHub Copilot cloud agent.” https://docs.github.com/copilot/concepts/agents/coding-agent/about-coding-agent ; “Kick off a task with Copilot agents on GitHub.” https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/kick-off-a-task ; GitHub Blog. “GitHub Copilot: Meet the new coding agent.” https://github.blog/news-insights/product-news/github-copilot-meet-the-new-coding-agent/
[R14] Bai et al. “Constitutional AI: Harmlessness from AI Feedback.” arXiv:2212.08073. 本文中的 Constitutional Runtime architecture 与该训练时对齐方法处于不同层次。
[R15] Anthropic Claude Code Docs. “Create custom subagents.” https://code.claude.com/docs/en/sub-agents
[R16] Hugging Face smolagents. “Agents API reference.” https://huggingface.co/docs/smolagents/en/reference/agents

附录 A：公开命名映射

附录 B：Mermaid 图源码

正文 PDF / DOCX 中使用根据 v7.3 内容重新生成的渲染图；Markdown 与 HTML 保留可复用的图义说明。以下 Mermaid 源码可作为后续重绘基准。

Figure 2.1 / 图 2.1 Mermaid 源码

flowchart TB
 A[Root Owner / Request<br/>根所有者 / 请求<br/>chat · CLI · API · issue] --> B[Constitutional Runtime<br/>CR current truth · CK authority · MK mission lifecycle]
 L[Authority Gate<br/>owner · support · recon<br/>routing · audit · escalation · closure authority] --> B
 R[Evidence Gate<br/>memory → evidence<br/>state_delta → receipt<br/>non-promotion → receipt] --> B
 B --> C[Execution Adapter Layer<br/>gateway · provider router · workflow engine · tools · sub-agent sessions<br/>replaceable; mission sovereignty remains above]
 C --> D1[Runtime A<br/>agent runtime]
 C --> D2[Runtime B<br/>gateway / channels]
 C --> D3[Runtime C<br/>tool registry / MCP]
 C --> D4[Runtime D<br/>sub-agent session]
 D1 -. outputs / artifacts / traces / receipts .-> C
 D2 -. outputs / artifacts / traces / receipts .-> C
 D3 -. outputs / artifacts / traces / receipts .-> C
 D4 -. outputs / artifacts / traces / receipts .-> C

Figure 2.2 / 图 2.2 Mermaid 源码

flowchart LR
 CAN[CAN / 执行能力<br/>搜索 · 写文件 · 调用工具 · 维护 session<br/>回答：这个节点能做什么动作？]
 MAY[MAY / 授权与归属<br/>为哪个 mission 做？谁授权？<br/>会改变什么 state surface？能否 closure？]
 COST[混淆的代价<br/>能调工具被误读成有权改任务<br/>endpoint 在线被误读成主权中心]
 RULE[正确的运行规则<br/>每次能力调用绑定 mission_id<br/>authority_relation · evidence · receipt]
 CAN -->|需要治理层裁决| MAY
 CAN -.-> COST
 MAY -.-> RULE

Figure 2.3 / 图 2.3 Mermaid 源码

flowchart LR
 A[Raw Request / Sidecar<br/>原始请求 + 入口元数据<br/>保留未解释版本] --> B[Draft Mission Envelope<br/>任务封套草案<br/>owner · scope · constraints]
 B --> C[CR Truth Check<br/>当前真值检查<br/>canonical / projection split]
 C --> D[CK Authority<br/>权限裁决<br/>ALLOW · DENY · HOLD · ESCALATE]
 D --> E[Route Mode Decision<br/>路由模式裁决<br/>single · bounded · council?]
 E --> F[Routing / Binding<br/>条件路由 + 参与者绑定<br/>routing? · council? · binding?]
 F --> G[Execution / Evidence<br/>执行片段 + 证据准入<br/>capability call → receipt]
 G --> H[Audit / State Transition<br/>审计? + 状态转移<br/>delta · non-promotion · no mutation]
 H --> I[Closure / Stop / Handoff<br/>结案 / 诚实停止 / 部分移交]
 G -. 证据不足或 audit 未解除 → 返回执行片段 .-> E

Figure 2.4 / 图 2.4 Mermaid 源码

flowchart TB
 U[User-facing Surface<br/>Chat · CLI · Issue · Web UI] --> M[Mission Object<br/>mission_id · owner · authority<br/>evidence · state_transition · closure]
 M --> P[Runtime Participants<br/>typed participants<br/>not law sources]
 M --> R{route_mode_decision}
 R --> A[single actor<br/>低风险 / 明确 owner]
 R --> B[bounded mandate<br/>预定义 scope / mandate]
 R --> C[recon / hold<br/>目标不清或证据不足]
 R --> D[embedded audit<br/>高风险或需复核]
 R --> E[temporary council<br/>跨域 / 会审 / 特殊审计]
 RC[Receipt Chain<br/>intake → CR truth → authority → route_mode → routing? → council?<br/>participant_binding? → execution → evidence → audit? → state_transition → closure]
 R --> RC

Figure 2.5 / 图 2.5 Mermaid 源码

flowchart TB
 W[Constitutional Runtime Architecture（广义整体架构）]
 CR[CR axis: current truth / lawful transition<br/>canonical state · truth gateway · evidence promotion · non-promotion receipt]
 CK[CK: executable authority law<br/>owner · support · consult · recon · routing<br/>audit · escalation · threshold · execution · closure]
 MK[MK: mission lifecycle governance<br/>mission envelope · route mode decision · receipts · closure / honest stop]
 A[Adjudicator<br/>ALLOW · DENY<br/>HOLD · ESCALATE]
 G[Receipt Graph<br/>跨对象核验<br/>非单个 schema]
 W --> CR --> CK --> MK
 A --> CK
 G --> CK