FrontierCS 2：面向计算机科学研发的基准

核心问题：LLM 智能体能否在真实代码仓库中做出超越论文作者原始代码的计算机科学研发贡献？

• 场景与动机：作者认为大量 CS 研发的形态是：研究者接手一个已发表系统，在其代码库上改进一个组件，并在论文报告的工作负载上与原作者实现比较。作者想测智能体能否完成同样的工作。
• 现有基准的不足（按论文说法）：FrontierCS、ALE-Bench、AtCoder 等开放式基准只给问题陈述、让智能体写一个程序、运行结束后评一次分；SWE-bench、MLE-bench 等环境类基准则按测试或排行榜评分，ResearchGym、MLS-Bench、PaperBench 等局限于机器学习领域，或按 rubric、复现实现而非作者原代码评分。
• 核心设计：取论文作者发布的代码，删除论文的贡献部分，被删除的代码成为人类参考（human reference），在论文自己的工作负载上测量后作为通过门槛；智能体在仓库内像研究者一样工作，可随时提交补丁并获得开发套件分数。
• 论文产出：48 个任务、覆盖 13 个 CS 领域的基准 FrontierCS 2，外加一个评审（judge）机制、FCI/FDI 能力—难度标度，以及 12 个智能体的评测和三个案例研究；另有 100 多个私有任务待公布。
• 评测对象设定：被测对象是"模型 + harness（智能体框架）"的组合，论文按模型命名智能体，但说明 harness 也是被测对象的一部分；每个智能体每个任务跑一次，五小时时限。

开放式编程基准

• FrontierCS、ALE-Bench、AtCoder 启发式竞赛——无已知最优解、按目标函数给程序打分；论文指出这些基准上智能体仍低于顶尖人类专家，且共同设计是"给问题陈述、写一个程序、结束后评一次分"。
• LiveCodeBench Pro、HeuriGym、NP-Engine、KernelBench——分别覆盖有已知解的竞赛题、组合优化启发式、可验证 NP 问题和 GPU kernel，作为同类工作被提及。
• nanoGPT speedrun、InferenceBench——加速类基准从代码库出发、对固定基线（人类 speedrun 记录或朴素 PyTorch 推理服务器）测量；论文指出 FrontierCS 2 改为对作者发布的人类参考代码评分，并在运行中为每个补丁打分。

研究与工程类智能体基准

• SWE-bench、Terminal-Bench、MLE-bench、RE-Bench——分别用 held-out 测试、Kaggle 排行榜和同时间预算的人类专家评分；PostTrainBench 测后训练模型的下游分数，DeployBench 检查研究构件能否跑通指定实验，EdgeBench 也在运行中给反馈。
• PaperBench、AIRS-Bench、ResearchGym、RSI-Forge、Into the Unknown、ReuF2F——覆盖论文复现、ML 研究、多领域论文任务等；论文指出这些基准都不用原作者代码做标准。
• MLS-Bench——论文称设计最接近：140 个 ML 任务、12 个方向，各要求改进一个指定组件；本文把该设计扩展到 ML 之外的 13 个 CS 领域。

从已有构件构建任务

• SWE-smith、FrontierSmith、BenchEvolver、DiscoGen——分别通过注入 bug、变异竞赛题、演化已解题、程序化生成来规模化造题。
• ResearchGym——同样从仓库中移除论文方法；论文指出区别是本文的 oracle 是被移除的代码本身，且任务跨 13 个领域。

定位：作者称本文与这些工作的区别在于：在论文自己的仓库里、以作者发布的代码为门槛、跨整个计算机科学评测，并在运行中给每个补丁反馈。

整体思路：以"做减法"的方式从论文作者发布的代码构建任务，把删除的代码作为人类参考门槛，让智能体在真实仓库中工作并由一个信息隔离的 judge 评分。框架名为 FrontierCS 2。

任务构建（Section 3）

• 做减法：定位实现论文贡献的代码并删除，其余依赖保持不变；被删函数仍被声明和调用，智能体只能编辑原贡献所在的文件。人类参考是一个恢复被删代码的私有补丁。
• 通过阈值：每个指标的阈值由参考代码在论文报告的工作负载上的测量值设定。以 SVG-EAR 为例：延迟不超过参考的 0.96 倍，PSNR 与参考相差不超过 0.25 dB，SSIM 不超过 0.01，LPIPS 不超过 0.005。
• 开发套件与最终套件：judge 在开发套件上给每次提交打分；只有最终提交在最终套件上评分，最终套件加入智能体从未见过的 held-out 实例（不同种子、查询或输入图）。
• 规模：48 个任务、13 个领域（Database 9、Machine Learning 9、MLSys 6、HPC 4、Programming Languages 4、Architecture 3、Network 3、Cryptography 3、Robotics 2、Security 2、Bioinformatics 1、Software Engineering 1、Theory 1，Figure 1）；Structured LWE 是唯一非论文代码构建的原创密码分析任务（附录 A）。

