一个协调器，三个 CLI：委托给 Codex 和 Gemini 真的能节省你的 Claude Token 吗？

像 2026 年的许多开发者一样，我最终在同一台机器上安装了三个 AI 编码 CLI，每一个都因不同的原因而赢得了一席之地：

• Claude Code ——协调器级别的智能体。最擅长多步推理、架构、调试以及在大型代码库中跨模块工作。也是我最在意其 Token 消耗的一个。
• OpenAI Codex CLI ——一个功能强大的编码智能体，当你交给它一个范围明确、自包含且规范精确的任务时，它表现出色。
• Google Gemini CLI ——多模态主力。图像生成、音频和 TTS、转录以及高质量翻译，特别是对于区域语言。

在某个时刻，一个显而易见的问题出现了：三个中最聪明的一个也是全天运行起来最昂贵的一个。那么我能让它成为 经理吗？给 Claude 一个任务，让它拆分工作，把部分工作交给 Codex 和 Gemini，让它们在完成时通过一个 Markdown 文件汇报——而 Claude 只把 Token 花在困难的部分和最终审查上？

我现在已经在实际工作中运行这个模式好几周了——一个完整的营销网站重新设计，一批 AI 生成的主图，八种语言的翻译，实用脚本，批量内容工作。这篇文章是完整的剧本：该模式是如何运作的，我使用的确切提示词形态，让它保持诚实的报告契约，真正节省的地方在哪里，以及决定整件事是否值得的两个隐性成本。

简短的回答： 是的，这个模式行得通，而且节省也是真实的——但前提是你得妥善设计好交接过程。 详细的回答是下面的所有内容。

首先，要明白你实际上在为什么买单

在任何策略变得有意义之前，你需要清楚地了解在一个智能体 CLI 会话中 Token 都去哪儿了。大致分为四个桶：

1. 输入 Token ——模型读取的所有内容：你的提示词、文件内容、工具输出、之前的对话。在一个漫长的编码会话中，这让其他一切相形见绌，因为智能体在每一轮都会重新读取上下文。
2. 输出 Token ——模型写入的所有内容：代码、散文、工具调用。通常按高于输入的费率计费。
3. 重读 ——无声的杀手。每次智能体打开一个 1,000 行的文件“只是为了检查一下”，你就要再次为这 1,000 行作为输入买单。
4. 返工 ——复合的杀手。一个被误解的任务会让你付出第一次尝试的代价、发现问题的审查代价，以及第二次尝试的代价。

委托攻击第 1 和第 2 个桶：子智能体的生成发生在 它的 账单上（不同的订阅、更便宜的模型，或者免费层），而协调器只读取一个紧凑的摘要。但糟糕的委托 会膨胀 第 3 和第 4 个桶——这正是本文讨论的核心矛盾。

协调器模式，正确定义

这是该架构最简单的形式：

            ┌─────────────────────────┐
            │   YOU (one instruction)  │
            └───────────┬─────────────┘
                        ▼
            ┌─────────────────────────┐
            │  CLAUDE (orchestrator)   │
            │  plans · splits · specs  │
            │  reviews · integrates    │
            └─────┬──────────────┬────┘
        spec + exact output path │
              ▼                  ▼
   ┌─────────────────┐  ┌─────────────────┐
   │  CODEX (coder)   │  │ GEMINI (media)   │
   │ scoped modules,  │  │ images, audio,   │
   │ tests, boiler-   │  │ translation      │
   │ plate, scripts   │  │                  │
   └────────┬────────┘  └────────┬────────┘
            │  artifacts → disk   │
            │  report.md (≤40 ln) │
            ▼                     ▼
            ┌─────────────────────────┐
            │  CLAUDE reads reports,   │
            │  verifies, fixes/retries │
            │  or integrates & ships   │
            └─────────────────────────┘

协调器拥有四样东西，并且 只有 这四样东西： 计划、 规范、 审查，以及 集成。所有庞大且机械性的东西都被向下推送，并带有两个不可协商的规则：

规则 1 —— 制品以确切的路径存入磁盘。 子智能体从不将其输出粘贴到对话中。它编写文件。协调器的上下文保持干净。

规则 2 —— 回复几乎什么都没有。 理想情况下是一个单词加上一份简短的 Markdown 报告。该报告是 唯一 协调器保证会阅读的东西。

如果你从这篇文章中什么都没记住，请记住这个： 委托提示词和报告是协调器在委托任务上花费 Token 的仅有的两个地方。 其他一切都是别人的账单。你整个的优化表面就是这两个文档。

演练 #1：将图像生成委托给 Gemini

这是我运行的最高价值的委托，因为协调器实际上无法做到这一点——Claude Code 背后没有图像模型。以下是 Claude 编写并发送给 Gemini CLI 的提示词的实际形态：

