Codex 的额度消耗有多快用过的朋友应该都有体会。跑一个稍微复杂点的任务上下文来回拉扯几千 token 就没了要是让模型在几个文件之间反复试探、改错再改那个消耗速度基本等于在烧钱。我一开始也是老老实实把所有任务都丢给同一个强模型处理直到某天跑了几个小时的批量重构看了一眼额度统计心态直接崩了。后来我琢磨出一套方案把 Codex 的使用拆成两个角色——让一个擅长推理、规划能力强的模型当“总指挥”负责理解需求、拆解任务、定好技术方案再让一个轻量、便宜的模型当“执行者”只按既定方案快速处理批量文件。说白了就是把“想”和“做”分离。这套方案我跑了小半年省额度的效果非常明显而且整个配置过程不复杂我今天把完整思路和配置都整理出来。1. 为什么 Codex 跑批量任务这么烧额度先说个扎心的事实Codex 这类的编程智能体费用大头从来不是“生成代码”本身而是“上下文反复传递”。它的工作方式是先把你的仓库摘要、文件内容、历史消息全部塞进上下文然后模型基于整段上下文做出判断生成一段修改。如果任务中途出现理解偏差它会在错误的代码基础上继续推演每一次纠错都要重新读取相关文件、重新推理这些 token 都在重复计费。我做过一次不太严谨的统计用强模型跑一个涉及 20 个文件的批量改动大概消耗了相当于直接对话方式写同样代码 5 倍左右的 token。原因很简单——每次修改一个文件智能体都要把相关依赖文件重新读一遍如果文件之间还有相互引用那读取的规模还会膨胀。批量任务的文件数量一上去这种膨胀是指数级的。具体来说Codex 跑批量任务时有几个消耗大户仓库扫描与文件读取每轮操作都要读取当前文件、相关文件这部分 token 非常可观长上下文保留为了让模型记住前面的决策所有历史消息默认都保留在上下文里越往后越长失败重试改错、报错、再改每一轮失败都在支付完整的推理成本多文件联动改 A 文件时要看 B 文件、C 文件跨文件的理解成本比想象中高得多所以省额度的关键路径其实很清楚要么减少每一轮的 token 消耗要么减少轮数。我后来采用的“Astra 规划 Luna 执行”的组合本质上是同时压这两条线。2. Astra 与 Luna 分工把“想”和“做”分离在介绍配置之前我先说清楚概念。Astra 和 Luna 并不是某个官方出品的神秘模型代号而是我在 Codex 里定义的两个角色配置Astra 角色使用当前可用能力最强的推理模型比如你账号下最贵的旗舰级模型只做规划和拆解任务不做批量代码修改。Luna 角色使用轻量、便宜的模型一般是支持代码生成的低价型号只做执行严格按照方案改代码。为什么要这样设计我拿现实中的团队协作来类比你不会让架构师去改每一个文件的命名和格式也不会让实习生去做系统架构设计。架构师只出蓝图然后由执行者照着蓝图干活效率最高、返工最少。Codex 的使用也是一样的道理。这里必须说一个很多人忽略的点规划任务和执行任务对模型能力的要求完全不同。规划任务需要强大的语义理解、全局推理和决策能力这种任务适合用最好的模型执行任务则更像是“照着说明文档改代码”——只要方案清晰一个普通模型完全能胜任而且它的 token 单价低、速度快批量跑起来也不心疼。实际操作中我会先让 Astra 把需求吃透输出一份足够细的“作战计划”哪些文件要改、每个文件怎么改、改动的风险点是什么、依赖关系是什么。然后切换到 Luna把我刚写好的计划方案直接贴在会话里让它逐文件处理。这里有一个经验之谈方案写得越细Luna 跑得越顺返工越少。如果方案模糊Luna 也会像强模型一样在错误的路线上来回试探那额度照样保不住。所以 Astra 阶段的产出质量直接决定了整个方案的省额度效果。3. 完整配置config.toml 双 Profile 方案搞清楚了设计思路接下来就是落地。Codex CLI 的配置核心是一个config.toml文件默认路径是~/.codex/config.toml支持定义多个 profile每个 profile 可以绑定不同的模型、不同的 temperature、不同的沙箱模式。我就用这这个机制实现 Astra 和 Luna 的分工。先看我的配置文件# ~/.codex/config.toml # 默认配置日常小需求直接用默认不折腾 model gpt-5-codex # Astra 角色总指挥负责规划、拆解、方案设计 [profiles.astra] model gpt-5-codex # 你账号下最强的推理模型 temperature 0.2 # 偏低温度减少发散 experimental_skip_sop false # 保持标准操作流程 sandbox_mode workspace-write # 规划阶段不需要太多写权限 # Luna 角色批量执行按方案干活 [profiles.luna] model gpt-5.1-codex-mini # 轻量、便宜、快的模型 temperature 0.1 # 更低的温度输出更稳定 experimental_skip_sop true # 跳过繁琐的流程说明直接干 sandbox_mode workspace-write [history] # 默认保留 200 条会话记录规划阶段足够用了简单解释一下配置里的几个关键点model 字段Codex 支持按 profile 绑定不同模型。Astra 用你账号下最强的模型这样它做规划时推理质量最高Luna 用便宜的低端模型执行时间复杂度低、单价低。这里我用了更具象的写法实际你配置的时候换成你账号里可用的模型 ID 就行——具体哪些模型可用取决于你的 Codex 版本和服务商。如果你接的是第三方兼容接口同理Astra 指向强模型、Luna 指向弱模型即可。temperature 设置Astra 的 temperature 我设成 0.2让它兼顾一点探索性而不是死板地只按字面理解Luna 则设成 0.1更低随机性、更稳定的输出。执行任务最怕模型自由发挥所以温度越低调越可靠。experimental_skip_sop这个参数很有意思。Codex 默认有一套标准操作流程SOP会让模型先思考、再计划、再执行——这对复杂任务很有用但对简单批量执行来说反而是多余的 token 开销。Luna 我直接跳过 SOP让它少说废话、多干活Astra 保留 SOP因为规划阶段需要完整思考链路。配置好之后日常使用就变成两个命令切换# 规划用 Astra 拆解任务输出方案 codex exec --profile astra 分析 src/ 目录把数据库查询统一改成参数化查询输出改造方案 # 执行切换到 Luna按方案批量处理 codex exec --profile luna 按照刚才的方案逐个修改 src/ 目录下的文件如果你习惯用交互式界面也可以进入 Codex TUI 后在输入框里用/profile astra或/profile luna动态切换不用重新起进程。4. 让整套方案跑起来的完整工作流配置只是第一步真正值钱的是怎么把两个角色串成一条高效流水线。我实际跑过很多次之后总结了一套固定的流程照着走基本不会翻车。4.1 第一步Astra 输出结构化方案这一阶段的目标是产出一份 Luna 看了不用动脑子就能执行的方案。所以我通常会在提示词里明确要求输出格式请对 src/ 目录做一次代码审计目标是把所有数据库操作改成参数化查询。 输出一份改造方案要求包含 1. 涉及文件清单按依赖顺序排列 2. 每个文件的改动点描述 3. 需要特别关注的边界情况 4. 改动之间的依赖关系注意这里我刻意要求 Astra“不要直接改代码”而是“输出方案”。因为你一旦让强模型直接动手它就会进入“边读边改”的模式token 消耗立刻起飞。方案输出阶段我一般限制它只读代码、不写文件这样上下文比较小而且它的思考会更聚焦。Astra 输出的方案我建议让它存成一个文件比如refactor-plan.md后面 Luna 直接读这个文件作为依据。好处是Luna 不需要重新理解需求只需要打开方案、按列表逐项执行。这里有一个判断标准如果你发现 Luna 在执行时频繁问你“这个需求不明确”“这个地方怎么改”说明 Astra 的方案拆得不够细。合格的方案应该像一个精确到步骤的施工图而不是一段泛泛而谈的“注意安全”。4.2 第二步启动 Luna 批量执行方案文件就位后切换到 Luna让它读取方案并按顺序执行请阅读 refactor-plan.md然后按照方案中的文件清单和改动点逐个文件完成修改。 每完成一个文件简要说明你改了什么。 如果遇到方案中未覆盖的情况不要自行决定记录下来并跳过。最后一句话非常关键要求 Luna 遇到不确定的情况“跳过而不是猜测”。这点在省额度上极其重要——一个便宜的模型一旦开始猜测它就会反复试错而每一次试错都在消耗 token。宁可让某个文件没改、后面人工补也不能让它在错误的路上打转。Luna 的批量执行能力其实很强。因为它没有复杂的推理负担上下文里只需要保留“方案 当前文件内容”就够了不需要像强模型那样把所有相关文件全载入。实际跑起来修改单个文件的 token 消耗会大幅下降。4.3 第三步Astra 做最终 Review批量执行完之后别急着收工。我会再切回 Astra让它做一次轻量 reviewLuna 已经按 refactor-plan.md 完成了修改。 请对改动做一次 review重点检查 1. 是否有遗漏的文件或遗漏的改动点 2. 是否有逻辑错误或风格不一致 3. 是否引入了新的问题 输出一份问题清单没有就直接说通过。这一步同样是用强模型但它的上下文只包含“改了什么 当前状态”不需要重读整个仓库token 消耗相比“边想边写”要小得多。更重要的是它能兜住 Luna 可能犯的低级错误。我有几次跳过 review结果 Luna 改了查询方式却忘了改调用处的传参类型等到测试跑挂了才发现回头再修反而更费额度。4.4 完整命令串示例如果你喜欢用脚本把这套流程串成一次执行可以参考这样的命令结构# 1. Astra 规划 codex exec --profile astra \ 分析 src/输出参数化查询改造方案保存到 refactor-plan.md # 2. Luna 执行 codex exec --profile luna \ 阅读 refactor-plan.md按方案完成所有文件修改 # 3. Astra review codex exec --profile astra \ review 刚才的改动输出问题清单当然真正实践里我不会把三段一次性跑完通常会在第一步和第二步之间人工过目一下方案。毕竟 Astra 的方案也偶有离谱的时候方案错了执行得越彻底返工成本越高。5. 额度消耗实测双模式到底省了多少说多少理论都不如看真实数据。我在几个中规模项目上做过对比测试项目情况大概是20 到 30 个源文件涉及批量重构、接口迁移、日志规范统一这类场景。我统计了“全程用强模型”和“Astra 规划 Luna 执行”两种模式的 token 消耗。先说结论双模式组合大约能省 60% 到 70% 的 token。具体拆开看是这样的数据基于我当时使用的模型计费标准数值供参考不同模型比例略有差异环节全强模型模式token双模式token任务理解与规划约 8 万Astra 规划约 3 万批量执行约 22 万Luna 执行约 5 万返工与纠错约 6 万Astra review 少量返工约 1.5 万合计约 36 万约 9.5 万粗看可能会觉得迷惑Astra 规划时的 token 并不少为什么总量能省这么多关键在于Luna 执行阶段的单价和上下文开销都远低于强模型。强模型在执行阶段因为要维护全局理解上下文里会堆积大量仓库信息而 Luna 是“拿到明确指令就改”上下文里只需要当前文件和方案片段这个差异在批量任务中会被放大。还有一个隐藏的省钱点低模型几乎不会返工。因为方案足够细、指令足够明确Luna 的每一次操作都是有效的。而强模型在“边想边写”模式下经常因为需求理解偏差出现先写后改的情况每改一次都相当于额外付一次全量推理费用。我建议你也做一个小实验挑一个改动量适中的任务分别用两种模式跑一次对比一下 token 记录。不用看绝对数值看比例就会明白为什么我这么推崇双模式。6. 避坑清单这套方案最容易翻车的几个细节配置和使用层面讲了不少最后说几个我踩过的坑给准备尝试的朋友提个醒。6.1 Astra 规划阶段的上下文控制Astra 规划时如果让它“把整个项目都看完再给方案”token 消耗会非常夸张。我的经验是规划之前先想清楚边界只让它看相关模块的代码而不是全仓库扫描。你可以通过把范围写明确来实现比如“只看src/controllers/和src/services/”而不是“分析整个项目”。另外如果某个项目的仓库很大上千个文件建议先用rg、grep这类工具缩小范围再丢给 Astra。6.2 Luna 被模糊指令卡住的处理Luna 便宜但便宜也有代价——它对模糊指令的容错率很低。如果方案里出现“优化一下”“改进一点”这种描述它大概率会自由发挥然后产出不符合预期的结果。我有一次让 Luna“优化一下所有的 import 排序”它把整个项目的 import 全部重排了顺带改了一些不该动的引用关系导致 review 阶段花了不少 token 修。后来我的方案里从不写模糊动词全是“将import块中未使用的依赖删除”“按isort默认配置重新排序”这种精确指令。如果有些任务实在没法写精确我就留着人工处理不塞给 Luna。6.3 Review 阶段的边界把握Astra review 不是万能的。它只能发现代码层面的逻辑问题和方案偏差发现不了“需求本身是不是合理”这种问题。所以我觉得 review 阶段更适合配合测试一起做让 Luna 改完代码后先跑一遍测试再把失败信息丢给 Astra 分析。这样既能减少 review 的上下文消耗又比让 Astra 从头读一遍代码更有效。另外review 阶段不要反复多轮。一般来说一轮 review 就够了如果有问题把问题清单打回去让 Luna 修而不是让 Astra 直接改。一旦让 Astra 介入修改它又会进入“边想边写”的高消耗模式省额度的意义就没了。6.4 关于切换频率和会话管理频繁在 Astra 和 Luna 之间切换会增加一些额外开销因为新会话要重新加载项目上下文。我建议按任务块来切而不是按文件切。比如“这 10 个文件交给 Luna 跑完整体切回 Astra review”不要改 1 个文件切一次。这个原则在跑大项目时感受很明显——切得越频繁上下文重建的浪费越严重。还有一个容易被忽略的点Codex 的历史会话文件会持续累积。如果发现 Codex TUI 启动变慢或者某些命令响应变卡通常就是历史记录太多了。我会定期清理~/.codex/history/下的旧会话文件保留最近两周的即可既省空间又能避免某些情况下上下文干扰。写在最后我把这套 Astra 当总指挥、Luna 批量干活的模式用在了日常几乎所有 Codex 任务上小到改 bug大到跨模块重构都是同一套流程强模型出方案、轻量模型执行、强模型复查。省下来的额度和时间非常可观更重要的是它让我不再焦虑“跑一个任务要烧多少钱”批量任务也敢随手交给 Codex 做了。最后再分享一个小技巧如果你发现方案中某些模式反复出现比如“把所有硬编码字符串抽成常量”可以把它沉淀到 AGENTS.md 里这样 Astra 规划时会更贴合项目上下文Luna 执行时也更少出现意外。配置这东西越用越顺手关键是迈出第一步。 
长河君 · 2026/9/17 3:15:17 · 阅读 1.2k Codex省额度实战：Astra规划+Luna执行双角色配置，批量任务Token消耗直降60%
Codex 的额度消耗有多快用过的朋友应该都有体会。跑一个稍微复杂点的任务上下文来回拉扯几千 token 就没了要是让模型在几个文件之间反复试探、改错再改那个消耗速度基本等于在烧钱。我一开始也是老老实实把所有任务都丢给同一个强模型处理直到某天跑了几个小时的批量重构看了一眼额度统计心态直接崩了。后来我琢磨出一套方案把 Codex 的使用拆成两个角色——让一个擅长推理、规划能力强的模型当“总指挥”负责理解需求、拆解任务、定好技术方案再让一个轻量、便宜的模型当“执行者”只按既定方案快速处理批量文件。说白了就是把“想”和“做”分离。这套方案我跑了小半年省额度的效果非常明显而且整个配置过程不复杂我今天把完整思路和配置都整理出来。1. 为什么 Codex 跑批量任务这么烧额度先说个扎心的事实Codex 这类的编程智能体费用大头从来不是“生成代码”本身而是“上下文反复传递”。它的工作方式是先把你的仓库摘要、文件内容、历史消息全部塞进上下文然后模型基于整段上下文做出判断生成一段修改。如果任务中途出现理解偏差它会在错误的代码基础上继续推演每一次纠错都要重新读取相关文件、重新推理这些 token 都在重复计费。我做过一次不太严谨的统计用强模型跑一个涉及 20 个文件的批量改动大概消耗了相当于直接对话方式写同样代码 5 倍左右的 token。原因很简单——每次修改一个文件智能体都要把相关依赖文件重新读一遍如果文件之间还有相互引用那读取的规模还会膨胀。批量任务的文件数量一上去这种膨胀是指数级的。具体来说Codex 跑批量任务时有几个消耗大户仓库扫描与文件读取每轮操作都要读取当前文件、相关文件这部分 token 非常可观长上下文保留为了让模型记住前面的决策所有历史消息默认都保留在上下文里越往后越长失败重试改错、报错、再改每一轮失败都在支付完整的推理成本多文件联动改 A 文件时要看 B 文件、C 文件跨文件的理解成本比想象中高得多所以省额度的关键路径其实很清楚要么减少每一轮的 token 消耗要么减少轮数。我后来采用的“Astra 规划 Luna 执行”的组合本质上是同时压这两条线。2. Astra 与 Luna 分工把“想”和“做”分离在介绍配置之前我先说清楚概念。Astra 和 Luna 并不是某个官方出品的神秘模型代号而是我在 Codex 里定义的两个角色配置Astra 角色使用当前可用能力最强的推理模型比如你账号下最贵的旗舰级模型只做规划和拆解任务不做批量代码修改。Luna 角色使用轻量、便宜的模型一般是支持代码生成的低价型号只做执行严格按照方案改代码。为什么要这样设计我拿现实中的团队协作来类比你不会让架构师去改每一个文件的命名和格式也不会让实习生去做系统架构设计。架构师只出蓝图然后由执行者照着蓝图干活效率最高、返工最少。Codex 的使用也是一样的道理。这里必须说一个很多人忽略的点规划任务和执行任务对模型能力的要求完全不同。规划任务需要强大的语义理解、全局推理和决策能力这种任务适合用最好的模型执行任务则更像是“照着说明文档改代码”——只要方案清晰一个普通模型完全能胜任而且它的 token 单价低、速度快批量跑起来也不心疼。实际操作中我会先让 Astra 把需求吃透输出一份足够细的“作战计划”哪些文件要改、每个文件怎么改、改动的风险点是什么、依赖关系是什么。然后切换到 Luna把我刚写好的计划方案直接贴在会话里让它逐文件处理。这里有一个经验之谈方案写得越细Luna 跑得越顺返工越少。如果方案模糊Luna 也会像强模型一样在错误的路线上来回试探那额度照样保不住。所以 Astra 阶段的产出质量直接决定了整个方案的省额度效果。3. 完整配置config.toml 双 Profile 方案搞清楚了设计思路接下来就是落地。Codex CLI 的配置核心是一个config.toml文件默认路径是~/.codex/config.toml支持定义多个 profile每个 profile 可以绑定不同的模型、不同的 temperature、不同的沙箱模式。我就用这这个机制实现 Astra 和 Luna 的分工。先看我的配置文件# ~/.codex/config.toml # 默认配置日常小需求直接用默认不折腾 model gpt-5-codex # Astra 角色总指挥负责规划、拆解、方案设计 [profiles.astra] model gpt-5-codex # 你账号下最强的推理模型 temperature 0.2 # 偏低温度减少发散 experimental_skip_sop false # 保持标准操作流程 sandbox_mode workspace-write # 规划阶段不需要太多写权限 # Luna 角色批量执行按方案干活 [profiles.luna] model gpt-5.1-codex-mini # 轻量、便宜、快的模型 temperature 0.1 # 更低的温度输出更稳定 experimental_skip_sop true # 跳过繁琐的流程说明直接干 sandbox_mode workspace-write [history] # 默认保留 200 条会话记录规划阶段足够用了简单解释一下配置里的几个关键点model 字段Codex 支持按 profile 绑定不同模型。Astra 用你账号下最强的模型这样它做规划时推理质量最高Luna 用便宜的低端模型执行时间复杂度低、单价低。这里我用了更具象的写法实际你配置的时候换成你账号里可用的模型 ID 就行——具体哪些模型可用取决于你的 Codex 版本和服务商。如果你接的是第三方兼容接口同理Astra 指向强模型、Luna 指向弱模型即可。temperature 设置Astra 的 temperature 我设成 0.2让它兼顾一点探索性而不是死板地只按字面理解Luna 则设成 0.1更低随机性、更稳定的输出。执行任务最怕模型自由发挥所以温度越低调越可靠。experimental_skip_sop这个参数很有意思。Codex 默认有一套标准操作流程SOP会让模型先思考、再计划、再执行——这对复杂任务很有用但对简单批量执行来说反而是多余的 token 开销。Luna 我直接跳过 SOP让它少说废话、多干活Astra 保留 SOP因为规划阶段需要完整思考链路。配置好之后日常使用就变成两个命令切换# 规划用 Astra 拆解任务输出方案 codex exec --profile astra 分析 src/ 目录把数据库查询统一改成参数化查询输出改造方案 # 执行切换到 Luna按方案批量处理 codex exec --profile luna 按照刚才的方案逐个修改 src/ 目录下的文件如果你习惯用交互式界面也可以进入 Codex TUI 后在输入框里用/profile astra或/profile luna动态切换不用重新起进程。4. 让整套方案跑起来的完整工作流配置只是第一步真正值钱的是怎么把两个角色串成一条高效流水线。我实际跑过很多次之后总结了一套固定的流程照着走基本不会翻车。4.1 第一步Astra 输出结构化方案这一阶段的目标是产出一份 Luna 看了不用动脑子就能执行的方案。所以我通常会在提示词里明确要求输出格式请对 src/ 目录做一次代码审计目标是把所有数据库操作改成参数化查询。 输出一份改造方案要求包含 1. 涉及文件清单按依赖顺序排列 2. 每个文件的改动点描述 3. 需要特别关注的边界情况 4. 改动之间的依赖关系注意这里我刻意要求 Astra“不要直接改代码”而是“输出方案”。因为你一旦让强模型直接动手它就会进入“边读边改”的模式token 消耗立刻起飞。方案输出阶段我一般限制它只读代码、不写文件这样上下文比较小而且它的思考会更聚焦。Astra 输出的方案我建议让它存成一个文件比如refactor-plan.md后面 Luna 直接读这个文件作为依据。好处是Luna 不需要重新理解需求只需要打开方案、按列表逐项执行。这里有一个判断标准如果你发现 Luna 在执行时频繁问你“这个需求不明确”“这个地方怎么改”说明 Astra 的方案拆得不够细。合格的方案应该像一个精确到步骤的施工图而不是一段泛泛而谈的“注意安全”。4.2 第二步启动 Luna 批量执行方案文件就位后切换到 Luna让它读取方案并按顺序执行请阅读 refactor-plan.md然后按照方案中的文件清单和改动点逐个文件完成修改。 每完成一个文件简要说明你改了什么。 如果遇到方案中未覆盖的情况不要自行决定记录下来并跳过。最后一句话非常关键要求 Luna 遇到不确定的情况“跳过而不是猜测”。这点在省额度上极其重要——一个便宜的模型一旦开始猜测它就会反复试错而每一次试错都在消耗 token。宁可让某个文件没改、后面人工补也不能让它在错误的路上打转。Luna 的批量执行能力其实很强。因为它没有复杂的推理负担上下文里只需要保留“方案 当前文件内容”就够了不需要像强模型那样把所有相关文件全载入。实际跑起来修改单个文件的 token 消耗会大幅下降。4.3 第三步Astra 做最终 Review批量执行完之后别急着收工。我会再切回 Astra让它做一次轻量 reviewLuna 已经按 refactor-plan.md 完成了修改。 请对改动做一次 review重点检查 1. 是否有遗漏的文件或遗漏的改动点 2. 是否有逻辑错误或风格不一致 3. 是否引入了新的问题 输出一份问题清单没有就直接说通过。这一步同样是用强模型但它的上下文只包含“改了什么 当前状态”不需要重读整个仓库token 消耗相比“边想边写”要小得多。更重要的是它能兜住 Luna 可能犯的低级错误。我有几次跳过 review结果 Luna 改了查询方式却忘了改调用处的传参类型等到测试跑挂了才发现回头再修反而更费额度。4.4 完整命令串示例如果你喜欢用脚本把这套流程串成一次执行可以参考这样的命令结构# 1. Astra 规划 codex exec --profile astra \ 分析 src/输出参数化查询改造方案保存到 refactor-plan.md # 2. Luna 执行 codex exec --profile luna \ 阅读 refactor-plan.md按方案完成所有文件修改 # 3. Astra review codex exec --profile astra \ review 刚才的改动输出问题清单当然真正实践里我不会把三段一次性跑完通常会在第一步和第二步之间人工过目一下方案。毕竟 Astra 的方案也偶有离谱的时候方案错了执行得越彻底返工成本越高。5. 额度消耗实测双模式到底省了多少说多少理论都不如看真实数据。我在几个中规模项目上做过对比测试项目情况大概是20 到 30 个源文件涉及批量重构、接口迁移、日志规范统一这类场景。我统计了“全程用强模型”和“Astra 规划 Luna 执行”两种模式的 token 消耗。先说结论双模式组合大约能省 60% 到 70% 的 token。具体拆开看是这样的数据基于我当时使用的模型计费标准数值供参考不同模型比例略有差异环节全强模型模式token双模式token任务理解与规划约 8 万Astra 规划约 3 万批量执行约 22 万Luna 执行约 5 万返工与纠错约 6 万Astra review 少量返工约 1.5 万合计约 36 万约 9.5 万粗看可能会觉得迷惑Astra 规划时的 token 并不少为什么总量能省这么多关键在于Luna 执行阶段的单价和上下文开销都远低于强模型。强模型在执行阶段因为要维护全局理解上下文里会堆积大量仓库信息而 Luna 是“拿到明确指令就改”上下文里只需要当前文件和方案片段这个差异在批量任务中会被放大。还有一个隐藏的省钱点低模型几乎不会返工。因为方案足够细、指令足够明确Luna 的每一次操作都是有效的。而强模型在“边想边写”模式下经常因为需求理解偏差出现先写后改的情况每改一次都相当于额外付一次全量推理费用。我建议你也做一个小实验挑一个改动量适中的任务分别用两种模式跑一次对比一下 token 记录。不用看绝对数值看比例就会明白为什么我这么推崇双模式。6. 避坑清单这套方案最容易翻车的几个细节配置和使用层面讲了不少最后说几个我踩过的坑给准备尝试的朋友提个醒。6.1 Astra 规划阶段的上下文控制Astra 规划时如果让它“把整个项目都看完再给方案”token 消耗会非常夸张。我的经验是规划之前先想清楚边界只让它看相关模块的代码而不是全仓库扫描。你可以通过把范围写明确来实现比如“只看src/controllers/和src/services/”而不是“分析整个项目”。另外如果某个项目的仓库很大上千个文件建议先用rg、grep这类工具缩小范围再丢给 Astra。6.2 Luna 被模糊指令卡住的处理Luna 便宜但便宜也有代价——它对模糊指令的容错率很低。如果方案里出现“优化一下”“改进一点”这种描述它大概率会自由发挥然后产出不符合预期的结果。我有一次让 Luna“优化一下所有的 import 排序”它把整个项目的 import 全部重排了顺带改了一些不该动的引用关系导致 review 阶段花了不少 token 修。后来我的方案里从不写模糊动词全是“将import块中未使用的依赖删除”“按isort默认配置重新排序”这种精确指令。如果有些任务实在没法写精确我就留着人工处理不塞给 Luna。6.3 Review 阶段的边界把握Astra review 不是万能的。它只能发现代码层面的逻辑问题和方案偏差发现不了“需求本身是不是合理”这种问题。所以我觉得 review 阶段更适合配合测试一起做让 Luna 改完代码后先跑一遍测试再把失败信息丢给 Astra 分析。这样既能减少 review 的上下文消耗又比让 Astra 从头读一遍代码更有效。另外review 阶段不要反复多轮。一般来说一轮 review 就够了如果有问题把问题清单打回去让 Luna 修而不是让 Astra 直接改。一旦让 Astra 介入修改它又会进入“边想边写”的高消耗模式省额度的意义就没了。6.4 关于切换频率和会话管理频繁在 Astra 和 Luna 之间切换会增加一些额外开销因为新会话要重新加载项目上下文。我建议按任务块来切而不是按文件切。比如“这 10 个文件交给 Luna 跑完整体切回 Astra review”不要改 1 个文件切一次。这个原则在跑大项目时感受很明显——切得越频繁上下文重建的浪费越严重。还有一个容易被忽略的点Codex 的历史会话文件会持续累积。如果发现 Codex TUI 启动变慢或者某些命令响应变卡通常就是历史记录太多了。我会定期清理~/.codex/history/下的旧会话文件保留最近两周的即可既省空间又能避免某些情况下上下文干扰。写在最后我把这套 Astra 当总指挥、Luna 批量干活的模式用在了日常几乎所有 Codex 任务上小到改 bug大到跨模块重构都是同一套流程强模型出方案、轻量模型执行、强模型复查。省下来的额度和时间非常可观更重要的是它让我不再焦虑“跑一个任务要烧多少钱”批量任务也敢随手交给 Codex 做了。最后再分享一个小技巧如果你发现方案中某些模式反复出现比如“把所有硬编码字符串抽成常量”可以把它沉淀到 AGENTS.md 里这样 Astra 规划时会更贴合项目上下文Luna 执行时也更少出现意外。配置这东西越用越顺手关键是迈出第一步。