科学软件正在成为科学仪器的一部分。代码中的缺陷因此不只会导致程序运行异常，还可能影响支撑科学结论的证据。针对这一问题，论文提出 SWE-bench Science，试图把科学软件工程中的真实修复难题带入代码智能体评测，并进一步分析智能体为什么失败。
一个面向科学软件的基准
SWE-bench Science包含来自98个GitHub仓库的119项任务，覆盖20个科学领域。与只看任务是否通过的评测不同，它把任务组织为三种范式：Issue-driven、Expert-exploratory和Engineering-integration，分别对应由问题驱动的修复、专家探索式任务，以及需要工程整合的任务。
这一设置强调，科学代码修复通常不只是补上一个函数或通过测试。智能体还需要理解代码背后的科学抽象，探索仓库中的相关实现，并确保修改能够覆盖完整行为、接入现有系统。论文报告，即使是表现最好的智能体 Claude Code with Opus-5（max），其 pass@1 也低于50%。这说明在科学软件场景中，通用编码能力距离稳定解决仓库级任务仍有明显差距。
失败不只是“代码写错了”
论文归纳出四类反复出现的失败机制：缺乏科学知识或抽象能力；错误的探索路径或停留在表层修复；修复覆盖不完整或系统集成失败；以及无法把从已观察案例中获得的科学知识推广到新情况。
研究还做了一组配对消融实验：在保留仓库和可执行工程环境的前提下，移除明确的科学指导。结果显示，科学知识并非对所有修复任务都同样有益。与任务相匹配、建立在可靠基础上的信息，能够约束修复方向，并改善平均表现和 token 效率；但不匹配的指导可能引入新的偏差。摘要相关表述在此处截断，因此更具体的负面影响仍需结合论文全文判断。
我的判断
这项工作的价值在于，它把“科学代码为什么难修”从泛泛而谈变成了可分类、可比较的评测问题。对代码智能体开发者而言，单看总体通过率已经不够，还应关注科学知识理解、仓库探索、跨模块集成和案例泛化等能力。它的适用边界也很清楚：119项任务来自98个仓库，能够反映一部分科学软件工程挑战，但不能据此概括所有科学领域或所有真实科研流程。低于50%的最佳 pass@1 说明现阶段智能体仍更适合承担受控、可验证的辅助工作，不能把一次通过当作科学软件可靠性的充分证据。