Generate a single photorealistic editorial corporate portrait.
Concept: <detailed art direction — subject, pose, wardrobe,
lighting, background, composition>.

CRITICAL: the entire subject must be fully inside the frame with
generous margin on all sides — do not crop arms or held objects.
Plain seamless light-grey studio background for easy cutout.
No text, no watermark, no logos, no props.

Save the image to /tmp/work/hero-cyber.png (overwrite if it exists).
Then reply only DONE.

注意这个提示词中的工程设计：

• 输出路径是精确的。 没有“把它保存在某个地方”——协调器准确地知道去哪里找，因此零来回拉扯。
• “Reply only DONE.” Gemini CLI 会很乐意用 400 个 Token 叙述它的创作过程。我们不需要。只要一个词。
• 约束条件被机械地拼写出来 （“完全在框架内”、“无水印”），因为你 没有 写出的每一个约束都是一场返工的轮盘赌。我从失败中吸取了每一行的教训——详情见下文。

然后协调器运行一个 质量关卡 在查看图像之前——一种廉价、机械的检查：

# does the file exist and is it non-trivial?
test -s /tmp/work/hero-cyber.png || echo "FAILED: missing/empty"

# entropy gate: catches blank/placeholder images without
# spending any model tokens at all
python3 -c "
from PIL import Image; import sys
img = Image.open('/tmp/work/hero-cyber.png')
# a flat placeholder has near-zero entropy; a real photo is > 4
print(img.entropy())
"

只有在关卡通过之后，协调器才会真正 查看 图像一次——单次视觉调用——以检查脚本无法检查的内容：构图、伪影、品牌安全性。这就是协调器端的全部 Token 成本：发出一个简短的提示词，返回一个单词，查看一次图像。

在后台运行这些。 图像任务需要一到五分钟。阻塞等待意味着你的协调器闲坐着，将整个上下文保存在内存中。启动任务，继续其他工作，当文件落盘时再回来看。现在每一个正经的智能体 CLI 都支持后台运行；请使用它。

演练 #2：将编码任务委托给 Codex

编码委托更棘手，因为故障模式不是一眼就能看出的糟糕图像——而是看起来合理但不适合你代码库的代码。修复方法是一个紧密的规范，使得“完成”是机器可检查的：

TASK: Write a standalone Node script at scripts/import-legacy.mjs

SPEC:
- Reads ./data/legacy-export.csv (papaparse is already a dependency)
- Maps columns per the table below … (exact mapping)
- Writes ./data/import-ready.json, an array of objects
- Node 22, ESM, no new dependencies
- Handle: missing fields → skip row + count; duplicate IDs → last wins

ACCEPTANCE (all must pass):
- node scripts/import-legacy.mjs runs clean on the sample file
- node --test tests/import-legacy.test.mjs passes (write these tests)
- npx eslint scripts/import-legacy.mjs → zero errors

REPORT: write REPORT-import.md (max 40 lines) with status, files
created, how to verify, and up to 5 gotchas. Do not paste file
contents into the report.

三个属性使这成为可委托的，而大多数编码任务则不是：

1. 自包含的 ——一个新文件，不对现有模块进行编辑，没有架构决策。
2. 机器可检查的验收标准 ——协调器通过三个命令进行验证，而不是逐行阅读代码。
3. 有界的接口 ——输入文件，输出文件，搞定。子智能体无法游荡到代码库的其余部分。

当报告落盘时，协调器运行验收命令（廉价），浏览可能遇到的问题（廉价），并且只有在某些地方失败或感觉不对时才打开实际代码。在一次干净的通过中，协调器从未阅读它本来要编写的 300 行代码—— 这就是 节省的地方。

真正节省的地方——用粗略的数学计算

1. 批量生成。 假设一个任务产生 2,000 行的输出（约 25k Token）。如果直接完成，协调器要支付约 25k 的输出 Token，加上围绕它的所有上下文阅读。如果是委托出去的，协调器要支付：一个约 300 Token 的规范，一次约 400 Token 的报告阅读，以及几百 Token 的验证命令。就称之为 约 1k Token 对比 约 30k Token ——减少了 95% 以上 在那个任务上，而生成本身则计入子智能体的配额。

2. 协调器无论如何都做不了的工作。 每一张图片，每一个音频文件，我最近交付的八种语言的翻译批次中的每一个，都是由 Gemini CLI 根据协调器编写的规范生成的。没有 Claude 原生的替代方案可供比较——这是纯粹的能力增益，Token 成本仅是规范加上报告。

3. 带有精确规范的冗长机械输出。 测试脚手架、数据迁移、样板模块、格式转换、根据大纲生成的文档草稿。共同点是： 低判断力，高容量。 容量恰好是输出 Token 的价格所在；判断力恰好是廉价智能体所缺乏的。将容量委托出去，保留判断力。

