Claude Code 新功能 Agent Teams：4 类活效率翻倍，4 类活纯烧 token

一个被低估的更新

Claude Code v2.1.32 以后，多了一个实验性功能 Agent Teams。

打开方式很朴素，settings.json 里加一行：

json 复制代码

{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } }

然后跟 Claude 说"开个 team"，它会自己拉起 N 个独立的 Claude Code 会话，每个有自己的上下文窗口、自己的任务、自己的终端，互相还能直接发消息。

我看到不少人评论"这不就是 subagent 吗"。完全不一样。一周用下来，我意识到 Anthropic 在这里做的事情，本质上是把 Claude Code 从"一个 AI 助手"升级成了"一个能开会的 AI 团队"。

但代价也很直接：token 用量线性放大。 5 个 teammate 同时干活，账单就是 5 倍。Pro 的 5 小时配额，5 个并行会话能在 1 小时内烧光。

所以问题不是"要不要用 Agent Teams"，而是"哪些活值得烧 5 倍 token 去并行，哪些活老老实实单会话搞定"。

下面这张表，是我跑了一周后总结出来的判断线。

Subagents vs Agent Teams：先把概念分清

很多人把这两个搞混，是后面用错的根源。

维度	Subagents	Agent Teams
谁在管	主 agent 派单 + 汇总	一个 lead 协调，teammate 自我推进
上下文	独立窗口，结果回传主 agent	独立窗口，完全独立
通信方式	只能向主 agent 报告	teammate 之间互发消息
协调机制	主 agent 串行调度	共享任务表 + 文件锁 + 邮箱
Token 成本	较低（结果汇总回主上下文）	较高（每个 teammate 独立计费）
适合的活	顺序、聚焦、要个结果就行	并行、要讨论、要互相挑战

一句话区分：Subagents 是"派几个人去干活"，Agent Teams 是"开个项目组并行推进"。

如果你的任务可以拆成"互不依赖、能各自跑完"的几块，Teams 才划算。如果任务本质是串行的（比如"先调研再写代码再写测试"），强行开 Team 只会让 lead 自己一个人干完，浪费 4 个 teammate 的 token。

4 类活，值得烧 5 倍 token

① 多视角代码评审

一个 reviewer 一次只能盯一个角度。让一个人同时看安全、性能、测试覆盖率，结果就是哪个深度都不够。

Agent Teams 的标准玩法是：

text 复制代码

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage

三个 reviewer 各自带一个滤镜过同一份 diff，lead 最后汇总冲突点。我实测下来，找出来的问题数量大约是单 reviewer 的 2.3 倍，而且类别覆盖更均衡------单 reviewer 总会偏向一类问题。

② 调试时的"竞争假设"

文档里有一个特别精妙的例子：让多个 teammate 各持一个 bug 假设，互相挑刺，像科学辩论一样推进。

text 复制代码

Spawn 5 teammates to investigate different hypotheses.
Have them talk to each other to try to disprove
each other's theories, like a scientific debate.

单会话调 bug 有个很大的认知偏差：找到第一个看起来合理的解释就停。但 5 个 teammate 互怼，能活下来的假设，大概率才是真正的 root cause。

这是我用 Teams 体感最强烈的场景。老 bug、看不出根因的诡异问题，并行竞争比串行试错快得多。

③ 跨层协作

前端、后端、测试，三层同时改的活。

让前端 teammate 改 UI，后端 teammate 改 API，测试 teammate 同步更新断言，三个人通过共享任务表对齐契约。一个改完通知另一个，blocked 任务自动解锁。

关键前提：三层之间通过 schema / 接口契约对齐，不直接编辑同一份文件。

④ 新模块拆分开发

一个新功能拆成 5 个独立模块------比如一个 CLI 工具的 5 个子命令、一个微服务的 5 个 endpoint。

每个 teammate 拿一块，互不踩脚。lead 最后做集成测试。

这种场景下，Teams 的优势是真正的物理并行，5 个 endpoint 同时写，比串行写完一个等下一个快 3-4 倍（不到 5 倍的原因是协调和集成有损耗）。

4 类活，白烧 token

① 顺序依赖任务

"先调研用户反馈，再设计方案，再写代码，再写测试"------这是个纯串行任务。

强行开 Team，结果就是 4 个 teammate 互相等，lead 自己干完所有活。

判断方法：把任务画成依赖图，如果是一条线，单会话或 subagent 就够。

② 同文件编辑

