SWE-bench Science: Can Coding Agents Resolve Engineering Tasks in Science? 精读

论文

• 标题：SWE-bench Science: Can Coding Agents Resolve Engineering Tasks in Science?
• 论文链接：https://arxiv.org/abs/2608.19799
• 代码：https://github.com/OpenMOSS/SWE-bench-Science
• 数据：https://huggingface.co/datasets/OpenMOSS-Team/SWE-bench-Science
• 榜单：https://swescience.github.io
• 发表时间：2026 年 8 月
• 机构：上海创新研究院 + 复旦大学（研究机构 + 高校合作，通讯作者：王宇芯、邱锡鹏）
• Hugging Face 当日热度：61 票

一句话概括：当代最强的 coding agent，在真实科学软件仓库里修 bug，十个任务只能修对不到五个——而且它们自己以为全修对了。

TL;DR

软件早已不只是科学的助手，而是「科学仪器本身的一部分」：模拟靠代码跑、仪器数据靠代码处理、论文结论靠代码复现。一个错误的补丁，毁掉的不仅是一个程序的输出，可能是整篇论文的证据链。但现有 coding agent 评测只看「总分过了多少」，看不出 agent 为什么失败。

SWE-bench Science 给出了一个系统性的答案：

• 基准规模：119 个任务，来自 98 个真实 GitHub 仓库，覆盖 20 个科学领域（化学 24 个任务最多，其次是材料 16、生物 13、生医工程 12、物理 11）；
• 核心方法：Chain-of-Evidence Protocol——公有测试（agent 可见、用于调试）与私有测试（评测容器内独立挂载、agent 不可见）物理隔离，配合三范式任务设计（Issue-driven / Expert-exploratory / Engineering-integration）与四阶段防泄漏构建流程；
• 核心数字：8 个前沿 agent 中最强的 Claude-Opus-5（max）Pass@1 仅 47.90%，而同一配置的公开测试分高达 96.64%——近一半的落差，全部是「公开测试全过、私有科学断言失败」的表面修复；
• 深度发现：人工审计归因出四类反复出现的失败机制；91 任务配对消融显示，给 agent 注入科学知识并非普遍有益——GPT-5.6-sol 的 Pass@1 反而从 36.26% 降到 31.87%，错位的信息会诱发「锚定」效应。

一、研究背景：科学代码出错，毁掉的不只是程序

1.1 软件成了科学仪器的一部分

论文开篇的一句话非常精准：软件不再仅仅是科学的辅助工具，它是产生科学主张的仪器的一部分（Software is no longer merely an aid to science; it is part of the instrument through which scientific claims are produced）。

想想今天的科研日常：研究组用代码跑分子动力学模拟、处理望远镜和测序仪的输出、训练代理模型、筛选化学/生物候选分子、管理高通量实验、复现已发表的论文。如果某段代码有 bug，受损的不只是一个程序的运行结果，而是这个程序算出来的每一个数据、以及基于这些数据的每一条科学结论。

打个比方：普通软件的 bug 像计算器按错了键，重按就行；科学软件的 bug 像显微镜的镜片装歪了——你看什么都可能是歪的，而且完全察觉不到。

1.2 现有评测的两大空白

论文指出，理解 coding agent 为什么在科学软件上失败，和测量它们的补丁能不能通过测试同样重要。一次失败的修复，可能源于：

1. 科学抽象错误（搞错了物理量的数学定义）；
2. 只修了表面症状（测试过了，根因没动）；
3. 修复不完整（一个模块改对了，跨模块的数据流断了）；
4. 无法泛化（修好了眼前这个案例，换个边界条件就崩）。

聚合的总分完全无法区分这些失败来源，因此对改进科学 coding agent 的指导意义有限。而盘点已有基准（见下表），要么是自包含的函数级编程题，要么聚焦于研究工作流，跨科学领域的仓库级覆盖 + 失败机制分析一直是空白。

注意最后一行：SWE-bench Science 是唯一同时做到「20 个科学领域 + 98 个真实仓库 + 仓库级软件工程」的基准。与 SWE-Bench 5G 只覆盖电信一个领域相比，它的跨领域广度是数量级领先的。

二、基准概览：119 个任务长什么样

2.1 规模与分布

SWE-bench Science 包含 119 个任务、98 个独立 GitHub 仓库、20 个科学领域，每个任务都经过人工检查以验证其科学契约（scientific contract）、可复现性与评测有效性。

领域分布上，前五大领域（化学 24、材料科学与工程 16、生物 13、生物医学工程 12、物理 11）合计 76 个任务，占 63.9%；也有六个领域各只贡献 1 个任务。仓库级覆盖广度是刻意设计的目标——不是让 agent 在一个领域刷分，而是考察跨领域的科学软件维护能力。

2.2 三种任务范式