节省消失的地方——两项税收和一项间接费用

验证税

这是没有人计算在内的成本，所以让我给你看一张我自己项目的收据——为网站生成的一批 AI 主角人像：

• 一张图片回来时带着一个 竞争对手可识别的笔记本电脑 Logo 被烤进了镜头中。在法律和品牌上是无法交付的。重新生成——不，等等，实际上是 用图像工具把它修补掉 ，然后重新验证。
• 另一组图片的边角 声称是透明的，但实际上并非如此 ——一种不透明的近白色，只有在有色背景下才会显现出来。发现得晚了，用泛洪填充一遍修复，重新验证。
• 第三组的平板电脑产品 生成时有一半在画框外 ——模型裁剪掉了图像本应展示的核心对象。带有新约束行“所有东西完全在画框内”的完全重新生成。

每一张这样的图片 都通过了 廉价的机械关卡。每一张图片仍然需要协调器亲自去查看、判断并指导修复。委托并没有移除审查步骤——它将生成成本转移到了别处，而审查成本却留在了原地。

而当一个委托的任务未通过审查时，你要付出 三倍的代价：委托的代价、发现问题的审查的代价以及重做的代价。同一个任务两次失败的委托，其成本通常高于协调器第一次直接完成该任务的成本。这就是为什么我图像提示词中的每一行约束读起来都像是一道伤疤——每一条 都是 一道伤疤。

预算规则：假设 20–30% 的委托创意任务需要一个修复周期，并将其计入你的决策中。 如果任务的验证成本很低（运行测试、检查文件），即使有返工，委托也是稳赚的。如果验证意味着“仔细阅读所有内容”，那么所谓的节省只是一种错觉。

集成税

如果任务涉及许多文件、必须匹配代码库的约定，或者依赖存在于协调器脑海中的上下文——架构决策、跨模块重构、竞态条件调试——那么将其交接出去是一种虚假的节省。子智能体没有你的上下文；为了安全地集成它，协调器最终不得不重读子智能体接触过的所有内容。为了同样的理解，你付出了两次代价：一次是让子智能体构建其自己的局部画面，另一次是让协调器重建完整的画面。

迹象很简单： 如果编写规范需要解释你的架构，那就不要委托这个任务。 单单是编写规范的成本就超过了节省下来的成本，而且误解的风险是巨大的。

间接费用底线

编写一个好的委托提示词要花费 200–400 Token。阅读一份报告要花费 300–500 Token。验证还要花费几百 Token。所以这里有一条底线： 如果任务的直接成本大概在 1,000–2,000 Token（约 50–100 行输出）以下，委托它每次都会亏钱。 直接做就行了。

Markdown 报告契约——节省成败的关键

让大多数人接受这种模式的想法是报告文件：每个子智能体完成后会为协调器留下一份 Markdown 摘要。这是正确的直觉——这也正是整个方案悄然失败的地方。 如果 Codex 写了一份 500 行的报告，而 Claude 把它们全读了，你横竖都要付钱——只不过是付阅读的钱而不是写作的钱。

这里有一份 糟糕的 报告（如果你不加以约束，智能体就会生成这种报告）：

一篇 340 行的短文：重申了任务，按时间顺序叙述了每一个决策，将它创建的两个文件的全部内容粘贴进去“供参考”，包含了完整的测试输出，并以三段关于未来改进的警告和建议作为结尾。

阅读它的成本比编写代码的成本还要高。以下是我强制执行的契约：

# Task: import-legacy script
Status: DONE
Files created:
  - scripts/import-legacy.mjs
  - tests/import-legacy.test.mjs
How to verify:
  - node --test tests/import-legacy.test.mjs
  - node scripts/import-legacy.mjs && head data/import-ready.json
Gotchas:
  - 14 rows in the sample CSV had no email; skipped, count logged
  - CSV dates are DD/MM/YYYY, not ISO — parser handles both

以及保持每份报告这种形态的四条规则：

1. 硬性上限：40 行。 在委托提示词中声明。状态、路径、验证命令、可能遇到的问题——别无其他。
2. 是路径，永远不是内容。 制品存放在磁盘上；报告指向它们。协调器只有在验证需要时才打开文件——读两遍成为一种 选择，而不是默认行为。
3. 针对纯生成任务“只回复 DONE”。 当制品可以不言自明时（图像、音频文件），哪怕是一份报告都嫌多。文件落盘，一个单词传回来，关卡开始运行。
4. 每一个规范中都有机器可检查的验收标准。 “做得好一点”会导致返工。“所有测试通过，零 Lint 错误，输出是小于 200 KB 的 1200×630 JPEG”则产生一个通过/失败的状态，协调器只需一条命令即可验证。验收标准的质量 就是 你的委托质量。

