“多人同时从不同角度看同一件事”是 Agent Teams 存在的全部理由——Claude Code 这套协作机制并不是为加速而加速，而是为对抗单 Agent 模式天然存在的两类偏差：关注点偏移与确认偏差。下面把官方反复点名、且在工程实践里被反复印证为强适用的几类任务逐一拆开。
一、Agent Teams 的价值锚点是”平行探索”
Agent Teams 之所以存在，是因为单 Agent 模式天然存在两类偏差：其一是关注点偏移，单 Agent 倾向于一次只深挖一个角度，看完安全就忘了性能；其二是确认偏差，单 Agent 找到一个合理解释后会很快停止寻找替代解释。多 Agent 团队靠”同一时间、不同视角”对冲这两类偏差。
| 偏差类型 | 单 Agent 表现 | Agent Teams 对策 |
|---|---|---|
| 关注点偏移 | 一次只盯一类问题 | 拆分维度、并行扫描 |
| 锚定偏差 | 找到首个合理解释就停 | 让成员主动反驳彼此 |
| 串行成本 | 做完 A 再做 B | 多成员同跑、A 与 B 同步推进 |
需要提醒的是，团队不会让所有任务都更快。文档明确指出，常规任务用单 Agent 更划算，团队模式只在前述偏差明显且能被多视角消除时收益才大于协调成本。
二、官方列出的强适用场景
按官方文档与开发者社区的复盘，Agent Teams 在以下四类场景的”平行探索”价值比较稳定。
- 代码审查（并行多角度）：让安全、性能、测试覆盖三个成员同时审同一份 PR，每人只盯一个维度，最后由 lead 汇总。比起一个审查者反复切换角度，盲区明显减少。
- 多模块 / 新功能开发：每个成员负责独立模块或文件，互不重叠，特别适合前后端、数据库、CI 脚本这种天然分层的活儿。
- 多假设调试（Competing Hypotheses）：在根因不明时，让若干成员各自提出假设、互相反驳，类似”科学辩论”模式，可以避免”试了一个不行再试下一个”的串行陷阱。
- 跨层改动协调（Cross-Layer Coordination）：涉及前端、后端、测试多层的修改，让每个 teammate 守住一层，靠消息机制同步接口和数据流，能让全栈修改保持一致。
- 研究与调研：让多个成员分别研究不同方案（如三种 OAuth 方案、三家云厂商），最后由 lead 对比汇总，比单 Agent 顺序调研快出几个量级。
官方原话：Agent Teams 适合研究、审查、新功能开发这类”平行探索价值高于成本”的任务；日常任务用单 Agent 更经济。
三、代码审查：把三类 reviewer 同时摆上桌
让 lead 派三个 reviewer 同时开工，是 Agent Teams 性价比很高的一种入门用法。下面给一个可复用的 prompt 模式：
Spawn three teammates to review PR #142:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.每个 reviewer 读同一份 PR，但过滤维度不同，lead 在所有 reviewer 报告完成后再做一次去重与汇总。比起单 Agent 顺序审，盲区明显更少，争议点也能被多视角暴露。
四、多假设调试：用”互相反驳”打破锚定
根因排查里很常见的一种失败模式，是”先想到的解释被反复验证，最终被错认为根因”。Agent Teams 提供了一种对抗这种偏差的结构化方法——让多个成员明确地、主动地反驳彼此。
Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses.
Have them talk to each other to try to disprove each other's theories,
like a scientific debate. Update the findings doc with whatever consensus emerges.这种结构的关键不在”人多”，而在”互相证伪”。每个成员不仅要研究自己的理论，还要负责把其他人的理论打掉——最后能存活的解释大概率就是真正的根因。
五、团队规模的取舍
官方建议从 3–5 个 teammate 起步，主要出于三方面的工程考量：
- token 成本线性增长：每个 teammate 有独立 context window，费用与数量成正比；
- 协调成本上升：越多 teammate，消息与任务协调越复杂；
- 收益递减：超过某个点，新成员带来的边际收益急剧下降。
| 团队规模 | 适用任务 | 注意事项 |
|---|---|---|
| 3 个 | 单一模块审查、单功能开发 | 协调成本最小 |
| 4–5 个 | 跨层改动、多方案调研 | 推荐默认规模 |
| 6 个以上 | 大型重构、并行多实验 | 务必严格拆分文件边界 |
每个 teammate 配 5–6 个任务比较有利于保持节奏，任务太小（协调成本高）或者太大（成员长时间无 check-in）都会拉低效率。
六、明确不该用团队的反模式
官方与社区都强调了几类应避免使用 Agent Teams 的场景：
- 强串行任务：B 必须等 A 结果的任务，单 Agent 串行比并行更稳；
- 多人改同一文件：会导致互相覆盖，必须先按文件拆分再谈并行；
- 小到不值一提的改动：单变量改名、单词改写等任务，团队开销远大于收益；
- 强依赖关系：跨多个共享状态的耦合任务，团队反而会因协调拖慢进度。
判断方法很直接：先问”如果让两个人同时做这件事，他们会不会撞车”，会撞车就拆文件，拆不动就退回单 Agent。
常见问题（FAQ）
Q1：团队规模应该从多少开始？
官方建议 3–5 个 teammate 起步，能覆盖多数任务且协调成本可控。
Q2：调试场景下”互相反驳”是必须的吗？
是的。竞争假设场景的核心机制就是让成员主动证伪彼此，否则多 Agent 会陷入”各自深挖自己的假设”反而更慢。
Q3：Agent Teams 会比单 Agent 更贵吗？
会。每个 teammate 有独立 context window，token 用量随成员数线性增加；常规任务仍优先单 Agent。
