我该选择多少推理投入？LLM 智能体推理投入的经济学

1. 问题与价值

这篇论文研究的是 LLM 智能体中的「推理努力程度」（reasoning effort）这一参数的经济学问题。现在主流推理模型都暴露一个 effort 旋钮，让用户在推理时计算量上做权衡：调高 effort 通常意味着更多 token、更长轨迹、更高费用，理论上也可能带来更高成功率。

问题在于：用户必须在任务执行前就选定 effort，而且即使任务成功了，用户也无法知道当初买的额外推理到底有没有用。论文把这个现象定性为「信任品」（credence good）问题——买家能观察到结果，但无法评估所购计算量的边际价值。

这个问题的价值在于：effort 现在是用户控制推理开销的主要杠杆。在长程智能体任务中，一个 effort 设置会被乘到轨迹的每一步、每一次调用上，而它只被选一次，靠直觉选，且没有反馈告诉用户选得对不对。如果高 effort 并不总是更好，那么用户正在为看不见、也无法验证的推理付费。

受益方是两类人。第一类是实际部署 LLM 智能体的工程师，他们需要知道固定高 effort 是否值得，以及有没有更省钱的策略。第二类是评估者，论文指出只看聚合准确率和 token 数会误判哪个配置真正更好，需要把任务级反转、完整轨迹成本、用户等待时间都纳入评估。

2. 已有工作的不足

在本文之前，相关研究大致分几条线。

一条是 test-time scaling 文献，如 Snell et al. 2025 和 Muennighoff et al. 2025，证明在难题上增加推理时计算可以提升性能。这条线的问题在于：它关注的是聚合层面的性能提升，没有回答「在单个任务上，高 effort 是否总是保持低 effort 的成功」这个反事实问题。

另一条是成本感知评估。Kapoor et al. 2024 提出用准确率-成本帕累托前沿做成本受控的智能体评估；Holistic Agent Leaderboard（Kapoor et al. 2026）发现高 reasoning effort 在多数运行中反而降低了准确率；Erol et al. 2026 测量正确解相对于人类专家基线的期望成本。这些工作的不足是：它们要么报告 effort 级别间的聚合准确率，要么在固定 effort 下比较模型，要么只研究单模型在单次调用基准上的表现，没有把 effort 当作一个任务级变量来审计其边际价值。

还有一条是 token 经济学。Bai et al. 2026 发现智能体编码任务中输入 token 而非输出 token 主导消耗；Fan et al. 2025 发现失败尝试比成功尝试更贵；Chen et al. 2026 发现标价可能错排实际成本。这些工作揭示了成本结构，但没有系统测量「同一个任务在不同 effort 下，成功与否和成本如何同时变化」。

论文明确指出的缺口是：已有工作没有在任务级别上审计 reasoning effort 的边际价值，没有把 effort 变化与轨迹行为变化、任务结果、推理成本、等待成本联系起来。具体方法名包括 Snell et al. 2025、Muennighoff et al. 2025、Kapoor et al. 2024、Kapoor et al. 2026、Erol et al. 2026、Bai et al. 2026、Fan et al. 2025、Chen et al. 2026。

3. 重建作者的思考路径

如果我是作者，面对第 2 项里的不足，第一步会想：既然 effort 是一个有序旋钮，用户自然假设调高只会「增加」解出的任务，即解集是嵌套的。那么最直接的检验就是：对每个模型和基准，把相邻 effort 级别的解集拿出来做差集，看高 effort 是否真的包含低 effort 的解集。

这一步撞上的第一个问题是：聚合准确率会掩盖实例级的丢失。比如 Inkling 在 GPQA 上从 low 到 medium 净增 16 题，但这个净增是两个不相交集合的差，medium 实际上在 5 道 low 解出的题上全挂了。所以光看聚合数会误判。

接下来我会想：就算高 effort 在聚合上更好，它在那些「所有 effort 都能解」的简单任务上是不是花了冤枉钱？这里需要一个公平比较：把任务限制在所有 effort 级别都解出的交集上，这样成本差异就不会被「多解了题」混淆。这一步会撞上第二个发现：高 effort 在简单任务上并不收缩到低 effort 的成本，而是像一个固定乘数一样放大计算量。

