现在 Agent 变得越来越强，可能有小伙伴就遇到这么一个问题：有些任务，已经很难让一个 Agent 从头处理到尾了。
以前我们常说“让一个 Agent 帮我完成任务”，听起来像是从输入到输出一条线走完。但在开发场景里，很多任务其实会被拆成一串步骤：读代码、查接口、写实现、补测试、看日志、做 Review。其实，上面的每一步都不难，麻烦的是这些信息会不断地堆进同一个上下文里。
上下文一多就容易乱，Agent 也就容易丢主线：前面确认过的需求，后面可能就忘了；日志里的问题还没处理完，测试结果又进来了；Review 意见一多，原本要改什么也开始变得模糊。
所以，多 Agent 系统里逐渐形成了两种常见协作方式：一种是 Subagent，另一种是 Agent Team。
它们都在解决“一个 Agent 不够用”的问题，但思路不太一样。
Subagent 是主 Agent 派出去的专项助手
你可以把 Subagent 理解成主 Agent 派出去的专项助手。主 Agent 负责整体目标和主线判断，Subagent 负责一个更明确的小任务。举个例子，你让 Agent 修改登录功能，它发现要先搞清楚几个问题：
认证逻辑在哪？
测试为什么会失败？
这次修改有没有安全风险？
会不会影响其他模块？
这时候，主 Agent 可以把任务拆出去：
Subagent A 去读认证相关代码；
Subagent B 去整理测试失败原因；
Subagent C 去做安全检查；
Subagent D 去 Review 改动影响；
每个 Subagent 都只关心自己的任务。完成任务后，它们把结论交回主 Agent，再由主 Agent 合并信息，继续做整体决策。
图注：Subagent 协作图。中间是主 Agent，向外派出多个 Subagent：查代码、跑测试、安全检查、代码 Review。每个 Subagent 最后只返回摘要。
Subagent 最大的价值，是让主 Agent 的上下文保持干净。
毕竟真实的开发环境中，中间过程会非常占空间。测试日志可能就有几千行，代码搜索可能会扫出几十个文件，依赖分析也可能带出很多无关内容。如果这些内容全部塞进主对话，主 Agent 很容易被干扰。这时候把这些开发过程交给 Subagent，主 Agent 只要拿到最终结果：
“相关文件主要是这三个。”
“测试失败集中在 session 过期逻辑。”
“这次改动可能影响权限校验。”
“建议补一个异常登录场景的测试。”
这样主线会清楚很多。
因此，Subagent 更像一种“任务委派”机制。主 Agent 不用亲自处理所有细节，只要把明确的小任务派出去，再等着收结果就好了。
Subagent 适合什么任务
像上面说到的那样，Subagent 其实是单独某个子任务的执行者。所以，它适合边界清楚、结果明确、可以独立完成的任务。像是：
查代码：找出某个功能对应的文件和调用链；
跑测试：整理失败用例和失败原因；
读文档：把某个模块的关键设计总结出来；
做 Review：检查代码是否有明显问题；
做检索：从资料里找出和问题相关的部分；
这些任务有一个共同点：不需要频繁讨论，只需要完成后返回结论。
但有些任务，光是拆出去还不够。
举个例子，我们现在要排查一个复杂 Bug。它可能是前端状态问题，也有可能是后端接口问题，还不能排除缓存和并发的嫌疑。如果只是派若干个 Subagent 分别去查，它们可能会各自给出一个看似合理的解释。但这些解释之间有没有冲突？哪个结果更有说服力？哪个假设值得优先验证？
这时候，就需要另一种协作方式：Agent Team。
Agent Team 让多个 Agent 像团队一样协作
正如其名，Agent Team 就是一个由多个 Agent 组成的小团队。
它和 Subagent 最大的区别在于：Subagent 更像是“主 Agent 派出去做一个明确任务”，而 Agent Team 更强调多个 Agent 围绕同一个目标协作：
Agent 1 负责规划；
Agent 2 负责实现；
Agent 3 负责测试；
Agent 4 负责质疑和 Review；
Agent 5 负责整理最终方案；
它们之间可以交换信息，也可以互相补充、互相纠错。这就更接近真实团队的工作方式。
图注：Agent Team 架构图。多个 Agent 围绕同一个任务协作：规划、开发、测试、Review、总结。过程中可以有共享任务板或共享上下文区域。
Agent Team 的价值，不只是“并行”，更重要的是多视角校验。
举个例子，我们在做代码 Review 的时候：安全 Agent 可能会说：“这里缺少权限校验。”；性能 Agent 可能会补充：“如果每次都查数据库，接口会变慢。”；测试 Agent 可能会继续说：“这里应该补一个缓存失效场景。”；维护性 Agent 可能会提醒：“这段逻辑最好抽成独立函数。”
这时候，多 Agent 就派上用场了。它不是把同一个任务重复做几遍，而是让不同分工的 Agent 互相补充视角。
Agent Team 适合什么任务
像上面提到的那样，擅长分工的 Agent Team 更适合复杂、开放、需要多轮判断的任务。像是：
复杂 Bug 排查：多个 Agent 从不同假设出发，同时验证问题原因；
跨模块开发：前端、后端、测试分别由不同 Agent 处理；
方案设计：一个 Agent 提方案，另一个 Agent 挑风险，再由一个 Agent 评估实现成本；
大型重构：把代码阅读、迁移实现、测试补充、风险检查拆给不同角色推进；
这些任务的共同点是：不是简单地操作下就能得到的结果。这些任务都要讨论方向、验证方案和同步信息。
Subagent 和 Agent Team 怎么选
这里用一个简单的标准判断，来看到底应该选哪个：如果任务边界清楚，做完后只需要返回结果，用 Subagent；反之，如果任务需要多个角色持续协作、互相验证，用 Agent Team。
更直白一点：Subagent 像专项助手；Agent Team 像小项目组：查代码、跑测试、整理日志、读文档、做单点 Review，更适合 Subagent；方案设计、复杂 Bug 排查、跨模块开发、大型重构，更适合 Agent Team。
业界的 Subagent 和 Agent Team 实践
如果把 Subagent 和 Agent Team 当成两种协作思路来看，我们已经能在很多工具和框架里看到类似设计了。
在 LangChain 的 multi-agent 文档里，Subagents 是这样一种模式：由一个 supervisor / 主 Agent 负责协调，把不同 Subagent 当成工具来调用，并决定什么时候调用它们、传入什么信息、如何合并返回结果。
Claude Code 中也有类似的分层设计。Claude Code 的 Subagents 会用来处理专项任务，比如代码搜索、测试整理、文档阅读、代码 Review；Agent Teams 则更接近团队协作，由主 Agent 负责协调，多个成员 Agent 共享任务列表、认领任务，并通过消息互相沟通。
OpenAI Codex 也有 Subagents 相关设计，可以为不同的开发方向启动专门的 agent，并行处理任务后再汇总执行结果。在 AI Coding 场景下，它很适合做安全、代码质量、Bug、竞态条件、测试稳定性这类专项检查。
单看多 Agent 框架的话，AutoGen 会更接近 Agent Team 这一类实践。它的 Group Chat 模式强调多个 Agent 共享同一条消息线索，不同 Agent 可以通过对话协作完成任务。
当然，不同产品和框架中 Subagent、Agent Team 的叫法不完全一样。这里更重要的不是名字，而是它们背后的协作方式：一类是把明确任务拆给子 Agent，另一类是让多个 Agent 以团队方式协作。
使用注意事项
虽然这篇文章一直在聊多 Agent，但实际使用时要注意：Agent 数量越多，系统不一定越稳。
Subagent 和 Agent Team 都能把任务拆开，但拆开之后，新的问题也会出现。
如果用 Subagent，常见风险是任务拆得太碎。每个 Subagent 都能给出一段结论，但这些结论可能比较零散，最后还是需要主 Agent 判断哪些信息有用、哪些信息冲突、哪些信息应该放回主线。
如果用 Agent Team，风险会更偏向协作本身：谁来分配任务？谁来判断优先级？谁来合并结果？不同 Agent 的结论互相冲突时，谁来做最终判断？如果多个 Agent 同时改到同一个模块，又怎么避免互相覆盖？
这些问题处理不好，多 Agent 很容易从“并行协作”变成“并行制造混乱”。
所以，多 Agent 系统真正重要的不是数量，而是任务边界、协作规则和结果合并方式。
小结
如果你刚开始理解多 Agent，可以先记住这句话：Subagent 解决的是“一个 Agent 忙不过来”的问题；Agent Team 解决的是“一个视角不够用”的问题。前者强调任务拆分，后者强调角色协作。
实际使用时，可以先从 Subagent 开始。遇到明确的小任务，就拆出去；当任务需要多个角色讨论、验证和协同推进，再考虑 Agent Team。
多 Agent 的价值，不在于让更多 Agent 同时说话。真正有价值的是：让合适的 Agent，在合适的位置，完成合适的任务。
