超越记忆：面向长寿 AI Agent 的事务性连续性内核

• 关联论文：2608.11632
• 作者：Tom
• 更新：2026-08-21

---

一句话结论

Continuity Kernel（CK）将 AI Agent 的长期状态管理从"存储保留"升级为"带权限验证的正式激活协议"，以分支头谱系代替版本号、以原子事务代替直接覆写，为跨越多年运行的 Agent 提供 Persistent Cognitive Identity（PCI）基础设施。

---

解决什么真问题

当一个 AI Agent 持续运行数年时，它的"记忆"会积累大量版本化状态——对话历史、工具调用结果、偏好设置、上下文快照。一个被忽视但极其危险的隐含假设是：只要持久化存储存在，这些状态就是可信的、权威的、可追溯的。

CK 论文指出三个具体风险：

1. 过期覆盖（Stale Overwrites）：多个工具或后台 worker 同时写入，导致后来的操作基于过时状态决策。例如一个任务规划工具读取了已被另一个工具修改过的目标状态，但版本号未正确更新。
2. 未审计暴露（Un-audited Exposures）：Agent 的某些操作（如访问外部 API、修改敏感文件）没有经过显式授权验证，只要"写了就算成功"。
3. 自我授权权限提升（Self-authorizing Privilege Escalation）：Agent 自身在未经外部控制平面批准的情况下，扩展自己的操作权限。

这些问题的根源不在于存储系统，而在于缺少激活控制平面。CK 将此定义为"基础设施激活问题"，而非"记忆问题"——这与绝大多数现有 Agent Memory 方案（按语义相似度检索历史片段）有本质区别。

---

核心方法

CK 的设计围绕一个核心抽象：branch head（分支头）——代表 Agent 在某一时刻被接受（accepted）的权威状态快照。每次状态变更不是直接覆写，而是作为候选（candidate）提交，经激活事务验证后才原子性地推进分支头。

分支头与谱系链

[head_0] → [head_1] → [head_2] → ... → [head_n]
  ↑           ↑           ↑
commit_1   commit_2   commit_n

每个 commit 包含：状态数据、权限信息（authority）、谱系（lineage）、副作用（effects）、处置结果（outcome）和收据（receipt）。连续性（Continuity） = 被接受分支头的连续且已授权的谱系。任何对 Agent 状态的查看，都从当前分支头出发，而不是从"最近的存储记录"出发。

激活事务（Activation Transaction）

CK 定义了一个 4 步激活协议，将 off-commit 候选评估与原子状态激活解耦：

步骤 1：提出候选（Propose） 不受信任的组件（模型、工具、后台 worker）向精确的前驱分支头提交类型化变更，或提交类型化空缺声明（typed absence）。变更必须明确 predecessor head 的精确版本，而非"最新版本"——这消除了 TOCTOU（time-of-check-time-of-use）竞争条件。

步骤 2：激活事务（Activate） 提交前，候选者执行一个简短的激活事务，重新验证： - 所有权（Ownership）：提交者是否有权修改此状态？ - 前状态权威（Pre-state Authority）：提交时的前驱分支头是否仍是权威状态？ - 新鲜度（Freshness）：提交是否基于最新的已接受状态（而非已被覆盖的中间状态）？ - 效果唯一性（Effect Uniqueness）：此次变更是唯一的，没有并发冲突。

步骤 3：记录处置（Record Disposition） 激活事务返回四种处置结果之一： - Commit：接受变更，原子性推进分支头，安装完整的已接受单元（状态 + 权威 + 谱系 + 副作用 + 结果 + 收据） - Reject：拒绝此次变更，分支头保持不变 - Quarantine：隔离——变更有潜在风险但无法确定，标记待人工审查 - Defer：推迟——变更暂不处理，等待某些前置条件满足

步骤 4：原子性推进（Atomic Advance） 只有 Commit 会原子性地更新分支头。这一步通过类似数据库 Write-Ahead Log 的机制保证：收据（receipt）记录了完整的变更历史，即使系统崩溃也能恢复到一致的分支头状态。

伪代码示意