然后我会问：为什么高 effort 会丢低 effort 的成功？如果只是「想得更久」，不该丢。这逼我去看轨迹本身。这里撞上第三个问题：effort 改变的不只是 token 数，而是解题策略。高 effort 更倾向于检索已有答案、更倾向于自我验证，而这些策略并不适合所有任务。SWE-Bench Pro 原始环境里 git 历史暴露了 gold commit，高 effort 模型会去读它，这其实是基准泄漏而不是真解题。

到这里，三个发现共同指向一个结论：固定 effort 不是最优的。那自然的下一步是：能不能按任务分配 effort？我会先试两个可部署策略。一个是让模型自己从任务描述选 effort（self-routing），撞上的问题是模型选不准，没有一致的成本-准确率优势。另一个是从最低 effort 开始，只在外部验证失败后才升级到最高 effort（naïve laddering），这个策略保留了低 effort 的初始成功，又只在需要时花高 effort 的钱。

最后我会想：API 账单够不够衡量成本？不够，因为用户等待时间也是成本。于是引入一个包含等待时间的 full cost 公式，把生成 token 数除以吞吐量再乘以时薪。

与论文实际路径的差异：我猜的路径是「先检验嵌套性，再看成本，再看行为，最后做路由」，论文实际也是这个顺序。差异在于：我一开始不会想到「None effort 不是零成本」这个反直觉发现——禁用推理后智能体用更长的轨迹补偿，输入 token 反而涨了。这个发现更像是作者在跑数据时撞出来的，而不是从理论推出来的。另一个差异是：我可能不会想到用 Act·ONOMY 这种三级分类法去标注轨迹行为，而是会自己定义几个粗粒度行为类别；论文用了现成的 10 个顶层动作、46 个子动作、120 个叶子类别的分类法，粒度细得多。

4. 核心 intuition

把 effort 想象成请人修水管。你打电话时要说「派个学徒还是老师傅」。老师傅收费高，但你可能以为他修得更快更好。实际发生的是：老师傅来了之后，先花半小时检查你整栋楼的管道，再上网查同户型别人的维修记录，最后反复确认自己拧的每个阀门都符合规范。学徒来了直接找到漏水点换了个垫圈就走了。两个人都修好了，但老师傅的账单是学徒的几十倍，而且老师傅有时候因为查太多资料反而把原本能修好的地方搞乱了。

这个类比对得上机制：高 effort 不是「同一个过程想得更久」，而是「换了策略」——更多检索、更多自我验证、更长轨迹。这些策略在难题上可能有用，但在简单任务上就是纯粹的浪费，甚至因为策略偏移而丢掉低 effort 本来能解的任务。关键点是：你作为用户，事后只看到「修好了」，看不到老师傅到底做了多少无用功，这就是信任品。

5. 方法 pipeline 举例

编一个具体输入：Terminal-Bench 2.1 里的一个任务，比如「在 Linux 容器里配置一个服务并让验证脚本通过」。模型用 GPT-5.6-sol，effort 级别有 none、low、medium、high、xhigh。

第一步，固定任务和 harness。同一个任务在五个 effort 级别下各跑一次，Terminus-2 智能体配置不变，只有 effort 参数变。

第二步，记录每次执行的完整轨迹。包括每次模型调用的输入 token、输出 token、隐藏推理 token、工具调用、验证命令、最终是否通过外部 verifier。

第三步，构造解集。假设 low 解出了任务 A、B、C；xhigh 解出了任务 B、C、D、E。那么聚合上 xhigh 解出 4 个，low 解出 3 个，xhigh 看起来更好。但做差集：low 解出而 xhigh 没解出的是任务 A，这是回归集；xhigh 解出而 low 没解出的是 D 和 E，这是新增集。净增是 2 减 1 等于 1，但用户拿到的是单次运行，他不知道自己会撞上 A 的丢失。

