用 Claude Code 写代码，最常见的用法是开一个终端，一个会话从头做到尾。但有些任务这样做效率不高：同时改前端、后端和测试三层时，一个会话要来回切换上下文；排查一个有三种可能原因的 bug 时，只能一个假设一个假设地试。
Claude Code 为此提供了一个实验性功能：Agent Teams（官方文档叫 agent teams）。它让多个 Claude Code 实例组成一个团队，一个会话当 lead 负责拆任务和汇总，其他会话当 teammate 并行干活，teammate 之间还能直接发消息。
这篇适合已经在用 Claude Code、知道子 Agent（Subagents）但不确定什么时候该用 Agent Teams 的开发者。文章会讲两者的区别、怎么开启和操作 Agent Teams、三个最适合的场景，以及目前的限制。
Claude Code Agent Teams 与子 Agent 的区别
Claude Code 已经有子 Agent，为什么还要 Agent Teams？关键在于协作方式。
子 Agent 是「上下级」关系：主 Agent 派一个子 Agent 去查代码，它查完把结果交回主 Agent，任务就结束了。主 Agent 负责管理全部工作，子 Agent 只负责交一份结果。子 Agent 在开发流程里的典型用法，可以参考 Simon Willison 的 Claude Code 子 Agent 与 TDD 用法。
Agent Teams 更像「同事」关系：每个 teammate 都是一个完整、独立的 Claude Code 会话，有自己的上下文窗口，可以读写文件、跑命令，还能按名字直接给其他 teammate 发消息。团队共用一个任务列表，teammate 做完手上的任务可以自己认领下一个。你也可以绕开 lead，直接跟任意一个 teammate 对话。
| 对比项 | 子 Agent（Subagents） | Agent Teams |
|---|---|---|
| 上下文 | 独立上下文窗口，结果交回调用方 | 独立上下文窗口，完全独立运行 |
| 沟通方式 | 把结果交回调用方 | teammate 之间直接发消息 |
| 协调方式 | 主 Agent 管理全部工作 | 通过消息和共享任务列表自行协调 |
| 适合 | 只关心结果的专注任务 | 需要讨论、互相质疑、共同推进的复杂任务 |
| token 成本 | 较低，结果会被总结后回到主上下文 | 较高，每个 teammate 都是单独的 Claude 实例 |
一个简单的判断标准：只需要结果，用子 Agent；teammate 之间需要交流、挑战彼此的方案、或者共同推进一个复杂任务，再考虑 Agent Teams。
怎么开启 Agent Teams
Agent Teams 默认关闭，需要把环境变量 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 设为 1，可以在 shell 环境里设，也可以写进 settings.json：
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
开启后，用自然语言描述任务和想要的 teammate 就行，例如让 Claude 派三个 teammate 分别从用户体验、技术架构和反方角度研究一个方案。Claude 会建任务列表、派出 teammate，最后汇总结果。
有两点要注意：
- 开启后，Claude 自己给某个子 Agent 起名字时，这个子 Agent 也会以 teammate 的形式启动，所以即使你没要求组队，也可能出现团队。不想要这种行为，就把变量改回
0。 - 只有交互式会话才会派出 teammate。用
-p的非交互模式（包括 Agent SDK）时不会组队。
两种显示模式
In-process：都在一个终端里
这是默认模式，所有 teammate 都跑在主终端里。lead 的终端会在输入框下方列出 teammate，用上下方向键选中一个，按 Enter 查看它的记录并直接给它发消息，按 Esc 取消选择。不需要额外安装任何东西，任何终端都能用。
Split panes：每个 teammate 一个窗格
每个 teammate 占一个窗格，可以同时看到所有人的输出，点进某个窗格就能和它直接对话。这个模式需要 tmux，或者装了 it2 命令行工具的 iTerm2。VS Code 内置终端、Windows Terminal 和 Ghostty 不支持分屏模式。
显示模式在 ~/.claude/settings.json 里用 teammateMode 设置，默认是 in-process；设成 auto 时，在 tmux 会话里或装了 it2 的 iTerm2 里会自动分屏，否则退回 in-process：
{
"teammateMode": "auto"
}
只想在某一次会话里切换，也可以用启动参数：
claude --teammate-mode in-process
Agent Teams 最适合的三个场景
场景一：调 bug 时同时验证多个假设
一个 bug 可能是数据库查询的问题，也可能是缓存过期，还可能是前端状态管理出错。以前要一个一个试，现在可以派几个 teammate 分头调查，并让它们互相反驳对方的理论。官方文档也提到，单个 Agent 容易找到一个说得通的解释就停下，多个调查者互相质疑，最后留下来的结论更可能是真正的根因。
场景二：前端、后端、测试三层同时改
加一个新功能需要同时改前端组件、后端 API 和测试用例时，可以让三个 teammate 各负责一层。它们能直接交流接口定义，比如后端 teammate 加了一个新字段，可以直接告诉前端 teammate，不用经过你转达。
场景三：多角度调研和评审
做技术方案或评审 PR 时，可以派一个 teammate 看安全，一个看性能，一个看测试覆盖；或者一个研究竞品方案、一个分析当前架构的约束、一个专门当反方找漏洞。lead 会在它们完成后汇总成一份报告。刚上手 Agent Teams 时，官方也建议先从这类不用写代码、边界清楚的调研和评审任务开始。
使用建议
- 团队规模：官方建议大多数情况先用 3 到 5 个 teammate，每个 teammate 分到 5 到 6 个任务比较合适。人数越多，协调成本越高，收益也会递减。
- 避免文件冲突：两个 teammate 改同一个文件会互相覆盖，拆任务时让每个 teammate 负责不同的文件或模块。
- 给足上下文：teammate 会自动加载 CLAUDE.md、MCP 服务和 Skill，但不会继承 lead 的对话历史，派任务时把具体信息写进提示里。
- 盯着进度：lead 有时会自己动手干活而不是等 teammate，可以直接让它等 teammate 完成。
限制与注意事项
Agent Teams 目前仍是实验性功能，已知的限制主要有这些：
- 会话恢复：
/resume和/rewind不会恢复 in-process 模式下的 teammate。恢复会话后 lead 可能还会给已经不存在的 teammate 发消息，这时让它重新派 teammate 即可。最好把 Agent Teams 用在一次能做完的任务上。 - 任务状态可能滞后：teammate 有时没把任务标成完成，导致依赖它的任务卡住，需要手动检查或让 lead 去催。
- 关闭可能较慢：teammate 要先做完当前请求或工具调用才会退出。团队的共享目录会在会话结束时自动清理。
- 每个会话只有一个团队，teammate 不能再派自己的 teammate，lead 也不能转交。
- token 消耗明显更高：每个 teammate 都是一个完整实例，token 用量随活跃 teammate 数量线性增长，订阅用户要特别留意配额。配额为什么会掉得快、怎么排查，可以看 Claude Code 配额为什么消耗这么快。
总结
Agent Teams 把 Claude Code 从「一个人干」变成了「带一个小团队干」。它最适合同时满足三个条件的任务：任务能拆开并行做、teammate 之间需要交流、愿意多花 token 换更快的进度。不满足这些条件时，单个会话或子 Agent 更合适，成本也更低。
建议先在不重要的项目上，用一次代码评审或 bug 排查试试，感受多个 Claude 同时干活的节奏，再决定要不要放进正式工作流。
想直接上手 Claude Code，可以在 AIGoCode 上使用 Claude Code 和 Codex。
参考链接
- Claude Code 文档：Orchestrate teams of Claude Code sessions：https://code.claude.com/docs/en/agent-teams
- Claude Code 文档：Subagents：https://code.claude.com/docs/en/sub-agents
- Claude Code 文档：Manage costs：https://code.claude.com/docs/en/costs