两个 teammate 改同一份文件，必然冲突。Teams 里虽然有文件锁，但锁住的那个 teammate 就是空转。

很多人把"并行开发"想成"5 个人改同一个仓库"，这跟"5 个人改同一份文件"是两回事。

判断方法：能不能把工作拆成"每个 teammate 只动一组互斥的文件"------能拆就上，拆不动就别用。

③ 小项目 / 小任务

总代码量 500 行以下，或者任务能在 30 分钟内单会话搞定。

协调成本（lead 派单、teammate 接活、互相对齐）会吃掉所有并行收益。

判断方法：3-5 teammate 是甜区，每人分到 5-6 个独立子任务最舒服。如果你只能拆出 3 个子任务，开 1 个会话或 2-3 个 subagent 就行。

④ 探索性任务

"帮我看看这个库怎么用"、"我想做个小工具但还没想清楚"。

这种活的本质是"信息密度低 + 频繁换方向"，lead 还没想清楚要什么，就让 5 个 teammate 各跑各的，跑完发现方向变了，5 倍 token 白烧。

判断方法：你能不能在 60 秒内给 5 个 teammate 写出明确、互不重叠的 spawn prompt。写不出，就不该开 Team。

一份可复用的决策清单：8 条线

每次想用 Agent Teams 前，过一遍这 8 个问题。5 个"是"以上才上 Team：

任务能拆成 3 个以上互不依赖的子任务吗？
每个子任务都能在没有其他子任务结果的情况下推进吗？
每个 teammate 编辑的文件集合互斥吗？
我能在 60 秒内为每个 teammate 写出明确的 spawn prompt 吗？
任务规模够大吗？（单会话至少要干 1 小时以上才划算）
我有耐心同时监控 3-5 个会话吗？（不监控会跑飞）
我的 Claude 配额经得起 5 倍消耗吗？（Pro 5 小时配额 / 5 ≈ 1 小时）
我能接受这是个实验性功能吗？（不支持 /resume，崩了要重来）

5 条实战避坑

1. 用 in-process 模式起步，别一上来就 tmux

split-pane 看起来酷，但要装 tmux 或 iTerm2 的 it2 CLI，VS Code 内置终端、Windows Terminal、Ghostty 都不支持。

新手先用默认的 in-process 模式，按 Shift+Down 在 teammate 之间切换就够了，体感学习曲线低一半。

2. 给 teammate 选小模型

Lead 用 Opus，teammate 用 Sonnet------很多场景这样配置就够，token 账单能砍掉一大半。

text 复制代码

Create a team with 4 teammates to refactor these modules in parallel.
Use Sonnet for each teammate.

3. 风险大的活，强制要求 plan approval

让 teammate 先出方案、lead 审批通过才允许动代码：

text 复制代码

Spawn an architect teammate to refactor the authentication module.
Require plan approval before they make any changes.

特别适合数据库迁移、架构改动这种"改错了很难回滚"的活。

4. lead 经常会"自己抢着干"

文档里都标了这个坑：lead 有时候不耐烦，自己把活干完了，teammate 空闲在旁边。

补一句话就行：

text 复制代码

Wait for your teammates to complete their tasks before proceeding

5. 收工记得 clean up

text 复制代码

Clean up the team

不然 tmux 会话、任务表、team 配置会留在 ~/.claude/teams/ 和 ~/.claude/tasks/ 里，下次起新 team 会冲突。

写在最后：这不是"AI 提效工具"，是"工作组织方式"的迁移

Subagent 时代，AI 还是"我的助手"------我派活、它干、它汇报。

Agent Teams 时代，AI 开始有"项目组"的形态------我定方向，team 自己分工、自己对齐、自己讨论、自己交付。

我自己最大的转变是：写 spawn prompt 的精力，比写代码本身花得还多。 这跟带人的体感非常像------一句话说不清楚，5 个 teammate 全跑偏；说清楚了，一晚上能干完单人三天的活。

这件事最值得思考的不是"Claude Code 又新增了一个功能"，而是：当 AI Agent 开始有团队结构，"项目经理"反而是普通开发者最容易上手的下一个角色。

不会管人的人，未来连 AI 也管不动。

参考资料

Anthropic 官方文档：Orchestrate teams of Claude Code sessions
CloudZero 成本分析：Claude Code Agents In 2026: Parallel Sessions Actually Cost
MindStudio 对比指南：Agent Teams vs Sub-Agents