分工：谁得到了什么，以及为什么

任务	交给	为什么
图像、音频/TTS、转录	Gemini CLI —— 一直如此	编排器完全做不了这些；纯收益
翻译（尤其是区域语言）	Gemini CLI	质量过硬，数量庞大，通过抽样即可轻松验证
带有严格规范的自包含脚本/模块	Codex CLI	数量大，判断要求低，机器可检查
测试脚手架，迁移，样板代码	Codex CLI	机械化输出；验收标准 = 测试本身
架构 & 设计决策	Claude — 永远不要委派	纯粹的判断；规范的成本会高于任务本身
多文件重构，集成工作	Claude	集成税使得委派得不偿失
调试	Claude	需要积累的上下文；子智能体可是从零开始的
对所有委派工作的最终审查	Claude	这正是你花钱购买高级模型所要完成的工作

有一点细微差别值得说明：这并不是说“Claude 好，其他差”。这是 数量与判断的较量。Codex 能写出极好的自包含代码；Gemini 的图像和翻译质量能胜任真正的生产工作。这种分工在于每个席位的成本以及每项任务的需求。

操作手册

几个能成倍节省成本的习惯：

将所有缓慢的工作置于后台。 生成任务通常运行一到五分钟。将它们分离出来执行，让编排器继续处理其他事情，等文件落地后再处理结果。永远不要让昂贵的智能体阻塞等待。

积极地进行批处理。 将六张图片作为六次对话生成，意味着有六轮的提示+报告开销。一个提示产生六个带有命名约定的文件（hero-01.png … hero-06.png），一份报告，一次审查。翻译也是一样：一次委派完成所有八种语言。

在智能审查前进行机械拦截。 文件存在 → 大小合理 → 熵/lint/测试通过 → 然后 把编排器的 tokens 花在判断上。门控捕获的每一个故障，都是你无需付费的模型审查。

快速失败，仅升级一次。 如果委派返回的结果有误，编排器会获得 一次 带有更明确约束的纠正重试机会（“上次尝试裁剪了平板电脑 —— 必须显示整个平板电脑”）。如果重试也失败了，就停止委派该任务；由编排器直接完成或绕过它。无休止的重试循环会让委派成为完成任何事情最昂贵的方式。

保持编排器会话的整洁。 长时间运行的编排器会话会积累上下文，而上下文就是你每轮都要支付的输入 token 租金。委派之所以有用，恰恰是因为产出物留在磁盘上而不是在对话中 —— 不要通过 cat把文件 -ing 到聊天中“看一眼”来破坏这一点。

把你学到的约束写入模板中。 每一次返工都会教会你一行提示词（“无水印”，“完全在框架内”，“没有新依赖”）。模板就是让你不再为同样的教训付两次钱的方法。

这样的工作周实际上是什么样子的

从定性上讲，在实际的项目周中运行这种模式后：编排器的上下文保持得很小，其轮次也保持得很快，因为大量的输出从未进入过对话。可见的 token 支出几乎全部转移到了规范、报告和审查上 —— 这正是你 希望 高级模型集中注意力的地方。子智能体则把它们自己的配额燃烧在数量上。失败是真实存在的，但也是可控的：大约四分之一的创意生成有一个修复周期，有着严格规范的代码任务几乎没有返工，还有一个任务（一个跨领域的重构），在规范草案开始变成架构文档后，我正确地将其保留给了编排器。

这种模式并没有让昂贵的模型变得更便宜。它只是让我不再把它当打字员用。

结论与检查清单

这个策略对吗？ 大多数情况下，是的。 对于生成密集型工作，节省是真实且巨大的 —— 这是对 输出的委派，而输出正是你付钱买的东西。对于判断密集型工作，节省是一种错觉 —— 这是对 理解的委派，而理解总是会回到编排器的账单上，通常还会带上利息。

将昂贵的 CLI 视为一位挑剔的技术负责人，带领着一支优秀、廉价的团队：它编写规范、审查简短的报告，并且只有在感觉不对劲时才会亲自打开引擎盖检查。

在委派任务之前，请运行这份检查清单：

• 输出是否 庞大 （>100 行 / >2k tokens），或者是编排器 根本无法生成的东西?
• 我能否编写规范 而无需解释我的架构?
• “完成”是否是 机器可检查的 （测试、代码检查、文件属性），而不是需要“仔细阅读所有内容”？
• 输出路径是否 精确，并且回复被限制为 DONE + 一份 ≤40 行的报告?
• 我是否预算了 一次修复周期 —— 并且决定了如果失败两次会发生什么？

五个“是”：委派它，将其置于后台，对它进行门控，并享受这笔算计。任何一个“否”：高级模型直接完成 —— 因为你花得最贵的 tokens 就是那些花了两次的 tokens。