把一个推理模型的 reasoning effort 或 thinking budget 调到最高，看上去像一种稳妥选择：多给一点计算，换更好的结果。问题在于，这个控件只暴露了成本和等待时间，没有替应用回答最关键的问题：这段额外计算究竟会做什么，又怎样证明它值得？
在部分推理密集型基准中，更多训练时和测试时计算确实可以提升表现；单次回答、多个候选的共识，以及对候选进行重排序，能得到不同结果。1 但另一组研究提醒我们，在交互式软件工程 Agent 和简单任务中，额外推理也可能表现为重复验证、无限探索，或者迟迟不采取下一步行动。4 5
这不是“高预算好”与“低预算好”的二选一。更准确的问题是：面对这项任务，是否应该增加计算？增加的计算该用于修订、生成候选，还是验证？什么信号足以触发升级？当系统无法获得新证据时，又该在哪里停止？
本文把推理预算看作应用的路由参数，而不是质量旋钮。先拆开它实际买到的能力，再讨论额外计算何时有效、何时伤害任务，最后给出一张可落地的路由表和一套最小评测协议。文中的路由表、矩阵和成本指标都是工程建议，不是任何一篇论文给出的通用公式。
第一章：推理预算到底买了什么
“模型多想一会儿”是一个方便但不够准确的说法。它容易让人把额外计算想成同一条思考链的延长，好像只要持续推进，答案就会沿着一条线稳定变好。测试时计算不是这样一个单一动作。
先做一个基本区分。训练时计算用于形成模型的能力；测试时计算发生在模型已经部署之后，为眼前这一道题追加资源。1 应用工程师通常无法改变前者，却可以在后者上做选择：一次请求允许多少推理资源，是否采样多个候选，何时调用外部工具或验证器，何时重试，何时停止。
这些选择看似都在“多花一点计算”，实际却对应至少三种不同的工作。
第一种是连续修订。系统先得到一个候选，再根据反馈检查、改写或补全它。它真正需要的不是更多文字，而是能指出“下一轮该改什么”的反馈。测试失败、缺失字段或反例都可能成为有效反馈；如果反馈本身不可靠，模型只会在原来的错误假设上反复打磨。
第二种是并行探索。系统生成多条候选路径，再从中选出更好的一个。它适合确实存在多个合理方案、并且候选差异能够被观察到的任务。若多个候选来自同一条错误前提，增加样本只会得到多份相似错误，而不是更强的答案。
第三种是验证与选择。系统使用确定性规则、工具结果、过程验证器、交叉来源或重排序机制，判断哪个候选更可靠。Snell 等人在测试时计算研究中比较了搜索、修订和过程验证等策略，也指出这些策略的效用会随任务难度和可用信号而变。2 这解释了为什么“生成得更多”不等于“选择得更好”：候选的质量和选择机制的质量，是两项独立能力。
还要注意，测试时计算不一定表现为一个模型内部更长的隐藏推理。2025 年底提出、并在 2026 年 5 月更新的 Recursive Language Models（RLM）把长提示当作外部环境，让模型用程序检查、拆分提示，并递归调用自己处理片段。11 这类方法把预算从“多生成一些 thinking token”扩展成上下文读取、代码执行、子调用和递归深度的组合。它在长上下文基准上有积极结果，但这仍是特定任务与实验框架的证据，不能直接推出所有业务都应采用递归 Agent。
一些 API 已将这类权衡做成调用方可见的控制面。例如 Google 在 Gemini 2.5 Flash 的工程说明中，将 thinking budget 描述为质量、成本和延迟之间的可配置取舍。3 这很重要，但也不应被过度解读。某个 API 的预算参数只是测试时计算的一种产品化接口；它不等于所有可能的并行采样、搜索、过程验证和结果选择机制，更不意味着不同厂商的参数含义、默认策略或计价方式相同。
近一年的产品更新说明，供应商也在把“是否深思”部分内置为自适应路由。OpenAI 的 GPT-5 系统卡描述了一个根据会话类型、复杂度、工具需求和显式意图选择模型的实时路由器；GPT-5 API 还提供 minimal 到 high 的 reasoning_effort 档位。6 7 Anthropic 在 Claude Opus 4.6 中引入 adaptive thinking，让模型判断何时需要更深推理，同时保留 low、medium、high、max 四档 effort。8 Gemini 3 则用 thinking_level 控制最大思考深度，并明确它是相对指导而非严格 token 保证；官方示例把 high 放在复杂分析，把 low 放在结构化抽取和摘要。9
这并不意味着应用可以取消自己的路由层。供应商只知道模型侧的信号；应用仍要决定工具权限、独立验证、外部副作用、人工审批和任务级成本。更准确的说法是：模型厂商正在提供一个粗粒度的自适应预算器，应用需要在它外面加上任务边界和停止条件。
因此，在比较具体参数之前，应用先要回答一个更基础的问题：这个任务是否值得被探索、选择或验证？如果答案是否定的，默认把预算拉高，往往只是把一个确定性工作拖慢。
第二章：什么时候多想真的有用
额外计算并非没有价值。问题是，研究证明的是有条件的收益，而不是“只要想得更久，所有任务都会更好”。
OpenAI 对推理模型的研究说明展示了一个直观事实：在受控的推理基准上，随着训练时和测试时计算增加，模型表现可以继续提升；单次回答、对多个答案求共识、再对候选重排序，得到的效果并不相同。1 Snell 等人的工作进一步表明，测试时计算如何分配取决于题目难度，自适应分配并不等同于统一采用最大的候选数或最长的推理路径。2
这些结果值得重视，也必须保留边界。它们主要来自数学推理与特定奖励模型语境，不能直接证明普通文本生成、业务审核或用户沟通同样会按比例受益。把基准上的曲线写成“所有应用都应该提高推理预算”，正好会掩盖应用层真正需要判断的条件。
更适合工程讨论的，是把“值得追加预算”拆成三个可审查的问题。
第一个问题是：任务中是否真的有值得探索的候选空间？ 对结构化抽取、格式转换、明确分类和确定性工具调用而言，很多正确性来自规则、schema 或工具本身。只要输入完整，可能并没有多条同样合理的路线可供模型探索。相反，多源综合、复杂规划、含局部歧义的分析，往往存在多个候选解释或方案，额外探索才可能发现差异。
第二个问题是：系统是否拥有独立的选择或验证信号？ 代码可以运行测试，提取结果可以检查 schema，事实性主张可以比对来源，业务操作可以检查规则与权限。没有这些信号时，系统即使生成多个候选，也很难可靠地判断哪个较好。让同一个模型同时生成、评价和批准自己的答案，最多是一种弱信号，不能替代独立验证。
第三个问题是：这项任务还能等多久？ 有些任务的价值随着行动窗口关闭而快速下降。用户正在等待的交互、临近截止的工具调用、需要尽快拿到下一步观察的 Agent 任务，都不应只用“潜在质量更高”衡量。多一轮分析若使系统错过可获得新反馈的时点，反而降低任务价值。
这三个条件也解释了“按难度分配”在产品里不能被简化为让模型自报“这题很难”。难度是一个有用输入，但模型自评并不等于可靠路由器。更可观察的代理信号包括输入是否缺失、候选是否冲突、历史上这类任务常在哪个环节失败、确定性校验是否未通过。它们也不是永久正确的难度分类器，只是应当通过真实任务数据被校准的触发器。
所以，固定最高预算不是一个保守默认值。它默认了每项任务都既有复杂候选，又有可靠验证，且总能等待更久。这三个前提在大多数应用里并不会同时成立。
第三章：为什么模型会越想越错
如果额外计算只是慢一些、贵一些，预算问题还可以只交给成本优化。但在交互任务里，推理会改变系统是否行动、如何行动，以及它什么时候放弃，因此也是行为风险参数。
Cuadron 等人对 4,018 条 SWE-bench Agent 轨迹的分析讨论了 reasoning-action dilemma，并将一些不良模式概括为 Analysis Paralysis、Rogue Actions 与 Premature Disengagement。4 这项研究的领域是软件工程 Agent，结论不应被推广成所有应用的因果定律；它提供的价值在于指出，一个系统可能不是“不会推理”，而是在本该调用工具、读取反馈或提交下一步行动时继续困在分析中。
想象一个代码修复任务。测试已经明确地告诉系统哪个断言失败，最有信息量的下一步通常是检查相关实现、修改候选、再次运行测试。如果系统没有形成新的假设，却继续复述可能原因、重新列举方案，增加的并不是解决问题的证据，而是延迟。另一个极端也同样危险：没有检查关键约束就匆忙行动，或者连续几轮尝试失败后过早退出。它们的共同点不是“想得太长”或“想得太短”，而是内部推理、外部反馈和行动时机没有对齐。
DeepMind 对过度思考的研究也给出一个重要校准：只按输出或推理长度判断 overthinking 并不充分。在简单任务中，过度思考可以表现为 over-verification 和 over-exploration，即没有必要地重复检查已经足够的信息，或在缺少决策标准时不断扩大搜索范围。5
最新的另一条研究线提醒我们，额外计算也可以花在“监控者”身上，而不只是被监控的 Agent。OpenAI 的 monitorability 评测发现，在其数学、科学和编码环境中，更长的推理链通常更容易被监控；但把小模型提高推理强度来换取更强监控能力，会产生额外的 inference compute，也就是作者所说的 monitorability tax，同时结果受任务分布限制。10 因此，高风险路由至少要区分两种预算：解决任务的预算，以及检查任务是否可靠的预算。
这一区分对应用实现很实用。一次验证是否有效，不取决于它看起来是否谨慎，而取决于它能否产生新的、足以改变选择的信息。一次探索是否有效，不取决于候选数量，而取决于新增候选是否能被某条规则、证据或测试区分。
可以用两个简单对照检查过程。若系统生成候选后运行一次能够决定取舍的测试，这是有效验证；若测试已经通过、没有新假设，却继续反复检查同一性质，这是过度验证。若系统发现多个来源相互冲突，再补充一个能够区分它们的原始出处，这是有效探索；若它没有制定判断标准，只是不断加入更多相似来源，这是过度探索。
由此得到的工程结论不是“禁止模型思考”，而是把停止条件当成任务策略的一部分。除了最大 token、最大时长和最大调用次数，还应有更贴近任务的条件：验证是否已通过；新一轮是否会获得新区分信息；候选数量是否超过可验证能力；行动窗口是否即将关闭。预算耗尽只是最后的保险丝，不应是唯一的停止理由。
第四章：不要把最高推理强度设为默认值
如果预算不是统一的质量旋钮，应用怎样开始一次请求？一个实用起点是同时看四项输入：任务难度、失败代价、可验证性和行动时效。
任务难度问的是：是否存在真实歧义、组合推理或多步依赖？它可以通过输入完整性、候选冲突、历史失败类型、规则校验失败等信号近似，但不能被模型自评替代。失败代价问的是：错误一旦被执行，影响范围多大、是否可逆、是否涉及权限或外部资源？可验证性问的是：系统能否借助测试、schema、来源、业务规则或人工复核，独立区分结果好坏？行动时效问的是：为了可能更好的答案，任务可以等待多久？
这四项不能合并成一个“任务重要性”分数。尤其要避免一个常见误解：高风险自动等于高预算。若一项动作错误代价很高、结果又无法可靠验证，继续让同一个模型思考并不会自动降低风险。更合理的下一步可能是补充证据、缩小授权范围、改为仅输出建议，或者明确要求人工批准。
这套判断可以落成两阶段路由。
第一阶段发生在请求前。应用根据任务类型和四项输入，给出低或中预算的基线，同时约定最大成本、最大时延和是否允许外部动作。基线的作用不是猜中最优参数，而是提供一个可比较、可解释的默认路径。
第二阶段发生在任务执行后。只有出现可解释的失败信号，系统才追加计算。结构校验失败时，可能需要定向修订；多个候选冲突时，可能需要增加候选并引入选择规则；关键来源不足时，可能需要补证据而非增加同类推理；测试失败时，可能需要读取工具反馈再修改。每次升级都应说明额外计算要解决什么，而不是把同一请求原样重试。
若验证器无法区分候选、成本或时限已接近上限，或者动作超出自动化授权范围，系统应停止或转人工。这并不表示自动化失败，而是承认当前系统没有足够的证据做出可靠决定。
这里也能看出“增加计算”和“增加证据”的区别。对于多源研究、合规判断或事实性主张，最有效的下一步可能是获得一条可追溯的原始资料。对于可运行代码、结构化抽取和工具调用，独立验证器通常比单纯提高 reasoning effort 更能定位错误。对于高影响且不可验证的动作，正确设计首先是限制自动执行，而不是用最高预算制造确定性幻觉。
第五章：一张可落地的推理路由表
路由表的目的不是给每个模型发一张“最佳 token 数”说明书。它的作用是让团队对四件事达成共同约定：哪些任务能自动进入这条路径；初始预算是多少；什么事实会触发升级；什么情况下必须停止、降级或交接。
| 任务类型 | 关键特征 | 初始策略 | 升级触发器 | 验证与停止 |
|---|---|---|---|---|
| 提取、分类、格式转换、确定性工具调用 | 规则清楚，可快速校验，错误可重试 | 低预算，尽早行动 | schema 失败、必填字段缺失、工具报错 | 通过结构或工具校验即停止；重复失败后返回明确错误 |
| 多源综合、需求澄清、局部歧义分析 | 存在多个合理候选，可补充证据 | 中预算，允许有限修订或少量候选 | 关键来源冲突、证据不足、候选无法一致 | 以来源质量、覆盖度或预先定义的检查表选择；无新证据时停止 |
| 高影响、复杂推理且结果可验证 | 错误代价高，但存在测试、模拟、规则或复核 | 高预算，或多个低/中预算候选加独立验证 | 测试失败、候选显著分歧、验证器发现关键缺陷 | 验证通过才允许下一步；无法区分时转人工 |
| 高影响且不可可靠验证 | 外部副作用大、证据不足、难以及时回滚 | 限制自动决策；预算不是主要控制 | 任何关键不确定性或授权边界触发 | 优先补证据和人工审批；不以更高预算替代授权 |
这张表是本文提出的工程框架，不是从某个基准直接抄出的分类器。表中的“低、中、高”也只能相对于一个应用自身的档位定义，不能对应某个跨厂商、跨版本都成立的 token 数。它需要结合团队的任务集、模型能力、工具权限、验证器质量和服务时限被持续校准。
真正落地时，不要一开始就让所有请求经过复杂路由。选择两到四类高频、边界稳定、能够独立验证的任务，先为它们建立基线。每类任务都要记录：为什么本次选择这个预算，什么事件触发了升级，升级后使用了修订、候选还是验证，最终是否通过了独立检查。
这些记录有一个容易被忽略的价值：它让策略具备可追溯性。当某次高预算请求成功时，团队可以判断成功来自更长推理、更多候选、额外证据、模型版本变化，还是工具偶然可用；当它失败时，也能区分推理不足、验证不足、工具故障和行动延迟。没有这条记录链，所谓“智能路由”往往只是不可解释的重试。
2026 年上半年社区里也出现了几种值得记录、但不能冒充共识的表述。它们的共同点，是把“更强推理”放回运行时约束中：
社区观察（非独立评测） - CTO Advisor 的 Keith Townsend 认为，代码 Agent 的推理能力提升并不会自动转化为交付速度；决策权放在哪里，以及工作流是否允许 Agent 行动，才是生产落地的关键。12 - s1r1us 对 RLM 的实践解读强调按需读取和程序化拆分上下文，同时提醒递归子调用在普通任务上可能带来“过度”和不可接受的时间、计算开销。13 - tetsuoai 把运行时 trace 当成路由学习材料：工具顺序、上下文长度、阶段切换和预算选择可以暴露稳定的失败模式，再反过来形成提示词、工具编排和路由规则。14
这些帖子不是样本代表性充分的调查，也没有替代基准实验的统计效力。它们的价值在于提供了工程团队正在使用的语言：预算不是孤立的模型参数，而是和权限、上下文、工具顺序、追踪记录一起构成运行时策略。本文采纳的是这个问题意识，不采纳其中任何未经验证的产品效果数字。
路由表还应保留一个明确的空白：没有验证器的高风险任务，暂时不进入自动预算优化。先把问题暴露出来，比用一个看起来更强的模型参数盖住它更有价值。
第六章：从 token 成本转向经验证的任务成本
只比较一轮请求消耗的 token，很容易得出错误结论。低预算回答若频繁验证失败、触发工具重试，最后还需要人工返工，可能比一次较高预算但验证通过的任务更贵。反过来，高预算回答即使更长、更完整，若没有通过独立验证或错过了行动窗口，也不应算作收益。
因此，成本的分母不应是“一次模型调用”，而应是“一个经独立验证成功完成的任务”。这个单位会把常被分散统计的资源重新放在一张账上：模型调用、工具调用、重试、等待、人工纠正，以及最终是否完成。Cuadron 等人的研究同时考察任务表现和计算变化，也说明性能和资源消耗不能被割裂讨论。4
一个最小任务记录不需要昂贵的观测平台。它至少应包含任务类型、输入版本、运行环境、初始和最终预算档位、升级触发器、追加动作、独立验证结果、模型与工具调用次数、端到端延迟、模型成本、人工纠正或接管，以及最终任务状态。人工成本一时难以折算为金额，也应记录接管次数和纠正时长；忽略它，只会把成本藏到模型账单之外。
可以用一个概念性指标把它们收束起来：
经验证任务成本 = 固定任务集内模型调用、工具调用、重试、等待和人工纠正的总成本 / 经独立验证成功的任务数。
这个指标不承诺所有任务都能用同一种成本函数比较。它要求的是更基本的纪律：一档预算策略要被称为“更好”，至少应同时满足质量、时限和完整任务成本的目标，而不是只在其中一个维度看起来更漂亮。
目前，这个项目没有同一真实任务在低、中、高预算下的公开原始对照数据。因此本文不能声称 Harness、Notes 研究流程或 ZhoMind-v2 已经验证“某档预算更优”。更诚实也更有用的做法，是把下一步实验写清楚。
先选一个边界明确、可重复且可独立验证的任务。例如，选择 Notes 研究流程中可由来源核验判断的子任务，或 Harness 中拥有确定测试结果的任务。固定模型版本、输入集、提示词、工具权限和验证器，只改变推理预算或候选/验证策略。至少比较低、中两档；只有当任务确实存在复杂候选且验证器可靠时，再加入高档或多候选策略。
对每档重复运行，记录任务是否完成、独立验证结果、总成本、延迟、重试、工具调用和人工接管。结果出来后，不只看哪档成功率更高，还要按失败类型解释差异：是推理不足、验证不足、工具不可用，还是系统把时间花在了没有新信息的分析上？只有当质量、时限和经验证任务成本同时符合目标时，新的策略才值得进入默认路由表。
结语：预算是路由参数，不是质量旋钮
更多推理既不是免费收益，也不是必然浪费。它的价值取决于额外计算被投入了什么动作：是在修订一个能被反馈纠正的候选，探索确实存在差异的路径，还是借助可靠验证器选择结果。任务是否需要探索、系统能否验证、行动还来不来得及，共同决定预算有没有意义。
这也解释了为什么高风险不能自动推导出高预算。高风险且不可验证的任务，首先需要的是更好的证据、清晰的授权边界和人工判断；提高同一个模型的推理强度，不会把不确定性自动变成可靠性。
对应用而言，最稳健的起点不是寻找一个永远正确的最高档位，而是建立低或中预算的可评测基线，用结构化失败信号触发定向升级，再以经验证的任务成本判断升级是否值得。好的推理系统不以“想得最久”为目标；它知道何时多算一步，何时去拿一条新证据，何时已经该停止并把决定交还给人。
参考资料
- OpenAI. Learning to reason with LLMs, 2024-09-12.
- Charlie Snell, Jaehoon Lee, Kelvin Xu, Aviral Kumar. Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters, 2024-08-06.
- Google. Start building with Gemini 2.5 Flash, 2025-04-17.
- Alejandro Cuadron et al. The Danger of Overthinking: Examining the Reasoning-Action Dilemma in Agentic Tasks, 2025-02-12.
- Xinliang Frederick Zhang, Anhad Mohananey, Alexandra Chronopoulou et al. Towards Structural Understanding of LLM Overthinking, 2026-07-02.
- OpenAI. Introducing GPT-5 for developers, 2025-08-07.
- OpenAI. GPT-5 System Card, 2025-08-07.
- Anthropic. Introducing Claude Opus 4.6, 2026-02-05.
- Google. New Gemini API updates for Gemini 3, 2025-11-25.
- OpenAI. Evaluating chain-of-thought monitorability, 2025-12-18.
- Alex L. Zhang, Tim Kraska, Omar Khattab. Recursive Language Models, revised 2026-05-11.
- Keith Townsend. X post on decision authority and workflow fit for coding agents, 2026-01-14. Community observation, not independent evaluation.
- s1r1us. X post on RLM practice and compute overhead, 2026-02-11. Community observation, not independent evaluation.
- tetsuo. X post on runtime traces as agent-routing feedback, 2026-03-12. Community observation, not independent evaluation.