我们对FrontierCode方法进行了改进，并发布了FrontierCode 1.1版本，其中包含了更清晰的公平互联网使用指南和更精细的评分标准。更多变更详情请参阅我们的博客： https://t.co/K1m1Qo34bQ

FrontierCode 1.1

来源：https://cognition.com/blog/frontier-code-1.1 作者：Eric Lu, Ben Pan, Fermi Ma, Alex Lombardi, Deniz Birlikci, Sam Lee, Ray Wang, Rohan Choudhury, TC Qin, Carlo Baronio, Jacob Teo, Joon Hee Lee, Silas Alberti 以及其他贡献者 → (https://cognition.com/blog/frontier-code-1.1#acknowledgments) 07.07.26

一个月前，我们推出了 FrontierCode[1]，这是一个不仅衡量代码正确性、还衡量代码质量的评估。今天，我们发布了改进版本FrontierCode 1.1，包含以下改进：

• 公平的互联网使用。我们改进了方法，以捕捉正当互联网使用（例如查阅文档）与不当使用（任何可能泄露任务解决方案的行为）之间的细微差别。
• 更公平的评分。我们审计了所有1000+条评分标准，放宽了75条过于严格、可能不公平地惩罚有效解决方案的标准。
• 新的模型分数。我们发布了 Sonnet 5 的分数以及 Fable 5 的更新分数。

未来，我们将报告基于 FrontierCode Main 和 Extended 子集、采用 1.1 方法评估的分数。我们将不再报告 Diamond 子集，原因详见下文。

