Cognition 发布 FrontierCode 2.0 编程基准：Opus 5.5 仅得 45%

FrontierCode 排行榜：依据生产代码标准评估模型立即查看 →

AI 的近期进展让软件工程师的生产力大幅提升。然而，我们在构建和部署 Devin 的过程中发现，智能体式软件工程仍远未解决。模型难以推断用户意图、遵守未明说的约束，也难以预见其改动带来的长期后果，从而不得不依赖人工介入。

现有的大多数编程基准无法捕捉这些差距，且往往很快饱和。我们很高兴推出 FrontierCode 2.0，这是我们编程基准系列的新一代版本，也是我们迄今为止评估用户体验的最佳尝试。

在 FrontierCode 1.0 中，顶尖开源维护者制定了严格的标准来衡量代码可合并性。FrontierCode 2.0 在此方法论基础上做出了若干关键改进：

1.更广的覆盖范围：任务取自更多仓库，涵盖更多类别，包括安全补丁和性能优化，以更好地反映编程工作的真实分布。

2.更高的可合并性标准：评分标准对正确性和设计提出了更广泛的要求，并进一步强调周全性。

3.更大的任务范围：与 FrontierCode 1.1 相比，参考解决方案平均修改的文件多 67%、代码行多 89%，而代码库规模大 25%。

得分是各评分项按权重汇总的结果。未通过阻断性标准的解决方案得 0 分。

成本为按 API 标价（含公开折扣）计算的每次运行平均美元支出。

帕累托前沿在高成本端包括 Opus 5.5，在低成本端包括 Luna、Haiku 和 Sol，其中 GPT-6.1 Sol 相对其成本表现出尤其强劲的性能。我们的结果还表明，开源模型仍有显著提升空间，西方开源模型更是如此。

FrontierCode 1.1 与 FrontierCode 2.0 对比

类别FrontierCode 1.1FrontierCode 2.0变化

DeepSeek V4.1 Flash43.9%19.3%

Kimi K344.2%17.7%

与 DeepSWE v1.1 和 FrontierCode 1.1 等基准相比，FrontierCode 2.0 能更清晰地区分不同能力层级的模型。该基准远未饱和：表现最好的模型 Opus 5.5 也仅得 45%。

FrontierCode 衡量什么#

模型已非常擅长遵循详尽、细致的问题规格说明。事实上，这正是大多数编程基准所考察的内容。例如，请看 Terminal-Bench 4.0 中 vf2-speedup-networkx 的以下片段。

提示词

构建 fast_networkx，它是 NetworkX 中专注于 VF2++ 图同构的子集的更快直接替代品。import fast_networkx as fnx 必须能在 /app 下正常工作。……节点键可以是任意可哈希的 Python 对象。保留 Python 相等语义，包括 1 == True 这类情况。

你不需要 MultiGraph、MultiDiGraph、图生成器、I/O、绘图，也不需要 VF2++ 以外的算法。

隐藏验证器有两道关卡。正确性关卡在有向图和无向图、标签、映射有效性、全同构枚举、自环、孤立节点、空图以及混合节点类型上，将 fnx 直接与 NetworkX 3.4.2 对比。速度关卡对隐藏的固定种子随机 5-正则图对（300 个节点）计时 vf2pp_is_isomorphic。各用例加速比的几何平均值必须至少比 NetworkX 快 5000 倍。

该任务完整规定了智能体应采用的方法和风格，而不要求从环境中做任何推断。

虽然 Terminal-Bench 4.0 是隔离纯模型智能的优秀基准，我们也尝试捕捉模型能力的其他组成部分。随着模型变得更强，用户越来越希望它们能自主工作。理想情况下，编程智能体应能接收非正式规格说明，找到既满足该规格、又满足其隐含约束和偏好的行动方案，顾及用户的盲点，并在无需反复纠正或澄清的情况下执行。

在典型的工程场景中会出现哪些未明说的约束和偏好？常见的例子包括复用现有抽象、遵循仓库约定，以及编写能真正捕获缺陷的非平凡测试。这些对于确保代码长期可维护、用户可理解至关重要。

考虑到这些及其他因素，FrontierCode 试图衡量以下方面：

功能正确性

解读并扩展用户的初始提示词

为实现并与现有代码库顺畅集成而做出合理的设计与范围选择

我们如何构建 FrontierCode 2.0

FrontierCode 2.0 基本保留了 FrontierCode 1.0 的方法论。20 多位世界级开源开发者每人针对每个任务花费 40 多小时，基于他们维护的仓库构建贴近真实的编程评测。我们的目标是衡量模型作为真正独立贡献者的表现，使用经过精心校准的评分标准来检验智能体的输出是否真正可合并。有关我们的评分方法和质量控制的更多信息，请参阅我们的 FrontierCode 1.0 博客文章。