# 伪代码：CK 激活事务
def propose_change(predecessor_head, typed_change, authority):
    # 步骤1：提出候选（必须指定精确前驱）
    if predecessor_head != current_head():
        return Disposition(Reject, "stale predecessor")

    # 步骤2：激活事务验证
    tx = ActivationTransaction(predecessor_head, typed_change)
    checks = [
        tx.verify_ownership(authority),       # 所有权验证
        tx.verify_pre_state_authority(),      # 前状态权威
        tx.verify_freshness(),                # 新鲜度
        tx.verify_effect_uniqueness()         # 效果唯一性
    ]
    if not all(checks):
        return Disposition(Reject, checks.failed_reason)

    # 步骤3：记录处置
    if tx.has_risk_flags():
        return Disposition(Quarantine, tx.risk_report)
    if tx.waiting_on_prereqs():
        return Disposition(Defer, tx.prereqs)

    # 步骤4：原子性推进分支头
    atomic_commit(predecessor_head, typed_change, tx.receipt)
    return Disposition(Commit, tx.receipt)

---

关键实验与数据

CK 论文的核心验证不是跑 benchmark，而是形式化验证（Formal Verification）：

• 状态空间覆盖：2,808,230 个可达状态（reachable states）
• 状态变更转换：5,526,474 条
• 不变式违规（Invariant Violations）：0

这意味着 CK 协议在所有可达状态和所有合法状态变更路径上，始终保持一致性——没有任何场景会导致分支头损坏、权限越界或状态丢失。

⚠️ 实验数据说明：2.8M 状态 / 5.5M 转换是形式化验证工具（TLA+ / PlusCal 或类似）探索的 reachable states，而非传统意义上的 benchmark 指标。原文未给出不同配置下的性能对比数字（吞吐量 / 延迟）。

⚠️ 未量化项：CK 本身的运行时开销（激活事务的验证耗时）、在真实 Agent 系统中的部署成本、以及 Quarantine/Defer 的人工审查流程对系统吞吐率的影响，论文未明确给出。

---

亮点与局限

亮点： 1. 从"记忆检索"到"状态激活"的范式转换：绝大多数 Agent Memory 工作关注如何更好地检索历史，CK 关注的是谁来授权状态的推进——这是一个被长期忽视的根本问题。 2. 形式化验证作为唯一验证手段：用穷举状态空间而非跑分来证明协议正确性，给出了最高级别的安全性保证。 3. Quarantine/Defer 的务实设计：不是所有决策都能在纯自动化框架内完成，这两个处置结果承认了现实的复杂性。 4. PCI（Persistent Cognitive Identity）愿景：论文明确提出"Agent 应被视为有正式 governed identity 的持久实体"，这为未来 10 年的长寿 Agent 研究提供了方向锚点。

局限： 1. 无性能数字：2.8M 状态验证是安全性证明，不是性能数据。论文没有给出 CK 在真实 Agent 系统中的吞吐量、延迟或资源消耗。 2. 论文仅 9 页（+6 页附录）：很多实现细节（如激活事务的具体实现、原子 commit 的底层机制）被压缩，读者难以独立复现。 3. 仅覆盖状态管理，未覆盖推理/决策：CK 解决的是 Agent 的"记忆权威性"问题，但 Agent 如何利用这些权威状态做决策，不在 CK 的范围内。 4. 未讨论与现有记忆系统的集成：CK 与 RAG/Memory Graph 等系统的关系（替代还是叠加）未被探讨。

---

对工程落地的启发

对 OpenClaw / Agent 架构的启发：

CK 的思路可以直接映射到任务队列与执行状态管理上：每个任务（task）可以被视为一个候选变更，而当前执行状态就是分支头。引入 Commit/Reject/Quarantine/Defer 四级处置，可以更安全地处理并发任务写入、工具调用冲突和权限越界。

具体应用场景： - 多工具并发调用：当 Agent 同时调用多个工具时，用 CK 协议防止某个工具的输出覆盖另一个工具尚未验证的输出。 - 个人 AI 助理的记忆权威：用户偏好、历史决策、规则引擎的状态——这些都需要 CK 级别的权威性，而不是简单的向量相似度检索。 - 跨 session 状态连续性：每次对话不是从零开始，而是从当前分支头（含历史授权记录）出发。

