三平面模型

May 20, 2026 · View on GitHub

本文是 01-constitution.md 的解释性文档,用于展开 Agent、Turn 与完整语义三个平面的边界、正面意义与相互关系。

本文不新增系统本体,不改变宪法条文的法律效力。若本文与 01-constitution.md 冲突,以宪法为准。

0. 阅读方法

01-constitution.md 负责给出正式法条,回答“什么必须成立”“什么默认不成立”“什么关系不得被破坏”。

本文负责回答另一组问题:

  • 这些法条在系统结构上分别落在哪个平面?
  • 它们为什么要这样写?
  • 它们积极建立了什么秩序?
  • 它们又刻意没有替实现层决定什么?

如果说宪法是在立法,本文就是释法。

1. Agent 平面

1.1 Agent 是什么

Agent 是 CommonGround 中可被委托、可承担责任、可产生语义事实的稳定逻辑主体。

“稳定逻辑主体”有两层含义:

  1. 它必须是协作系统中可被指称、可被授权、可被追责的正式对象。
  2. 它不能被宿主、进程、容器、会话或网络端点等运维 substrate 直接替代。

这意味着:Agent 可以被重新部署、迁移宿主、以不同进程继续工作,而不必因此失去其逻辑身份。

1.2 Agent 的实现形态不是本体

宪法要求 Agent 是稳定逻辑主体,但没有要求它必须是某一种认知机制、模型类型或交互范式。

这意味着,CommonGround 中的 Agent 可以由不同形态承载,例如:

  • 基于 LLM 的 conversation agent
  • 负责拉起其他主体的 provision agent
  • 直接执行业务规则的 deterministic service agent
  • 负责连接外部系统的 gateway agent
  • 人机混合、脚本驱动或其他受约束 runtime 提供的执行主体

这些例子可以帮助解释当前实现与接入方式,但它们不是新的本体枚举,也不是唯一允许的分类法。

真正决定某个对象是否应被建模为 Agent 的,不是它“像不像 chatbot”,而是它是否以自己的稳定身份进入协作秩序,能够被委托、被授权、被追责,并以该身份产生正式语义事实。

因此,系统不应把“是否由 LLM 驱动”误当成 Agent 的成立条件,也不应把“当前是某个 service / gateway / worker 进程在提供能力”误当成该进程本身已经是正式主体。

在产品、接口或部署语境中,可以把某些非对话式、非 prompt-facing、由受控后台系统承载的 Agent 称为 Service,例如 Admin Service、Nanobot Provision Service 或 Gateway Service。这个名称只用于降低误解:Service 仍然落在 Agent 平面,不是第四平面,也不会因为叫 Service 就绕过 Agent 的授权、审计、控制边界和失效规则。

更具体的接入判断如果属于 active public surface,应写入当前 guide。历史接入笔记不定义当前真源。

1.3 Agent 身份与部署 substrate 的边界

CommonGround 可以观察到某个 Agent 最近是否活跃、从哪个入口接入、由哪个 runtime 提供服务,但这些都只是协作和运维上的观察信号。

它们可以影响 admission、调度、解释和排障,但不自动构成正式身份,也不自动构成执行权。

因此,系统不应把“现在连得上某个进程”误当成“该进程就是正式主体”,也不应把“某个 Agent 目前离线”误当成“其逻辑身份已不存在”。

1.4 能力、可用性与授权

Agent 可以声明能力,可以暴露适配性,可以呈现健康状态、负载与接活意愿。

这些信息有积极意义:

  • 帮助系统与人类理解谁适合接什么工作
  • 帮助 admission 与 routing 做受约束判断
  • 帮助 operator 观察系统当前的工作形态

但这些信息本身不等于控制权。

能力是“能做什么”的陈述;授权是“被允许做什么控制动作”的正式边界。元宪法要求二者分离,否则能力描述就会被偷偷升级为权力来源。

1.5 Agent 并发与连续性不是默认自然事实

同一 Agent 是否可以并发推进多个 Turn,不应靠实现偶然性决定。

一旦系统允许并发,它就必须回答:

  • 语义是否隔离
  • 会话是否隔离
  • 执行授权如何防冲突
  • 历史材料如何被读取
  • 连续性影响落在什么层级