Judge 与信息隔离（Section 4）

• 信息划分：智能体持有仓库；judge 持有评测器、held-out 最终套件和人类参考。智能体有五小时，可随时提交补丁；judge 返回开发套件分数和一条消息，只告知各指标阈值在多少开发工作负载上达标，不给参考分数和评测器原始输出。
• 沙箱隔离：双方各自运行在独立沙箱，仅由本次运行启动的 driver 连接；智能体沙箱除 driver 外无网络，无法下载作者代码。GPU 任务中智能体可经 driver 申请开发 GPU，只有 judge 使用与参考对比测量的 GPU；部分任务（如 Continuum）judge 还有测试沙箱。
• 通过判定：开发套件分数不计入结果；运行结束时智能体指定一个补丁为最终提交，judge 只在 held-out 套件上评这个补丁。最终提交在每个指标、每个 held-out 工作负载上都达到阈值才算 pass；judge 另按各任务自己的标度给 0–100 的最终分，无最终提交记 0 分。

FCI 与 FDI（Section 5.2、附录 D）

• 联合拟合：FCI 改编自 Epoch AI 的 Epoch Capabilities Index（项目反应模型），对每次运行取两个观测——在任务哪些指标组上超过参考、最终分相对参考的边际 y_at = (s_at − s^ref_t)/c_t（最终分与参考分之差按任务单位归一化），两者共享一个运行效应。
• 标度：每个智能体一个强度值，FCI = 10 ×（强度 − Kimi K2.7 的强度），即每 logit 10 分、Kimi K2.7 锚定在 0；任务的 FDI 是使其通过概率为 1/2 的 FCI。区间为重抽样任务的 90% bootstrap 区间（500 次抽样）。
• 拟合规模：624 次运行（含未公开报告的锚点智能体 Kimi K2.7）、115 个指标组、48 个任务的 tie level，共 163 个任务参数（附录 D）。

测试时扩展（Section 5.3）

• 预算下的 FCI：固定任务参数，预算 B 内完成的运行保留 held-out 结果，到 B 仍在运行的记为无最终提交（0 分），重新拟合各智能体强度；运行结果随 B 只能改善，曲线不下降。

实验设置

• 被测智能体：12 个模型各配一个 harness——Claude Opus 5.5（Claude Code）、GPT-6 Astra（Codex CLI）、GPT-6.1 Sol（Codex CLI）、Gemini 4 Argon（Pi）、GLM 5.3（ZCode）、Muse Wonder 1.0（Muse Code）、DeepSeek V4.1 Flash（DeepSeek Harness）、Kimi K3（Kimi Code）、GLM 5.3 Flash（ZCode）、Muse Spark 1.3（Muse Code）、Qwen 3.8 Max（Qwen Code）、Step 5 Preview（Step Code）；另有 Kimi K2.7（Kimi Code）仅作 FCI 零点、不公开报告（Table 4）。
• 任务与运行：48 个任务，每个智能体每任务跑一次，五小时时限；Gemini 4 Argon 有两次运行被服务商拒绝，按失败计入。
• 指标：主指标 pass rate（通过运行占比）；另报告 mean score（最终分减参考分的均值，0 为持平）、FCI/FDI；Figure 5 给出每次运行平均成本。
• 判定方式：judge 按各任务阈值在 held-out 最终套件上判定，非 LLM 评审；每个指标、每个 held-out 工作负载都达标才算 pass。
• 重复次数：每任务一次运行，论文未报告重复实验。

主结果

表格较宽，可左右滑动

智能体	Pass rate（Figure 2）	FCI（Figure 7）	平均最终分边际（Figure 6）
Claude Opus 5.5	58	55.7	+9.4
GPT-6 Astra	44	50.7	+7.1
Gemini 4 Argon	40	39.5	+2.1
GPT-6.1 Sol	35	42.6	+5.7
GLM 5.3	25	36.6	+1.8
Kimi K3	21	26.4	−1.2
Muse Wonder 1.0	21	34.5	+4.1
DeepSeek V4.1 Flash	15	30.7	+0.5
Muse Spark 1.3	12	22.1	−3.3
Qwen 3.8 Max	12	21.9	−6.4
GLM 5.3 Flash	12	22.9	−8.4
Step 5 Preview	8	9.8	−10.6

• 整体格局：作者称 Claude Opus 5.5 领先，其余智能体通过率均低于 50%；16 个任务没有任何运行通过。
• 分数不等于通过：作者报告多数最终分超过参考的运行仍在至少一个指标或工作负载上不达标；也有通过的运行最终分持平或低于参考。
• FCI 排序：FCI 与 pass rate 排序几乎一致；任务难度跨度大于智能体能力跨度，任务难度中位数约等于最强智能体的 FCI；作者说明单个任务的 FDI 不确定性大，不对任务逐个排序。

