CompressionBench 三天前挂上 arXiv。标题问得很直白：coding agent 能不能自己把一个大模型压小。很多人扫这种论文，第一眼找的是最终分数——3.4%，涨了还是跌了。这篇真正的发现藏在另一个数字里：17 of 79。
先把这个 benchmark 让人干什么说清楚，不然下面没法聊。它不是“给你一个压缩算法，你去实现”。它把整件事端到端扔给 agent：一个原始 checkpoint，一个存储上限，一个推理环境，一段时间预算，剩下你自己看着办。agent 自己选压缩路线，自己设计实验，自己决定下一轮改哪儿，perplexity 当反馈信号回灌给它。交出来的东西必须是能跑的权重加推理代码，不是一份报告。
这里最容易被搞混的是：门槛不在“会不会量化”。量化代码 agent 早就写得出来，GPTQ 那套抄一遍改改超参，属于它舒适区里的活。难的是中间那一串判断：位宽降到多少、哪些层留高精度、校准集拿什么、这一轮改动到底该归因到哪个变量。以前这些判断是人做的，人是那个“看完曲线说再试一次”的角色。这个 benchmark 把人拿掉了。
六个 agent，六种模型规模配置，一共 36 份提交，29 份过了独立验证。每个任务挑 perplexity 最好那一版拼起来，平均 perplexity 相对 BF16 涨 3.4%，下游准确率 77.33%，BF16 是 79.56%。
说人话就是：掉两个多点，换整条流水线没人插手。值不值是另一个问题，先把量级记住。
然后是整篇论文里我觉得最该被引用的那组记录：24 次修订，21 次 perplexity 往下走，存储占用基本没动。翻译成大白话，agent 找到了一条“预算不变、持续变好”的路，而且走了二十多步没撞墙。看到这儿你会觉得它挺能干。
如果文章到这儿结束，这就是一篇合格的 benchmark 论文，结论是“基本可行，略有损失”。但作者多做了一件事，这件事比他们的主结论重要得多。
他们拿完整模型，把前面那些局部评估得出的排名重新排了一遍。79 个早期局部排名，翻了 17 个。
五分之一。你按局部信号做的判断，换把尺子重新量，五次里有一次是错的。而且这不是随机噪声那种错。噪声应该上下对称地抖，跟你用哪把尺子没关系。它跟尺子有关系，说明局部评估这一层带着系统性偏差。
偏差从哪儿来？往下拆两层。
第一层，perplexity 是 token 上的平均。平均对长尾天生不敏感。一个压过的模型，百分之九十九的 token 预测得跟原来一样好，剩下那一点直接崩——比如生成 JSON 时开始重复同一个括号，或者该收尾的地方停不下来——平均值上你只看到小数点后面动了一点点。生成测试一跑，问题立刻现形。论文里那条“生成和推理测试暴露了 likelihood 指标抓不到的失败”，说的就是这个。这里最容易被搞混的是，perplexity 不是“错的指标”，是“粒度和失败模式对不上的指标”。它测的东西没错，只是它测的那个东西恰好不是会崩的那个东西。
第二层更根本。压缩一个模型，不是一个“每一步都能独立打分”的过程。你动了某一层的精度，误差不会乖乖停在那层，它会顺着后面的计算往下传，后面的层有的放大它，有的补偿它。所以“这一步改完 perplexity 降了 0.02”和“这一步改对了”之间，隔着一整个归因问题。你以为你在测这一步，其实你测的是这一步加上它前面二十步的累积状态，再加上这版校准集的抽样运气。
归因问题这四个字，才是这篇论文真正的题目。
打个比方，一个拳手降体重，每天上秤，数字很稳，一天掉零点几公斤。但秤不告诉他掉的是水还是肌肉，也不告诉他明天上场还有没有力气。这个类比到这儿就该收了——秤至少还是同一个指标，perplexity 和“这模型还能不能好好答题”根本不是一个东西，前者的下降可以是后者的下降换来的。
回到 agent。二十四轮实验它跑得动，这点不用怀疑，它不缺算力也不缺耐心，你让它跑两百轮它也跑。它缺的是“这次降的 0.02，到底是因为我改的那个东西，还是因为上一轮改动延迟生效了，还是因为这一轮抽到的评估样本刚好简单”。这个问题人也不一定答得上来，但人知道自己答不上来，人会换组样本再验一遍，或者干脆留一版备份。模型不会，模型看到数字降了就往下走。这是它的工作机制决定的，不是态度问题。
论文作者把 representation design、experimental judgment、capability validation 三条列成关键因素。我读下来的感觉是，前两条是手段，第三条才是真正卡住的地方。设计表征、设计实验，这些是搜索问题，搜索是 agent 的强项。判断一个实验到底验证了什么，这是元认知问题，自回归采样这个机制本身不提供这一层。
再说一句偏的。论文的 motivation 写的是 recursive self-improvement，说 AI 系统应该能改进后来系统所依赖的模型和基础设施。框架很大。我觉得它实际证明的东西比这个框架小，同时比这个框架有意思。
小的那部分：29/36 的通过率说明 agent 能把一件验证标准明确的事做到可交付。这叫工程能力，离“自我改进”还差着好几层，中间最少隔着一个“验证标准是谁定的”。这次的标准是人定的：存储上限人给的，验证流程人写的，perplexity 当反馈信号也是人选的。agent 是在一个人搭好的笼子里跑得很快。
有意思的那部分：它把“agent 的实验判断力”变成了一个能打分的量。17/79 就是那个分数。在这之前这件事只能靠体感聊——你会说 agent 有时候会一本正经地在错误方向上做二十次实验，听起来像抱怨。现在有个数字摆在那儿，五分之一的局部判断换把尺子之后站不住。这比任何一条 perplexity 曲线都值得记。
还有一层，关于那个独立验证环节。它是被加进去的，不是长出来的。agent 自己那个 perplexity 内循环不可信，所以才需要外面套一个用完整模型、用生成测试、用真实推理环境跑的外循环。这跟我们见过的所有 agent 系统一个德性：循环本身不带刹车，刹车是外挂的。外挂多厚，决定你敢把多少权限交出去。这次的外挂够厚，29 份提交能过；但这也意味着这份成绩单里有多少是 agent 的、有多少是那套验证流程兜住的，其实分不太开。
绕回开头。3.4% 是这篇论文的成绩，17/79 是这篇论文的发现。这两个数字的关系，跟你以后看这类“agent 能自己干 X 了”的论文时的读法有关：第一个该找的不是 X 做到了什么程度，是它怎么知道自己做到了。前者是能力展示，后者才是机制。
至于再往下一层——如果哪天那个独立验证的环也是 agent 自己搭的，这套东西还成不成立，就不是这篇论文能回答的了。这个坑先留着。
懂了这层，你下次看到某个 agent 刷出一个漂亮分数，第一反应大概会先去翻它的评估协议，而不是先看那个分数。