SWE-bench Science: 编码智能体能否解决科学中的工程任务？

TL;DR SWE-bench Science 提供 119 个科学软件修复任务，最强 agent 的 pass@1 不足 50%，揭示科学知识缺失等四类失败机制及科学指导的双刃剑效应。

问题

问题背景

科学计算已深度嵌入研究流程，软件成为科学仪器的一部分；通用编码代理（如 Claude Code）在软件工程基准上进步显著，但科学软件修复的可靠性仍不明确。

现有方法局限

主流评估如 SWE-bench 聚焦通用 GitHub issue，问题多为显式 bug 或缺失功能，以 pass@1 聚合为主。科学软件任务有本质差异：

• 错误常表现为隐式数值偏差、领域假设违反，而非异常退出；
• 修复需同时满足科学正确性与工程可执行性；
• 现有基准未区分科学知识与工程上下文的作用，也未分析失败机制，导致能力评估片面。

SWE-bench Science 专门针对科学仓库，区分三种任务范式（Issue-driven、Expert-exploratory、Engineering-integration），并揭示四个失败机制：科学抽象缺陷、表面修复、集成不足、泛化失败。

为什么难 / 重要

科学软件错误可能产出看似合理但错误的数值结果，直接影响科学结论；修复需领域抽象（守恒律、量纲、统计假设），LLM 对此类上下文敏感。同时，科学代码常依赖专业数值库、并行或特定硬件，仓库级多文件改动与系统集成复杂。业界对科研自动化需求高，但可信任度低，因此需要专门基准来揭示失败模式。

行业类比

类似医学影像 AI 若仅关注图像特征而忽略病史与生理约束，可能给出局部正确但整体误诊的判断；科学软件代理若缺乏领域约束，也会生成测试通过但结论不可信的修复。

核心洞察

• 科学软件工程的评估不能只停留在 pass@1 或测试通过率，必须显式考察修复对科学结论有效性的影响。现有 SWE-bench 系列以通用软件任务为主，通过率是主要指标，但科学代码中的错误即使通过测试也可能破坏实验推理或数据完整性。SWE-bench Science 通过引入 20 个科学领域、119 个任务，识别出科学知识缺失、抽象不足等四类失败机制，揭示了通用 agent 在科学上下文中与普通软件修复的显著差异。
• 科学知识指导对 coding agent 的效果因对齐程度而异，well-grounded 信息能提升平均性能和 token 效率，poorly aligned 信息会引发锚定，不提升精确修复成功率。这挑战了“注入更多领域知识总是有益”的直觉。消融实验显示，保留仓库与可执行工程上下文时，显式科学指导并非普遍正收益。这意味着设计 agent 提示策略或知识增强方法时，需要评估知识的相关性与质量，而非简单堆叠上下文，对构建可信科学编程助手有直接工程启示。

方法

基准构建流程

输入为来自 GitHub 的 119 个真实科学软件修复任务，覆盖 20 个科学领域（如物理、化学、生物等）。每个任务包含仓库快照、问题描述及可执行验证脚本。关键步骤是将任务按修复来源划分为三类范式：

• Issue-driven：由用户 issue 触发的缺陷修复。
• Expert-exploratory：专家在探索性研究中发现的代码问题。
• Engineering-integration：科学软件与工程系统集成时暴露的接口或兼容性缺陷。

每个任务均保留完整的仓库上下文与可执行测试，形成仓库级评估环境，避免脱离实际依赖关系的简化评测。

评估协议与失败机制分析

使用主流 coding agent（如 Claude Code 搭配 Opus-5 (max)）在所有任务上运行，计算 pass@1 指标。对失败样本进行人工归类，提炼出四种核心失败机制：

1. 科学知识或抽象不足：agent 缺乏领域概念或数学模型理解。
2. 误导性探索或表面修复：仅修补症状而未触及根因。
3. 修复覆盖不全或系统集成缺失：局部修复未考虑与其他模块的交互。
4. 科学知识泛化失败：无法将已知科学规则推广到未见案例。

科学指导消融实验

设计配对消融：在保留仓库与可执行工程上下文的前提下，移除显式科学指导（如公式、领域背景说明），对比 agent 表现。输出显示科学知识并非均匀有益：对齐良好的指导可约束修复空间、提升平均性能与 token 效率；偏移或错误的指导会导致锚定效应，不保证精确修复率提升。

与同类基准（如原始 SWE-bench）仅关注聚合成功率的差异在于，本方法引入科学领域任务范式与失败机制细粒度拆解，并量化科学知识注入的双向效应，为科学软件工程中的 agent 能力边界提供更精确的诊断依据。

实验

实验设计