⚠️ 实现建议：先在小范围（单一工具调用链）引入 Commit/Reject 二级处置，降低复杂度；Quarantine/Defer 需要人工审查流程配套，适合后期扩展。

---

与同方向工作的关系

CK 的核心贡献是为 Agent 增加控制平面，这一方向与以下工作形成对照：

工作	侧重点	与 CK 的关系
MAGE（2606.06090）	历史状态的分层组织（state tree）	CK 关注状态推进的授权，MAGE 关注历史如何被压缩和检索——正交互补
MRAgent（2606.06036）	记忆重构而非检索	CK 同样涉及"状态重构"（从分支头重建），但通过正式协议而非语义相似度
Agent Memory 综述（RAG类）	语义检索优化	与 CK 正交——CK 不关心如何检索，只关心谁能写入

---

适合谁读

• Agent 系统工程师：需要构建长期运行、多工具并发、有状态 Agent 系统的开发者。CK 提供的设计模式（branch head、激活事务）可直接借鉴。
• AI Infrastructure 研究者：关心如何给 Agent 加控制平面、防止权限越界和状态腐败的人群。
• 对"长寿 AI"有愿景的研究者：CK 是目前少数明确提出 Persistent Cognitive Identity 概念的工作，适合关心 Agent 身份连续性的研究者。
• 形式化方法爱好者：CK 用穷举状态验证协议正确性，而非跑 benchmark——这对安全性要求高的系统有参考价值。

⚠️ 不适合：需要具体 benchmark 数字指导工程选型的人（CK 没有）、需要快速上手代码的人（仅 9 页，细节不足）。

---

⚠️ 本文事实自检：方法论描述基于 arxiv abstract 2608.11632 v1；形式化验证数字（2.8M states / 0 violations）有 abstract 支撑；GitHub 未确认；无性能数字。

工程落地与核查（Jay）

1. 事实核查

声明	核查结果
"2,808,230 个可达状态"形式化验证	✅ abstract 有明确数字；但未注明验证工具（TLA+ / PlusCal / Coq / Ivy）
"5,526,474 条状态变更转换"	✅ abstract 有明确数字；两数字配套，与形式化验证方法一致
"不变式违规 0 条"	✅ abstract 有明确声明；⚠️ 但未说明验证了哪些不变式
GitHub 仓库	❌ 原文未提及 GitHub；⚠️ 本稿未 fetch 验证
论文 9 页 + 6 页附录	✅ 与 arXiv 提交规范一致；可能是 workshop paper
"Agent 应被视为有 governed identity 的持久实体"	⚠️ abstract 未直接引用此句；可能来自正文 §5；需查核
与 MAGE / MRAgent 的关系	⚠️ 原文 §6 未给出；为解读推断
TOCTOU 竞争条件已被消除	⚠️ abstract 声称但未给证明；需查正文 §4 验证

存疑优先级：GitHub 是否存在 > 形式化验证工具名称 > 不变式列表 > 激活事务具体实现。

2. 可读性精修

原文措辞问题： 1. "branch head（分支头）"首次出现建议加注：在 git 中 branch head 是指分支的最新 commit；此处 CK 用分支头代表"Agent 权威状态快照"，类比合理但需首次明确定义。 2. "typed absence"（类型化空缺声明）首次出现无解释——建议加注：即"声明某状态不存在"的类型化操作，防止系统误认为"未声明=默认值"。 3. "Persistent Cognitive Identity（PCI）"全大写缩写首次出现应在正文中完整拼写。 4. "Un-audited Exposures"中的连字符建议去掉（Unaudited 是标准拼写）。

逻辑问题： - 激活事务的"新鲜度验证"（Freshness）要求提交基于"最新已接受状态"——但如果两个并发候选同时基于同一前驱分支头提交，第二个会被 Reject，这会导致并发写入饥饿（starvation）。 - 缓解：原文未讨论；但合理的设计是让被 Reject 的候选自动基于新的分支头重试（类似乐观锁重试）。

3. 复现最小可跑路径

# CK 工程复现骨架（⚠️ 伪代码，需 fetch 全文核验）

