在软件开发中，我们经常遇到需要从多个角度同时推进的复杂任务。比如代码审查时，安全性、性能、测试覆盖率都需要关注；调试时，多个假设需要并行验证。传统的单一 AI 助手模式在这些场景下显得力不从心。
Claude Code 的 Agent Teams 功能正是为解决这类问题而生。它允许你协调多个 Claude Code 实例作为一个团队协同工作，每个成员独立运行、相互通信，共同完成复杂任务。
什么是 Agent Teams？
Agent Teams 是 Claude Code 的一项实验性功能，它让你能够同时运行多个 Claude Code 实例，形成一个协作团队。在这个团队中：
- 一个会话充当"团队负责人"（Team Lead），负责协调工作、分配任务、综合结果
- 多个"队友"（Teammates）独立工作，每个都有自己的上下文窗口
- 队友之间可以直接通信，分享发现、相互质疑
- 你也可以直接与任何队友交互，无需通过负责人中转
这与 Claude Code 的 Subagents 有本质区别。Subagents 在单个会话中运行，只能向主代理报告结果；而 Agent Teams 中的每个队友都是完全独立的 Claude 实例，能够进行真正的协作讨论。
Agent Teams vs Subagents：如何选择？
在决定使用哪种方式之前，先了解它们的核心差异：
| 特性 | Subagents | Agent Teams |
|---|---|---|
| 上下文 | 独立窗口，结果返回给调用者 | 独立窗口，完全独立运行 |
| 通信方式 | 仅向主代理报告结果 | 队友之间可直接发送消息 |
| 协调机制 | 主代理管理所有工作 | 共享任务列表，自我协调 |
| 适用场景 | 只需要结果的专注任务 | 需要讨论和协作的复杂工作 |
| Token 成本 | 较低（结果汇总回主上下文） | 较高（每个队友是独立实例） |
简单来说：当你需要快速、专注的工作者报告结果时，用 Subagents；当队友需要分享发现、相互质疑和自我协调时，用 Agent Teams。
Agent Teams 最适合哪些场景？
Agent Teams 在以下场景中表现出色：
1. 研究和审查
多个队友可以同时调查问题的不同方面，然后分享和质疑彼此的发现。比如代码审查时，一个关注安全性，一个检查性能，一个验证测试覆盖率。
2. 新模块或功能开发
队友可以各自负责一个独立的部分，互不干扰。前端、后端、测试可以同时推进。
3. 使用竞争假设进行调试
当 bug 原因不明时，让多个队友并行测试不同的理论，更快收敛到答案。
4. 跨层协调
涉及前端、后端和测试的变更，每个由不同的队友负责，通过消息机制保持同步。
需要注意的是，Agent Teams 会增加协调开销，Token 消耗明显高于单个会话。对于顺序任务、同一文件编辑或依赖关系复杂的工作，单个会话或 Subagents 更高效。
如何启用 Agent Teams？
Agent Teams 默认是禁用的，需要手动开启。有两种方式：
方式一：通过环境变量
在 shell 中设置：
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
方式二：通过配置文件
在 settings.json 中添加：
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
创建你的第一个 Agent Team
启用功能后，用自然语言告诉 Claude 你想要的团队结构和任务。Claude 会自动创建团队、生成队友并协调工作。
来看一个实际例子。假设你正在设计一个 CLI 工具，想从多个角度探索方案：
这个提示效果很好，因为三个角色是独立的，可以在不相互等待的情况下探索问题。Claude 会：
- 创建一个带有共享任务列表的团队
- 为每个角度生成队友
- 让他们各自探索问题
- 综合发现并在完成时清理团队
两种显示模式
Agent Teams 支持两种显示模式，根据你的工作环境选择：
In-process 模式（默认）
所有队友在主终端内运行。使用 Shift+Up/Down 选择队友并直接发送消息。这种模式在任何终端中都能工作，无需额外设置。
Split panes 模式
每个队友获得自己的窗格，你可以同时看到每个人的输出，点击窗格直接交互。这种模式需要 tmux 或 iTerm2 支持。
配置方式：
{
"teammateMode": "in-process" // 或 "tmux" 启用分割窗格
}
也可以在启动时指定：
claude --teammate-mode in-process
默认值是 "auto"，如果你已经在 tmux 会话中运行，则使用分割窗格，否则使用 in-process。
控制你的 Agent Team
团队创建后，你可以通过自然语言指挥负责人进行各种操作。
指定队友数量和模型
Claude 会根据任务自动决定队友数量，你也可以明确指定：
要求计划批准
对于复杂或有风险的任务，可以要求队友在实施前先提交计划：
生成一个架构师队友来重构认证模块。
在他们做任何更改之前需要计划批准。
队友完成计划后会向负责人发送批准请求。负责人审查后批准或拒绝并提供反馈。
使用委派模式
有时负责人会自己动手实施任务，而不是等待队友。委派模式可以防止这种情况，将负责人限制为仅使用协调工具：生成、消息传递、关闭队友和管理任务。
启用方式：先启动一个团队，然后按 Shift+Tab 循环进入委派模式。
直接与队友交谈
每个队友都是完整的、独立的 Claude Code 会话，你可以直接向任何队友发送消息：
- In-process 模式：使用
Shift+Up/Down选择队友，然后输入消息。按Enter查看队友会话，按Escape中断当前轮次，按Ctrl+T切换任务列表。 - Split-pane 模式：点击队友的窗格直接交互。
任务分配和认领
共享任务列表协调整个团队的工作。任务有三种状态：待处理、进行中、已完成。任务也可以设置依赖关系。
分配方式有两种：
- 负责人分配：告诉负责人将哪个任务分配给哪个队友
- 自我认领：队友完成任务后，自动选择下一个未分配、未阻塞的任务
关闭队友和清理团队
优雅地结束队友会话：
完成所有工作后，清理团队资源：
清理团队
注意：清理前需要先关闭所有队友，且只能由负责人执行清理操作。
Agent Teams 的架构
了解底层架构有助于更好地使用这个功能。
| 组件 | 作用 |
|---|---|
| Team Lead | 创建团队、生成队友、协调工作的主会话 |
| Teammates | 各自处理分配任务的独立 Claude Code 实例 |
| Task List | 队友认领和完成的共享工作项列表 |
| Mailbox | 代理之间通信的消息系统 |
团队和任务数据存储在本地：
- 团队配置：
~/.claude/teams/{team-name}/config.json - 任务列表：
~/.claude/tasks/{team-name}/
实战案例
案例一：并行代码审查
单个审查者往往一次只关注一种问题。把审查标准分解为独立的领域，安全性、性能、测试覆盖率可以同时获得彻底关注：
每个审查者从同一个 PR 工作，但应用不同的视角。负责人在他们完成后综合所有发现。
案例二：使用竞争假设调试
当根本原因不清楚时，单个代理往往会找到一个看似合理的解释就停止寻找。让多个队友明确对抗，每个人不仅调查自己的理论，还要质疑其他人的理论：
用户报告应用在发送一条消息后就退出，而不是保持连接。
生成 5 个队友来调查不同的假设。让他们相互交流，
尝试反驳彼此的理论，像科学辩论一样。
将达成的共识更新到发现文档中。
辩论结构是关键。顺序调查容易受到锚定效应影响——一旦探索了一个理论，后续调查就会偏向它。多个独立调查人员积极尝试相互反驳，幸存下来的理论更可能是真正的根本原因。
最佳实践
给队友足够的上下文
队友会自动加载项目上下文（CLAUDE.md、MCP servers、skills），但不会继承负责人的对话历史。在生成提示中包含任务相关的具体细节：
生成一个安全审查队友，提示："审查 src/auth/ 的认证模块，
检查安全漏洞。重点关注 token 处理、会话管理和输入验证。
应用使用存储在 httpOnly cookies 中的 JWT token。
报告任何问题并标注严重程度。"
适当调整任务大小
- 太小：协调开销超过收益
- 太大：队友工作太久不检查，增加浪费努力的风险
- 恰到好处：自包含的单位，产生清晰的可交付成果，如函数、测试文件或审查
每个队友分配 5-6 个任务是比较理想的，既能保持生产力，又让负责人在有人卡住时能重新分配工作。
避免文件冲突
两个队友编辑同一文件会导致覆盖。分解工作时，确保每个队友拥有不同的文件集。
监控和引导
定期检查队友进度，重定向不起作用的方法，及时综合发现。让团队无人值守运行太长时间会增加浪费努力的风险。
从研究和审查开始
如果你是 Agent Teams 新手，建议从具有明确边界且不需要编写代码的任务开始：审查 PR、研究库或调查错误。这些任务能展示并行探索的价值，而不会带来并行实施的协调挑战。
常见问题排查
队友未出现
- 在 in-process 模式中，队友可能已在运行但不可见，按
Shift+Down循环查看 - 检查任务是否足够复杂，Claude 会根据任务决定是否生成队友
- 如果使用分割窗格，确保 tmux 已安装并在 PATH 中可用
过多权限提示
队友权限请求会冒泡到负责人，可能造成摩擦。在生成队友之前，在权限设置中预批准常见操作可以减少中断。
队友在错误时停止
队友可能在遇到错误后停止而不是恢复。检查他们的输出，然后直接给他们额外指示，或生成替代队友继续工作。
负责人在工作完成前关闭
如果负责人过早决定团队已完成，告诉它继续。也可以要求负责人在继续之前等待队友完成。
当前限制
Agent Teams 仍是实验性功能，存在一些已知限制：
- In-process 队友没有会话恢复：
/resume和/rewind不会恢复 in-process 队友 - 任务状态可能滞后：队友有时无法将任务标记为已完成，阻止依赖任务
- 关闭可能较慢：队友在关闭前会完成当前请求或工具调用
- 每个会话一个团队：负责人一次只能管理一个团队
- 没有嵌套团队：队友无法生成自己的团队
- 负责人是固定的：无法将队友提升为负责人或转移领导权
- 分割窗格需要 tmux 或 iTerm2：VS Code 集成终端、Windows Terminal 或 Ghostty 不支持
总结
Agent Teams 为复杂的软件开发任务提供了一种全新的协作模式。通过让多个 AI 代理并行工作、相互通信，它能够在代码审查、调试、功能开发等场景中发挥独特价值。
虽然目前仍是实验性功能，但对于需要多角度探索、并行验证假设的任务，Agent Teams 已经展现出明显的优势。建议从研究和审查类任务开始尝试，逐步熟悉这种新的工作方式。