科学软件修复不只是让测试变绿：SWE-bench Science揭示编码智能体的知识鸿沟

导语

当软件只是信息处理工具时，修复一个缺陷通常意味着让程序恢复预期行为。但在科研场景中，代码往往就是实验仪器、模拟系统或数据分析流程的一部分。一个看似微小的实现错误，可能改变计算结果，进一步影响论文中的证据和科学结论。SWE-bench Science正是针对这一问题提出的仓库级基准：它不只问编码智能体能否修改代码，还要考察修复是否遵守背后的科学语义。

基准测试了什么

该基准收集了来自98个GitHub仓库的119项任务，覆盖20个科学领域，并将任务分为三类：

• 问题驱动型：围绕真实缺陷、报错或用户提交的问题完成修复；
• 专家探索型：需要理解领域背景，主动定位潜在的科学或算法问题；
• 工程集成型：要求把修复方案正确接入现有模块、接口和完整工作流。

这种设计区别于只看补丁是否通过公开测试的传统评测。研究报告称，即使是表现最好的Claude Code搭配Opus-5（max），Pass@1仍低于50%，说明科学软件修复远未达到“让模型读懂报错并自动改好”的阶段。

四类典型失败

研究将失败原因归纳为四种机制。第一，智能体缺少必要的科学知识，或无法建立正确的抽象，因而把领域约束误判为普通编程细节。第二，探索过程可能偏离问题本质，最终停留在表面修复。第三，补丁覆盖范围不足，局部代码虽然改变，却没有完成跨模块的系统集成。第四，模型难以把从已观察样例中获得的科学规律推广到新的输入和边界条件。

这四类问题也解释了为什么“测试通过”不能简单等同于“科学问题已解决”。根据项目方在讨论区的说明，评测使用了不向智能体公开的私有测试套件，重点检查任务背后的科学行为契约，并在全新工作区中应用提交补丁后执行验证。公开复现测试只能作为诊断依据，修改公开断言或针对可见样例硬编码，并不能通过真正的科学验收。项目方举例称，Qwen3.8-27B通过了全部119项公开复现，但私有评测中只有35项达到完整Pass@1。

科学知识并非总是越多越好

基准还进行了成对消融实验：在保留代码仓库和可执行工程环境的同时，移除显式科学指导。结果表明，领域知识的作用并不稳定。准确、贴合任务的指导能够缩小搜索空间、提高平均表现并减少令牌消耗；如果指导与实际问题不匹配，则可能把智能体锚定在错误方向，反而降低修复质量。

意义与影响

SWE-bench Science的价值在于，它把编码智能体的能力边界从“能否生成可运行补丁”推进到“能否维护科学语义”。这对科研机构、科学计算软件维护者和模型开发者都具有现实意义：未来的评测需要同时关注代码行为、领域约束、跨模块集成和未见条件下的泛化能力。

不过，Pass@1仍然只是能力切片，不能替代领域专家对科学结论的最终审查。更可靠的科研智能体，必须学会区分通过测试与保持语义之间的差异，并在不确定时主动暴露假设、验证边界，而不是仅仅追逐一个绿色检查标记。

来源：Hugging Face Daily Papers