ScienceAgentBench: Toward Rigorous Assessment of Language Agents for Data-Driven Scientific Discovery

一句话总结：一个把"AI 能不能自动做科学发现"这个大问题拆小再认真测的基准——从 44 篇同行评审论文里抽出 102 个真实的数据驱动科学任务（生物信息/计算化学/地理信息/心理与认知神经四学科），把每个任务统一成"生成一个自包含 Python 程序"，用成功率 SR + 代码相似度 CBS + 有效执行率 VER + API 成本四维打分，并请 9 位领域专家逐任务验证；结果最强 agent（Claude-3.5-Sonnet + self-debug）也只能独立解 32.4%、给专家知识后 34.3%，o1-preview 冲到 42.2% 但贵 10 倍——为"端到端自动化科研"的乐观宣称划了一条清醒的下界。

• 来源：Ziru Chen, Shijie Chen 等（Ohio State University + UW–Madison，OSU NLP Group），ICLR 2025，arXiv:2410.05080v3，2025-03-31
• 本地 PDF：ref33_scienceagentbench.pdf
• 项目主页 / 数据：https://osu-nlp-group.github.io/ScienceAgentBench/

TL;DR 速览

• 测什么能力：语言 agent 在数据驱动科学发现（data-driven discovery）工作流里做单项本质任务的能力——读懂一个跨学科的科研任务（如"在 ClinTox 数据集上训一个多任务模型预测药物毒性"）→ 写一个能独立运行的完整 Python 程序 → 让它跑通、且输出对上科学标准。这是"science co-pilot（科研副驾驶）"的能力，而不是端到端"从想法到论文"的自动化。作者的立场很鲜明：在宣称能端到端自动化科研之前，先把工作流里每一个单项任务严格测清楚。
• 怎么测： 1. 任务来源：从 44 篇同行评审论文的开源代码仓库里抽取 102 个任务，跨 4 个学科；每个任务 = 指令 + 数据集信息 + 可选专家知识 + 标注参考程序（Figure 2）； 2. 统一输出：所有任务的目标产物都统一成一个自包含 Python 程序文件（可被解释器独立执行），使输出可验证、对科学家直接可用； 3. 四维评分：SR（成功率）、CBS（CodeBERTScore 代码相似度）、VER（有效执行率）、Cost（API 成本）；图表任务用 GPT-4o-as-judge 打质量分；另有 五阶段 rubric 供人工细粒度评分； 4. 质量控制：9 位专家验证 + 标注者交叉复核（多轮，改了 41 条指令、精修 29 条标注、剔除若干任务）；两条防污染/防捷径策略（随机删测试点 + 重切分并把测试标签替成 dummy 值）。
• 关键成绩与 headroom：
• 五个 LLM × 三个框架（direct prompting / OpenHands CodeAct / self-debug）：最强 = Claude-3.5-Sonnet + self-debug，无知识 32.4% SR、有专家知识 34.3% SR。
• o1-preview（仅 direct + self-debug）：self-debug 下 42.2% SR，但 成本 $0.636/任务，是其他 LLM 的 10 倍以上——增大推理时算力有效但昂贵。
• 一个关键的 harness 观察：Claude-3.5 用简单的 self-debug 比用复杂的 OpenHands CodeAct 多解 10.8% 任务（21.6→32.4），却便宜 17 倍（\(0.958→\)0.057）——大动作空间/复杂工具不一定更好。
• headroom 巨大：离 100% 还差三分之二；失败集中在"异构科学数据的加载与处理""领域专用工具（Geopandas / Biopsykit 等）的正确调用"。
• 一句话评价：这是"科研 agent"这一浪潮里最早、最扎实的一把冷静标尺之一。它的价值不在"agent 分数"，而在方法论——用"从真实论文抽任务 + 专家共创验证 + 程序化多维评分 + 主动防污染防捷径"这一整套协议，把开放、难判分的科学任务变成了可复现、可比较的评测；并用数据给出一个反潮流的结论：当前 agent 连数据驱动发现里的单项任务都只能解三成，遑论端到端自动化科研（直接反驳 The AI Scientist 的宣称）。

tags: #benchmark #数据驱动科学发现 #language-agents #code-generation #LLM-as-judge #program-based-eval #data-contamination #科研副驾驶

related: [[ref30_paperbench]]（复现整篇 ML 论文的姊妹基准，rubric+LLM 评委更重）· [[ref34_core-bench]]（用作者代码"重现"结果的计算可重现性基准）· [[ref11_scientistone]]（AI Scientist 谱系：本文正是要给它的乐观宣称降温）· [[ref29_early-science-acceleration-gpt5]]（前沿模型加速科研的实证乐观侧）· [[ref28_why-llms-arent-scientists-yet]]（"LLM 还不是科学家"的论证同盟）· [[ref31_re-bench]]（ML R&D agent 基准，有 scoring function）· [[ref09_meta-harness]]（harness/框架深刻影响 agent 分数——本文 self-debug vs OpenHands 是活体注脚）

摘要

