Claude Code 终极进阶：Agent Teams 让 AI 团队真正协作

发表于 更新于 分类于 阅读次数： 本文字数： 7.1k 阅读时长 ≈ 6 分钟

cover

Subagents 用了一段时间后，我遇到了一个新问题：前端 Subagent 发现了一个 API 返回格式的问题，但它只能把结果报告给我，我再转达给后端 Subagent。

这个”中转”的过程很低效。真实的开发团队里，前端工程师发现 API 问题，会直接找后端工程师讨论，不需要每次都经过项目经理。

Agent Teams 就是为了解决这个问题。

Agent Teams 不是”更多的 Subagents”，而是”会互相沟通的独立 Claude 实例”。每个 teammate 有自己的上下文窗口，可以直接给其他 teammates 发消息，通过共享任务列表协调工作。

2026 年 2 月，Anthropic 随 Opus 4.6 发布了这个实验性功能。一个月后，社区已经用它完成了从代码重构到内容创作的各种复杂任务。有人用 3 个 teammates，花 15 分钟和 $7.80，生成了一周的社交媒体内容。

什么是 Agent Teams？为什么需要它

先搞清楚一个核心概念：Agent Teams 不是 Subagents 的升级版，而是完全不同的架构。

Subagents 的工作方式：

一个主 Claude 会话，里面运行多个 Subagents。Subagents 在独立的上下文中工作，完成后把结果返回给主 Claude。它们之间不能直接通信。

就像一个项目经理带着几个外包团队。每个团队独立工作，完成后向项目经理汇报。团队之间不直接交流。

Agent Teams 的工作方式：

多个独立的 Claude Code 会话，每个都是完整的 Claude 实例。它们可以：

  • 直接给其他 teammates 发消息
  • 通过共享任务列表协调工作
  • 独立做决策，不需要每次都请示 team lead

就像一个真实的开发团队。每个人有自己的工作区，可以直接沟通，通过看板协调任务。

Agent Teams 的三大优势：

1. 真正的并行协作

Subagents 是”并行执行，串行汇报”。Agent Teams 是”并行执行，并行协作”。

前端 teammate 发现 API 返回格式有问题，可以直接给后端 teammate 发消息：”嘿，这个接口返回的数据结构不对，能改一下吗？”后端 teammate 收到消息，立即修改，然后回复：”改好了，现在返回的是数组。”

整个过程不需要 team lead 介入。

2. 独立的上下文窗口

每个 teammate 都是完整的 Claude Code 实例，有自己的 200K token 上下文窗口。

在大型项目中，这个优势尤其明显。一个 teammate 负责前端，加载所有 React 组件；另一个负责后端，加载所有 API 代码；第三个负责测试，加载所有测试文件。它们不会互相挤占上下文空间。

3. 灵活的任务分配

Team lead 可以动态创建任务，teammates 可以自己认领任务，也可以创建新任务。

就像真实的敏捷团队，通过任务看板协调工作，而不是事事请示。

Agent Teams vs Subagents：什么时候用哪个

很多人会困惑：我已经有 Subagents 了，为什么还需要 Agent Teams？

答案是：它们解决不同的问题。

Subagents 适合：

  • 快速的并行任务（代码审查、多文件搜索）
  • 不需要互相沟通的独立任务
  • 预算有限的场景（Subagents 共享主会话的上下文）

Agent Teams 适合：

  • 需要协作的复杂任务（全栈功能开发、大型重构）
  • 跨层级的工作（前端+后端+数据库+测试）
  • 需要独立决策的场景（每个 teammate 可以自主判断）

对比表格：

特性 Subagents Agent Teams
架构 单个会话，多个子进程 多个独立会话
通信 只能向主 Claude 报告 可以互相发消息
上下文 共享主会话的上下文 每个有独立的上下文窗口
成本 较低 较高（每个 teammate 独立计费）
协调 主 Claude 协调 通过任务列表和消息协调
适用场景 简单并行任务 复杂协作任务