如上所述，FrontierCode 2.0 主要在任务多样性、评分标准和任务范围方面对 FrontierCode 1.0 进行了改进。具体而言：

我们的任务取自多出 55% 的代码仓库，以更好地反映真实编程工作的分布。

任务包含多出 43% 的阻断性标准，这些标准以更高的精确度捕捉正确性和设计要求。

任务往往需要对代码库进行更大规模的修改。

我们还通过更严格地审核任务提示词、参考解和评分标准来加强质量控制。这种在人工和自动审查上的投入，经常能发现取自上游仓库的参考解中细微的边界情况。在 FrontierCode 2.0 的 80% 任务中，参考解与上游 PR 不同，而 FrontierCode 1.0 中这一比例为 60%。随着 FrontierCode 扩展到与安全相关的任务，这种额外的细致更为重要，因为漏洞利用往往取决于微小的细节。在我们的一条自动审核流水线中，一个智能体发现了上游实现中的一个安全漏洞；经人工审查后，我们将其报告给了仓库维护者。

评估全面性

在对评分标准进行分类时，我们识别出了一个“全面性”类别。全面性标准所强制的正确性条件，是智能体能够从指令和现有代码库中推断出来的，即使这些条件并未被明确说明。它们对于 FrontierCode 2.0 在提示词不完整的情况下评估智能体的能力至关重要，因为它们能捕捉到那些表面上回应了提示词、却留下或引入了重大功能缺陷的解决方案。

全面性标准的示例包括：

修复某个缺陷的每一处实例。提示词指出了某条代码路径中的一个缺陷，但同一缺陷也存在于一条同级路径中。一个全面的智能体会找到并修复这两处。

匹配现有支持。提示词要求实现新功能，并提到了一种输入类型。一个全面的智能体会注意到类似的代码还处理了其他输入类型，并同样支持它们。

按类别划分的阻断项

类别FrontierCode 1.1FrontierCode 2.0变化

全面性168501

核心行为399353

避免回归174259

有效测试编写202213

Lint / 格式 / 类型检查112183

范围56123

向后兼容性8576

FrontierCode 1.1 和 2.0 的评分标准类型分布。

在 FrontierCode 2.0 的所有阻断性标准中，全面性所占的比重大幅增加，其总数相比 FrontierCode 1.1 增长了 3 倍。

按类别划分的阻断项失败率

类别FrontierCode 1.1FrontierCode 2.0变化

全面性11.7%19.2%

核心行为9.5%14.9%

向后兼容性2.9%5.9%

范围9.0%3.8%

避免回归1.3%3.3%

测试完整性3.4%2.5%

有效测试编写2.8%1.6%

编译0.7%1.2%

Lint / 格式 / 类型检查1.7%1.0%

推理努力程度如何影响性能

FrontierCode 是少数几个编写更多（正确）代码未必能提高模型得分的编程基准之一。这导致了一个有趣的现象：模型在更高的推理努力程度下得分反而可能更低。由于这种非单调性往往与用户感受相符，却在其他评测中难以观察到，我们认为这是该基准的一个有用特性。

然而，这种评分方法导致 FrontierCode 1.1 上随着努力程度提高，模型表现呈现出有些难以解读的锯齿状波动：

FrontierCode 1.1 主要指标vs成本（美元）

得分是各评分项按权重汇总的结果。未通过阻断性标准的解决方案得 0 分。

成本是每次运行的平均美元花费。

正如我们此前所讨论的，造成这一现象的一个主要因素是范围阻断项的存在。大多数标准的通过率随模型努力程度提高而上升，但范围标准的通过率却下降：

实现类标准

范围类标准

按推理努力程度划分的评分项通过率

类别低努力最高努力变化

实现类标准：Claude Opus 579.3%83.0%

实现类标准：Claude Opus 4.875.5%79.2%

实现类标准：Claude Fable 579.2%81.8%

实现类标准：GPT-5.6 Sol68.6%73.0%

范围类标准：Claude Opus 569.2%51.1%

范围类标准：Claude Opus 4.881.9%70.9%

范围类标准：Claude Fable 579.1%63.4%

范围类标准：GPT-5.6 Sol79.7%68.3%

换言之，随着努力程度提高，模型倾向于编写更多代码、触及更多文件，即使这些改动未必更可取。将这些曲线的影响叠加起来，就可能产生形状奇特的得分曲线。较小的促成因素包括在更高努力程度下更频繁的作弊（模型倾向于“意外地”拉取解决方案提交）以及彻底的过度思考，即模型说服自己实现了对所需改动的一种误读。