论文最有辨识度的设计之一，是把任务分为三个范式，避免把不同的能力混在一个总分里：

这个分类很关键：Issue-driven 任务里历史 issue 是定义起点；Expert-exploratory 任务里 issue 只是可选背景，agent 面对「现象与根因分离」的谜题；Engineering-integration 任务则要求理解系统架构、连接完整的多模块能力链。三种范式分别对应科学软件维护中最常见的三类真实工作。

2.3 任务规模：不是玩具

任务的仓库上下文和修复规模差异巨大：

• 输入代码：平均 80,600.12 行非空代码，最小 174 行，最大 2,029,051 行——agent 需要在最大两百多万行的代码库里找问题；
• 参考补丁：平均新增 117.81 行（范围 1–1,035）、删除 44.53 行（范围 0–458）。

对比 SWE-bench 原版多为一两百行上下文内的局部修改，这里的平均参考补丁超过 160 行增删，且散布在真实的科学计算代码库中——对 fault localization 和跨文件理解的要求高得多。

2.4 一个具体例子

论文用图 3 给了一个直观例子：两种周期性表示描述同一块晶体，但能量对不上。agent 可见的输入包括问题陈述、科学背景（周期性 Hartree-Fock 中，原胞 k 点与 Γ 超胞的能量应当不变）和仓库快照。公开测试只做诊断（收敛性、数值有限、表示间隙），而私有测试包含 10 个科学用例（FFT 网格一致性、k 点排序、胞几何、MDF 积分等）。

关键在于：公开测试全过（public PASS）不代表修好了——如果私有用例只过了 7/10，Pass@1 依然是 0。这个例子完美预演了后面 96.64% vs 47.90% 的巨大落差。

三、方法拆解：Chain-of-Evidence Protocol

论文的评测严谨性建立在一条「证据链协议」上，核心是信息公开的物理隔离。

3.1 任务 Schema：可见与不可见的分界

Agent 可见（标准条件下）：

• 仓库快照：任务前的精确状态，依赖锁定、入口可运行；剥离了 Git 历史、远程、未来变更日志、构建缓存和与解答相关的工件；
• 问题陈述：在测试作者与参考补丁作者互相查看对方工件之前冻结——从流程上防止题目泄露答案；
• 必需科学上下文 c_req：让任务良定义所需的本地、带版本的定义与约束，在所有条件下保持固定；
• 公开测试：支持交互式调试的软件与科学断言。

仅评测方可见：私有测试、契约标签、参考补丁与备选有效补丁、科学原理与定位支持块、预期文件、来源与难度元数据、污染等级、事后标注。私有测试只在补丁提交后于独立评测容器中挂载，不能通过 agent 工作区、环境变量、日志或任务元数据访问到。

打个比方：这就像一场标准化考试——学生（agent）拿到试卷和草稿纸（仓库快照 + 公开测试），可以随便打草稿自查；但标准答案（私有测试）锁在隔壁阅卷教室，只在交卷后拿出来对分。学生不可能「对着答案凑答案」。

3.2 四阶段构建流程

所有原始任务经过统一、可审计的四阶段流程：

1. 来源采样与筛选：从候选开源科学计算仓库收集真实 issue、PR、commit 与文献，剔除过于简单的修复、环境不稳定的任务、解答严重泄露的任务、与已有样本大量重叠的项目；
2. 快照冻结与复现：冻结缺陷出现前的源码快照 S_bug，在隔离容器中执行，验证目标异常能可靠复现——确保失败源于核心算法或逻辑语义，而非环境噪音；
3. 公有材料抽象与信息隔离：提取任务所考察的科学不变量与数据流约束，构建公开评测包（公开仓库、现象粗粒度描述、复现脚本、领域背景文档），不暴露补丁位置与隐藏断言；
4. 隐藏 Oracle 与反校准：基于语义等价与边界条件构建隐藏验证套件，不仅检查正常输入的执行结果，还反向检查硬编码解、启发式伪修复和不完整修复——专治「应试选手」。

3.3 三类范式的差异化再设计

原始任务还会按范式做针对性重构，每类都有自己的「防作弊」设计：

• Issue-driven：回滚到问题 commit 之前，构造最小可复现示例；把上游错误压缩成粗粒度可审计现象（如不同计算路径结果不一致）；隐藏验证器覆盖不同数据规模、边界参数、输入顺序变换，验证修复真正恢复了科学语义而非拟合公开脚本；
• Expert-exploratory：先设计高层科学场景（分子表示一致性校准、测量链偏差分析、医学图像坐标对齐等），从理论材料或结果矛盾中提取值得探索的核心差异；构造可运行的公开工作流，保留领域背景和可观察异常但隐藏缺陷源码的精确位置；隐藏验证器改变参数规模、物理拓扑、坐标顺序或边界条件，检验 agent 是否真正推断出了科学机制；
• Engineering-integration：分析仓库端到端调用链（数据加载 → 参数解释 → 中间表示构建 → 算子组装 → 数值求解），选择合适范围的功能缺口；公开代码保留完整包结构与邻近模块，复现脚本展示多阶段状态对比；隐藏验证器包括备选执行路径、状态重置测试、模块间行为契约测试，确保修复达到架构级集成而非单点通过。