因此,“单线程 Agent”不是宪法公理,“天然可并发 Agent”也不是宪法公理。二者都属于需要显式建模的设计选择。

2. Turn 平面

2.1 Turn 是什么

Turn 是 CommonGround 中最小的 durable work boundary。

它把一段正式工作收拢成一个可指称、可审计、可恢复的边界。这个边界至少要能回答:

  • 这段工作从何而来
  • 后续控制权如何成立
  • 它现在处于什么状态
  • 它是否已经终结
  • 它的正式语义边界是什么

因此,Turn 不是单条消息,也不是单条同步回复。它更像一份可持续观察、可因果追溯的工作壳。

2.2 Turn 的出生边界

Turn 必须通过受控出生边界创建。

出生边界的积极作用是同时建立:

  • 工作边界
  • 初始语义边界
  • 因果来源
  • 后续控制权来源或其显式解析机制

这里最重要的不是“出生时一定绑定某个具体实现对象”,而是“出生后谁能继续控制、基于什么制度继续控制,必须从出生边界开始就是可解释的”。

2.3 Requester、owner 与 controller

一个 Turn 可以有不同角色:

  • requester:促成出生的一方
  • owner 或后续控制边界中的合法主体:负责推进 Turn 的一方
  • observer / operator:可观察或在受约束条件下干预的一方

宪法强调这些角色不能自动混同。

这样做的正面意义是:系统能够支持委托、监督、派生与恢复,而不会把“谁先说话”误写成“谁永远有权”。

2.4 Turn 的生命周期

Turn 可以经历等待执行、执行中、暂停等待事实、终结等状态。

这些状态的意义不只是“显示一个状态机”,而是为恢复和问责提供正式语境:

  • 什么时候还能推进
  • 谁还能推进
  • 什么动作已经不再合法
  • 什么事实已经进入终局

Kernel 可以做 safety-oriented 的状态收敛,但不能把复杂业务策略写成内建自动机。

2.5 Turn 的控制边界与恢复

恢复必须建立在 durable facts 上。

当某个 Turn 因等待外部事实而暂停时,后续主体应通过 durable feed、query 或其他正式观察面回到事实,再决定是否继续推进。

这里的关键不是“系统有没有自动通知”,而是“即使通知丢失,仍然能从 durable truth 回到正确判断”。

2.6 Child 派生

Turn 可以派生 child Turn,但 child 是新的工作边界,而不是 parent 的一个隐藏 continuation。

因此:

  • child 有自己的生命周期
  • child 有自己的完整语义
  • child 完成自己的工作
  • parent 只能观察 child 的事实
  • parent 是否吸收 child 的结果,必须由 parent 合法控制边界内的主体决定

这条区分,是 CommonGround 避免重新滑回“中心共享会话池”的关键。

3. 完整语义平面

3.1 完整语义的积极意义

完整语义不是“把所有内容都存下来”的口号,而是某个 Turn 正式拥有的语义边界。

它的积极意义在于:

  • 为该 Turn 提供可恢复的判断材料
  • 为该 Turn 的结果与过程建立可审计记录
  • 为后续观察、争议处理与问责提供语义依据

因此,完整语义是一种正式归属关系,而不是单纯的日志容器。

3.2 完整语义可以承载什么

完整语义可以承载多种类型的正式语义材料,例如:

  • 初始输入
  • 当前 Turn 主动吸收的观察
  • 过程中的正式记录
  • 工具或外部观察摘要
  • 最终交付物
  • 错误与终止原因

这里的重点不在于列目录,而在于:这些内容一旦进入完整语义,就成为“该 Turn 正式拥有的语义事实”。

3.3 归属与内容本体分离

完整语义负责回答的是:

  • 哪个 Turn 拥有什么语义事实
  • 这些事实在该 Turn 中按什么顺序和角色出现

内容层负责承载具体内容本体。

所以,完整语义可以引用内容层,但内容层本身不替代语义归属。一个内容对象被很多地方复用,不等于它自动属于所有 Turn。

3.4 初始语义是出生例外

Turn 出生时,上游可以为新 Turn 提供初始语义上下文。

这是因为新工作边界不能在“完全无上下文”的真空中出生。

