使用 AI 工具的实用技巧 讲了一个重要原则：一个会话只聊一个主题。对话越长、上下文里无关信息越多，模型的回答质量就越差。
但如果你在使用类似 Claude Code、Codex 这类编程 Agent，就会发现一个问题：复杂任务本身就包含很多步骤，你没法把它拆成多个会话。
比如你让 Agent 重构一个模块，它需要先搜索相关文件，逐个阅读理解依赖关系，规划改动方案，执行修改，最后跑测试验证。
前几步搜索和阅读产生的大量中间结果全部堆在 messages 数组里，到真正动手改代码的时候，上下文已经被这些中间过程塞满了。
有没有办法让 Agent「分身」去做这些探索工作，自己只接收最终结论？这就是 Sub Agent（子 Agent）要解决的问题。
和你直接对话的上下文我们一般称为主 Agent（或父 Agent），主 Agent 在合适的时候可能创建子 Agent 去完成一些任务。
Sub Agent 的本质
先用一个类比来理解：
假设你在写一篇论文，写到一半需要查一些资料来确认细节，你可以自己去查：翻十几篇文档、对比不同来源的说法、做笔记整理。查完之后脑子里塞满了各种中间信息，回来接着写的时候，思路已经被这些杂活搅乱了。
另一种做法是请个外包来处理这些杂活。你给他一句话的需求，他独立去翻资料、做对比，最后给你一段简洁的结论。你的思路始终在正事上，不会被查资料过程中乱七八糟的细节打断。
Sub Agent 就是这个「外包」。它的技术本质很简单：新开一个 messages 数组（上下文），在独立的上下文里完成任务，返回一段摘要。
主 Agent 把任务描述作为 prompt 发给 Sub Agent，Sub Agent 在全新的上下文里独立工作：搜文件、读代码、调工具，做完之后返回一段摘要给主 Agent。主 Agent 的上下文里只多了这段摘要，而不是 Sub Agent 过程中读过的所有文件内容。
比如编程 Agent 的场景，假设你让 Agent 开发一个功能：
不用 Sub Agent：主 Agent 自己在项目中搜索相关的代码实现，读了 10 个文件，最终确定其中有 3 个文件是和任务相关的。但这 10 个文件内容会全部追加到了上下文，到写代码时，上下文里堆了大量已经不再需要的搜索结果和文件内容。
用 Sub Agent：主 Agent 开一个 Sub Agent 去做搜索和分析。Sub Agent 在自己的上下文中完成这些工作，最后返回一段话：「认证模块涉及 auth.ts、middleware.ts、session.ts 三个文件，auth.ts 是入口，session.ts 依赖 Redis 连接」。主 Agent 的上下文里只有这段摘要，干干净净。
这就是 Sub Agent 作为上下文优化手段的核心：把探索过程隔离在独立的上下文里，只把结论带回主线。
下面以 Claude Code 为例，为了触发 Sub Agent，我明确要求使用 Sub Agent 去调查项目部署方式。
这个组件复刻了 Claude Code 的交互方式和 UI，点击组件，按上/下方向键可以切换主 Agent 和子 Agent 的上下文：
可以看到主 Agent 给子 Agent 新开了一个会话，详细描述了任务，然后就等着子 Agent 完成后返回结果，再进行之后的工作。
什么任务适合用 Sub Agent
有一个简单的判断标准：如果你只关心结论、不关心过程，这个任务就适合交给 Sub Agent。
探索性搜索是最典型的场景。比如「找出项目里所有跟鉴权相关的代码在哪」，Sub Agent 可能要读几十个文件才能搞清楚，但主 Agent 只需要最终的文件清单和关系梳理。如果这些中间过程全堆在主上下文里，会严重干扰后续的工作。
独立性强的子任务也很适合。比如「给这个函数写单元测试」，这个任务不依赖父级对话里的上下文，任务描述本身就足够了。Sub Agent 可以独立完成，写完把结果交回来就行。
还有一类是需要「第二意见」的审查。
这一点非常有意思，就比如我们自己写的代码，自己可能很难发现其中的问题，但如果让其他同事交叉 review 一下，就容易看出问题，所谓当局者迷旁观者清。
那么在 Agent 场景也是类似的，主 Agent 自己写的代码，让它在自己的上下文中复查自己的代码，那就很难发现问题；但如果启动一个 Sub Agent 在独立的上下文中检查，就不会受思维定势的影响，能给出更客观准确的判断。
最后，Sub Agent 也适合并行处理多个互不依赖的任务。
比如同时调研三个模块的实现方式，开三个 Sub Agent 并行跑，比串行一个一个来快得多。
反过来，有些情况不适合使用 Sub Agent：
-
如果任务很简单，一个工具调用就能搞定，开 Sub Agent 反而多此一举，创建新上下文本身就有开销。
-
如果任务强依赖父级上下文里的大量信息也不太合适。Sub Agent 从空白上下文开始，需要在 prompt 里把相关信息重新说一遍，要复述的信息太多的话，隔离的好处就被抵消了。
另外要注意，并不是 Sub Agent 用的越多越好。
比如 Claude Opus 4.6 模型默认就比较倾向于多开 Sub Agent，然后直接根据 Sub Agent 的分析开始干活。
Opus 4.7 调整了这个默认行为：默认少开 Sub Agent，更多依赖主 Agent 自己推理。
我比较推荐的搭配方式是：让 Sub Agent 给一个大致的分析收窄问题边界，然后主 Agent 还要基于这个分析亲自进行深入分析，最后再开始干活。
AI 工具怎么用 Sub Agent
理解了 Sub Agent 的原理，一个自然的问题是：我需要自己手动创建 Sub Agent 吗？
大多数情况下不需要。 Claude Code、Codex 这类工具的主 Agent 会自主判断什么时候该开 Sub Agent，并且自己给 Sub Agent 写 prompt。你日常使用时看到工具弹出了一个子任务面板，那就是主 Agent 在自动「分身」。
以 Claude Code 为例，它内置了几种 Sub Agent 类型，主 Agent 会根据任务性质自动选择：
- Explore Agent：只读的快速搜索 Agent，用 Haiku 模型（Claude 系列里最小最快的型号，适合简单任务）来搜索和分析代码，不做任何修改
- Plan Agent：规划阶段的调研 Agent，收集信息辅助制定方案，同样是只读
- general-purpose Agent：能读也能写的通用 Agent，处理需要多步操作的复杂子任务
当你让 Claude Code 做一个复杂任务时，它可能会自动开一个 Explore Agent 先搜一遍代码，拿到结论后再自己动手改。整个过程你不需要干预，主 Agent 自己判断什么时候该分身、该用哪种类型、prompt 怎么写。
Codex 也有类似的设计，内置了 default、worker、explorer 三种 Agent 类型，默认最多同时开 6 个并行 Agent，且 Sub Agent 不能再开自己的 Sub Agent（只允许一层委派，防止无限套娃）。
不管是 Claude Code 还是 Codex，套路都一样：主 Agent 自主决策 → 自己写 prompt → Sub Agent 独立工作 → 返回摘要。对你来说，这个过程是自动的。
自定义 Sub Agent
虽然工具会自动处理大多数情况，但如果某个工作流反复出现，可以把它沉淀成自定义 Sub Agent。
自定义 Agent 没啥神奇的，以 Claude Code 为例，自定义 Agent 就是 .claude/agents/ 目录下的一个 Markdown 文件：
---
name: code-reviewer
description: 代码审查专家，改完代码后自动触发
tools: Read, Grep, Glob, Bash
model: sonnet
---
你是一个代码审查专家，审查时重点关注代码质量、安全性和最佳实践。
具体要求如下：
...description 告诉主 Agent 什么时候该用这个 Sub Agent，tools 限制它能用哪些工具（这个例子里去掉了 Write 和 Edit，审查者能搜代码、跑命令，但不能直接改文件），model 指定用哪个模型（Claude 系列有 Haiku、Sonnet、Opus 三种模型）。
Markdown 正文就是给这个 Agent 的 system prompt。主 Agent 决定调用这个 Sub Agent 的时候，就会把 markdown 正文作为发给 Sub Agent 的指令，让 Sub Agent 在独立的上下文里完成任务。
Codex 用 TOML 文件做类似的事情，放在 .codex/agents/ 目录下：
name = "reviewer"
description = "PR reviewer focused on correctness and security."
developer_instructions = """
Review code like an owner.
Prioritize correctness, security, and missing test coverage.
"""思路是一样的：用自然语言定义好「什么时候用」和「怎么干活」，就可以了。
以我的使用经验来看，如果你只是开发代码，大部分情况下不需要自定义 Agent，Claude Code 默认的几种 Agent 类型已经够用了。除非你是构建自己的工作流，才可能需要对某个场景做一个固定的 Agent。
比如让 AI 帮你整理邮件，可能有很多定制化的需求，而且需求一般不会频繁变化。这个场景就比较适合总结一套固定的 prompt 模板，创建一个专门的 email-summary Agent，然后这样用：
调用 email-summary Agent，看看今天是否有重要的邮件有时候 Claude Code 可能不会自动调用到正确的 Agent，所以最好明确指定 Agent 的名字。
这样 Claude Code 就会单开一个 email-summary Agent 来处理任务，不会占用当前对话的上下文。
总结
本文介绍了 Sub Agent 的原理和使用方法，理解这个机制后就能善用 Sub Agent，提高工作效率。
当你看到 Claude Code 界面上弹出一个子任务面板，知道它正在用独立上下文做探索就行。Sub Agent 产生的中间过程不会污染你的主对话，你只会看到最终结论。
如果你的任务明显适合并行处理，也可以主动引导，直接说「用 Sub Agent 分别调研这三个模块，然后汇总结果」。虽然工具自己也可能会这么做，但明确的指令能减少工具的判断成本，直接按你的意图行动。
成本方面也值得留意，每个 Sub Agent 都有独立的上下文，意味着独立的 token 消耗。如果主 Agent 一口气开了很多 Sub Agent，token 消耗会明显变多。理解这点能帮你判断什么时候值得开、什么时候直接在主对话里做更划算。
如果你发现自己每次改完代码都要让 Agent 做一遍审查，或者每次处理 PR 都走相同的流程，就可以把它沉淀成自定义 Agent，不用每次重复说明。