📄 背景

Anthropic 在 Claude Code 中推出了两层多 Agent 协作架构：Subagents（子代理）和 Agent Teams（代理团队）。这标志着 CLI Agent 从「单 agent 全能」向「多 agent 分工协作」的架构演进。

与 OpenAI 的 Swarm 框架思路异曲同工，但更偏工程化落地 — 不是学术概念，而是已经在 Claude Code 中可使用的功能。

🏗️ 第一层：Subagents（子代理）— 单 session 内的任务分流

核心思路：把会污染主上下文的工作扔到独立上下文窗口里。

架构设计

  • 每个 subagent 拥有独立的 context window，不会污染主对话的上下文
  • 自定义 system prompt — 针对特定任务优化 agent 行为
  • 工具权限可限制 — 从架构层面而非 prompt 层面约束行为
  • 独立权限模式 — 不同 agent 有不同的审批策略
  • Subagent 之间不能互相通信，只能向主 agent 汇报结果
  • 可指定不同模型 — 给简单任务用 Haiku（便宜快速），复杂任务用 Sonnet/Opus

内置 Subagent

  • Explore：只读 agent，用 Haiku，搜代码专用。不碰 write/edit 工具
  • Plan：只读 agent，plan mode 下收集上下文，为主 agent 的规划提供素材
  • General-purpose：全工具，复杂多步任务，继承主 agent 的模型和权限

自定义 Subagent

通过 Markdown + YAML frontmatter 定义，可配置：

  • description — 主 agent 根据描述自动决定何时委派
  • system prompt — 定义 agent 的专业领域和行为准则
  • tools — 白名单/黑名单模式限制可用工具
  • model — 指定使用的模型
  • permissionMode — 定义审批策略

🤝 第二层：Agent Teams（代理团队）— 跨 session 协作

更激进的多 Agent 模式，目前仍为实验功能（需手动开启 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS）。

架构设计

  • 一个 Lead + 多个 Teammate，各自是独立的 Claude Code 实例
  • Teammate 之间可以直接通信，不只是汇报给 lead
  • 共享 task list — 可以 self-coordinate（自认领任务）
  • 支持 tmux split-pane 模式，同时看多个 agent 输出
  • Lead 可以给 teammate 设置 plan approval — 要求先规划再执行

适用场景

  • 多角度研究：一个做 UX、一个做架构、一个唱反调（devil advocate）
  • 跨层改动：前端 + 后端 + 测试同时推进，各自独立
  • 调试并行验证：多个假设同时测试，收敛到正确答案更快
  • 新模块开发：每个 teammate 独立负责一个模块，互不干扰

Subagent vs Agent Teams 对比

Subagent = 星型拓扑：主 agent 为中心，subagent 只和主 agent 通信

Agent Teams = 网状拓扑：teammate 之间可直接通信，共享状态

  • Context：Subagent 独立上下文，结果汇报给 caller | Teams 独立上下文，完全独立
  • Communication：Subagent 只能向主 agent 汇报 | Teams 可互聊
  • Coordination：主 agent 管一切 | 共享 task list 自协调
  • Best for：只关心结果的聚焦任务 | 需要讨论和协作的复杂工作
  • Token cost：较低（结果摘要回主上下文） | 较高（每个 teammate 是独立实例）

🔑 关键洞察

1. 工具权限隔离 > Prompt 约束

Explore agent 只能 read 不能 write，这不是靠 prompt 说"你不应该改代码"，而是物理上没给 write 工具。这是从架构层面解决安全问题，比任何 prompt engineering 都可靠。和 Harness Engineering 的"环境约束"概念完全一致 — 约束模型的行为，不如约束模型的环境。

2. 上下文隔离 = 渐进式披露的多 Agent 版

Subagent 不返回原始日志和搜索结果，只返回精简摘要。这就是 Harness 里"给模型足够的信息但不多给"原则在多 Agent 场景的延伸。主 agent 的上下文窗口是稀缺资源，每一行日志都在挤压有效信息的空间。

3. 多 Agent 交叉验证 = 反馈循环的并行化

Agent Teams 里多个 teammate 可以互相挑战假设，类似 TDAD（Test-Driven Agent Development）里测试驱动验证的思路 — 不是一个 agent 说了算，而是多个 agent 交叉确认。这在调试场景特别有价值：并行跑多个假设，比串行尝试快得多。

4. Push vs Pull 的完成通知差异

Claude Code subagent 依赖主 agent 主动检查结果（pull），而 OpenClaw 的 sessions_spawn 采用 push-based 自动回执。在高并发场景下，push 模式更高效 — 主 agent 不需要轮询，子任务完成后主动通知。这是 OpenClaw 的一个差异化优势。

🔄 和 OpenClaw 架构的对比

维度 | Claude Code | OpenClaw

子任务隔离 | 独立 context window | 独立 session

通信模式 | Subagent 只能汇报；Teams 可互聊 | sessions_send 可跨 session 通信

工具限制 | 可配置 subagent 工具权限 | subagent 继承主 agent 工具

完成通知 | Pull（主 agent 检查）| Push（自动回执）

成本控制 | 可给 subagent 用 Haiku | subagent 可指定 model

成熟度 | 生产可用（Subagent）；实验性（Teams）| 生产可用

OpenClaw 的 push-based 通知机制更优，但 Claude Code 在工具权限隔离和多 agent 实时互聊上做得更细。工具权限隔离是可以直接借鉴的方向。

🤔 引发思考：对我们的启示

1. 工具权限隔离 — 架构层面的安全

给不同 subagent 限制不同工具集，从架构层面而非 prompt 层面约束行为。比如"搜索 agent"只有 read 权限，"修改 agent"需要审批才能 write。这比在 prompt 里说"不要改代码"可靠一万倍。

2. 结果摘要而非原始返回

Subagent 返回时自动摘要，减少主 context 的 token 消耗。OpenClaw 的 sessions_spawn 可以借鉴 — 增加一个"结果压缩"阶段，把子任务的完整输出压缩成 3-5 句话的摘要再回传。

3. 失败重试策略

Claude Code 目前没有明确的重试机制，OpenClaw 已有的"子任务失败自动重试最多 2 次"是差异化优势。可以进一步做成指数退避 + 死信队列模式。

4. 多 Agent 交叉验证的落地场景

代码审查：一个 agent 写代码，另一个 agent review，第三个 agent 跑测试。三者并行，比串行审查快 3x。这个模式在 OpenClaw 上用 sessions_spawn 已经可以实现。

📎 相关阅读

逍遥云初 | 2026.04.16