CORE-Bench: Fostering the Credibility of Published Research Through a Computational Reproducibility Agent Benchmark

一句话总结：Princeton 造的一个"给 AI agent 一篇论文的现成代码+数据仓库，让它把代码装好、跑通、再从输出里读出论文报告的数值结果"的基准——测的是计算可复现性（computational reproducibility）而非从零复现；270 个任务（90 篇论文 × Easy/Medium/Hard 三级），评分是"回答报告数值问题、且落在 3 次人工复现的 95% 预测区间内、全部答对才算过"；最强 agent（CORE-Agent + GPT-4o）在最简单级拿 60%、在最难级只有 21%，暴露"装依赖 + 从多文件里检索对结果"这段的巨大 headroom。

• 来源：Zachary S. Siegel, Sayash Kapoor, Nitya Nadgir, Benedikt Stroebl, Arvind Narayanan（Princeton University），arXiv:2409.11363v2，2024-09-17（v2: 2026-06-22）
• 本地 PDF：ref34_core-bench.pdf
• 代码/数据开源：https://github.com/siegelz/core-bench （含专用评测 harness）
• 数据来源：CodeOcean.com 的可复现 capsule

TL;DR 速览

• 测什么能力：AI agent 的计算可复现性能力——给定一篇已发表论文配套的代码仓库（CodeOcean capsule），agent 要：① 装好库/包/依赖 → ② 确定并运行正确命令把代码跑通 → ③ 在生成的一堆输出文件（终端文本、PDF、HTML、图表）里检索并读出论文报告的具体数值/标签，填进一个 report.json。这是"reproduce（重现，给代码跑通）"而不是"replicate（从零复现，只给论文）"——正好是 [[ref30_paperbench]] 的互补下界。
• 怎么测： 1. 任务：270 个任务 = 90 篇论文 × 3 个难度级（Easy/Medium/Hard）；90 篇横跨计算机科学 / 社会科学 / 医学三大学科，代码为 Python 或 R（是最早纳入 R 任务的基准之一）；含纯语言 / 视觉-语言两类问题。 2. 难度分级 = 给多少复现信息：Easy 直接给"代码已成功运行的完整输出"（只考信息抽取）；Medium 给 Dockerfile + README（考跑 Docker + 抽取）；Hard 只给 README、不给 Dockerfile（考装依赖 + 定命令 + 跑 + 抽取）。 3. 评分：报告 task accuracy——一个任务下所有 task question 都答对才算 1，否则 0；数值答案要落在 3 次人工复现结果的 95% 预测区间内（应对随机性，但 181 题里只有 17 题有随机答案）；每题都保证至少有一个"猜不出来的开放数值问题"防蒙。 4. 防污染/防作弊：源自公共仓库、可周期性更新任务集；每个任务在隔离 VM 里跑（防篡改 benchmark、标准化硬件）；后来还封了 CodeOcean.com 域名防 agent 上网查原仓库。
• 关键成绩与 headroom：
• 最强 = CORE-Agent + GPT-4o：Easy 60.0% / Medium 57.8% / Hard 21.5%（test set，3 次平均）。
• Hard 级 21% 就是全文的招牌数字——"给了现成代码都只能复现两成"，headroom 巨大。
• 任务专用改造收益极大、尤其对弱模型：AutoGPT→CORE-Agent，GPT-4o-mini 在 Easy 从 8.9% 飙到 44.4%；GPT-4o 在 Easy 从 35.6% 到 60.6%。仅用"几天工程 + 加提示 hint + 加 report 格式校验"。
• 文本题 >> 视觉题（Easy 上 GPT-4o：写题 87.9% vs 视觉题 59.3%）；Python >> R（约 66% vs 27%）。
• pass@1 22.2% → pass@3 31.1%（Hard）：多跑几次就能明显提分，说明瓶颈部分是可靠性。
• 一句话评价：这是"AI 能不能自动做科研"链条上最接地气、最可运营的一把尺——它不追求"从零复现"的极限难度，而是卡住"连现成代码都跑不通/读不对"这个更早、更普遍的痛点，且用"隔离 VM 并行 harness + 从公共仓库可持续刷新 + 预测区间判分"把一个原本要 20 天、需研究生级专业知识的人工苦活，压成两小时可自动跑的评测。核心信号与 [[ref30_paperbench]] 惊人一致：agent 会写/会跑一部分，但"把依赖装齐、在多文件里定位对结果"这段是主要失败源。

