哈喽大家好，我是欧呦，这篇文章将为大家分享怎样用好子 Agent。

如果你刚开始接触 AI Agent，或者还不了解什么是 Skill，建议先读一下前面的两篇基础文章：《AI Agent 推荐与环境配置》 和 《从 0 到 1 了解什么是 Skill》。把基础概念了解清楚之后，再来看这篇关于子 Agent 的分享，理解起来会更顺畅。

什么是子 Agent？只用一个窗口从头干到尾有什么痛点？

一个会话从头做到尾与主 Agent 调度独立子会话的对比

如果要用日常生活里的团队协作来举例：假设我们去跟一个团队的负责人聊需求，这个负责人专门负责跟我们沟通。等我们沟通清楚、要开始做事情的时候，为了提升效率，或者让其他人干各自更擅长的事情，他不会所有活都自己一个人闷头干，而是会派他的下属去做。

放在 AI Agent 里面也是一样：直接跟我们沟通、负责统筹的这个就是主 Agent，而它底下派出去干活的那些下属，就是子 Agent（Subagent）。 子 Agent 一般不直接和我们对话，它只接收主 Agent 分配的任务，在自己独立的环境里执行完之后，再把结果汇报给主 Agent。

1. 只在一个聊天窗口里从头干到尾的痛点

平时如果只在一个聊天窗口里面，让同一个 Agent 从头干到尾，最大的痛点就是它的上下文会膨胀得特别快。

因为当我们进行 Vibe Coding（通过自然语言让 AI 写代码）的时候，Agent 既需要去大范围探索代码、读取许多文件，又需要去修改代码、看运行日志。几轮操作下来，当前窗口的上下文一下子就膨胀满了，甚至触发系统的上下文压缩。一旦上下文塞满或被压缩，它对于最开始我们讨论清楚的需求和约束条件，往往就会变得模糊，回答和改代码的质量也会跟着下降。

2. 为什么我会开始使用子 Agent？

最开始我使用子 Agent，其实是为了提升我的编程速度。

一方面，主 Agent 一个人干活只能串行，而子 Agent 是可以并行执行的——主 Agent 把互不冲突的子任务派给几个子 Agent 同时去做，等待时间会短很多；另一方面，我不需要自己手动去开多个聊天话题、分别跟不同的窗口沟通，我自始至终只需要在主窗口里跟主 Agent 一个人沟通，由它去替我分发任务和汇总结果。

哪些任务适合交给子 Agent？什么时候不适合并行？

在判断哪些事情适合交给子 Agent 时，有一个很简单好记的标准：

如果一个任务会产生大量的中间过程信息，但最终只需要一个精简的摘要或改动结果，那它就非常适合交给子 Agent。

具体到日常开发与创作中，最典型的场景有下面这几类：

  • 大范围代码搜索与调研：在一个很大的代码仓库里找某段逻辑写在哪里，子 Agent 翻看十几个文件后，只需要把具体的文件路径、行号和结构摘要返回给主 Agent，主 Agent 的上下文就不会被无关源码塞满。
  • 只读的 Code Review（代码审查）：子 Agent 没有主 Agent 之前的历史对话包袱，视角更干净，只针对当前这一次的代码变更做检查，判断更加准确。
  • 测试失败与大日志文件分析：报错日志非常占上下文，一个子 Agent 读两三个日志文件可能就读满了；让子 Agent 先在日志里定位到核心报错原因再返回给主 Agent，效率会高很多。
  • 多方案并行评估：让不同的子 Agent 各自聚焦评估一个备选方案，再把结论汇总给主 Agent 做决策。

1. 谁来决定派不派子 Agent？

很多刚接触子 Agent 的朋友会问：平时写代码的时候，到底怎么判断这一步该让主 Agent 自己干，还是让我去命令它派子 Agent 干？

实话说，这件事情让主 Agent 干还是派给子 Agent 干，平时并不是由我来决定的，一般来说都是主 Agent 自己决定的。

