Codex Sol 可指挥 Luna Max，但配额计算尚未得到证实

Codex Sol 用户正在测试一种新的分工方式：让旗舰模型继续负责全局，再把实施工作交给 Luna Max。该配置使质量与消耗之间形成直接的拉扯。Sol 负责规划与审查，而自定义 Luna 工作代理负责写代码，无需让主线程的每一轮都承担这项工作。

这一思路来自一篇 AYi AI Notes 帖子。帖子提出，在 ~/.codex/agents/ 下创建 luna-worker.toml，选择 gpt-5.6-luna，并将推理强度设为 max。随后，Codex Sol 担任编排器，即负责拆分任务、委派工作并评估返回改动的代理。

这一配置机制真实存在，且已有文档说明。但其所承诺的配额节省和产出翻倍尚未得到独立验证。这一区别很重要，因为 OpenAI 警告，子代理工作流的 token 消耗可能高于可比的单代理运行。最终效果与其说取决于文件名，不如说取决于哪些工作被委派出去。

Codex Sol 模式将判断与实施拆分开来

关键变化并不只是能够使用另一种模型，而是将架构判断与执行分离。

OpenAI 将 Codex 子代理描述为在独立线程中执行指定工作的专用代理。父代理可以生成它们、等待结果、发送后续指令，并将其工作整合为一个响应。

这种结构让 Codex Sol 得以保留那些影响范围广泛的决策。这些决策包括任务拆分、接口设计、依赖选择、验收标准和最终代码审查。Luna 工作代理则接收一个更窄的约定，并在该边界内完成实施。

OpenAI 的子代理文档确认，本地 Codex 客户端支持位于 ~/.codex/agents/ 下的个人代理文件。项目专用定义则可以放在仓库内的 .codex/agents/ 中。

每个独立代理文件必须包含三个字段：

• name，用于标识代理角色

• description，帮助 Codex 判断该角色何时适用

• developer_instructions，定义其工作行为

该文件还可以覆盖常规会话设置，包括 model、model_reasoning_effort、沙盒控制、工具和技能配置。

据报道的配置大致如下：

该示例反映了文档中说明的配置格式。它并未复现原帖作者已验证的文件，因为源材料无法提供其完整指令。

这一区别很重要，因为仅靠选择模型并不能造就可靠的工作代理。描述会影响路由，而开发者指令则定义范围、测试职责和停止条件。模糊的配置可能会让原本专注于实施的代理变成另一个通用对话代理。

该文件也不会自动将每个编程请求都变为 Luna 任务。当前 Codex 版本会在收到直接请求，或适用的项目指令或技能要求委派时，才进行委派。用户仍需要一条路由规则，告诉 Sol 哪些工作属于工作代理。

这条规则可以放在提示词、项目 AGENTS.md 或其他适用的指令层中。一项有用的策略是将架构与审查留给 Sol，再把边界明确的实施单元路由给 Luna。

这一模式挑战了让单一旗舰模型贯穿每个步骤的默认习惯。它将模型能力视作一个组合，而不是单一设置。

为什么 Luna Max 是一种不同寻常的工作代理选择

Luna Max 将面向效率的模型与文档中最高的推理设置结合起来，形成了一场刻意设计的质量与消耗实验。

OpenAI 将 gpt-5.6-sol 定位为适用于高要求工作的旗舰模型。它将 gpt-5.6-terra 描述为能力与效率之间的平衡，而 gpt-5.6-luna 则面向清晰、可重复且高吞吐量的任务。

当 Sol 已经消除了歧义时，这一指引使 Luna 成为合理的实施工作代理。诸如添加带验证的端点、更新组件或实现指定迁移这样的小型任务，比设计其周围系统拥有更清晰的解空间。

Max 推理改变了这一特征。推理强度控制受支持模型可投入多少内部工作来探索和验证答案。OpenAI 表示，更高的设置可以改善复杂工作，但也会增加响应时间和 token 使用量。

该公司的 GPT-5.6 指引建议将 Luna 用于高效、高吞吐量的工作负载，并建议将 max 用于需要更深入探索和验证的高要求任务。

因此，将这两项设置结合起来并不是最显而易见的效率配置。Luna 提供了较低的模型层级，而 Max 则要求该模型进行更深入的思考。这里的押注是：这一组合能保留足够的实施质量，同时无需在每个工作代理回合都为 Sol 级别的判断付费。

