Agent Token 的虚假繁荣：停止用消防水龙头浇花

这几天读到罗福莉老师在推特的一篇文章，讲述 Anthropic封锁第三方 harness（OpenClaw） 使用 Claude订阅、以及 MiMo Token Plan定价设计背后的思考。她的核心观点是：全球 compute capacity已经严重跟不上 agent 产生的 token 需求，出路不是把 token 卖得更便宜去做内卷竞争，而是"更高效的 Agent 框架"和"更强大高效的模型"协同进化。

我反复读了好几遍，做推理引擎的人对 agent 框架的 token 铺张浪费早就怨声载道。她把一个行业里大家心照不宣的事情，用非常克制但精准的方式讲了出来：我们现在面对的 compute allocation 危机，本质上不是算力不够，而是 token 用错了地方。

我想从我自己的视角，把这件事再往深里推一层。

我是 Claude Code 的高强度用户，这一点我毫不避讳。你们可以查到我在 SGLang Omni 最新的代码都高强度使用 Claude Code 执行了我的系统设计。Claude Code 在商业上的成功是毋庸置疑的，它确实让很多人（当然包括我）第一次体验到了"用 Agent 写代码"是什么感觉。但我同时也是一个推理引擎的开发者——我每天的工作就是思考怎么让 Prefix Cache命中率更高，怎么让 KV Cache的内存布局更合理，怎么让一次推理请求的成本尽可能低。所以当我把 Claude Code 接入到一个本地推理引擎上，去观测它实际产生的请求模式时，我的感受是——怎么说呢——有点像一个精心设计了节水系统的水利工程师，看到有人拿消防水龙头浇花。

我统计了 Claude Code 一天内在本地 Serving Engine上跑出来的 Cache Hit Rate，数字惨不忍睹。这不是一个"还行但有改进空间"的问题，而是一个"我们在推理引擎层面精心设计的 Prefix Cache 机制，几乎被完全破坏了"的问题。罗福莉老师提到 OpenClaw 的 Context Management 很差——单个 User Query 内部会发起多轮低价值 Tool Call，每次都携带超过 100K 的 Context Window——Claude Code 自身的 Context 管理远远没有做到合理利用 Prefix Cache 等等一系列我们为推理引擎做出的设计。很多人已经发现了，比如 Resume 功能会导致 KV Cache 直接无法命中这种近乎愚蠢的 Bug。我可以这么说，整个 Session 的 Context 构造方式，从一开始就没有为 Cache 的复用做过认真的设计。

也许 Anthropic 内部有他们的权衡——毕竟他们控制着模型和推理栈的两端，理论上可以在 API 层面做很多我们看不到的优化。但从我能观测到的外部行为来看，大量的 Token 被花在了重复传输已经处理过的 Context、重复 Parse 已经确认的 Tool Call 结果、以及维护一个不断膨胀但信息密度极低的 Conversation History 上。如果仅仅是为了多赚推理消耗的 Token 的价格，我真为此感到遗憾。但是许多人对 Claude Code 的使用也是订阅制，消耗更多的 Token 对 Anthropic 从根本上讲是负担。我并不理解这么低效的 Context Management 对 Claude Code 有什么意义？

我有一个大胆的假设：对于那些动辄消耗 700K Token 的长 Session，我们一定有办法重构 Session 的 Context 形式，让它用 10% 的 Token 完成一模一样的任务。不是靠牺牲效果，而是靠更聪明的 Context 压缩、更合理的 Prefix 复用策略、更精确的 Tool Call 调度。这不是一个理论上的推测——任何做过推理引擎优化的人，看到现在 Agent 框架的请求模式，都会得出类似的判断。

罗福莉老师说得很对：全球的 Compute Capacity 跟不上 Agent 创造的 Token 需求。但我想补充的是，这个缺口里面，有相当大一部分是繁荣的假象，是虚假的需求——是 Agent 框架的粗糙设计人为制造出来的。

我可以做一个类比：我一直喜欢拿 RAM 膨胀来说事——1969 年，64KB 的内存把阿波罗号送上了月球；2026 年，我打开一个网页，500MB 的内存开销轻轻松松。每一代硬件工程师拼命把内存做大，然后每一代软件工程师肆意挥霍，拼命把它塞满。大家已经习惯了这个循环，甚至觉得这就是进步的正常代价。

但 LLM 推理不一样。RAM 膨胀的代价是你的电脑卡一点、多花几百块升级内存，用户几乎无感。Token 膨胀的代价是真金白银——是 GPU 集群的电费、是用户的订阅费、是整个行业的 Compute Budget。而且这个代价会随着 Agent 使用量的增长指数级放大。如果我们在 Agent 时代的早期不建立"Token 应该被高效使用"的工程纪律，等规模上来以后再补课，成本会高到难以想象。

罗福莉老师提到 Anthropic 封掉第三方 Harness 的订阅接入，客观上在倒逼这些框架改进 Context Management。我同意这个判断，但我自己的直观感受是，这件事的影响不应该只停留在"第三方框架要省着点用 Token"这个层面。它应该触发一个更根本的反思：我们到底需要什么样的 Agent-Inference 协同设计？

现在的 Agent 框架和推理引擎之间，基本上是一个完全解耦的关系——Agent 框架把推理引擎当成一个无状态的 API 调用，每次请求携带完整 Context。然而，推理引擎却在尽力做 Prefix Matching，能 Cache 多少算多少。这种架构简单、通用，但在长 Wession 场景下极其低效。如果 Agent 框架能够感知推理引擎的 Cache 状态，主动构造 Cache 友好的请求；如果推理引擎能够理解 Agent 的 Session 语义，在 Cache 淘汰策略上做更智能的决策——这两者之间的信息通道一旦打通，Token 效率的提升空间是巨大的。

当然也可能我想多了。也许市场最终的选择就是：算力够便宜，浪费就浪费了。就像 RAM 的故事一样，最后大家选择了"内存够大，不用优化"。但我不太相信 Token 经济会走上同一条路，至少短期内不会——因为 GPU 算力的供给弹性远远小于 DRAM 的供给弹性。在算力受限的前提下，Token Efficiency 就不是一个"Nice to Have"的优化方向，而是决定谁能活下来的核心竞争力。

大多数人很喜欢听到"我们把模型做得更大了"、"我们把 Context Window 拉到百万 token 了"、"我们把 HBM 堆到了新高度"——这些叙事性感、好传播、容易融资。但我严肃地认为，"把现在铺张浪费的 Token 开销想办法减少"，是一个被严重低估的方向。这不是一个防守性的优化，而是一个进攻性的能力——谁先做到同等质量下 Token 消耗降一个数量级，谁就能在同样的 Compute Budget 下服务十倍的用户，或者给同一个用户十倍深度的 Agent 体验。

Agent 时代不属于烧算力最凶猛的人，属于用算力最聪明的人。罗福莉老师说的这句话，我深以为然。但我想追问一句：谁来定义"聪明"？是做模型的人，做推理引擎的人，还是做 Agent 框架的人？我觉得答案是——这三方必须坐到一起。而现在，我们还远远没有。