Subagent 的意义是隔离性
Subagent 的价值不是“多找几个 agent 干活”，而是隔离。
- 并行、分工、提速都是隔离带来的二级收益；如果任务不可隔离，即使并行启动多个 agent，也容易制造冲突、重复和整合成本。
- Planner 拆 subagent 的核心问题不是“能不能拆”，而是“拆出去之后，是否形成了更干净的上下文、更清楚的局部目标、更安全的权限边界、更合适的模型选择和更可验证的输出”。
- 因此，subagent 不是组织管理上的“岗位分工”类比，而是 agent harness 里的边界设计。
- 在真实 AI 应用里，subagent 还承担模型路由的作用：把探索、长思考、审美判断、代码修复、QA 验收等不同需求，交给最适合的模型和运行策略。
Subagent有五种隔离
无论隔离的是上下文、目标函数、权限、责任，还是为局部任务选择模型，底层逻辑都是一样的：把一个可能污染主循环的局部过程，封装成可输入、可执行、可验证、可回收的单元。
一个 subagent 隔离单元通常包括：
- 独立 context：它可以读取大量局部材料，但只把压缩结论带回主 agent。
- 独立 instruction：它有自己的局部目标和判断标准，不必共享主 agent 的全部推理轨道。
- 独立 tool boundary：它只能使用完成局部任务所需的工具和权限。
- 独立 model / runtime profile：它可以绑定更适合当前局部任务的模型、推理深度、并发策略和成本预算。
- 独立 output contract：它必须交回结构化 artifact，例如文件列表、风险清单、测试报告、失败复现步骤。
各方向的不同点在于“隔离对象”不同：
| 隔离方向 | 隔离的对象 | 主要解决的问题 | 常见 subagent |
|---|---|---|---|
| 上下文隔离 | 信息量和噪音 | 主上下文被搜索、日志、调研结果撑爆 | explorer、scout、log analyst |
| 目标函数隔离 | 局部优化目标 | 实现者自评过度乐观，或不同立场互相干扰 | evaluator、reviewer、security reviewer |
| 权限隔离 | 工具和操作边界 | 高风险动作、敏感数据、写权限不应被所有 agent 共享 | read-only checker、DB reader、browser evaluator |
| 责任隔离 | 决策归属 | subagent 不应替 planner 做最终产品取舍 | implementer、test writer、risk analyst |
| 模型匹配 | 模型能力、速度、成本和风格 | 不同局部任务需要不同模型特长 | fast explorer、deep reasoner、aesthetic reviewer |
一、上下文隔离：把高噪音过程放进独立 Context
上下文隔离解决的是“信息太多、太吵、太局部”的问题。主 agent 真正需要的是结论和证据，不需要吃下所有原始材料。
适合上下文隔离的信号：
- 需要搜索很多文件，例如找出所有调用点、权限校验点、数据流入口。
- 需要读长日志、CI 输出、trace、benchmark 结果。
- 需要比较多种方案、调研外部文档或 GitHub issue。
- 需要跨模块理解，例如前端、API、数据库、权限、异步任务同时相关。
- 需要跑测试并解释失败，尤其测试输出可能反复很长。
- 需要生成中间地图，例如调用链、依赖图、风险面、API surface。
- 用户请求中出现“所有”“全部”“全局”“影响范围”“梳理”“排查”“调研”“审计”等词。
Context Probe
Context Probe是正式执行前的低成本探测动作，用来判断当前任务需要读取多少上下文、涉及哪些模块、信息噪音有多大，以及是否值得拆 subagent。- 它不是让 agent 开始解决问题，而是先回答“这个问题有多大、从哪里入手、需要哪些上下文”。
- 对刚入门的读者，可以把它理解为工程里的“先探路”：不急着修路或开车，而是先看地图范围、路口数量、可能堵点和风险区域。
- 常见探测方式包括：
rg看命中数量、find/ls看目录规模、查看测试日志大小、看相关模块数量、检查是否跨服务 / 跨语言 / 跨层。 - 如果命中 3 个文件，主 agent 自己读通常更快。
- 如果命中几十个文件，适合先派 explorer / scout subagent 做归纳。
- Scout subagent 的任务不是解决问题，而是估算问题：找涉及模块、文件数量、风险点和建议拆分方式，最后只输出短摘要。
适合 subagent 的上下文形态：
- 原始上下文很大，但最终可以压缩成小摘要。
- 例如：读 2000 行日志，输出 5 个失败原因；搜索 50 个文件，输出 8 个关键调用点；读多篇官方文档，输出一个迁移 checklist。
- 如果原始上下文本身就是主 agent 后续每一步都要依赖的核心决策依据，则不适合外包；主 agent 应该自己读。
二、目标函数隔离：让不同立场分开推理
目标函数隔离解决的是“不同局部目标混在一起后互相污染”的问题。
- Generator 倾向于完成实现。
- Evaluator 倾向于寻找失败证据。
- Security reviewer 倾向于默认存在风险。
- Performance reviewer 倾向于默认存在瓶颈。
- Planner 倾向于做全局取舍和最终收口。
这些目标都服务于同一个用户目标，但局部优化方向不同。如果让同一个 agent 既实现又验收，它很容易因为理解了自己的实现路径而变得宽容。
判断目标是否适合隔离，可以看五个维度：
- 成功标准是否不同：planner 要交付可用功能，explorer 只需列出调用点，reviewer 只需找风险。
- 立场是否不同：generator 要完成实现，evaluator 要找失败证据，security reviewer 要默认存在风险，performance reviewer 要默认存在瓶颈。
- 工具权限是否不同：只读 explorer、可写 implementer、只读 SQL checker、浏览器 evaluator 的权限边界不同，通常也意味着目标不同。
- 输出物是否不同：文件列表、风险清单、API spec、测试报告、方案对比、失败复现步骤、review finding 都可以作为独立 artifact。
- 是否需要全局取舍：如果子任务必须理解所有产品权衡、用户偏好、技术债和排期才能做决定，就不适合独立；如果只需完成局部问题并带回证据，就适合拆。
三、权限隔离：不同任务只给必要工具
权限隔离解决的是“所有 agent 共享同一组工具会放大风险”的问题。
典型做法：
- Explorer 只读代码和文档，不改文件。
- Implementer 只允许修改指定模块，不扩展写集。
- DB checker 只能执行只读查询，不允许写数据库。
- Browser evaluator 可以操作页面和截图，但不改源码。
- Security reviewer 可以读配置和权限规则，但不能执行高风险命令。
权限隔离的价值是把 prompt 里的“请不要做”变成系统层的“不能做”。这比依赖模型自觉更稳。
四、责任隔离：Subagent 只完成局部 Contract
责任隔离解决的是“谁对最终取舍负责”的问题。
- Planner 的目标是全局的：理解用户意图、定义成功标准、控制范围、安排顺序、分配任务、整合结果、判断取舍、对最终交付负责。
- Subagent 的目标应是局部的：找信息、做一个模块、审查风险、验证行为、写测试、比较方案、找 bug、总结文档。
- Subagent 不负责最终产品取舍，只负责完成一个局部 contract，并把证据交回 planner。
这能防止 subagent 擅自扩大范围、替用户做产品判断，或者在缺少全局上下文时做不可逆决策。
Subagent Contract
Planner 拆 subagent 时，本质是在设计局部 contract。一个清晰 contract 至少包括：
- 你是谁：只读 explorer、实现者、evaluator、reviewer。
- 你的目标：找调用点、改某模块、验证用户路径、找风险。
- 你的输入：相关 spec、路径、限制。
- 你的权限：只读、可写某些文件、可跑测试。
- 你的模型 / 运行策略：快速探索模型、长思考模型、审美模型、低成本并发模型，或指定推理深度和预算。
- 你的非目标：不要改无关文件、不要做产品取舍、不要扩展范围。
- 你的输出：文件列表、结论、证据、下一步建议。
五、模型匹配：为局部任务挑选最合适的模型
模型匹配解决的是“所有任务都用同一个模型，会在速度、成本、质量和能力上失衡”的问题。
拆出 subagent 后，planner 可以为不同局部需求选择不同模型和运行策略：
- 探索类需求：优先选择快速、擅长搜索和并发扫描的模型或工具型 agent，例如用户提到的
Context 1、swe grep这类探索 / 检索取向能力。 - 长思考需求：优先选择推理更强、能处理复杂取舍和多步规划的模型。
- 审美 / 体验判断：优先选择在视觉、文案、产品直觉或创意表达上更强的模型。
- 代码修复需求：优先选择熟悉代码修改、测试反馈和 repo 工具链的 coding model。
- 验收 / QA 需求：优先选择稳定、保守、能严格按 checklist 找失败证据的模型或配置。
这里的关键不是“哪个模型整体最强”，而是“哪个模型最适合这个局部 contract”。探索型 subagent 要的是速度、覆盖率和并发能力；审美型 subagent 要的是品味和表达判断；复杂规划型 subagent 要的是长思考和全局取舍能力。
这也是 subagent 相比单一主 agent 的额外价值：它让模型选择从“全局固定”变成“按任务局部路由”。
工程实践
Planner 拆 subagent 的实现来自四层共同作用。
- 模型预训练提供通用语义先验：模型通常知道“审计”“全局”“排查”“调研”“所有调用点”意味着范围可能较大。
- Prompt / policy / skill 提供显式启发式规则：例如命中超过 20 个文件先派 scout、日志超过 500 行先做日志归纳、实现者不能自评高风险任务。
- 运行时 probe 提供当前任务的真实规模：搜索命中数量、目录规模、日志行数、涉及模块数、是否跨服务 / 跨语言 / 跨层。
- 数据库 / memory / traces 提供历史经验：过去哪类任务经常上下文爆炸、哪个 repo 的哪些目录复杂、哪类任务派 scout 后成功率更高。
- 最稳的 planner 不应只靠其中一层，而应按顺序综合：先用模型理解任务语义，再用规则触发 probe，再用 probe 拿到实时规模，最后参考历史 traces 决定是否拆 subagent。
| 分层 | 内容 | 例子 |
|---|---|---|
| 模型预训练 | 通用语言和任务先验 | “审计”“全局”“排查”通常意味着范围大 |
| Prompt / policy | 明确启发式规则 | 命中超过 20 个文件先派 scout |
| 运行时 probe | 当前任务实时数据 | rg 命中 63 个文件，CI 日志 1200 行 |
| 数据库 / traces | 历史经验和统计 | 过去权限任务平均涉及 40 个文件，安全 review 必须独立 |
总结
- 只要 subagent contract 写不清，就先不要拆。
- 能写清 contract，并且拆分能节省上下文、带来独立视角、并行收益、权限隔离或更好的模型匹配，才值得拆。
- Planner 拆 subagent 的关键不是预测子 agent 是否聪明，而是判断局部任务是否可隔离、可验收、可交接。