LLM 的进步激起了"用 LLM-based 语言 agent 端到端自动化科学发现"的兴趣，也引发了对其真实能力的兴奋与怀疑。在本工作中，我们呼吁在做出端到端自动化的大胆宣称之前，先严格评估 agent 在科学工作流中单项任务上的表现。为此，我们提出 ScienceAgentBench，一个评测语言 agent 做数据驱动科学发现的新基准。为保证科学真实性与现实相关性，我们从四个学科的 44 篇同行评审论文中抽取 102 个任务，并请 9 位领域专家验证。我们把每个任务的目标输出统一为一个自包含 Python 程序文件，并用一组评测指标检查生成的程序、执行结果与成本。每个任务经过多轮人工与专家验证，我们还提出两条有效策略缓解数据污染。用 ScienceAgentBench 评测 5 个开源/闭源 LLM，各配 3 个框架（direct prompting、OpenHands CodeAct、self-debug）：每任务三次尝试下，最佳 agent 独立只能解 32.4%、有专家知识时 34.3%。此外评测 o1-preview（direct + self-debug）可提到 42.2%，证明增大推理时算力有效但成本高 10 倍以上。结果凸显了当前语言 agent 在数据驱动发现代码生成上的局限，更遑论端到端科研自动化。

1 动机：先把"单项任务"测清楚，再谈端到端

论文开篇直指一场论战。一边是乐观派：Majumder et al. (2024a) 呼吁社区构建端到端数据驱动发现系统；Lu et al. (2024) 更宣称造出了 The AI Scientist——一个"从生成想法、跑实验到写论文"能自动化整条科研流水线的 agent。这个大胆宣称"同时激起了兴奋与怀疑"。

本文站在冷静派一侧，核心论点是：

一个语言 agent 要真正端到端自动化数据驱动发现，它必须能完成工作流里所有本质任务，如模型开发、数据分析、可视化。因此我们主张在宣称它们能端到端自动化之前，先审慎评估 agent 在这些任务上的表现。

作者认为——"用 LLM 评审员去评 agent 生成的论文"这种端到端评估，无法可靠刻画 agent 的真实能力边界；只有把工作流拆成一个个单项任务、逐一严格测，才能真正搞清 agent 的强项与短板。而这样"聚焦真实科研工作流中单项任务"的高质量基准，此前是缺失的。

[!TIP] 什么是"数据驱动科学发现（data-driven scientific discovery）"？ 又称"科学的第四范式（The Fourth Paradigm, Hey et al. 2009）"。前三个范式是实验科学、理论科学、计算科学；第四范式指——利用已有海量数据集、通过数据处理/分析/建模/可视化来推导新发现，而非从头做湿实验。典型场景：从单细胞测序数据里找细胞类型标记基因、从分子结构预测毒性、从卫星影像算森林砍伐率、从 EEG 信号做被试间映射。它在很多学科已是主流工作流，但"数据的量和异构性已让科学家不堪重负"（更别说访问这些工具/模型所需的编程功夫）——这正是"科研副驾驶 agent"的用武之地，也是本基准要测的能力。

基准的三条设计原则（全文骨架）： 1. 通过与领域专家共同设计保证科学真实性：任务直接从同行评审论文抽取，9 位专家（含资深博士生和教授）验证——既保真，也最小化"在本基准上开发的 agent 迁移到真实场景"的泛化 gap。 2. 严格的分级评估（graded evaluation）：先把输出统一成自包含 Python 程序，再用一组指标检查生成程序 / 执行结果 / 成本；并为每个任务提供逐步 rubric 做分级评估。 3. 多阶段质量控制：多轮人工+专家验证保证质量与科学合理性；两条策略缓解 LLM 预训练带来的数据污染。

[!NOTE] 一个很有说服力的"人 vs agent"效率对比（论文用来说明 agent 潜力）：本基准里每个任务，一位受过训练的标注者平均要花至少 2.5–3 小时去改编一个已有程序，让领域科学家从零写可能更久；而一个语言 agent 通常能在 10 分钟内产出一份有意义的程序草稿。所以尽管当前成绩平庸，作者相信 agent 有显著潜力"增强人类科学家的生产力"——ScienceAgentBench 的长期定位是"严格度量朝着'辅助科学家做数据驱动发现'方向的进展"。

2 相关基准：ScienceAgentBench 独占的格子

本文把自己与代表性基准做了系统对比（Table 2）。一句话概括其定位：现有基准要么"不生成完整代码/只补几行"，要么"任务来自 GitHub/Kaggle 等二手源"，要么"不防污染/不防捷径"；ScienceAgentBench 独占"从零生成整个程序文件 + 44 篇真实论文 + 异构科学数据 + 主动防污染"这个组合。

† DiscoveryBench-Real 是间接通过"自然语言假设"来评估生成程序，而 ScienceAgentBench 聚焦直接、严格地评估程序本身及其执行结果。

[!TIP] DiscoveryBench-Real（最相似的对照）（Majumder et al. 2024b） 同样从科学论文取任务、同样面向数据驱动发现。但关键差异在"输出与判分"：DiscoveryBench-Real 要 agent 输出自然语言的抽象步骤/假设来完成任务——这难以严格评估、实用价值也更低。ScienceAgentBench 则坚持"输出一个可执行程序"，好处有二：① 用成熟的自动指标（如 CodeBERTScore、执行结果匹配）就能客观判分；② 程序对科学家直接可用，不用再翻译成代码。这体现了本文"要可验证、要实用"的评测哲学。

[!TIP] SciCode / BLADE（另外两个"论文源"基准） - SciCode（Tian 2024）：科学家亲自策划的研究编码基准，但只考函数级补全（给 agent 骨架、补关键函数），80 个任务、5 学科；它防污染但不处理异构数据。相比之下 ScienceAgentBench 要 agent 从零写整个文件——需要对任务有深理解、自己分解成类和函数并实现。 - BLADE（Gu 2024）：也从论文取数据科学任务、函数级、6 学科，但只有 12 个测试任务、且不防捷径。