当任务拆分已经降低不确定性时，这种方式可能有效。以一个包含十个独立适配器的仓库迁移为例。Sol 可以识别共享接口、定义不变量并指定测试；随后 Luna 工作代理便能针对同一约定实现各个适配器。

当工作代理必须重新发现架构时，经济性就会削弱。如果每个 Luna 代理都要阅读整个仓库、讨论需求、修订计划并反复尝试大范围改动，Max 推理可能会抹去预期的节省。

这一配置也对提示词质量提出了新的要求。使用单一代理的人类可以通过交互解决歧义；而编排器必须在委派之前，将这种歧义转化为边界明确的工作任务。

最好的工作任务会明确具体目标、相关文件、约束条件、测试命令、预期输出以及需要升级处理的条件。它们还会告诉工作代理不要改动什么。

这正是 Codex Sol 在工作流中体现价值的地方。Sol 不应只是转发用户的提示词，而应将请求转化为所有权清晰、完成标准可衡量的实施单元。

对开发者而言，这类似于经验丰富的技术负责人向贡献者分配工作。负责人保护架构并整合结果；贡献者则在既定范围内独立工作。

这一类比也有局限，因为模型不像长期团队成员那样保留组织层面的理解。每个代理仍需要足够的上下文，而每个额外的上下文包都会带来消耗与协调成本。

已经维护可搜索工程知识库的团队在这里更具优势。稳定的规范、架构说明和测试指引能为编排器提供更好的材料，以便分配边界狭窄的任务。

因此，Luna Max 并不是一种通用的低价工作代理。它是一种专用执行配置，其价值会随着任务边界变得更清晰而上升。

真正的对手是单模型编程

核心较量是编排式模型路由，与让每个编程步骤都由一个高能力模型完成之间的对比。

单模型 Codex 会话很容易理解。一个代理探索仓库、提出问题、制定计划、编辑文件、运行测试、诊断失败，并审查自己的工作。

这种连续性具有真实价值。代理可以在同一上下文中保留决策，无需将其总结给另一个线程。小型任务往往能从这种简洁性中受益，因为委派开销会超过实施工作本身。

随着任务扩大，成本开始显现。探索日志、测试输出、被放弃的方法和实施细节，会不断累积在同一段承载需求与架构决策的对话中。

OpenAI 将这些影响称为上下文污染和上下文腐化。随着无关材料填满线程，重要信息会更难被提取。该公司表示，子代理可以通过将嘈杂的工作移出主对话，并返回提炼后的结果来提供帮助。

在拟议的安排中，Codex Sol 成为持久决策的守护者。其线程应包含目标、系统约束、任务图、集成选择、审查发现和最终状态。

Luna 工作代理吸收局部噪声。它们检查相关文件、生成补丁、运行聚焦测试，并返回简洁的回执。它们的原始调查过程无需占据 Sol 的主上下文。

这带来的改善可能不止于配额使用。它还可以降低长篇实施记录将早期需求挤出实际注意范围的风险。编排器看到的是摘要，而不是每一条失败命令。

不过，委派会带来另一种形式的开销。Sol 必须准备工作代理提示词、监控进度、解读结果、检查改动，并且有时需要将任务退回修改。

并行写入还会带来另一个问题。OpenAI 建议从以阅读为主的子代理工作开始，因为同时编辑代码可能产生冲突并提高协调成本。两个代理改动同一个共享模块时，可能会生成各自合理、但组合后失败的补丁。

因此，合理的 Codex Sol 工作流会按所有权拆分工作。一名工作代理可以更新后端处理程序，另一名可以添加隔离测试，第三名可以审查文档。共享类型和核心配置则应由一名负责人维护。

Git worktree 或严格分离的文件可以减少干扰，但无法消除语义冲突。两项改动可能各自都能编译，却对同一约定作出了不兼容的假设。

编排器还必须区分实施与审查。让 Luna 编写代码后再接受自己的结果，会削弱这种分工。Sol 应根据原始任务检查 diff、验证测试，并寻找超出范围的改动。

这一审查角色是让 Sol 保持在顶层的最有力理由。旗舰模型将其能力投入杠杆点，而非重复性的编辑工作。

一个典型流程可分为五个阶段：

