Subagent：让多个 AI 角色协作

1. Subagent 是什么#

Subagent 可以理解成由主 Agent 调度的专职 AI 角色。

典型结构：

1
用户目标
2
  ↓
3
主 Agent 拆分任务
4
  ↓
5
Subagent A：需求分析
6
Subagent B：代码阅读
7
Subagent C：测试设计
8
Subagent D：安全审查
9
  ↓
10
主 Agent 汇总结果
11
  ↓
12
输出最终结论

每个 Subagent 只负责一部分任务，例如：

• 需求分析
• 代码阅读
• 实现方案
• 测试设计
• 安全审查
• 文档整理
• 发布检查

主 Agent 负责拆任务、分发上下文、收集结果、解决冲突和输出最终答案。

2. 为什么需要 Subagent#

复杂任务常常包含多个专业视角。

示例：实现一个支付功能，需要关注：

• 产品需求是否清楚
• 接口设计是否合理
• 数据库事务是否安全
• 支付回调是否幂等
• 前端交互是否完整
• 测试场景是否覆盖
• 安全风险是否可控
• 发布和回滚是否准备好

如果一个 Agent 同时处理所有内容，容易出现：

• 上下文过长
• 重点分散
• 某些风险被遗漏
• 输出结构混乱
• 反复切换角色
• 结果难以审查

Subagent 能带来几个收益：

• 分工更清楚
• 专注度更高
• 并行执行更方便
• 上下文可以隔离
• 结果可以互相审查
• 主 Agent 更容易做最终判断

Subagent 适合复杂、多角色、多视角的任务。

3. 主 Agent 调度#

主 Agent 是协调者。

它负责：

• 理解用户目标
• 判断需要哪些 Subagent
• 拆分任务
• 为每个 Subagent 准备上下文
• 定义输出格式
• 收集结果
• 检查结果质量
• 处理冲突
• 输出最终结论

示例：

1
用户目标：请 review 这次支付功能改动。
2

3
主 Agent 拆分：
4
1. 代码阅读 Subagent：理解改动范围和核心逻辑。
5
2. 安全审查 Subagent：检查权限、幂等、签名和敏感信息。
6
3. 测试 Subagent：检查测试覆盖和缺口。
7
4. 文档 Subagent：检查接口文档是否需要更新。

主 Agent 不能只收集文本，还要判断每个结果是否可用。

4. 子 Agent 分工#

Subagent 分工要清楚。

常见角色包括：

• 需求分析 Subagent
• 代码阅读 Subagent
• 实现 Subagent
• 测试 Subagent
• 安全审查 Subagent
• 文档 Subagent
• 发布检查 Subagent

1
业务目标：
2
用户流程：
3
功能点：
4
异常场景：
5
待确认问题：

1
入口文件：
2
关键函数：
3
调用链：
4
影响范围：
5
风险点：

1
已有覆盖：
2
缺失测试：
3
高风险场景：
4
回归范围：

1
安全风险：
2
影响：
3
证据：
4
修复建议：

5. 上下文隔离#

上下文隔离是 Subagent 的关键能力。

每个 Subagent 只应该拿到完成任务所需的信息。

这样做有几个好处：

• 降低上下文长度
• 减少无关干扰
• 保护敏感信息
• 提高专注度
• 降低结果混乱概率

示例：

1
测试 Subagent 需要：
2
- 需求说明
3
- 接口定义
4
- 已有测试文件
5
- 改动 diff
6

7
它不一定需要：
8
- 生产密钥
9
- 部署机器信息
10
- 用户隐私数据

主 Agent 要负责筛选上下文，避免把所有材料无差别塞给每个 Subagent。

6. 结果汇总#

Subagent 完成任务后，主 Agent 需要汇总结果。

汇总时要做几件事：

• 去重
• 合并相同问题
• 按严重程度排序
• 标注来源角色
• 检查证据是否充分
• 区分事实、推断和建议
• 输出统一格式

示例：

1
最终 Findings：
2
1. [P1] 支付回调缺少幂等校验
3
   来源：安全审查 Subagent、代码阅读 Subagent
4
   证据：callbackHandler 中直接更新订单状态，未检查 transactionId 是否已处理
5
   影响：重复回调可能导致重复发货
6
   建议：增加 transactionId 唯一约束和幂等检查

主 Agent 的价值，体现在最终判断和整合质量上。

7. 互相审查#

Subagent 之间可以互相审查结果。

常见方式：