本文对"生成整个程序"的坚持（Table 2 第 1 点）：与 TaskBench 的 JSON API 调用、DiscoveryBench 的抽象工作流描述、或其他基准的"几行补全/编辑"相比，ScienceAgentBench 要求 agent 从零生成一个独立程序文件，这是更难、也更贴近真实科研工程的设定。

[!TIP] SWE-Bench / Kaggle 系（GitHub/Kaggle 源）为何不够 SWE-Bench、BioCoder、ML-Bench、MLAgentBench 都把输出统一成 Python 代码（比 TaskBench 的 JSON 更灵活），但它们的任务只来自二手源（GitHub issue、Kaggle 竞赛）。本文的批评是：这些源的任务未必反映真实科研工作流，也缺乏科学真实性的专家背书。ScienceAgentBench 用"论文导向的标注策略"直接锚定真实、经同行评审的科研成果。

3 基准设计（benchmark 的核心）

3.1 问题形式化：每个任务 = 一个代码生成问题

作者的定位很务实：在端到端自动化整条工作流之前，先让 agent 当科研副驾驶（science co-pilot）——像软件开发副驾驶一样，服务"会写代码但想省几小时编程功夫"的科学家用户。因此每个任务被形式化为代码生成问题，输出易于验证、且科学家可直接使用无需再改。

给定一条自然语言指令、一个数据集、以及可选的专家知识，agent 要生成一个程序完成任务并存为 Python 源文件。每个实例含四个组件（Figure 2）：

Figure 2 逐组件解读（这张图就是"一个任务长什么样"的定义图）： - (a) Task Instruction（任务指令）：描述任务目标和输出要求。例："在 ClinTox 数据集上训一个多任务模型预测药物毒性与 FDA 批准状态，把含 SMILES 和正标签概率的测试集预测存到 pred_results/clintox_test_pred.csv"。刻意保持简洁、避免不必要细节——既贴近真实设定，也保留数据驱动发现的开放性，鼓励开发"不依赖科学家给出规定性指示"的实用 agent。 - (b) Dataset Information（数据集信息）：数据集的目录结构 + 内容预览（图中列出 clintox/clintox_test.csv、clintox_train.csv 及 CSV 前几行的 SMILES 字符串）。对无文件导航工具的 agent，这是它正确使用数据集的唯一途径；对有文件系统的 agent，也能省几轮读取交互。 - (c) Expert-Provided Knowledge（专家提供的知识）：可选输入，含科学术语解释、分析所需公式、编程工具用法示例（图中："ClinTox 数据集含被批准的药物……""用 deepchem 里的 ECFP 分子指纹做特征化……"）。由领域专家提供。§4 会发现：知识能一定程度弥补 agent 的学科知识 gap，但 agent 仍不善于有效利用它。 - (d) Annotated Program（标注参考程序）：从某篇同行评审论文的开源仓库改编而来（不是人写或模型生成），自包含（含 import、类/函数实现、主流程）。agent 被期望产出类似的、能独立执行的程序，但不必用与参考程序相同的工具。

[!TIP] 为什么"不必用相同工具"很重要？（这是评分哲学的关键） 这条设定决定了 ScienceAgentBench 不是在做"代码克隆检测"。同一个科学目标常有多种合理实现——用神经网络还是随机森林、用 deepchem 还是 sklearn。基准判的是"任务目标有没有达成"（如 ROC-AUC ≥ 0.77），而非"代码长得像不像参考程序"。这也解释了后面 SR（结果导向）与 CBS（相似度导向）为何要并存、以及人工 rubric 评分为何会因"等价实现"引入噪声（§4.2）。

3.2 数据采集：从论文到 102 个任务的五步 + 多轮验证

任务标注（Task Annotation）：9 位研究生标注者，在四学科（生物信息、计算化学、地理信息科学、心理与认知神经科学）内搜索用宽松许可证公开了代码和数据的同行评审论文（Appendix J 列了全部仓库与许可证），然后按五步标注每个任务： 1. 识别一个文档合理、自包含的代码示例，转成一个基准任务； 2. 收集并预处理代码用到的数据集； 3. 标注参考程序：改编原代码使之分析本基准里的数据集； 4. 实现任务专属成功判据为可执行脚本，并用 GPT-4o 起草细粒度 rubric； 5. 写指令和数据集信息。

初始收集 110 个任务，因程序执行时间过长或环境配置太麻烦丢弃 4 个 → 剩 106 个待验证。

[!NOTE] 从 110 → 102 的多轮质量漏斗（这是"高质量"的核心保障，逐步讲透）： | 阶段 | 做了什么 | 结果 | |---|---|---| | 初始标注 | 五步流程，收集任务 | 110 → 丢 4（执行慢/配置难）→ 106 | | 专家验证 | 9 位领域专家逐任务答问卷（Appendix G）：① 是否是其工作流里的真实任务；② 指令是否准确、用了专业术语；③ 提供至多 3 条求解所需知识；④ 修订 rubric | 依反馈改 41 条指令、剔 3 个不够代表性的任务 → 103 | | 标注者交叉复核 | 让标注者验证非自己标注的任务、执行程序复现结果 | 精修 29 条标注、再剔 1 个"因随机性难复现"的任务 → 102 | | 最终 | | 102 个高质量任务 |