tags: #benchmark #计算可复现性 #computational-reproducibility #research-agent #AutoGPT #agent-scaffold #长时程agent #LLM工具使用 #data-contamination

related: [[ref30_paperbench]]（姊妹基准：给论文不给代码的"从零复现"，CORE-Bench 是其"给代码只考跑通"的互补下界，PaperBench 正文明确对照本文）· [[ref33_scienceagentbench]]（数据驱动科学发现 agent 基准）· [[ref11_scientistone]]（AI Scientist 谱系：不止复现、还要产出研究）· [[ref09_meta-harness]]（"AutoGPT→CORE-Agent 加提示就大涨、且对弱模型收益更大"正是 harness 与分数深度耦合的活标本）· [[ref17_self-harness]]（Terminal-Bench 谱系的自改进 harness）

摘要

AI agents 有潜力在一系列重要任务上帮助用户，包括开展科学研究。为推动有用 agent 的发展，我们需要有挑战性、且更关键地直接对应真实世界目标任务的基准。本文提出这样一个基准，用来度量 AI agent 在科研中一个至关重要却出人意料地困难的环节——计算可复现性——上的准确率。这个对科研过程至关重要的任务，指的是用作者提供的代码和数据重现一项研究的结果。我们提出 CORE-Bench（Computational Reproducibility Agent Benchmark），一个由 90 篇论文、跨三大学科（计算机、社会科学、医学）、共 270 个任务构成的基准；任务含三个难度级、既有纯语言也有视觉-语言任务。我们提供一套评测系统，能以快速、可并行的方式度量 agent 准确率（相比串行实现每轮省下数天）。我们评了两个基线 agent：通用的 AutoGPT 和为任务定制的 CORE-Agent，各用 GPT-4o / GPT-4o-mini 两个底座。最强 agent 在最难级只达 21% 准确率，显示自动化例行科研任务仍有巨大空间。

1 动机：可复现性危机

论文开篇引了一句经典（Buckheit & Donoho, 1995）："一篇关于计算科学的论文本身不是学术成果，它只是成果的广告；真正的成果是生成那些图表的完整软件环境与完整指令集。" 这句话把全文的立意钉死了——论文只是"广告"，能不能一键跑出图表才是学术的实体。

计算可复现性危机是真实且跨学科的。 作者调查了 15 个学科的证据（Table 1），发现即便论文附带了数据和代码，仍有相当比例的研究无法被计算复现：

[!TIP] 什么是"计算可复现性（computational reproducibility）"？和"复现（replicability）"怎么区分？ 本文用的是 National Academies (2019) 的经典区分，务必分清： - Reproducibility（可复现性 / 计算复现）：用原作者提供的同一份数据 + 代码，能否得到同样的结果。这是"把别人的仓库跑起来出对数字"——CORE-Bench 测的就是这个。 - Replicability（可复制性 / 独立复现）：用新的数据 / 新独立实现，看能否得到一致的结论。这是"换个人从头做一遍"——[[ref30_paperbench]] 测的更接近这一端（只给论文、不给代码）。

一句话对照：CORE-Bench 假设代码已存在、考"能不能跑通并读对"；PaperBench 把代码抽掉、考"能不能从论文写出代码"。 两者是同一光谱上的两个刻度，CORE-Bench 是更早、更普遍、更可运营的那个下界。

为什么"有代码也难复现"？ 论文列了一串真实工程痛点：软件库没锁版本；研究者用了不同机器架构（ARM vs x86）或操作系统（Linux/Windows/MacOS）；旧库和新硬件不兼容；或结果本身有内在方差。ML 也不例外——作者分析 2022 ML 可复现性挑战赛，28 篇带代码+数据的论文里只有 18 篇能完全复现，其中 6/28 即便和原作者沟通了仍无法完全复现。

核心问题："AI agent 能否自动化已发表科研的计算复现？" 作者的逻辑链是：语言模型在 HumanEval 这类基准上已能解大多数题，compound AI systems（agent）又把 SWE-bench 从裸模型的 <5% 抬到 >30%；于是有人喊"很快能自动化大部分科研"。但作者反驳——在 agent 能自动化科研之前，它必须先能复现已有结果（何况做新研究常常还要先复现旧 baseline 做对比）。复现是产出的前置下界。