第四步，算 always-solved 成本。取所有 effort 都解出的任务，比如任务 B 和 C。在 low 下，任务 B 的平均成本是 0.7 美分；在 xhigh 下，任务 B 的平均成本是 2.51 倍于 low。这个倍数只来自「同一个任务在不同 effort 下的花费差异」，不掺杂「多解了题」的混淆。

第五步，看轨迹行为。对任务 B 的 low 和 xhigh 轨迹分别做 Act·ONOMY 标注。假设 low 轨迹里 Evaluation 类行为占 10%，xhigh 里占 18%。再细看叶子类别：xhigh 里 Plan verification step、Run verification command、Confirm actual == expected 三个类别的计数都更高，但最终结果都是通过。这说明多出来的验证没有改变结果。

第六步，跑 laddering。对任务 A、B、C、D、E 各从 low 开始。A 在 low 下通过，保留，不升级。B、C 在 low 下通过，保留。D 在 low 下失败，升级到 xhigh 重试，通过，计两次成本。E 在 low 下失败，升级到 xhigh 也失败，计两次成本。最终成功集合是 A、B、C、D，比固定 xhigh 的 B、C、D、E 多了一个 A，少了一个 E，净成功数相同或更高，而成本因为大部分任务在 low 就停了，比全部跑 xhigh 低。

6. 核心数学推导

论文的核心公式是 full cost 的定义，出现在第 3.4 节。

先解释符号。C_full(i, e; m) 表示任务 i 在 effort 级别 e 下用模型 m 执行的估计总成本。C_API(i, e; m) 是 API 账单，单位是美元，包含输入、输出和隐藏推理 token 的费用。N_out(i, e; m) 是生成的总 token 数，包括推理 token。r_m 是模型 m 的输出吞吐量，单位是 token 每秒。w 是时薪，论文取美国全职业平均时薪 33.54 美元每小时。3600 是把秒换算成小时的因子。

推导过程：

第一步，计算等待时间。生成 N_out 个 token，每秒生成 r_m 个，所以等待秒数是 N_out / r_m。

第二步，把秒换算成小时。等待小时数是 N_out / (r_m × 3600)。

第三步，把等待时间货币化。等待成本是 w × N_out / (r_m × 3600)。

第四步，加上 API 账单。总成本是 C_API + w × N_out / (r_m × 3600)。

这就是论文里的公式：C_full(i, e; m) := C_API(i, e; m) + w × N_out(i, e; m) / (3600 × r_m)。

这个公式在算的是：一个用户在任务执行期间被阻塞等待时，实际付出的总成本，包括付给 API 提供商的钱和等待时间的机会成本。论文用它来说明：API 账单会低估 laddering 的节省，因为 laddering 虽然可能多付一次 API 调用，但总生成 token 更少，等待时间更短，而等待时间在 full cost 里占 58% 到 98%。

另一个核心数学对象是解集差。设 s_e 是模型在 effort 级别 e 下解出的实例集合，e1 < e2 表示两个有序级别。嵌套假设是 s_e1 ⊆ s_e2，即高 effort 只增不减。论文检验的是回归集 s_e1 \ s_e2 是否非空。Inkling 在 GPQA 上从 low 到 medium 的例子：∣s_medium∣ - ∣s_low∣ = 16，但 ∣s_low \ s_medium∣ = 5，说明净增 16 掩盖了 5 个丢失。

7. 实验设计

数据集有四个。AIME 2026 是数学竞赛题，30 道题，每题 10 次尝试，单次 API 调用。GPQA Diamond 是研究生级科学问答，198 道题，每题 4 次尝试，单次调用。Terminal-Bench 2.1 是终端环境智能体任务，89 个任务，用 Terminus-2 harness，多轮交互。SWE-Bench Pro 是仓库级软件工程任务，44 个实例的 pilot，用 mini-swe-agent，多轮交互。另外还有一个 corrected 版本的 SWE-Bench Pro，移除了 git 历史并限制网络访问。

