Claude Code 在 Opus 4.6 发布的同一天推出了 Agent Teams 功能。简单说：你可以在 Claude Code 里同时起多个 Agent，让它们并行工作。

听起来很酷。但"多 Agent 并行"在实际使用中，token 消耗是 single agent 的好几倍。不了解这一点就开干，月底看账单可能会心跳加速。

Agent Teams 是什么

以前 Claude Code 一次只能跑一个 Agent。你让它改代码，它从头到尾串行执行：读文件 → 分析 → 修改 → 测试。遇到大项目，一个 Agent 要自己处理前端、后端、测试，效率低且容易在中途丢失上下文。

Agent Teams 让你拆分任务。主 Agent 可以 spawn 多个子 Agent，每个子 Agent 独立工作，有自己的上下文。比如做一次大的 codebase review：

• Agent A 检查前端组件
• Agent B 审查后端 API
• Agent C 跑测试覆盖分析
• Agent D 检查配置和依赖

它们并行执行，各自读文件、分析代码，最后汇总结果。

怎么开启

目前还是研究预览阶段，需要手动开环境变量：

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

设完之后启动 Claude Code，模型在需要时会自动决定是否拆分任务。你也可以在提示里显式要求：“把这个任务拆成多个 Agent 并行处理。”

子 Agent 跑起来后，你能看到多个 Agent 的实时状态。用 Shift+Up/Down 可以切换到不同子 Agent 的窗口，直接接管操作。底层用的是 tmux。

适合什么场景

Anthropic 在文档里说得很明确：Agent Teams 最适合"独立的、读操作为主的任务"。

好的场景：

• Codebase review（不同模块互不干扰）
• 多文件的 bug 分析（每个 Agent 查一个可疑区域）
• 文档生成（每个 Agent 负责一部分文档）
• 多仓库的依赖检查

不好的场景：

• 多个 Agent 同时改同一个文件（冲突）
• 有严格执行顺序的任务（A 的输出是 B 的输入）
• 写操作密集的任务（合并冲突很难自动处理）

如果你的任务需要多个 Agent 之间频繁通信和协调，现阶段 Agent Teams 可能帮不了太多。它更像是"并行的独立工人"，不是"紧密配合的团队"。

Token 消耗：这是重点

每个子 Agent 是一个独立的对话。它有自己的 system prompt、自己的上下文、自己的工具调用。

也就是说，你起 4 个子 Agent，token 消耗至少是 4 倍，通常更多——因为每个 Agent 都需要：

1. 理解整体任务（主 Agent 把任务描述传过去）
2. 读取相关文件（即使只分析一部分，也需要理解项目结构）
3. 独立思考和推理

根据 Claude Code 的 changelog，官方也标注了"token-intensive feature"。

一个粗略的估算。假设你让单个 Agent 做一次完整的 code review，消耗 50K 输入 token + 10K 输出 token，成本约 $0.50。

拆成 4 个子 Agent，每个消耗 30K 输入 + 5K 输出（每个子任务更小，但基础开销不变），再加上主 Agent 的协调开销（~20K 输入 + 3K 输出），总成本约 $1.00。翻了一倍。

快了吗？快了。墙上时间从 5 分钟降到 2 分钟（并行执行）。值不值，取决于你对时间和钱的权衡。

控制成本的几个办法

1. 用 API 调用而不是 Pro 订阅

如果你用的是 Claude Pro（$20/月），Agent Teams 会很快把 Opus 的使用额度吃光。Pro 计划对 Opus 有使用限制，"几个小时的 vibe coding"就可能触顶，等几小时才能恢复。

用 API 调用 + 自己控制 budget 会更可预测。通过 ANTHROPIC_API_KEY 接入，设好每日/每月预算上限。

2. 子 Agent 用低 effort

主 Agent 负责规划和汇总，需要高质量的推理，用 high effort。子 Agent 执行的是更明确的子任务，用 medium 或 low effort 就够了。

Claude Code 里可以通过配置让子 Agent 使用特定的 effort 级别。changelog 里也提到"claude can dynamically choose the model used by its subagents"——主 Agent 可以让子 Agent 用更便宜的模型（比如 Sonnet 或 Haiku）。

3. 限制子 Agent 数量

不是越多越好。每个额外的子 Agent 都有固定的初始化开销。对于大多数任务，2-4 个子 Agent 是性价比最高的区间。超过这个数量，协调成本上升，收益递减。

4. 明确子任务边界

给子 Agent 的任务描述越具体，它花在"理解任务"上的 token 越少。

差的提示：“检查这个项目有没有问题。”
好的提示：“检查 src/api/ 目录下所有 handler 文件的错误处理逻辑，重点看是否有未捕获的异常和缺失的 HTTP 状态码。”

跨平台的模型别名问题

跟 Agent Teams 没有直接关系，但在使用 Claude Code 时经常遇到：opus 这个模型别名在不同平台上指向不同的模型版本。

GitHub 上有个真实的 issue（#18447）：用 Vertex AI 时，opus 解析成 Opus 4.1；用 Anthropic 直连 API 时，opus 解析成 Opus 4.5。如果你的 Vertex AI 项目只开通了 Opus 4.5 没有 4.1，直接 404。

Opus 4.6 发布后，这个问题更容易碰到。

解决办法：不要用 opus 别名，显式指定完整 model ID。

# 不要这样
claude --model opus

# 要这样
claude --model claude-opus-4-6

或者用环境变量覆盖：

export ANTHROPIC_DEFAULT_OPUS_MODEL="claude-opus-4-6"

Hacker News 上也有人反映 Claude Code 默认切到 Opus 导致 API 账单突增。如果你是 API 付费用户，一定要确认 Claude Code 用的是哪个模型——在 Claude Code 里输入 /model 可以查看和切换。

现阶段的定位

Agent Teams 目前是研究预览，不是生产就绪的功能。Anthropic 自己也给了这个定位。

值得试的场景：你日常用 Claude Code 做大项目开发，经常觉得"一个 Agent 忙不过来"。开了 Agent Teams，让它在 review、重构、文档这些并行性强的任务上分工。

不建议的场景：你想在自己的产品里集成"多 Agent 协作"。Agent Teams 是 Claude Code 的功能，不是 API 功能。如果你想在 API 层面实现多 Agent，看 Anthropic 的 Agent SDK 或自己用多个 API 请求编排。