论文的两大贡献： 1. CORE-Bench：270 任务 / 90 篇 / 三学科 / Python+R / 三难度级 / 语言+视觉，源自 CodeOcean、可周期性更新以缓解污染和饱和。 2. 基线评测 + 专用评测 harness：AutoGPT 与 CORE-Agent 各配 GPT-4o/4o-mini，并开源一套在隔离 VM 上并行跑的评测 harness（把评测从 20+ 天压到两小时）。

2 相关基准

CORE-Bench 的定位可以一句话概括：现有 agent 科研/编程基准要么做"从零 ML 实验/Kaggle 题"，要么做"科学推理/引用"，要么做"真实 GitHub 修 bug"——唯独"用现成仓库自动复现论文结果"这个环节此前没人认真做。

[!TIP] PaperBench（最直接的姊妹对照，务必分清） [[ref30_paperbench]] 让 agent 只拿论文、不拿代码，从零写整个代码库把 20 篇 ICML 论文的实验实现出来、跑通、对上数字，用"与作者共创的 8316 叶子层级 rubric + LLM 评委"打分。它和 CORE-Bench 是同一问题的两个刻度：PaperBench 把"从论文到代码"这段最难的工作留给 agent，CORE-Bench 把代码给足、只考"跑通 + 读对"。PaperBench 正文的相关工作里就明确用 CORE-Bench 做对照，说"CORE-Bench 假设代码已存在、只考执行"。两把尺共享同一个诊断信号——agent 卡在"执行 + 出对结果"，而非"写代码"。

[!TIP] SWE-bench（agent 提升幅度的动机引用） Jimenez et al. (2023) 的 GitHub issue 修复基准。本文引它是为动机：裸语言模型在 SWE-bench 上 <5%，加上 agent scaffold 后 >30%——正是这个"scaffold 让能力跳变"的现象，让作者相信 agent 有望自动化复现，也预告了本文"AutoGPT→CORE-Agent 加提示就从 8.9% 到 44.4%"的核心发现。此外作者显式借鉴了 SWE-bench Verified（Chowdhury 2024）的思路——只收"经验证人类可解"的子集，以保证"高分是可达的"（见 §3 的十条筛选准则）。

[!TIP] AI Scientist（被本文冷静回应的乐观侧） Lu et al. (2024) 的 "The AI Scientist" 端到端自动化 AI 研究（从想法生成到写论文）。本文多次引用它作为"过度乐观"的代表——AI 生成论文的质量已被质疑（Koppel 2024）。CORE-Bench 的态度是：在畅想"完全自动化科研"之前，先量一量"连复现都做不做得到"。这与 [[ref11_scientistone]] / [[ref30_paperbench]] 的"复现是产出的下界"是同一立场。

3 基准设计

这是 benchmark 论文的核心。CORE-Bench 的设计可拆成五块：任务规范 → capsule 来源与筛选 → Easy/Medium/Hard 分级 → 评分协议（预测区间 + 全对才算）→ 隔离 VM harness / 防污染。先看总览图。

Figure 1 逐元素解读（全文骨架图，读懂它就读懂了 CORE-Bench）： - 左上「Task Prompt」：给 agent 的运行指令，例如 "Run 'IAQ-PostCollection-Analysis.R' using Rscript."（用 Rscript 跑这个脚本）。 - 左中「Task Questions」：要 agent 回答的具体问题，例如 "① 从 Experimental IAQ Data 图，报告 y 轴标签；② 从 Indoor Air Quality - Kitchen - Autumn 图，报告 hum 与 gas 的相关系数。" 注意这些是要从复现输出里读出的数值/文字。 - 左下「Code Repository」：给 agent 的仓库文件树（code / data / readme.txt / IAQ-PostColle… / expData.csv / MScDataKit…）——这就是"现成代码+数据"。 - 中间「Virtual Machine + Agent」：agent 在隔离 VM 里装依赖、跑代码。 - 右上「Report」：agent 提交一个 JSON，逐题填答案；系统对照"成功复现的真值"判 ✅/❌——图中第 1 题 "Gas Resistance" 判 ✅、第 2 题 "-0.642" 判 ❌。 - 闭环含义：一次评测 = 读任务 → 在 VM 跑通 → 从输出检索填 report → 对真值判分；且必须每题都对，任务才算成功。

3.1 任务规范：capsule 里有什么

