Distill

我不断看到各类 Token 压缩工具靠让模型"换种说话方式"——电报式、原始人式的输出——来削减 Token。这确实是种取巧手段，但却让我有点不安：压缩风格本身对要砍掉什么没有独立校验。在高强度设定下，很容易把真正重要的那句话——比如一句"这无法撤销"或一处被遗漏的前提假设——连同废话一起压缩掉。我想做的是这样一个工具：安全相关内容由代码强制保护，物理上无法被压缩掉，而不是寄希望于模型还能记住某条指令。

其实有两个原因。第一，我看过的所有压缩工具都只触达输出端——也就是模型写出来的内容——却忽略了工具描述和工具结果通常主导着 Agent 的上下文，远比模型自己的文本多得多。第二，说实话更关键的那个：没人报告扣减后的净数字。每个工具都只引用输出压缩的毛收益，却从不减去工具自身运行的成本——它自己的指令开销、自己的压缩调用。一个永远只会显得好看的数字，不是让我放心的数字，所以我不打算交付这样一个东西。

一开始我默认 Skill（输出端压缩）才是产品，中间件只是个锦上添花。真正的测量把这个判断翻转了：基准测试显示，在现代 Agent 框架本身就足够精简的情况下，Skill 几乎相当于零操作，而中间件——在 MCP 工具描述和结果抵达模型之前就对其进行压缩——在重复性日志上却测出了高达 87% 的压缩率。这把整个叙事重新排序为"中间件优先"。

后面的过程，基本上就是发现自己在一些更细节的事情上判断错了，然后在测量捕捉到错误之后再修正，而不是事先预判到：单样本的基准测试跑一遍会在重跑时符号反转，直到我强制使用 n=3 以上的中位数；基准测试框架是从项目自己的代码库里运行的，于是模型可以直接读取自己的评估测试用例，意识到自己正在被测试，而不是按自然方式作答；Skill 自身的自检指令里有一个隐蔽的单向偏差，让它在复杂回合上反而会扩展输出，而不是压缩输出，直到一次干净的重新测量才将它暴露出来。这些问题没有一个是我通过审视代码推理就能发现的——只有真正跑起来、并且相信数字而不是我的假设，才能捕捉到。这也成了真正塑造产品的原则：测量永远胜过假设，哪怕——尤其是——当诚实的数字不那么好看的时候。