Codex 额度不够用？试试这套三级任务分流法

古希腊掌管 Codex 额度重置的神，叫 Tibo。可最近这位神也歇了——周额度只降不涨。

古希腊掌管 Codex 额度重置的神，叫 Tibo。可最近这位神也歇了——不重置了，我们周额度只降不涨。

过去我的做法是 Sol 加 Ultra 同时开着，Fast 也常备。一个任务刚启动，下一个已经排在后面，编排踩得猛，额度消耗得快。赶上重置周期，还能撑一撑；现在这条路越来越靠不住。

既然额度见底，不如回头看一眼：Codex 的额度到底花在了哪里？

先关掉一个倍率开关

最先冒出来的，是 Fast 这一档。

GPT-5.6 启用 Fast 后，速度提升约 1.5 倍，额度消耗却会变成 Standard 的 2.5 倍。算下来，多花一倍半的额度，只换回来一半速度。以前赶进度，这个交换值得；现在额度紧张，Standard 才是日常档位。

真正紧急的交付任务才临时开启 Fast，结束后立刻关回。这一步能立刻止血，但只处理了一个倍率开关。

Fast 关掉以后，Sol 还是要读仓库、追调用链、翻日志、改代码、跑测试。任务稍微复杂一点，额度依旧掉得很快。

问题出在任务进门的方式

继续往深处看，问题出在任务进门的方式。

以往接到一个 Bug，最自然的说法是：

“修一下登录后刷新页面会退出的问题。”

这句话对人来说很自然，对 Agent 来说几乎没有边界。它不知道问题在哪个模块，不知道允许改什么，也不知道做到什么程度才算结束。

于是 Sol 只能从头包办：先找登录代码，再追前后端调用链，跑复现、读日志、判断根因，最后改代码、补测试、自己验收。任务确实完成了，但这条链路里混着三种性质完全不同的工作。

第一种是调查——搜索 auth 引用、阅读大文件、整理报错。这些工作主要消耗上下文，不直接产出修改。

第二种是判断——登录状态应该放在 Cookie、session 还是本地状态里，需要权衡利弊。

第三种是执行——修改已经圈定的文件、补一条回归测试、执行测试命令，重点是按要求完成动作。

三种工作需要的判断量不同，继续全部塞给 Sol，等于让主模型一边定方案，一边翻日志，还要亲自完成每一处机械修改。

三级分工：Sol、Terra、Luna

正好赶上 Luna 降价 80%、Terra 降价 20%，我便顺着这三类工作，把 Codex 重新分了一次工。

主线程继续使用 Sol + Ultra。完整需求、方案取舍和最终验收都留在这里。

在此之外，新增两个自定义 Agent。

第一个叫 terra-researcher，使用 Terra + high，并且设为只读。它专门做跨文件调查：梳理调用链、阅读大文件、检查 diff，把散在仓库里的信息压成几条带文件位置的证据。

把它设成只读，是因为调查阶段最怕顺手修改。Agent 查到一半就觉得自己已经猜到答案，直接改了三个文件；主线程拿回来才发现根因还没确定，只能一边处理旧改动，一边重新调查。模型费用省下来了，很快又被返工吃掉。

另一个叫 luna-worker，使用 Luna + medium。它只接范围已经圈定、结果能够检查的工作：搜索指定模块、修改指定文件、执行一条测试命令、整理失败日志，或者完成规则明确的批量调整。

Sol 管方向，Terra 找证据，Luna 做执行。三类工作的归属，至此基本清晰。

五格任务卡：先把活说清楚

但只写两个 TOML，还不算任务分流。

如果派活时仍然只说一句"帮我看看这个 Bug"，Codex 还是要临场猜该叫谁，子 Agent 也会重新理解一遍需求。模型换便宜了，任务描述依旧很宽，消耗并不会自动降下来。

我在项目的 AGENTS.md 里加了一条硬规则：每次委派之前，先把任务写成一张五格任务卡。

第一格写交付物。“研究登录模块"没有停手位置。我会把它改成：“找出刷新后登录状态丢失的调用链，返回有文件位置支持的根因候选，不修改代码。“这句话写完，Terra 才知道查到哪里可以交卷。

**第二格写工作范围。**从哪个目录开始，哪些文件允许修改，哪些系统不能碰。已经知道入口文件，就把路径直接给它。范围越清楚，子 Agent 花在盲目搜索上的上下文越少。

**第三格写禁止事项。**调查任务禁止写入；局部修复禁止顺手重构；测试任务不能为了变绿删除失败用例；没有明确授权，不能增加依赖、改数据库或调整公共接口。