数据源是 CodeOcean capsule——一种自带环境、"已知稍加努力即可复现"的科研代码包（Clyburne-Sherin et al., 2019）。每个 capsule 的结构如下（对应原文 Figure 2）：

关键设计：这些文件（README / Dockerfile / 现成输出）按难度级选择性地提供给 agent——这正是 Easy/Medium/Hard 分级的机制（见 §3.3）。

3.2 capsule 来源与筛选：从 5090 到 90

构造哲学（最重要的方法论张力）：作者点破——"我们要任务真实地难，但要让构造 benchmark 本身远比解 benchmark 容易。" 在野外验证一篇论文的可复现性要花几小时、要领域专家，验一百篇跨领域论文根本不现实。解法就是基于 CodeOcean capsule（本就设计为可复现），把"验证可复现"这件苦活外包给 CodeOcean 平台。

Figure 3 逐元素解读： - 5,090 个初始 capsule（作者写爬虫抓全 CodeOcean 元数据 + 手动导出环境文件）。 - 第一刀按学科：只留 计算机 / 社会科学 / 医学 → 2,536（剔除 2,554 个学科外的）。 - 第二刀按语言：只留 Python / R → 1,657（剔除 879 个非 Python/R 的）。 - 第三刀按十条选择准则（Table 2）→ 最终 90：医学 25、社会科学 28、计算机（先随机抽 355 再筛）37。 - 为什么计算机多？ CodeOcean 上 Python/R 的计算机 capsule 有 1259 个、社科 270、医学 128——社科/医学满足全部准则的太少，只能让计算机偏多。

十条筛选准则（Table 2）——目的是"保证任务清晰、可达高分"，思路同 SWE-bench Verified：

[!NOTE] 低方差准则的一个具体反例（Listing 2/3）：一个被拒的 capsule（826891）——同一份代码两次人工运行，spike probability 一次是 0.423、一次是 0.783，差异巨大。这种高方差 capsule 会让"报告某数值"的判分失去意义，故被排除。这解释了为什么"结果方差低"要作为硬准则。

数据集划分：90 篇按 45 训练 / 45 测试切分（Table A2）；训练集用于开发 agent，正文结果除非注明都在测试集上报。

3.3 难度分级：Easy / Medium / Hard = 给多少复现信息

三个难度级对应"给 agent 多少复现信息"，从而各测一组递增的技能。270 任务 = 90 篇 × 3 级；但181 task question 是三级共用的（同一篇的三级问同样的问题，只是给的信息不同——所以问题数 < 任务数）。

[!TIP] 为什么要做"难度阶梯（ladder of difficulty）"？ 因为一个只报"复现整篇成不成"的全或无指标，在弱 agent 阶段会全 0、没有区分度。三级阶梯把"从零跑通"这个复合任务拆成可分别探针（probe）的能力层：Easy 只探"信息检索/读输出"，Medium 加探"终端 Docker 交互"，Hard 再加"依赖解析 + 命令推断"。即便 agent 完全做不了 Hard，我们仍能从 Easy/Medium 看出它到底卡在哪一环——这与 [[ref30_paperbench]] 的"Code Dev → Execution → Result Match 三类叶子构成部分进度链"是同一设计哲学，只是 CORE-Bench 用"给信息的多少"而非"打分的层级"来切。

3.4 评分协议：回答报告数值问题 + 全对才算 + 预测区间

这是 benchmark 的评分心脏。 主指标是 task accuracy：

[!TIP] 把评分口径讲透 + 数值举例 逐项拆解这套判分为什么这么设计： 1. 为什么"全部答对才算成功"？ 为了防蒙。作者保证每个任务至少有一个"猜不出来的开放数值问题"（如一个连续数值），并要求所有问题都对——这样 agent 无法靠瞎猜某几题拿分。代价是指标严格（一题之差满盘皆输），但这正是"复现"语义所要求的：读错任一个报告值都不算复现成功。 2. 为什么用"95% 预测区间"而不是"精确相等"？ 因为代码输出可能有随机性（不同 seed/硬件）。预测区间给出"未来一次观测预期落入的范围"（Spence & Stanley 2016），比"3 次的置信区间"更宽、更适合判"agent 这一次跑出来的值算不算对"。但注意：181 个 task question 里只有 17 个有随机答案——绝大多数题是确定值，预测区间只对那 17 题起实质作用。 3. 视觉 vs 文本两类问题：视觉题要从图/表/plot/PDF 表格里读属性（如"某图的 x 轴标签""某相关系数");文本题从命令行文本、PDF 文本、HTML/markdown/latex 表格里读。一个任务可以只含视觉题、只含文本题、或两者都有。 4. 具体例子：任务问"报告神经网络第 10 个 epoch 后的测试准确率"（文本题）——agent 跑通代码后从终端输出/日志里找到 epoch 10 ... test_acc: 0.8123，填 0.8123；若这题是确定值就要精确/近似匹配真值，若有随机性则看是否落进 3 次人工复现的 95% 预测区间。再问"从 Indoor Air Quality - Kitchen - Autumn 图报告 hum 与 gas 的相关系数"（视觉题）——agent 得先在多个输出图里定位对那张图，再用 vision 模型读出相关系数 -0.64x。只有两题都对，这个任务才计 1。

