编程基准与智能体时代脱节 — 排行榜错误比较智能体的三个原因

引言 — 用衡量模型的标尺去比较系统
编程智能体不是模型，而是系统
三处脱节
更好的评测长什么样
结语
参考资料

引言 — 用衡量模型的标尺去比较系统

编程智能体如今已成为许多团队构建软件的主要方式。然而，我们给它们排座次所用的标尺，仍然停留在只衡量 单个模型 的年代。此前在分辨编程评测中信号与噪声的文章里，我们看到排行榜会因污染和基础设施噪声而动摇；在UniClawBench 一文里，我们看到了关于更好的智能体基准该如何构建的一个具体答案。本文要读的论文，正面回答了衔接二者之间的那个问题 — 为什么会脱节，究竟哪里在结构上出了错。

Tessl 团队（Maria I. Gorinova 等人）于 2026 年 6 月 16 日投稿到 arXiv 的立场论文 《Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering》 的主张正如标题所言 — 如今的编程基准，与智能体式软件工程存在根本性的脱节。

脱节的根源很简单。今天的基准是为了评估 单个模型，在智能体之前的时代设计出来的。因此它对照一个正解（reference solution）给出 唯一的端到端（end-to-end）分数，却不提供任何关于中间过程的信号。问题在于，我们正拿这把标尺去比较的不是模型，而是系统。

编程智能体不是模型，而是系统

论文最核心的重新框定就在这里。实战中的编程智能体并不是单个模型，而是一套 系统执行框架（system harness） — 它是模型、执行框架、上下文、环境、反馈信号相互交织而成的复合体。

score = f(model, harness, context, environment, feedback)

这幅图里最关键的一句话是这样的 — 在这些构成要素中，哪怕只改动 其中一个，分数也可能以 相当于相邻模型世代之间差距的幅度 发生变动。也就是说，仅仅调整执行框架或上下文，就可能带来仿佛换了新一代模型般的分数变化。

把这些构成要素具体地描绘出来会很有帮助。在编程智能体中，执行框架是重试与计划的循环，上下文是检索与提示词组装摆在模型面前的东西，环境是容器、工具、测试运行器，反馈是运行代码后返回的结果。每一项都是一个设计决策，而它们全都被折叠进同一个分数之中。

如此一来，排行榜上的一个数字就陷入了尴尬的处境。模型 A 胜过模型 B 这一标示，究竟是因为 A 真的是更好的模型，还是仅仅因为包裹 A 的执行框架更胜一筹，单凭这个数字无从分辨。前一篇文章里，Anthropic 一行权重都没改、仅靠容器配置就让分数发生了变动，这个实测正是上述主张的经验性佐证。

三处脱节

论文把这一脱节归纳为三个具体的症状。

1）把模型与执行框架混为一谈。 基准分数把模型和其余的执行框架 揉成一团。于是它无法区分某项改进究竟归功于模型变好了，还是系统设计变好了。当厂商说“新模型提升了几个百分点”时，那份涨幅中的相当一部分，其实可能是执行框架的功劳。

2）单一正解惩罚了正当的替代方案。 若对照唯一的正解方案来评分，同样正确的另一种解法 会被判为错误。软件的正解本就不止一个。哪怕是功能上完全正确的方案，只要评分被绑定在某个特定 gold patch 的 diff 或测试上，也会得零分。（前一篇文章引用过 OpenAI 的观察 — SWE-bench Verified 的未解决任务中有超过 60% 按评分标准根本无法解出 — 这正是同一问题的极端案例。）

3）缺乏组件级信号。 由于缺失单个执行框架组件层面的信号，端到端的系统分数很难引导改进。数字只有一个，而它并不会告诉你，这究竟是上下文管理的问题、工具调用的问题，还是反馈循环的问题。对于构建系统的人来说，这是最深层的问题 — 如果无法定位问题出在哪里，也就无从知道该修什么。

这三者并非彼此独立 — 它们会叠加放大。混为一谈掩盖了究竟哪个组件挣到了分数，单一正解评分掩盖了那些其实正确的行为，而组件信号的缺失则让你即便怀疑执行框架也无从证实。三者交叠之下，端到端的数字就成了一个虽能排出名次、却无从从中学到任何东西的值。

更好的评测长什么样

有一点要先说清楚。这篇论文的摘要只是 重新框定 了问题，并没有开出具体的替代基准。所以下面这些，是论文的框定自然指向的方向，也是前面看到的 UniClawBench 那样的设计已经部分实现了的东西。这三个方向，正好把三处脱节逐一翻转过来。

组件级（component-level）。 对每个构成要素进行度量，一次只改动一个（ablation），并报告是哪一部分让分数发生了变动。要显现出来的不该是端到端的单一数字，而是执行框架的哪一层做出了贡献。
多正解（multi-reference）。 不再拿字符串去比对单个 gold patch，而是以 结果与行为 来评分。UniClawBench 在运行中的容器里通过分步检查点来查看“那件事是否真的发生了”，正是这个方向的具体实例。
系统感知（system-aware）。 先把执行框架固定下来并记录清楚，再把系统当作系统来比较。也就是停止把某一个数字称作“模型的实力”这种错觉。

概括来说，好的智能体评测应当告诉你 是什么（哪个组件）、为什么（以什么行为）发生了变动。单凭一个名次，这两点你都无从知晓。

现实中，大多数公开排行榜这三点一个都不给。于是负担就落到了你身上 — 固定住自己的执行框架，用自己任务的结果来评分，把自己的组件一个一个地换着试。这比从表格里读名次要费功夫，但唯有这样得来的数字，才能真正说出关于你自己系统的一些东西。

结语

它是一篇立场论文，这个性质有必要清楚地记住。它既不是新的基准，也不是新的数据 — 而是一种视角。所以不该把它当作结果来引用，而应像一副透镜那样去使用。只不过，这副透镜相当锐利。

把核心浓缩成一句话就是 — 当我们用排行榜上的一个数字去比较两个智能体时，其实是在比较 两个完整的系统，却假装自己在比较两个模型。所以真正有用的问题不是“谁是第一”，而是“是哪个组件制造了这个差距，我能否在自己的执行框架里复现它”。组件级、多正解、系统感知 — 在这三者齐备之前，智能体排行榜上的小数点，大多不是信号，而是配置（configuration）。