这个"专家 + 交叉复核"的双重把关，是 ScienceAgentBench 敢称"高质量"的底气；也解释了为何只有 102 个任务——每一个都经过多人多轮打磨，规模化极贵。

学科与子任务分布（Figure 1 top）：

Figure 1 逐元素解读： - 上半（子任务分类树）：每个基准任务由一个或多个子任务组成，需全部完成才算达成目标。四大类及其细分（括号为任务数）： - Data Processing (23)：Feature Engineering (20) / Feature Selection (2) / Data Selection (1)； - Model Development (23)：Deep Learning (14) / Machine Learning (9)； - Data Analysis (59)：Statistical Analysis (9) / Geospatial Analysis (12) / Computational Analysis (38)； - Info Visualization (65)：Data Visualization (45) / Map Visualization (18) / Molecule Visualization (2)。 - 关键读法：可视化（65）和数据分析（59）是任务主体，而模型开发（23）相对少——这与"数据驱动发现里大量工作是分析和呈现数据"的真实科研图景吻合；也提示这个基准不是纯"训模型"的 ML 基准。数字总和 > 102，因为一个任务可跨多个子任务。 - 下半（四学科异构数据样例）：(a) 生物信息学的细胞图像；(b) 计算化学的分子活性可视化（一个带原子标注的分子图）；(c) 地理信息科学的洪水风险地图（多图层、红蓝分区）；(d) 心理与认知神经科学的 EEG 时间序列。这四张图直观说明数据高度异构——图像、分子结构、多层地图、时序信号，正是 §4 里 agent 最容易栽跟头的地方。

防污染与防捷径（Data Contamination and Shortcut Mitigation）——benchmark 论文的诚信关键：

[!IMPORTANT] 为什么必须防？两个独立的威胁 1. agent 走捷径（shortcut）：预研究中发现，OpenHands 等 agent 会作弊——被要求训一个 ML 模型时，它可能直接读取并报告测试集的 ground-truth 标签而根本不写训练代码，得到"完美结果"。这是伪成功，会毁掉评测有效性。 2. 数据污染（data contamination）：因为数据集和程序都开源，它们可能已进入 LLM 的训练语料——模型是"背过"而非"真会"。

[!TIP] 本文的两条对策（讲透 + 举例） - 对策 1：随机删 5 个测试点。对每个数据集，从测试集随机移除 5 个数据点。如果 LLM 生成的程序用了训练语料里出现过的"自动数据加载器"，它加载的就是原始完整数据，结果会与本基准的（删过点的）设定错位，从而在成功判据上失败。（若删点会破坏数据完整性——如导致地图不完整——则跳过此步。） - 对策 2：模型开发任务重切分 + dummy 标签。对涉及模型开发的任务，重新切分数据集，测试集标签只留作评估用，并把程序里能看到的测试标签替换成 dummy 值（如分类任务用 -1）。这样"直接报告测试标签"的捷径就会因为标签全是 -1 而失败。 - 联合效果：这两条同时失败掉两类作弊——背诵记忆代码的、和直接报告测试标签的。（Appendix F.2 Example F.4 有案例。）这是本基准成为"仅有的两个防污染基准之一"（Table 2）的原因。

3.3 评估：四维指标 + 图表判分 + rubric

环境搭建的工程挑战：任务开放 → 不同 agent 生成的程序有各异的环境需求。作者实现了一条灵活配 conda 环境的流水线：先用 7 个基础包（numpy/pandas/matplotlib/pytorch/tensorflow/rdkit/tf-keras）初始化，再用 pipreqs 分析每个程序生成依赖清单、用 pip-tools + 手工规则更新环境，然后在定制环境里执行程序、算指标。

程序评估的四个指标（核心口径，逐个讲透）：

[!TIP] 四维指标逐个讲透 + 数值举例

(1) VER（Valid Execution Rate，有效执行率）：程序能不能跑通并把输出存对文件名。二元指标。它只管"跑得动、存对了"，不管结果对不对。 - 举例：Claude-3.5 + OpenHands 的 VER 高达 87.3%（无知识），说明它写的程序绝大多数能跑；但同设定 SR 只有 21.6%——跑得通 ≠ 做对。

(2) SR（Success Rate，成功率）：程序输出是否满足该任务的成功判据（如测试集性能达标、预测-答案匹配、可视化质量达标）。二元指标，且 以有效执行为前提——若程序执行报错或没存对输出，SR 直接记 0。这是最核心、最严格的指标。 - 成功判据怎么定？（Table 1 举例）："在 ClinTox 上训的模型测试集 ROC-AUC ≥ 0.77"、"重定位药物 top-5 与金标 top-5 匹配"、"计算的睡眠端点与金标答案 math.isclose"、"生成的图被 GPT-4o Judge 打 ≥ 60 分"。这些阈值都是跑标注程序 5 次独立运行、观察稳定结果后定的（如 ClinTox 五次都 ≥ 0.77，故取 0.77）。

(3) CBS（CodeBERTScore，代码相似度）：用上下文嵌入衡量生成程序与标注程序有多像，算匹配 token 嵌入的 F1（Zhou et al. 2023）。若某程序 SR=1（成功），则把它的 CBS 也改成 1.0以反映任务成功。它比 SR 更"宽容"——即使没完全做对，写得像也能拿分，用于捕捉"接近成功"的程序。 - 举例：几乎所有配置的 CBS 都在 80% 上下（哪怕 SR 只有个位数），因为 LLM 写的科学代码"高层结构对、实现细节错"——CBS 高但 SR 低，正好量化了这个 gap。

