Anchor/Handoff：Agent 协作的缺失一环

> 来源: https://github.com/bubbuild/bub | https://tape.systems

> 背景: Bub Agent 框架提出的形式化多 Agent 交接协议

> 日期: 2026-03-12

📌 问题：Agent 交接的困境

当多个 Agent 接力完成一个复杂任务时，会遇到一个根本性问题：

Agent A（调研）→ 产生 200 轮对话历史
Agent B（编码）→ 要继承 A 的全部 200 轮？上下文窗口爆了
                → 只看最后几轮？丢失关键决策原因
                → 写一段摘要？信息损失不可控

核心困境：下一个 Agent 要么上下文溢出，要么信息丢失。

目前业界的常见做法：

没有一个方案是结构化的、可追溯的、形式化的。

🔗 Anchor/Handoff 是什么？

Bub 框架和 Tape Systems 提出了一套形式化的解决方案。

Tape：不可变的事实记录

所有 Agent 行为记录为一条只追加、不可覆盖的事实序列（Tape）：

Entry #1: [user] "帮我调研 Rust vs Go"
Entry #2: [assistant] "开始调研..."
Entry #3: [tool_call] web_search("Rust vs Go performance 2026")
Entry #4: [tool_result] {...搜索结果...}
...
Entry #200: [assistant] "调研完成，推荐 Rust"

核心不变量：

1. 历史只追加，不覆盖

2. 派生数据不替代原始事实

3. 修正通过追加完成，不通过删除

Anchor：结构化的存档点

当一个阶段完成时，Agent 创建一个 Anchor——类似游戏存档：

{
  "phase": "research_complete",
  "summary": "调研完成：选择 Rust + Axum 框架",
  "reasoning": "Go 在异步场景下性能不如 Rust；Axum 社区活跃度 > Actix",
  "key_decisions": [
    {"decision": "选择 Rust", "reason": "性能 + 内存安全", "evidence": [3, 15, 42]},
    {"decision": "选择 PostgreSQL", "reason": "JSONB + 全文搜索", "evidence": [67, 89]},
    {"decision": "不用 MongoDB", "reason": "一致性需求高", "evidence": [91]}
  ],
  "next_steps": ["搭建项目骨架", "写数据库迁移", "配置 CI/CD"],
  "source_ids": [3, 15, 42, 67, 89, 91, 128, 130, 200],
  "owner": "agent-researcher"
}

Anchor 的关键特征：

Handoff：安全交接

当 Agent A 完成工作后，执行 Handoff：

,handoff name=research-phase summary="调研完成，选择 Rust+Axum+PG"

这个操作会：

1. 写一个新 Anchor——浓缩当前阶段的精华

2. 附带最小继承状态——下游需要的最少信息

3. 移动执行起点——新 Agent 从 Anchor 开始，不需要读 200 轮历史

Agent B 接手时的上下文：

[Anchor: research_complete]
  summary: "选择 Rust + Axum + PG"
  decisions: 3 个关键决策（附原因和证据指针）
  next_steps: 3 个待办

→ Agent B 从这里开始工作
→ 如果对某个决策有疑问，通过 source_ids 回溯原始对话

View：按需组装上下文

View 是面向任务的上下文窗口——不是"给你所有历史"，而是"给你这个任务需要的信息"：

View = Anchor 状态 + 相关 Tape 条目（按需检索）+ 当前任务指令

不同的 Agent 可以构建不同的 View：

• 编码 Agent：只需要技术决策 + 架构设计
• 测试 Agent：只需要功能规格 + 边界条件
• PM Agent：只需要进度 + 风险 + 下一步

📐 类比理解

🌍 现实中的应用场景

场景 1：多 Agent 软件开发

Researcher Agent → [Anchor: 技术选型完成]
     ↓ handoff
Architect Agent → [Anchor: 架构设计完成]
     ↓ handoff
Coder Agent → [Anchor: 核心模块完成]
     ↓ handoff
Reviewer Agent → [Anchor: 代码审查完成]
     ↓ handoff
DevOps Agent → 部署上线

每个 Agent 只读上一个 Anchor，不读全部历史。

场景 2：企业合规审计

金融机构需要审计 AI Agent 的每一个决策：

• Tape：完整记录，不可篡改 → 满足审计要求
• Anchor：关键检查点 → 审计人员可以跳到重要节点
• source_ids：证据链 → 每个决策都有可追溯的依据

场景 3：长期项目（跨越多个 session）

项目做了 3 个月，经历了 50 个 session：

• 没有 Anchor：每次重启要读海量历史
• 有 Anchor：读最新的 Anchor 就能续上

🔬 与现有方案对比

OpenClaw 的 Session Compaction vs Anchor

OpenClaw 已经有 session compaction（会话压缩），在 context 过长时自动摘要：

• 相同点：都是为了解决上下文窗口限制
• 不同点：

- Compaction 是被动的（context 满了才压缩）；Anchor 是主动的（阶段完成时创建）

- Compaction 是自由文本摘要；Anchor 是结构化数据

- Compaction 没有证据指针；Anchor 的 source_ids 可以回溯原始对话

- Compaction 面向单 Agent；Anchor/Handoff 面向多 Agent 协作

💡 启示与建议

对我们项目的启发

1. 报告系统已经是一种 Tape：我们的深度研究报告是追加式、有来源链接的——这本质上就是 Tape 思想

2. 缺少 Anchor：当 researcher 和 coder 协作时，没有形式化的交接点——目前靠人工在频道里说"做完了"

3. 可以借鉴：在 OpenClaw 的 sub-agent 机制中引入简单的 Anchor——spawn 子 Agent 时附带结构化的上下文摘要

行业趋势

Agent 协作正在从"单 Agent 完成一切"转向"多 Agent 分工接力"。当这个趋势成熟时，Anchor/Handoff 这类形式化交接协议可能会成为标准组件，就像 HTTP 对 Web 一样基础。

目前 Bub 的实现还太早期，但它提出的问题是对的：Agent 不只需要完成任务，还需要让别人（人或 Agent）能接着干。

📊 评分

报告由深度研究助手自动生成 | 2026-03-12

来源: https://github.com/bubbuild/bub | https://tape.systems