Subagents 还是 Agent Teams？先做对 Multi-Agent 的第一层判断Agent 工作流一旦跨过

Agent 工作流一旦跨过某个复杂度阈值，架构选择就会立刻出现。

该先用 subagents，还是已经该升级到 agent teams，或者要不要继续往更重的 multi-agent 形态走？

不用急着做出选择，可以先回归到核心问题，“这个任务到底需要什么样的协同方式？”，然后结合下两层进行判断：

1. 这个任务是否有必要从 single agent 升级到 multi-agent？
2. 如果真有必要使用 multi-agent，再去考虑是用 subagents 就能满足，还是已经到了必须使用 agent teams 的阶段？

我的判断是：对大多数场景，默认升级顺序应该是 single agent -> subagents -> agent teams。

这个顺序对应的，本质上是瓶颈类型的变化。前一阶段的主导瓶颈通常是上下文边界、支线分流和局部并行，subagents 已经能覆盖主要收益。等任务进入跨多轮推进，瓶颈会逐步转向局部记忆、稳定 ownership 和持续同步，agent teams 也就进入更合适的区间。

这也是本文的主线：先判断要不要进入 multi-agent，再判断更适合停在 subagents，还是升级到 agent teams。

single agent 和 multi-agent 的区别

单智能体与多智能体的区别

先把最上层的概念摆正。

single agent 和 multi-agent 的真正区别，不是“一个代理”还是“多个代理”这么简单，而是任务是否需要被拆进多个上下文窗口里协同推进。

• single agent：一个代理拿着同一个上下文窗口，从头到尾处理整条主线。它的优点是链路短、协调成本低、上下文不丢失，特别适合强耦合、需要连续推理的任务。
• multi-agent：多个代理在不同上下文窗口里工作，再通过父代理、协调层或共享机制汇总结果。它的优点是可以做 context isolation、并行探索和专业化分工，但代价是协调成本更高。

本质上：

• single agent 解决的是“一条主线怎么走完”
• multi-agent 解决的是“什么时候值得把主线拆开”

而 subagents 和 agent teams，都是属于 multi-agent 的不同模式。

什么情况下该考虑使用 multi-agent

大多数场景都应该先从 single agent 开始。只有当单代理已经开始碰到明确约束时，才值得考虑 multi-agent。

下面是被反复验证出的三类触发条件。

1. 上下文污染已经开始拖累效果

这是最常见的一类。

比如你在一个大型代码库里开发功能，主线任务是完成实现，但过程中总会冒出大量旁支探索：认证链路怎么走、现有邮件系统怎么发、shared util 被哪些模块复用、数据库 schema 和接口字段到底怎么对上。

这些探索本身有价值，但它们不应该长时间停留在主代理的上下文里。因为一旦这些旁支不断堆积，主代理的注意力就会被稀释，推理会变慢，结果也会开始发散。

2. 子任务天然可以并行

如果几个任务彼此独立，multi-agent 可以显著扩大搜索和处理覆盖面。

典型例子包括：

• 并行研究一个问题的多个侧面
• 同时检查多个服务或多个代码包
• 并行验证安全、性能、测试覆盖率

这里要特别强调一点：并行代理的价值通常是更全面，不是必然更快。多代理经常会增加总 token 消耗，甚至拉长总耗时，但它能换来更大的搜索空间和更完整的结果。

3. 专业化可以明显提升工具选择或任务聚焦

当一个代理要同时掌握太多工具、太多 system prompt 风格、太多领域知识时，稳定性会下降。

这时候，拆出几个职责清晰的专业代理，往往会比“一个全能代理硬扛所有任务”更稳。比如：

• security-reviewer 安全审查代理，只看安全风险
• perf-reviewer 性能审查代理，只看性能瓶颈
• schema-checker 结构校验代理，只验证输出是否符合 schema

什么时候还不该考虑 `multi-agent`

如果你的任务只是：

• 一个代理就能完整做完
• 子步骤之间高度依赖，必须持续共享同一大块上下文
• 为了分工而硬拆成规划代理 / 开发代理 / 测试代理 / 审查代理（planner / developer / tester / reviewer）

那就应该先克制住做重架构的冲动。

因为一旦进入多代理，成本会立刻变高。同类任务的多代理方案，常见会比单代理多消耗 3 到 10 倍 token。额外开销主要来自三件事：重复携带上下文、代理之间的协调消息，以及为了交接而做的结果摘要。

所以，第一层判断不是“能不能做成 multi-agent”，而是“这些新增成本，能不能被真实收益覆盖掉”。

先看全景：multi-agent 不只有两种模式

multi-agent 当然不只有 subagents 和 agent teams。

更完整的模式图里，至少还包括：

