JetBrains AI 團隊近日發佈了一項針對“Rust Token Killer”（簡稱 rtk）的基準測試結果，引發了業界對 AI 代理 token 壓縮工具實際效能的廣泛討論。rtk 是一個 CLI 代理，通過攔截 git status 等命令，將冗長的輸出壓縮為簡短格式，其 README 聲稱可在 30 分鐘的會話中將 118k token 的命令輸出壓縮至 24k，節省幅度高達 60-90%。然而，JetBrains 的嚴謹測試表明，這一數字在實際應用中不僅無法實現，甚至可能產生相反效果。
測試團隊使用 Claude Code 2.1.201 和 claude-sonnet-5 模型，在 SkillsBench 基準的 86 個任務上進行了配對 A/B 測試。實驗中，arm A 使用標準的 Claude Code，arm B 則集成了 rtk v0.43.0 及其 PreToolUse hook。為了確保結果可靠，團隊設計了多階段測試：先進行 10 個 Bash 密集型任務的 k=1 煙霧測試，接着對相同任務進行 k=3 測試，最後完成全部 86 個任務在低推理成本和高推理成本下的兩次完整運行，共計 425 次計費試驗。
關鍵發現之一是：rtk 的實際影響範圍極為有限。通過重放 83 個已有基線轉錄，團隊發現 Claude Code 主要使用內置的 Read 和 Grep 工具讀取文件和搜索代碼，這些工具完全繞過 Bash hook。此外，代理在 shell 中運行的一半命令是 python3 等其他未覆蓋命令，另有六分之一的命令使用管道、heredoc 和替換，rtk 故意不重寫這些命令。最終，只有約 33% 的 Bash 調用被 hook 攔截，而這些調用攜帶的字符量不到工具結果總字符的 20%。考慮到工具結果本身只佔會話輸入 token 的一部分（因為同一上下文會在每一輪被緩存重讀），rtk 能影響的最大輸入 token 份額僅為約 3%。
在成本方面，低推理成本下，rtk 臂的中位數成本比基線高出 7.6%（p=0.004），回合數增加 13.8%，緩存讀取增加 14.3%。而 rtk 唯一聲稱壓縮的“新輸入” token 類別僅增加了 3.2%（p=0.23），並無統計差異。有趣的是，當推理成本提高時，成本差異完全消失（中位數差 +0.1%，p=0.99），回合數和質量也無顯著差異。這意味着在高推理成本下，模型可能因輸出壓縮而減少不必要的探索回合，但即便如此，rtk 也從未展現出任何成本節約。
質量方面，團隊仔細檢查了回合數差異最大的六個煙霧測試配對，在約 150 次 Bash 調用中只發現了一個真正的重寫錯誤（複合 find 謂詞被轉化為用法錯誤並觸發重試），以及一次代理故意繞過 hook 的情況。在完整運行中，任務得分在低推理成本下為 5 次更好、4 次更差、71 次持平，高推理成本下為 5 次更好、4 次更差、62 次持平（符號檢驗 p=1.0），表明兩組在統計上不可區分。
最引人深思的是第五個發現：rtk 自帶的評分板與實際賬單之間的巨大差距。在低推理成本的完整運行中，rtk 的內部分析報告節省了 9620 萬 token——聲稱避免了 99.8% 的 token 消耗，但同一試驗的實際計費卻上升了。這一矛盾源於三個機制：首先，rtk 將完整的原始輸出作為反事實進行計數，但 Claude Code 會在工具結果遠未達到 320k token 時便進行截斷，因此代理無論如何只會收到幾千 token；完整運行中記錄了 190 次這樣的大型讀取，每次平均“節省”約 506k token。其次，rtk 在執行時以字符數除以 4 來估算 token，但會話輸入成本的主要部分來自按十分之一價格計費的緩存重讀。第三，hook 從未看到大部分上下文。正如團隊總結的那樣：“評分板在給自己打分。”
JetBrains 團隊強調，rtk 是一個誠實的工程作品，過濾器本身優雅有效，質量未受影響，hook 機制也如預期般運行。但問題在於其使用了錯誤的反事實：工具宣稱的節省並非相對於實際賬單，而是相對於一個不存在的理想狀態。這一發現具有更廣泛的啓示：在評估任何上下文壓縮工具時，應測量配對賬單而非工具自身的差異。rtk 的案例清楚地表明，看似誘人的 token 節省可能隱藏着意想不到的成本。