速评：那个用pass@k给AI编码智能体刷分刷了快两年的玩法，终于被人写成论文扒了个底朝天。
论文是8月11日挂到arXiv上的，到今天19天，讨论度我体感不算热。但里面那个数值得念三遍：在合成多rollout基准上，误用指标能让报告分数绝对提高0.85到0.97——报告写着0.96、0.98，修正后的真身是0.00到0.12。
这不是误差，是凭空捏造。
问题出在Chen等人2021年那篇pass@k原始论文上。原定义里n是独立采样尝试的次数，这跟生成代码那套自回归采样是一一对应的——你试了多少次，n就是多少。结果这几年做agent benchmark的人怎么用的？把n设置成单个提交里单元测试的数量。一个是采样次数，一个是测试用例条数，两个维度的东西被硬塞进同一个公式里。测试集规模越大，n越大，报告出来的pass@k就越高。
合理吗？不合理。方便吗？太方便了。
你要是个做agent的公司，库里躺着一堆跑不满的测试用例，把它们全塞进n，第二天就能给投资人看一个0.97的pass@k曲线。这剧本，眼熟。
我不信写这些benchmark的人看不懂原始论文。pass@k的数学不复杂，复杂的是承认"我手里的分数是假的"之后还要给自家产品重新定级。所以大家都默契地不去看那个n到底填的是什么，反正排行榜上人人都在涨，谁先松手谁吃亏。
这里有个细节我特别想提：论文用了廉价的单次rollout代理去做替代，想省掉重复运行的推理成本，结果Spearman相关系数只有0.417。这个数很尴尬——说它完全不相关吧，好歹不是零附近；说它能用吧，0.417对选型决策来说就是随机噪声往上浮动一点。省钱的捷径基本堵死了，想拿到真实分数，路只有一条：老老实实跑多个独立rollout，花那份算力钱。一分钱成本没涨的benchmark，分数全是水。
还有个数据值得单独摆出来：SWE-bench Verified上5个任务的初步试验，宏平均隐藏测试通过率0.80，严格任务解决率0.20。0.80的意思是"大多数测试用例过了"，0.20的意思是"整个任务完整解决"——中间那60个百分点的落差，就是agent编到一半卡住、把简单case修好了但完整链路没走通、或者改了这个测试搞坏了另一个测试的真实状态。这跟我旁观agent在真实仓库里的表现对得上：片段正确率很好看，端到端交付率稀碎。
不过跟所有"这瓜终于被扒了"的爽文比，论文自己给了个凉水：security-adjusted reliability@k在包含三个智能体的live-API测试里，调整后排名没变。功能正确且不含高严重性不安全模式的rollout算进去，还是原来那个顺序。说明在"谁更安全"这个维度上，被测的这三家可能压根没有区分度——不是修正指标没用，是当前agent的安全水平整体都在及格线以下，矮子里拔将军，怎么拔都是那个将军。
对，我得承认我用过这类benchmark。去年我还在某家agent的发布通稿里看到那个0.9几的pass@k数字，当时我按原始定义心算了一下，怎么都凑不到那个高度。我没细想，因为大家都在转那张图，我也跟着转了。现在回头看，转发的时候我应该更早意识到——那就不是能算出来的数，是n被灌了水的数。
通稿里"pass@k创新高"的形容词，不用当真；现在连pass@k本身，也要先问一句：这个n，填的是尝试次数，还是测试用例条数？
这里立个flag：如果这个修正指标被主流benchmark采纳——哪怕只是被接受——未来半年内会有一批agent产品悄悄更新自己的技术报告，把0.9几改成0.1几，然后加一句"我们采用了更严格的评估标准"。
至于那篇论文，建议有空的同行去翻翻，尤其看看作者怎么把"n的含义"这一个问题讲得这么慢、这么细。慢到让人觉得这个领域之前两年都没人在认真看公式。