# Codex 子 Agent 使用技巧：怎么拆任务、怎么省钱、怎么避坑
**作者**: oil-oil
**日期**: 2026-07-21T02:51:12.000Z
**来源**: [https://x.com/I_am_oil_oil/status/2079398758358700085](https://x.com/I_am_oil_oil/status/2079398758358700085)
---
哈喽大家好，今天这篇给大家分享一下 Codex 里面的子 Agent 怎么使用，以及我自己总结的一些最佳实践。
## 先搞清楚：主 Agent 和子 Agent 分别是什么
在开始之前，先说一下 Codex 里面的子 Agent 到底是个什么东西。
我们日常跟 Codex 对话的时候，是一个一个的话题。跟我们直接对话的这个，如果拟人化一点来说，它就是主 Agent——负责跟我们对话，并且执行任务。
那子 Agent 是什么呢？就是主 Agent 可以派发出去的“下级”。这个下级是不跟我们交流的，它只跟主 Agent 交流：主 Agent 给它分配任务，它单独去执行，执行完成之后再把结果汇报给主 Agent。
所以整个交流关系就是：我们 ↔ 主 Agent ↔ 子 Agent。子 Agent 不会直接跟我们对话。
## 子 Agent 的三个核心作用
我觉得它最核心的作用有三个。
第一个，提升执行效率。子 Agent 可以并行执行任务。一个主 Agent 干活的时候只能自己一个人干，但如果它能把任务拆分成不同的子任务——就像一个组织里面，你把活分配给不同的人——他们并行执行完之后再告诉你结果，你自己验收就好了。
第二个，节省执行开销。这个怎么说呢？Codex 里面的子 Agent 是可以指定模型的。一些简单的任务，我们可以派发给能力比较弱、但刚好适配这个任务的模型。把复杂任务拆分清楚之后，派发给便宜的模型去执行，主 Agent 负责验收就好了。
第三个，控制主 Agent 的上下文不要膨胀得太快。这个点其实很重要。如果我们一直跟一个主 Agent 对话，它既要负责方案的构思，又要负责方案的落地。落地的时候就有大量的工具调用——比如写代码要读大量的文件、输出大量的 Token。它改了好几个文件之后我们再跟它对话，很可能就触发上下文压缩了。而且这些工具调用的上下文，对我们后续的决策帮助不大，反而是一种干扰。
用子 Agent 的方式，主 Agent 只负责方案的生成，子 Agent 负责执行，执行完只把汇总好的结论返回给主 Agent。主 Agent 不用频繁调用那些修改代码的工具，上下文膨胀就很慢，主线程可以一直保持一个清醒清晰的状态。
## 哪些任务适合交给子 Agent 并行
适合并行的，是那种任务角度比较明确、可以拆成多个路径的工作：
- 探索类：查看代码、做调研，可以分多个平台、多个角度去调研；
- 运行测试、分析日志、独立检查：各自运行用例并说明失败原因，分别检查安全、质量和回归。
不适合并行的：
- 同时修改同一个领域的文件：派两个子 Agent 可能改到同一个文件，相互覆盖，也很难合并；
- 必须串行的任务：下一步依赖上一步的判断，子 Agent 没办法并行；
- 比较复杂的外部动作：涉及权限、发布、删除这一类的，不适合交给子 Agent 执行。
判断方法其实很简单：每个子 Agent 是否都有独立的任务、明确的范围和可以检查的结果？满足了再并行。
## 别忽略成本：并行省时间，但不省 Tok
子 Agent 也不完全只有好处，分配不好的话劣势很大。
一般来说，开启子 Agent 一定会造成更多的 Token 开销。举个例子：我们想修改一个页面，主 Agent 已经读过一些前置依赖的代码了，派发给子 Agent 之后，子 Agent 可能不需要读那么多依赖，但它还是要读一些规范——比如仓库里有没有 Skill 指导它怎么写好看的页面。这些信息主 Agent 要读，子 Agent 也要读。如果三个子 Agent 都负责前端修改，都要读设计相关的 Skill，那主 Agent 读一遍、三个子 Agent 各读一遍，开销肯定是上去的。
再加上主 Agent 派发任务时要写提示词，子 Agent 执行完还要返回总结内容，这些都是实打实的 Token。
所以它为什么有时候还划算？因为子 Agent 可以选便宜的模型。把适当的任务分配给适当的模型，整体算下来才是省的。Codex 官方 Manual 里也说了：与相近的单 Agent 任务相比，子 Agent 工作流通常会消耗更多 Token。是否并行，先看等待时间对你重不重要，再看任务能不能拆开。
## 自定义子 Agent：怎么创建，以及一个大坑
在 Codex 里打一个 @ 符号往下滚，能看到 Agents 列表，这些就是当前的子 Agent。我自己配了五个：
- 复杂任务执行者：配的 Terra 模型；
- 执行者：改代码用的，Luna 模型 + high 思考程度；
- Explorer 探索者：只读的，快速了解仓库信息或者批量联网调研就用它，Luna 模型最便宜；
- Reviewer：帮忙 review 代码的。
创建也很简单，直接跟 Codex 说“帮我创建一个自定义 Agent，专门用于写前端代码，模型用 Luna High”就行。它会触发 OpenAI Docs 这个 Skill 查自己的配置，然后在 ~/.codex/agents/ 下面建一个配置目录，写一个 TOML 配置文件，里面是名称、用途说明和 developer_instructions（就是它的系统提示词）。
建好之后再按 @，就能看到多出来的自定义 Agent，通过 @ 明确告诉主 Agent 去派发它。
但这里有个很重要的坑：Codex 派发子 Agent 的时候，不一定遵循子 Agent 自己配置的模型。比如我们给 frontend 配了 Luna + high，但大多数时候 Codex 派发时会直接继承当前主线程的模型和推理强度——我主线程选的是 Sol Extra High，那它派发出去的子 Agent 也是这个配置。也就是说，很多人辛辛苦苦建的自定义 Agent，配置的模型和推理强度大多数时候根本没用上，非常浪费 credits。
怎么处理？我试过很多方式，核心是两个：
1. 在提示词里明确要求：触发子 Agent 时必须传 agent_type 这个字段，指定为你要的那个 Agent；
2. 写一个 Skill 来约束调度。因为子 Agent 的上下文不一定是独立的，它可能继承主线程所有历史信息，也会继承主线程的模型。只靠自定义 Agent 的配置、没有 Skill 约束、提示词又写得不清楚的话，子 Agent 会非常浪费额度。
## 我的做法：Team Mode Skill + 一个 default 拦截器
我自己平时是用一个叫 Team Mode 的 Skill 来管理这些子 Agent 的，已经开源在我的 GitHub 上了。它里面描述了什么时候该用哪个子 Agent、什么时候继承上下文、什么时候不继承、什么时候复用某一个子 Agent（子 Agent 是可以销毁的，某个业务一直由同一个子 Agent 负责的话，可以重复教给它）。
还有一个比较“曲线救国”的技巧：我创建了一个叫 default 的自定义子 Agent，它是故意触发不了的。作用是——如果派发时 agent_type 传了空，又想白嫖主线程的模型配置，就会被拦截到这个 default 上，触发失败；然后主 Agent 根据错误信息再重新派发。用这种绕弯子的方式，避免 Codex 在没指定类型的情况下触发错误的子 Agent。
另外两个日常经验：
- 没有自定义子 Agent 也能用。直接说“使用三个子 Agent 并行检查当前的分支”，它自己就会去派发；
- 把思考程度调到 Ultra 之后，它会非常激进地使用子 Agent，不用你主动要求。默认情况下它一般是不派发的。
## 可以直接抄的提示词
最后给一个可以直接复制的写法：
> 请使用 3 个子 Agent 并行检查当前分支，所有子 Agent 都不要修改文件：
> 1. 查看改动范围和调用关系；
> 2. 检查测试缺口和潜在回归；
> 3. 检查正确性、安全和维护风险。
> 每个子 Agent 返回结论、相关文件或命令，以及未确认项。等全部返回后，请汇总结果，去掉重复内容，检查每项结论是否有证据支持，并说明仍未确认的问题。
要点就三个：一个 Agent 只做一件事；说明需要返回什么；要求主 Agent 最后汇总、去重、核对证据。
总结一下：子 Agent 的价值不是“多开几个模型”，而是把独立、噪声高、可验收的工作移出主线程。主线程保留决定，子线程承包噪声。
今天的分享就到这里，希望对大家有帮助。大家分享一下 Codex 里面的子 Agent 怎么使用，以及我自己总结的一些最佳实践。
## 相关链接
- [oil-oil](https://x.com/I_am_oil_oil)
- [@I_am_oil_oil](https://x.com/I_am_oil_oil)
- [1.8K](https://x.com/I_am_oil_oil/status/2079398758358700085/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:51 AM · Jul 21, 2026](https://x.com/I_am_oil_oil/status/2079398758358700085)
- [1,864 Views](https://x.com/I_am_oil_oil/status/2079398758358700085/analytics)
- [View quotes](https://x.com/I_am_oil_oil/status/2079398758358700085/quotes)
---
*导出时间: 2026/7/21 14:06:41*