1. Sol 调查请求并定义架构边界。

2. Sol 将计划转化为独立、可测试的任务。

3. Luna Max 在独立线程中实施选定任务。

4. Sol 审查返回的 diff、测试证据和未解决风险。

5. Sol 集成已接受的工作，并运行更广泛的验证。

这一流程并不一定更快。当多个任务可独立推进，或实施会产生大量可丢弃的上下文时，它的表现最佳。

对于一个修复显而易见的单文件 bug，父代理很可能在工作代理获得足够上下文之前就已完成。对于涉及独立软件包的广泛功能，编排则更有机会弥补其开销。

因此，正确的比较并不是 Sol 对阵 Luna，而是昂贵的连续线程，对阵一个在不同阶段投入不同类型注意力的层级结构。

产出翻倍的说法仍需要证据

目前没有公开基准证明，这一 Codex Sol 安排能够将配额使用减半或将完成工作翻倍。

原始社交媒体帖子描绘了一个颇具吸引力的结果：节省额度，同时产出两倍工作量。这一说法应被视为个人工作流报告，而非经过测量的产品保证。

OpenAI 明确指出，与可比的单智能体运行相比，子智能体工作流会消耗更多 token。每个子智能体都会独立进行模型和工具调用，而父智能体仍需消耗 token 来创建任务并综合结果。

这一警告并不能证明所报道的配置效率低下。它说明，仅凭使用 Luna 并不能推断效率；较低层级执行能否抵消额外的编排成本，取决于工作负载设计。

评估这一说法至少需要四项指标。

首先，用户需要统计父智能体及每个子智能体的总消耗。只查看 Sol 线程会得出误导性结论，因为工作线程的使用量同样属于该工作流。

其次，他们需要衡量完成任务的质量。如果 Sol 最终必须重写大部分补丁，那么一次更便宜的初稿并不是真的更便宜。返工、测试失败和评审轮次都应纳入计算。

第三，他们需要衡量实际耗时。并行工作线程可以缩短经过时间，却消耗更多总 token。这种取舍仍可能值得，但它并不等于降低配额消耗。

第四，他们需要一个可比的基线。同一组任务应分别通过仅使用 Sol、Sol 搭配 Luna Max，以及或许 Sol 搭配较低推理设置的 Luna 来运行。否则，任务难度本身就可能解释差异。

推理强度尤其值得仔细审视。OpenAI 表示，更高的推理强度会增加 token 使用量和延迟。Max 能改善高难度工作的结果，但若将其用于常规修改，可能会浪费选择 Luna 本可带来的效率优势。

基于任务难度的路由策略，会比一种永久固定的设置更可信。清晰、机械性的变更可以采用较低推理强度，而 Max 则保留给存在复杂边界条件的限定任务。

这一社会层面的说法同样面临运行时验证问题。自定义文件可以指定模型，但开发者应确认被创建的线程实际上获得了请求的角色、模型和推理级别。

这并非理论上的担忧。一份社区 Bug 报告描述称，在多智能体功能持续调整的发布期间，子智能体继承了父智能体的设置。后续回复报告了一些配置层面的变通方法，但运行时行为会因构建版本和工具界面而异。

另一份 Codex issue记录了自定义智能体文件与工具支持会话之间的不匹配。报告称，有效的项目智能体并未通过可用的创建接口暴露出来。

这些报告并不能证明当前的自定义智能体已损坏。OpenAI 当前文档称，智能体文件中的值优先于继承设置。这些报告说明，用户应检查实际的子智能体元数据，而不是仅仅相信配置意图。

可靠的测试应为每项分配记录以下内容：

• 请求的智能体角色

• 解析后的模型

• 解析后的推理强度

• 变更的文件

• 测试命令及结果

• 父智能体评审结果

• 修订轮次

• 所有线程的总使用量

• 端到端耗时

最终比较应使用具有代表性的工作。只包含样板代码的基准会偏向工作模型，而只包含架构不确定性的基准则会偏向 Sol。真实开发同时包含两者。

团队还应纳入失败控制机制。当某项任务需要未提供的架构决策时，工作智能体必须停止。悄然即兴做出这类决策，会带来评审成本和隐藏的不一致性。

最安全的开发者指令不是“无论如何都要完成”，而是“在此边界内实现；当边界不足时进行升级”。