3.4 科学辅助信息分离：91 个任务的配对实验

论文还有一个精巧的实验设计：科学信息的边际贡献。119 个任务中有 91 个允许把「科学辅助信息」（科学原理、上游修复、审计发现、论文摘录、专家指导——即无法从源码或运行行为直接获得的证据）从材料中剥离，同时保持仓库快照、执行环境、公开复现入口、隐藏验证器和必需上下文全部不变。

注意这个消融的严谨性：它不是把 agent 扔进「无线索环境」，而是估计在相同的仓库证据下，额外科学信息的边际贡献。仓库内在的工程线索（代码结构、接口、测试、未完成的实现）都保留着，因为这些一旦拿掉，软件任务本身就变了。

四、实验设置：八个前沿 agent 横评

论文评测了 8 个 agent 配置，横跨三家 harness：

评测指标设计得很讲究：

• Public Score / Private Score：公开/私有测试用例上的平均分；
• Fail2Pass：修复前失败的私有测试中，修复后通过的比例（修复进展）；
• Pass2Pass：修复前通过的私有测试中，修复后仍通过的比例（回归保持；若此前通过集为空则记 1）；
• Pass@1：严格二值指标，所有适用私有测试全部通过才记 1。

一句话：Fail2Pass 衡量「修好了多少」，Pass2Pass 衡量「有没有修坏别的」，Pass@1 衡量「是不是完整正确」。

五、主要结果：96.64% 与 47.90% 的鸿沟

5.1 主结果表

几个值得反复咀嚼的观察：

**第一，没有全能冠军。**DeepSeek-V4-Pro 公开分满分（100%）、Engineering-integration 最强（44.44%）；GPT-5.6-sol 私有分（78.82%）、Fail2Pass（72.30%）、Pass2Pass（97.66%）三项第一；Claude-Opus-5 总 Pass@1 和 Issue/Expert 两类领先。不同的能力维度由不同的模型领跑，说明科学软件工程不是单一能力。

**第二，头部与尾部差距悬殊。**最强 47.90% 与最弱 Qwen3.5-397B 的 14.29% 相差 3.4 倍——即便都是「前沿模型」，在科学软件上的表现也远未收敛。

**第三，也是最扎心的：公开分与 Pass@1 的鸿沟。**Claude-Opus-5 公开测试拿了 96.64%，最终 Pass@1 只有 47.90%。接近一半的落差意味着：agent 在自己能看到的测试上几乎完美，但在看不到的科学断言上大面积失败。这正是公有/私有测试物理隔离设计要暴露的问题——如果只用公开测试评测，你会以为这些 agent 已经接近满分了。

5.2 Token 消耗与性价比

论文还画了 Pass@1 对 token 消耗的散点图：Claude-Opus-5 以适中的 token 预算拿下最高 Pass@1；GPT-5.6-sol 用短得多的输出达到相近水平（输出 token 明显更省）；DeepSeek-V4-Pro 输入 token 花得多但排名靠后。Kimi-K3 和 GLM-5.2 性能较低但输入 token 更省。400B 以下的小模型中，Nex N2 的性能-token 平衡最好。

结论：模型间的差异主要在于如何有效利用上下文和生成预算，而不是 token 用量本身。烧 token 烧不出科学正确性。

六、失败机制：四类反复出现的「病因」

光知道分数不够，论文对失败案例做了人工审计，归因出四类互斥的科学失败机制：

（此外 Claude-Opus-5 还有 4 例运行/评测路径失败，不计入四类。）

各模型的错误计数分布很有信息量：

几个亮点：Claude-Opus-5 的科学类错误总数最少（58），且「表面修复」仅 2 例——它的强不是偶然，是探索纪律性最好；DeepSeek-V4-Pro 的知识/抽象错误（15）和集成错误（19）都最少，这解释了它为什么在 Engineering-integration 上最强；DeepSeek-V4-flash 泛化错误最少（6），但集成错误高达 48——每家模型的病灶不一样，改进方向也应该不一样。

把这张表和主结果表对照看，就能理解 96.64% → 47.90% 落差的本质：公开测试过、私有断言挂，正是「表面修复」和「泛化失败」的直接体现。agent 修好了看得见的东西，但科学正确性藏在看不见的地方。

七、科学知识注入：一把双刃剑

7.1 配对消融结果