这一格专门拦返工。许多任务变贵，原因不是模型不够聪明，而是 Agent 多做了一件你没要求的事，主线程只能再花一轮额度把它收回来。

**第四格写验收方式。**可以是一条测试命令，也可以是几项能够实际操作的行为。套到登录 Bug 上就是：登录成功后刷新，用户状态仍然存在；退出后刷新，状态不能恢复；原有的认证测试全部通过。

如果连验收条件都写不出来，就不该把修改交给 Luna——这通常意味着任务还没拆到能够执行的程度。

**第五格写返回格式。**子 Agent 最后只交回相关文件、关键证据、实际 diff、测试结果和未解决问题。完整的搜索过程、几千行日志、已经排除的错误方向，全留在子线程里。

子 Agent 能省额度，很大一部分原因就在这里：嘈杂过程没有进入主线程。如果最后又把原始日志倒回 Sol，前面做的上下文隔离就等于白做。

三条路由：这张卡该交给谁

五格任务卡解决的是"怎么把活说清楚”。接下来才是"这张卡该交给谁”。

我把任务分成三条路线。

文件、动作和验收都已明确，直接交给 Luna。

比如已经确认是 session.ts 里的过期时间写错了，只需改一个字段，再跑现有测试。这个时候再让 Terra 调查一遍，或让 Sol 从头阅读认证模块，只会重复消费上下文。

根因还不清楚，需要跨文件找证据，先交给 Terra。

Terra 把真实调用链压缩回来，Sol 根据证据圈定方案，再让 Luna 执行。这里的顺序不能颠倒：证据还没齐就开始修改，后面大概率会多出一轮返工。

涉及架构、权限、安全、数据库、支付、公共接口，或几个核心模块之间要做取舍，任务留在 Sol。

这类决定一旦选错方向，后面做十次便宜修改也救不回来。省额度不能靠降低决策质量。

把登录 Bug 走一遍

把刚才那个登录 Bug 放进这套路线里，过程会变成这样。

Sol 先生成一张调查卡：目标是定位刷新退出的根因；范围从认证中间件和 session 恢复逻辑开始；禁止修改；只返回调用链、证据和根因候选。

这张卡交给 Terra。

Terra 查到：登录成功后，服务端已经正确写入 session；问题出在刷新页面时，前端恢复函数读取了另一个存储键；现有用例只覆盖首次登录，也没有覆盖刷新恢复。它把相关文件、函数位置和证据交回主线程。中间读过多少文件、跑过多少搜索，都不进入 Sol 的上下文。

拿到这些证据，Sol 只需要做三个决定：统一存储键，保持认证接口不变，增加刷新恢复的回归测试。可修改的范围也从整个仓库缩小到两个文件。

接着再生成一张执行卡，交给 Luna。

卡里写清两个修改、禁止调整认证接口、禁止新增依赖，以及需要运行的测试命令。如果 Luna 发现还要动第三个模块，立即停手，把问题退回主线程。

Luna 改完、跑完测试，只交回 diff、测试结果和越界检查。最后由 Sol 对照最初的需求检查证据和修改，决定能否交付。

整条链路里，Sol 始终握着方向。真正占上下文的搜索过程和已经说清楚的机械执行，被分到了更合适的位置。

三个最常踩的坑

这套分流最容易在三个地方走样。

**第一个坑，是让 Sol、Terra 和 Luna 同时分析同一个 Bug。**每个子 Agent 都会自己读取上下文、推理、调用工具。三份分析通常只会多出一次汇总和冲突处理，很难带来三倍价值。

**第二个坑，是把所有子 Agent 都开到 max。**Luna 接的是清晰、重复、能验收的工作，medium 通常够用。任务开始需要复杂判断，就应该换路线。继续给执行模型提高推理档位，只会重新做贵。

**第三个坑，是一开始就并行写代码。**搜索、审查、跑不同测试可以并行；几个 Agent 同时修改共享文件，很容易把主线程拖进合并冲突。真要并行修改，就放进不同工作树，合并以后再跑同一套测试。

熔断规则

路由写完，还要加一组熔断规则。

这几条看起来是在让 Agent 停工，实际拦住的是最贵的消耗——沿着错误方向连续做很多轮。

省度的关键

到这里，我们实际上控制住了四个地方：

Fast 的倍率

Sol 读取的上下文

子 Agent 的推理档位

同一项工作被重复执行的次数

虽然 Luna 和 Terra 的降价让分流这件事更划算，但最后能省多少，仍然取决于任务有没有边界、交付物能不能验收，以及失败以后能不能及时停下来。