• 测试 Subagent 检查实现方案是否可测试
• 安全 Subagent 审查代码阅读结果中的风险
• 文档 Subagent 检查需求分析是否缺字段
• Review Subagent 检查实现 Subagent 的代码改动

示例流程：

1
实现 Subagent 给出方案
2
  ↓
3
测试 Subagent 设计验证场景
4
  ↓
5
安全 Subagent 检查高风险点
6
  ↓
7
主 Agent 汇总并决定是否可执行

互相审查能降低单个角色遗漏风险。

8. 并行执行#

Subagent 可以并行执行。

适合并行的任务：

• 多个方案调研
• 多个模块代码阅读
• 多个角色审查同一 diff
• 多个数据源检索
• 文档、测试、安全分头检查

并行执行要注意：

• 输入上下文要提前准备
• 输出格式要统一
• 结果要能合并
• 冲突要能处理
• 成本和并发要受控

示例：

1
主 Agent 同时派发：
2
1. Subagent A 调研方案一。
3
2. Subagent B 调研方案二。
4
3. Subagent C 调研方案三。
5

6
最后主 Agent 对比成本、风险、实现复杂度和维护性。

并行能提升效率，但更需要结果汇总能力。

9. 角色边界#

角色边界用于防止 Subagent 越权。

示例：

1
测试 Subagent：
2
职责：设计测试点、检查测试覆盖。
3
边界：不修改业务代码，不执行部署，不做最终上线判断。
4

5
安全 Subagent：
6
职责：检查安全风险。
7
边界：不直接修改生产配置，不读取无关敏感数据。

边界清楚后，主 Agent 更容易控制流程。

建议为每个 Subagent 定义：

• 职责
• 输入
• 输出
• 可用工具
• 禁止动作
• 完成条件

10. 冲突处理#

多个 Subagent 可能给出不同结论。

常见冲突：

• 一个认为风险高，另一个认为风险低
• 一个建议修改代码，另一个建议只补测试
• 一个认为资料不足，另一个给出明确结论
• 不同 Subagent 引用不同来源

冲突处理方法：

• 要求提供证据
• 回到源码或资料验证
• 标注不确定项
• 让第三个审查角色复核
• 请求人工决策
• 在最终结果中说明差异

示例：

1
冲突点：
2
安全 Subagent 认为支付回调缺少签名校验。
3
代码阅读 Subagent 认为网关层已经校验。
4

5
处理：
6
需要读取网关中间件配置确认签名校验是否覆盖该路径。

冲突不可怕，关键是不能把冲突混成确定结论。

11. Subagent 实战练习#

可以按下面顺序练习：

1. 一个 Subagent 读代码，一个 Subagent 写测试，一个 Subagent 做 review
2. 多个 Subagent 分别调研不同技术方案
3. 主 Agent 拆任务、收结果、做最终判断
4. 用 Subagent 完成一次完整功能开发流程
5. 让安全 Subagent 审查高风险改动
6. 让测试 Subagent 检查测试覆盖
7. 让文档 Subagent 检查文档缺口
8. 给每个 Subagent 定义输出模板
9. 给 Subagent 结果增加互审流程
10. 设计 Subagent 协作 Eval

每个练习都可以检查三个问题：

• 分工是否清楚
• 上下文是否足够且不过量
• 主 Agent 是否能做出高质量汇总

12. 阶段验收标准#

学完这一章，可以用下面的问题检查自己：

• 我能不能判断什么时候需要 Subagent？
• 我能不能设计主 Agent 的调度职责？
• 我能不能为每个 Subagent 定义清楚分工？
• 我能不能控制每个 Subagent 的上下文范围？
• 我能不能统一 Subagent 输出格式？
• 我能不能合并多个 Subagent 的结果？
• 我能不能让 Subagent 互相审查？
• 我能不能并行执行多个 Subagent？
• 我能不能处理 Subagent 结论冲突？
• 我能不能评估 Subagent 协作效果？

如果这些问题大多数都能做到，说明 Subagent 阶段已经基本合格。

13. 本章总结#

Subagent 的核心是用多个专职 AI 角色协作完成复杂任务。

一套可用的 Subagent 体系，建议至少包含：

• 主 Agent 调度
• 子 Agent 分工
• 上下文隔离
• 结果汇总
• 互相审查
• 并行执行
• 角色边界
• 冲突处理
• 统一输出格式
• 协作 Eval

Subagent 让 AI 从单角色执行走向多角色协作。它适合复杂研发、测试设计、代码审查、安全评估、方案调研和发布检查。

这一章的目标很明确：让多个 AI 角色各自专注、互相补位，再由主 Agent 汇总成可靠结论。