我日常的做法是：提前给主 Agent 分配好几个子 Agent 角色（或者利用它自带的子 Agent 机制），再配好调度规则，让主 Agent 根据当前任务的复杂度自己判断是否需要派发子 Agent。我平时很少去明确命令它「你现在必须派发子 Agent」，除非遇到某个主 Agent 一直不主动派发，而我当下确实需要提高任务效率、或者明确要并行处理多个任务时，我才会主动提醒它去调用子 Agent。

2. 三类不适合并行派子 Agent 的场景

虽然子 Agent 可以并行提速，但并不是所有任务都适合拆开并行。遇到以下三类情况时，不建议并行派发子 Agent：

  1. 多个子 Agent 可能同时修改同一片文件：如果两个子 Agent 同时去改同一个文件或紧密耦合的模块，非常容易互相覆盖对方的改动，最后很难合并。
  2. 任务本身必须串行推进：如果下一步的实现完全依赖上一步的执行结果（比如必须先把数据库表结构改好，才能去写对应的接口逻辑），就没法同时派出去并行做。
  3. 涉及权限、发布或删除等高风险动作：像线上部署、删除数据、修改核心配置这类比较复杂或者有风险的操作，应该留在主线程里由主 Agent 配合我们谨慎执行，不适合直接放权给子 Agent。

为什么自带的子 Agent 不够？通用的三层配置理念

现在不少主流的 AI Agent 工具（比如 Claude Code、Codex 等）其实都已经内置了默认的子 Agent 机制。那为什么自带的子 Agent 还不够，我们往往还需要自己去定制子 Agent？

1. 为什么要定制自己的子 Agent？

核心原因有两个：

第一，不同主 Agent 的默认调度能力不同

有些主 Agent 的自主调度能力很强，比如 Claude Code，它在需要探索代码时就会比较积极、合理地调用子 Agent；但像 Codex 它默认自带的子 Agent 调度能力就不太行，默认往往不会主动调用，或者在分配任务的时候分配得没有那么好。

这时候，我们就可以提前给它预定好规则和角色：明确规定哪些子 Agent 是用来探索代码的、哪些是用来执行任务的、哪些是用来做 Review 的、哪些是用来写文案的。

第二，专项场景可以定制专属提示词与便宜模型，省上下文又省钱

子 Agent 是可以单独定制它自己的系统提示词（System Prompt）以及所使用的模型的。因此，定制子 Agent 还有一个非常实用的价值，就是在专项场景下使用刚好够用的便宜模型。

比如说探索代码这件事，它对于模型推理能力的要求其实很低，只需要在一个很大的代码仓库里面检索到目标代码所在的位置。这时候如果你给探索子 Agent 配置一个价格很便宜的模型，让它去承担大规模的代码输入、整理成一份简短的报告后再交回给主 Agent，不仅主 Agent 不需要输入那么多 Token，你整体的模型开销也能极大降低。

2. 适用于任何工具的「三层配置架构」

不管你使用的是哪一款支持子 Agent 的工具，想要把自定义子 Agent 管好、用稳，底层都遵循同一套三层配置理念：

第一层：全局配置（控制运行边界）

最外面一层是工具的全局设置（比如在设置面板的 Configuration 或主目录下的全局配置文件里），主要用来控制子 Agent 的默认模型，以及两个和运行边界相关的参数：一个是最大子 Agent 并发数量（比如默认同时最多跑 6 个子 Agent），另一个是最大嵌套层级（也就是子 Agent 底下还能不能继续套娃调用下一层子 Agent）。

在实际使用中，这两个参数一般保持默认即可，特别是嵌套层级保持最多一层就够了——也就是只让主 Agent 派发子 Agent，禁止子 Agent 自己再去套娃派发下一层子 Agent。层数再多实际效果并不会更好，反而容易失控和浪费额度。即便你想调整全局配置，也可以直接让主 Agent 帮你修改，不需要自己手动去翻配置文件。

第二层：自定义子 Agent 角色配置（放角色专属知识与模型）

中间一层是每个自定义子 Agent 独立的配置文件（比如存放在个人主目录 ~ 下的隐藏配置文件夹 ~/.codex/agents/ 或 .claude/agents/ 中），用来定义这个角色的名字、使用的模型、思考强度，以及它的内置系统提示词。