• 构建 SWE-bench Science 基准，包含 119 个任务、来自 98 个 GitHub 仓库、覆盖 20 个科学领域。任务分三类范式：Issue-driven、Expert-exploratory、Engineering-integration。
• 评估多个 coding agents，核心指标为 pass@1，最佳 agent 为 Claude Code with Opus-5 (max)。
• 进行配对消融（paired ablation）：移除显式科学指导但保留仓库与可执行工程上下文，对比修复效果。

关键发现

• 最佳 agent 的 pass@1 低于 50%，表明科学软件工程对当前 coding agents 构成显著挑战。
• 识别出四种主要失败机制：
  1. 科学知识或抽象缺陷；
  2. 误导性探索或表面修复；
  3. 修复覆盖不全或系统集成问题；
  4. 未能将科学知识泛化到未见案例。
• 消融实验显示：良构科学知识能约束修复空间并提升平均性能与 token 效率；不匹配的指导会诱导锚定，且未必提升精确修复成功率。

对比解读

与通用 SWE-bench 相比，科学领域引入领域特异复杂性和隐性知识，单一通用 agent 难以有效应对。科学知识作为额外上下文的作用并非单调正向：只有高质量、对齐任务的知识才产生收益，错误注入可能有害。这提示未来工程实践需要发展领域感知的检索或知识注入策略，而非盲目添加科学文档；同时需要更细粒度的评测来区分表面修复与真实科学逻辑正确性。

行业影响

落地场景

可应用于需要维护科学计算代码的产品与业务：生物信息管线、材料模拟软件、医疗影像分析工具、气候与地球科学模型、量化金融计算库。例如，在药物研发 CRO 的流程中，自动修复组学数据处理脚本；在云科学计算平台，监控用户提交的 Notebook 依赖与数值错误并生成修复建议；在医疗影像 AI 部署中，修复推理服务的数据预处理与后处理 bug。

商业价值

当前最强 agent 在科学任务 pass@1 不足 50%，说明该垂直领域存在显著能力缺口。若将修复成功率提升，可：

• 降低科研工程师排查 bug 的时间成本，减少因实验代码错误导致的数据返工与结论失效；
• 加速科学软件版本迭代，缩短从实验脚本到可复现分析工具的周期；
• 形成面向科研与工程交叉领域的 AI 代码助手差异化能力，支撑 B 端订阅或内部提效。 但需注意，科学知识引导并非总是正向：错误锚定可能降低修复准确率，产品设计应引入知识注入开关或置信度过滤。

与现有工作流接口

可将该基准作为模型选型与回归评测集，接入 GitHub Actions / GitLab CI 的 pull request 检查，或作为 IDE 插件（VS Code / JupyterLab）的智能修复后端。通过 MCP 或 API 调用外部科学知识库（论文摘要、公式库、领域文档），在 agent 生成修复后利用基准中的失败机制标签进行验证。同时，失败案例可构造 fine-tuning 数据集或 RAG 索引，提升 agent 在科学软件工程中的推理与泛化能力。项目主页：SWE-bench Science

局限

• **数据集规模与覆盖有限**：SWE-bench Science 包含 119 个任务、98 个仓库，仅覆盖 20 个科学领域，平均每个领域约 6 个任务，远小于 SWE-bench 原版的 2294 个任务。这种规模限制了细粒度的跨领域对比和统计显著性，且任务主要来自公开 GitHub issue 或专家探索，可能偏向容易发现和可复现的问题，难以代表科学软件中更深层的数值错误、并行缺陷或硬件相关故障。对实际工程而言，该基准更适合作为初步诊断工具，而非全面反映 agent 在科学软件维护中的真实表现。
• **评估指标较为单一**：论文主要采用 **pass@1** 作为核心指标，仅衡量一次性修复是否通过测试，未考虑修复引入的回归、执行效率、代码质量或数值精度。科学计算代码的正确性往往不能仅由单元测试保证，例如浮点误差、收敛性、物理量守恒等需要更专门的验证。此外，pass@1 无法区分 agent 是真正理解问题还是碰巧通过测试，也缺乏对多次尝试或交互式调试的评估。建议后续工作引入更丰富的指标（如 pass@k、覆盖率、数值误差阈值、资源消耗等），以更全面刻画 agent 能力。
• **科学知识消融的因果推断有限**：论文通过 paired ablation 移除显式科学指导，发现科学知识并非均匀有益，但该设计可能无法完全隔离领域知识，因为仓库结构、测试用例和文档本身已隐含科学背景。结果“错误对齐的指导会诱发锚定”可能部分归因于指导文本的质量和与任务的匹配度，而非科学知识本身的作用。此外，失败机制的分类基于人工分析，带有一定主观性，且未在更大规模或不同模型上验证其普遍性。对于工程实践，这意味着在真实系统中注入领域知识时需要更谨慎地评估其质量和时效。