问题构造（附录 A.3）：作者在 CodeOcean 上成功复现后，人工检视 results/ 文件夹，从任意结果文件里挑输出（模型准确率、轴标签、任意指标）作为要抽取的目标，再逐个写英文提示。每篇 1–8 个问题，共 90 capsule / 181 问题。图表在问题里的指代方式有三种：按"图表所测量的量"、按"图表标题"、按"文件名/PDF/HTML 里的图表编号"。

Figure 4 逐元素解读（这张图把"任务结构"和"评分机制"两件事一次讲清）： - (a) 任务执行流水线（左）：Task Prompt（Run 'main.py'）+ Provided Task Questions（报告 F1 分数 / 报告 ROC 曲线下 AUC）→ agent 拿到 Set-up（核心文件 REPRODUCING.md / README.md / environment 的 Dockerfile+requirements.txt / code 的 run）、Run Code（feature_selection.py / utils.py …）、Extract Result（把结果填进 JSON 的 "results" 字段，如 F1=0.75）。 - (b) 评估准则（右）：3 个 Manual Run 各给出一组 F1 真值 → 合成 Prediction Interval（如 [0.7040, 0.7092]、[0.6640, 0.6939]）；Agent Run 报出自己的一组 F1（如 [0.90, 0.98]）→ 逐题看是否落进对应区间 → Matching results ✓。 - 关键信息：评分是"agent 报告值 vs 3 次人工复现的预测区间"的逐题匹配、全对才过——图里直观展示了"3 次真值 → 区间 → agent 值落区间"的判定链。

3.5 隔离 VM 评测 harness：20 天 → 2 小时

因为 agent 要在环境里导航/操作/理解，每个任务跑在隔离 VM 里：保证任务间封装、标准化硬件、可并行、防 agent 篡改评测、助力可复现。环境每任务重置到同一起点（对齐 AISI/METR 的做法）。

Figure 5 逐元素解读（这张图是"为什么这个 benchmark 可运营"的关键）： - Manager 机（顶部）存 benchmark 代码 + CORE-Bench 数据集，三步循环： - ① Create VMs：为每个 (task, agent) 对建一台 VM，上传 capsule + agent 代码。 - ② Run agent on each VM：在所有 VM 上并行调用 agent（图中 AutoGPT(gpt-4o) / CORE-Agent(gpt-4o) 各跑一排 Workers，每个 Worker 对应一个 capsule-XXXXXXX）。 - ③ Download & evaluate：agent 一旦写出 task_completed.log（即完成），Manager 就下载结果、删除 VM、在 Manager 本地评分。 - 关键信息：270 任务 + 每任务 2 小时上限，串行要 20+ 天；用这套并行 harness 只需两小时多。且 benchmark 与 agent 代码清晰分离，便于开发新 agent。硬件上非 GPU capsule 用 Standard_E2as_v5、GPU capsule 用 Standard_NC4as_T4_v3（Azure）。

3.6 防污染与防作弊

[!TIP] 什么是数据污染（data contamination）？CORE-Bench 怎么防？ 指评测样本或其答案泄漏进模型训练语料，导致模型不是"真会"而是"背过"，虚高分数、失去测量意义。CORE-Bench 的风险是：这些 CodeOcean 论文和结果都公开在网。 本文的应对： 1. 可周期性更新任务集——benchmark 基于公共仓库，作者可持续加入新 capsule，"缓解污染与饱和的担忧"（这是相对固定基准的一大结构性优势）。 2. 隔离 VM——防 agent 篡改 benchmark、标准化硬件访问。 3. 封锁在线来源——发布版 harness 已限制访问 CodeOcean.com 域名（起因是有 agent 试图上 CodeOcean 网站查缺失依赖）。

