Codex 的 Reasoning Effort 为什么不能长期固定使用 high 或 xhigh？

Codex 的 Reasoning Effort 不应长期固定为 high 或 xhigh，因为更高推理投入会增加延迟和 Token 用量，却不保证简单任务得到更好结果。对于指令冲突、停止条件薄弱或工具范围过大的任务，高档位还可能带来过度思考、无必要搜索和质量回退。正确策略是从适合当前模型的平衡档位建立基线，只在评测证明复杂任务获益时临时升档。

高档位解决的是什么问题

high 和 xhigh 允许模型在回答前进行更完整的复杂推理，适合根因未知、约束相互依赖或失败成本高的任务。

它们解决的是“推理投入不足”，不能解决以下问题：

• 缺少日志、代码或业务规则。
• 需求彼此矛盾。
• 工具没有权限或网络不可用。
• 验收标准不明确。
• 所选模型缺少必要能力。

为什么更高不一定更好

模型面对简单、模式明确的任务时，额外推理可能只是重新审视已经确定的答案。它不会增加有效信息，反而可能引入原需求没有提出的方案分支。

例如仓库已有完全一致的实现模板时，任务重点是准确复用。高档位若开始讨论新的架构选择，可能偏离代码库约定。

风险一：响应和完成时间增加

较高 Reasoning Effort 通常需要更多模型计算，首次响应和完整任务时间可能增长。交互开发中，延迟会打断开发者反馈循环。

如果任务本身只需几十秒验证，等待更长时间却得到相同结果，没有工程收益。

风险二：推理 Token 和用量增加

推理 Token 即使不直接显示，也会占用上下文并计入用量。长期把所有任务固定在高档，会让机械操作、检索和格式化承担不必要成本。

具体增幅由模型和任务决定，不存在可跨场景使用的固定倍数。应查看真实运行数据。

风险三：过度探索

工具范围开放、停止条件模糊时，高档位可能继续搜索更多文件、文档和替代路径，即使已有足够证据完成任务。

这会产生：

• 更多无关工具调用。
• 更大的上下文压力。
• 更长的执行路径。
• 更难审查的修改范围。

风险四：把已解决的问题重新打开

项目约定、现有模式和明确需求已经关闭了一些设计分支。高档位可能重新质疑这些选择，例如在要求“照现有模块实现”时讨论全新数据模型。

推理越多并不意味着约束遵循越好。提示应明确哪些事实已确定，哪些问题允许权衡。

风险五：质量可能回退

当输入含有冲突指令或弱停止条件时，额外推理可能放大歧义。模型可能生成更多假设、选择错误目标，或对简单答案过度复杂化。

因此，官方建议只有评测显示可测量质量提升时，才提高 Reasoning Effort。

high 适合哪些任务

• 复杂并发和时序错误。
• 跨服务根因分析。
• 数据库迁移与回滚设计。
• 安全、权限和隐私审查。
• 多个架构方案的约束权衡。
• 长链工具调用和复杂规划。

这些任务的共同点是需要发现隐藏依赖，且遗漏风险的成本较高。

xhigh 适合哪些任务

xhigh 应保留给模型明确支持、任务极难且不敏感于延迟的场景，例如：

• 深度研究和大规模材料综合。
• 长时间异步 Agent 工作。
• 复杂安全或代码审查。
• 困难算法与能力边界评测。

即使属于这些类别，也应先比较 high 与 xhigh。如果后者没有明显提高通过率，就不值得长期采用。

哪些任务应该使用 low

• 分类、路由和字段提取。
• 按明确规则修改配置。
• 复用项目中已有实现模式。
• 执行指定命令并整理结果。
• 有完整测试保护的局部改动。

这些任务的答案空间小、验证容易，额外推理通常收益有限。

medium 为什么适合作为基线

当任务复杂度不确定时，medium 往往是质量、可靠性、延迟和用量之间的平衡起点。具体默认仍由模型决定，不应假设所有模型相同。

基线的价值在于便于比较：简单任务可以向下测，复杂失败可以向上测。

“长期固定 high”最容易掩盖流程问题

团队若把高档作为默认，可能忽略真正需要改进的地方：

• 提示没有写清预期结果。
• 验收测试不足。
• 代码库规范没有文档化。
• 工具输出包含大量噪声。
• 任务拆分过大或边界重叠。

先改善任务定义和验证，通常比无差别升档更有效。

过度思考有哪些识别信号

• 对明确约定反复提出替代方案。
• 在已有充分证据后继续搜索。
• 修改范围超过任务需要。
• 为低风险问题设计复杂抽象。
• 最终结果与低档位相同，但耗时明显增加。
• 生成大量解释，却没有提升测试结果。

这些信号应通过运行日志和差异审查确认，而不是只看模型是否显示“思考中”。

推理不足有哪些识别信号

• 遗漏跨模块依赖。
• 无法解释冲突证据。
• 只修复表面症状。
• 没有考虑回滚和失败模式。
• 在信息完整时仍频繁走错工具路径。

这些情况才说明可能需要升到 high，同时也要检查模型是否适合任务。

动态调档的推荐流程