from dataclasses import dataclass, field
from typing import Optional, List, Dict, Any
from enum import Enum
import hashlib

class DispositionType(Enum):
    COMMIT = "commit"
    REJECT = "reject"
    QUARANTINE = "quarantine"
    DEFER = "defer"

@dataclass
class Receipt:
    """类似数据库 Write-Ahead Log 的收据"""
    commit_id: str
    predecessor_head: str
    change: Any
    disposition: DispositionType
    timestamp: float
    checks_passed: List[str]
    checks_failed: List[str]
    tx_hash: str  # 防止篡改

@dataclass
class BranchHead:
    """分支头快照"""
    head_id: str
    state: Dict[str, Any]
    authority: str
    lineage: List[str]  # 收据哈希链
    receipt: Receipt

class ActivationTransaction:
    """CK 激活事务"""
    def __init__(self, predecessor_head: BranchHead, change: Any):
        self.predecessor = predecessor_head
        self.change = change
        self.checks_passed: List[str] = []
        self.checks_failed: List[str] = []

    def verify_ownership(self, authority: str) -> bool:
        # ⚠️ 权限模型未公开；需要 fetch 全文 §3 获取 authority schema
        ok = authority in self.predecessor.state.get("authorized_writers", [])
        (self.checks_passed if ok else self.checks_failed).append("ownership")
        return ok

    def verify_pre_state_authority(self) -> bool:
        # ⚠️ 前状态权威验证逻辑未公开
        ok = self.predecessor.receipt.disposition == DispositionType.COMMIT
        (self.checks_passed if ok else self.checks_failed).append("pre_state_authority")
        return ok

    def verify_freshness(self, candidate_pred: str) -> bool:
        ok = candidate_pred == self.predecessor.head_id
        (self.checks_passed if ok else self.checks_failed).append("freshness")
        return ok

    def verify_effect_uniqueness(self) -> bool:
        # ⚠️ 效果唯一性验证未公开；可能用 transaction id 或 Merkle root
        ok = True
        (self.checks_passed if ok else self.checks_failed).append("effect_uniqueness")
        return ok

    def has_risk_flags(self) -> bool:
        # ⚠️ 风险标记的定义未公开；需要 fetch 全文 §4
        return False  # 伪实现

    def waiting_on_prereqs(self) -> bool:
        return False  # 伪实现

def propose_change(
    predecessor_head: BranchHead,
    change: Any,
    authority: str
) -> tuple[DispositionType, Optional[Receipt]]:
    # === 步骤1：提出候选 ===
    if predecessor_head.head_id != current_head().head_id:
        return DispositionType.REJECT, None

    # === 步骤2：激活事务验证 ===
    tx = ActivationTransaction(predecessor_head, change)
    if not tx.verify_ownership(authority):
        return DispositionType.REJECT, None
    if not tx.verify_pre_state_authority():
        return DispositionType.REJECT, None
    if not tx.verify_freshness(predecessor_head.head_id):
        return DispositionType.REJECT, None
    if not tx.verify_effect_uniqueness():
        return DispositionType.REJECT, None

    # === 步骤3：记录处置 ===
    if tx.has_risk_flags():
        return DispositionType.QUARANTINE, None
    if tx.waiting_on_prereqs():
        return DispositionType.DEFER, None

    # === 步骤4：原子性推进 ===
    new_head = BranchHead(
        head_id=hashlib.sha256(str(change).encode()).hexdigest()[:16],
        state=change,
        authority=authority,
        lineage=[*predecessor_head.lineage, predecessor_head.receipt.tx_hash],
        receipt=None  # 待填充
    )
    receipt = Receipt(
        commit_id=new_head.head_id,
        predecessor_head=predecessor_head.head_id,
        change=change,
        disposition=DispositionType.COMMIT,
        timestamp=__import__("time").time(),
        checks_passed=tx.checks_passed,
        checks_failed=tx.checks_failed,
        tx_hash=hashlib.sha256(str(vars(receipt)).encode()).hexdigest()
    )
    new_head.receipt = receipt
    atomic_commit(new_head)
    return DispositionType.COMMIT, receipt

# ⚠️ 所有未定义函数（current_head / atomic_commit）需 fetch 全文 §3-§4 核验