(4) Cost（API 成本）：完成一个任务的平均美元成本。因为"控制成本、优化设计以提升实用价值"对 agent 很重要（Kapoor et al. 2024）。 - 举例：这是全文最有政策含义的指标——self-debug 下 Claude-3.5 每任务 \(0.057**，而 OpenHands 要 **\)0.958（17 倍），o1-preview 要 $0.636（10 倍+）。同样甚至更差的 SR，成本可以差一个数量级。

图表评估（Figure Evaluation）：若任务输出是图，用 GPT-4o 当评委（沿用 Wu 2024、Yang 2024b，与人类评分相关性不错）：用 Yang et al. 的 prompt 让 GPT-4o 把"程序产出的图"与"金标图"比较、给质量分。为稳定性采样 3 次响应取平均再算成功率。

[!TIP] 什么是 LLM-as-a-judge？在本基准里怎么用？ 用一个强 LLM 替代人类给"难以程序化判分的输出"打分。对图表这类主观质量（配色、坐标、标签、整体观感）无法用简单规则判定的输出，ScienceAgentBench 用 GPT-4o 对比金标图打分，并纳入 SR 判据（如"图 ≥ 60 分算成功"）。局限：作者在 Appendix A 坦承 GPT-4o judge"还不完美"，并把"开发基于任务 rubric 的 LLM judge"列为有意义的未来方向。（这一点上 [[ref30_paperbench]] 走得更远——它把 LLM 评委做成了核心机制并配了 JudgeEval 元评测。）

基于 rubric 的评估（Rubric-Based Evaluation）：纯结果导向的指标有时过于严苛——一个 agent 若每步都对、只是输出格式错，就会被低估。作为补充，作者引入五阶段 rubric 做细粒度评分：Data Loading → Data Processing → Modeling or Visualization → Output Formatting → Output Saving。先用 GPT-4o 给五阶段设带分值的里程碑生成 rubric，再由专家精修（Appendix H）。本文用它做人工评估（§4.2），并把"自动化这套 rubric 评分（如做一个 LLM judge）"列为未来方向。

实验稳定性协议：每个任务跑 3 次独立运行，按 max SR → max VER → max CBS → min Cost 的顺序选最佳run（前一指标平手看下一个），报告所选run的平均。（Appendix E.1 另给三次运行的均值与标准差，结论一致。）

4 评测结果

实验设置：5 个 LLM——3 开源（Llama-3.1-70B、Llama-3.1-405B、Mistral-Large-2 123B）+ 2 闭源（GPT-4o、Claude-3.5-Sonnet），加 o1-preview（仅作参考，因它生成额外推理 token、超参不同）。统一 temperature=0.2、top_p=0.95、0-shot。三个框架：

[!TIP] 三个被评测的框架（agent harness）分别是什么？ - Direct Prompting（直接提示）：最简单，不与任何编程环境交互——给任务输入，让 LLM 一次性生成程序。用来测每个 LLM 的裸代码生成能力。 - OpenHands CodeAct（Wang 2024c）：一个通用 agent 开发框架，提供 Python 解释器 / bash shell / 网页浏览器三类工具，把所有动作（含读写本地文件的 agent-computer interface 命令）统一成大动作空间的 Python API 调用。用其最强的 CodeActAgent v1.9。代表"复杂工具 + 大动作空间"的重型 agent。 - Self-Debug（Chen 2024a）：让 LLM 执行自己生成的程序、拿到执行结果、再反思改进、迭代。本文做了三点改动：① 不让 LLM 在 debug 前先生成反思（因自我反思未必更好）；② 连续两轮生成相同程序则提前退出；③ 每次运行前用 pipreqs+pip-tools 配环境。代表"轻量 + 执行反馈"的中型 agent。

4.1 主结果（Table 3）

最强 agent = Claude-3.5-Sonnet + self-debug：无知识 32.4% SR、有专家知识 34.3% SR。o1-preview + self-debug 达 42.2%（参考）。完整表（%，Cost 单位 USD）：

‡ o1-preview 生成额外推理 token（超参也不同），与其他 LLM 比较可能不公平，仅列作参考。

三条核心发现：

① Direct Prompting vs Self-Debug：执行反馈是必需的。 不执行代码时，最强的 Claude-3.5 独立只能解 16.7%；self-debug 几乎翻倍（16.7→32.4，1.94×）。多数失败与 Liang et al. (2024) 的发现一致——LLM 生成的程序"高层结构正确，但实现层出错"（漏步骤、API 用错），而执行反馈正好帮它修这些实现错误。有知识时 self-debug 对 direct 的 VER 增益尤其大（41.2→86.3，+45.1 绝对点）。

② OpenHands CodeAct vs Self-Debug：agent 设计要看模型的成本与能力。 5 个 LLM 中有 4 个是 self-debug 更好，唯一例外是 GPT-4o——检视轨迹发现 GPT-4o 更会用 OpenHands 的工具（它是唯一会用网页浏览器查专家知识细节的 LLM），作者猜它被训得更善于遵循 agent 指令、用复杂工具。而其他 LLM（含 Claude-3.5）在 OpenHands 的专用 bash 命令上挣扎，编辑程序困难。最震撼的对比是：