结果 (https://cognition.com/blog/frontier-code-1.1#results)

上方图表展示了 FrontierCode 1.1 Main 的结果。尽管 FrontierCode 1.1 的方法导致了一些绝对分数上的变化，但我们评估的模型之间的相对表现与 1.0 版本相比没有实质性变化。

在本博客的剩余部分，我们将详细介绍改进后的、关于合理互联网使用的方法。

正确对待互联网使用 (https://cognition.com/blog/frontier-code-1.1#internet-use)

FrontierCode 的任务源自开源代码库中的真实 PR。这产生了一个真实的任务分布，但这也意味着任务解决方案可能存在于公共互联网的某个地方，例如上游仓库的后续版本、其多个镜像中，甚至包注册表中（代理有时可以通过安装最新版本来获取修复）。因此，能够访问互联网的代理有时可以通过查找答案而不是自己解决任务来走捷径。

在设计 FrontierCode 1.0 时，我们发现了一些代理找到上游代码库的实例，但这种情况很少见，我们认为不值得进行明确的修正或方法更改。然而，像 Fable 5 这样的最新模型越来越擅长在线检索信息，不当互联网使用的发生率因此上升。如果没有相反的指示，查找现有的修复方案对于一个有能力的代理来说是一种自然策略。我们预计这一趋势在未来的模型中将持续下去。

为什么不完全关闭互联网？

不当的互联网使用在 SWE 评估中越来越常见[2,3,4,5]，通常的解决办法是完全禁用互联网访问。但全面禁止存在两个严重问题：

• 一些 FrontierCode 任务在设计上需要互联网访问，例如查阅 API 合同。这反映了现实世界中的软件工程，也是该基准测试的一个明确目标。
• 即使对于不需要互联网的任务，前沿模型也越来越被训练成将搜索作为其推理和上下文收集流程的核心部分。禁用互联网访问会消除这一能力，并可能导致基准测试低估模型的真实性能。

出于这些原因，FrontierCode 没有（并且仍然没有）禁止互联网使用。相反，FrontierCode 1.1 旨在消除不公平的互联网使用，同时保留互联网访问带来的真实感。

我们的方法：定义公平的互联网使用，然后验证

我们发现，最新的模型足够对齐，只需告知它们哪些互联网访问是被允许的（例如查阅文档）以及哪些是被禁止的（任何可能绕开任务的方式），就几乎完全消除了不公平的互联网使用，同时仍然允许公平的互联网使用。对提示的遵守程度非常好：采用此提示后，我们评估的每个模型的不公平互联网使用率均降至1%以下。

FrontierCode 1.1 通过两种保障措施实现这一点：一个解释什么是公平互联网使用的提示，以及一个检测不公平互联网使用并将其运行结果清零的经典验证器。目前，仅靠提示就足以基本消除不公平的互联网使用；验证器确认了这一点，并能捕捉未来可能出现的偏差。

保障措施1：一个“公平互联网使用”提示，清晰区分允许和不允许的互联网使用。

下面我们提供两个模型互联网使用的示例：

模型可以自由搜索网页，但扫描器会在模型打开上游 PR diff 页面的那一刻标记该运行。任务：长邮件中的省略号

0/14

滚动到视图内观看代理工作…

互动：实时观看代理工作。常规步骤播放较快；扫描器在模型打开上游 PR diff 页面、运行被标记的时刻减速。保障措施2：程序化检测。我们标记对源拉取请求、上游补丁或文件，以及可能包含解决方案的镜像或贩售副本的引用。为了惩罚不公平的互联网使用，被标记的运行得分为零。

这些保障措施共同基本消除了所有不公平的互联网使用，同时仍然允许公平使用。代理继续像在真实任务中那样查阅文档、API 参考和背景概念。我们相信，这种消除不公平互联网使用同时保留真实感的组合，使得 FrontierCode 1.1 能更准确地衡量模型的真实能力。

我们考虑过的替代方案

在确定这些保障措施之前，我们还考虑过通过特定网站的阻止列表或允许列表来强制执行公平的互联网使用。不公平的互联网使用主要分为两类：GitHub（及其众多镜像）和包注册表（代理通常只会运行 npm install 来拉取已经包含解决方案的最新版本）。

阻止列表被证明不切实际。经过多次屏蔽域名和检查代理轨迹的迭代，我们的阻止列表增长到大约 1200 个域名，而代理仍在不断寻找新的变通方法，有时会花费 20 多个回合对抗阻止列表，然后自行解决任务。屏蔽网站也会破坏合法的工作流程，因为像 GitHub 这样的网站有时确实是完成任务所必需的。

允许列表则存在相反的问题：它需要预测代理可能合法需要的每个网站，并为每个任务构建自定义的允许列表，这无法扩展。此外，无论哪种方式，它都会扭曲代理行为：如果允许列表对代理可见，它会引导代理访问列表中的网站；如果隐藏，代理要么认为互联网坏了，要么浪费时间探测哪些网站可达。这两种情况都不能反映代理在实际中如何使用互联网。

最终，清晰定义公平使用并验证合规性，比任何形式的网络层强制措施都更简单、更稳健。

细化的障碍标准 (https://cognition.com/blog/frontier-code-1.1#blocker-criteria)

FrontierCode 根据一组由评审者定义的标准对每个任务进行评分，其中一些被指定为障碍：这些是对任务至关重要的要求，如果有一个障碍未通过，则该运行的总分将被限制，就像在真实代码审查中提出修改要求一样。对于 FrontierCode 1.1，我们审计了 FrontierCode 中所有 1000+ 个障碍标准，并手动审查了被标记的标准。我们发现 75 个障碍过于严格，并将它们降级为非障碍状态。我们预计这将大幅减少评分中假阴性结果的出现。

弃用 FrontierCode Diamond (https://cognition.com/blog/frontier-code-1.1#diamond)

正如我们在原始博客文章[1]中所述，Diamond 由我们完整的 150 个任务 Extended 集中最难的 50 个任务组成，而 Main 由最难的 100 个任务组成。随着 FrontierCode 1.1 的更新，Diamond 集不再反映最难的 50 个任务。此外，由于最难任务的解决率非常低，我们确定 Diamond 的性能本质上存在噪音。因此，我们将弃用 Diamond 集，未来将依赖 Main 和 Extended 集。

参考文献 (https://cognition.com/blog/frontier-code-1.1#references)

[1] Cognition, “Introducing FrontierCode,” 2026. https://cognition.com/blog/frontier-code

[2] METR, “Summary of METR’s predeployment evaluation of GPT-5.6 Sol,” June 26, 2026. https://metr.org/blog/2026-06-26-gpt-5-6-sol/

[3] Naman Jain, “Reward hacking is swamping model intelligence gains,” June 25, 2026. https://cursor.com/blog/reward-hacking-coding-benchmarks

[4] Datacurve, “DeepSWE v1.1 — A revision of DeepSWE v1,” July 2026. https://deepswe.datacurve.ai/blog/deepswe-v1-1

[5] Posttrain, “Clean Coding Index,” 2026. https://coding-index.posttrain.dev/

致谢

研究：Eric Lu, Ben Pan, Fermi Ma, Alex Lombardi, Deniz Birlikci, Sam Lee, Ray Wang, Rohan Choudhury, TC Qin, Carlo Baronio, Jacob Teo, Joon Hee Lee, Silas Alberti 设计：Katie Cheng, Joseph Alessio 贡献者：Jeffrey Ling, Walden Yan