• 生成 - 验证者（Generator-verifier）：适合先生成、再按明确标准验证的任务
• subagents / orchestrator-subagent：适合一次性委派、上下文隔离和局部并行
• agent teams：适合长期协作、稳定 ownership 和局部记忆
• message bus：适合 event-driven workflow
• shared state：适合共享黑板式协作和研究型任务

先把这张全景图放在脑子里，后面再把镜头收回到最常见的第一个分叉。

但对大多数技术团队来说，真正最常遇到、也最容易选错的第一个分叉点，通常不是这五种模式一起选，而是：

• 这件事还停留在一次性委派
• 还是已经进入长期协作

也正因为如此，下面本文只重点展开 subagents 和 agent teams。它们之所以值得单独对比，不是因为比别的模式更高级，而是因为它们构成了大多数工程团队最常遇到的第一个架构分叉点。

subagents 与 agent teams 对比

真正让人选错架构的，通常不是不知道 multi-agent，而是不知道 subagents 和 agent teams 到底差在哪。

一句话说，subagents 是一次性委派机制，agent teams 是长期协作机制。

把它们放到同一张表里看，会更清楚：

这里最容易犯的错，是把两者都理解成“多几个代理一起干活”。

这句话当然没错，但它太粗了。真正决定架构的，不是代理数量，而是生命周期、记忆方式和协作结构。

先做选型

前面对比已经把边界讲清了，接下来先连续完成选型判断：什么时候该停在 subagents，什么时候才该升级到 agent teams。

也可以把这个判断再压缩成一句话：你遇到的到底是上下文问题，还是协作问题。

什么时候该选择 subagents

对大多数技术团队，subagents 应该是默认的第一层升级方案。

subagents 最适合下面四类场景。

1. 主代理开始被支线任务拖慢

你正在实现支付通知，但中途冒出四条支线：

• 认证逻辑在哪一层做
• 邮件入口点有哪些
• 设计系统里有没有现成组件
• 某个 shared util 到底被谁复用

这些问题都值得查，但不值得把它们永久留在主线程里。最好的做法是把它们分配给几个 subagents，让它们各自探索，最后只带着摘要回来。

2. 子任务彼此独立，可以并行

例如：

• 并行排查三个模块的 TypeScript 错误
• 同时梳理 API routes、数据库 schema 和前端数据流
• 并行做安全检查、性能检查和测试覆盖率复核

这种时候，subagents 的价值不是把系统做成一套长期协作架构，而是把一次性委派做得更干净。

3. 你需要一个不受历史对话影响的第二视角

很多工程问题不是没人做 review，而是做 review 的人已经被自己的实现过程说服了。

这时候，一个只读的 subagent 很有价值。它不知道前面的争论和假设，更像一个真正独立的 reviewer。

它特别适合做：

• 提交前安全审查
• 边界条件检查
• 测试覆盖率复核
• 独立验证当前实现有没有对样例过拟合

4. 你需要轻度专业化，但不需要长期协作

如果某类任务需要特定 prompt、受限工具或固定视角，subagents 很适合承接。

例如：

• security-reviewer 安全审查员
• perf-reviewer 性能审查代理
• schema-checker 结构校验代理

如果几个步骤强依赖同一套上下文，而且每一步都需要拿着上一轮的完整推理继续往下走，subagents 反而会带来额外摩擦。尤其是把一个本来共享上下文的任务，机械拆成 planner / developer / tester 这样的角色链条，几乎一定会引入传话损耗。

什么时候该选择 `agent teams`

agent teams 解决的已经不是“把支线任务切出去”，而是“让一组长期在线的代理持续协作”。

agent teams 最适合下面三类场景。

1. 子任务会跨多轮推进，而且需要保留局部记忆

这是 agent teams 和 subagents 最核心的分界线。

如果一个代理今天研究完服务 A，明天还要继续接着做，并且它已经慢慢摸清了这个服务的依赖关系、测试习惯、部署约束，那这份积累就是局部记忆。subagents 做完即走，给不了这种记忆连续性；agent teams 则正好相反，它的价值就在这里。

典型场景包括：

• 大规模代码库迁移
• 长周期重构
• 多服务并行改造
• 长时间运行的研究任务

2. 每个成员都有稳定负责的一块，而不是临时被拉来做一段任务

如果你的任务天然可以按服务、模块、研究方向或工作流阶段，切成几条长期负责的线，那么把这些线交给稳定成员，会比每次都重新拉起一批 subagents 更顺。

例如，在一次代码库迁移里：

• 一个成员长期负责认证相关服务
• 一个成员长期负责支付链路
• 一个成员长期负责测试与回归
• 一个协调者负责汇总进度和依赖

这里的重点已经不是一次性拆任务，而是让每个成员持续积累自己那一块的上下文。

3. 协作已经从“结果汇总”变成“持续同步”

当多个成员不再只是最后交差，而是需要在任务推进过程中反复同步状态、更新计划、处理依赖，agent teams 会比 subagents 更自然。

