本文整理自 Oil Book（book.oiloil.org） 免费实战指南（原文地址：book.oiloil.org/articles/su...）。站内提供无广告纸质书排版、全套原创手绘图解与完整 AI 工程系列目录。
哈喽大家好，我是欧呦，这篇文章将为大家分享怎样用好子 Agent。
如果你刚开始接触 AI Agent，或者还不了解什么是 Skill，建议先读一下前面的两篇基础文章：《AI Agent 推荐与环境配置》 和 《从 0 到 1 了解什么是 Skill》。把基础概念了解清楚之后，再来看这篇关于子 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。
2. 谁来决定派不派子 Agent？
看清了哪些任务适合拆、哪些不能拆之后，很多刚接触子 Agent 的朋友会问：平时写代码的时候，到底怎么判断这一步该让主 Agent 自己干，还是让我去命令它派子 Agent 干？
实话说，这件事情让主 Agent 干还是派给子 Agent 干，平时并不是由我来决定的，一般来说都是主 Agent 自己决定的。
我日常的做法是：提前给主 Agent 分配好几个子 Agent 角色（或者利用它自带的子 Agent 机制），再配好调度规则，让主 Agent 根据当前任务的复杂度自己判断是否需要派发子 Agent。我平时很少去明确命令它「你现在必须派发子 Agent」，除非遇到某个主 Agent 一直不主动派发，而我当下确实需要提高任务效率、或者明确要并行处理多个任务时，我才会主动提醒它去调用子 Agent。
自定义子 Agent 的三层配置
既然平时主要靠提前配好角色和规则让主 Agent 自动调度，而不少主流工具（比如 Claude Code、Codex 等）其实都已经内置了默认的子 Agent 机制，那为什么自带的子 Agent 还不够，我们往往还需要自己去定制子 Agent？
1. 为什么要定制自己的子 Agent？
核心原因有两个：
第一，不同主 Agent 的默认调度能力不同
有些主 Agent 的自主调度能力很强，比如 Claude Code，它在需要探索代码时就会比较积极、合理地调用子 Agent；但像 Codex 它默认自带的子 Agent 调度能力就不太行，默认往往不会主动调用，或者在分配任务的时候分配得没有那么好。
这时候，我们就可以提前给它预定好规则和角色：明确规定哪些子 Agent 是用来探索代码的、哪些是用来执行任务的、哪些是用来做 Review 的、哪些是用来写文案的。
第二，专项场景可以定制专属提示词与便宜模型，省上下文又省钱
子 Agent 是可以单独定制它自己的系统提示词（System Prompt）以及所使用的模型的。因此，定制子 Agent 还有一个非常实用的价值，就是针对检索、跑腿这类推理要求低的专项场景配置便宜够用的轻量模型，既帮主 Agent 省下上下文空间，又能把整体模型开销压下来。
2. 怎么在工具里创建自定义子 Agent？
很多朋友听到「自定义子 Agent」可能会担心：不同工具里子 Agent 的配置文件格式不一样（有的是 Markdown，有的是 .toml），自己不会写怎么办？
其实在 Claude Code 或者 Codex 里面配置自己的子 Agent 非常简单：不需要自己手写配置文件，直接让主 Agent 自己去配就好了。
你只需要在对话框里跟主 Agent 说清楚三件事：
- 你想要创建一个叫什么名字的子 Agent；
- 它专门负责什么事情（职责与规范要求）；
- 它需要使用什么模型和思考档位。
比如你可以直接在对话框里对主 Agent 发这样一句话：
text
帮我创建一个名叫 explorer 的自定义子 Agent，权限设为只读，专门用来在代码仓库里快速定位相关文件和行号并汇总成简短报告，模型请配置为你支持的最便宜一档的轻量模型。主 Agent 收到后，自己就会去查阅它内置的配置文档，自动在对应的目录（比如个人主目录 ~ 下的 ~/.codex/agents/ 或 ~/.claude/agents/）下帮你把配置文件生成好。创建完成之后，你在输入框里输入 @ 就能在列表里看到刚才建好的子 Agent，也可以直接跟主 Agent 说「用刚创建的 explorer 子 Agent 帮我看一下项目的目录结构」来验证它是否生效。
3. 适用于任何工具的「三层配置架构」
知道了创建单个子 Agent 有多简单之后，想要把一整组自定义子 Agent 管好、用稳，不管你使用的是哪一款工具，底层都遵循同一套三层配置架构：
第一层：全局配置（控制运行边界）
最外面一层是工具的全局设置（比如在设置面板的 Configuration 或主目录下的全局配置文件里），主要用来控制子 Agent 的默认模型，以及两个和运行边界相关的参数：一个是最大子 Agent 并发数量 （比如默认同时最多跑 6 个子 Agent），另一个是最大嵌套层级（也就是子 Agent 底下还能不能继续套娃调用下一层子 Agent）。
在实际使用中，这两个参数一般保持默认即可，特别是嵌套层级保持最多一层就够了------也就是只让主 Agent 派发子 Agent，禁止子 Agent 自己再去套娃派发下一层子 Agent。层数再多实际效果并不会更好，反而容易失控和浪费额度。即便你想调整全局配置，也可以直接让主 Agent 帮你修改，不需要自己手动去翻配置文件。
第二层：自定义子 Agent 角色配置（放角色专属知识与模型）
中间一层就是上面刚创建的每个子 Agent 独立的配置文件（如 ~/.codex/agents/ 或 ~/.claude/agents/ 中的文件），用来定义这个角色的名字、使用的模型、思考强度，以及它的内置系统提示词（比如前端子 Agent 内置前端规范，审查子 Agent 内置代码审查清单）。
第三层：调度 Skill（管什么时候派谁）
最里面一层是一个用来约束主 Agent 调度行为的 Skill，主要告诉主 Agent：遇到什么规模的任务该派发哪一类子 Agent、什么时候需要把当前对话的历史上下文带给子 Agent、什么时候直接复用已经启动过的子 Agent。之所以做成一个按需触发的 Skill，而不是塞进每次对话默认必读的全局规则文件 AGENTS.md（或 CLAUDE.md）里，是因为日常简单对话根本不需要每次都启动一套开发小队，只有在真正进入多模块编程任务时按需开启即可。
理解了第二层和第三层之后，有一个非常关键的分工原则：最好把「怎么干活」的具体执行规范写在第二层子 Agent 自己的配置文件里，而第三层 Skill 只负责管调度。
这是因为 Skill 是给主 Agent 读的。如果你把一大段前端规范或审查清单全写在 Skill 里，主 Agent 每次派发任务时都要把这一大段提示词重新输出一遍发给子 Agent，既多耗输出又占上下文；反过来，把角色专属规范直接写进子 Agent 自己的配置文件里，主 Agent 派活时只需要简单交代一句「你去检查一下某个位置相关的代码」，子 Agent 内置的提示词自然会指导它按规范执行。简单总结就是：Skill 管调度，子 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 里）：
- 开发前先派探索者做
Explore：遇到跨目录或多模块的复杂需求时，主 Agent 先并行派出探索者（Explorer）子 Agent 把相关代码路径摸清楚，只把关键文件位置和结构摘要带回主上下文，然后再由主 Agent 制定方案并交给执行者（Executor）落地。 - 完成后再派审查者做
Simplify：代码改完、准备提交之前，主 Agent 自动拉起审查者（Reviewer）子 Agent，独立检查一遍实现质量和代码复用情况，把多余的分支判断和冗余代码砍掉，确认干净后再交付给我们。
派发其他 Agent 作为子 Agent
前面我们介绍的三层配置和角色分工，主要用的是 Claude Code 或 Codex 等工具内置的原生子 Agent 机制 。但原生子 Agent 默认往往只能调用它们自家体系里的模型------如果我们想在一个 Agent 里面，直接派发另一个独立的 AI Agent 作为子 Agent（比如在 Claude Code 里派发 Codex 去写代码，或者同时调度多个不同厂商的 Agent），最简单的方式是什么？
其实最简单的方式，就是利用 AI Agent 可以执行命令的特性，让它直接去调用另一个 AI Agent 的命令行工具（CLI），再配合 Skill 和内置脚本把调用规则与复杂参数封装起来：
具体来说，这套设计理念分为三层递进：
- 直接调用目标 Agent 的命令行（CLI）：现在主流的 AI Agent（比如 Claude Code、Codex、Kimi CLI 等）基本都提供了命令行工具，支持在终端里直接传入一句提示词让它执行任务。只要某一个 Agent 有命令行工具，而当前的主 Agent 又能执行命令，那么主 Agent 只需要在终端里运行一条命令，就能把任务派发给另一个 Agent 去完成。
- 封装成 Skill，让主 Agent 记住调用规则 ：如果每次都要我们手动告诉主 Agent 另一个 Agent 的命令该怎么敲，用起来还是太麻烦了。为了让它更加方便地调用，我们可以把这套调用方式封装成一个 Skill，在说明文件
SKILL.md里写清楚目标 Agent 命令行的调用格式和触发场景。这样下一次我们只要触发这个 Skill，AI Agent 看到这个 Skill，自然就知道该怎么样去写这个命令行的规则了。 - 在 Skill 里封装脚本，屏蔽底层调用复杂度 ：如果只靠
SKILL.md让主 Agent 每次现场去拼装原始的 CLI 命令，实际调用像 Codex 或者其他 AI Agent 时还是会有不少复杂度------一方面不同命令行工具的只读/权限参数、工作目录和会话续接（session_id）写法各不相同，主 Agent 现场拼命令容易出错；另一方面命令行运行过程中会打印一大串读取文件和 JSON 事件流的中间记录，直接返回会很快塞满主话题的上下文。
因此，我们可以在 Skill 的 scripts/ 目录下进一步封装一层脚本，把这些复杂度全部收进脚本内部。
如果你也想直接在工作流里用上这套机制，或者看看它是怎么实现的，可以参考我开源在 GitHub 上的 oil-oil/oil-delegate。它正是按照上面的设计理念，通过内置脚本把 Claude Code、Codex、Antigravity、Kimi Code 等多个主流 Agent 的命令行工具统一封装了起来：
- 首次使用自动扫描本机环境：自动检测你电脑上已经安装了哪些 Agent CLI，让你选择启用哪几个、以及是否设置一个默认委托的 Agent；
- 内部屏蔽参数差异与日志噪音：脚本在内部自动处理不同 CLI 的权限参数、记录会话 ID（方便得到结果后接着追问或返工，不用重复交代背景），同时把中间冗长的读取与执行过程过滤掉，只把精简的结果报告带回主话题。
平时你完全不用背各家命令行怎么写，只需要在当前主 Agent 里直接说「用 cc 检查这个仓库的登录流程」或「让 codex 修复这个测试」，主 Agent 就会调用脚本把任务派发给对应的 Agent 去执行。顺着同样的思路，只要某一个 AI Agent 提供了命令行，你都可以用这种方式把它变成主话题底下的子 Agent。
使用子 Agent 的避坑建议
最后，结合我自己日常高强度使用子 Agent 踩过的坑，给大家总结三条最实在的避坑建议：
1. 创建子 Agent 时显式指定模型，防止默认继承主线程高价模型
我自己早期就踩过这个坑：在创建自定义子 Agent 时忘了检查模型字段，结果很多工具在不显式指定模型时，会默认直接继承当前主话题正在使用的高价主力模型。
这样做完全没有起到省钱的作用------顶多只是让主 Agent 的上下文膨胀得慢了一点，但底下的子 Agent 照样在用高价模型大口读取几十个文件的 Token。所以创建检索、跑腿类子 Agent 时，一定要在配置里明确写死最便宜够用的轻量档模型。
2. 子 Agent 不一定能省钱，派发子 Agent 本身有额外的 Token 开销
大家一定要有一个清晰的预期：启动子 Agent 并不天然等于省钱。
因为只要你派发了子 Agent，就代表着你的总 Token 开销往往会比单个 Agent 直接执行更高------主 Agent 之前读过的项目规范和背景信息，每个新启动的子 Agent 往往都要自己重新读一遍；主 Agent 派活时要输出提示词，子 Agent 执行完还要输出总结报告。如果同时启动三个子 Agent，这些基础读取就会叠加三次。
这个额外的 Token 消耗之所以划算，前提一定是你给子 Agent 配置了单价便宜得多的模型，用模型之间的巨大差价，把多出来的 Token 数量抵消掉。
3. 简单的任务完全没必要用子 Agent，单个主 Agent 直接做更好
有些任务其实非常简单明确（比如顺手改一两个已知文件里的文案或样式），这时候让当前的主 Agent 直接动手改就好了。
如果遇到一两步就能改完的简单小活，还非要去启动子 Agent，主 Agent 光是组织派发提示词、拉起子 Agent、等待子 Agent 读文件再返回结果，反而会白白浪费时间。把子 Agent 留给那些真正会产生大量中间信息、或者确实需要多路并行与独立审查的任务，才是最舒服的用法。
延伸阅读与 Oil Book 免费目录
- 《一文读懂 DeepSeek Super-agent》：看工业级 Personal Agent 如何设计 Router/Worker 双层调度。
- 《从 0 到 1 了解什么是 Skill》：结合这篇同主题的实战文章，把相关方法用到自己的项目中。
更多 AI Agent 实战指南、模型实测手记与免费工程章节，收录于 Oil Book（book.oiloil.org） ，本文网页原版地址：book.oiloil.org/articles/su... 。