1. 从当前模型默认值或 medium 开始。
2. 明确结果、约束、停止条件和验证方式。
3. 执行代表性任务并记录结果。
4. 简单任务连续通过时尝试降低一级。
5. 复杂任务出现推理不足时提高一级。
6. 任何升档都比较质量、时间和用量。
7. 模型升级后重新评测。

一次性升档比永久修改更稳妥

只对某个困难任务使用 high：

codex --config 'model_reasoning_effort="high"'

若模型支持且任务确实需要，可临时使用 xhigh：

codex --config 'model_reasoning_effort="xhigh"'

命令行覆盖只影响本次启动，避免把高成本配置扩散到后续简单任务。

会话内按阶段切换

交互式 Codex CLI 可以使用 /reasoning 调整当前对话档位。例如：

1. 用 medium 阅读需求和仓库。
2. 遇到复杂架构分支时切到 high。
3. 方案确定后，机械执行阶段切回 medium 或 low。
4. 最终审查按风险决定是否再次升档。

用 profile 隔离高推理工作流

经常做深度审查时，可以创建专用 profile，而不是修改全局默认：

# ~/.codex/deep-review.config.toml
model = "当前已验证的模型标识"
model_reasoning_effort = "high"

启动时使用：

codex --profile deep-review

日常会话继续使用平衡档位，减少误用。

不要把模型选择和 effort 混为一谈

Reasoning Effort 是同一模型“投入多少推理”，模型选择是“由哪个模型处理”。若模型缺少必要上下文、工具或能力，升到最高档仍可能失败。

评测时可以先固定模型比较档位，再固定档位比较模型，避免同时改变两个变量。

评测应覆盖哪些任务

至少包含：

• 模式明确的局部实现。
• 普通多文件功能。
• 复杂 Bug 定位。
• 架构或迁移计划。
• 安全与边界审查。

一个简单任务得出的结论不能推广到所有工作流。

评测应记录哪些指标

指标	作用
首次通过率	判断推理是否足够
测试与审查结果	验证实际质量
总完成时间	包含工具和返工成本
推理及总 Token	衡量资源投入
工具调用次数	识别过度探索
人工纠正次数	发现隐性成本
越界修改数量	衡量约束遵循

设置明确停止条件

高档位任务尤其需要明确停止标准，例如：

• 指定必须通过的测试。
• 限制允许修改的模块。
• 要求已有证据足够时停止搜索。
• 定义无法继续时的汇报方式。
• 禁止未经授权的外部副作用。

停止条件越弱，高推理投入越可能变成长时间无边界探索。

让确定性机制承担确定性工作

格式校验、测试、类型检查、权限策略和数据约束应由工具执行，不应依赖模型“想得更仔细”。把确定性问题交给确定性机制，Reasoning Effort 才能集中处理真正模糊的判断。

高档位不能替代安全控制

high 或 xhigh 不会收紧文件系统、网络和命令权限。甚至在工具范围过大时，更强探索能力可能扩大副作用面。

沙箱、审批、最小权限和可回滚操作必须独立设置。

常见误区一：更慢说明想得更好

延迟只能说明执行时间更长，不能证明结论更正确。必须用验收和对照实验判断。

常见误区二：回答更长说明质量更高

输出详细度与推理强度是不同维度。更多文字可能只是重复解释，不能替代测试。

常见误区三：一次成功就设为默认

单次结果容易受随机性和任务类型影响。应覆盖多类任务并重复运行，再形成团队默认。

常见误区四：所有子 Agent 都用低档

子 Agent 如果承担安全审查或复杂实现，也可能需要高推理。应按子任务本身分级，而不是按角色名称决定。

常见误区五：所有重要任务都用 xhigh

重要不等于推理困难。数据删除操作可能非常重要，但执行步骤明确，真正需要的是审批、备份和验证，而不是最高 Reasoning Effort。

长期默认应该如何制定

推荐原则是“最低可稳定通过档位”：

1. 选择能够满足大多数日常任务的平衡默认。
2. 为简单批量工作建立低档 profile。
3. 为复杂审查建立高档 profile。
4. 将 xhigh 保留为经过评测的例外。
5. 定期审计运行时间、用量和失败类型。

常见问题

high 会不会总比 medium 准确

不会。高档位提供更多推理机会，但输入质量、任务结构和模型能力仍决定结果。

xhigh 为什么不适合作为默认

它的目标是最困难且不敏感于延迟的任务，日常工作通常无法获得与额外成本匹配的收益。

什么时候应该永久使用 high

只有当某个稳定工作流的代表性评测持续证明 high 优于较低档位，并且额外延迟和用量可接受时。

降低档位会不会影响所有结果

影响取决于任务。模式明确的工作可能没有可测量差异，复杂推理任务则可能明显下降，因此必须分类评测。

总结

Codex 的 high 和 xhigh 是复杂任务的专用资源，不是通用质量开关。长期固定高档会增加延迟和推理用量，还可能在冲突指令、弱停止条件和开放工具环境中引发过度探索或质量回退。以平衡档位为基线，按任务阶段临时升降，并用成功率、测试结果、总时间、Token 和工具调用次数验证，才是更可靠的 Reasoning Effort 策略。