安全 guardrail 的现实（§4.7）：一个 agent 曾试图上网找缺失依赖、甚至想在 CodeOcean 注册账号（因网站需 JavaScript 而未得逞）。作者坦言"没有现成机制阻止 agent 犯简单错误（如在某网站创建上千个账号）"，当前只因 agent 无法渲染 JS 才没造成破坏——随 agent 变强需加更多安全检查。

4 评测结果

4.1 主结果：最强 21%（Hard），任务专用改造收益巨大

两个基线 agent： - AutoGPT：几乎未改的通用 AutoGPT，仅加了一个 query_vision_language_model 工具（喂图+问题、返 OpenAI 对图像的回答，因为"能查视觉模型"不是 CORE-Bench 专属才加进 AutoGPT）。 - CORE-Agent：在 AutoGPT 基础上为每个难度级定制——核心改动是加了对 report.json 提交与键名的程序化校验，外加针对每级的提示 hint（治由训练集失败分析发现的常见坑）。作者强调：这套改造只花了几天，最耗时的是分析失败日志找有效提示，且大受益于 AutoGPT 对历史动作的自动摘要。

主结果（Table 5，test set，pass@1，CORE-Agent 取 3 次平均，AutoGPT 因成本只跑 1 次）：

[!IMPORTANT] 两个头条读数： 1. 最强 agent 在 Hard 级只有 21.5%——"给了现成代码、只要装依赖+跑通+读数"都只能复现两成，headroom 极大。这是全文的招牌数字。 2. 通用 agent 稍加任务定制就大涨，且对弱模型收益更大——Easy 级上，GPT-4o-mini 从 AutoGPT 的 8.9% 跳到 CORE-Agent 的 44.4%（≈5×），GPT-4o 从 35.6% 到 60.6%。作者据此假设："未来更强的模型将需要更少的任务专用改造就能表现好。" 这正是 [[ref09_meta-harness]] / [[ref17_self-harness]] 的核心论点在评测端的活标本——harness（scaffold + 提示 + 格式校验）不是中性容器，它和分数深度耦合，且对越弱的模型杠杆越大。

4.2 难度、模型、成本三条曲线

① 准确率随难度递减（如预期）：Easy > Medium > Hard。Medium 若 agent 擅长终端交互本应和 Easy 差不多难；Hard 因为要装全部依赖 + 推断正确命令，显著更难——这解释了从 ~58% 到 ~21% 的断崖。

② 更强模型即便 token 预算更少也更准：两 agent 都设 $4/任务的 API 成本上限。GPT-4o-mini 每 token 成本不到 GPT-4o 的 5%（同样预算能跑更久），但 GPT-4o 仍在两 agent 上都胜出；GPT-4o-mini 驱动的 agent 实际便宜 3–5×。各设定下平均成本 Easy < Medium < Hard。

③ 提高成本上限收益有限（Figure 7）：把 Hard 的上限从 $4 提到 $10，GPT-4o-mini 不变、GPT-4o 仅从 26% 微升到 31%。原因很尖锐——agent 成功时都很快成功（CORE-Agent+GPT-4o 成功任务平均只花 $0.54，失败任务花 $2.59），失败时则常卡住、反复装同一个库直到烧完预算。给更多时间也解不开——"卡住的往往一直卡着"。

4.3 分项：文本 > 视觉，Python >> R

文本题比视觉题容易：Easy 级上 CORE-Agent+GPT-4o 视觉题 59.3% vs 文本题 87.9%；GPT-4o-mini 视觉题 37.8% vs 文本题 81.8%。视觉题难在：要从多个输出图里先定位对那张图（agent 常用错图回答），定位后读图也难。

Figure 8 逐元素解读： - 左（按学科）：CORE-Agent+GPT-4o 在 计算机 ≈57% > 社科 ≈41% > 医学 ≈37%；GPT-4o-mini 各学科都更低（约 27–35%）。误差棒是 3 次试验的 1 个标准差。 - 右（按语言）：Python ≈66% 远高于 R ≈27%（GPT-4o）；GPT-4o-mini 同样 Python(≈44%) >> R(≈18%)。 - 为什么 R 难？ R 输出常更难解析（很多 R capsule 生成整份 PDF 手稿要 agent 通读）；装 R 包的依赖也常比 Python 慢很多。计算机学科不成比例地用 Python，这也解释了它为何最可复现。