这里有一个非常关键的配置原则：如果想通过 Skill 触发子 Agent，最好把「怎么干活」的执行规范写在子 Agent 自己的配置文件里，而不是写在 Skill 里。

原因很简单：Skill 是给主 Agent 读的。如果你把具体的执行规范（比如一大段前端开发规范或代码审查清单）全写在 Skill 里，就意味着主 Agent 每次派发任务时，都要把这一大段提示词重新输出一遍发给子 Agent——这样主 Agent 的输出会变多，占用的上下文也会变大。

反过来，当你把角色相关的知识直接写进子 Agent 自己的配置文件里（比如前端子 Agent 内置前端规范，后端子 Agent 内置后端规范），它们各自就不用去读冗长的通用规范了；主 Agent 派活时也只需要简单交代一句「你去看一下某个位置相关的代码」，子 Agent 内置的提示词自然会指导它按规范工作。简单总结就是：Skill 管调度，子 Agent 配置文件管执行。

第三层：调度 Skill（管什么时候派谁）

最里面一层是一个用来约束主 Agent 调度行为的 Skill，主要告诉主 Agent：遇到什么规模的任务该派发哪一类子 Agent、什么时候需要把当前对话的历史上下文带给子 Agent、什么时候直接复用已经启动过的子 Agent。

我自己平时在 Codex 里使用的就是一套叫 Team Mode 的开源调度 Skill（已开源在 GitHub：codex-team-mode）。之所以做成一个按需触发的 Skill，而不是塞进每次对话默认必读的全局规则文件 AGENTS.md（或 CLAUDE.md）里，是因为日常简单对话根本不需要每次都启动一套开发小队，只有在真正进入多模块编程任务时按需开启即可。

3. 怎么在工具里创建自定义子 Agent？

很多朋友可能会担心：不同工具里子 Agent 的配置文件格式不一样（有的是 Markdown，有的是 .toml），自己不会写怎么办？

其实如果想在 Claude Code 或者 Codex 里面配置自己的子 Agent，非常简单：不需要自己手写配置文件，直接让 Agent 自己去配就好了。

你只需要在对话框里跟主 Agent 说清楚三件事：

  1. 你想要创建一个叫什么名字的子 Agent；
  2. 它专门负责什么事情（职责与规范要求）；
  3. 它需要使用什么模型和思考档位。

比如你可以直接在对话框里对主 Agent 发这样一句话：

text
帮我创建一个名叫 explorer 的自定义子 Agent，权限设为只读，专门用来在代码仓库里快速定位相关文件和行号并汇总成简短报告，模型请配置为你支持的最便宜一档的轻量模型。

主 Agent 收到后，自己就会去查阅它内置的配置文档，自动在对应的目录（比如 ~/.codex/agents/ 或 .claude/agents/）下帮你把配置文件生成好。创建完成之后，你在输入框里输入 @ 就能在列表里看到刚才建好的子 Agent，也可以直接跟主 Agent 说「用刚创建的 explorer 子 Agent 帮我看一下项目的目录结构」来验证它是否生效。

子 Agent 的角色划分理念与协作闭环

四个子 Agent 角色各自处理明确的工作

我自己在给主 Agent 分配下属的时候，不会按任务难度去切出一大堆细碎的角色，而是按照专项职责与模型长板来划分。

需要说明的是，下面我提到的具体模型名称（比如 Codex 里的轻量档 GPT Luna、高阶档 GPT-6 Astra，或者 Gemini 等）都只是拿我日常使用的模型档位来举例——不管各家模型以后怎么换代改名，我们要掌握的是整个子 Agent 的分工理念，这套理念适用于任何 Agent 工具和任何大模型。

1. 探索者（Explorer）：用便宜模型吃下大规模代码检索

我一般都会先规划一个探索者（Explorer）角色。它是一个只读的子 Agent，专门用来在复杂的代码仓库里面去探索代码位置，或者在动手前做一些资料调研。

