为什么重要
现有的编码智能体评测存在一个结构性盲区：它们几乎不考察”科学正确性”。
- 科学推理类基准（如 GPQA、SciEval）测的是概念性知识，答对选择题即可，不涉及动手改代码。
- 通用软件工程基准（如 SWE-bench 系列）测的是通用功能实现与 issue 修复，任务分布被 Web 应用和工具库主导。论文指出 SWE-bench 虽包含 Astropy 一个科学仓库，但这远远谈不上代表性采样。
真实的计算科学研究却是另一回事。一个研究生或博士后的日常是：读文献 → 把物理/数学假设编码进模拟代码 → 跑大规模模拟 → 根据求解器反馈迭代。这条链路要求模型能读懂长生命周期的科研仓库、理解领域特定的不变量（守恒律、k 点排序、胞几何）和数值约束，并且在不破坏科学正确性的前提下实现或修复代码。
AInsteinBench 填补的正是这个空白：它不问”你能不能修一个 Web 应用的 bug”，而问”你能不能在 PySCF、Qiskit、Einstein Toolkit 这类生产级科研软件生态里，端到端地完成一次真实的科研开发”。
构建方式
仓库选择
按四条标准从科研软件中筛出 6 个仓库，覆盖 5 个学科域：
| 域 | 仓库 | 角色 |
|---|---|---|
| QC 量子化学 | PySCF | 高精度电子结构求解器，模块化 Python 接口 |
| QI 量子信息 | Qiskit | 量子电路构建与模拟，硬件后端执行 |
| NR 数值相对论 | Einstein Toolkit + AMReX | 大规模相对论模拟、高性能 AMR 框架 |
| MD 分子动力学 | OpenMM | 力场分子动力学，面向生物分子的优化内核 |
| CI 化学信息学 | RDKit | 分子性质预测、指纹与化学信息学算法 |
选择标准为：认可度（领域事实标准，用户与引用量大）、广度（学科不同、软件栈跨 Python 前端与 C/C++/Fortran 高性能内核）、维护性（issue 讨论活跃、有结构化测试套件）、可复现（能在固定 commit 上跑自包含构建与测试，不依赖外部数据）。
两条数据流水线
A. 仓库爬取的真实 PR（bug 修复为主）
- PR 爬取：克隆仓库，用 GitHub API 收集全部 PR，抽取 issue 描述、base commit、fix patch、关联测试更新。仅保留同时满足三条的 PR：(1) 解决明确定义的科学或数值 bug（排除文档、重构、大型功能添加）；(2) 包含能暴露失败并验证修复的测试更新；(3) 已合并进主分支。
- 环境配置：为每个 PR 重建与其创建时相近的依赖栈，在最小化隔离 Docker 容器中执行，保证确定性测试与跨机器可复现。
- Fail-to-Pass 过滤：沿用 SWE-bench / Multi-SWE-bench 流程，验证每个实例在重建环境中能产生清晰的 fail-to-pass 转换。
- API 补充：对新功能类 PR，解析 fix patch 的 git diff 抽取新引入函数/类的签名，再解析 test patch 筛出真正被测试用到的符号，把精简后的 “Minimal API” 文档块附加到 issue 描述里。
B. 合成的功能实现任务
识别科研仓库中的关键计算模块（例如 Einstein Toolkit 里的 Cactus “Thorn”），移除或屏蔽模块内部分源码做功能消融，然后基于随附文档、接口规范与剩余代码上下文构造任务，要求智能体重建缺失组件——比如用特定时空度规填充网格、实现微分方程右端源项、做寻找视界的表观球面分解。这类任务的验证靠参数文件与输出检查定义的测试模拟（如 test/ 目录的参考数据），原始代码只作为参考答案。
人工验证与难度分级
10 名相关领域博士做最终审核，分两层：
- Issue 验证：确认每个实例有明确且有意义的科学背景，剔除纯工程驱动、缺乏科学相关性的问题；评估描述清晰度（能否仅凭仓库内上下文推断失败模式与预期行为）；对描述不完整的功能请求，用与测试相关的最小 API 文档补齐。
- 测试验证：审核 test patch 是否忠实捕捉预期科学需求，并修正两类失败模式——覆盖不足（测试太弱，允许伪修复）通过增加回归用例强化；覆盖过度（过度约束特定实现策略，拒绝其他科学上有效的修复）移除规定性断言。
难度按 科学深度（1–5） 与 工程难度（1–5） 两个维度打分，取整均值后分档：Easy [1, 2.33]、Medium (2.33, 3.66]、Hard (3.66, 5]。
关键发现
1. 最好的模型也只解决 44%，科学软件远未被攻克
Claude 4.5 Opus 以 44.0% 的整体解决率居首，即便在 Easy 档也只有 59.3%，Hard 档骤降到 30.2%。作为对照，同一批模型在通用 SWE-bench 类基准上已能冲到 90% 以上——通用编码能力与科研编码能力之间的落差，是这份基准最刺眼的信号。
2. 学科分化极大，最难的域指向真实科研痛点
以榜首 Claude 4.5 Opus 为例，分域得分为 QI（量子信息）67.6% > MD（分子动力学）53.7% > NR（数值相对论）44.1% > QC（量子化学）38.3% > CI（化学信息学）19.6%。
- CI 全线崩塌：GLM 4.6 与 GPT-4o 在 RDKit 上直接 0.0%，原因是化学信息学要求真实的三维空间推理。
- NR 需要跨文件协调：AMReX 一类任务常常要跨 5 个以上文件协同修改，解决率最低。
3. 失败是”知识失败”而非”编码失败”
论文归纳出五类失败模式：数学细节错误、守恒律破坏、空间推理不足、科学/代码约定误用、科学知识混淆。没有一类是语法或 API 使用问题——写 Python 从来不是科学软件的难点。
4. 定位能力不等于修复能力
论文把 issue 定位（是否编辑了 gold patch 涉及的必需文件）单独抽出评测。DeepSeek V3.2 与 Claude Opus 4.5 的定位分数都超过 0.70，但整体解决率只有 37.0% 和 44.0%。模型找得到病灶，却修不好。
5. 效率上，成功轨迹早早饱和
几乎所有问题至少需要 20 次迭代做仓库探索与定位；成功轨迹集中累积在前 20–60 步，此后额外步骤主要贡献的是失败轨迹。这意味着给智能体更多步数并不能线性换取成功率。
局限性与展望
- 仅覆盖 6 个仓库，虽横跨 5 个学科，但对整个科研软件生态仍是小样本。
- 评测使用 CodeAct Agent 单一 harness，harness 效应未被量化（同期其他基准已证明换 harness 会改变排名）。
- 合成任务依赖”模块消融”构造，与真实科研需求分布是否一致有待检验。
- 论文未报告被会议接收的 venue，目前为 arXiv 预印本。
关联基准
- SWE-bench Science：同为科学软件工程方向，但采用公开/隐藏双测试集设计
- SWE-bench Verified：通用仓库级 issue 修复的事实标准
- SWE-bench Pro：更长周期、更难的商业级仓库任务
- SciCode：科学 coding 的知识与实现评测