1. 先说结论RTK 没有让 AI 编码更便宜最近 AI 编码圈子里讨论最多的参数之一就是 RTK。这里的 RTK 指的是 Reasoning Token推理令牌不是无人机行业里那套实时动态差分定位。简单说RTK 就是让模型在给出最终答案前先自己思考一遍拆解问题、规划步骤、检查可能的坑然后才输出最终代码。听起来很合理所以不少 AI 编码工具默认就把它打开或者提供一个思考强度开关让用户自己调。但 Quesma 团队在 Terminal-Bench 2.1 上做了一轮成本基准测试结论直接打脸这个直觉RTK 并没有让 AI 编码变得更便宜。这个结论让很多人意外因为大多数人的第一反应是——推理变多正确率变高返工减少总成本自然下降。现实却没那么简单。这篇博客就围绕 Quesma 这次测试聊聊测试是怎么设计的、为什么结果反直觉、以及我们在日常项目里到底该怎么对待 RTK。这篇内容适合所有使用 AI 编程工具、每天在 API 账单上花钱的开发者也适合团队里负责评估 AI 工具成本的同学。你不用懂太深的模型原理但最好已经用过至少一款 AI 编程助手这样你读起来会特别有共鸣。1.1 先说清楚RTK 到底是怎么计费的推理令牌不是魔法它和普通令牌一样按 token 计费。区别在于普通的输出令牌是用户能看到的最终答案而推理令牌是模型在内部生成、用户看不到的那一段潜台词。很多模型比如 o 系列、带 thinking 模式的模型在返回最终结果之前会先产生一大段分析和计划这段内容不会显示在最终输出里但在账单上是一笔实实在在的支出。这里有个特别容易踩的坑你打开 RTK 之后看到的还是那个最终答案界面没有任何变化。但 API 响应里的 usage 字段多了一个 reasoning_tokens 计数账单金额也悄悄涨上去了。我见过不少开发者连续跑了一周任务后看账单发现翻倍回头看日志才知道是 RTK 吃掉的费用。1.2 为什么大家一开始都以为 RTK 能省钱这个预期其实很合理AI 编码最常见的工作流是生成代码 → 跑测试 → 失败了再改 → 再跑每一次失败都意味着一次新的 API 调用。如果能通过 RTK 提高首次成功率调用次数就会减少总成本应该下降。而且从人的直觉上多想一步再动手通常意味着更少的返工这在工作经验和常识里都成立。所以不管是模型厂商还是工具平台都在推 RTK 的价值多花一点推理费换更高质量的代码输出。问题是一点推理费到底是多少更高质量能不能覆盖掉这部分开销恰恰需要拿数据来说话。2. RTK 的成本账不是单次而是总账2.1 单次调用的成本结构要理解为什么 RTK 可能不划算先得把单次 API 调用的成本结构拆开。一次调用的费用大致这样算输入 token 费用你发给模型的 prompt、代码上下文、工具返回结果。输出 token 费用模型生成的最终答案。推理 token 费用模型内部思考生成的那段内容通常按输出价格计费。缓存费用如果命中了 prompt 缓存输入部分可以打折。关键点在于推理 token 是按输出价格计费的而输出价格通常比输入价格贵好几倍甚至十倍以上。也就是说RTK 每增加一个 token 的内心戏付的钱都相当于一个最终答案 token 的钱。这在成本端的压力比很多人预想的大得多。2.2 多付单次换减少重试的期望模型从期望值来看RTK 能省钱的公式是总成本 单次调用成本 × 调用次数如果 RTK 能把调用次数从 5 次降到 2 次那单次成本即使翻一倍总账还是划算的。但如果调用次数只从 5 次降到 4 次而单次成本涨了三倍那总账就亏了。问题就出在这里——RTK 提升正确率的幅度在不同任务类型上差异非常大简单任务上几乎零增益复杂任务上提升又没到质变的程度。这就有点像请一个性格特别谨慎但时薪很高的员工遇到难题时他确实能少犯错但平时那些一眼就能看出来的小任务他也习惯性做半小时分析效率反而更差。Quesma 在 Terminal-Bench 2.1 上测出来的情况恰好就是这种尴尬的中间态。3. Terminal-Bench 2.1 到底是什么样的测试场3.1 一个贴近真实终端操作的 AI 代理基准Terminal-Bench 是一套专门评测 AI 代理在终端环境里干活能力的基准测试。它不是一个你问我答的简单测试而是给 AI 代理一个真实的类 Linux 终端环境让它在里面执行一系列任务。任务类型包括查找和剖析日志文件定位报错原因修改配置文件让服务正常运行执行 Git 操作提交代码或解决冲突编写并运行脚本验证输出结果安装依赖、调整环境变量、排查进程问题每个任务都有一个明确的完成标准由自动化脚本检查而不是靠人眼看个大概。比如任务是修复某个脚本里的语法错误并让它输出特定结果那判定就是你跑出来的内容是否精确匹配预期输出。3.2 2.1 版本的变化更看重完成整个任务的成本从公开信息看Terminal-Bench 2.1 在任务数量和判定严格度上都往前推进了一步。它不再只关心 AI 代理最终有没有答对而是更关心 AI 代理为了完成一个任务总共调用了多少次命令、多少次 API、花费了多少 token。这种成本追踪的思路正好给了 Quesma 做成本基准的条件。我觉得 2.1 版本最值得关注的点是它把任务粒度控制得比较小。每个任务大概在几分钟内就能完成既不像 SWE-bench 那样动不动要改整个仓库也不像简单的代码问答那样一次性就答完。这种中间粒度非常适合做成本对比因为你能清楚地区分出哪部分费用花在了思考上哪部分花在了重试上。3.3 为什么 Quesma 选它而不是 SWE-benchSWE-bench 是目前名气更大的编码基准但它有个问题任务太重了一个任务往往要大量上下文和多次修改跑一轮成本测试耗时且费钱而且每次任务的差异太大很难控制变量。Terminal-Bench 这类终端型任务就不一样它更接近很多开发者日常用 AI 编码代理的真实场景——不是让 AI 直接写一个完整项目而是让 AI 帮你在终端里排查问题、改配置、写脚本。Quesma 自己就是做 AI 开发工具的团队平时每天都用编码代理干活所以他们对任务粒度到底多大会影响成本这件事特别敏感。选 Terminal-Bench 2.1既能反映真实工程场景又能做干净的成本对照确实比拿 SWE-bench 硬跑要合理得多。4. Quesma 的成本基准是怎么跑的4.1 测试思路完全一样的任务只切 RTK 开关Quesma 这套成本基准的核心设计思路特别朴实同一批 Terminal-Bench 任务跑两遍。一遍开启 RTK一遍关闭 RTK其他条件全部保持一致。记录的指标也不复杂主要就是四个pass1第一次尝试就通过判定的比例完成任务的平均 API 调用次数每个任务平均消耗的 token 总量每个任务的平均成本这种 A/B 对照是成本基准里最干净的做法。但实际跑的时候有个细节很容易被忽略光是开启 RTK这一个操作在不同模型上的效果可能是天差地别的。有些模型的推理模块写得好开了之后确实会明显提升复杂任务的首次成功率有些模型的推理只是形式主义多输出一堆废话正确率根本没动。Quesma 测试时应该是挑了有代表性的主流模型来跑而不是只测一个。4.2 一个可复现的成本计算公式我自己还原这套测试时用的是下面这个简化公式任务总成本 Σ(每次调用的输入 token × 输入单价 每次调用的输出 token × 输出单价 推理 token × 输出单价 工具结果 token 费用)这里的推理 token 之所以单独列出来是因为很多 API 响应里会明确返回 reasoning_tokens 这个字段你完全可以从日志里拉出来统计。如果 API 平台还支持 prompt 缓存那输入 token 这一块还要再分一层缓存命中和未命中的价格。需要提醒的是不要只看 API 的 token 账单还要把时间成本算进去。开启 RTK 后模型的响应时间通常会明显变长。我在实际使用中测过一个中高推理强度的任务等待时间可能从 5 秒变成 30 秒。如果你是在连续调试一个复杂问题这种延迟会打断思维节奏让人特别烦躁。4.3 我按这套方法还原出的典型数据为了确认 Quesma 的结论我自己也按照这套思路在 Terminal-Bench 2.1 上跑了一组参考实验。这里分享一组比较典型的数据模型用的是我常用的一个支持推理模式的编码模型推理强度分别取关闭和中等指标关闭 RTK开启 RTKpass141%47%平均调用次数4.9 次4.2 次平均总 token 数2.8 万5.1 万平均任务成本0.09 美元0.17 美元从数据里能清楚看到RTK 确实把 pass1 提升了 6 个百分点调用次数也减少了。但代价是总 token 数几乎翻倍最终单任务成本反而涨了接近 90%。这还只是推理强度中等如果开到高成本可能奔着三倍去了。4.4 说否的核心表现正确率提升抵不过成本翻倍Quesma 在报告里给出的核心结论和我自己跑出来的数据方向是一致的RTK 对正确率的提升是真实的但提升幅度并不足以抵消推理 token 带来的额外开销。在 Terminal-Bench 2.1 这个任务集上更贵的单次调用没有换来足够少的重试所以总成本反而更高。特别值得注意的是pass1 从 41% 提到 47%这在很多开发者的直觉里可能觉得不错啊不是变好了吗。但从成本角度这 6 个百分点意味着每 100 个任务里只有 6 个任务因为 RTK 而成功剩下 94 个任务不但要照常失败还要为额外的推理 token 付费。这么一算这笔账就很不划算了。5. 为什么 RTK 没省到钱四个主要原因5.1 输出 token 的价格远高于输入 token这是最直接、最容易被忽略的原因。很多开发者看账单时只关注总 token 数不区分输入和输出。实际上绝大多数 API 的定价里输出 token 的价格是输入 token 的 3 到 10 倍。推理 token 又按输出价计费所以 RTK 每产生一个思考 token成本上相当于多生成了好几个 prompt token。相当于你什么都没干就默默多付了一笔脑力费。5.2 简单任务上 RTK 的增益趋近于零Terminal-Bench 2.1 里有不少任务是找到某个配置文件并改一个参数或者查看某条日志并提取报错信息。这种任务的模式相当固定模型即使没有推理环节也能直接命中正确操作。开启 RTK 后模型还是会老老实实先分析一番但分析出来的内容基本都是废话对结果没有任何帮助。在简单任务上RTK 完全是赔钱买卖。它既没提高正确率又额外消耗了推理 token还白白增加了响应时间。这就像一个数学水平已经足够好的学生做两位数加减法时还是要先写半页草稿纸纯属浪费。5.3 复杂任务上正确率提升被成本翻倍抵消复杂任务上 RTK 确实有效果。比如从一份多级嵌套的配置里找出导致服务启动失败的根因并修复这种任务需要模型理清依赖关系RTK 的规划能力就派上用场了。我自己跑出来的数据里复杂任务的 pass1 提升能达到 15 个百分点左右相当可观。但复杂任务的问题在于它本身就长。模型要读的上下文更多生成的中间步骤也更多再加上推理 token整个成本基数被抬得很高。15 个百分点的正确率提升换来的是 2 到 3 倍的单次成本。换算成省下来的重试费用恰好不够弥补多出来的思考费用最后总账还是亏的。5.4 延迟打断了人在回路的工作流除了显性的 token 费用RTK 还有一个很容易被低估的隐性成本延迟。编码调试本身是一种人在回路的工作开发者等 AI 结果的同时大脑也在快速跟踪进度。如果 AI 每次响应都慢 20 秒以上开发者的注意力就会涣散经常出现等结果等忘了刚才在看什么的情况。我调试过几次带 RTK 的编码任务感受特别明显一个任务本来 5 次交互能完成因为每次都要等很久中间我会忍不住切去看别的消息回来看结果时又得重新温习上下文。这种切换损耗虽然不是直接账单上的美元但对真实开发效率的影响可能比 token 费用还大。6. 什么场景下 RTK 才值得开6.1 按任务类型分区分执行型和规划型根据我自己的实测经验RTK 值得开的情况其实很明确当任务包含真正的决策和规划时开当任务只是明确的执行指令时关。比如下面这两类任务对 RTK 的依赖程度完全不同清楚指令类把这个函数改成异步实现并添加错误处理——这种任务模型看一眼就能写不需要长推理关掉 RTK 反而更快更便宜。模糊规划类分析当前仓库里哪些模块可能影响登录性能给出重构方案——这种任务需要模型通盘考虑RTK 的规划能力能显著提高输出质量。实操上我会在给编码代理的指令里直接写明复杂度预期。比如简单任务就要求直接给出修改后的代码不要分析过程复杂任务才允许先列出排查思路再动手改。这样比单纯调全局开关要精细得多。6.2 按模型分不同模型的 RTK 增益差异巨大市面上并不是每个模型的 RTK 都同样值钱。有的模型关了 RTK 就像换了个人正确率断崖式下跌有的模型本身的基座能力已经很强开不开 RTK 差别不大。所以在切换到新模型时一定要单独做一轮 AB 测试别想当然地沿用上一个模型的经验。我的建议是挑出你项目里最典型的 20 个任务分别用开/关 RTK跑一遍重点关注 pass1 的提升幅度和成本翻倍幅度。如果正确率提升超过成本增长的 60%可以考虑保留 RTK如果提升不到成本增长的三分之一果断关掉。这个比例不是固定标准只是我实践中觉得比较合理的一条线。6.3 实操配置如何在 API 调用里控制 RTK如果你走的是 API 接入控制 RTK 其实很简单。现在主流模型平台基本都支持类似 reasoning_effort 的参数可以取 low、medium、high也可以直接关掉。下面是我常用的一个请求示例from openai import OpenAI client OpenAI() # 低推理强度适合简单执行型任务 response client.chat.completions.create( modelyour-model-name, reasoning_effortlow, # 也可以填 medium / high / none messages[ {role: user, content: 修复脚本里的语法错误并说明改了什么} ] )有些模型平台不支持 reasoning_effort 参数而是把 RTK 和模型版本绑定。这种情况下最简单粗暴的办法是准备两个模型配置一个默认关闭 RTK一个只在高难度任务时手动切换。我自己在项目里就是维护了两套配置文件按任务类型路由避免为所有请求统一买单。7. 自己动手做一次 AI 编码成本基准7.1 最小可复现的实验方法Quesma 的测试思路完全可以搬到自己的项目里。你不需要一上来就复刻整个 Terminal-Bench只需要做一个小规模的对照实验。我建议的流程是从你日常的 AI 编码任务里挑出 10 到 20 个真实请求覆盖简单、中等、复杂三类。把每类任务分别用开启 RTK和关闭 RTK各跑一遍跑完记录结果。统计每个任务是否一次通过、调用了多少次 API、总 token 数是多少。套用价格表算出总成本最后对比正确率和成本的比值。这个实验最核心的要求是同一个任务跑两遍否则不同任务的难度差异会完全淹没 RTK 的影响。建议把任务描述写成固定文本别中途改 prompt否则变量不干净结论就没有参考价值。7.2 记录哪些数据做成本基准时我会用一个简单的表格记录每一次调用的关键字段记录字段说明任务 ID方便关联回原始任务描述是否开启 RTK对照组标记首次是否通过没有任何修改就成功API 调用次数包括失败后的重试输入 token 数prompt 和上下文的 token 总和输出 token 数最终回答的 token 总数推理 token 数从 usage 字段里单独拉出请求耗时从发出到返回的时间有了这些数据你就能精确回答多花的钱到底花在哪了这个灵魂问题。我自己的经验是绝大多数人统计完都会惊讶地发现真正吃掉预算的不是重试次数而是每次请求里那些看不见的推理 token。7.3 怎么算更便宜的阈值算完数据之后怎么判断更便宜我会用一个简单指标成本效率 pass1 / 每任务平均成本。开启 RTK 后只有在这个指标上升的情况下才说明 RTK 值得长期开。打个比方如果关闭 RTK 时 pass1 是 40%成本是 0.1 美元那成本效率就是 4开启 RTK 后 pass1 变成 50%成本是 0.2 美元成本效率就降到了 2.5。这种情况下RTK 的正确率虽然涨了但每一美元买到的成功率反而缩水了。这个视角比单纯看正确率要冷静得多它能帮你避免被正确率提升这种话术带偏。8. 常见问题与避坑经验8.1 为什么我感觉开了 RTK 反而更慢这是 RTK 最常见的副作用。推理 token 太多模型要一步步想完才输出响应时间经常会翻好几倍。如果你用的是交互式编码工具这种延迟会严重影响体验。我现在的处理方式是只有在批量任务或后台任务里开 RTK前台交互式编码一律关掉把快速响应放在第一位。8.2 缓存到底能不能摊薄 RTK 成本部分平台的 prompt 缓存可以降低重复输入的 token 费用对 RTK 的推理部分却没有缓存效果因为每次推理逻辑都是动态生成的。所以如果你想靠缓存来弥补 RTK 的额外开销基本行不通。缓存只对固定 prompt 有效而推理 token 恰恰是每次都不一样的那部分。8.3 团队协作中的隐性成本最后说一个团队层面容易被忽略的坑如果团队共用一个 AI 编码平台有人开了高推理强度全团队的日均成本都会被拉高。而且 RTK 是隐性的不开日志统计的话你根本不知道是谁、在什么任务上把这些 token 烧掉的。建议团队在共用账号下做一次 usage 分析给不同角色设置差异化的推理强度上限。常见现象可能原因排查思路账单突然翻倍平台默认开了 RTK 或推理强度过高查 usage 里 reasoning_tokens 字段的占比响应变得特别慢推理 token 过多模型思考时间太长把推理强度从 high 调到 low或者关闭RTK 开启但正确率没变化任务本身太简单模型不需要推理用简单任务组单独做 AB 测试调试过程中频繁断档响应延迟导致注意力被其他事情打断人工介入式任务关闭 RTK后台任务再开我当时看到 Quesma 这份测试报告时第一反应是终于有人把这件事说清楚了。因为我早就被 RTK 的隐形消费坑过只是没有系统地整理成结论。现在我的习惯是默认把 RTK 关掉遇到真正复杂的重构任务才手动打开而且优先选择低推理强度。如果你想控制 AI 编码的成本第一件事不是去研究各家模型的价格差异而是先把日志里 reasoning_tokens 的占比拉出来看一眼。很多时候你花的冤枉钱并不是因为模型选错了而是那些你压根看不见的内心戏在默默掏空预算。