怎样用好子 Agent

1. 怎样用好子 Agent

[!abstract] 速览

  • 主 Agent 负责跟我们沟通、统筹，子 Agent 只接收它分配的任务，在自己独立的环境里执行完，再把结果汇报回来。
  • 适合交给子 Agent 的任务，共同点是会产生大量的中间过程信息，但最终只需要一个精简的摘要或改动结果。
  • 定制子 Agent 的价值，在于按角色单独配置系统提示词与刚好够用的便宜模型，做到 Skill 管调度、子 Agent 配置文件管执行。
  • 日常闭环：开发前探索（Explore）+ 完成后审查精简（Simplify）。
等距插画：中央的木色控制盒通过管道连接四个圆形工作台，台上分别放着放大镜与文档、钢笔与稿纸、印章与勾选单据、罗盘刻度盘，象征主 Agent 把任务分派到各自的作业台

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

1.1. 什么是子 Agent 与单窗口痛点

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

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

双栏对比插画：左侧「一个话题，从头做到尾」是一个人被多个堆叠的编辑器窗口包围、满头汗；右侧「主 Agent 调度独立子 Agent」是一个主 Agent 通过对话框与下方三个子 Agent 窗口双向连接

1.1.1. 只在一个话题里从头干到尾的痛点

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

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

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

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

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

1.2. 哪些任务适合交给子 Agent

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

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

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

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

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

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

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

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

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

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

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

1.3. 自定义子 Agent 的三层配置

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

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

核心原因有两个：

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

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

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

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

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

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

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

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

插画：三层机械台座，第 3 层是调度 Skill 的箭头转盘，第 2 层是三个角色配置罐（放大镜、代码、盾牌图标），第 1 层是带仪表的全局运行边界

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

最外面一层是工具的全局设置（比如在设置面板的 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 内置的提示词自然会指导它按规范工作。

[!important] 一句话原则
Skill 管调度，子 Agent 配置文件管执行。

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

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

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

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

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

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

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

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

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

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

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

1.4. 四个核心角色与协作闭环

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

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

角色 定位 模型与要点
探索者（Explorer） 只读探索代码位置，或在动手前做资料调研 最便宜、响应最快一档：Codex 用 GPT Luna 并开启快速模式，Claude Code 用最轻量的 Haiku 档位
执行者（Executor） 修改代码这类边界明确的执行任务 偏向执行类的模型即可，不需要很强的产品设计与全局规划能力
审查者（Reviewer） 不带历史上下文的独立审查 只针对当前这一次代码变更做检查，问题清单交主 Agent 修复
专项长板角色 写文案等按模型长板分工 指定文笔更自然的 Gemini
专家顾问（Expert Advisor） 疑难 Bug 与跨模块架构攻坚 各家最贵、推理最强的顶级档，例如 GPT-6 Astra，按需唤起

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

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

插画：拿放大镜的人在文件夹树中定位到一个高亮文件；底部标注「只读权限并行扫描代码库」「配最便宜快速的轻量模型」「只向主 Agent 返回简短摘要」

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

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

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

插画：在编辑器窗口内移动光标修改代码，右上角打勾；底部标注「主 Agent 提前交代规范与文件」「专注边界明确的代码落地」「避开轻量模型自主召回短板」

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

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

1.4.3. 审查者（Reviewer）：用不带历史上下文的独立视角精确 Review

第三个核心角色是专门用来做代码审查的审查者（Reviewer）。为什么 Review 的时候需要单独拎出来让子 Agent 做，而不是让刚写完代码的 Agent 自己检查？核心原因就在于子 Agent 和主 Agent 的上下文是相互独立的。

插画：拿放大镜的人在看含增删行的代码差异视图，圈出被复用的目录结构；底部标注「上下文独立无历史思维惯性」「只针对当前代码变更做检查」「输出问题清单交主 Agent 修复」

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

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

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

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

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

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

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

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

1.5. 派发其他 Agent 作为子 Agent

前面我们介绍的三层配置和角色分工，主要用的是 Claude Code 或 Codex 等工具内置的原生子 Agent 机制。但原生子 Agent 默认往往只能调用它们自家体系里的模型——如果我们想在一个 Agent 里面，直接派发另一个独立的 AI Agent 作为子 Agent（比如在 Claude Code 里派发 Codex 去写代码，或者同时调度多个不同厂商的 Agent），最简单的方式是什么？

其实最简单的方式，就是利用 AI Agent 可以执行命令的特性，让它直接去调用另一个 AI Agent 的命令行工具（CLI），再配合 Skill 和内置脚本把调用规则与复杂参数封装起来：

插画：主 Agent 卡片经「任务说明」进入含权限参数、会话续接、日志过滤的内置脚本，再分别调用 Codex CLI 与其他 CLI，结果汇总为「精简报告」回流主 Agent；左下 SKILL.md 提供调用规则

具体来说，这套设计理念分为三层递进：

  1. 直接调用目标 Agent 的命令行（CLI）：现在主流的 AI Agent（比如 Claude Code、Codex、Kimi CLI 等）基本都提供了命令行工具，支持在终端里直接传入一句提示词让它执行任务。只要某一个 Agent 有命令行工具，而当前的主 Agent 又能执行命令，那么主 Agent 只需要在终端里运行一条命令，就能把任务派发给另一个 Agent 去完成。
  2. 封装成 Skill，让主 Agent 记住调用规则：如果每次都要我们手动告诉主 Agent 另一个 Agent 的命令该怎么敲，用起来还是太麻烦了。为了让它更加方便地调用，我们可以把这套调用方式封装成一个 Skill，在说明文件 SKILL.md 里写清楚目标 Agent 命令行的调用格式和触发场景。这样下一次我们只要触发这个 Skill，AI Agent 看到这个 Skill，自然就知道这条命令行该怎么写了。
  3. 在 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。

1.6. 使用子 Agent 的避坑建议

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

插画：三条避坑建议的对照图——侦探与代码文件夹旁标 CHEAP + LIGHTWEIGHT，皇冠宝箱标 EXPENSIVE + HEAVY 并打叉；天平一端三份子 Agent 文档、另一端 LOW-COST MODEL 硬币；主 Agent 交付单份代码，旁边的多层节点树被划掉；右侧编号列出三条建议

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

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

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

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

[!warning] 先摆正预期
大家一定要有一个清晰的预期：启动子 Agent 并不天然等于省钱。

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

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

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

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

如果遇到一两步就能改完的简单小活，还非要去启动子 Agent，主 Agent 光是组织派发提示词、拉起子 Agent、等待子 Agent 读文件再返回结果，这一整套流程反而会白白浪费时间。

[!note] 用法边界
把子 Agent 留给那些真正会产生大量中间信息、或者确实需要多路并行与独立审查的任务，才是最舒服的用法。