一文搞懂 SubAgent：AI 为什么也需要给自己找个助手

一文搞懂 SubAgent：AI 为什么也需要给自己找个助手？

一、为什么需要 SubAgent？

假设你正在使用 AI 编程助手开发项目，突然问了一句：

“这个项目使用的是什么测试框架？”

为了回答这个问题，AI 可能会：

1. 读取项目配置文件。
2. 搜索相关依赖。
3. 检查测试目录。
4. 最终告诉你：“项目使用 pytest。”

问题来了：明明最终只需要一句话，AI 却产生了大量中间过程。

这些文件内容、搜索结果和工具输出可能进入主对话的上下文。随着任务不断进行，上下文中的无关信息越来越多，不仅占用 Token，还可能干扰模型对关键信息的关注。

这也是长任务中容易出现上下文质量下降（Context Rot）的原因之一。

有没有办法让 AI 自己去调查，但只把最终结论告诉我们？

这就引出了 SubAgent（子智能体）。

二、什么是 SubAgent？

SubAgent 可以理解为：主 Agent 临时派出去执行特定任务的助手。

举个例子。

你是一家公司的主管，需要了解某个竞品的情况。

你不会亲自翻阅几十份报告，而是安排一名助理负责调研。助理完成工作后，只需要向你汇报关键结论。

SubAgent 的工作方式也是如此。

它的基本执行流程如下：

主 Agent → 分配子任务 → SubAgent 独立执行 → 返回结果 → 主 Agent 继续工作

其中：

• 主 Agent：负责理解用户需求、分配任务和综合结果。
• SubAgent：负责执行具体子任务，例如搜索代码、分析日志、审查代码等。

最重要的是，SubAgent 拥有自己的独立上下文（Context Window）。

它执行过程中产生的大量搜索结果、文件内容和工具调用记录，不需要全部进入主 Agent 的上下文。

主 Agent 通常只接收最终结果。

因此，SubAgent 不只是简单地多开一个 AI，而是一种通过任务委派实现上下文隔离的机制。

三、SubAgent 的三个核心特点

理解 SubAgent，重点掌握三个特点。

1. 独立上下文

这是 SubAgent 最重要的特点。

主 Agent 和 SubAgent 分别维护自己的上下文。

例如，SubAgent 为了定位一个 Bug，阅读了几十个文件、分析了上千行日志。

这些过程主要保留在 SubAgent 的上下文中。

主 Agent 最终可能只需要知道：

“问题出现在用户认证模块，原因是没有正确处理过期 Token。”

这样就能减少无关信息对主上下文的干扰。

需要注意，上下文隔离不等于文件系统隔离。子 Agent 是否能修改主项目中的文件，取决于实际工具权限和运行环境。

2. 工具与权限控制

SubAgent 可以拥有与主 Agent 不同的工具集和权限。

例如，一个专门负责代码审查的 SubAgent，可以只开放：

• Read：读取文件。
• Grep：搜索文件内容。
• Glob：查找文件路径。

不向它开放代码编辑工具，就可以限制它直接修改代码的能力。

因此，SubAgent 不仅能实现任务分工，还能控制不同任务的执行能力。

不过，工具权限是否真正受限，取决于具体配置，并非所有 SubAgent 默认都是只读的。

3. 结果返回

SubAgent 完成任务后，会将结果返回主 Agent。

通常返回的是经过整理的摘要，而不是完整执行历史。

例如：

SubAgent 阅读了 20 个代码文件，最终只返回：

“该函数被 12 处调用，其中 3 处位于测试模块，主要调用路径为 A → B → C。”

主 Agent 就可以根据这些信息继续完成后续工作。

独立上下文、可配置的工具权限、结果返回，就是理解 SubAgent 的三个关键点。

四、SubAgent 有哪些实际应用？

在 Agent 开发中，SubAgent 常见于以下场景。

场景一：代码库探索

主 Agent 需要修改某个函数，但不了解整个项目的调用关系。

于是将代码搜索任务交给 SubAgent，后者负责阅读文件、分析调用链，最后返回关键发现。

主 Agent 不需要亲自处理大量探索信息。

场景二：代码审查

主 Agent 完成代码编写后，调用专门的 Code Reviewer SubAgent。

子 Agent 负责检查潜在 Bug、安全风险和代码质量问题，并返回审查报告。

这种方式还能实现开发和审查的角色分工。