这改变了对生产力的理解。生成更多代码并不自动意味着产出更多。能够通过测试并保持设计意图的已接受变更，才是相关的衡量单位。

在出现受控测量结果之前，“产出翻倍”仍是一项值得验证的假设，而非读者可以直接假定的结论。

Codex Sol 用户接下来应关注什么

三个信号将决定由 Sol 主导、Luna 工作智能体执行的模式，会成为持久工作流，还是仅停留在优化实验阶段。

第一个信号是可验证的模型路由。Codex 客户端需要让用户能够轻松检查解析后的子智能体角色、模型、推理强度和权限模式。

OpenAI 的文档称，在自定义智能体文件中设置的值具有优先级。文档还说明，未指定的设置可以来自显式创建值、[agents] 默认值，或父会话。

这种解析顺序很灵活，但灵活性也可能掩盖错误。要求使用 Luna Max 的开发者，应当能够确认实际使用的是 Luna Max，而无需搜索原始会话日志或逆向分析工具调用。

如果即将发布的 Codex 版本能让这种验证在应用、CLI、IDE 和工具支持会话中保持一致，Sol 主导的模式将更具可信度。如果路由仍依赖于特定客户端行为，所宣称的节省就仍然难以复现。

第二个信号是工作负载层面的测量。用户需要能够在智能体树中归因统计消耗、延迟、重试和已接受产出的仪表盘。

父线程看起来可能很高效，只是因为实现工作被转移到了其他地方。若没有汇总报告，就无法知道委派究竟节省了配额，还是仅仅重新分配了配额消耗。

最有用的指标应将总使用量与已接受任务结合起来。团队随后便可在相同代码库和评估套件上，对比仅使用 Sol 的工作与由 Sol 编排 Luna 的工作。

质量必须与消耗并列可见。若一种工作智能体配置降低了使用量，却让评审时间翻倍，那么它并没有提供明确优势。并行工作流也是如此：即使更快完成，若产生相互冲突的补丁，也不构成优势。

第三个信号是稳定路由惯例的出现。如今，用户可以定义自定义智能体，并指示 Codex 进行委派。更困难的问题是决定何时应当委派。

所报道的配置提供了一条规则：Sol 负责规划和评审，Luna Max 负责实现。这条规则容易记住，但生产团队需要更精确的边界。

成熟的策略可能会将以下任务路由至：

• 架构、模糊的调试问题和集成决策交给 Sol

• 代码库探索和文档扫描交给 Terra

• 范围狭窄的实现、重复性迁移和隔离测试交给 Luna

• 安全敏感或跨领域评审交回 Sol

• 存在冲突或规格不足的任务，在编辑前交回父智能体

这些边界应根据测量结果演进，而不是依据模型品牌。一个在某个代码库表现良好的 Luna 工作智能体，可能会在测试稀少或约定未文档化的另一个代码库中表现不佳。

开发者应从易于验证的任务开始。合适的候选包括隔离的测试补充、基于模式的适配器、机械性的 API 迁移，以及具有明确验收标准的组件。

他们应避免从认证系统重构、缺少回滚方案的数据迁移，或跨越多个共享子系统的变更开始。这些任务会在工作智能体分配中埋入过多隐性判断。

实际的下一步是开展一项受控的内部试验。选择一小组已完成的问题，保留其原始需求，并通过两种工作流分别运行。比较已接受产出、总消耗、经过时间和评审投入。

在试验期间，应保持 luna-worker.toml 配置的范围狭窄。要求提供文件摘要、测试证据和明确的升级说明。让 Codex Sol 按照与基线相同的验收标准评审每一份 diff。

如果工作智能体反复返回干净、边界明确的变更，再逐步扩大其任务范围。如果 Sol 花费大量时间修复问题或重新发现决策，应先改进任务拆分，再更换模型。

Codex Sol 与 Luna Max 的模式指向了 AI 编程一个可信的未来：一个模型不必承担所有角色。然而，编排并非免费的效率层；它用持续上下文交换了路由、验证和协调。

真正有用的问题并不是 Luna 能否写出更多代码，而是 Sol 能否将工作定义得足够清晰，以至于 Luna 编写的代码能通过评审。在真实任务中衡量这一结果，再让证据决定应将多少开发队列委派出去。