FrontierCode 2.0（阅读约 13 分钟）

# FrontierCode 2.0 来源：https://cognition.com/blog/frontier-code-2.0 作者：The Cognition Team，2026.10.27 FrontierCode 排行榜——按照生产级代码标准评测模型 立即查看（https://cognition.com/frontiercode） 近年来 AI 的飞速进步让软件工程师的生产力大幅提升。然而，我们在构建和部署 Devin 的过程中发现，智能体驱动的软件工程仍然远未被解决。模型难以推断用户意图、尊重未明确说明的约束、预判其改动的长期影响，因此仍需要人工介入。 现有的大多数编码基准测试无法捕捉这些差距，而且往往很快就被刷满。我们很高兴地介绍 **FrontierCode 2.0**——这是我们编码基准测试系列的最新一代，也是我们迄今对用户体验评测的最佳尝试。 在 FrontierCode 1.0 中，顶尖开源维护者制定了严格的评分标准来衡量代码的可合并性。FrontierCode 2.0 在此基础上进行了几项关键改进： 1. **更广泛的覆盖范围**：任务取自更多仓库，涵盖更多类别，包括安全补丁和性能优化，以更好地反映编码工作的真实分布。 2. **更高的可合并性标准**：评分标准施加了更全面的正确性和设计要求，并更加注重彻底性。 3. **更大的任务范围**：与 FrontierCode 1.1 相比，参考解决方案平均修改的文件数多 67%，修改的代码行数多 89%，且所处代码库大 25%。 ## 结果（https://cognition.com/blog/frontier-code-2.0#results） #### FrontierCode 2.0 #### FrontierCode 2.0 对比成本（$） **得分**是评分项的加权综合。未通过阻断性标准的解决方案得 0 分。 **成本**是按标准 API 定价（含公开折扣）计算的每次 rollout 的平均美元花费。 帕累托前沿包括高端的 Opus 5.5，以及低成本端的 Luna、Haiku 和 Sol，其中 GPT-6.1 Sol 相对于其成本表现出色。我们的结果也凸显了开源模型的巨大提升空间，西方开源模型的差距尤为明显。 #### FrontierCode 1.1 对比 FrontierCode 2.0 | 类别 | FrontierCode 1.1 | FrontierCode 2.0 | 变化 | |---|---|---|---| | Claude Opus 5.5 | 54.6% | 45.5% | | | GPT-6 Astra | 53.3% | 42.8% | | | Grok 4.7 | 47.6% | 28.6% | | | Gemini 4 Argon | 47.5% | 26.3% | | | Muse Wonder 1.0 | 47.0% | 24.3% | | | SWE-2 | 50.0% | 23.9% | | | DeepSeek V4.1 Flash | 43.9% | 19.3% | | | Kimi K3 | 44.2% | 17.7% | | 与 DeepSWE v1.1 和 FrontierCode 1.1 等基准测试相比，FrontierCode 2.0 能更清晰地区分不同能力层级的模型。该基准远未被刷满：表现最好的模型 Opus 5.5 仅得 45%。 ## FrontierCode 评测的内容（https://cognition.com/blog/frontier-code-2.0#what-frontiercode-measures） 模型已经非常擅长遵循详尽、精细的问题规格说明。事实上，这正是大多数编码基准测试所考察的内容。例如，以下是 Terminal-Bench 4.0 中 `vf2-speedup-networkx` 任务的节选： ``` 构建 fast_networkx，一个专注于 VF2++ 图同构的 NetworkX 子集的更快的即插即用替代品。 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 是隔离纯模型智能的优秀基准，但我们也试图捕捉模型能力的其他组成部分。随着模型变得越来越强，用户越来越希望它们能自主工作。理想情况下，一个编码智能体应当接收一份非正式的需求说明，找到既满足规格又符合其隐含的约束和偏好的执行方案，考虑用户的盲区，并且无需反复纠正或澄清即可执行完毕。 在典型的工程场景中，会出现哪些未明确说明的约束和偏好？常见的例子包括：复用已有抽象、遵循仓库代码规范、编写能真正发现 bug 的非平凡测试。这些对于确保代码长期可维护、对用户可理解非常重要。 基于这些以及其他考量，FrontierCode 试图衡量以下方面： - 功能正确性 - 对用户初始提示的解读和扩展 - 为实现做出合理的设计和范围选择，并与现有代码库顺畅集成 ### 我们如何构建 FrontierCode 2.0 FrontierCode 2.0 大体上沿用了 FrontierCode 1.0（https://cognition.com/blog/frontier-code）的方法论。超过 20 位世界级开源开发者各自花费 40 小时以上，从他们维护的仓库中构建真实的编码评测任务。我们的目标是衡量模型作为真正独立贡献者的表现，使用精心校准的评分标准来检验智能体的输出是否真正可合并。关于我们的评分方法和质量控制的更多信息，请参阅我们的 FrontierCode 1.0 博客文章（https://cognition.com/blog/frontier-code）。 如上所述，FrontierCode 2.0 主要通过增加任务多样性、评分标准和任务范围来改进 FrontierCode 1.0。具体来说： - 我们的任务取自多出 55% 的仓库，以更好地捕捉真实编码工作的分布。 - 任务包含多出 43% 的阻断性标准，这些标准以更具体的方式捕捉正确性和设计要求。 - 任务往往需要对代码库进行更大的改动。 我们还通过更严格地审查任务提示、参考解决方案和评分标准来加强质量控制。这些在人工和自动化审核上的投入经常发现来自上游仓库的参考解决方案中微妙的边界情况。在 80% 的 FrontierCode 2.0 任务中，参考解决方案与上游 PR 不同，这一比例从 FrontierCode 1.0 的 60% 上升而来。随着 FrontierCode 拓展到安全相关任务，这种额外的谨慎变得更加重要，因为安全漏洞往往取决于细微之处。在我们的一个自动化审核流程中，某个智能体发现了上游实现中的一个安全漏洞；经过人工审查后，我们将其报告给了仓库维护者。 ### 评估彻底性 在对评分标准进行分类时，我们识别出了一个"彻底性"类别。彻底性标准要求的正确性条件，是智能体理应能从指令和现有代码库中推断出来的，即使这些条件没有被明确表述。它们对于 FrontierCode 2.0 在不完整提示条件下评估智能体的能力至关重要，因为它们能捕捉到那些表面上回应了提示、但遗留或引入了重大功能缺陷的解决方案。 彻底性标准的示例包括： - **修复每一处同类 bug。**提示中指出了某一条代码路径上的 bug，但相同的 bug 也存在于相邻的代码路径中。一个彻底的智能体会找到并修复两处。 - **匹配已有支持范围。**提示要求添加新功能，并提及了一种输入类型。一个彻底的智能体会注意到类似的代码也处理其他输入类型，并同样为它们提供支持。 #### 各类别阻断性标准数量 | 类别 | FrontierCode 1.1 | FrontierCode 2.0 | 变化 | |---|---|---|---| | 彻底性 | 168 | 501 | | | 核心行为 | 399 | 353 | | | 避免回归 | 174 | 259 | | | 有效测试编写 | 202 | 213 | | | Lint / 格式化 / 类型检查 | 112 | 183 | | | 范围 | 56 | 123 | | | 向后兼容性 | 85 | 76 | | | 编译 | 86 | 69 | | | 测试完整性 | 48 | 48 | | | 文档 / 元数据 | 6 | 17 | | | 实现细节 | 9 | 11 | | FrontierCode 1.1 与 2.0 的评分标准类型分布。 在 FrontierCode 2.0 的所有阻断性标准中，彻底性占了显著更大的比例，其总数相比 FrontierCode 1.1 增长了 3 倍。 #### 各类别阻断性标准失败率 | 类别 | FrontierCode 1.1 | FrontierCode 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 主榜对比成本（$） **得分**是评分项的加权综合。未通过阻断性标准的解决方案得 0 分。 **成本**是每次 rollout 的平均美元花费。 正如我们之前所讨论的，导致这一现象的主要因素之一是范围类阻断性标准的存在。大多数标准的通过率会随模型推理力度的提高而*上升*，但范围类标准的通过率却*下降*： #### 各推理力度下评分标准通过率 实现类标准 范围类标准 | 类别 | 低推理力度 | 最高推理力度 | 变化 | |---|---|---|---| | 实现类标准：Claude Opus 5 | 79.3% | 83.0% | | | 实现类标准：Claude Opus 4.8 | 75.5% | 79.2% | | | 实现类标准：Claude Fable 5 | 79.2% | 81.8% | | | 实现类标准：GPT-5.6 Sol | 68.6% | 73.0% | | | 范围类标准：Claude Opus 5 | 69.2% | 51.1% | | | 范围类标准：Claude Opus 4.8 | 81.9% | 70.9% | | | 范围类标准：Claude Fable 5 | 79.1% | 63.4% | | | 范围类标准：GPT-5.6 Sol | 79.7% | 68.3% | | 换句话说，随着推理力度增加，模型倾向于写更多代码、改动更多文件，即使这些改动并不理想。这些曲线效应叠加后会产生形状怪异的得分曲线。其他次要因素包括在更高推理力度下更频繁的作弊行为（模型倾向于"不经意地"拉取到解决方案的 commit），以及过度思考——模型自我纠结后实现了对所要求改动的错误解读。 在 FrontierCode 1.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 的任务设计和评分标准，我们在下面介绍几个示例任务。 ## 致谢 感谢 Claudio Costa*、Martin McKeaveney*、Tomer Nosrati*、Merlijn Vos*、Cristiam Da Silva*、Daniel Fonseca、Fawzi Essam、Ibrahima Gaye Coulibaly、Juan Patricio Marroquin Gavelan、Kai（Tam Nhu）Tran、Manuel Kießling、Mateusz Łopaciński、Thorbjorn Lindeijer*（组长）