在 FrontierCode 1.0 中使用范围阻断项曾有些争议。对违反范围标准的改动的另一种解读是，模型可能以整体上改进代码的方式超出了提示词的要求。经调查，我们确实看到了一些出人意料地合理、却未能通过范围阻断项的解决方案。

在 FrontierCode 2.0 中，我们放宽了范围标准，以容纳出人意料但可以接受的行为。模型现在更不容易违反任何给定的范围标准：按努力程度平均，FrontierCode 2.0 的失败率为 3.8%，而 FrontierCode 1.1 为 9.0%。结合我们改进后的审计，我们确信我们的努力-性能曲线衡量的是更高推理努力下的真实性能退化。

各类别中未通过的阻断项检查占该类别全部阻断项检查的百分比。

按类别和努力程度划分的阻断项失败率

类别低努力最高努力变化

彻底性26.0%15.3%

核心行为20.9%12.3%

向后兼容性9.7%5.2%

范围3.8%4.9%

避免回归4.4%2.2%

测试完整性3.0%1.9%

有效编写测试3.9%1.3%

编译2.3%0.7%

Lint / 格式 / 类型检查1.3%0.5%

FrontierCode 2.0 上按类别和推理努力程度划分的阻断项失败率。每条线显示某一类别中未通过的阻断项检查所占比例。彻底性在每个努力程度上都具有最高的失败率，高于核心行为。结果汇总了四个模型（Claude Opus 5.5、Claude Fable 5.1、GPT-6.1 Sol 和 GPT-6 Astra）。

任务示例

为了说明 FrontierCode 2.0 的任务设计和评分标准，我们在下面介绍几个示例任务。

Claude Opus 5.5低：0/5 次运行通过✕低中：0/5 次运行通过✕中高：0/5 次运行通过✕高极高：0/5 次运行通过✕极高最高：0/5 次运行通过✕最高

Claude Opus 5.5（最高努力）修复 Mock Service Worker 中一个已报告的 bug：resetHandlers() 不会重启生成器解析器。任务：msw-fix-reset-generator-state0/109滚动以查看智能体工作……

Claude Opus 5.5（最高努力）在此任务上的表现。扫描器会播放完整运行过程，并在被标记的编辑处放慢速度。

此任务来自开源 Mock Service Worker 仓库，这是一个广泛使用的 JavaScript 网络请求模拟库。它要求模型修复用户报告的一个 bug：resetHandlers() 不会重启生成器。

在此任务上，Claude Opus 5.5 在重置时丢弃了对旧生成器的引用，因此下一个请求会从头开始一个新的生成器。这修复了所报告的 bug。但仅仅丢弃引用意味着旧生成器永远不会被关闭，因此用户在 finally 块中编写的任何清理代码都不会运行。

jsx

function* () { try { yield 'first' return 'rest' } finally { cleanup() // 重置后永远不会运行 } }

跳过用户的清理代码可能导致资源泄漏或使应用程序处于不一致状态。该任务并未明确要求模型处理清理，但经验丰富的 JavaScript 开发者期望一个丢弃生成器的库会关闭它，以便其 finally 块运行，而 Opus 5.5 的解决方案未能满足这一隐含的正确性期望。FrontierCode 2.0 中的此类任务表明，模型往往无法推断出直接指定内容之外的用户意图，从而导致它们引入违反未明说但可明确推断的约束的 bug。

GPT-6 Astra低：5/5 次运行通过低中：2/5 次运行通过✕中高：1/5 次运行通过✕高极高：2/5 次运行通过✕极高最高：1/5 次运行通过✕最高

此任务来自 PostHog 的开源 Android SDK，应用使用它来记录分析事件。当设备离线时，SDK 会将事件写入磁盘，并在应用下次启动时发送它们。任务是修复一个启动 bug，其中两个模块同时发送数据：实时队列发送新事件，而旧版集成 PostHogSendCachedEventsIntegration.kt 发送缓存的事件。两者发生竞争，导致事件到达服务器的顺序错乱。

在低努力下，GPT-6 Astra 将缓存加载移入 PostHogQueue.kt，从旧版集成中移除发送逻辑，并保持 SDK 的公共 API 不变，从而产生了一个通过的解决方案。

在最高努力下，模型经常直接删除 PostHogSendCachedEventsIntegration.kt，并将其职责分散到其他旧版文件中。这也修复了竞争并通过了大多数隐藏行为测试。但被删除的类是 SDK 公共 posthog.api 接口的一部分，因此移除它会为每个引用它的应用引入不必要的破坏性变更。范围阻断项会确定性地检查模型是否修改了某些文件，从而捕获此变更，智能体因此未能通过该任务。

精简（通过）GPT-6 Astra，低努力重写（失败）GPT-6 Astra，高努力

✕ 在任务范围阻断项允许的路径之外。点击文件以查看双方的变更。

* pod lead