多 Agent 系统中的 Subagent 与 Agent Team 协作模式

AI Agent 能处理的任务越来越复杂，但复杂任务并不一定适合交给一个 Agent 从头做到尾。尤其在软件开发场景里，一个需求往往会拆成很多环节：读代码、查调用链、理解接口、实现逻辑、补测试、跑用例、分析日志、做代码 Review。每个环节单独看都不算特别难，真正麻烦的是信息会不断堆进同一个上下文。

上下文太长以后，Agent 容易遇到几个问题：

• 前面确认过的需求，后面可能被弱化或遗忘；
• 日志、测试结果、代码片段混在一起，主线变得不清楚；
• Review 意见变多以后，Agent 难以判断哪些问题最重要；
• 多个假设同时存在时，Agent 可能过早选定一个方向。

多 Agent 系统的核心目标，就是把任务拆开，让不同 Agent 承担不同职责。常见的协作方式主要有两类：Subagent 和 Agent Team。它们都在解决“一个 Agent 不够用”的问题，但解决方式不一样。

Subagent 更像专项助手，适合处理边界清楚的小任务；Agent Team 更像一个小型项目组，适合处理需要多角色协作、互相验证的复杂任务。

Subagent：主 Agent 派出的专项助手

Subagent 是由主 Agent 调度的子 Agent。主 Agent 负责理解整体目标、拆分任务和合并结论，Subagent 只处理某个具体问题。

假设要修改一个登录功能，主 Agent 可能先发现几个需要澄清的问题：

• 认证逻辑在哪些文件里？
• 当前失败测试的原因是什么？
• 修改会不会影响权限校验？
• 有没有新增安全风险？
• 是否需要补充异常登录场景的测试？

这些问题可以拆给不同 Subagent 处理：

flowchart TD
    Main[主 Agent：负责目标、拆分和决策]

    Main --> A[Subagent A：查认证代码]
    Main --> B[Subagent B：分析测试失败]
    Main --> C[Subagent C：检查安全风险]
    Main --> D[Subagent D：评估改动影响]

    A --> R[返回摘要]
    B --> R
    C --> R
    D --> R

    R --> Main

这种结构里，Subagent 不需要知道完整项目背景，也不需要参与最终决策。它只要把自己的任务完成，并把结论压缩成主 Agent 能使用的信息即可。

例如，几个 Subagent 返回的结果可能是：

• “登录相关逻辑集中在 auth/session.ts、auth/service.ts 和 middleware/auth.ts。”
• “失败用例主要和 session 过期时间判断有关。”
• “当前修改会影响管理员权限校验，需要补一个回归测试。”
• “异常登录场景缺少覆盖，建议补充 token 失效后的接口行为测试。”

主 Agent 拿到这些摘要后，再决定如何修改代码、是否补测试、是否需要进一步验证。

Subagent 的核心价值：隔离过程，保留结论

开发任务的中间过程通常非常占上下文空间。一次代码搜索可能命中几十个文件，一段测试日志可能有几千行，依赖分析也可能带出很多无关信息。如果这些内容全部进入主 Agent 的上下文，主 Agent 就容易被细节干扰。

Subagent 的作用，是把“搜索、阅读、运行、整理”这些过程放到子上下文中完成，最后只把有用结论交回主上下文。

flowchart LR
    Task[开发任务] --> Main[主 Agent]
    Main --> Sub[Subagent 执行细节任务]
    Sub --> Noise[大量中间信息：日志、搜索结果、临时代码片段]
    Sub --> Summary[压缩后的结论]
    Summary --> Main
    Main --> Decision[继续决策和实现]

这种模式能让主 Agent 的上下文更干净。主 Agent 关注的是目标、约束、关键事实和下一步动作，而不是被所有中间材料淹没。

Subagent 适合处理哪些任务

Subagent 适合边界清楚、输入明确、输出可以被压缩成结论的任务。它不适合长时间讨论，也不适合频繁调整目标。

这些任务有一个共同点：不需要多个 Agent 反复协商，只需要独立执行并返回结果。

不过，Subagent 不是万能的。如果要排查一个复杂 Bug，问题可能来自前端状态、后端接口、缓存失效、并发时序或环境配置。多个 Subagent 各查一个方向，可能会得到几个看起来都合理的解释，但这些解释之间是否冲突、哪个假设更值得验证、下一步该先排查哪里，仍然需要更强的协作机制。

这时就需要 Agent Team。

Agent Team：多个 Agent 像团队一样协作

Agent Team 是由多个 Agent 组成的协作小组。它和 Subagent 的区别，不只是 Agent 数量更多，而是协作关系不同。

Subagent 通常是“主 Agent 派任务，子 Agent 返回结果”；Agent Team 则是多个角色围绕同一个目标持续交流、同步信息、互相质疑和修正方案。

一个典型的 Agent Team 可以这样分工：

flowchart TD
    Goal[共同目标：完成复杂开发任务]

    Planner[规划 Agent：拆目标和排优先级]
    Developer[开发 Agent：实现代码]
    Tester[测试 Agent：补测试并跑用例]
    Reviewer[Review Agent：检查风险和质量]
    Summarizer[总结 Agent：合并结论和输出方案]

    Goal --> Planner
    Planner --> Developer
    Planner --> Tester
    Developer --> Reviewer
    Tester --> Reviewer
    Reviewer --> Developer
    Reviewer --> Summarizer
    Tester --> Summarizer
    Developer --> Summarizer

