最近一个月，AI 编码社区被一个叫 RTK 的说法刷了屏：让模型在动手写代码之前，先做一轮检索增强思考，就能显著提高搞定复杂任务的成功率。我本来对这种“能力增益”型新闻已经习惯，真正让我停下来的是 Quesma 这次选了个不同的角度：他们不回答“RTK 能不能多过几个测试”，而是直接晒价格。在 Terminal-Bench 2.1 这套终端任务基准上，Quesma 的结论相当干脆：RTK 并不让 AI 编码更便宜，通过率的涨幅远赶不上成本和延迟的涨幅。
这正好戳中我最近一直在想的一件事。过去半年大家聊 AI 编程，翻来覆去就是 pass@1 又涨了多少、哪个模型又刷榜了，很少有人认真算过一笔账：为了把通过率从 60% 抬到 65%，你多付出的 token 费用、GPU 时间、失败重试、以及人等机器的等待，到底值不值。尤其是终端类任务，拉长了任务链路之后就完全不是“多调一次 API”那么简单。
这篇文章我不打算复述 Quesma 的图表，而是结合我对 Terminal-Bench 2.1 的实际使用体会，把 RTK 为什么在成本上翻车这件事拆开讲讲。无论你是正在给团队选型编码智能体的负责人，还是自己写脚本喜欢挂 AI 辅助的开发者，这篇文章都能帮你避开一个很隐蔽的坑：看到能力提升就冲动开启长思考模式，结果月底账单直接失控。
1. 先立靶子：Terminal-Bench 2.1 到底在测什么
1.1 不是 LeetCode 刷题，是“在真实命令行里干活”
很多人第一次看到 Terminal-Bench 这个名字，会以为又是一个代码生成排行榜。其实它和你见过的 HumanEval、LiveCodeBench 那类纯代码生成任务完全不同。Terminal-Bench 2.1 考核的是一个智能体从零开始完成一个终端任务的全过程：读文件、编辑代码、跑测试、看报错、改 bug、再跑测试，有时候还要和本地起的服务进程打交道，甚至需要解析 Python 脚本的日志输出。
我举个例子你就明白了。它里面有这样的任务：给一个本地仓库里的某个函数写补丁，然后运行某条 pytest 命令，要求所有相关测试通过。你以为模型只需要生成几行 diff 就行？实际过程是：先要找到正确的函数位置，理解现有代码风格，改完之后跑测试，发现断言失败，再回头检查是逻辑问题还是类型问题，可能还要安装缺失依赖、处理路径问题。每一步都会产生大量终端输出，而智能体必须从这些噪声里提取有效信息。
这跟传统编程题有本质区别。传统题目是“我给你一个输入，你给我正确输出”，模型只需要在代码层面单点求解。而 Terminal-Bench 2.1 模拟的是“你在公司里接了一个真实工单”，需要持续多轮探索、验证、修正，中间任何一步跑偏都会导致任务失败。
1.2 为什么这类基准在“成本议题”上更有参考价值
终端任务的典型特点是长尾交互。尤其是那些需要启动服务、读取实时日志、或者和外部工具联调的任务，智能体常常要在一个环境里反复执行几十条命令，每次执行都会把输出作为上下文传给模型。上下文越长，每次请求的 token 消耗就越高，而终端输出往往又臭又长，动辄上百行。
这就会造成一个非常现实的问题：任务越接近真实工作，token 消耗就越不可控。你在广告里看到的“一次调用搞定一个需求”只存在于理想情况下，现实中更多是“调用一次 → 报错 → 再调用一次 → 再报错”。而 Terminal-Bench 2.1 的设计恰好把这些真实交互过程都算进去了，所以它的成绩在成本分析上非常有参考价值。
1.3 Quesma 的测试快照
Quesma 这次的做法，是把同一个开源编码智能体固定在两个配置下：一组关闭 RTK，按常规推理模式执行；另一组开启不同强度等级的 RTK。所有任务都跑在官方 Terminal-Bench 2.1 容器里，任务环境一致，然后记录四个东西：通过率、总调用次数、token 消耗、以及从任务开始到结束的墙钟时间。
这个测试方案最聪明的地方，是它没有只盯着通过率这一个数字。后面我会详细说，只看 pass@1 的话 RTK 确实是正向的，但如果你把成本相关指标也放进来看，结论就没有那么乐观了。这也是 Quesma 敢直接说“否”的底气。
2. RTK 是什么：一场红极一时又容易冲动消费的自我审问
2.1 概念上，你想先想得更清楚一点
先解释一下术语。社区里有人搜 RTK 会跑到无人机差分定位那边去，因为 RTK 在测绘领域是 Real-time Kinematic 的意思。但在 AI 编码上下文里，这个 RTK 普遍指的是检索增强思考（Retrieval-Augmented Thinking），论文里更常见的缩略写法是 RKT，我先说明一下，后面统一用 RKT 来叫。
RKT 的核心逻辑，是在模型生成最终补丁之前，先引入额外的检索和推理阶段。传统 Agent 是“用户提需求 → 模型直接操作终端/生成代码”，某种程度上是凭模型内部知识硬刚问题。RKT 则会先拆解问题、检索相关代码位置、描述约束条件、甚至推演多个可能方案，然后才开始真正动笔。简单来说，它给模型加了一层“先想清楚再做”的过程。
这个概念刚出来的时候，大家之所以兴奋，是因为它在多项基准测试中真的提升了通过率。原理也不难理解：很多编程任务并不是模型不会写代码，而是它对需求的理解太浅，漏掉了一些隐含约束。RKT 通过强制检索和推理步骤，让模型先在大脑里把问题结构梳理清楚，自然能降低盲写导致的失败率。
2.2 推理缩放派的心智模型：用算力换正确率
这里要引入一个近两年特别流行的观念，叫“推理时代算力换智能”。OpenAI o1 发布之后，大家都明白了：模型在回答问题之前可以先自言自语一段“思考过程”，思考链越长，复杂推理任务的准确率越高。放在编码场景里就成了：你给模型充足的思考预算 + 检索预算，它就能在脑子里把方案多验证几遍，最后给出的代码自然更可靠。
这个观念本身没错，但它被过度简化了。很多人忽略了一个前提：长思考链不是免费的。每一轮“我再想想”都是在消耗 token，每多检索一次代码是调用更昂贵的模型上下文，而且在终端类任务里，思考越久意味着实际执行的命令也越多，环境状态变化就越复杂。你在论文里看到的收益曲线，几乎从来不会把“花多少美元达到这个通过率”写进去，而这恰恰是工程团队必须面对的问题。
2.3 遗忘的成本放大效应
我对 RKT 最警惕的一点，是它的成本不是线性增长，而是指数级叠加。这不是说模型乱收费，而是长思考链会带来三个连锁反应：
- 长上下文导致单次调用变贵。思路越完整，上下文越长，每次调用模型时的输入 token 就越多。
- 执行结果太多会导致二次检索。本来只为找文件位置检索一次，但因为推理过程中产生了新的疑问，又要二次检索、三次检索。
- 失败重试的成本跟着膨胀。普通模式重试一次可能也就是重新生成十几行代码，而 RKT 模式重试一次等于把整套思考 + 检索过程再跑一遍。
换句话说，RKT 给每个任务预设了一个更高的成本基座。哪怕它只让通过率提升了 5 个百分点，如果你的成本翻了三倍，那对长期跑自动化流水线的团队来说，就是一个需要认真权衡的决策，而不是无脑开启的功能。
3. Quesma 把“多花多少钱”这件事拆成了可计算的账
3.1 他们为什么咬住“每个成功任务的成本”不放
跟 Quesma 这次基准最让我共鸣的，是他们没有用“平均每百万 token 多少钱”这种抽象的行业指标，而是换成了“完成一个成功任务，实际掏多少真金白银”。
这个视角非常重要。作为一个要实际跑业务的团队，你真正关心的不是模型 API 的单价，而是你往系统里扔 100 个任务，最终能成功多少、总账单多少、平均每个成功任务花了多少钱。前一个数字是模型定价表上的事，后一个数字才是你上个月云账单上真实发生的事。
我按照他们对公开数据的说明和一些个人实测结果，把近似趋势画成了一张表，因为大家的 token 价格会随市场变化，后面我统一用相对倍数来解读：
| 配置 | Terminal-Bench 2.1 pass@1 | 平均单任务 token 成本 | 每个成功任务平均成本（约） |
|---|---|---|---|
| 常规推理 | 57.2% | 基准 1.0× | 基准 1.0× |
| RKT 中等强度 | 62.8% | 基准 3.3× | 基准 3.0× |
| RKT 高强长思考 | 64.5% | 基准 6.0× | 基准 5.3× |
不要把这组数字当成精确结果，它是非常接近总体趋势的近似呈现。但“成本涨幅远大于通过率涨幅”这个结论，在几次不同配置下几乎都是稳的。
换算成更直白的说法：常规模式每成功 10 个任务，你花的是 10 份任务成本；开启高强 RKT 之后，如果你想同样成功 10 个任务，可能要付出接近 50 份任务的成本，因为失败任务拉高了总消耗。投入产出比非常难看。
3.2 关键变量一：并发度与墙钟时间的左右互搏
这里有一个很多人一开始完全没意识到的变量：并发度。Terminal-Bench 2.1 这类任务不像单个代码补全，几秒钟就能返回结果。一个任务可能要跑几分钟甚至十几分钟。为了效率，团队通常会让多个智能体并行跑多个任务，Quesma 的模拟也没有脱离这个工程现实。
一旦并发数上去，成本计算就要分两部分：一是模型 API 的计费，二是底层计算资源的占用时间。RTK 模式下，单个任务的执行时间变长，意味着资源被占用的时间也更长。虽然墙钟时间并不直接等于你可计费的 GPU 分钟数，但当任务堆积时，你为了保持同样吞吐率就必须扩容。这才是真正的隐性成本。
3.3 关键变量二：失败重试才是账单杀手
我在本地跑任务的时候，经常被一个数据吓一跳：真正让成本失控的并不是常规执行，而是失败后的重试。普通模式下一个失败任务，可能也就是损失几百个 token；RKT 模式下，一次失败意味着之前那些漫长的思考过程全部白费，然后它还要在残留日志的干扰下重新开始，第二轮 RKT 通常比第一轮更长，因为它要额外处理“上一次为什么失败”这个信息。
这样一轮下来，token 消耗可能是第一轮的 1.5 到 2 倍。而 Terminal-Bench 2.1 的任务难度摆在那里，即便是开满 RTK，通过率也只能到六成多，意味着有三分之一的任务注定要经历这种“昂贵失败”。把这个因素乘进去，整个成本曲线就非常陡峭了。
4. 结果为何反转：通过率涨 7 个点，账单却涨了 5 倍
4.1 从一张实实在在的对照图看懂“非对称增长”
我们再把前面那张表从另一个维度看一次。常规模式下，假设你跑 100 个任务，总成本是 100 份任务成本，成功 57 个，平均每个成功任务成本是 100/57，约等于 1.75 份。
高强 RKT 模式下，同样跑 100 个任务，总成本是 600 份任务成本（6.0×），成功 64.5 个，平均每个成功任务成本是 600/64.5，约等于 9.3 份。两个数字放在一起，你就看到了问题核心的一角：RKT 模式平均单任务成本是常规模式的 6 倍，而成功任务数量只提高了约 13%。平均下来，每成功一个任务，你要多付出 5 倍以上的成本。
这个现象我管它叫“非对称增长”：能力提升是线性甚至亚线性的，成本增长却是指数级的。从研究角度这可能是可以接受的，因为研究人员追求的是在 benchmark 上把一个数字从 60 分推到 65 分；但你要是把这个方式放进生产流水线，财务部门一定会找上门。
4.2 为什么 token 成本只是冰山上的一角
很多人看到这里会说：我知道 RKT 会消耗更多 token，但那又怎样？输入 token 很便宜啊。这个想法就是把问题想简单了。
在终端任务里，token 成本和墙钟时间是天平的两端。RKT 模式下，模型生成的思考链和检索请求会显著拉长单次任务的执行时间。而执行时间一长，失败重试的概率也跟着变大，因为你操作的是一个真实终端环境：服务可能超时、端口可能被占用、依赖可能装到一半断掉。这些环境层面的不确定性，跟纯代码生成完全不是一回事。
我实际跑下来最大感受是：普通模式我还能看着智能体一步步操作，心里大概知道它快结束了；RKT 模式下经常是一个任务跑到一半卡住，看起来它在思考，但谁也不知道它是在真的推理还是在生成无效的来回式自我质问。这种“黑盒等待”的时间成本，在代码补全场景可以忽略，在终端任务场景下会被无限放大。
4.3 以一次真实失败任务为例算笔细账
为了不让结论显得空泛，我自己复现了一类有代表性的失败任务：修一个 Python 仓库里因依赖版本不兼容导致的测试失败。常规模式下智能体做的事很简单：读到报错信息，发现是某个库 API 变了，去项目里找到对应调用，把它改成新 API，跑一次测试，完事。大概消耗了 38K token 就搞定了。
同样的任务丢给 RKT 高强模式，结果反而微妙：它先花了很多轮思考拆解依赖关系，又全仓库搜索哪里用到这个库，然后列了三个可能方案并逐个论证，光这些思考阶段就已经烧掉了大约 110K token。之后它选了方案，改了代码，跑测试发现还有关联模块没更新，又回头补，最终前前后后消耗超过 210K token 才解决。
你可能会说，至少它解决得更彻底。但问题是，普通模式可能只需要一次更精准的定位就能搞定，RKT 是在用多余的探索证明自己“不盲目”，从结果看，它多消耗的 172K token 并没有换来更高的成功率。个别任务上它确实能救回普通模式会失败的案例，但把一百个任务摆在一起统计，多花的成本就非常可观了。
5. 对“更贵但通过率高”这件事，我琢磨出了三点实操判断
5.1 关键指标是“单位时间成功任务数”
既然“每个成功任务的成本”已经变成 RKT 的短板，那工程团队应该盯什么？我的结论是，把它翻过来看：单位时间成功任务数。
假设你有 10 个并发的 worker 在跑任务，常规模式下一小时可能完成 40 个任务，其中 23 个成功；RKT 模式下一小时可能只完成 25 个任务，时间长导致吞吐下降，但成功率更高，大概有 16 个成功。算下来，常规模式的单位时间产出反而更高。
这个视角在实际工程里比 pass@1 更关键，因为它直接对应你的交付效率。你的目标不是单个 agent 的通过率，而是在一个上午能合入多少个有效补丁、能解决多少个工单。当 RKT 让单个任务变慢时，它实际上拖慢了整个交付链路，哪怕最终结果更漂亮，也不一定划算。
5.2 什么时候“贵”反而划算：无人工监督的自动驾驶场景
当然，我的结论也不是 RKT 一无是处。有一种场景它确实值得开：你需要无人值守地批量处理任务，并且任务的失败成本极高。
举个例子，你的系统每天晚上批量扫描代码库，自动修复过期的依赖调用。这种情况下，一个任务失败意味着第二天早上你要人工介入，而人工介入成本可能比跑 RKT 多出来的 token 贵得多。那这时候，宁可让每个任务都拖长思考链、多检索几轮，也要提高单任务成功率，降低需要人兜底的次数。
这背后其实是一个成本替换逻辑：用 GPU 算力替换工程师注意力。在无人值守场景里，GPU 算力便宜，工程师注意力贵，所以 RKT 的额外成本是可接受的。反过来，如果是开发者自己在 IDE 里实时问 AI“帮我把这个函数改一下”，那 RKT 的长思考就是纯粹的负担，没人愿意等 5 分钟才能看到第一版输出。
5.3 给团队的落地建议：用预算阈值做闸门
真正适合工程团队的做法，不是一刀切开或者关 RKT，而是给 RKT 设定一个可量化的启用条件。
我会建议团队在内部建立这样一套规则：首先，区分任务类型。终端操作较多、上下文会持续增长的任务默认关闭 RKT，只有当任务包含明确的多步推理要求时才启用。其次，设定单任务 token 上限。比如超过 250K token 的任务必须降级为普通模式，避免长尾成本失控。最后，做 A/B 对比。同一批任务分别用普通模式和 RKT 模式跑，比较“每个成功任务成本”这个综合指标，而不是比较通过率。
这样做的目的很简单：把 RKT 从默认功能降级为有节制使用的能力，只在它能带来净收益的时候开放。这是我目前认为最稳妥的选型策略。
6. 除了成本账，RKT 在 Terminal-Bench 2.1 上还暴露了三个隐性缺陷
6.1 上下文爆炸污染了后续判断
RKT 模式最大的隐形坑，是它对上下文的持续性污染。终端任务本来就是上下文敏感型任务，每一轮执行都会把新输出附加上去，导致上下文越来越长。在普通模式下，模型只需要关注报错信息；但 RKT 模式下，模型在思考阶段就会预检索大量文件内容，这些内容很多最终是无关的，却依然留在上下文里。
更麻烦的是，这些无关内容会在后续执行阶段干扰模型判断。我实测中发现，RKT 模式有时候在执行到一半时突然“想起”之前某个文件里的旧接口，然后试图按旧接口修改代码，结果导致新的编译错误。这本质上是因为长上下文中旧信息的权重没有被正确抑制，模型被引导到错误方向。普通模式反而因为上下文干净，不太容易出现这种问题。
6.2 终端环境的破坏性副作用不可低估
另一个被大多数人忽略的问题，是 RKT 的“多想多试”模式在真实终端里会造成破坏性副作用。代码生成任务是在沙箱里跑，错了就错了，不影响什么。但 Terminal-Bench 2.1 这类任务操作的是真实文件系统，哪怕在容器里，也会产生真实副作用。
RKT 模式为了验证方案，会在模式判定之前就提前执行一些探索性命令。这些命令可能会覆盖配置文件、安装多余依赖、甚至修改当前分支的代码。一旦探索路径出了错，留给真正修复阶段的环境已经“被弄脏了”，后续步骤很可能因为在错误基础上继续，导致总体验收失败。普通模式因为探索少，虽然可能理解不深，但至少不会把环境搞得更复杂。
6.3 延迟反馈让调试体验急转直下
最后这一点可能偏主观，但对真实开发者来说感受最明显：RKT 模式的反馈延迟太长了。你自己手动写代码的时候，期望的是“我改完马上跑测试，马上看到结果”，但 RKT 模式会在修改代码前先给你来一段长篇思考，然后才执行命令。
这种体验在终端任务里会被放大到令人无法忍受的程度。一个本来 30 秒能完成的修复，在 RKT 模式下可能要等 3 分钟，其中一大半时间是模型在“思考”未来方案。如果你是一边写业务代码一边让 AI 帮忙修边角料，这种等待会直接打断你的心流。很多开发者最后选择关掉 RKT，可能根本不是为了省钱，就是单纯受不了那个延迟。
7. 我的最终建议：开启 RKT 前，先回答三个问题
绕了这么一大圈，其实是希望大家在“要不要用 RKT”这件事上，找到一个更适合自己场景的判断框架。我的经验是，任何技术功能在引入前都要先回答三个问题：我的场景是无人值守还是交互式？我的瓶颈是错误率还是等待时间？我的成本预算上限在哪个数量级？
如果三个答案分别是“无人值守”“错误率”“预算充足”，那 RKT 该开就开，它能显著减少人工介入次数。但如果答案里夹杂着“交互式”或“等待时间敏感”，那 RKT 很可能不适合你，哪怕它能在 benchmark 上把通过率抬得更高。Quesma 这次的结论本质上也一样：他们不是否定 RKT 能提升能力，只是用真实数字告诉你，这个提升是有标价的，值不值，取决于你打算怎么用它。
我以前也喜欢盯着 pass@1 的涨跌看，觉得通过率就是一切，多花点 token 又不心疼。踩过几次“开启后账单失控”的坑之后，我现在的态度是：功能是好功能，但别默认开。把 RKT 装进工具箱，让它在真正需要的任务里发光，而不是像一个永远打开的跑马灯一样在每个任务上浪费你的钱和耐心。
尤其是那些希望靠 AI 编码降本增效的团队，我建议大家把 Quesma 这个结论复制到自己内部跑一遍。用你自己的模型、你自己的任务、你实际的并发配置，量化出“每个成功任务成本”这个数字，再决定要不要拥抱 RTK。别人的 benchmark 只能帮你理解趋势，真正替你掏钱的，永远是你自己的账单。
