Codex 会话里一半的 token 都是噪音：ContextSniper 的「证据包」启示

Fri, 02 Oct 2026 07:30:00 +0800

你一定见过这样的会话。

一个登录接口偶发超时。你把问题丢给 Codex，它开始工作：先列目录，再读认证模块，顺手把整个 services/auth/ 扫了一遍，然后跑测试，失败，再读一遍日志，又去翻网关配置，最后在某个中间件里找到一行被吞掉的超时设置，改掉，测试通过。

整个过程花了二十分钟，烧掉一百多万 token。而真正解决问题的信息，是那三行报错堆栈加上一个配置项。剩下的，全是陪跑。

这不是 Codex 不会用，这是所有仓库级 agent 的共同困境。ICML 2026 收录的 ContextSniper 把这个困境量化了出来，结论值得每个把 agent 用在真实代码库上的人认真读一遍。

一半 token 去哪儿了

ContextSniper 由 Luk 等人提出。他们在 SWE-bench Lite 的一个 50 任务子集上做了一组对照实验，测的是「修复一个真实仓库 bug」这件事的成本结构。

基线数据相当扎眼：一个未改造的 OpenClaw agent，跑完这 50 个任务总共消耗了 6780 万 token，平均每个任务 136 万。Claude Code 更贵，总共 8597 万。

关键在于这 136 万 token 的构成。整文件的通读、宽泛的 grep 扫描、原封不动的终端输出，一层一层往上下文里堆。模型对这些内容并不会真正投入注意力，但你得为每一个 token 付两次钱：一次是输入计费，一次是压缩导致前缀缓存失效后的惩罚。

后者的代价常被低估。TokenPilot 在 2026 年 6 月的测试里记录了一个很说明问题的数字：在朴素的压缩策略下，prompt cache 的命中率从 79.2% 掉到 38.7%。缓存本来是最便宜的省钱手段，结果被压缩策略亲手毁掉。

ContextSniper 的做法是换一个思路：与其想办法把窗口撑大，不如严格筛选什么内容有资格进入窗口。它用一套三级记忆层次来检索「证据包」，结果是 OpenClaw 的 token 用量砍掉 51.5%，Claude Code 砍掉 38.9%，而 SWE-bench Lite 上的解决率只掉了两个百分点（26.0% → 24.0%，32.0% → 30.0%），这个幅度还在 50 任务样本的置信区间内。

ContextSniper on Codexer

Codex 会话里一半的 token 都是噪音：ContextSniper 的「证据包」启示

一半 token 去哪儿了