4.4 可靠性：pass@k 与 pass∧k

• pass@k（重试能提分）：Hard 上 CORE-Agent+GPT-4o 的 pass@1 = 22.2% → pass@3 = 31.1%；GPT-4o-mini 15.6% → 26.7%。说明"多跑几次取最好"是简单有效的提分手段（呼应 Kapoor 2024、Brown 2024 的 repeated sampling 结论）。
• pass∧k（一致性差）：pass∧k = "连续 k 次全成功"的概率。Hard 上 GPT-4o 的 pass∧1 = 22.2% → pass∧3 = 8.89%——同一批题 agent 无法稳定重复解出。这暴露 agent 的随机性问题：能解的题不一定次次解得出，"让 agent 可靠地解出它本有能力解的题"是个未解难题。

4.5 定性失败模式（agent 到底卡在哪）

作者人工看日志总结（§4.6）： - Easy：输出写在单文件/直接打印到终端时 agent 表现好；输出分散在多文件（多张图）时，agent 难判断哪张图相关，常用错图回答。 - Medium：AutoGPT 常不听指令用 Docker——读了 README 就想手动复现、被冲突指令带偏；CORE-Agent 因任务专用提示基本不犯这错，错误多来自上面的检索问题。 - Hard：除检索问题外，agent 栽在装依赖——常在烧完预算前还没解决版本冲突，卡在反复装同一个库；给更多预算也解不开。

[!IMPORTANT] CORE-Bench 测出的 agent 能力画像：会读单文件输出、会跑简单命令，但"在多文件里定位对结果"和"把一堆依赖装齐跑通"是两大主要失败源。" 这与 [[ref30_paperbench]] 的"Code Dev 35–43% 但 Execution 只有 2–7%"是同一诊断的两种度量**——当前 agent 的短板高度集中在"环境搭建 + 执行 + 精准定位结果"，而非"写代码"本身。

4.6 成本

• 跑 agent：设 $4/任务上限；成功任务平均仅 $0.54，失败任务 $2.59（Hard, GPT-4o）；GPT-4o-mini 驱动便宜 3–5×。
• 评测 harness：270 任务串行 20+ 天 → 并行两小时多。

5 局限与讨论

• 只测"可复现"不测"可复制"：CORE-Bench 明确只测"用现成代码跑出结果"，不测"论文报告的数字本身对不对"、也不测"从零复现"（那是 [[ref30_paperbench]] 的地盘）。因为源自 CodeOcean 的都是可复现论文，作者认为无需纳入不可复现论文。
• CodeOcean 的选择偏差：十条准则（<45 分钟、<10GB、一条 Bash 命令、低方差、有 README/标注）让任务比"野外论文"干净得多——真实世界很多论文并不满足这些。作者坦承这是刻意为之（保证"高分可达"，同 SWE-bench Verified），但也意味着 CORE-Bench 是可复现性的乐观子集。
• 学科不均衡：计算机 37 / 社科 28 / 医学 25，因社科/医学满足全准则的 capsule 稀缺；这可能让"跨学科分布偏移"的结论偏保守。
• agent guardrail 不足：agent 能执行任意网页动作，缺乏防"创建上千账号"这类简单错误的机制；当前只因 agent 无法渲染 JS 才没出事，随能力增强需加安全检查（He et al. 2024）。
• 可靠性差是硬伤：pass∧3 掉到 8.9%——agent 解题极不稳定，"让 agent 稳定解出本有能力解的题"是重要未解问题。
• 成绩受 scaffold 强烈混淆：AutoGPT vs CORE-Agent 差异巨大（Hard 6.7% vs 21.5%），说明报告的"agent 分数"本质是"某 scaffold × 某模型"的联合分数——换更强的 scaffold（如 [[ref09_meta-harness]] 那样自动搜）很可能显著抬高这些数字。

个人思考

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