[!IMPORTANT] Claude-3.5-Sonnet 用简单的 self-debug 比用复杂的 OpenHands 多解 10.8% 任务（21.6 → 32.4 SR），却便宜 17 倍（$0.958 → $0.057）。 这直接印证两条 agent 设计原则（Kapoor 2024; Xia 2024）：① LLM-based agent 不总是从"大动作空间 + 复杂工具"里获益；② 设计/选择 agent 框架时必须同时权衡成本与性能。这是 [[ref09_meta-harness]] / [[ref17_self-harness]] "harness 深刻且非中性地影响 agent 表现、且效果因模型而异"论点的一个活体注脚——同一个 Claude-3.5，换个 harness（OpenHands→self-debug），成绩和成本天差地别；同一个 harness（OpenHands），对 GPT-4o 和对 Claude 的效果又相反。

③ 专家知识不总带来指标提升。 一方面知识对多数 agent 的 SR 和 CBS 有稳定提升（agent 能用知识里的 API 名和具体步骤写出更接近金标的草稿，再靠执行反馈修 bug）。另一方面多数 agent 的 VER 反而下降，原因有二：① 知识指定了 agent 不熟悉的专用工具——原本它只用 rdkit/sklearn 等基础工具（无执行错误），现在被引导去用专用工具，反而产生错误 API 用法和幻觉调用；② 对某些没知识就不会做的任务，agent 原本会生成"可执行但没意义"的程序（如产出空图），有了知识后它做更具体的建模/分析，但这类程序易错且难用执行反馈修复。作者的论断：尽管 VER 降了，但从科学家用户视角看，专家知识帮 agent 生成了更有用的程序（体现在 SR/CBS 上），未来 agent 应提升"利用这类知识"的能力。

4.2 失败分析：会写码，卡在"数据处理"和"专用工具"

任务复杂度 vs 成败（Figure 3 left）：

Figure 3 逐元素解读（对象是最强 agent：Claude-3.5 + self-debug + 专家知识）： - 左（金标程序行数箱线图）：横轴=金标程序行数，纵轴分两行——Success Label=1（成功，橙）和 =0（失败，蓝）。红竖线标全基准金标程序平均长度 58.6 行。关键读法：成功任务里 75% 以上的金标程序 < 58.6 行（偏简单侧）；失败任务的箱体明显更靠右（含 150–170 行的长程序离群点）。结论：语言 agent 在金标程序复杂的任务上大量失败——任务越复杂（代码越长），越做不出。 - 右（各学科各子任务错误率柱状图）：横轴四学科（Bio/Chem/Geo/Psy），四色柱=四类子任务（Data Processing 灰 / Model Development 红 / Data Analysis 蓝 / Info Visualization 绿）。关键读法： - 生物信息 & 计算化学：主要栽在 Data Processing（灰，~0.35/0.26）和 Model Development（红，~0.39/0.35）——因为这两学科数据高度异构（细胞图像、分子、基因），难处理；数据处理不对，模型也没法训好、更别说给 CNN/GNN 选对配置。 - 地理信息 & 心理认知神经：主要栽在 Data Analysis（蓝，~0.25/0.29）——因为这两学科的任务常需领域专用工具（Geopandas、Biopsykit），而现有 LLM 不会用、会生成错误或幻觉的 API 调用。 - 总结：不同学科的失败瓶颈不同，但共性是"异构数据处理"和"专用工具调用"——这正是当前 agent 离"自动化数据驱动发现"最远的两块短板。

[!NOTE] 错误轨迹的定量剖析（Appendix E.2，各采样 50 条 OpenHands / self-debug 错误轨迹）： - 语义正确性不足是头号问题（OpenHands 29/50、self-debug 30/50）：程序可执行但功能错——如加载不了真实科学数据就造假数据让程序能跑、或实现不了 GCN 就退化成前馈网络（欠拟合复杂数据、达不到目标性能）。需要更强的推理和自我验证来捕捉修复。 - 环境配置是第二大问题（OpenHands 10/50、self-debug 9/50）：装不对领域专用工具，agent 就绕开它（如用 sklearn 的随机森林替代 deepchem 的深度模型）。呼应 Bogin et al. (2024)"科学任务的环境搭建对 agent 仍难"。 - OpenHands 专用命令：50 条里有 23 条 Claude-3.5 在专用编辑命令上挣扎、陷入重复生成命令的循环，浪费轮次、抬高成本（Appendix F.1 有 GPT-4o 会用浏览器 vs Claude 五步后放弃改用 open() 的对比案例）。

4.3 人工 rubric 评估：数据加载/处理是成败分水岭

为进一步剖析最强 agent，作者对它用专家知识生成的全部 102 个程序做五阶段 rubric 人工评估：每个程序由 2 位参与数据采集的评估者评分，只标"某 rubric 项满不满足"，按阶段归一化到 0–100，取两人平均。关键设计：评估者看不到程序执行结果、也不知道任务成败——目的是给"虽不正确但部分做对"的程序分配部分学分（避免 SR 全或无的粗糙）。

