最近一个月AI 编码社区被一个叫 RTK 的说法刷了屏让模型在动手写代码之前先做一轮检索增强思考就能显著提高搞定复杂任务的成功率。我本来对这种“能力增益”型新闻已经习惯真正让我停下来的是 Quesma 这次选了个不同的角度他们不回答“RTK 能不能多过几个测试”而是直接晒价格。在 Terminal-Bench 2.1 这套终端任务基准上Quesma 的结论相当干脆RTK 并不让 AI 编码更便宜通过率的涨幅远赶不上成本和延迟的涨幅。这正好戳中我最近一直在想的一件事。过去半年大家聊 AI 编程翻来覆去就是 pass1 又涨了多少、哪个模型又刷榜了很少有人认真算过一笔账为了把通过率从 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 消耗、以及从任务开始到结束的墙钟时间。这个测试方案最聪明的地方是它没有只盯着通过率这一个数字。后面我会详细说只看 pass1 的话 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 pass1平均单任务 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 关键变量二失败重试才是账单杀手我在本地跑任务的时候经常被一个数据吓一跳真正让成本失控的并不是常规执行而是失败后的重试。普通模式下一个失败任务可能也就是损失几百个 tokenRKT 模式下一次失败意味着之前那些漫长的思考过程全部白费然后它还要在残留日志的干扰下重新开始第二轮 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 个成功。算下来常规模式的单位时间产出反而更高。这个视角在实际工程里比 pass1 更关键因为它直接对应你的交付效率。你的目标不是单个 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 能提升能力只是用真实数字告诉你这个提升是有标价的值不值取决于你打算怎么用它。我以前也喜欢盯着 pass1 的涨跌看觉得通过率就是一切多花点 token 又不心疼。踩过几次“开启后账单失控”的坑之后我现在的态度是功能是好功能但别默认开。把 RKT 装进工具箱让它在真正需要的任务里发光而不是像一个永远打开的跑马灯一样在每个任务上浪费你的钱和耐心。尤其是那些希望靠 AI 编码降本增效的团队我建议大家把 Quesma 这个结论复制到自己内部跑一遍。用你自己的模型、你自己的任务、你实际的并发配置量化出“每个成功任务成本”这个数字再决定要不要拥抱 RTK。别人的 benchmark 只能帮你理解趋势真正替你掏钱的永远是你自己的账单。