本页目录12
- Agent Teams 目前为实验性功能,须在 settings.json 中设置环境变量 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 才能启用
- 与 Subagents 的核心区别在于:队友之间可直接互发消息,并通过共享任务列表自主认领工作,而非只向主智能体汇报
- 显示模式分为 in-process(默认,任何终端可用)和 split-panes(需要 tmux 或 iTerm2),可通过 teammateMode 配置
- 建议从 3~5 人团队起步,每人分配 5~6 个任务;团队过大会导致协调开销超过并行收益
- 队友继承 Team Lead 的权限设置,但不继承其对话历史,关键背景须在 spawn 提示词中显式说明
- 当前已知限制:不支持 /resume 恢复队友、任务状态可能滞后、不支持嵌套团队、分屏模式不兼容 VS Code 集成终端
本文是对官方文档《Orchestrate teams of Claude Code sessions》的中文要点摘要,完整内容以原文为准:https://code.claude.com/docs/en/agent-teams
什么是 Agent Teams
Agent Teams 让多个 Claude Code 实例协同工作。其中一个会话担任团队负责人(Team Lead),负责创建任务、分配工作、汇总结果;其余会话作为队友(Teammate),各自拥有独立的上下文窗口,并可相互直接通信。
注意:该功能目前为实验性,默认关闭。需在
settings.json的env字段中启用CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS,或在 shell 中设置同名环境变量为1。
Agent Teams vs. Subagents
| 对比维度 | Subagents | Agent Teams |
|---|---|---|
| 通信方式 | 仅向主智能体汇报结果 | 队友之间可直接互发消息 |
| 协调机制 | 主智能体统一调度 | 共享任务列表,自主认领 |
| Token 开销 | 较低 | 较高(每位队友独立消耗) |
| 适用场景 | 专注任务、只需汇报结果 | 需要讨论、互相验证、协作推进 |
选择原则:队友之间无需互相沟通时选 Subagents;任务需要跨角色讨论和验证时选 Agent Teams。
如何启动团队
启用后,用自然语言描述任务和期望角色即可,无需额外建团命令(v2.1.178 起已移除旧版 TeamCreate / TeamDelete 工具):
I'm designing a CLI tool. Spawn three teammates:
one on UX, one on technical architecture, one playing devil's advocate.
Claude 会自动填充共享任务列表、生成队友并在完成后汇总结果。Lead 终端底部的智能体面板显示所有队友状态,可用上下方向键选择、Enter 进入查看并直接发消息、Escape 中断其当前执行。
显示模式
通过 teammateMode(写入 ~/.claude/settings.json)或启动时 --teammate-mode 标志设置:
in-process(默认):所有队友在主终端内运行,方向键导航,适用于任何终端auto:已在 tmux 会话中或使用 iTerm2 时自动开启分屏,否则降级为 in-processtmux:强制分屏,自动判断使用 tmux 还是 iTerm2iterm2(v2.1.186 起):使用 iTerm2 原生分屏,需安装it2CLI 并在 iTerm2 偏好设置中启用 Python API
核心机制
共享任务列表与消息通信
- 任务存储在
~/.claude/tasks/{team-name}/,支持依赖关系,用文件锁防止多人同时认领同一任务 - 队友可按名字互发消息,Team Lead 自动收到通知,无需主动轮询
- 队友完成任务后会主动通知 Lead,依赖该任务的其他任务自动解锁
计划审批流程
可要求队友先提交实施方案,Lead 审批通过后再执行变更:
Spawn an architect teammate to refactor the auth module.
Require plan approval before they make any changes.
Lead 可在 prompt 中设置审批标准,例如「只批准包含测试覆盖的方案」或「拒绝涉及数据库 schema 变更的方案」。
质量门控 Hooks
| Hook | 触发时机 | 退出码 2 效果 |
|---|---|---|
TeammateIdle | 队友即将进入空闲 | 发送反馈,让队友继续工作 |
TaskCreated | 任务创建时 | 阻止创建并反馈原因 |
TaskCompleted | 任务标记完成时 | 阻止完成并反馈原因 |
Subagent 定义复用
可在 spawn 时引用已定义的 subagent 类型(涵盖任一 subagent 作用域:项目级、用户级、插件级、CLI 定义级),队友将继承其 tools 白名单和 model 配置,系统提示词以附加方式合并而非替换。
最佳实践
- 规模适中:从 3~5 人团队起步,每位队友分配约 5~6 个任务;规模过大时协调开销会抵消并行收益
- 任务粒度适当:每个任务应自包含并有明确交付物(一个函数、一个测试文件、一份评审),避免粒度过细或过粗
- 明确文件归属:两个队友编辑同一文件会导致覆盖,须划清各自负责的文件范围
- 显式提供背景:队友不继承 Lead 的对话历史,关键约束须在 spawn 提示词中说明
- 全程监控推进:定期检查进度并纠偏,避免长时间无人监督导致资源浪费
典型应用场景
- 并行代码评审:3 个队友分别从安全性、性能、测试覆盖率角度审查同一 PR,Lead 汇总
- 多假设并发调试:多个队友各自验证不同根因假设并相互「辩论」验伪,比单线索调查更快收敛
- 跨层功能开发:前端、后端、测试各由独立队友负责,互不干扰,适合改动横跨多层的大型特性
已知限制
/resume和/rewind无法恢复 in-process 模式的队友,恢复后需重新 spawn- 任务状态有时滞后,可能阻塞依赖任务,需手动干预
- 关闭队友须等其完成当前工具调用,速度较慢
- 每个会话只有一个团队,且不支持嵌套(队友不能再生成队友)
- 分屏模式不兼容 VS Code 集成终端、Windows Terminal、Ghostty