Subagent 首先是 Context Isolation

subagent 不只是为了并行。

并行当然有价值。一个复杂任务可以拆成几个子任务，让不同 agent 同时查资料、读代码、验证假设。但如果只从并行角度理解 subagent，会漏掉更重要的一点：

subagent 是一种 context isolation。

主 agent 的 context 里通常有很多东西：用户目标、全局约束、历史对话、工具输出、当前计划、未决问题。不是每个子任务都需要看到这些东西。

例如让一个 subagent 去读某个模块的代码，它可能只需要：

- 当前子问题

- 相关文件

- 输出格式要求

- 必要的权限

- 少量全局约束

它不一定需要看到主任务里的所有聊天历史，也不一定需要继承所有工具权限，更不应该自动拿到所有 secret 或项目资料。

这样做有几个好处。

第一，context 更干净。subagent 只看和局部任务相关的材料，少受主上下文里其它讨论干扰。

第二，任务边界更清楚。给 subagent 的输入越明确，它返回的结果越容易合并。

第三，权限可以裁剪。父 agent 能做的事，不代表子 agent 都应该能做。

第四，失败影响更小。子任务走偏时，不会直接污染主 context。主 agent 可以只接收一个 summary、evidence 或 error report。

所以 subagent 更像是从主任务里 fork 出一个局部工作区。

这个局部工作区可以有自己的 context、工具集、权限、scratchpad，甚至自己的临时文件系统。它完成后，不应该把所有内部轨迹都倒回主上下文，而是返回经过整理的结果：

- 结论是什么

- 证据在哪里

- 做过哪些关键检查

- 有哪些不确定点

- 是否需要主 agent 继续处理

这和 context 组装不是拼聊天记录 是同一个思路。完整事件记录可以留在 trace 里，但主上下文只需要吸收对下一步有用的工作视图。

subagent 也可以看成一种 routing。

某些任务被路由给更适合的模型、prompt、skill、工具集或权限包。代码搜索、资料检索、UI 检查、评审、测试修复，都可以是不同类型的 subagent 工作。

但无论实现成什么样，最重要的问题都是：

这个子任务到底需要看到什么？

它应该带走哪些约束？

它可以调用哪些工具？

它最后应该以什么形式把结果合并回来？

如果这些边界不清楚，subagent 只会把复杂度从一个 agent 变成多个 agent。数量变多，不等于系统变强。

好的 subagent 不是“多叫几个模型来帮忙”，而是为局部问题创建合适的隔离环境，再把可用结果干净地合并回主任务。