这里的 Agent 不只是各做各的，它们会围绕同一个目标持续同步。例如开发 Agent 完成实现后，测试 Agent 可以根据改动补充用例；Review Agent 发现权限校验缺失后，开发 Agent 需要回到代码里修正；总结 Agent 则把最终决策、改动范围和验证结果整理出来。

Agent Team 的重点不是并行，而是多视角校验。

做代码 Review 时，不同角色可能关注不同问题：

这些视角互相补充，能减少单个 Agent 因关注范围有限而漏掉问题的概率。

Agent Team 适合处理哪些任务

Agent Team 更适合复杂、开放、需要多轮判断的任务。它处理的不是“查一下就有答案”的问题，而是需要不断提出假设、验证假设、调整方向的问题。

以复杂 Bug 排查为例，Agent Team 的协作流程可以设计成这样：

sequenceDiagram
    participant P as 规划 Agent
    participant F as 前端 Agent
    participant B as 后端 Agent
    participant C as 缓存 Agent
    participant T as 测试 Agent
    participant R as Review Agent

    P->>F: 检查状态更新和请求参数
    P->>B: 检查接口逻辑和数据库查询
    P->>C: 检查缓存键和失效策略
    F-->>P: 返回前端假设
    B-->>P: 返回后端假设
    C-->>P: 返回缓存假设
    P->>T: 设计验证用例
    T-->>P: 返回复现结果
    P->>R: 汇总证据并请求风险检查
    R-->>P: 给出最终判断和修复建议

这种任务如果只用 Subagent，可能会得到一堆分散结论；使用 Agent Team，重点会变成“如何让不同结论互相验证，并收敛到一个可执行方案”。

Subagent 和 Agent Team 的选择标准

选 Subagent 还是 Agent Team，可以看两个问题：

1. 任务边界是否清楚？
2. 是否需要多个角色持续协作和互相验证？

如果任务边界清楚，执行完只要返回一个结论，用 Subagent 更合适。如果任务本身开放，需要多个角色讨论方向、检查风险、反复修正，用 Agent Team 更合适。

更简单的判断方式是：Subagent 解决“任务太多，一个 Agent 忙不过来”的问题；Agent Team 解决“视角太少，一个 Agent 判断不充分”的问题。

常见工具中的对应设计

不同框架和产品对这些模式的命名不完全一样，但底层思路大致可以对应起来。

在 LangChain 这类框架里，常见结构是 supervisor 负责路由和合并结果。它决定什么时候调用哪个子 Agent、传入什么上下文、如何处理返回结果。

flowchart LR
    User[用户任务] --> Supervisor[Supervisor / 主 Agent]
    Supervisor --> CodeAgent[代码 Agent]
    Supervisor --> TestAgent[测试 Agent]
    Supervisor --> DocAgent[文档 Agent]
    Supervisor --> ReviewAgent[Review Agent]

    CodeAgent --> Supervisor
    TestAgent --> Supervisor
    DocAgent --> Supervisor
    ReviewAgent --> Supervisor

    Supervisor --> Answer[最终结果]

AutoGen 的 Group Chat 更接近团队协作。多个 Agent 共享同一条消息线索，每个 Agent 根据自己的角色发言、执行动作或提出质疑，最终由某个角色收敛结果。

使用多 Agent 时要注意什么

Agent 数量变多，不代表系统一定更稳定。多 Agent 能拆任务，也会引入新的协调成本。

使用 Subagent 时，最常见的问题是任务拆得太碎。每个 Subagent 都能返回一段结论，但主 Agent 仍然要判断哪些结论有用、哪些结论冲突、哪些信息需要进入主线。如果缺少明确的返回格式，主 Agent 可能拿到大量风格不一致、粒度不一致的摘要。

使用 Agent Team 时，主要风险来自协作本身：

• 谁来分配任务？
• 谁来判断优先级？
• 谁来合并结果？
• 多个 Agent 结论冲突时，谁做最终判断？
• 多个 Agent 同时修改同一块代码时，如何避免互相覆盖？
• 共享上下文里哪些信息必须保留，哪些信息应该丢弃？

设计多 Agent 系统时，关键不是把 Agent 数量堆上去，而是提前定义任务边界、通信规则和结果合并方式。

一个可执行的多 Agent 设计通常需要明确这几件事：

实践中的推荐用法

刚开始构建多 Agent 流程时，可以先从 Subagent 入手。它的结构更简单，收益也比较直接：把搜索、日志分析、测试整理、文档阅读这类消耗上下文的任务移出去，让主 Agent 保持清晰。

当任务开始出现这些信号时，再考虑 Agent Team：

• 需要多个专业视角共同判断；
• 一个结论必须被另一个角色验证；
• 任务会跨多个模块或多个代码仓库；
• 需要持续同步状态，而不是一次性返回结果；
• 风险较高，需要规划、实现、测试和 Review 分开执行。

多 Agent 的价值不在于让更多 Agent 同时工作，而在于让合适的 Agent 处理合适的任务。边界清楚的小任务交给 Subagent，开放复杂的目标交给 Agent Team，主 Agent 或协调角色再负责收敛信息和控制方向。这样设计出来的系统，才不会从“并行协作”变成“并行制造混乱”。