因为探索任务只需要生成搜索关键词、找到对应的文件和行号，并把大规模输入的相关信息整理成一份简短的报告返回给主 Agent，对模型的推理要求很低。所以我会给它配置最便宜、响应最快一档的模型——以 Codex 为例，我会使用 GPT Luna 模型（最便宜一档的轻量模型）并开启快速模式来进行代码探索；如果是在 Claude Code 里，对应的也是最轻量的 Haiku 档位。这样可以放心让它并行去扫几十个文件，既帮主 Agent 省下了大量上下文，又几乎不怎么消耗额度。

2. 执行者（Executor）：偏向执行落地的模型，避开自主召回短板

第二个常备角色是执行者（Executor），专门负责修改代码这类边界明确的执行任务。对于执行者来说，它偏向于执行类的模型即可，不需要有很强的产品设计能力、不需要很强的全局规划能力，也不需要很强的沟通交流感。

这里有一个很有意思的实战经验：有些价格便宜的轻量模型，单独拿来当主 Agent 用的时候不够稳定，但拿来当执行子 Agent 却非常好用。

为什么会这样？因为当项目里已经积累了比较多规范文档或 Skill 时，轻量模型如果单独作为主 Agent 跟我们对话，只要我们不明确点出文件名，它经常想不起来主动去读取对应的规范文件（也就是自主召回能力偏弱）。但当它作为执行子 Agent 运行时，能力更强的主 Agent 在派发任务之前，已经把「这次要读哪几份规范、要改哪几个文件、边界在哪里」全都交代得清清楚楚了——这正好避开了轻量模型自主召回弱的短板，同时又能享受到它极低的调用成本。

3. 审查者（Reviewer）：用无历史包袱的独立上下文精确 Review

第三个核心角色是专门用来做代码审查的审查者（Reviewer）。

为什么 Review 的时候需要单独拎出来让子 Agent 做，而不是让刚写完代码的 Agent 自己检查？核心原因就在于子 Agent 和主 Agent 的上下文是相互独立的。

当主 Agent 在一个窗口里跟我们聊了很久、了解了很多历史业务信息和实现过程之后，你再让它自己去 Review 刚才写的代码，它很容易顺着之前的思维惯性走，Review 得往往不够准确。

而审查子 Agent 启动时没有那些历史上下文的干扰，它可以非常客观、精确地只针对当前这一次的代码变更去做 Review（比如重点检查有没有过度复杂化、有没有加多余的防御分支、组件拆分是否合理、有没有放着现成库不用去重复造轮子）。而且等审查子 Agent 把问题清单列出来之后，主 Agent 拿到反馈就可以直接自己去完成修复。

4. 专项长板角色与专家顾问（写文案与疑难问题攻坚）

除了上面三个围绕代码读写的核心角色，我们还可以根据不同模型的独特长板，配置两类专项子角色：

  • 写文案等专项长板角色：比如有的模型写代码很强，但写出来的中文文案容易有机器味或翻译腔；那我就会专门配一个用来写文案的子 Agent，模型指定用文笔更自然的 Gemini。
  • 专家顾问（Expert Advisor）：像各家最贵、推理能力最强的顶级档模型（例如 GPT-6 Astra），如果全程挂在主窗口写日常业务代码，额度很快就会见底。更划算的理念是：日常用中等开销的主力模型作为主 Agent 推进开发；只有当某个疑难 Bug 连续改了几轮还没修好，或者在动手前需要先定一套复杂的跨模块架构方案时，再由主 Agent 唤起顶级模型的「专家顾问」子 Agent 来出主意。

5. 把角色串起来：「开发前 Explore + 完成后 Simplify」的协作闭环

把上面这些角色配齐之后，在日常处理复杂任务时，主 Agent 就可以把「探索者（Explorer）」「执行者（Executor）」和「审查者（Reviewer）」串起来，自然地跑通一套「开发前探索（Explore）+ 完成后审查精简（Simplify）」的协作闭环（这套流程我也直接集成在了开源的 codex-team-mode 里）：

  1. 开发前先派探索者做 Explore：遇到跨目录或多模块的复杂需求时，主 Agent 先并行派出探索者（Explorer）子 Agent 把相关代码路径摸清楚，只把关键文件位置和结构摘要带回主上下文，然后再由主 Agent 制定方案并交给执行者（Executor）落地。
  2. 完成后再派审查者做 Simplify：代码改完、准备提交之前，主 Agent 自动拉起审查者（Reviewer）子 Agent，独立检查一遍实现质量和代码复用情况，把多余的分支判断和冗余代码砍掉，确认干净后再交付给我们。

