文章目录Codex多模型子代理技术解析让Sol指挥Luna Max省额度翻倍产出一、引言二、角色分工为什么 Sol 不该亲自搬每块砖2.1 两种模型两类工作2.2 编排架构三、创建 Luna Worker完整 TOML 配置3.1 个人级自定义 Agent3.2 控制并发数量四、让 Sol 真正完成委托而不是口头分工4.1 推荐主提示词4.2 好任务与坏任务五、典型工作流一项功能如何拆成四条流水线六、额度与产出应该怎样算账6.1 省的是什么6.2 用数据验证“翻倍产出”七、安全、冲突与适用边界7.1 四个常见失败点7.2 不适合委托给 Luna 的任务八、总结Codex多模型子代理技术解析让Sol指挥Luna Max省额度翻倍产出一、引言亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.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 Lunaeffortmax边界明确的实现、补测试、迁移、文档同步、批量分析模糊需求下独立改变架构、未经授权扩展范围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.tomlname 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_workerdescription告诉 Codex 何时适合使用明确、边界清晰的实现任务model固定子代理模型gpt-5.6-lunamodel_reasoning_effort子代理推理强度maxsandbox_mode文件写入边界workspace-writedeveloper_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梳理权限模型、邀请状态、过期策略和公共 API2A. 后端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 输入包含大量搜索、日志、实现细节聚焦需求、摘要和最终 diffSol 输出计划、实现、修复、审查全部承担主要负责计划和审查总 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 官方手册 【Codex多模型子代理技术解析】让Sol指挥Luna Max省额度翻倍产出
文章目录Codex多模型子代理技术解析让Sol指挥Luna Max省额度翻倍产出一、引言二、角色分工为什么 Sol 不该亲自搬每块砖2.1 两种模型两类工作2.2 编排架构三、创建 Luna Worker完整 TOML 配置3.1 个人级自定义 Agent3.2 控制并发数量四、让 Sol 真正完成委托而不是口头分工4.1 推荐主提示词4.2 好任务与坏任务五、典型工作流一项功能如何拆成四条流水线六、额度与产出应该怎样算账6.1 省的是什么6.2 用数据验证“翻倍产出”七、安全、冲突与适用边界7.1 四个常见失败点7.2 不适合委托给 Luna 的任务八、总结Codex多模型子代理技术解析让Sol指挥Luna Max省额度翻倍产出一、引言亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.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 Lunaeffortmax边界明确的实现、补测试、迁移、文档同步、批量分析模糊需求下独立改变架构、未经授权扩展范围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.tomlname 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_workerdescription告诉 Codex 何时适合使用明确、边界清晰的实现任务model固定子代理模型gpt-5.6-lunamodel_reasoning_effort子代理推理强度maxsandbox_mode文件写入边界workspace-writedeveloper_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梳理权限模型、邀请状态、过期策略和公共 API2A. 后端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 输入包含大量搜索、日志、实现细节聚焦需求、摘要和最终 diffSol 输出计划、实现、修复、审查全部承担主要负责计划和审查总 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 官方手册