Codex 思考等级与实际表现的权衡（medium 未必输 high）

给 Codex 选择思考等级时，直觉常常是：任务重要就开 high，算力更多总不会错。但在真实仓库里，交付质量不只由“想得够不够久”决定，还受上下文质量、任务边界、测试反馈、工具权限和停止条件影响。high 可能解决更难的推理，也可能在简单任务上扩大搜索范围、增加无效修改和等待时间。

因此，正确问题不是“哪个档位最强”，而是“同一类任务在哪个档位的端到端通过率最好，代价又是多少”。medium 未必输 high，不是说它在所有题上能力相同，而是很多工程任务的瓶颈根本不在额外推理。

一、思考等级控制的是预算，不是质量承诺

OpenAI 官方模型指南把 reasoning effort 描述为质量、延迟与成本之间的可调旋钮，并建议以 medium 作为平衡起点，只在评测证明有可衡量收益时提高到 high 或更高。官方也明确提醒，更高思考等级不会自动带来更好结果；指令冲突、停止条件薄弱或工具范围过宽时，额外推理反而可能产生过度搜索和质量回退。具体支持档位会随模型而异，应以所选模型的官方模型指南为准。

这意味着 high 解决的是“任务需要更多推理预算”的问题，不会自动修复缺失的依赖、错误的需求、不可运行的测试或模糊的验收标准。若 Agent 读错目标，多想几轮可能只是把错误方案做得更完整。

二、为什么 medium 会在常见任务中打平

很多日常开发任务具有短反馈闭环：修改一个组件、运行测试、根据报错再修正。只要 medium 能做出合理的首次假设，测试工具就会提供比内部继续猜测更高质量的新证据。此时多一次真实验证，往往比更长的预先推理更有价值。

任务特征	medium 可能已足够	high 可能更有价值
修改范围	单文件或边界清楚	跨模块、影响链不明显
验收方式	有快速、确定的测试	缺少测试，需要综合判断
约束数量	少量且无冲突	多来源约束需要权衡
失败成本	可安全重试	一次错误会造成较大返工
搜索空间	入口和目标明确	根因未知、候选路径很多

另一个原因是停止行为。medium 更可能在达到验收标准后结束；high 若没有明确 stop rule，可能继续重构、补文档或搜索边缘情况。改动越多，潜在回归面也越大。这里比较的是整次任务结果，不是某段代码看起来是否更聪明。

三、不要用一次任务得出档位结论

同一 Prompt 的 Agent 轨迹会受工具返回、仓库状态与生成波动影响。拿一次 medium 成功和一次 high 失败做截图，只能说明两个个例。评测至少应固定仓库 commit、任务描述、可用工具、超时、网络条件和测试命令，并为每个任务重复运行。

任务集要来自自己的真实工作：小型 bug、跨文件功能、日志诊断、受约束重构和测试补全都应覆盖。公开编程榜单只能说明一般能力，无法代表你的 monorepo、内部框架和 CI。建立题集的方法可参考 AI 编程 Agent 内部基准设计与 LLM 评测 Golden Set 构建方法。

评测时不要让一个档位继承另一个档位产生的文件或缓存；每次运行都从相同快照开始。否则后跑的配置会得到额外上下文，比较天然不公平。

四、同时记录成功、时间与改动风险

只统计“测试是否通过”会漏掉很多工程代价。一次任务至少记录以下字段：

{
  "task_id": "bug-017",
  "effort": "medium",
  "tests_passed": true,
  "wall_time_seconds": 184,
  "tool_calls": 12,
  "files_changed": 3,
  "review_findings": 0,
  "required_human_fix": false
}

核心指标可以分四组：完成率衡量是否达到验收；首次通过率衡量是否靠反复试错；墙钟时间和用量衡量资源；越界文件、无关重构与 reviewer finding 衡量风险。high 即使多解决一道难题，如果在大量简单题上显著增加时延和审查负担，也未必适合作为全局默认值。

不要自行假设“high 一定多耗多少倍”。推理消耗与延迟取决于模型、任务和工具循环，必须记录真实运行数据。评测采样和尾部分析思路也可参考采样参数对输出分布的实际影响。

五、按失败类型判断是否值得升档

medium 失败后，不应无条件改成 high 重跑。先给失败归因：若因为漏掉跨模块约束、错误地简化多步逻辑或无法在多个方案间取舍，提高思考等级有合理依据；若因为权限不足、依赖不可用、测试本身损坏或输入缺少关键信息，升档不会补齐外部证据。

还要区分“推理不足”和“执行纪律不足”。Agent 已经找到根因却没有跑测试，应该加强验收与停止规则；反复打开无关文件，应该缩小工具与路径范围；修改正确但输出格式不合规，应该使用结构化约束。把所有失败都归因于模型档位，会掩盖运行框架的问题。

六、采用默认 medium、证据触发升档

实用策略是先按任务类型设默认值，再提供有限的升级条件。低风险、边界清晰且有强测试的任务默认 medium；架构迁移、复杂并发 bug、跨系统数据一致性和高约束规划可直接进入 high。对于介于两者之间的任务，medium 失败且失败类型属于推理不足时，才允许 high 重试一次。

升档必须沿用同一验收标准，不能因为 high 花费更高就放宽评价。生产系统还应设置最大工具调用数、墙钟超时和允许改动路径，避免升级后的搜索空间失控。任务结束后把结果写回评测数据，定期更新路由规则，而不是永久保留第一次拍脑袋的分类。

七、什么时候应该保留 high

如果内部数据表明 high 在某类任务上持续提高独立审查通过率，并且增加的时间与用量能被业务价值覆盖，就应保留。典型候选是需要跨多个抽象层追踪根因、缺少即时测试反馈、必须同时满足许多不相容约束的任务。

反过来，如果 medium 与 high 的完成率接近，而 medium 的交付更快、diff 更小、人工修复更少，那么选择 medium 不是“降级”，而是更好的系统配置。模型与 Codex 运行时更新后应重新跑基准；历史结论不能自动外推到新版本。