devgo.cn先看这个榜在测什么
LSCBench 是新加坡国立大学（NUS）和 Qwen 团队一起做的**安全编码**基准。做法是拿 150 个真实漏洞，切成 450 道题，覆盖七种编程语言，分成三个粒度：补一个函数、写一整个文件、重建一个仓库的源码树。粒度就是题目要求你交付到哪一层，从「填个空」到「把整个项目搭起来」。
最阴的地方在于：题目描述里**完全不提安全**。它只给你功能需求，你交上去之后，再由两套隐藏用例判卷——一套测功能跑不跑得通，一套测原来的漏洞还在不在。跑测的六个前沿 agent 分别跑在 Claude Code 和 Codex 里，限制 500 轮对话、关掉交互式工具、不给联网。
结果：最强的 Claude Fable 5，做到「既能用又没漏洞」的只有 **25.1%**。而单纯功能能跑通的比例是 73.6% 到 91.3%。翻译一下就是——**代码基本都能写出来，但基本都把漏洞原样留着**。
它真正值钱的地方，是把每一跑的原始记录都放出来了
大多数评测论文给你一张表加一个 PDF，你只能信。LSCBench 的作者把仓库 `alibaba/last-secure-code-benchmark` 连同一个目录一起放了：2700 份 trace JSON，每个模型 450 份，配一个 catalog 文件（一份把所有跑的结果汇总成索引的清单），里面带着每一次运行的判决。
trace 就是 agent 这一跑的完整记录——它收到的每一步输入、发出的每个动作、最后的产物和判定。有了它，表格上的数字就从「说法」变成了「测出来的东西」，别人跟你对不上号的时候，你可以直接回去重算。
这位作者就真去重算了。按模型、按 450 道题逐个统计「功能通过且安全通过」的并集，结果跟论文 Table 10 逐行对比：六行里有五行小数点都对得上。场景级那一列也对得上——Claude Fable 5 在「三个粒度全都守住」这个更严的口径下是 12.0%，和论文一致。合并统计也对：450 道题里有 198 道（44.0%）至少被一个模型守住，19 道被六个模型全守住了，62 道只有一个模型守住。
唯一对不上的是 Kimi-K3 的 FuncPass：catalog 里是 92.2%（415/450），论文里写 91.3%，差四道题。不改变任何排名，也不影响任何结论，但这是 2700 次运行里唯一一处不一致。作者自己也说，从外面看不出这是版本漂移还是「缺失判决该怎么算」的口径差异——而这恰恰是重点：**轨迹发出来了，你至少能看见存在分歧；只有表格的话，你连分歧存在都不会知道。**
反过来说，那些不给原始数据的榜，一旦没人能重新推导，头条数字过几个月就烂掉了。
一个 reward 位，把两种完全不同的失败压成了同一个 0
每条 trace 都带一个 `reward` 字段，只有在这一跑**既功能通过又安全通过**的时候才是 1。于是这里出现了问题：一个「代码跑得通但漏洞还在」的提交，和一个「压根没编译出来」的提交，都记 0 分。
这俩是完全不同的事。前者是安全没做到，后者是能力没做到，读结果的人该做的反应完全不同。论文本身很小心，FuncPass、SecPass、Func ∧ Sec 三列分开报，可发出来的 catalog 又把这个一位的 reward 当成了汇总口径。全库 2700 跑里有 574 跑是 reward 1。如果你按 reward 去过滤「agent 放弃了」的样本，会捞错——在那一列里，「放弃」和「写了个带洞的实现」长得一模一样；你要是想按分数给「安全退步」和「构建退步」排序，也排不了，必须回到那两个布尔值上。
更值得警惕的：120 次跑崩了，其中 15 次照样拿了满分
catalog 还记了退出原因（也就是这次运行为什么结束），这是作者说他一开始没预料到、后来最在意的字段。
2700 跑里有 120 跑（4.4%）不是「agent 自己觉得干完了」而结束的：6 次撞上 500 轮上限（`AgentMaxTurnsError`），25 次死于 API 限流（`ApiRateLimitError`），16 次超时，还有 5 次是判卷器自己挂了（`VerifierTimeoutError`）——这最后一次根本不算 agent 的锅。
关键在于，这 120 跑里有 **15 跑仍然拿到了 reward 1**。撞了轮数上限、或者被限流打断，产物有可能已经是对的、也是安全的，这个满分是真的。但换个角度：数据集里全部通过样本的 2.6%，来自一次压根没干净收尾的运行。如果你正在用一两个百分点的差距给模型排名，这个量级和你的领先幅度是同一个数量级。
那 5 次判卷器超时是最干净的样本：它们被记成 `functional: false, secure: false`，跟论文对「缺失判决」的处理一致（缺了就按失败算）。这个约定站得住脚，但它把一个基础设施故障变成了模型失败——而你能看见这件事，纯粹是因为轨迹被放出来了。
引用任何一个榜单前的四个检查
作者给了四条，每一条在有轨迹的情况下都只要几分钟：
1. **先数行数，再看分数。**450 道题乘 6 个模型等于 2700。catalog 少了行，你的分母就是错的。
2. **把 FuncPass 和 SecPass 拆开看**，别用那个被压成一位的 reward。它把安全失误和构建失误混在了一起。
3. **对每一跑都看一眼退出原因**，数数有多少个通过是来自崩掉的运行。如果一个模型的领先幅度小于它「崩了但过了」的次数，那还不能叫排名。
4. **看场景级那一列，不只看任务级。**在一个粒度上守住漏洞，不能证明模型真的理解它。Claude Fable 5 从任务级 25.1% 掉到场景级 12.0%，这个落差才是「一致性」的诚实刻度。
最后一句是给两种人的。如果你**维护**一个评测，最便宜的可信度就是：把 summary 和逐跑结果一起发，连失败原因一起。如果你**消费**一个评测，最便宜的体检就是数行数、拆 reward、读退出原因——这三道过滤挡在你和一个「听起来比实际更好」的数字之间。
内容与图片版权归原作者所有 · 原文: https://dev.to/cole_halton_42f71d71b809b/a-benchmark-shipped-2700-agent-trajectories-i-recomputed-its-leaderboard-pgf