如何跨厂商调用其他 Agent 当子 Agent？

看到这里你可能会有一个疑问：像 Claude Code 或 Codex 内置的原生子 Agent，默认往往只能调用它们自家体系里的模型；那如果我想在当前主 Agent 里，把任务派发给另一个厂商的 Agent（比如在 Claude Code 里调用 Codex 写代码，或者在 Codex 里调用 Gemini 写文案），是怎么做到的？

其实原理非常简单，我利用的是 AI Agent 能够调用本地脚本 的特性——通过脚本去调用另外一个 Agent 的命令行工具（CLI）。

现在主流的 AI Agent 基本都提供了命令行工具（CLI）。只要某一个 Agent 有命令行工具，我们就可以写一个轻量的包装脚本放进 Skill 里：当主 Agent 觉得某个任务适合交给另一个 Agent 时，它就在后台运行这个脚本，拉起对应 Agent 的命令行工具并把任务说明传过去；等对方在独立会话里执行完毕、把精简的 Markdown 结果写入本地文件后，主 Agent 再读取这份输出文件来验收结果。

如果你也想用这种方式实现跨 Agent 协同，可以直接看看我开源在 GitHub 上的 oil-oil/codex 仓库。它就是通过内置的包装脚本（如 ask_codex.sh），让 Claude Code 或其他任何支持调用本地脚本的 Agent，都能直接把编码、探索和评审任务委托给本机的 Codex CLI 去执行。沿用同样的思路，只要目标 Agent 有 CLI，你就可以把它变成你主窗口底下的一个专项子 Agent。

使用子 Agent 的三条实战避坑建议

最后，结合我自己日常高强度使用子 Agent 踩过的坑，给大家总结三条最实在的避坑建议：

1. 千万不要用价格很贵的模型去探索代码

我自己早期就踩过这个坑：当时用价格很贵的模型去当探索子 Agent 找代码（或者在创建自定义子 Agent 时没检查模型配置，导致子 Agent 默认直接继承了主线程正在用的高价模型）。

这样做其实完全没有起到省钱的作用，顶多只是让主 Agent 的上下文膨胀得慢了一点，但底下的子 Agent 照样在用高价模型大口吃进几十个文件的 Token。所以，探索代码这类跑腿检索的活，一定要确认配上了最便宜够用的轻量模型。

2. 子 Agent 不一定能省钱，派发子线程本身有额外的 Token 开销

大家一定要有一个清晰的预期：启动子 Agent 并不天然等于省钱。

因为只要你派发了子线程，就代表着你的总 Token 开销往往会比单个 Agent 直接执行更高——主 Agent 之前读过的项目规范和背景信息，每个新启动的子 Agent 往往都要自己重新读一遍；主 Agent 派活时要输出提示词，子 Agent 执行完还要输出总结报告。如果同时启动三个子 Agent，这些基础读取就会叠加三次。

这个额外的 Token 消耗之所以划算，前提一定是你给子 Agent 配置了单价便宜得多的模型，用模型之间的巨大差价，把多出来的 Token 数量抵消掉。

3. 简单的任务完全没必要用子 Agent，单个主 Agent 直接做更好

有些任务其实非常简单明确（比如顺手改一两个已知文件里的文案或样式），这时候让当前的主 Agent 直接动手改就好了。

如果遇到一两步就能改完的简单小活，还非要去启动子 Agent，主 Agent 光是组织派发提示词、拉起子线程、等待子线程读文件再返回结果，反而会白白浪费时间。把子 Agent 留给那些真正会产生大量中间信息、或者确实需要多路并行与独立审查的任务，才是最舒服的用法。