多 Agent 真正的难点，不是“能不能并行”，而是“并行之后会不会更乱”。
很多团队一听到 Claude Code 推出 Agent Teams，第一反应都是：好，终于可以把一个大任务拆给多个 Agent 一起干了。
但如果你真的做过工程协作，很快就会意识到：
- 并行不等于高效
- 多会话不等于多产能
- 多 Agent 最大的成本，往往不是 token，而是协调成本
这也是为什么我很喜欢把 Claude Code 里两个能力分开看：
- Subagents：单会话内的“专职工”
- Agent Teams：多会话协作的“项目组”
如果你把这两个东西混成一类，你会很容易误判场景：本来只需要一个轻量 subagent 的任务，结果你拉起了一个 team，最后人还没省下，复杂度先翻倍。
这篇文章不讲概念炫技，重点回答一个更实用的问题：
什么时候该用 Agent Team，什么时候只该用 Subagent？
我会从工作机制、成本模型、典型场景、失败模式和落地建议五个维度展开，帮你建立一套能直接用于工程决策的判断框架。
一、先把概念掰正：它们不是一个层级的能力
很多人说“Claude Code 支持多 Agent”，这句话不算错，但太粗。
因为 Claude Code 里至少有两种完全不同的多代理机制：
1）Subagents：主代理的“分身工具”
Subagent 的核心特点是：
- 运行在同一个主会话的大框架内
- 拥有自己的上下文窗口
- 可以被赋予专门的系统提示和工具权限
- 只向主代理回传结果，不会彼此直接对话
你可以把它理解成：主代理临时雇了一个专家去干活，专家回来交报告，最后仍然由主代理做综合判断。
这类模式特别适合：
- 代码搜索
- 定向分析
- 只读调研
- 小范围验证
- 明确边界内的局部修改
它的本质是：把探索和执行从主上下文里隔离出去，但不引入真正的团队协作。
2）Agent Teams：真正的“多会话协作”
Agent Teams 则完全不同。
它不是主代理叫几个助手查资料，而是直接拉起一支团队：
- 每个 teammate 都是独立会话
- 可以维护自己的任务上下文
- 可以通过共享 task list 协作
- 可以彼此发消息，形成 agent 间协同
- 主 lead 负责统筹、分配和汇总
这个模式更像一个真实项目组：
- 一个负责架构
- 一个负责前端
- 一个负责后端
- 一个负责测试或反驳假设
这时你得到的不是“多个工具调用”，而是一个具有协同结构的执行系统。
3）一句话区分
如果你只记一句：
- Subagent = 专职工，只对主代理负责
- Agent Team = 项目组，成员之间可以协作
这句区分，在很多场景下足够你做出 80% 的正确判断。
二、为什么很多团队会误用 Agent Teams
误用 Agent Teams 的根源，通常有两个。
原因一：把“任务大”误等同于“应该开 Team”
任务大，不代表适合多会话协作。
比如：
- 改一个核心模块，涉及同一组文件频繁来回修改
- 重构一个事务链路，前后步骤依赖很强
- 修一个需要边看边改的复杂 Bug
这类任务看起来大，但它们其实有一个共同点：
依赖密集，局部决策频繁，状态变化快。
这时候你把任务拆成多个 teammate，表面上是在并行，实际上是在制造：
- 文件冲突
- 状态不一致
- 假设版本不一致
- lead 汇总困难
结果常常是：3 个 Agent 一起忙，最后还不如 1 个 Agent 顺着做来得稳。
原因二：把“多视角”误等同于“多实现者”
有些场景你确实需要多个视角，但不一定需要多个会话都去改代码。
比如：
- 一个 Agent 做代码探索
- 一个 Agent 做风险评审
- 一个 Agent 做测试建议
这类工作很适合 subagents，因为你要的是“多专家输入”，不是“多人同时落地”。
如果此时上 Agent Team，成本就会迅速升高：
- 每个人都保留一套上下文
- lead 还要同步理解每个人的过程
- 任务列表、消息传递、状态维护全部增加
本来只是需要三份报告，最后却搭了一个项目管理系统。
三、真正的判断标准：先看“协作结构”，再看“任务规模”
很多文章喜欢教你按任务大小判断：小任务单 Agent，大任务多 Agent。
这套说法太粗。
更准确的判断顺序应该是：
第一问：多个 worker 之间是否需要直接沟通？
如果不需要，优先 subagents。
因为 subagents 的最大优势，就是：
- 轻
- 快
- 成本低
- 结果直接回主代理
- 不引入额外协调层
典型场景：
- “去帮我找这个报错可能涉及哪些模块”
- “分别分析接口性能、事务边界、缓存一致性风险”
- “帮我从测试、架构、安全三个角度审视这份改动”
这些任务都不要求 worker 之间对齐中间状态，所以 subagent 完全够用。
第二问：任务是否可以拆成相对独立的工作面？
如果可以，Agent Teams 才有价值。
所谓相对独立，不是“理论上可以拆”，而是拆完之后每个成员能在一段时间内不互相阻塞。
例如：
- 前端 teammate 设计交互流
- 后端 teammate 定义 API 与领域逻辑
- 测试 teammate 同步设计回归策略
这三者之间存在关联，但在前期探索阶段可以并行推进。
这就是 Agent Teams 真正擅长的场景：先分头挖，再集中收敛。
第三问：你是否愿意为协作成本买单？
Agent Teams 的收益从来不是免费的。
你需要接受：
- 更多 token 消耗
- 更复杂的中间状态
- lead 需要承担整合压力
- teammate 间可能出现重复探索
- 某些时候 shutdown / 恢复 / 交接会不如单会话顺滑
如果这个任务的价值，不值得你支付这些成本，那就不要上 Team。
所以真正的判断不是“能不能并行”，而是：
这份并行收益，是否大于协作成本。
四、四类典型场景：该用谁，一眼判断
下面给你一个非常实用的分类框架。
场景 A：大范围探索，但最终只需要主代理做决策
比如：
- 理解一个陌生仓库
- 分析某个功能链路涉及的目录、服务、配置
- 让不同 agent 从安全、性能、可维护性角度做评审
建议：Subagents
原因很简单：
- worker 之间不需要互相说话
- 主代理天然就是汇总中心
- 你要的是并行取样，不是团队协作
这个场景下如果开 Agent Team，大概率只是把原本简单的调研工作复杂化。
场景 B：并行验证多个竞争性假设
比如线上出现一个诡异问题：
- Agent 1 去验证是不是缓存击穿
- Agent 2 去验证是不是事务失效
- Agent 3 去验证是不是异步补偿链路有重复消费
这个场景表面看 subagent 也能做，但如果你希望这些 worker 共享发现、彼此修正假设，那么 Agent Team 就开始有意义了。
建议：
- 只需要独立调研结论 → Subagents
- 需要 agent 间互相 challenge、不断收敛同一问题 → Agent Teams
这也是 Agent Teams 最有实战价值的场景之一：竞争性假设并行调试。
场景 C：跨层改造，工作面可以明确切开
比如你要做一个完整功能：
- 一个 teammate 负责接口契约与数据结构
- 一个 teammate 负责业务逻辑与领域实现
- 一个 teammate 负责测试与回归策略
- lead 负责统一验收标准
如果改动边界清楚、接口先行，Agent Team 很适合。
因为这里最大的收益不是“更多人写代码”，而是：
不同工作面可以在统一目标下并行推进。
但前提是两条：
- 切分边界要清楚
- 不要让多个 teammate 同时编辑同一组核心文件
如果这两条做不到，Agent Team 的收益会急剧下降。
场景 D：高依赖、强顺序、频繁回退的复杂重构
这是最容易误判的场景。
一个认证模块重构、一个结算链路重构、一个历史包袱很重的核心模块升级，看起来很适合“多人同时干”，实际上经常非常不适合。
因为这种任务的本质不是工作量大，而是决策链特别长：
- 改一步，要观察影响
- 观察完，再决定下一步
- 下一步又可能推翻前一步
这类任务最需要的是连续、稳定、单线程的上下文积累。
建议：单会话 + 必要时配 subagents 做只读辅助
不要为了“看起来先进”硬上 Team。
五、一个很关键但常被忽略的维度：上下文污染 vs 协调开销
为什么 subagents 在很多场景里这么有价值？
因为它帮你解决的是一个很真实的问题：
主会话上下文很宝贵。
当你让主代理自己去搜索代码、读几十个文件、做大量探索时，主上下文很容易被“探索噪音”塞满。后面真正进入实现阶段时，重要信息反而被稀释了。
Subagent 的价值就在这里：
- 把探索过程隔离出去
- 只把结果摘要回传
- 主代理保留更干净的决策上下文
这是一种典型的“降噪”收益。
但 Agent Teams 解决的就不是上下文污染，而是协同产能。
它允许多个上下文同时展开，并通过任务列表和消息互通形成协作结构。
所以两者的成本收益模型完全不同：
Subagents 主要解决
- 主上下文过载
- 局部任务需要专门角色
- 需要限制工具权限
- 需要把探索与实现隔离
Agent Teams 主要解决
- 工作面可并行拆分
- 多个 agent 需要互相交流
- 需要共享任务列表和协调机制
- 需要 lead 以项目组方式统筹执行
你一旦按这个模型去看，就不会再陷入“反正都是多 Agent，哪个好像都一样”的误区。
六、落地建议：团队真要用，怎么避免翻车
下面是我认为最值得落地的几条实践建议。
建议 1：默认从 Subagent 开始，而不是默认开 Team
这是最重要的一条。
工程里很多问题，不是“多 agent 不够多”，而是“协调结构设计过度”。
经验上我会这样判断：
- 能用一个主代理解决，就别拆
- 需要隔离探索或角色分工，就上 subagent
- 只有当 worker 之间必须直接协作时，才考虑 Agent Team
这是一条很朴素但极有效的复杂度控制原则。
建议 2：Agent Team 的拆分要按“工作面”而不是按“文件夹”
很多人拆任务喜欢说：
- 你负责
src/api - 你负责
src/service - 你负责
src/test
这看似清楚，其实很容易造成边界错配。因为真实协作的单位，通常不是目录，而是工作面。
更好的拆法是：
- 一个负责“接口契约与输入输出定义”
- 一个负责“业务规则与状态流转”
- 一个负责“测试、回归与反例构造”
这样拆的好处是：角色目标更清楚，也更容易判断谁应该跟谁同步。
建议 3：对同文件高冲突区域设禁区
如果你已经知道某几个文件是：
- 核心 orchestrator
- 主配置入口
- 数据结构定义中心
- 关键事务边界
那就尽量不要让多个 teammate 同时碰它们。
最稳的方式是：
- 各 teammate 在外围独立探索/准备
- 最后由 lead 或单独一个 teammate 负责合并到关键文件
多 Agent 最大的问题，从来不是“不会写”，而是同时写进同一个真相来源。
建议 4：把 Team 当成“研究组”比“编码组”更稳
从目前工程实践看，Agent Teams 最稳、最有价值的落地方式，往往不是多人同时改代码，而是多人同时研究：
- 一个做方案 A
- 一个做方案 B
- 一个做反例和风险扫描
- lead 最后选方案
这个模式的收益特别高，因为它把 Agent 的强项——快速探索、快速生成假设、快速整理证据——发挥到了最大。
反过来，多人同时落代码，则更依赖边界定义和冲突管理，难度高得多。
建议 5：让 lead 的职责更像 Tech Lead，而不是“转发器”
Agent Team 好不好用，最终很大程度上取决于 lead 怎么工作。
一个差的 lead 只是：
- 把任务分发出去
- 收结果
- 机械拼接
一个好的 lead 会做三件事：
- 定义统一验收标准：什么叫完成，什么叫不可接受
- 控制接口边界：谁输出给谁，谁依赖谁
- 主动做收敛：发现两个 teammate 路线冲突时及时拉齐
如果 lead 不做这三件事，Agent Team 很容易退化成“多人各写各的”。
七、给你一个最终判断模板
如果你在真实项目里犹豫该怎么选，可以直接套下面这套判断顺序：
先问 4 个问题
- 多个 worker 之间需要直接交流吗？
- 否：优先 Subagents
- 是：继续判断
- 任务能拆成相对独立的工作面吗？
- 否：不要上 Team
- 是：继续判断
- 并行收益是否明显大于协调成本？
- 否：不要上 Team
- 是：继续判断
- 是否存在大量同文件冲突风险？
- 是：谨慎，优先单会话/少量 subagent
- 否：可以考虑 Agent Team
一个经验法则
如果你发现自己需要用很多话去解释“这些 agent 之间到底怎么合作”，那通常说明：
这个 Team 设计已经开始过重了。
真正好的 Agent Team 方案，应该在任务边界上天然清楚，而不是靠持续补充说明来维持。
八、结语：多 Agent 的本质不是更多人，而是更好的组织结构
很多人追逐多 Agent，本质上是在追逐一种想象：
“如果一个 Agent 已经这么强，那三个一起上，不就更强了吗？”
现实没这么简单。
一个工程系统里，真正稀缺的从来不是“执行者数量”，而是：
- 边界是否清楚
- 信息是否对齐
- 决策是否可收敛
- 复杂度是否被控制住
所以别把 Agent Teams 当成“高级版并行”。它真正代表的，是从单代理执行，升级到带组织结构的协同执行。
而任何组织结构，都会带来额外成本。
这也是我对 Claude Code 这两类能力的最终建议：
- Subagents：优先作为默认武器，用来隔离探索、保住主上下文、做轻量专业分工
- Agent Teams：只在“确实需要多人协作结构”时启用，用来解决单会话难以高效推进的并行研究与跨面协作问题
如果你把这个边界想清楚，你就不会落入“为了多 Agent 而多 Agent”的陷阱。
真正成熟的团队，不是会开多少 Agent，而是知道：
什么时候该加人，什么时候该减复杂度。