Claude Code 学习站

Claude Code Agent Teams:多智能体协同团队完全指南

Claude Code 实验性 Agent Teams 功能详解:如何启用多 Claude 实例协同工作、团队分工、共享任务列表与最佳实践,适合需要并行探索和相互验证的复杂任务。

本页目录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.jsonenv 字段中启用 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS,或在 shell 中设置同名环境变量为 1

Agent Teams vs. Subagents

对比维度SubagentsAgent 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-process
  • tmux:强制分屏,自动判断使用 tmux 还是 iTerm2
  • iterm2(v2.1.186 起):使用 iTerm2 原生分屏,需安装 it2 CLI 并在 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 配置,系统提示词以附加方式合并而非替换。

最佳实践

  1. 规模适中:从 3~5 人团队起步,每位队友分配约 5~6 个任务;规模过大时协调开销会抵消并行收益
  2. 任务粒度适当:每个任务应自包含并有明确交付物(一个函数、一个测试文件、一份评审),避免粒度过细或过粗
  3. 明确文件归属:两个队友编辑同一文件会导致覆盖,须划清各自负责的文件范围
  4. 显式提供背景:队友不继承 Lead 的对话历史,关键约束须在 spawn 提示词中说明
  5. 全程监控推进:定期检查进度并纠偏,避免长时间无人监督导致资源浪费

典型应用场景

  • 并行代码评审:3 个队友分别从安全性、性能、测试覆盖率角度审查同一 PR,Lead 汇总
  • 多假设并发调试:多个队友各自验证不同根因假设并相互「辩论」验伪,比单线索调查更快收敛
  • 跨层功能开发:前端、后端、测试各由独立队友负责,互不干扰,适合改动横跨多层的大型特性

已知限制

  • /resume/rewind 无法恢复 in-process 模式的队友,恢复后需重新 spawn
  • 任务状态有时滞后,可能阻塞依赖任务,需手动干预
  • 关闭队友须等其完成当前工具调用,速度较慢
  • 每个会话只有一个团队,且不支持嵌套(队友不能再生成队友)
  • 分屏模式不兼容 VS Code 集成终端、Windows Terminal、Ghostty