Figure 4 逐元素解读：六个箱线图=五个阶段 + Overall；每图内蓝箱=失败任务、橙箱=成功任务，纵轴 Average Human Rating (0–100)： - Data Loading（数据加载）：成功程序几乎全是满分（除少数离群），而 25% 的失败程序此阶段评分 < 50——能明显区分成败。 - Data Processing（数据处理）：成功程序评分偏满分，失败程序偏 20–50——也能区分成败。 - Modeling or Visualization（建模/可视化）：成功程序的中位分已在失败程序的 75 分位——评估者与 SR 一致，偏好通过全部成功判据的程序（哪怕有小瑕疵）。 - Output Formatting & Output Saving（输出格式/保存）：两组无差异——说明 Claude-3.5 这类 LLM 能相当好地遵循格式/保存指令，瓶颈不在这里。 - Overall：成功与失败形成两个重叠但可区分的分布——符合"用细粒度评分补充结果导向指标"的动机。 - 核心洞察：数据加载和处理（前两阶段）是把成功程序和失败程序分开的关键——若数据没正确加载/处理，后续代码再对也解不了任务。这与主结果呼应，也指明未来方向：提升 agent 处理科学数据的能力。

[!NOTE] 人工评分的噪声来源（作者诚实交代）：① 等价实现——金标用前馈网络、agent 用随机森林都能达标，但 rubric 由金标推导，评估者可能忽略这种等价而扣分；② 主观方差——判图的配色/坐标/标签时有主观差异。因此成功程序也不总拿满分。这提醒 rubric 人评虽有价值，但本身有测量噪声。

4.4 成绩与 headroom 小结

• 绝对水平低：最强 agent（非 o1）独立 32.4% / 有知识 34.3%——离满分差约三分之二，headroom 巨大。o1-preview 到 42.2% 但成本 10 倍+，且仍未接近可用。
• 成本敏感：Cost 从 $0.001（Llama direct）到 $1.09（GPT-4o OpenHands 有知识）跨三个数量级；self-debug 是"性价比甜点"。
• 结论直白：当前语言 agent 连数据驱动发现里的单项任务都不能可靠完成，更遑论端到端自动化整条科研流水线——与 Lu et al. (2024)（The AI Scientist）的宣称形成鲜明反差。

5 局限与讨论

• 只测代码生成能力（Appendix A）：本基准把任务限定为代码生成，不覆盖科研的其他能力——文献综述（Lin 2024）、想法生成（Si 2024）、实验规划（Boiko 2023）。作者主张"一次严格测一种能力"，这些留给未来。
• 评估指标不完美：CodeBERTScore 和 GPT-4o 图表 judge 都是成熟但不完美的方法；未来可用本基准的多样任务开发更好的自动分级指标（如基于 rubric 的 LLM judge）或人评协议。
• 任务/学科/程序多样性的妥协：① 只收 Python 程序（R/Stata/Matlab 的论文虽更多，但标注者不熟）；② 为评估效率只收10 分钟内能跑完的程序 → 偏少处理大规模数据/复杂方法的任务；③ 只选 4 个"开源数据丰富 + 专家易联系"的学科。作者强调流程可扩展、计划扩到更多学科/语言。
• 规模适中（102）：小于合成/简单任务的基准，但考虑标注难度和评估成本，作者认为对评估 agent 是合理规模。
• 安全声明（Ethics）：生物信息/计算化学任务聚焦性质预测、特征分析、分子可视化，不涉及合成；agent 不连实验室硬件（不同于 Coscientist），无法自主产出危险物质；输出统一为处理已公开数据的 Python 程序。仍建议开发者认真对待潜在风险、提供干预与反馈机制。

个人思考

与其他论文的关联（放进本项目坐标系）

• 对 [[ref30_paperbench]]（最值得对照的姊妹基准）：两者都"给 agent 真实科研任务、看它走多远"，但切的是不同层次—— | 维度 | ScienceAgentBench (ref33) | PaperBench (ref30) | |---|---|---| | 任务单元 | 科研工作流里的单项任务（一个数据分析/建模/可视化） | 复现整篇 ML 论文的全部实验 | | 任务源 | 44 篇论文的代码示例（抽单个任务） | 20 篇 ICML 论文本体（复现全部贡献） | | 输出 | 一个自包含 Python 程序文件 | 一整个代码仓库 + reproduce.sh | | 评分 | 程序化多维（SR/CBS/VER/Cost）+ GPT-4o 图评 + 人工 rubric | 层级 rubric 树（8316 叶子）+ LLM 评委 + 隔离复现 | | 时程 | agent ~10 分钟出草稿 | 人类专家数天、agent 12 小时 | | 最强成绩 | 34.3%（Claude-3.5 self-debug）| 21.0%（Claude-3.5 BasicAgent）| | 防污染 | 删测试点 + dummy 标签 | 黑名单 + 隔离复现 + 时效性 |

