Codex 子 Agent 分工实战：Sol 当军师、Luna 当搬砖工，单任务成本压到 $0.61
先看一组反常识的数据：在 DeepSWE（软件工程能力评测）排行榜上，gpt-5.6-luna 以 $0.61 的单任务成本登顶榜单 ，而 Claude Opus 5、GPT-5.6 这些更贵的模型，花了数倍成本，得分反而不如它。贵的模型不是不能打，是用错了地方------让高级架构师去搬砖，不是不行，是太贵了。
这几天 Twitter 上疯传的 Codex 子 Agent 方案，本质就一句话：让贵模型只做规划和决策，把执行类的脏活扔给便宜模型并行干。 有人算过账，ChatGPT Plus 套餐用这个方案，能跑出 Pro 套餐 20 倍的效果。我照着配了一版，顺手把它迁移到了自己的内容流水线上，这篇把配置步骤、坑和迁移思路一起给你。
为什么你的额度总是不够用
结论先行：额度不够用不是用量问题，是两个结构性问题------贵的模型干了太多脏活，加上长对话在"慢性中毒"。
痛点一：所有活都让 Sol 干，等于让架构师搬砖
用过 Codex 的人都知道，GPT-5.6（Sol）推理确实强，但账单真的顶不住。一个稍微复杂点的开发任务跑下来，额度肉眼可见往下掉。面对大量任务开发时，Sol 的额度根本不够用------还没干到一半，额度就见了底。
而便宜的模型真的不能打吗？DeepSWE 的数据已经回答了：在大量执行类任务上，Luna 的性价比碾压所有对手------花着十分之一的钱，干着一样甚至更好的活。
痛点二：Context Rot（上下文腐烂），长对话在偷偷降智
当你把所有东西塞进一个对话------需求讨论、代码探索、测试日志、报错堆栈------模型的有效注意力会被逐渐稀释，开始忘记之前的约定、重复犯错、幻觉越来越严重。
OpenAI 官方把这种现象叫 Context Rot（上下文腐烂）：
Context pollution : useful information gets buried under noisy intermediate output. Context rot: performance degrades as the chat fills up with less relevant details.
（污染：有用信息被噪声中间输出埋掉；腐烂：对话塞满无关细节后，性能持续下降。）
关键句：你在一个越来越乱的桌子上办公，重要文件被埋在废纸下面------模型也一样，塞得越多，忘得越多。
核心思路：大脑负责想，手脚负责干
结论先行：主 Agent 是大脑，子 Agent 是手脚；大脑不干体力活，手脚不做重大决策。
分工模式一句话：Sol（GPT-5.6）留在主线程当军师，负责方案设计；Luna（GPT-5.6-luna）配置成子 Agent 当搬砖工，负责并行执行。
| 角色 | 模型 | 干什么 | 代价 |
|---|---|---|---|
| 军师（主 Agent） | gpt-5.6 | 拆解需求、定方案、整合汇报 | 贵，但只碰关键决策 |
| 搬砖工（子 Agent） | gpt-5.6-luna | 探索代码、跑测试、做总结、改小 bug | $0.61/任务，可并行 |
为什么这么配能省钱？因为 LLM 的成本大头不在"思考"，在"token 量"。 把探索、测试这种高 token 低判断的活挪给便宜模型，贵模型只保留在小 token 高判断的规划环节，账单自然就下来了。
三步配好你的首个子 Agent
结论先行：配置不用写代码，一个 TOML 文件 + 一句调用，5 分钟跑通。
步骤一：打开 Max 推理强度
进入 Codex 的 Settings → Configuration → Available reasoning efforts，勾选 Max 。不打开这个选项，后面配置 model_reasoning_effort = "max" 不会生效。
步骤二：创建子 Agent 配置文件
在 Codex 对话中直接输入这段提示词，它会自动创建文件：
text
请在 ~/.codex/agents/luna-worker.toml 创建一个全局自定义子代理。
配置要求：
- 代理名称：luna_worker
- 模型：gpt-5.6-luna
- 推理强度：max
- 定位：快速完成边界明确、可重复的小型任务
- 工作方式：严格遵守任务范围，独立执行，在可行时验证结果，并简洁汇报结果、相关文件路径和注意事项执行后你会得到类似这样的文件（路径：~/.codex/agents/luna-worker.toml）：
toml
name = "luna_worker"
description = "Fast worker for clear, narrowly scoped, and repeatable tasks."
developer_instructions = """
Handle the assigned task strictly within its stated scope.
Work independently and use appropriate tools when needed.
Verify the result when practical.
Do not make unrelated changes.
Return a concise summary containing the result, relevant file paths, verification performed, and any important caveats.
"""
model = "gpt-5.6-luna"
model_reasoning_effort = "max"步骤三：开始使用
以后在 Codex 对话中这样调用：
text
请使用 luna_worker 子代理完成以下任务：检查 src/ 目录下所有 TypeScript 文件的 import 是否有循环依赖。等待子代理完成后，汇总结果。Sol 收到指令 → 派 Luna 去干活 → Luna 干完回来汇报 → Sol 整合后给你最终答案。 全程你只看到 Sol 的最终回复，脏活都在后台并行跑完。
进阶：组建你的 Agent 团队
结论先行：不止一个子 Agent------你可以配多个不同职责的 Agent，像团队一样并行协作，各自独立上下文互不干扰。
官方文档里的"代码审查三人组"：
| Agent | 模型 | 职责 | 沙箱 |
|---|---|---|---|
| pr_explorer（代码探索者） | gpt-5.6-luna / medium | 只读追踪真实执行路径，先取证再提改动 | read-only |
| reviewer（代码审查员） | gpt-5.6-terra / high | 优先找正确性、安全、行为回归、缺测试 | read-only |
| docs_researcher（文档研究员） | gpt-5.6-luna / medium | 用 docs MCP 核实 API 和框架行为 | read-only |
三个 Agent 并行，最后主 Agent 汇总。前端调试场景同理：一个 Agent 用浏览器复现 bug、一个只读追踪代码路径、最后一个在问题明确后做最小修复------特别适合排查 UI 回归和跨组件交互 bug。
模型和推理强度怎么选：一张速查表
结论先行：省钱技巧是------大部分执行类子 Agent 用 luna + medium 就够，只有深度推理的审查类任务才上 high / max。
| 场景 | 模型 | 推理强度 |
|---|---|---|
| 探索代码、跑测试、总结 | gpt-5.6-luna | medium |
| 写代码、做具体修复 | gpt-5.6-luna | max |
| 代码审查、方案设计 | gpt-5.6-terra | high |
| 主 Agent 最终决策 | gpt-5.6 | max |
5 条实操避坑
结论先行：子 Agent 不是银弹，用错场景反而更贵。这 5 条是从官方文档和实测里压出来的。
- 子 Agent 适合"读多写少"：最适合探索、测试、总结这类只读任务；多个 Agent 同时改代码容易冲突。
- 好的子 Agent 是"窄而偏执"的：每个只做一件事，指令写得越具体越好。别让它"顺便看看其他地方有没有问题"------它会跑偏。
- 子 Agent 消耗更多 Token：每个有独立上下文和工具调用，token 比单 Agent 高；但复杂任务的质量提升值得这个成本。
- 沙箱权限要控死 ：只读的子 Agent 设
sandbox_mode = "read-only"，只有明确需要写权限的才给workspace-write。 - 用
/agent管理线程：CLI 里可以查看和切换活跃的子 Agent 线程，实时看它们干到哪了。
落到你自己的流水线：内容生产怎么套
结论先行：这套"贵模型规划、便宜模型执行"的路由逻辑，不止 Codex 能用------你的内容流水线、多平台运营工作流同样适用。
我在自己的公众号/掘金/知乎内容流水线上做了三处迁移：
- 写稿用强模型，填表格用轻模型：选题钩子、标题这种"高判断"环节走强模型；结构化环节（拼 YAML、填表格、格式转换）走便宜模型------这就是我在 Harness 里写的"模型路由服从回归、不服从价格表"。
- 把长任务拆成短上下文：以前一个对话从选题聊到配图，后来发现越往后越"不在状态"------这就是 Context Rot。现在每步独立上下文，选题一个任务、写稿一个任务、配图一个任务，各自状态干净。
- 子 Agent 的 TOML 就是 Skill 的雏形 ：
name + description + developer_instructions这套结构，和你把工作流封装成 Skill 是一个思路------先定义职责边界，再定义执行纪律，最后绑定模型。
Context Rot 值得每个搭流水线的人记住：对话越长，越要警惕"它看起来在正常工作"。 如果发现 Agent 开始重复犯错、忘记约定，先别怪它，先检查你的上下文是不是塞太满了。
总结
核心心智模型就一句话：主 Agent 是大脑，子 Agent 是手脚。大脑不要干体力活。
贵模型负责想，便宜模型负责干，短上下文防止降智------这套组合拳不挑工具，Codex 能用，你的 WorkBuddy 工作台能用，任何 LLM 应用都能用。
你平时怎么处理"长对话越聊越蠢"的问题？是硬着头皮继续，还是果断开新会话？评论区聊聊你的 Context Rot 经历。下一篇准备写《Agent 工具失控实录：一条 SQL 锁库 4 小时、一次回调触发越权打款》，讲 Agent 权限治理的底线设计，敬请关注。