原文：Orchestrate teams of Claude Code sessions
⚠️ 实验性功能，默认禁用
什么是 Agent Teams
Agent Teams 让多个独立的 Claude Code 实例作为一个团队协作。一个 Lead 会话负责协调，多个 Teammate 会话独立工作，它们通过共享任务列表和点对点消息通信。
类比：如果 SubAgent 是 Worker Thread（后台线程），那 Agent Teams 就是微服务架构——每个 Teammate 是一个独立服务，通过消息队列交换信息。
Agent Teams vs SubAgent
| SubAgent | Agent Teams | |
|---|---|---|
| 上下文 | 独立窗口，结果回传 | 独立窗口，完全独立 |
| 通信 | 只能向主 agent 汇报 | Teammates 之间直接通信 |
| 协调 | 主 agent 管理 | 共享任务列表 + 自协调 |
| Token 成本 | 较低（结果摘要回传） | 较高（每个 teammate 是独立实例） |
| 适用 | 只需要结果的聚焦任务 | 需要讨论和协作的复杂工作 |
决策点：如果你的并行任务之间需要互相分享发现、互相质疑，用 Agent Teams。否则用 SubAgent。
架构组件
| 组件 | 角色 |
|---|---|
| Team Lead | 主会话，创建团队、分配任务、综合结果 |
| Teammates | 独立的 Claude Code 实例 |
| Task List | 共享任务列表（pending → in_progress → completed） |
| Mailbox | Agent 间的消息系统 |
最佳使用场景
- 并行 Code Review：安全审查 + 性能审查 + 测试覆盖率审查同时进行
- 竞争假设调试：多个 Agent 分别验证不同的 bug 假设，互相质疑
- 新模块开发：每个 Agent 负责一个独立模块
- 跨层协调：前端 + 后端 + 测试分别由不同 Agent 负责
关键操作
启用
// settings.json
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}启动团队
Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage显示模式
- In-process：所有 teammate 在主终端中，
Shift+Down切换 - Split panes：每个 teammate 一个终端面板（需要 tmux 或 iTerm2）
质量门控（Hook）
TeammateIdle：teammate 空闲时触发（exit 2 可让它继续工作）TaskCompleted：任务完成时触发（exit 2 可阻止完成）
实际案例：竞争假设调试
Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to
each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.为什么有效：单个 Agent 调查倾向于找到一个合理解释就停止（锚定偏见）。多个 Agent 互相质疑，存活下来的假设更可能是真正的根因。
当前限制
- 不支持会话恢复（resume 不会恢复 in-process teammates）
- 任务状态可能滞后
- 每个会话只能管一个 team
- Teammates 不能再创建 team（不能嵌套）
- Lead 固定，不能转让
知识检测
概念理解题
-
Agent Teams 的”竞争假设调试”模式为什么比单个 Agent 调试更有效？这和科学方法论中的什么概念类似？
-
为什么文档建议”3-5 个 teammates，每个 5-6 个任务”？更多 teammates 会带来什么问题？
应用题
- 你要做一个大型 Web 应用的性能优化。设计一个 Agent Team 配置：Lead 做什么、Teammates 分别负责什么、如何协调。
迁移思考题
- OpenClaw 没有 Agent Teams 的等价物。如果你要在 OpenClaw 上实现类似的多 Agent 协作，你会用什么底层机制？（提示：考虑 webhook + isolated session）
参见
参考答案
1. 竞争假设调试的有效性
单个 Agent 调查倾向于锚定偏见——找到第一个合理解释就停止。多个 Agent 互相质疑，每个假设都被挑战，存活下来的更可能是真正的根因。这和科学方法论中的同行评审（peer review）和可证伪性（falsifiability）一致：一个假设如果经不起其他研究者的质疑，就不够可靠。
2. “3-5 个 teammates，5-6 个任务”
每个 teammate 是独立的 Claude 实例——更多意味着更高的 token 成本（线性增长）、更复杂的协调（二次增长）、更多的消息传递开销。而且任务分得太细会导致 teammate 之间的依赖关系复杂化，反而降低效率。3-5 个是经验上的平衡点——足够并行化，又不至于失控。
3. Web 应用性能优化 Agent Team
Lead：总体协调，综合各 teammate 发现，制定优先级修复计划。Teammate 1（Bundle 分析）：分析 bundle 大小、依赖树、tree-shaking 和 code splitting 机会。Teammate 2（运行时性能）：检查 React re-render、内存泄漏、useMemo/useCallback 使用。Teammate 3（网络与加载）：检查 API 调用瀑布、缓存策略、图片优化、Core Web Vitals。协调方式：每个 teammate 把发现写入共享任务列表，Lead 综合后制定优先级。
4. OpenClaw 的多 Agent 协作
OpenClaw 的 Multi-Agent Routing 是路由型（根据消息内容选择哪个 Agent 处理），不是协作型（多个 Agent 讨论同一个问题）。要实现协作型，可以：(1) 多个 isolated session 通过 webhook 互相传递消息 (2) 一个”协调者” Agent 通过 agent RPC 调用其他 Agent (3) 用共享的 Memory 文件作为”白板”——每个 Agent 把发现写入，其他 Agent 读取。但这比 Claude Code Agent Teams 的原生支持复杂得多。