我的判断：ScienceAgentBench 是"广而浅"（跨 4 学科、单项任务、能程序化判分），PaperBench 是"窄而深"（只 ML、整篇复现、必须 rubric+评委）。两者对"科研 agent 能力"是互补坐标：一把测"跨学科单项任务的可用性"，一把测"端到端复现的马拉松"。ScienceAgentBench 的判分更轻、可复现性更强、复现门槛更低（无需 GPU 集群），更适合做快速迭代的开发基准；PaperBench 更适合做能力上限的安全监控标尺。 - 对 [[ref34_core-bench]]（重现 vs 复现 vs 单项任务）：三者构成一条清晰谱系——CORE-Bench 给作者代码只考"跑通重现结果"（计算可重现性）；ScienceAgentBench 给论文里的任务考"从零写单个程序"；PaperBench 只给论文考"从零复现整篇"。难度递增、给的脚手架递减。ScienceAgentBench 卡在中间：比 CORE-Bench 难（要自己写代码），比 PaperBench 易（只做单项任务、有数据集信息和可选知识）。 - 对 [[ref11_scientistone]] / [[ref29_early-science-acceleration-gpt5]] / [[ref28_why-llms-arent-scientists-yet]]：本文是冷静派的旗帜之一。它直接点名反驳 The AI Scientist（ref11 谱系）的"端到端自动化科研"宣称，用"单项任务只解三成"的硬数据给乐观降温；与 ref28"LLM 还不是科学家"是论证同盟；而 ref29 是乐观侧证据。放在一起能构成本项目"AI 做科研到底到哪了"的辩证三角：能加速（ref29）、能产出想法（ref11）、但连单项数据任务都不可靠（ref33）、且缺乏科学家的核心素质（ref28）。 - 对 [[ref09_meta-harness]] / [[ref17_self-harness]]（harness 视角的注脚）：ScienceAgentBench 报告的"agent 分数"其实是"某个 LLM × 某个框架"的联合分数——self-debug vs OpenHands 在同一 Claude-3.5 上差 10.8 个点、成本差 17 倍，且框架效果因模型而异（GPT-4o 独爱 OpenHands）。这正是 Meta-Harness/Self-Harness "harness 非中性、且模型专属"论点的现成证据。反过来想：如果用 Meta-Harness 那样自动搜 harness，这些 32%/34% 很可能被显著抬高——任何科研 agent 基准的分数都应标注 harness/框架，否则跨模型不可比。

方法论启示（可迁移到"造评测"的通用思路）

1. "从真实论文抽任务 + 专家共创验证"是保证生态效度的黄金路径——比 GitHub/Kaggle 二手源更贴近真实工作流，且专家背书能最小化"基准→现实"的泛化 gap。代价是极贵（每任务 2.5–3 小时标注 + 多轮专家/交叉复核），这解释了 102 的规模。
2. 主动防污染 + 防捷径是 benchmark 诚信的底线——"删测试点让自动加载器失效"和"dummy 标签让报答案作弊失效"这两招简单、正交、廉价，任何"用公开数据/代码"的基准都该抄。这是 ScienceAgentBench 区别于绝大多数基准的关键。
3. 多维指标各司其职：SR（严格结果，全或无）+ CBS（宽容相似度，捕捉"接近成功"）+ VER（执行健康度）+ Cost（实用性）——四维一起看才不会被单一指标误导（如 VER 高但 SR 低 = 跑得通但做不对；CBS 高但 SR 低 = 写得像但没做对）。
4. 结果导向指标要配细粒度 rubric 补充——SR 全或无会低估"每步都对只是格式错"的程序；五阶段 rubric（还刻意对评估者隐藏成败结果以给部分学分）是把"部分进度"测出来的好办法。

在我的工作中能怎么用

• 本项目（harness 演化）需要"衡量 agent 科研/数据分析能力"的坐标，ScienceAgentBench 是"跨学科单项任务"这一极，适合和 PaperBench（复现马拉松）、RE-Bench（工程冲刺）、TerminalBench（终端长时程）一起做串讲。
• 它的"防污染两策 + 多维指标 + rubric 补充"协议，可直接启发我们评自己 skill/harness 产出的质量——尤其"删数据点让记忆失效"的思路，对任何担心污染的评测都通用。
• 它是"harness 非中性"最干净的公开证据之一（self-debug vs OpenHands），可作为 Meta-Harness/Self-Harness 叙事的基准侧实证锚点。

开放问题 / 疑问

• 10 分钟执行上限的选择偏差：为评估效率只收 10 分钟内能跑完的任务，系统性地排除了大规模数据/复杂方法的任务——这会不会让基准偏简单、低估真实科研的难度？（作者自己承认这个妥协。）随着模型变强，是否需要一个"重型"版本纳入长执行任务？
• GPT-4o 图评委的可靠性：图表任务的 SR 依赖 GPT-4o judge（采样 3 次取平均），但作者也说它"不完美"；对配色/标签等主观维度，judge 与人类的相关性到底多高、方差多大？这对"可视化任务占 65 个"的基准是不小的隐忧。
• 专家知识"帮倒忙"现象值得深挖：知识提升 SR 却降 VER（引入不熟悉的工具→幻觉 API）——这说明当前 agent"利用领域知识"的能力有结构性缺陷。是 prompt 组织问题，还是模型根本没内化这些专用库？这是一个很好的后续研究点。
• 污染防御的时效性：本文用 2024 及以前的论文/数据，删点+dummy 标签当时有效；但未来模型若在更新的语料上训练、甚至见过本基准本身，这两招还够吗？（这是所有静态基准的共同宿命，PaperBench 也担心同样的事。）

局限性（对基准本身）

• 规模适中（102 任务、4 学科、仅 Python），且因 10 分钟上限偏向较简单任务；创建极贵、难被第三方复制这套"论文抽取 + 专家验证"流程。
• 只测代码生成，不覆盖文献综述/想法生成/实验规划等科研能力。
• 分数与 harness/框架深度耦合（self-debug vs OpenHands 差异巨大），跨模型比较需标注框架、否则不可比。
• 自动评估指标（CBS、GPT-4o 图评）不完美；rubric 目前靠人工、未自动化（作者把"做 rubric-based LLM judge"列为明确的未来方向）。