文章目录
- Codex多模型子代理技术解析：让Sol指挥Luna Max省额度翻倍产出
- 一、引言
- 二、角色分工：为什么 Sol 不该亲自搬每块砖
- 2.1 两种模型，两类工作
- 2.2 编排架构
- 三、创建 Luna Worker：完整 TOML 配置
- 3.1 个人级自定义 Agent
- 3.2 控制并发数量
- 四、让 Sol 真正完成委托，而不是口头分工
- 4.1 推荐主提示词
- 4.2 好任务与坏任务
- 五、典型工作流：一项功能如何拆成四条流水线
- 六、额度与产出：应该怎样算账
- 6.1 省的是什么
- 6.2 用数据验证“翻倍产出”
- 七、安全、冲突与适用边界
- 7.1 四个常见失败点
- 7.2 不适合委托给 Luna 的任务
- 八、总结
Codex多模型子代理技术解析：让Sol指挥Luna Max省额度翻倍产出
一、引言
亲爱的朋友们，创作不容易，若对您有帮助的话，请点赞收藏加关注哦，您的关注是我持续创作的动力，谢谢大家！有问题请私信或联系邮箱：jasonai.fn@gmail.com
高阶 Codex 工作流的核心，不是让最强模型包办每一行代码，而是把它放在最有价值的位置：让 GPT-5.6 Sol 负责理解需求、拆解任务、控制边界和审查结果，让 GPT-5.6 Luna Max 承担清晰、重复、实现量大的执行工作。
这很像一个技术负责人带执行工程师。Sol 的昂贵推理用在架构选择和最终判断上，Luna 的高吞吐用在搜索、改代码、补测试和整理文档上。配置得当时，主模型上下文更干净，独立任务还能并行推进。
“省额度翻倍产出”应被理解为一种可测量的工程目标，而不是平台保证：它可能减少 Sol 的稀缺额度占用并缩短墙钟时间，但多 Agent 会增加总 Token、协调和复核成本。真正有效的优化对象是单位合格交付物消耗的 Sol 额度，而不是追求子 Agent 数量。
二、角色分工：为什么 Sol 不该亲自搬每块砖
2.1 两种模型，两类工作
| 角色 | 模型 | 最适合的任务 | 不应承担的任务 |
|---|---|---|---|
| 主代理/负责人 | GPT-5.6 Sol | 澄清需求、架构决策、任务拆分、风险判断、代码审查、最终验收 | 大量机械搜索、逐文件改名、重复实现 |
| 执行子代理 | GPT-5.6 Luna，effort=max | 边界明确的实现、补测试、迁移、文档同步、批量分析 | 模糊需求下独立改变架构、未经授权扩展范围 |
Codex 官方手册把gpt-5.6-luna定位为适合快速、范围窄、清晰、可重复或高吞吐的 Agent。把 reasoning effort 提到max，并不会把 Luna 变成 Sol，而是让它在执行明确任务时更充分地检查边界、错误路径和验证结果。
2.2 编排架构
用户目标 │ ▼ Sol 主代理 需求澄清 · 架构 · 拆分 · 风险 · 验收 │ ├── Luna Worker A：实现后端改动 ├── Luna Worker B：补充测试 ├── Luna Worker C：更新文档/迁移脚本 │ ▼ Sol 汇总代码差异 审查冲突 · 运行关键测试 · 检查越界 · 最终交付这套结构有两个收益。第一，探索日志、测试输出和机械实现细节留在子线程，不会持续污染主线程上下文。第二，互不依赖的任务可以并行，整体耗时取决于最慢分支，而不是所有分支耗时之和。
三、创建 Luna Worker：完整 TOML 配置
3.1 个人级自定义 Agent
在~/.codex/agents/下创建luna-worker.toml：
name = "luna_worker" description = "Implementation-focused worker for clear, bounded coding tasks delegated by the lead agent." model = "gpt-5.6-luna" model_reasoning_effort = "max" sandbox_mode = "workspace-write" developer_instructions = """ Act as an implementation worker, not the project lead. Work only on the bounded task delegated by the parent agent. Read the relevant code and local instructions before editing. Preserve existing architecture and conventions unless the task explicitly requires a change. Make the smallest defensible patch, add focused tests, and run relevant verification. Do not broaden scope, change public contracts, or perform destructive operations without returning to the parent. Return a concise summary with changed files, test results, assumptions, and unresolved risks. """三个字段不可省略：name、description和developer_instructions。文件名只是约定，Codex 真正使用name识别 Agent。model_reasoning_effort才是官方配置键，不是reasoning_effort。
| 配置项 | 作用 | 本方案选择 |
|---|---|---|
name | 主代理委托时引用的名称 | luna_worker |
description | 告诉 Codex 何时适合使用 | 明确、边界清晰的实现任务 |
model | 固定子代理模型 | gpt-5.6-luna |
model_reasoning_effort | 子代理推理强度 | max |
sandbox_mode | 文件写入边界 | workspace-write |
developer_instructions | 执行纪律和回传格式 | 小改动、先验证、不扩范围 |
如果团队成员都要使用，应改放到项目内的.codex/agents/luna-worker.toml，并随仓库版本管理。个人目录适合个人默认，项目目录适合团队一致性；未受信任项目会跳过项目级.codex/配置。
3.2 控制并发数量
可在~/.codex/config.toml或项目.codex/config.toml中设置：
[agents] enabled = true max_concurrent_threads_per_session = 4不建议一开始就把并发开到最大。对于共享工作区，两个 Agent 同时修改同一文件，很容易产生覆盖和语义冲突。先从 2 到 4 个线程开始，并把写任务按目录、模块或职责分开。
四、让 Sol 真正完成委托，而不是口头分工
4.1 推荐主提示词
你是本任务的技术负责人。先阅读仓库约束并制定可验收计划。 把边界明确、实现量大的独立任务委托给 luna_worker； 你保留需求解释、架构决策、跨模块协调、安全判断和最终代码审查。 要求： 1. 写任务按文件或模块隔离，避免多个子代理修改同一区域； 2. 每个子任务必须包含输入、禁止事项、验收标准和测试命令； 3. 等待所有必要子代理返回后，检查 diff 和测试证据； 4. 不直接接受“已完成”的文字结论，必须复核关键行为； 5. 最后汇总 Sol 与 Luna 的职责、变更文件、测试结果和残余风险。在 Codex CLI 中可以使用/agent查看和切换子线程；App 与 IDE 会在支持的界面中显示后台 Agent。当前 Codex 版本要求用户直接提出委托，或由适用的AGENTS.md、Skill 指令明确要求多 Agent 工作。
4.2 好任务与坏任务
| 委托质量 | 示例 | 结果 |
|---|---|---|
| 差 | “把这个项目做好” | Luna 必须重新做需求和架构判断，分工失效 |
| 差 | “修复所有问题” | 范围无限，容易越界 |
| 好 | “只修改billing/，为退款状态机增加幂等检查，并运行指定测试” | 边界与验收清晰 |
| 好 | “读取接口定义，补充三类错误路径测试，不修改生产代码” | 适合独立并行 |
| 好 | “按既有模式迁移这 12 个调用点，返回未能机械迁移的例外” | 高吞吐且可复核 |
一个合格子任务至少包含：目标、可修改范围、不可修改范围、输入资料、测试命令、完成标准和回传格式。
五、典型工作流：一项功能如何拆成四条流水线
假设要给现有 SaaS 增加团队邀请功能：
| 阶段 | 负责人 | 工作内容 |
|---|---|---|
| 1. 设计 | Sol | 梳理权限模型、邀请状态、过期策略和公共 API |
| 2A. 后端 | Luna A | 实现邀请实体、服务与接口，限定后端目录 |
| 2B. 测试 | Luna B | 基于设计补权限、过期、重复接受测试 |
| 2C. 文档 | Luna C | 更新 API 文档、迁移说明与配置样例 |
| 3. 集成 | Sol | 检查接口一致性、解决冲突、补跨模块问题 |
| 4. 验收 | Sol | 运行关键测试、审查权限绕过与回归风险 |
Sol 输出设计契约 ├── Luna A 写实现 ──┐ ├── Luna B 写测试 ──┼──> Sol 统一审查与集成 └── Luna C 写文档 ──┘如果 B 的测试必须等待 A 的实现，就不要伪装成并行任务。可以先让 B 根据契约设计测试清单，再在 A 完成后触发第二轮落地。多 Agent 的速度来自真实独立性，不是把依赖关系藏起来。
六、额度与产出：应该怎样算账
6.1 省的是什么
| 指标 | 单 Sol 模式 | Sol + Luna 模式 |
|---|---|---|
| Sol 输入 | 包含大量搜索、日志、实现细节 | 聚焦需求、摘要和最终 diff |
| Sol 输出 | 计划、实现、修复、审查全部承担 | 主要负责计划和审查 |
| 总 Token | 通常较低 | 通常更高，因为子线程各自读取上下文 |
| 墙钟时间 | 串行 | 独立任务可并行 |
| 上下文噪声 | 容易累积 | 中间噪声留在子线程 |
| 协调成本 | 低 | 需要任务契约和复核 |
因此，这套方案不是“免费算力技巧”。它把成本结构从“高价值模型做所有事情”，改为“高价值模型做高价值判断，快速模型批量执行”。
6.2 用数据验证“翻倍产出”
连续记录 10 到 20 个相似任务：
单位合格产出成本 = Sol 消耗额度 / 通过验收的交付物数量 一次通过率 = 无需返工的子任务数 / 子任务总数 并行收益 = 串行预计耗时 / 实际墙钟时间 返工率 = 被 Sol 退回的子任务数 / 子任务总数如果 Sol 额度下降 40%，交付量增加 60%，但 Luna 返工率达到 50%，说明任务切分或 Agent 指令有问题。只有在质量门槛不下降时，吞吐提升才有意义。
七、安全、冲突与适用边界
7.1 四个常见失败点
| 失败点 | 表现 | 修复方式 |
|---|---|---|
| 任务过大 | Luna 自行改变架构或公共接口 | 缩小到单模块、单契约 |
| 写入冲突 | 多个 Agent 同改一个文件 | 按目录隔离，或改为串行 |
| 验证不足 | 子代理只说“测试通过” | 要求返回命令与关键结果，Sol 重跑核心测试 |
| 权限过宽 | 执行任务触及密钥、数据库或部署 | 使用沙盒、最小权限和人工审批 |
子代理继承父线程当前的权限模式与运行时覆盖。即使 Agent 文件配置了不同默认值，父线程交互中选择的沙盒和审批策略仍会重新应用。不要把自定义 Agent 当成绕过权限的入口。
7.2 不适合委托给 Luna 的任务
- 需求仍在变化，需要频繁与用户权衡；
- 跨多个核心模块的大型架构改造；
- 生产数据删除、基础设施变更和安全响应；
- 无法自动验证、错误代价很高的业务决策；
- 主代理自己都无法写出明确验收标准的任务。
这些工作更适合由 Sol 保持主导，必要时让 Luna 做只读探索或准备证据。
八、总结
| 维度 | 核心要点 |
|---|---|
| 角色设计 | Sol 做决策与审查，Luna Max 做清晰、重复、实现量大的任务 |
| 配置关键 | 自定义 Agent 放在~/.codex/agents/，使用model_reasoning_effort = "max" |
| 效率来源 | 减少 Sol 机械劳动、隔离上下文噪声、并行独立任务 |
| 成本真相 | 可能节省 Sol 额度，但总 Token 往往增加 |
| 质量门槛 | 子代理产出必须由 Sol 检查 diff、测试与边界 |
Codex 多模型编排的高阶玩法，不是让 Sol“少干活”，而是让它只做最难替代的工作。当任务能够被写成清晰契约，Luna Max 就是一支高吞吐执行队；当需求仍然模糊，Sol 就必须留在驾驶位。所谓翻倍产出，最终要用通过验收的交付物和 Sol 额度账单来证明。
参考资料：
- Subagents — Codex / ChatGPT Work 官方手册
- Configuration Reference — Codex 官方手册
- Config basics — Codex 官方手册
