Codex 应如何同时选择模型与 Reasoning Effort？
Codex 同时选择模型与 Reasoning Effort 时，应先选择“具备任务所需能力的模型”，再在该模型支持的档位内选择“投入多少推理”。模型决定能力上限、上下文、工具、速度和价格基础；Reasoning Effort 只是在同一模型内调节推理投入。弱模型配最高档不一定等价于强模型配中档，强模型配最低档也不一定适合复杂代理任务。
最可靠的方法是两阶段筛选：先用硬约束淘汰不满足需求的模型，再对少量候选模型分别测试 low、medium、high 等有效档位。一次只改变一个变量，记录任务合格率、总完成时间、token、工具调用和人工返工，最终选择“满足质量门槛且合格任务成本最低”的组合。
模型和 Effort 分别控制什么
| 维度 | 模型选择 | Reasoning Effort |
|---|---|---|
| 核心作用 | 决定基础能力与产品边界 | 调节该模型的推理投入 |
| 上下文窗口 | 由模型决定 | 通常不改变窗口上限 |
| 工具和模态 | 由模型与产品支持决定 | 不能补出缺失工具 |
| 推理深度 | 决定能力基础 | 在支持范围内调节 |
| 延迟和资源 | 决定基础曲线 | 在曲线上继续权衡 |
| 可用档位 | 每个模型不同 | 必须服从模型支持列表 |
如果任务需要图像理解，而候选模型不支持图像输入，把 effort 调到 xhigh 也无法解决。如果任务需要长上下文但模型窗口不足，更高 effort 同样不能恢复被截断的信息。
第一步：写出任务能力清单
在看模型名称和档位之前，先把任务需求分成硬约束与软目标。
硬约束常包括：
- 是否需要文本之外的输入模态；
- 上下文窗口是否能容纳仓库或文档；
- 是否支持 Codex 所需的工具调用；
- 是否允许指定 reasoning effort；
- 是否符合组织的数据驻留和安全政策；
- 是否在目标账户、区域和 provider 中可用。
软目标包括更低延迟、更低成本、更高复杂任务成功率和更稳定的格式。硬约束不满足的模型直接淘汰，不能靠 effort 补偿。
第二步：按任务类型缩小模型候选
高频简单任务
代码查找、格式调整、简单分类、明确命令和机械变换，更看重低延迟与单位成本。可以优先评估速度型或成本型模型，前提是工具与上下文能力足够。
常规开发任务
功能实现、测试补充、常规缺陷修复和中等重构，需要稳定的工具使用、指令遵循和代码理解。平衡型模型通常更适合作为团队默认。
困难代理任务
跨模块迁移、复杂调试、安全审计和长期自主工作，需要更强的推理、工具规划与上下文一致性。应优先选择能力更强的模型，再评估 high 或更高档位是否有额外收益。
这里不宜用固定型号表，因为模型目录会更新。应读取当前 Codex 环境提供的模型描述，再根据任务能力筛选。
第三步：读取模型支持的 Effort
每个模型可用的 reasoning effort 不完全相同。候选集合可能包含 none、minimal、low、medium、high、xhigh 或 max 的一部分。Codex 产品中的 Ultra 还可能带有多代理编排语义，不能当作每个模型的普通下一档。
选择器应以精确模型的 supported reasoning efforts 为准：
candidate_efforts = model.supported_reasoning_efforts
default_effort = model.default_reasoning_effort如果模型没有声明 xhigh，就不要因为另一个模型支持而强行配置。模型切换后必须重新验证旧 effort。
第四步：从模型默认或 medium 建立基线
如果没有历史数据，先使用模型公布的默认 effort。对于常规编码，也可以在支持时以 medium 作为统一基线。基线的作用是测量，而不是宣称 medium 永远最佳。
model = "<candidate-model>"
model_reasoning_effort = "medium"先让候选模型在相同任务集和相同 effort 下比较基础能力。随后固定模型，再改变 effort。这样能区分“模型更强”与“投入更多推理”各自贡献。
不要同时更换模型和档位
从模型 A 的 low 直接切换到模型 B 的 high，即使结果变好，也无法判断原因。可能是模型 B 基础能力更强，也可能只是 high 使用了更多推理，还可能是两者共同作用。
推荐实验顺序：
- 模型 A + medium 与模型 B + medium 比较。
- 选出满足质量门槛的候选模型。
- 固定模型 A，比较 low、medium、high。
- 固定模型 B，比较同样的有效档位。
- 最后比较每个模型的最佳组合。
建立二维候选矩阵
| 组合 | 简单任务 | 常规开发 | 复杂任务 | 延迟 | 合格任务成本 |
|---|---|---|---|---|---|
| 速度型模型 + low | 待测 | 待测 | 待测 | 待测 | 待测 |
| 速度型模型 + medium | 待测 | 待测 | 待测 | 待测 | 待测 |
| 平衡型模型 + low | 待测 | 待测 | 待测 | 待测 | 待测 |
| 平衡型模型 + medium | 待测 | 待测 | 待测 | 待测 | 待测 |
| 强能力模型 + high | 待测 | 待测 | 待测 | 待测 | 待测 |
| 强能力模型 + xhigh | 待测 | 待测 | 待测 | 待测 | 待测 |
只测试实际支持的组合，不需要穷举所有模型与档位。先用能力和预算缩小候选，再运行代表性任务。
简单任务的组合策略
对于可快速自动验收的任务，优先尝试速度型或成本型模型配 low。若一次通过率与平衡模型相同，该组合通常更经济。若出现漏改文件、工具调用不稳定或格式不一致，先提升到 medium，再考虑换模型。
这种顺序能减少变量：同一模型升档后改善，说明推理投入可能不足；升档仍失败，再换更强模型更合理。
常规开发的组合策略
常规开发通常以平衡型模型加 medium 为起点。它应覆盖大多数功能实现、测试和局部重构。出现跨模块依赖、高风险决策或连续失败时，可以先升到 high。
如果同一类任务在 high 仍频繁失败，问题可能是模型基础能力、上下文限制或工具能力不足。此时换更合适的模型比继续提高 effort 更有效。
复杂任务的组合策略
困难调试、架构迁移和安全审计应先确保模型具备足够能力与上下文，再从 high 建立基线。xhigh 或 max 只在当前模型明确支持、延迟可接受，并且评测显示质量继续提升时使用。
强模型配 medium 有时会优于较弱模型配 xhigh，因为模型的知识表示、工具规划和推理效率不同；反过来，某些明确任务可能在较经济模型的 high 上已经达到要求。没有通用换算公式。
“弱模型高档”能替代“强模型低档”吗
不能默认替代。Reasoning Effort 不能改变模型的训练能力、上下文窗口、模态和工具支持。它只让同一模型在可用能力范围内投入更多推理。
两种组合可以通过评测比较，但不能用档位名称直接推导等价关系。即使输出质量相近，延迟、token、工具调用稳定性和长任务一致性也可能不同。
何时应先换模型，而不是升 Effort
- 当前模型缺少必需模态或工具；
- 上下文窗口不足，关键信息被截断；
- high 多次运行仍出现同类能力错误；
- 任务需要的代码语言或领域能力明显不足；
- 模型不支持所需结构化输出或执行方式；
- 更高 effort 的延迟已超过业务上限。
何时应先升 Effort，而不是换模型
- 模型能力与工具满足硬约束；
- 错误主要来自遗漏步骤或推理不充分；
- 任务存在多个约束和方案权衡；
- 当前档位在复杂样本上接近成功；
- 升级成本低于引入新模型的迁移成本。
用 Profile 固化经过验证的组合
对重复工作流，可以为模型与 effort 组合建立独立 profile：
# ~/.codex/quick.config.toml
model = "<fast-model>"
model_reasoning_effort = "low"# ~/.codex/daily.config.toml
model = "<balanced-model>"
model_reasoning_effort = "medium"# ~/.codex/deep.config.toml
model = "<strong-model>"
model_reasoning_effort = "high"模型名称必须使用当前环境真实可用的 ID。不要把示例占位符原样写入配置。选择 profile 后，通过会话状态确认实际模型和 effort。
一次性实验如何执行
命令行覆盖适合临时比较 effort：
codex --config 'model_reasoning_effort="low"'
codex --config 'model_reasoning_effort="medium"'
codex --config 'model_reasoning_effort="high"'切换模型可以使用当前 Codex 版本提供的模型选择入口或配置。实验时应记录精确模型 ID，不要只记显示名。
评测任务集怎么设计
任务集应覆盖真实工作分布：
- 简单查找和机械修改；
- 常规功能实现；
- 有明确复现的缺陷修复；
- 跨模块重构；
- 复杂调试或安全检查；
- 长上下文、多轮工具任务。
每个任务从相同提交开始，使用相同提示、权限和验收命令。每种组合运行多次，减少随机波动。
应该记录哪些指标
- 验收是否通过；
- 自动测试和人工盲审得分；
- 输入、输出与 reasoning token；
- 首次有效动作和总完成时间；
- 工具调用数、失败调用和重试；
- 改动是否越界；
- 人工返工时间。
最终可计算：
合格任务成本 = 该组合总资源消耗 / 通过验收的任务数设置质量门槛再优化成本
模型和 effort 选择是约束优化问题。先设定必须达到的质量门槛，例如关键任务通过率、严重缺陷漏检率和最大人工返工时间。淘汰不达标组合后，再在剩余组合中比较延迟和成本。
如果先按最低 token 选组合，可能得到频繁失败的方案；如果只按最高成功率选组合，可能为微小收益支付巨大延迟。质量门槛能让权衡更清晰。
考虑路由而不是单一全局组合
大型团队通常不需要一个模型与 effort 处理所有任务。可以按任务类型路由：
- 明确、低风险任务：速度型模型 + low；
- 常规开发：平衡型模型 + medium；
- 复杂、高风险任务：强能力模型 + high；
- 极难任务：在评测后使用 xhigh 或 max；
- 可并行的大型任务：单独评估 Codex Ultra 编排。
路由规则应允许任务在发现新风险时升级，也允许根因确认后进入较低档的机械执行。
模型升级后的迁移方法
新模型发布时，不要同时修改模型、effort、提示和工具定义。推荐：
- 固定现有提示和工具。
- 新旧模型使用可比较的基线 effort。
- 运行同一评测集。
- 若质量变化，再单独调整 effort。
- 保存新组合的结果和生效日期。
这样可以区分模型迁移收益与调档收益。
安全和权限不能由模型组合决定
强模型或高 effort 不应自动获得更宽权限。沙箱、审批、网络访问和生产写入是独立安全控制。即使任务使用最高能力组合，也应保持最小权限，并对不可逆操作设置明确审批。
常见错误
按名称猜模型强弱
应查看当前模型说明并用任务集验证，不能只按营销名称排序。
认为档位跨模型等价
不同模型的 medium 不具有统一绝对计算量，也没有可靠的跨模型换算。
只比较一次运行
生成结果和工具时间存在波动，需要重复样本和统一验收。
模型切换后保留无效 effort
每次切换都应重新读取支持列表，避免无效值或静默回退。
所有任务使用最强组合
这会增加延迟和资源，却不保证简单任务质量提升。应按任务路由。
结论
Codex 同时选择模型与 Reasoning Effort 的正确顺序，是先按模态、上下文、工具、安全和可用性筛选模型，再在该模型支持的档位中从默认值或 medium 建立基线。比较时固定一个变量，构建模型与 effort 的二维评测矩阵，并以质量门槛、总完成时间、token 和返工计算合格任务成本。弱模型高档与强模型中低档没有通用等价关系；日常工作应采用经过验证的多组合路由，而不是把所有任务固定到一个“最强”设置。