但这个例外的意义是帮助新 Turn 建立自己的工作边界,而不是让上游在出生后继续以未建模方式写入该 Turn 的完整语义。

3.5 读取完整语义是为了恢复当前 Turn 的判断

当主体认领、恢复或审计某个 Turn 时,它需要读取该 Turn 已有的完整语义与因果事实,以恢复对当前 Turn 的判断。

这个“恢复判断”指的是:

  • 了解当前 Turn 已经发生了什么
  • 识别哪些观察已经被正式吸收
  • 判断当前还有什么合法动作可做

它不等于默认恢复 Agent 私有状态,也不等于默认把旧历史提升为 Agent-native memory substrate。

4. 默认法律效力

4.1 可读不等于有法律效力

系统中很多材料都可以被读取、展示、搜索、汇总、解析。

但“可读”不等于“自动有法律效力”。

这条区分在 CommonGround 里非常关键,因为大量材料都以 durable 形式存在,如果不区分“存在”与“效力”,系统很快就会把任何能读到的东西都误当成 truth 或 authority。

4.2 旧 Turn 历史的默认效力

旧 Turn 的 semantic、context、feed、过程记录、中间 deliverable、观察摘要与诊断材料,默认提供的是:

  • inspect
  • audit
  • reference
  • shared observation

这些效力本身是积极的、必要的。没有它们,系统就失去解释力、恢复力和审计力。

但它们默认只到这里为止。

4.3 默认不成立的效力

除非另有显式建模,旧 Turn 历史不自动产生:

  • Agent 私有状态恢复效力
  • 身份连续性证明效力
  • 授权连续性证明效力
  • contract effect
  • 其他 machine-authoritative effect

也就是说,宪法限制的不是“读历史”这件事,而是“历史自动变成权力或连续性底座”这件事。

4.4 CommonGround 不是 Agent-native memory 的默认真源

CommonGround 保存的是跨主体协作所需的公共事实,而不是 Agent 私有内在状态的默认真源。

因此,面向用户的 session continuity、内部思考、长期记忆、runtime-local 工作内态,以及 reboot 后继续工作的私有 continuity substrate,不应被默认建模为 CommonGround truth。

这并不禁止某个 Agent 或 runtime 显式读取旧历史作为外部参考;它只是否定一种默认推定:CG 自动拥有 Agent 私有连续性的真源地位。

4.5 Machine-authoritative effect 必须显式建模

某条记录若要产生 machine-authoritative effect,系统必须能明确回答:

  • 它究竟在产生什么效力
  • 这个效力作用于哪个边界
  • 为什么这种效力不是 mere persistence 自动带来的

“显式建模”约束的是效力如何成立,而不是预先规定唯一 schema、唯一 parser 或唯一实现路径。

5. 平面间关系

5.1 允许引用,不允许混同

三个平面之间可以互相引用:

  • Turn 可以引用 Agent
  • 完整语义可以引用 Turn
  • durable facts 可以引用 Agent、Turn 与语义对象

但引用不等于混同。

Agent 不等于 Turn。 Turn 不等于完整语义。 完整语义不等于执行权。 durable facts 不等于自动有效的法律关系。

5.2 为什么这不是在冻结实现形态

三平面模型规定的是最小本体与默认效力边界,而不是唯一实现路径。

它不直接规定:

  • 只能用哪种 runtime
  • 只能用哪种 host model
  • 只能用哪种 concurrency policy
  • 只能用哪种 projection 结构
  • 只能用哪种 contract fact 载体

它真正规定的是:无论你选哪种实现,它都不能越过这些法定边界。

5.3 为什么这套结构有正面建制意义

这套结构并不只是“限制系统别做错事”。

它也积极建立了:

  • 正式主体
  • 正式工作边界
  • 正式语义归属
  • 正式控制边界
  • 正式默认法律效力

正因为这些东西被明确定义,上层 agent runtime、projection、companion、operator governance 与集成系统,才有稳定公共秩序可依附。

6. 收束

01-constitution.md 回答的是:什么是 CommonGround 内核的法定秩序。

本文回答的是:这些法定秩序为什么这样成立,以及它们如何在 Agent、Turn 与完整语义三个平面中展开。

若要判断一个设计是否违背这些边界,继续看 03-design-review-principles.md