编码 agent 压到 4 位，到底还剩多少。
简单说，分数基本没掉，但解题的方式换了。这个变化比掉点更难发现。
11 月 2 日 arXiv 上有一篇，编号 2611.02368。NeurIPS 的 SLM-Agents 研讨会收了，会开在巴黎。作者四个人：Areej Mehboob、Muhammad Ali Shafique、Muhammad Usman Qadeer、Hamza Farooq。
我挑它不是因为结论漂亮。是里面有一组数，看完我坐了一会儿。
实验先交代清楚。基线 BF16，对照组是 4 位的 AWQ 和 GPTQ。模型挑了 Qwen2.5-Coder-Instruct 的 7B、14B、32B，外加一个 24B 的 Devstral-Small-2507。题库是 OJBench，跑了三个随机种子。
第一层结论很平淡。没发现统计显著的准确率下降。
这种结论最适合拿去当标题。量化不掉点，皆大欢喜。
我得先说句不太配合的。三个种子跑出来的“没显著差异”，也可能只是样本不够大。这话放在前面，是因为后面那些反而更硬。
然后作者把轨迹拆开了。
轨迹这个词值得多讲一句。它不是模型的最终答案，是它从读题到交卷的整个过程：中间试了几次，改了几次，有没有跑起来看一眼。
Qwen-7B 在 AWQ 下，一次性把题解出来的次数从 17 掉到 0。同一时间，循环式求解从 10 涨到 25。
我盯着这两个数看了一会儿。17 掉到 0，不是掉了一点，是没了。模型没变笨，是它变了性格。以前敢一口气写完，现在不敢，要先跑一遍看看结果。
同样一道题，一次写对的成本最低。循环求解要多花几轮 token，多花几轮时间。分数上它们都算对。
自己一个人用，这甚至可能算好事。多试几轮，稳一点。但你在跑批量、在算成本、在卡延迟，这个变化是实打实的。分数一样，token 花得不一样，时间花得不一样。
再往下还有一层。Qwen-32B 成功的那些案例，全部涉及工具调用。Devstral 那边，很少能产生有效的执行器调用。
这条我觉得比准确率那段重要得多。同样挂着“编码 agent”四个字，一个靠反复调工具把活磨成，一个基本不碰工具。分数就算打平，能落地的场景也完全不是一回事。榜单给你一个数，正好把这个差别抹干净。
失败类型也在动。Qwen-32B 的编译错误明显多于更小的 Qwen，量化之后还略增了一点。Devstral 量化之后，失败从运行时错误明显转向错误答案和超时。
错误答案和超时，在流水线里的代价差得远。运行时错误你当场就抓到。错误答案会顺着往下游走，等发现的时候已经不知道流到哪了。
所以这篇我真正想拎出来的一句话是：准确率是最后一个告诉你真相的指标。
现在的榜单大多只报最终准确率。这个指标好统计，也好比较，所以大家都在用。但它只看最后一格，中间是怎么走过来的，全丢了。
至于量化为什么把求解轨迹改成这样，论文没讲透。我也只看懂一半，先放在这里。我能想到的解释是 4 位下模型对自己的判断没那么有把握了。这只是猜，别当结论。
留给普通人的判断很简单。
你在自己机器上跑个 4 位的小模型，帮你改改脚本、写写小工具，这事没什么好犹豫的。省下来的显存是白得的，试错多几轮也不亏。
但你要把它挂到流水线上，让它自动改代码、自动提 PR，就别只看 benchmark 上那个准确率了。看它到底怎么解的，调不调工具。再看它失败的时候错在哪一步。这几样东西比一个百分比诚实得多。
论文最后给的建议也是这个。评估量化鲁棒性，除了最终准确率，还要看求解轨迹、工具使用和失败模式。
我认同。说得再直接一点：一个只看分数的评测，测不出 agent 换了个活法。
本周就这些。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。