基于执行的代码评测

它怎么评

早期的代码评测看生成的代码和参考答案像不像；基于执行的评测则直接跑起来看结果：给模型一个真实仓库和一个问题，它改完代码后运行项目的测试，通过才算解决。

• SWE-bench 系列取自开源项目真实的 issue 和修复提交，考的是在陌生的大型仓库里定位并修好问题。
• Terminal-Bench 系列让智能体在终端里完成装环境、处理数据、配置服务这类多步任务，最后检查环境的状态。

同一个分数背后的变量

1. 评测外壳：给模型哪些工具、多少轮交互、多少时间和 token 预算。外壳不同，同一个模型可以差十几个百分点。
2. 推理强度：同一模型开到最高推理强度和用默认档，分数和成本都不同。
3. 尝试次数：pass@k 是 k 次里至少成功一次的比例，量的是「能不能做到」；pass^k 要求 k 次全部成功，量的是「每次都能做到」。智能体上线更关心后者，而两者常常差得很远。
4. 题目子集与污染：用的是全集还是筛过的子集，题目是否可能已经出现在训练数据里。

读分数的规矩

• 厂商自报的数字，只有外壳、推理强度、尝试次数都写明且一致时才能横向比较；不一致时只看同一来源的同族对比。
• 第三方用统一外壳复测的结果，比发布页上的表格更可信。
• 分数说明模型在这类任务上能做到什么，不说明它在你的仓库里表现如何；拿自己的几个真实任务试一遍，比多看一个基准有用。