模型有八个。专有模型 GPT-5.6-sol、GPT-5.6-terra、GPT-5.6-luna、Claude Sonnet 5；开放权重模型 GLM-5.2、Inkling、Kimi K3、DeepSeek V4 Flash。每个模型的 effort 设置不同，GPT-5.6 系列和 Claude Sonnet 5 有 none、low、medium、high、xhigh；GLM-5.2 只有 none、high、max；Kimi K3 只有 low、high、max。

指标有三个层面。成功指标：AIME 和 GPQA 用 pass@k 判定任务是否解出，mean@k 报告聚合表现；智能体基准用任务是否通过 verifier 的二元结果。成本指标：完整执行的 token 用量换算成美元，区分输入、输出、隐藏推理 token。行为指标：用 Act·ONOMY 分类法标注轨迹，该分类法有 10 个顶层动作组（Evaluation、Reasoning、Planning、Retrieval、Executing、Reflection、Deciding、Memory、Grounding、Learning），46 个子动作，120 个叶子类别。标注粒度是轨迹内每一步（一个工具调用或模型输出中的一条陈述）分配一个叶子类别。标注者是用 Claude Sonnet 5 按照 Gao et al. 2026 推荐的标注设置自动标注，不是人工。行为与成本/结果的关联方式是：比较同一任务在最低和最高 effort 下，各行为组的平均每轨迹占比变化，以及验证类叶子类别的计数变化，再按「两端都通过」和「两端都失败」分组看验证行为是否改变结果。

消融有三个。第一个是 corrected SWE-Bench Pro 环境，用来分离检索 gold commit 的泄漏效应。第二个是 DeepSWE 四轮 rollout 分析，用来检验单次运行协议下的反转是否只是采样噪声。第三个是 same-effort retry 对照，在 DeepSWE 上比较 laddering（low 到 high）与 low 到 low、high 到 high 的重试策略，用来确认 laddering 的收益不是单纯来自第二次尝试。

实验能否支撑结论：能支撑「高 effort 不保持低 effort 成功」「高 effort 在 always-solved 任务上超支」「effort 改变策略」这三个核心发现，因为它们在多个模型和基准上重复出现。但有一个明显缺口：智能体基准每个任务每个 effort 只跑一次，单次运行的反转可能来自执行变异性而非系统性的 effort 效应。论文用 DeepSWE 的四轮 rollout 做了补充，在更严格标准下反转仍存在，但主实验的实例级反转数字本身有噪声。另一个缺口是：laddering 的成功率和成本是从已有执行重建的，不是真正端到端跑出来的策略，它假设存在可靠的外部正确性检查，这个假设在很多部署里不成立。

8. take-aways

第一条：高 effort 不保持低 effort 的成功。在 Terminal-Bench 上，八个模型从最低到最高 effort 都有非空回归集；GPT-5.6-sol 从 high 到 xhigh 丢了 8 个任务，只新增 5 个，解出数从 76 降到 73（89 个任务）。

第二条：在 always-solved 任务上，高 effort 的成本可以是最低 effort 的 42 倍。这个 42 倍出现在图 2 的某个模型-基准组合上，具体是成本相对最低 reasoning effort 的比值。

第三条：禁用推理不省钱。GPT-5.6-luna 在 always-solved 任务上，none 平均 21.5 次模型调用，low 是 5.4 次，none 的成本是 low 的 4.58 倍，因为输入 token 账单从 0.0021 美元涨到 0.0258 美元。

第四条：naïve laddering 在所有模型和基准上匹配或超过固定最高 effort 的成功率，且在 AIME 上中位成本节省 25.3%，GPQA 上节省 41.5%，corrected SWE-Bench Pro 上节省 15.5%，这些节省包括了升级时两次执行的成本。

第五条：等待时间主导 full cost。在智能体模型-effort 比较中，等待成本占 combined cost 的约 58% 到 98%；GPT-5.6-sol 在 always-solved SWE-Bench Pro 最高 effort 下，API 账单 1.24 美元，加等待后 4.62 美元，其中 73% 是用户时间。