这是论文最有启发性的实验：在 91 个可分离任务上，对比「有/无科学辅助信息」两种条件。论文选了 GPT-5.6-sol（xhigh）和 DeepSeek-V4-flash（high）两个配置：

结果出现了方向相反的两种效应：

• GPT-5.6-sol：科学信息让平均公开/私有分微涨（96.70→97.80、73.23→74.06），token 还更省了（输入 3.86M→3.70M），但 Pass@1 从 36.26% 掉到 31.87%；
• DeepSeek-V4-flash：科学信息让公开分、私有分、Pass@1 全面上涨（16.48%→23.08%），代价是 token 消耗大增（输入 4.84M→7.40M）。

7.2 任务级转移：平均数掩盖了什么

平均数之下是剧烈的任务级翻转。GPT-5.6-sol 有 8 个任务只有给了信息才解出，但也有 12 个任务只有不给信息才解出；DeepSeek-V4-flash 则是 9 个 vs 3 个。

对 GPT-5.6-sol 案例的检查揭示了机制：科学信息能提供局部代码症状中没有的语义约束（极限情形、坐标一致性、独立观测量、权威接口），但也可能诱发锚定（anchoring）、范围溢出（scope spillover）或对所给解释的过早依赖。说白了：给对的信息能圈住搜索空间，给偏的信息会把 agent 带进沟里，且它还深信不疑。

论文还观察到一个模式：基线较弱的 DeepSeek-V4-flash 从科学指导中获益更大，而强模型对它的依赖更低。这提示：科学知识注入的价值是模型相关的——「给 agent 塞论文」不是一个可以无脑开大的旋钮。

7.3 我的点评

这一节对做 agent / RAG 的工程师有直接警示意义。我们默认「上下文里的知识越多越好」，但这个实验表明：知识的组织和接地（grounding）方式比知识本身更重要。一条无法被 agent 用执行验证的科学原理，可能变成先入为主的枷锁。对更强的模型，宁可给可执行的复现脚本让它自己发现约束；对较弱的模型，精心对齐的科学原理才物有所值。论文自己也承认这只是描述性对比，未建立统计显著性与因果效应——但这恰恰是这个问题最值得继续挖的地方。

八、讨论：局限与开放问题

论文坦承两点局限：

1. 各科学领域任务数仍有限——最大的化学领域也只有 24 个任务，六个领域各只有 1 个，跨领域比较的可靠性受限；
2. 科学知识作用的分析还是初步的——领域知识究竟如何被使用、如何让它真正促成任务成功，探索不足。

此外我个人认为还有两点值得后续关注：一是 119 个任务的规模相对 SWE-bench 家族动辄数百上千的体量偏小，Pass@1 差一两个任务就是约 0.84 个百分点，榜单排名的噪声边界需要谨慎解读；二是四类失败机制的标注依赖人工审计，标注者间一致性等细节论文未展开，复现这类质性分析需要社区共同校准。

当然，这些局限不影响核心贡献的成立：一个防泄漏设计严密、跨 20 个领域、带失败机制标注的仓库级科学软件工程基准，本身就是社区稀缺的基础设施。

九、总结：科学软件工程是 coding agent 的下一座大山

回到标题的那个问题：**coding agent 能解决科学中的工程任务吗？**SWE-bench Science 的回答是——还不能，但我们现在知道它们败在哪里了。

三个带走的结论：

1. 公开测试会撒谎。最强的 agent 公开测试 96.64%、真实 Pass@1 只有 47.90%。任何只看可见测试的 agent 评测，都在系统性高估科学软件工程能力。公有/私有测试物理隔离 + 隐藏 Oracle 反校准，应该成为科学基准的标配方法论。

2. 失败有结构。四类机制——知识/抽象缺失、表面修复、覆盖/集成不全、科学泛化失败——把「不通过」拆成了可操作的改进方向。而且各模型病灶不同：有的缺知识，有的缺纪律，有的缺系统观。改进科学 coding agent，先看它挂在哪一类上。

3. 知识不是免费午餐。配对消融证明科学信息注入的效果模型相关、方向可正可负。错位的指导诱发锚定，精对的指导约束搜索。如何让 agent 把外部科学知识与仓库证据连接起来、并通过执行加以验证，是比「注入更多知识」重要得多的问题。

从更大的图景看，这篇论文属于「agent 评测从通用软件走向垂直领域」浪潮中的关键一块：SWE-Bench 5G 之于电信、AInsteinBench 之于科学计算、SWE-bench Science 之于全域科学软件。当 coding agent 开始被指望写科研代码、复现论文、维护实验管线时，我们需要的正是这样能区分「看起来修好了」和「科学上修对了」的度量体系。上海创新研究院与复旦团队的这项工作，为这座大山立起了第一个可靠的海拔标记——山顶还远，但路径已经清晰。