测试时扩展（Section 5.3）

• 领先者随预算变化：最小预算下 DeepSeek V4.1 Flash 领先，最大预算下 Claude Opus 5.5 领先（Figure 8）。
• 成本口径：作者注明 DeepSeek V4.1 Flash 的成本是下界，其领先取决于 token 定价方式。

案例研究（Section 6）

• QuarterPIR：多数智能体通过；Muse Wonder 1.0 用两个校验和把 6700 万条目数据库的每次查询字节数从参考的 1,760 降到 1,280，其他通过运行最少为 1,664（Figure 9）；作者称 pass 和最终分都区分不出这一改进幅度，GPT-6.1 Sol 节省少得多却得分略高。
• BBQ：仅 Claude Opus 5.5、Gemini 4 Argon、GPT-6.1 Sol 通过；Claude Opus 5.5 时钟周期最短但查找表用量在通过电路中最大，且不支持 BBQ 原设计的更大规模（Figure 10）；作者称最终分奖励速度、忽略电路面积，把它排第一。
• SVG-EAR：无运行通过；GPT-6 Astra 最接近，每个 clip 都比参考快、平均 PSNR 23.8 dB 高于参考的 21.7 dB，仍在两个 clip 的图像质量上失败（Figure 11）；作者称多数运行在时间上达标，瓶颈在图像质量区间。

其他消融与分析

• 成本—通过率：Figure 5 显示 GPT-6.1 Sol 通过率低于 GPT-6 Astra 且每次运行成本低得多。
• FCI 区间：Figure 7 的 90% bootstrap 区间只能分开能力差距大的智能体。
• FDI 与通过率：作者报告 FDI 跨任务与通过率走势接近。

作者指出的局限与后续方向

• 附带成本未计入：Conclusion 指出 BBQ 上最终分把电路最大的通过方案排第一，因为它忽略电路面积；作者认为这类基准需要在 pass 之外报告此类附带成本。
• 改进幅度不可见：Conclusion 指出 QuarterPIR 上 pass 和最终分都无法把大幅压缩字节数的运行与其他通过运行区分开。
• 指标可能遗漏好想法：Section 6.1 指出该校验和想法只有人工阅读补丁才发现，两个度量都没有把它挑出来。
• 任务 FDI 不确定性：Section 5.2 指出单个任务的 FDI 不确定，因此不对任务逐个排序。
• 私有任务集待公布：摘要与 Conclusion 称还有 100 多个私有任务，作者计划未来公布。

实验覆盖范围

• 被测智能体：12 个公开报告的智能体（模型 + harness 组合），另有 Kimi K2.7 仅作 FCI 零点（Section 5.1、Table 4）。
• 任务规模：48 个公开任务、13 个领域；每智能体每任务一次运行，共 624 次运行进入 FCI 拟合（含 Kimi K2.7，附录 D）。
• 运行协议：五小时时限，开发套件提交次数按任务设上限（3–100 次，Table 3）；论文未报告同一智能体同一任务的重复运行。
• 成本数据：Figure 5 给出各智能体每次运行平均成本；DeepSeek V4.1 Flash 的成本为下界（Section 5.3）。
• 区间估计：FCI 报告 90% bootstrap 区间（500 次重抽样），FDI 区间用 2,000 次加权抽样（附录 D）。

FrontierCS 2 是一个计算机科学研发基准，问的是：LLM 智能体能否在论文自己的代码仓库里做出超越作者原始代码的贡献。

• 问题：既有开放式基准只给问题陈述、跑一次程序评分，环境类基准又局限于 ML 或按 rubric 评分，都不用作者原代码做标准。
• 方法：删除论文贡献的代码作为人类参考，智能体在五小时内随时提交补丁、获得开发套件分数；judge 私有持有评测器、held-out 最终套件和参考，最终提交须在每个指标、每个 held-out 工作负载上都达标才算 pass。48 个任务覆盖 13 个领域。
• 主结果：12 个智能体各跑一遍，Claude Opus 5.5 通过率 58% 最高，其余均低于 50%；16 个任务无运行通过（Figure 2）。
• 分数与通过脱钩：多数最终分超过参考的运行仍因某个指标或工作负载不达标而失败（Section 5.1）。
• 能力标度：FCI 上 Claude Opus 5.5 为 55.7、Step 5 Preview 为 9.8；任务难度中位数约等于最强智能体的 FCI（Figure 7）。
• 作者结论：案例研究显示 pass 和最终分会遗漏附带成本（电路面积）和改进幅度（字节压缩），作者认为此类基准应报告附带成本，并推荐用 FCI/FDI 这类带区间的标度；另有 100 多个私有任务计划未来公布。