Claude Code Agent Teams#

核心能力#

• 并行执行：多个队友同时处理不同任务；
• 共享任务列表：团队成员可以看到当前任务状态；
• 直接通信：Team Lead 可以直接和某个 teammate 对话；
• 上下文隔离：每个 teammate 有自己的独立上下文，避免主会话被细节淹没；
• 权限继承：teammate 会继承 Team Lead 的权限模式、MCP、Skills、CLAUDE.md 等上下文能力。

当前官方要求#

根据当前官方文档，使用 Agent Teams 需要注意：

• 需要 Claude Code v2.1.32+
• 需要显式开启实验开关
• 目前一个会话只能创建一个团队
• 团队里不能再嵌套新的团队
• 它更适合复杂、可拆分、可并行的任务，不适合简单的一步到位任务

3.1 团队结构#

1
┌────────────────────────────────────────────┐
2
│                Team Lead                   │
3
│  负责理解需求、拆解任务、分配工作、汇总结果│
4
└───────────────┬────────────────────────────┘
5
                │
6
    ┌───────────┼───────────┬───────────┐
7
    │           │           │           │
8
    ▼           ▼           ▼           ▼
9
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
10
│架构队友│ │后端队友│ │前端队友│ │测试队友│
11
└────────┘ └────────┘ └────────┘ └────────┘
12
                │
13
                ▼
14
         Shared Task List
15
      （pending / in_progress / completed）

3.2 共享任务列表#

官方文档里，Agent Teams 的一个关键设计就是 Shared Task List。它不是简单的待办事项，而是团队成员协同的状态面板。

常见状态包括：

• pending
• in_progress
• completed

这个机制的价值在于：

• Team Lead 能知道谁正在做什么；
• teammate 之间能避免重复劳动；
• 在大任务里更容易控制依赖关系；
• 对多轮长任务来说，可追踪性明显更强。

3.3 直接消息通信#

Agent Teams 不是完全中心化的“总控台 + 工作者”模式。

在当前官方设计里，teammates 之间可以直接通信，而不是所有消息都必须经过 Team Lead 转发。这样做的好处是：

• 架构队友可以直接和实现队友对齐接口；
• 测试队友可以直接向实现队友反馈失败点；
• Team Lead 不需要处理所有细节通信，减轻主会话压力。

3.4 上下文隔离#

这是我认为 Agent Teams 最重要的一点。

单会话最大的痛点，是所有内容都在一个上下文里竞争注意力。任务一多，主会话很容易变成：

4.1 启用实验功能#

按照当前官方文档，推荐在 settings.json 中配置环境变量：

1
C:\Users\Administrator\.claude

1
{
2
  "env": {
3
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
4
  }
5
}

也可以直接使用环境变量方式开启。

4.2 版本检查#

先确认 Claude Code 版本是否足够新：

1
PS C:\Users\Administrator> claude --version
2
2.1.74 (Claude Code)

如果版本低于官方要求，就先升级，否则后面很多行为和界面都可能对不上。

4.3 显示模式#

当前官方文档提到，Agent Teams 有不同的 teammate 显示模式。

• 默认是 auto
• 如果终端支持，可以使用 tmux 相关模式看到分屏效果

需要注意的是，官方当前明确提到：

• VS Code 集成终端
• Windows Terminal
• Ghostty

这些环境不支持 split-pane teammate display。

4.4 首次创建团队#

启用后，你可以直接用自然语言告诉 Claude Code：

1
创建一个 4 人的开发团队：
2
1. 架构师，负责方案拆解和边界确认
3
2. 后端工程师，负责 API 和数据层修改
4
3. 前端工程师，负责页面和接口联调
5
4. QA 工程师，负责测试方案和回归验证
6

7
请先输出任务拆解，再开始执行。

如果是复杂任务，后面可以在加补充：

1
在开始改代码前，先让架构师给出文件边界、接口契约和风险点，经过我确认后再进入实现阶段。

这一步很关键。因为一旦你让多个 teammate 直接开工，而没有先做边界约束，文件冲突、重复修改和返工会非常常见。

5.1 阶段一：先做拆解，再做实现#

这边我没有用teams来写PRD，我在外面另外用 Gemini 生成了一份需求文档，这样可以马上微调

