7 月 30 日，OpenAI 宣布 GPT-5.6 Luna 的价格下调 80%。现在 API 每百万 tokens 的输入价格是 $0.20，输出价格是 $1.20；Codex 和 ChatGPT Work 的订阅价格、额度预算不变，但 Luna 和 Terra 会消耗更少额度。具体价格和生效时间见 OpenAI 的价格公告，当前单价也可以在 GPT-5.6 Luna 模型页核对。
这次降价让 Luna Max 的定位更实际。Luna 是模型，Max 是推理强度。两者合在一起，在任务边界清楚、结果可以检查的情况下，已经能处理指定文件修改、补测试、固定格式转换和重复迁移这类工作。OpenAI 在公告中给了类似的工作流例子：Sol 处理不确定性、制定计划，Luna 修改代码、编写并运行测试、评估结果。
所以我才开 luna_worker 这个子代理：Sol 保留规划、取舍和最终验收，降价后的 Luna Max 承接已经说清楚的执行任务。
我以前会在 Codex 里选好一个模型和推理强度，然后让它从需求分析一直做到最终检查。任务不大时这样够用，项目一复杂，问题就出来了：做架构判断需要强模型，批量改文件、补测试和整理数据却未必需要同样昂贵的判断能力。
我把模型按职责分开：
Sol：理解需求 → 拆任务 → 定验收标准
↓
Luna Max：完成边界明确的任务 → 自己验证
↓
Sol：检查结果 → 合并修改 → 做最终决定
本文根据 OhMyself 的英文原文 重新整理，并在 2026 年 8 月 2 日核对了 Codex 配置和公开测试数据。
为什么是 Sol 规划、Luna 执行
模型和推理强度是两个不同的选择。模型决定能力、速度和成本的大致区间，model_reasoning_effort 决定这次任务可以使用多少推理预算。
Codex 子代理说明 把三种模型这样区分：GPT-5.6 适合需要规划、工具调用和持续验证的复杂工作；Terra 偏向快速探索和阅读；Luna 适合范围窄、规则清楚、可以重复执行的任务。给 Luna 使用 Max，只是给这个执行模型更多推理预算，模型本身仍然是 Luna。
子代理还可以把搜索输出、编译错误和失败尝试留在独立线程里。主线程只接收结论和验证结果，不会被几千行中间日志淹没。对长任务来说，少一层中间日志，复核结果会更容易。
子代理会单独使用模型和工具，因此总用量会增加。它不是免费算力，也不保证比单代理更省。任务太小、无法并行或无法验证时，派子代理反而多了一层沟通成本。
112 个仓库任务的测试快照
Distributed Radar 提供了一组公开的仓库级任务数据。下面是我在 2026 年 8 月 2 日取到的快照：能力按 112 个任务各自的多数结果统计，时间和费用取每个任务单元格中最新的有效运行记录。
| 配置 | 通过任务 | 通过率 | 平均耗时 | 平均 Token 等价费用 |
|---|---|---|---|---|
| GPT-5.6 Luna Max | 60 / 112 | 53.6% | 32.1 分钟 | $0.46 |
| GPT-5.5 xhigh | 72 / 112 | 64.3% | 23.7 分钟 | $5.82 |
| GPT-5.6 Sol xhigh | 77 / 112 | 68.8% | 25.4 分钟 | $6.48 |
表中的 Luna 费用按 7 月 31 日的公开 token 价格计算，已经使用降价后的 $0.20 / $1.20 输入和输出单价，不是拿旧价格再折算一次。
在这组任务里，Luna Max 的通过率和速度都不是三者最高。它的优势是尝试成本低：平均等价费用比 GPT-5.5 xhigh 低约 92%，比 Sol xhigh 低约 93%。
费用低不等于结果最好。Luna Max 和 GPT-5.5 xhigh 同时通过了 55 项；Luna 单独通过 5 项，GPT-5.5 单独通过 17 项，还有 35 项两者都没通过。把所有任务先交给 Luna、失败后再换 GPT-5.5，至少要满足三个条件：
- 测试或检查能可靠识别失败。
- 任务允许重试，不要求一次成功。
- 更长的串行等待时间可以接受。
按这份快照计算，先跑 Luna、再把 52 个失败项交给 GPT-5.5，平均等价费用约为：
$0.46 + (52 / 112 × $5.82) ≈ $3.16这个数字比所有任务直接使用 GPT-5.5 xhigh 低约 46%，但没有算 Sol 规划和复核的消耗，也没有计算两轮执行带来的等待时间。它只能说明“廉价尝试 + 可靠验收”有可能划算，不能证明混合代理一定能得到更高质量。
公开数据可以从 leaderboard API 和 任务明细 API 复核。榜单会继续变化，本文数字只代表上述日期的快照。
让 Codex 创建 Luna Max 子代理
不用自己找配置目录，也不用手写 TOML。直接把下面这段交给 Codex：
请创建或更新一个名为 luna_worker 的个人自定义 Agent。
要求：
- 保存到 ~/.codex/agents/ 下；
- model 使用 gpt-5.6-luna；
- model_reasoning_effort 使用 max；
- 只接收范围明确、边界清楚、可以独立完成并验证的委派任务；
- 不得修改主任务目标，不得主动扩大范围，不得修改无关文件；
- 遇到歧义或缺少关键决策时，停止并把问题报告给主代理；
- 完成后说明结果、验证方法和仍然存在的限制。
请保留其他 Codex 配置，不要覆盖无关文件。创建后检查当前版本是否支持这些字段，展示准确的文件差异，并验证配置能够正常加载。如果 max 不受当前模型或账号支持，请先告诉我可用的推理强度，不要自行猜测。当前 Codex 允许两种位置：
~/.codex/agents/*.toml：个人配置，在本机不同项目中复用。.codex/agents/*.toml：项目配置，可以跟随仓库一起管理。
自定义 Agent 文件至少要有 name、description 和 developer_instructions。模型与推理强度可以另外设置。不同 Codex 版本和账号可用的推理强度可能不同，所以最好让 Codex 在本机创建并验证，不要把文章里的配置当成固定模板。
正常生成的配置大致会是这样：
name = "luna_worker"
description = "用于范围明确、可独立完成并验证的执行任务。"
model = "gpt-5.6-luna"
model_reasoning_effort = "max"
developer_instructions = """
只处理目标、范围和验收条件明确的委派任务。
不得改变主任务目标、扩大范围或修改无关文件。
遇到歧义、阻塞或范围外决策时，停止并报告主代理。
完成工作后进行必要验证，并返回结果、验证记录和剩余限制。
"""配置格式仍可能变化，文章里的代码只用来帮助你看懂结果，最终以 Codex 对当前安装版本的验证为准。
任务边界决定执行结果
模型配置只是前半段。主代理还要把任务写成一份清楚的执行说明，至少写明五件事：
- 要得到什么结果；
- 哪些文件或目录可以改；
- 哪些条件不能破坏；
- 用什么测试或检查判断完成；
- 返回时要汇报什么。
例如下面这条就适合交给执行型子代理：
使用 luna_worker 为 src/config.test.ts 中的 parseConfig 增加表格驱动测试。
不要修改生产代码，只覆盖文档列出的五种输入。
完成后运行这个测试文件，并返回测试结果以及仍未覆盖的行为。“优化整个配置系统”就不适合。它没有范围，没有验收标准，还要求执行者自己做架构决定。
哪些任务适合交给 Luna
| 适合 Luna 的任务 | 应该留给 Sol 的任务 |
|---|---|
| 指定文件内的机械重构 | 架构和技术选型 |
| 为已知行为补测试 | 含糊的产品需求 |
| 固定格式的数据转换 | 跨项目、难以撤销的修改 |
| 根据指定资料整理文档 | 最终安全审查 |
| 复现一个范围明确的错误 | 需要重新定义目标的工作 |
| 有自动检查的重复迁移 | 最终集成和验收 |
任务越容易自动验证，越适合让便宜的执行模型先试。失败只能靠“看起来差不多”判断的工作，省下来的模型费用很可能会变成人工返工。
并行修改时要划清文件归属
子代理在独立线程里工作，但它们可能共享同一个仓库。两个 Agent 同时改同一份文件，很容易互相覆盖，最后还要花时间处理冲突。
并行任务最好满足两个条件：
- 写入范围互不重叠，例如每个 Agent 负责不同目录。
- 主代理保留集成点，等结果返回后统一检查和合并。
只需要查资料、读大文件或跑测试的任务更适合并行。大量写代码时宁可少开几个，也不要为了看起来快而把协调成本放大。
让项目长期使用这套分工
创建 luna_worker 只是让 Codex 能找到它；需要稳定路由时，要在任务里明确点名：
规划、集成和最终复核由 Sol 完成。
把三个互不依赖的文件转换任务分别交给 luna_worker，
每个任务都写明文件范围和检查方法，验收后再合并。如果一个仓库长期采用这种做法，可以把简短的委派规则写进项目的 AGENTS.md。飞导航的 AGENTS.md 项目说明写法 里介绍了这类规则应该放什么。规则应写清什么任务值得委派、哪些决策由主代理保留，而不是设置成“永远使用 Luna”。
还没用过子代理的话，可以先看 AI Agent 新手入门，分清聊天、Agent 和能实际操作项目的编码代理。想了解不同推理强度怎么测，可以再看 GPT-5.6 Juice 值测试。
Luna 适合的场景很具体：任务边界清楚，结果可以检查，失败后允许重试。把强模型留给判断，把执行模型用于这类任务，再由测试和主代理复核，成本和质量才有机会取得平衡。