令牌压缩幻觉：为什么我对 RTK 持怀疑态度

RTK 的收益范围

• 几位用户试用了 RTK，觉得它“还行”或中性：工作质量差不多，令牌节省有限或不够明确。
• 提到的具体数字：
  • 一份报告：节省了约 51k 输入令牌和 23k 输出令牌，每个命令约快 3 秒，被认为值得。
  • 另一份：在一个 300k 令牌的会话中只节省了约 3k 令牌，被视为微不足道。
  • 另一篇写作（在帖子中链接）报告称，使用 RTK 加上类似工具可节省约 3–4% 的成本（在约 $900 的账单上约省 $5）。
• 多条评论指出，RTK 只压缩工具输出，而聊天/消息往往占据上下文的大头，因此对整体影响有限。

指标、准确性与基准测试

• 一个反复出现的主要抱怨是：RTK 宣传了很大的令牌“收益”，却没有发布准确性或任务基准测试。
• 有些人认为这种“收益”指标只是个虚荣或游戏化数字，可能误导管理者对真实成本节省或性能的判断。
• 也有人认为“节省的令牌就是节省的令牌”，并表示自己在实践中没有观察到正确性问题。
• 有几位建议，正确的指标应是“每个正确答案的成本”，而不是原始令牌节省。
• 据称，一篇被链接的论文对 RTK 的基准表现并不理想；另一款工具（Headroom、Tilth）则因同时包含准确性和节省基准而受到称赞。

正确性、失败模式与可维护性

• 担心依赖正则表达式和格式的过滤器会在 CLI 改变输出时静默失效，可能把损坏或不完整的数据喂给代理。
• RTK 的支持者表示，这些过滤器在失败时会回退到原始输出，用户也可以通过环境变量标志按命令禁用 RTK。
• 许多人认为，将工具输出压缩得更紧凑、对 LLM 更友好的这个思路是合理的，但怀疑单个仓库能否在各个版本中稳健处理“每一个流行命令”。

替代方案与更广泛的工具生态

• 提到的其他工具包括：caveman、ponytail、Headroom、Tilth、Maki、语义搜索方案，以及带有子代理或本地模型的自定义 harness。
• 一些人对以下类型的工具更有信心：
  • 不绑定推理供应商。
  • 在不同任务和模型上发布基准测试。
  • 使用结构化输出（JSON、tree-sitter 等），而不是临时性的正则解析。

元话题：评估与“魔法盒子”文化

• 反复出现的主题是：这个生态里充满了“LLM 魔法盒子”工具；大多数开发者没有严谨的方法来衡量代理是否真的更好。
• 有些人依赖自己的盲测 A/B 测试；另一些人则强调，做出稳健的基准测试既困难又昂贵。