经验法则：

  • 任务可以完全独立完成 → 用 Subagents
  • 任务需要频繁沟通协调 → 用 Agent Teams
  • 预算紧张 → 用 Subagents
  • 项目复杂度高 → 用 Agent Teams

90% 的情况下，Subagents 就够了。只有在真正需要多个 AI 协作的复杂项目中，才需要 Agent Teams。

启用 Agent Teams：5 分钟配置

Agent Teams 是实验性功能，默认关闭。启用很简单。

第一步：检查前置条件

必需：

  • Claude Code 已安装
  • Claude Opus 4.6 模型
  • Pro 订阅（$20/月）或 Max 订阅（$100-$200/月）

可选但推荐：

  • tmux（实现多面板显示）

检查你的 Claude Code 版本：

1
claude --version

确保是 v2.1.32 或更高版本。

第二步：启用 Agent Teams

有两种方式启用：

方式一：通过 settings.json（推荐）

找到你的 Claude Code 配置文件：

1
2
3
4
5
# macOS/Linux
~/.claude/settings.json

# Windows
%USERPROFILE%\.claude\settings.json

打开文件，添加：

1
2
3
{
  "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}

保存文件。

方式二：通过环境变量

在你的 shell 配置文件中添加：

1
2
# ~/.zshrc 或 ~/.bashrc
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

然后重启终端。

第三步：安装 tmux（可选）

tmux 让每个 teammate 有自己的终端面板，方便观察。

macOS：

1
brew install tmux

Linux：

1
2
sudo apt install tmux  # Ubuntu/Debian
sudo yum install tmux  # CentOS/RHEL

Windows：

Windows 用户可以使用 WSL（Windows Subsystem for Linux）安装 tmux。

第四步：验证配置

重启 Claude Code：

1
claude

输入：

1
Agent Teams 功能是否已启用？

如果 Claude 回复说 Agent Teams 已启用，说明配置成功。

实战：创建你的第一个 Agent Team

让我们通过一个实际案例来理解 Agent Teams 的工作方式。

场景：全栈功能开发

假设你要添加一个”用户评论”功能，涉及前端、后端、数据库和测试。

第一步：启动 Claude Code

如果安装了 tmux，先启动 tmux：

1
tmux

然后在 tmux 中启动 Claude Code：

1
claude

第二步：创建 Agent Team

用自然语言描述你的需求和团队结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
创建一个 Agent Team 来实现用户评论功能。

团队结构：
1. Frontend Developer：负责 React 组件和 UI
2. Backend Developer：负责 API 端点和业务逻辑
3. Database Engineer：负责数据库迁移和查询优化
4. Test Engineer：负责编写和运行测试

任务：
- 设计评论数据模型
- 创建数据库迁移
- 实现后端 API（创建、读取、删除评论）
- 实现前端组件（评论列表、评论表单）
- 编写单元测试和集成测试

请通过共享任务列表协调工作。

第三步：Claude 创建团队

Claude 会：

  1. 分析你的需求
  2. 创建一个 team lead（你当前的会话）
  3. 生成 4 个 teammates
  4. 创建共享任务列表
  5. 分配初始任务

如果你使用了 tmux，会看到屏幕分成多个面板，每个 teammate 有自己的面板。

第四步：观察协作

你会看到 teammates 开始工作：

Database Engineer：

1
2
3
4
[database-engineer] 创建任务：设计评论表结构
[database-engineer] 正在分析现有数据库架构...
[database-engineer] 发现用户表已存在，可以建立外键关联
[database-engineer] 创建迁移文件：20260312_create_comments_table.sql

Backend Developer：

1
2
3
4
[backend-developer] 等待数据库迁移完成...
[backend-developer] 收到消息：数据库表已创建
[backend-developer] 开始实现 API 端点...
[backend-developer] 创建文件：src/api/comments.js

Frontend Developer：

1
2
3
[frontend-developer] 发消息给 backend-developer：API 端点的路径是什么？
[frontend-developer] 收到回复：/api/comments
[frontend-developer] 开始实现评论组件...

Test Engineer：

1
2
3
[test-engineer] 等待实现完成...
[test-engineer] 收到通知：API 已实现
[test-engineer] 开始编写测试用例...

第五步：直接与 Teammate 交互

你可以直接给某个 teammate 发消息：

1
@backend-developer 能否添加分页功能？每页 20 条评论

Backend Developer 会收到消息并回复：

1
2
[backend-developer] 收到。正在添加分页参数...
[backend-developer] 已完成。API 现在支持 ?page=1&limit=20

第六步：查看进度

查看任务列表：

1
显示当前任务列表

你会看到：

1
2
3
4
5
6
7
任务列表：

✅ 设计评论表结构（database-engineer）
✅ 创建数据库迁移（database-engineer）
✅ 实现 API 端点（backend-developer）
🔄 实现前端组件（frontend-developer，进行中）
⏳ 编写测试用例（test-engineer，等待中）

第七步：完成和总结

当所有任务完成后，team lead 会总结：

1
2
3
4
5
6
7
8
9
10
11
12
13
评论功能开发完成！

完成的工作：
- 数据库：comments 表，包含外键和索引
- 后端：3 个 API 端点（创建、读取、删除），支持分页
- 前端：CommentList 和 CommentForm 组件
- 测试：12 个单元测试，3 个集成测试

所有测试通过 ✅

文件变更：
- 新增：5 个文件
- 修改：2 个文件

整个过程，4 个 teammates 并行工作，互相沟通，15-20 分钟完成。

最佳实践：让 Agent Teams 更高效

1. 控制团队规模

建议：3-5 个 teammates

更多的 teammates 不一定更快。协调开销会随着人数增加而增加。

好的例子：

  • 3 人团队：前端、后端、测试
  • 4 人团队：前端、后端、数据库、测试
  • 5 人团队：前端、后端、数据库、测试、文档

不好的例子：

  • 10 人团队：协调开销大于收益

2. 明确职责边界

每个 teammate 应该有清晰的职责范围。

好的职责划分：

1
2
3
4
5
6
7
8
9
Frontend Developer：
- 负责 src/components/ 目录
- 实现所有 React 组件
- 处理前端状态管理

Backend Developer：
- 负责 src/api/ 目录
- 实现所有 API 端点
- 处理业务逻辑

不好的职责划分：

1
2
Developer 1：做一些前端和后端
Developer 2：也做一些前端和后端

职责重叠会导致冲突和重复工作。

3. 利用 CLAUDE.md

在项目根目录创建 CLAUDE.md，所有 teammates 都会读取：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 项目规范

## 技术栈
- Frontend: React 18 + TypeScript
- Backend: Node.js + Express
- Database: PostgreSQL
- Testing: Jest

## 编码规范
- 使用函数式组件
- 所有函数必须有 TypeScript 类型
- API 路径格式：/api/v1/resource

## 测试要求
- 每个 API 端点必须有测试
- 测试覆盖率 > 80%

这样所有 teammates 都遵循相同的规范，减少沟通成本。

4. 成本控制

Agent Teams 的成本是 Subagents 的 3-5 倍（因为每个 teammate 有独立的上下文窗口）。

降低成本的方法：

  1. 只在必要时使用：简单任务用 Subagents
  2. 控制团队规模：3-5 人最经济
  3. 清晰的 CLAUDE.md：减少探索时间
  4. 明确的任务描述：避免返工

成本估算：

  • 3 人团队，20 分钟任务：约 $5-10
  • 5 人团队，30 分钟任务：约 $10-20

5. 任务分解要合理

把大任务分解成可以并行的小任务。

好的分解：

1
2
3
4
任务 1：设计数据库表（database-engineer）
任务 2：实现 API（backend-developer，依赖任务 1）
任务 3：实现前端（frontend-developer，依赖任务 2）
任务 4：编写测试（test-engineer，依赖任务 2 和 3）

有依赖关系，但可以流水线式并行。

不好的分解：

1
任务 1：实现整个功能（所有人一起做）

没有并行空间。

6. 监控进度

定期检查任务列表：

1
显示任务列表和每个 teammate 的状态

如果某个 teammate 卡住了，可以介入帮助或重新分配任务。

常见问题排查

问题 1：Agent Teams 功能未启用

症状：Claude 说不支持 Agent Teams。

解决：

  1. 检查配置文件：
    1
    cat ~/.claude/settings.json

确保包含：

1
2
3
{
  "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}

  1. 检查环境变量：

    1
    echo $CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS

  2. 重启 Claude Code

问题 2：Teammates 之间没有通信

症状：Teammates 各自工作，不互相沟通。

原因：任务描述不够明确，或者职责没有重叠。

解决：

在创建团队时明确说明需要协作：

1
2
3
4
创建 Agent Team，teammates 需要互相沟通协调。

Frontend Developer 需要向 Backend Developer 确认 API 格式。
Backend Developer 需要向 Database Engineer 确认表结构。

问题 3：成本太高

症状：一个任务花费了几十美元。

原因：团队规模太大，或者任务时间太长。

解决：

  1. 减少 teammates 数量（3-5 人最佳）
  2. 提供清晰的 CLAUDE.md，减少探索时间
  3. 把大任务拆分成多个小任务，分批完成

问题 4：Teammates 产生冲突

症状：多个 teammates 修改了同一个文件，产生冲突。

原因：职责边界不清晰。

解决：

明确每个 teammate 负责的文件或目录：

1
2
3
Frontend Developer：只修改 src/components/
Backend Developer：只修改 src/api/
Database Engineer：只修改 migrations/

实际应用场景

场景一：大型代码重构

1
2
3
4
5
6
7
8
9
创建 Agent Team 重构支付模块。

团队：
1. API Refactor：重构 API 层
2. Database Migration：迁移数据库
3. Test Update：更新测试
4. Documentation：更新文档

要求：保持向后兼容，所有测试必须通过。

4 个 teammates 并行工作，互相协调，确保重构不破坏现有功能。

场景二：多平台功能开发

1
2
3
4
5
6
7
8
9
创建 Agent Team 实现跨平台通知功能。

团队：
1. iOS Developer：实现 iOS 推送
2. Android Developer：实现 Android 推送
3. Backend Developer：实现通知服务
4. Web Developer：实现 Web 通知

通过共享任务列表协调 API 接口设计。

场景三：内容创作流水线

1
2
3
4
5
6
7
8
9
创建 Agent Team 生成一周的社交媒体内容。

团队：
1. Researcher：搜集行业资讯和热点
2. Copywriter：撰写文案
3. Designer：设计配图（描述设计需求）
4. Scheduler：规划发布时间

目标：生成 7 天的内容，包括文案、配图需求、发布时间。

这个案例中，有人用 3 个 teammates，15 分钟完成，花费 $7.80。

场景四：代码审查流水线

1
2
3
4
5
6
7
8
9
创建 Agent Team 审查这个 PR。

团队：
1. Security Reviewer：检查安全漏洞
2. Performance Reviewer：分析性能问题
3. Code Quality Reviewer：检查代码质量
4. Test Reviewer：检查测试覆盖率

每个 reviewer 独立审查，最后汇总报告。

写在最后

Agent Teams 的成本是 Subagents 的 3-5 倍，这个数字让我在用之前会认真想一下：这个任务真的需要多个 AI 互相沟通吗？

大多数时候，答案是不需要。Subagents 就够了。

但有一次我在做一个全栈功能，前端、后端、数据库都要改，而且改动之间有依赖关系。用 Subagents 的话，我得手动协调每一步的顺序。那次我试了 Agent Teams，4 个 teammates 自己协商了依赖顺序，我只是偶尔看一眼进度。

那次之后我的判断标准变了：如果我需要手动协调多个 Subagents 之间的信息传递，就换 Agent Teams。如果任务可以完全独立完成，就继续用 Subagents。

我现在还在摸索 Agent Teams 的边界——什么规模的任务值得这个成本，什么时候 3 人团队比 5 人团队更高效。这个问题我还没有确定的答案。