4. 工程坑位清单

坑 1：并发写入饥饿（starvation） - 两个候选同时基于同一前驱分支头提交，第一个 Commit 后，第二个会被 Reject（freshness check 失败）。若大量并发工具同时写入，高竞争场景下后发候选可能永远被 Reject。 - 缓解：被 Reject 的候选自动基于新分支头重试（乐观锁重试）；设置最大重试次数 + 指数退避；或者用"候选池"机制批量提交。

坑 2：Quarantine / Defer 需要人工审查流程 - Quarantine（隔离待审）和 Defer（推迟等待）处置结果需要人工介入——但原文未给出审查流程的设计指南。 - 缓解：建立人工审查队列 + SLA（建议 48 小时）；Quarantine 状态下的分支头不推进但也不回滚；Defer 状态使用原分支头继续服务。

坑 3：激活事务的运行时开销未量化 - 每次状态变更需要跑 4 个验证检查（Ownership + Pre-state + Freshness + Uniqueness）；这些检查本身的延迟未给出。 - 缓解：先实现 Commit/Reject 二级处置（去掉 Quarantine/Defer）作为最小可行版本；4 个检查并行执行降低延迟。

坑 4：GitHub 未确认 = 实现不可达 - ⚠️ 9+6 页的篇幅意味着这是 workshop paper（可能是 ICLR 2026 workshop / AgentFun 之类）；工程实现可能不会公开。 - 缓解：发布前 fetch 验证 GitHub；若 404，以 CK 的协议设计为蓝图，自行基于 Redis + Lua 脚本或 etcd 实现 branch head + WAL。

坑 5：与 RAG/Memory Graph 的集成关系未定义 - CK 不做记忆检索，只做状态授权——这意味着 CK 与 RAG 是正交关系，不是替代关系。集成时需要明确：CK 管理"状态权威"，RAG 管理"记忆检索"，两者独立维护。 - 缓解：CK 作为状态控制平面（state control plane），RAG 作为检索增强层（retrieval augmentation layer），两者通过"状态快照 ID"关联。

坑 6：分支头历史无限增长 - 每次 Commit 都追加 lineage 链，长期运行的 Agent 会有数万条历史 commit；序列化体积和遍历成本线性增长。 - 缓解：定期做分支头快照（snapshot），快照之前的 lineage 链可以压缩归档；参考 git 的"pack file"机制。

5. 生产集成建议

Phase 1（OpenClaw 任务队列改造）： - 将每个 task submission 建模为候选变更 - 实现 Commit/Reject 二级处置（暂不引入 Quarantine/Defer） - 用 Redis List + Lua 脚本实现 branch head WAL

Phase 2（多工具并发安全）： - 多工具并发调用时，用 CK 协议管理工具输出的状态写入 - 防止工具 A 的输出覆盖工具 B 尚未验证的结果 - 关键：激活事务中的 Freshness check 必须基于精确的前驱分支头 ID（不是时间戳）

Phase 3（长寿 Agent 记忆权威）： - 用户偏好、规则引擎、系统提示的变更全部走 CK 协议 - Agent 的"身份"不再依赖单点覆写，而是依赖分支头的连续谱系 - 这时候 Quarantine/Defer 才有意义——高风险操作（如修改系统提示模板）进 Quarantine

6. 总结评分

机制完整性：branch head + 激活事务四步 + 四级处置 + WAL 收据，协议设计严密，机制层 5 分。 实验支撑：形式化验证 2.8M states / 0 violations 有支撑；但无性能数字、无吞吐量/延迟，实验层 2 分。 工程可复现性：GitHub 未确认、9+6 页 workshop paper、实现细节被压缩，工程层 2 分。 风险标注质量：⚠️ 覆盖了并发饥饿、无性能数字、与 RAG 集成关系未定义，4 分。

综合工程评分：3 / 5（协议设计扎实，形式化验证提供了高置信度的安全性保证，但无 GitHub、无性能数字、9+6 页 workshop paper 的篇幅限制了工程可复现性。建议优先将 CK 的协议设计作为蓝图实现（Phase 1 的 Commit/Reject 二级），GitHub 确认后再投入完整实现）。