提示词：

1
请确认我的以下请求。请以产品经理的身份回复我。我会提供一个主题，您将协助我根据以下标题编写一份PRD文档：主题、简介、问题陈述、目标与目的、用户故事、技术需求、收益、关键绩效指标（KPI）、开发风险、结论。在我针对某个具体主题、功能或开发请求您编写之前，请不要主动撰写任何PRD文档。

5.2 阶段二：按文件归属并行实现#

需求确认后，再分配实现类任务：

1
我想开发一个语音转弹幕的项目。
2

3
创建一个团队来协作开发：
4

5
团队成员分工：
6
- Teammate A（后端开发）：设计整体架构，对接转译api，写接口给小程序和web界面
7
- Teammate B（小程序开发）：使用uni-app加vue3来开发微信小程序前端界面
8
- Teammate C（web前端开发）：使用vue3来实现web界面显示弹幕功能
9
- Teammate D（UI/UX设计）：设计小程序和web的ui，使用skill UI ux pro max
10
- Teammate E（测试）：测试网页是否正常
11

12
技术要求：
13
- 后端使用 java
14
- 小程序使用uni-app加vue3
15
- web使用使用vue3
16

17
请先让架构师设计整体方案，定义好数据结构后，其他成员再并行开发。

这时候 Agent Teams 的并行优势才会真正发挥出来。

5.3 阶段三：汇总与回归#

最后可以汇总一下：

• Team Lead 汇总每个 teammate 的产出
• QA 队友统一给出测试结果
• 架构队友确认没有偏离最初设计
• Team Lead 再输出最终结论

参考提示词：

1
停止新增修改，开始汇总：
2

3
1. 每个 teammate 用 5 条以内总结自己的工作
4
2. QA 队友列出已验证项、未验证项和风险点
5
3. Team Lead 输出最终交付摘要：
6
   - 改了什么
7
   - 为什么这样改
8
   - 还有哪些风险
9
   - 下一步建议

效果

场景一：多角度代码审查#

1
创建一个 agent team 审查这个 PR：
2
- 安全审查者：检查注入、XSS、权限等安全问题
3
- 性能审查者：分析 N+1 查询、内存泄漏、缓存策略
4
- 测试审查者：验证测试覆盖率和边界情况
5
让他们各自审查后汇报发现。

为什么适合 Agent Teams: 三个审查维度完全独立，不会产生文件冲突，可以并行执行。

场景二：新功能模块并行开发#

1
创建一个团队来构建用户通知系统：
2

3
队友 1：开发后端 API（src/api/notifications/）
4
队友 2：开发前端组件（src/components/notifications/）
5
队友 3：编写集成测试（tests/notifications/）

为什么适合: 每个队友负责不同目录，天然隔离，完成后合并即可。

场景三：竞争假设调试#

1
有一个间歇性 Bug，创建 team 用不同假设调试：
2
- 队友 A：调查是否是竞态条件
3
- 队友 B：调查是否是内存泄漏
4
- 队友 C：调查是否是第三方 API 超时
5
各自独立验证假设并汇报。

为什么适合: 对抗式调试，多条线索并行排查，谁先找到根因谁赢。

场景四：跨层修改协调#

当一个改动横跨前端、后端和数据库时，Agent Teams 可以让每层的专家各司其职，通过消息系统协调接口定义。

场景五：探索性研究#

1
我在设计一个 CLI 工具来追踪代码中的 TODO 注释。
2
创建一个团队从不同角度探索：
3
- 一个队友负责用户体验设计
4
- 一个队友负责技术架构
5
- 一个队友扮演"质疑者"（devil's advocate）

为什么适合: 多视角碰撞，互相挑战对方的假设和结论。

8.1 优势#

8.2 局限#

8.3 成本#

这点必须单独说。

官方文档已经明确提示：Agent Teams 会显著增加 token 消耗。Anthropic 的工程文章里，在多智能体研究系统实验中也提到，多智能体在效果更好的同时，通常也伴随更高的资源消耗。

所以正确的使用姿势不是“所有任务都上 Agent Teams”，而是：

• 简单任务：单会话或 subagents
• 中等复杂任务：2 到 3 个 teammates
• 复杂且可并行任务：Agent Teams

这才是比较合理的性价比。