### [Codex省钱配置教程：Sol负责规划，Luna执行与Review，一次配置降低Agent成本](https://www.zuoshipin.com/article/24255)

**Published:** 2026-08-24T06:34:05

**Author:** 天才交易员

**Excerpt:** Codex成本优化完整教程：用GPT-5.6 Sol负责规划，用Luna承担Review和子Agent执行，并…

**先说结论：**Codex 降低成本的关键，不是把所有任务都换成最便宜的模型，而是让高能力模型负责需求理解、规划和复杂决策，让成本更低、速度更快的模型承担高频执行、子 Agent 与代码审查。当前 Codex 已提供主模型、`review_model` 和默认子 Agent 模型等配置字段，一次设置后即可长期复用。

Codex 的站内介绍与官方入口：[Codex – AI 编程智能体](https://www.zuoshipin.com/link/1474.html)。本文以 GPT-5.6 Sol 与 GPT-5.6 Luna 为示例；实际可用模型、费用和额度取决于账号、套餐与所用 Provider。

![Codex省钱配置教程配图 1](https://admin.zuoshipin.com/wp-content/uploads/2026/08/codex-cost-saving-cover.png)

Codex 成本优化的核心：规划、执行、审查按能力分工

## 一、为什么“全程使用最强模型”容易浪费预算？

一项看似简单的 Codex 任务，通常包含多个难度不同的阶段：

1.  **主对话与规划：**理解目标、读取上下文、拆分任务、选择实现路线并协调执行。
2.  **子 Agent 执行：**修改文件、补代码、跑测试、搜索资料或完成一个边界清晰的子任务。
3.  **Review：**通过 `/review` 检查代码差异、发现风险并提出修改建议。
4.  **Compact：**上下文过长时进行压缩，保留继续工作需要的信息。

这些阶段对推理能力的要求不同。如果每一步都使用最昂贵的模型，就相当于让高级架构师长期承担机械修改和重复检查。真正有效的优化，是把预算集中在方向判断和复杂取舍上。

![Codex省钱配置教程配图 2](https://admin.zuoshipin.com/wp-content/uploads/2026/08/codex-task-model-routing.png)

从任务输入到主模型、子Agent、Review和Compact的工作链路

## 二、当前推荐的模型分工

| 环节  | 示例模型 | 推荐理由 |
| --- | --- | --- |
| 主对话 | GPT-5.6 Sol | 适合复杂推理、规划与编码决策 |
| /review | GPT-5.6 Luna | 边界明确、调用频率较高 |
| 默认子 Agent | GPT-5.6 Luna | 适合成本敏感、高并发执行 |
| Compact | 随当前实现与主会话 | 当前没有独立的 compact 模型配置项 |

这不是固定答案。若任务涉及架构重构、安全审计、复杂并发或模糊需求，子 Agent 和 Review 也可能需要更强模型。正确方法是先设一个默认分工，再根据任务风险显式升级。

![Codex省钱配置教程配图 3](https://admin.zuoshipin.com/wp-content/uploads/2026/08/codex-model-role-table.png)

不同工作环节的模型选择与作用

## 三、最简单的配置：一个 config.toml 完成主模型、Review和子Agent分工

用户级配置文件位置：

-   **macOS / Linux：**`~/.codex/config.toml`
-   **Windows：**`C:Users<用户名>.codexconfig.toml`

推荐先使用当前官方字段完成最小配置：

```toml
model = "gpt-5.6-sol"
model_reasoning_effort = "high"
review_model = "gpt-5.6-luna"

[agents]
default_subagent_model = "gpt-5.6-luna"
default_subagent_reasoning_effort = "medium"
```

这几项分别控制：

-   `model`：新会话默认主模型。
-   `model_reasoning_effort`：主模型推理强度，复杂任务可设为 `high`。
-   `review_model`：执行 `/review` 时使用的模型；它不是所有“审查类提示词”的全局自动路由。
-   `agents.default_subagent_model`：未显式指定模型时，子 Agent 默认使用的模型。
-   `agents.default_subagent_reasoning_effort`：未显式覆盖时，子 Agent 的默认推理强度。

> **重要修正：**只在 `~/.codex/agents/` 新建一个 `worker.toml`，并不会自动让所有子 Agent 使用它。最省事的方法是使用上面的 `agents.default_subagent_model`；需要自定义角色时，再在主配置中声明角色和配置文件。

## 四、自定义 worker 角色：需要在主配置里显式声明

如果希望让 Codex 在分工时看到一个名为 worker 的专用角色，可在主 `config.toml` 中增加：

```toml
[agents.worker]
description = "负责边界清晰的代码修改、文件处理和测试执行"
config_file = "agents/worker.toml"
```

然后创建 `~/.codex/agents/worker.toml`：

```toml
model = "gpt-5.6-luna"
model_reasoning_effort = "medium"
```

`config_file` 的相对路径以声明角色的配置文件所在目录为基准。若在一次 spawn 中显式指定模型或推理强度，该次显式设置会优先于默认值。

## 五、如何验证配置真的生效？

1.  保存配置后重新启动 Codex，或至少新建一个任务。
2.  在设置或任务信息中确认主模型是预期值。
3.  执行一次 `/review`，确认审查环节使用了配置的 Review 模型。
4.  创建一个边界清晰的子任务，检查子 Agent 的模型与推理强度。
5.  使用同一测试任务对比修改前后的质量、耗时、Token或积分消耗。

不要只看总成本。建议同时记录首次通过率、返工次数、测试失败数和交付时间。若省下 30% 调用成本，却增加大量人工返工，整体并没有真正降本。

## 六、第三方 Provider 如何沿用同一思路？

Codex 支持自定义模型 Provider，但当前协议字段 `wire_api` 只支持 `responses`。第三方服务必须兼容 Responses API，并以服务商实际提供的模型名、专属 API Key 和 Base URL 为准。

```toml
model = "<Provider中的强模型>"
review_model = "<Provider中的轻量模型>"
model_provider = "my-provider"

[agents]
default_subagent_model = "<Provider中的轻量模型>"
default_subagent_reasoning_effort = "medium"

[model_providers.my-provider]
name = "my-provider"
base_url = "https://example.com/api/v1"
env_key = "MY_PROVIDER_API_KEY"
wire_api = "responses"
```

第三方模型通常继承当前会话的 Provider，因此主模型、Review 和子 Agent 的模型名都应当是该 Provider 可识别的名称。国内 Provider 的套餐、专属密钥和端点可能随产品更新变化，不要照抄旧截图；可结合站内 [火山方舟相关模型入口](https://www.zuoshipin.com/link/23249.html)核对当前产品信息。

> **密钥安全：**只在系统环境变量中保存 API Key，不要把真实密钥直接写进 `config.toml`、仓库、截图或教程。Provider 配置使用 `env_key`引用环境变量名。

## 七、进一步省钱的 7 个实用策略

1.  **默认轻量、按风险升级：**子 Agent 默认用 Luna，遇到复杂重构再显式切换。
2.  **降低清晰任务的推理强度：**机械修改可尝试 `low` 或 `medium`，不要所有调用都设为 `high`。
3.  **先缩小任务边界：**明确文件、交付物与验收标准，减少模型探索无关目录。
4.  **避免重复传入大文件：**只提供相关片段，长项目使用项目说明与稳定文档沉淀背景。
5.  **把测试命令写清楚：**让子 Agent 一次完成修改和验证，减少反复来回。
6.  **Review 聚焦高风险差异：**明确安全、并发、数据迁移或兼容性关注点，避免泛泛审查。
7.  **建立自己的成本基准：**用固定任务每周比较质量、时间和消耗，模型升级后重新测。

## 八、哪些情况下不应该为了省钱降模型？

-   需求本身模糊，需要大量澄清和架构判断；
-   涉及支付、权限、加密、隐私或安全边界；
-   跨多个系统的数据迁移和不可逆操作；
-   难以复现的并发、性能或生产故障；
-   代码审查结果将直接作为发布门禁。

这些任务的错误成本往往高于模型成本。可以继续让轻量模型负责资料整理与测试执行，但最终规划、关键修改和审批应交给更强模型并保留人工复核。

## 九、推荐的落地顺序

1.  先只配置 `review_model`，观察 Review 质量和消耗。
2.  再配置默认子 Agent 模型，用 3-5 个真实任务验证。
3.  确认稳定后，才建立 worker、researcher 等自定义角色。
4.  最后接入第三方 Provider，并单独验证模型名、工具调用、流式响应和错误处理。

**一句话总结：**让 Sol 负责想清楚，让 Luna 负责高频执行与常规审查；按任务风险升级，而不是让最贵模型包办所有工作。

## 常见问题

### review\_model 会自动接管所有代码审查吗？

不会。当前配置说明表明它是 `/review` 的模型覆盖项；普通对话中要求“帮我审查代码”仍可能由当前会话模型执行。

### 只创建 worker.toml 就能让子 Agent 自动使用吗？

不能保证。建议使用 `agents.default_subagent_model`设置默认模型；自定义角色还应通过 `agents.<name>.config_file`显式声明。

### Compact 可以单独指定便宜模型吗？

当前公开配置参考中没有独立的 Compact 模型字段，因此不要假设可以单独切换。

### 第三方 Provider 一定能接入 Codex 吗？

不一定。它需要提供兼容的 Responses API、正确的模型名和认证方式，工具调用与推理元数据也要逐项测试。

### 使用 Luna 一定比 Sol 省钱吗？

官方将 Luna 定位为成本敏感、高吞吐场景，通常更适合高频执行；但最终成本仍取决于套餐、Provider、输入输出量、返工次数和实际定价。

**Categories:** AI资讯

---