因为 subagents 的默认通信模型是“做完再回父代理”，而 agent teams 允许团队在更长时间尺度上管理成员关系、进度和分工。

如果你的任务还是一次性委派、做完就走、结果可以被压成摘要，那通常还没到 agent teams 的阶段。

怎么落地

选型完成之后，再进入第二步：怎么把选中的模式落下来。

怎么使用 `subagents`

如果你在 Claude Code 这类环境里使用 subagents，一个比较稳的做法是下面五步。

1. 按上下文边界拆，不按角色拆

不要一上来就拆成 planner / developer / tester。

正确的问题是：哪些任务可以在不共享核心上下文的情况下独立完成？只有这些任务，才适合委派给 subagents。

2. 任务边界、返回格式、并行要求要写清楚

subagents 最怕边界模糊。

比起“帮我研究一下这个系统”，更好的写法是：

请用 `subagents` 并行探索这个代码库：

1. 梳理认证链路
2. 找出所有邮件发送入口
3. 检查支付异常处理逻辑

每项任务只返回简短摘要和相关文件路径，不要直接粘贴原始文件内容。

这里有三个关键点：任务独立、明确并行、只回摘要。

3. 工具和权限尽量收紧

研究型 subagent 给只读权限，实现型 subagent 才给写权限。

工具越聚焦，输出越稳定，也越容易判断它到底有没有完成任务。

4. 把验证工作单独做成 `reviewer` 或 `verifier`

很多团队会让主代理自己实现、自己审查、自己打分。更稳的做法是把验证工作独立出来，交给一个新的 subagent。

它可以专门做：

• 跑测试
• 检查 schema
• 检查安全问题
• 按验收标准做 review

5. 先从对话式委派开始，再沉淀成自定义 `subagents`

先在对话里直接调用，跑顺了，再沉淀成自定义 subagent、项目级规则或 CLAUDE.md 约束。

这个顺序更稳，因为你先验证了模式，再去固化，而不是一开始就把半成熟流程写死。

怎么使用 `agent teams`

如果你已经确认任务进入长期协作阶段，agent teams 的落地重点就不再是 prompt，而是协作设计。

一个够用的做法是下面五步。

1. 先证明 `subagents` 已经不够

只有当下面这些现象已经出现，才值得升级：

• 同一条工作线要跨多轮持续推进
• 成员需要保留自己的局部记忆
• 每次重新拉起 subagent 都要重复灌大量背景
• 协作问题已经比上下文问题更突出

2. 按负责范围和上下文来组队

不要按组织岗位来拆团队。

更稳的做法是按服务、模块、研究方向、系统边界来拆，让每个成员长期负责自己那一块。这样，它积累下来的上下文才真的有复利。

3. 给每个成员稳定的职责、输入和交付物

一个 agent team 不是“大家都很聪明，所以会自动协作”。

你需要明确：

• 谁负责哪条工作线
• 谁可以改什么
• 什么信息必须同步
• 每轮同步输出什么摘要

没有这些护栏，团队很快就会变成一堆互相打断的代理。

4. 设计好协调层，而不是只设计成员

agent teams 通常需要一个协调层，负责：

• 分发任务
• 跟踪进度
• 处理依赖关系
• 决定什么时候汇总

这不一定意味着一个绝对中心化的“总指挥”，但你至少要有一套稳定的协调协议。

5. 一开始就补齐可观测性和停止条件

长期协作系统最怕两件事：失控和无限继续。

所以要尽早补上：

• 日志和回放
• 轮次限制
• 终止条件
• 失败重试规则
• 冲突处理规则

如果这些东西缺位，agent teams 往往不是死在能力不够，而是死在协作无法管理。

一个够用的升级顺序

对大多数团队，我更建议按下面这个顺序升级：

这个顺序背后的逻辑很简单：先解决上下文问题，再解决协作问题；先上轻模式，再上重模式。

很多团队的问题不是“架构不够先进”，而是“太早把简单问题复杂化了”。

收尾一下

不用急着选择 “要不要上 subagents 或 agent teams”。

可以先回归到下面两点来进行判断：

一次性委派，先用 subagents。

需要长期协作，再上 agent teams。

如果连 agent teams 都开始扛不住，再去考虑 消息总线 (Message bus) 或 共享状态 (Shared-state) 这类更重的模式。

围绕上下文边界来设计，而不是围绕角色来设计。先从简单方案开始，只有在确实必要时再增加复杂度。

参考资料

• How and when to use subagents in Claude Codehttps://claude.com/blog/subagents-in-claude-code
• Building multi-agent systems: When and how to use themhttps://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them
• Multi-agent coordination patterns: Five approaches and when to use themhttps://claude.com/blog/multi-agent-coordination-patterns

AI趣实验出品（全平台同名）

Subagents 还是 Agent Teams？先做对 Multi-Agent 的第一层判断