9. 最脆弱的假设

最脆弱的假设是：naïve laddering 依赖「可靠的外部正确性检查」。论文自己明确说了这个假设：「It requires a reliable external correctness check, which many deployments lack」。如果这个检查不存在、有噪声、或者检查本身很贵，laddering 的整个收益结构就崩了。

具体来说，laddering 的价值来自两个机制：一是保留低 effort 的初始成功，避免高 effort 在简单任务上超支；二是只在失败后升级，把高 effort 的钱花在刀刃上。如果正确性检查不可靠，会出现两种情况。假阳性（把失败判成成功）会让 laddering 在应该升级时停下来，丢掉高 effort 本来能解的任务。假阴性（把成功判成失败）会让 laddering 在不需要升级时多花一次高 effort 的钱，成本优势消失。

论文没有给出这个假设成立的证据。它只是说「where a reliable correctness check exists」，然后在这个前提下评估 laddering。对于 Terminal-Bench 和 SWE-Bench Pro，外部 verifier 是基准自带的，所以假设成立。但对于真实部署，比如用户让智能体写一段代码，谁来判定「这段代码对不对」？如果判定本身需要另一个模型或者人工审查，那 laddering 的成本结构就完全变了。论文在结论里也承认这是 stopgap 而非 solution。

10. 一周最小复现

目标：复现「高 effort 在 always-solved 任务上超支」和「naïve laddering 匹配或超过固定高 effort」这两个最核心的结论。

硬件约束：一张 24GB 消费级显卡。这意味着不能跑 GPT-5.6 或 Claude Sonnet 5 这种专有模型，只能跑开放权重模型。DeepSeek V4 Flash 是论文里成本最低的开放模型之一，但 24GB 显存可能不够跑满血版，需要量化或选更小的变体。如果 DeepSeek V4 Flash 不可行，可以用论文里的 Inkling 或 GLM-5.2 的小型变体，或者用任何一个支持 reasoning effort 的开放模型替代。

数据规模：不要跑全部四个基准。选 GPQA Diamond 的一个子集，比如 50 道题，每题 4 次尝试，两个 effort 级别（low 和 high）。GPQA 是单次调用，不需要智能体 harness，一周内能跑完。

具体步骤：

第一天，搭环境。装推理框架，加载模型，确认 effort 参数能通过 API 或本地推理设置。记录每个调用的输入 token、输出 token、推理 token。

第二天到第三天，跑 50 道题在 low 和 high 两个级别下各 4 次。记录每道题每个级别是否解出，以及每次调用的 token 用量。

第四天，算 always-solved 集合。取 low 和 high 都解出的题，比较这些题在两个级别下的平均成本。预期指标：high 的平均成本应该是 low 的若干倍，论文在 GPQA 上报告的最高倍数是 42 倍，但那是跨所有模型的最大值，单个开放模型可能低一些，比如 2 到 10 倍。

第五天，重建 laddering。对每道题，先看 low 的第一次尝试是否解出，解出就保留；没解出就假设升级到 high 并取 high 的第一次尝试结果。算 laddering 的成功率和总成本，与固定 high 比较。预期：laddering 的成功率不低于固定 high，成本更低。

第六天到第七天，写分析脚本，画成本对比图，算节省百分比。如果时间允许，加一个 none effort 级别，验证「禁用推理不省钱」是否在本地模型上成立。

关键注意点：本地模型的 effort 机制可能和专有 API 不同，论文在 related work 里提到不同模型的 effort 实现差异很大（gpt-oss 用系统提示词里的 effort 关键词，Qwen3 用推理时中断强制思考预算，DeepSeek-V4 用不同长度惩罚蒸馏专家）。复现时要先确认所用模型的 effort 到底控制什么。

11. 反例设计

核心主张是：naïve laddering（从最低 effort 开始，失败后升级到最高 effort）在所有模型和基准上匹配或超过固定最高 effort 的成功率，同时在多数情况下成本更低。

要推翻这个主张，设计如下实验。