场景三：并行调研

假设需要对比三种技术方案。

主 Agent 可以同时启动三个 SubAgent，分别调查不同方案的优缺点。

等它们返回结果后，再由主 Agent 进行综合分析。

因此，SubAgent 除了上下文隔离，还可以实现专业化分工和并行执行。

五、Claude Code 如何使用 SubAgent？

Claude Code 已经内置了 SubAgent 机制，可以直接使用，也支持自定义。

1. 内置 SubAgent

常见的内置类型包括：

Claude Code 会根据任务需要决定是否调用这些 SubAgent。

例如，当你要求它分析大型项目结构时，它可能委派 Explore 进行探索。

2. 自定义 SubAgent

除了内置类型，我们也可以创建自己的 SubAgent。

在 Claude Code 中，自定义 SubAgent 通常使用一个 Markdown 文件定义。

例如，创建一个 code-reviewer.md，存放在：

项目目录/.claude/agents/

文件主要包含以下配置：

• name：SubAgent 的名称。
• description：描述适合处理什么任务。
• tools：允许使用哪些工具。
• model：指定使用的模型。
• 系统提示词：规定具体工作方式。

例如，可以定义一个只使用文件读取和搜索工具的代码审查者，让它负责检查代码质量并提出修改建议。

配置完成后，可以直接告诉 Claude Code：

“使用 code-reviewer 子 Agent 检查刚才修改的代码。”

另外，自定义 SubAgent 也可以保存在 ~/.claude/agents/ 中，供多个项目复用。

3. 自动调用与手动调用

SubAgent 主要有两种触发方式：

自动调用：Claude 根据任务内容和 SubAgent 的 description，自行判断是否需要委派。

手动调用：用户明确指定使用哪个 SubAgent。

需要特别说明：自动调用并不保证每次都会发生。如果希望指定某个 SubAgent 执行任务，手动调用更直接。

六、SubAgent 和 Agent Teams 有什么区别？

两者都能实现多个 Agent 协作，但协作方式不同。

简单理解：

SubAgent 更像主管向助理分配任务，Agent Teams 更像一个团队中的成员共同完成项目。

在基础用法中，SubAgent 主要向主 Agent 汇报结果；而 Agent Teams 更强调成员之间的直接沟通和协调。

不过，两者的具体能力也会随框架和版本变化，并非完全互斥。

七、什么时候适合使用 SubAgent？

虽然 SubAgent 很有用，但并不是任务越多、子 Agent 越多就越好。

比较适合使用 SubAgent 的情况：

• 子任务需要大量搜索或探索，但最终只需要少量结论。
• 子任务相对独立，可以单独完成。
• 希望不同任务拥有不同的工具权限。
• 多项任务可以并行执行。

不太适合使用的情况：

• 任务非常简单，主 Agent 可以直接完成。
• 子任务需要频繁依赖主对话中的完整信息。
• 中间执行过程本身对后续决策十分重要。

另外，SubAgent 本身也需要消耗 Token，任务委派和结果汇总也会产生额外开销。

因此，使用 SubAgent 的关键不是尽可能多地创建 Agent，而是合理拆分任务。

八、补充：什么是 Fork？

普通 SubAgent 通常从新的上下文开始，通过主 Agent 提供的任务说明获取必要信息。

但有时，子任务需要理解之前的完整对话。

例如，主 Agent 已经和用户讨论出一套技术方案，现在需要基于该方案编写测试。

这时可以考虑使用 Fork（上下文分叉）。

Fork 的核心思想是：继承已有上下文，但隔离后续执行过程。

子 Agent 可以从主 Agent 当前的对话状态继续工作，而后续产生的探索过程不会全部写入原来的主对话。

需要注意，Fork 继承上下文，因此不具备普通 SubAgent 那样的初始上下文隔离优势。

九、总结

SubAgent 是 Agent 系统中非常实用的一种任务委派机制。

它的核心价值在于：

让子任务在独立上下文中完成工作，只把必要结果返回主 Agent，减少无关执行信息对主对话的干扰。

在此基础上，还可以实现权限控制、专业化分工以及并行执行。

对于初学者而言，暂时不必考虑复杂的多 Agent 编排。

先理解一次最简单的过程：

主 Agent 分配任务 → SubAgent 独立执行 → 返回关键结果。

理解这个过程，就已经掌握了 SubAgent 的基本工作原理。