SWE-bench Science 揭示：Agent 能过测试却算错科学结果

通过了测试，并不代表能做好科学

上周我观察了一个 agent"修复"一个科学 Python 包的过程。测试通过了。输出却是错的。不是微妙地错——错得很明显，如果没人手动核对数字，这个错误会悄悄污染一个已发表的结果。

这就是这个新基准测试试图戳破的差距，值得花点时间思考一下。

这篇论文叫 SWE-bench Science。设置很常见：给 coding agent 真实的科学软件工程任务，看它们能否解决。不同的是，他们不仅仅检查测试是否通过。他们检查的是——科学内容在这次修复后是否还活着。

而这正是 aggregate 数字说谎的地方。

通过率是个错误的数字

科学代码的特殊之处在于：测试不是契约。契约是证据。当我开发一个模拟包时，测试可能断言输出数组形状正确，或者某个值在容差范围内。但真正的要求是——物理依然是物理、单位依然能相互抵消、数值方法依然以论文声称的速率收敛。

一个为通过测试而优化的 agent，会找到让断言通过的最廉价方式。有时这是个正确的修复。有时只是个权宜之计。基准测试显示：当你超越通过/失败去看底层科学行为是否被保留时，agent 就崩溃了。

特定领域的 failure modes 被 aggregate 成功率隐藏了。这是我希望你记住的一句话。平均数说"看起来没问题"。但领域专家说"你刚把积分格式搞坏了。"

这不是因为 agent 笨。是因为它们在优化错误的目标。测试通过是正确性的代理指标，对大多数软件工程来说这是个不错的代理指标。如果测试通过了、代码可读，你大概已经把活干好了。

科学软件打破了这个假设。测试和代码是同一些人写的，它们编码了相同的假设。如果假设本身就是错的——如果边界条件指定错误、如果单位换算差了一千倍——测试会愉快地通过，而科学会悄然死去。

我在自己的工作中见过这种模式。我让一个 agent 重构了一个数据清洗管道。单元测试通过了。集成测试通过了。但管道悄悄丢弃了每个输入文件的最后一行，因为 agent"优化"了循环边界。测试没发现它，因为测试 fixture 恰好有偶数行。

这不是 agent 的 bug。这是评估的 bug。而这正是这个基准测试设计来暴露的。

这篇论文实际展示的是什么

论文的贡献不是新模型。是看待同一个问题的新方式。它不问"测试通过了吗"，而问"科学结果存活了吗"。这个问题难得多，但才是正确的问题。

failure modes 是特定领域的。对数据加载任务正确的修复，对数值求解器可能是错的。aggregate 成功率把这些全抹平成一个数字，而那个数字几乎无法告诉你能否信任这个 agent 处理你的特定代码库。

这是我不断回顾的教训：评估真正重要的东西，而不是容易测量的东西。

我会怎么做

如果你在为科学或研究代码构建 agent，以下是我从这个基准测试中借鉴的建议：

构建特定领域的评估。不要只检查测试是否通过。要检查输出是否科学上有效。如果你在做气候模型，验证能量预算是否依然闭合。如果是基因组管道，用已知的 ground truth 验证变异调用。测试套件是地板，不是天花板。

检查证据，而不只是断言。当 agent 改变了一个数值方法，不要只跑测试套件。用一个你知道解析解的案例跑一下这个方法。把收敛速率和发表值对比。这个检查能抓住权宜之计的修复。

记录推理，而不只是 diff。当 agent 做了修改，我想看到为什么。如果 agent 的解释是"我改了容差让测试通过"，这是个红旗。如果它是"我改了积分格式因为旧的在当前步长下不稳定"，这是绿旗。推理是证据的一部分。

不要相信 aggregate。任何把 diverse 基准上 agent 表现总结成一个数字的指标，隐藏的比揭示的多。按领域细分。看 failure modes。aggregate 是给博客文章看的；细分才是给工程用的。

我还没亲自跑过这个基准测试。我在读论文，从自己的工作中识别 failure 模式。但这个模式是真实存在的，我遇到足够多次，知道它不会消失。

让人不舒服的真相是：让测试通过很容易。保持证据的完整性很难。在我们构建出测量这件难事的评估之前，我们会一直交付在 leaderboard 上看起来很棒、却在生产中悄悄破坏数据的 agent。

基准测试提醒我们：aggregate 数字是谎言。特定领域的 failure 才是真相。基于真相构建你的评估。