选一个正确性检查有系统偏差的任务集。具体做法：构造或找一个任务集，其中低 effort 的失败模式和高 effort 的失败模式高度相关，即低 effort 解不出的题，高 effort 也大概率解不出，但高 effort 的成本显著更高。在这种情况下，laddering 会在大量任务上触发升级，付出两次执行的成本，却几乎不增加成功数。

判据：如果存在一个模型-基准组合，使得 laddering 的成功率显著低于固定最高 effort，或者 laddering 的总成本显著高于固定最高 effort 且成功率没有提升，那么「laddering 匹配或超过固定高 effort」这个主张就被推翻。

更尖锐的反例设计：找一个正确性检查本身很贵的场景。比如任务是需要人工专家审查的开放式生成任务，检查成本是每次 10 美元。laddering 的升级决策依赖检查，而固定高 effort 不需要检查。把检查成本计入总成本后，laddering 的成本优势可能完全消失甚至反转。

判据：如果加入检查成本后，laddering 的 full cost 超过固定最高 effort 的 full cost，且成功率没有显著提升，那么论文「laddering 是更优策略」的实践建议在该场景下不成立。

这个反例实验不需要推翻「高 effort 不保持低 effort 成功」这个描述性发现，它针对的是论文的规范性主张——laddering 作为可部署策略的优越性。论文自己在 3.4 节承认 laddering 依赖可靠外部检查，所以这个反例是在攻击论文已经意识到但未充分量化的那个假设。

12. 落地判断

用于「抢占式 GPU 自托管 27B 模型做多智能体脚手架」这个场景，论文的发现可以直接用，但有几个关键调整。

怎么用：第一，不要默认把 27B 模型的 effort 拉到最高。论文的核心发现是固定高 effort 不保持低 effort 成功，且在简单任务上超支。自托管场景里，抢占式 GPU 的算力是波动的，高 effort 意味着更长轨迹、更多 token、更长的 GPU 占用时间，这会增加被抢占的概率。所以默认应该用最低 effort。

第二，如果任务有可验证的结果（比如代码能跑通测试、命令能通过检查），用 laddering：先低 effort 跑，失败后再升级。这正好适合多智能体脚手架，因为脚手架通常有某种验证器或测试套件。

第三，把等待时间算进成本。自托管场景里，等待时间不是按美国时薪算，而是按 GPU 租用时长算。抢占式 GPU 按秒计费，长轨迹直接等于多花钱。论文的 full cost 公式可以改写成：总成本等于 GPU 租用时长乘以单价，加上被抢占后重跑的成本。

成本量级：27B 模型在 24GB 卡上，如果量化到 4-bit，推理速度大约每秒 20 到 40 个 token。一个多智能体任务如果跑 20 次模型调用，每次调用平均 2000 个输出 token，总输出就是 20×2000=40000 token，按每秒 30 token 算，纯生成时间约 22 分钟。抢占式 GPU 如果单价是每小时 0.3 美元，单任务 GPU 成本约 0.11 美元。如果高 effort 把轨迹拉长 3 倍，成本变成 0.33 美元，而且被抢占的风险从「低」变成「中」。这个量级下，laddering 省下的不是 API 账单，而是 GPU 租用时长和被抢占后的重跑成本。

最大的坑：自托管 27B 模型的 effort 机制可能和论文里的专有模型完全不同。论文在 related work 里列了多种实现：gpt-oss 用系统提示词里的 effort 关键词，Qwen3 用推理时中断，DeepSeek-V4 用不同长度惩罚蒸馏的专家。27B 模型如果是通用开源模型，可能根本没有原生的 effort 参数，需要自己在系统提示词里写「think step by step」或者限制最大 token 数来模拟 effort。这种情况下，论文的发现是否迁移，取决于这个模拟的 effort 是否真的改变了模型的策略分布，而不是只改变了输出长度。如果只是截断输出，那高 effort 不会带来论文里观察到的「更多检索、更多自我验证」的行为变化，laddering 的收益结构也会不同。