• 对 [[ref30_paperbench]]（最重要的姊妹关系）：这两篇是"AI 复现科研"光谱的两个刻度，必须成对讲。CORE-Bench = "给代码，考跑通+读对"（可复现性，reproduce）；PaperBench = "只给论文，考从零写代码复现"（可复制性，replicate）。PaperBench 正文明确把 CORE-Bench 当对照。两把尺共享同一惊人诊断——agent 卡在"执行 + 出对结果"而非"写代码"（CORE-Bench 的 Hard 21% + 装依赖失败；PaperBench 的 Execution 仅 2–7%）。做本项目的"agent 科研能力"坐标，这两篇是天然的一对下界/上界。
• 对 [[ref09_meta-harness]] / [[ref17_self-harness]]：CORE-Bench 的 "AutoGPT→CORE-Agent 加提示+格式校验就从 8.9% 涨到 44.4%、且对弱模型杠杆更大" 是这两篇"harness 深度耦合分数、且 scaffold 收益随模型变弱而增大"论点的天然实验证据。反过来，CORE-Bench 报告的分数应标注 scaffold 才可比——若用 Meta-Harness 自动搜 scaffold，21% 这个数字大概率会被推高。这提示：任何 agent benchmark 的分数都是"模型 × harness"的联合量。
• 对 [[ref33_scienceagentbench]] / [[ref11_scientistone]]：ScienceAgentBench 面向数据驱动科学发现、ScientistOne 面向"产出新研究"；CORE-Bench 是这条谱系最保守、最可运营的一端——复现是产出的下界，连给代码都只复现两成，就为"自主科研"的现状划了条清醒的线。

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

1. 把"验证真值"外包给可信平台——CORE-Bench 最聪明的一招是基于 CodeOcean capsule（本就可复现），从而让"构造 benchmark 远比解 benchmark 容易"这个铁律成立。任何要"验证复杂产物"的评测都该想：有没有现成的、已验证的数据源可依托？
2. 难度阶梯 = 给信息的多少——用"给多少复现材料"切 Easy/Medium/Hard，比"给多少分层 rubric"更轻量，且天然对应真实场景的信息完备度。全 0 阶段仍有区分度。
3. "全对才算 + 至少一个开放数值问题"防蒙——比单题准确率更严格，且契合"复现"语义（读错任一值就不算复现）。
4. 预测区间判随机答案——用 3 次人工复现构 95% 预测区间，是处理"输出有随机性"的干净做法（虽然本文只有 17/181 题用得上）。
5. 可周期性更新的公共数据源 = 抗污染/抗饱和——相比固定 benchmark 的结构性优势，值得任何长期 benchmark 借鉴。

在我的工作中能怎么用

• 本项目（harness 演化）需要一个"衡量 agent 科研/工程能力"的坐标，CORE-Bench 是"给代码考跑通"的一极，适合和 PaperBench（从零复现）、RE-Bench（自包含研究工程）、TerminalBench（终端长时程）一起做串讲，形成"复现难度光谱"。
• 它的 "AutoGPT→CORE-Agent 几天改造大涨" 是论证 "scaffold/harness 值得被自动优化" 的绝佳实证锚点，可直接引到 Meta-Harness 的串讲里。

开放问题 / 疑问

• CodeOcean 选择偏差有多大？ 十条准则把任务筛得很干净，真实世界可复现率恐怕远低于 CORE-Bench 的乐观子集——21% 在"野外论文"上会是多少？
• 分数被 scaffold 严重混淆：21%（CORE-Agent+GPT-4o+BasicAgent 式）到底是"模型能力"还是"这个 scaffold 能力"？作者自己也承认任务专用改造的巨大影响。更公平的报告或许该给"每模型 × 其最优 scaffold"。
• 可靠性（pass∧k）为何这么差？ 同批题无法稳定重复解——是采样随机性、还是环境交互的脆弱性主导？这对"跨模型比较"的稳健性是隐忧。
• 视觉题瓶颈：59% 视觉 vs 88% 文本的差距，多少来自"定位错图"、多少来自"读图能力"？随 vision 模型变强这个 gap 会不会自然消失？

局限性（对基准本身）

• 只测"可复现"不测"可复制"，是 PaperBench 的严格下界；单看它会低估"从零复现"的真实难度。
• CodeOcean 筛选让任务成为可复现性的乐观子集，学科分布偏计算机/Python。
• 分数与 scaffold/prompt 深度耦合，跨模型/跨 agent 比较需极其小心。
• 底座是 2024 年的 GPT-4o/4o-mini + AutoGPT，绝对分数会随模型迭代很快过时（但相对结论——难度阶梯、Python>>R、执行/依赖是瓶颈——大概率长期成立）。