CyberGym 基准详解：E2E 分数实际衡量的是什么

流传最广的那个 CyberGym 分数——发布帖里的数字、会被拿来跨模型比较的那个——是 131 个经过筛选的任务上的任务成功率；这里的成功意味着智能体生成了一个概念验证输入，能使未修补的 C/C++ 构建崩溃，编写了一个阻止该崩溃的补丁，并且没有破坏项目开发者编写的测试。在 BenchLM 的汇总中，MiMo-V2.6-Flash 以 95.1% 领先，MiMo-V2.6-Pro 为 94.0%，DeepSeek-V4.1-Flash 落后几个百分点，处在接近 90% 的高位。几乎所有引用那张表的人都没有提到三件决定这些数字是否可比的事：该基准存在不止一种实现，大多数行是提供方自报而非独立运行的结果，而最有趣的那个阶段被记录了却没有计入。这正是同一套来源标注标准，AI 事件档案将其应用于自身条目——没有来源的说法不算结果——而 CyberGym 语料库未达到该标准的频率，比其声誉所暗示的更高。

本指南介绍该基准要求智能体做什么、任务集是如何构建的、各实现在哪些地方存在差异，以及防御者应从高分中得出什么结论、不应得出什么结论。

任务：找到、复现、修补——且不破坏任何东西

CyberGym 来自伯克利负责任去中心化智能中心（Berkeley Center for Responsible, Decentralized Intelligence），其前提被刻意设定得很窄。每个任务都针对一个被广泛使用的开源 C/C++ 项目中的内存安全漏洞。智能体必须定位该缺陷，编写一个能触发 sanitizer 崩溃的概念验证输入，然后修补代码，使该崩溃不再复现——同时项目自身的测试仍能继续通过。这一整套流程才是关键所在。一个只要求“找出缺陷”的基准测试会奖励模式识别；而要求提供可用的崩溃输入和不破坏功能的补丁，则迫使智能体完成从怀疑到实证缺陷再到修复的闭环。

RDI 将该基准托管在一个更广泛的观测体系内，该体系跟踪 AI 在网络攻击与防御各阶段的能力；这种定位值得注意：CyberGym 是测试台上的一个工具，与 ExploitGym 以及端到端变体并列。把它当作独立排行榜来解读会丢失这一背景，这也是这些数字在传播中容易失真的原因之一。

四个阶段，其中三个阶段计分

评分规则是基准测试中最未被充分报道的部分，因为正是在这里，一个听起来合理的分数可能与实际发生的情况出现偏差。

阶段 1是复现：智能体提供的概念验证输入是否会使未修补的构建崩溃。阶段 2是补丁：提交的更改是否阻止了该特定崩溃。阶段 3是回归：开发者编写的功能测试是否仍能通过。这三项共同产生评分。

第 4 阶段要问的是补丁是否修复了真正的真实漏洞，并且它被记录为诊断项，而不计入评分。这种不对称值得稍作说明，因为它正是“智能体能让崩溃消失”与“智能体能修复缺陷”之间的区别。两者都是有用的主张；但它们不是同一种主张。一个通过捕获信号、把边界检查放宽到越过溢出范围，或干脆完全禁用该代码路径来压制崩溃的智能体，会在第 1 到第 3 阶段得分，却在第 4 阶段失败。如果一份报告只给出一个数字，却不说是否查看了第 4 阶段，你就无法判断所衡量的到底是这两件事中的哪一件——而诊断项存在的意义，正是让你可以提出这个问题。

131 项任务是如何选出的——以及这对评分有什么影响

源数据集大于评分集，而过滤是影响可比性的最大单一杠杆。RDI 的数据集包含来自 139 个开源项目的 920 个漏洞，这些漏洞取自 Google 的 OSS-Fuzz。第三方追踪器使用的端到端变体将其缩小到 131 个任务，每个项目一个任务，按难度选择，并排除存在 oracle 泄漏或沙箱兼容性限制的任务。

由此直接得出三个后果。第一，每个项目一项任务意味着得分主要由广度而非深度决定：一个在许多项目上表现平平的智能体，会胜过一个在三个项目上表现优异的智能体；这是一种站得住脚的设计选择，也是一种不同的衡量方式，不同于“这个智能体能够修复多少漏洞”。第二，排除 oracle 泄漏会移除那些答案可从环境中发现、而非通过推理得出的任务，因此剩余任务集在特定意义上更难——它移除的是捷径，而不是移除简单任务。第三，每个任务 90 分钟的时间预算，并且是在基于项目 OSS-Fuzz 镜像构建的沙箱内，这属于成功定义的一部分，而非细节；因为很大一部分真实漏洞工作恰恰受这类约束限制，而依赖无界探索的智能体在这里会失败，在其他地方却会成功。

任何忽略任务选择规则的比较，都是在比较两个恰好同名的不同测试。

两种实现，以及它们为什么不必一致

大多数混淆就出在这里。CyberGym-E2E 既作为一个 RDI 基准存在，也作为由第三方评估方运行的一套实现存在，而这两者并不保证对同一个模型给出相同的数值。评估方自己的文档对此说得很直白：其实现使用一个经过筛选的 131 个任务集，每个项目一个任务，按难度选取；并且它使用自己的 agent harness，在基于该项目 OSS-Fuzz 镜像构建的隔离沙箱中运行每个任务，每个任务有 90 分钟预算。

这句话里包含两个决定得分的变量。运行框架是智能体在其内部运行的循环——它如何观察工具输出、能走多少步、在尝试失败后如何恢复。更强的运行框架搭配更弱的模型，可以胜过相反的组合，而运行框架并不属于模型的权重。预算与这两者都相互作用。因此，CyberGym 的数字应当准确地表述为“这个模型，在这个运行框架中，在这个实现下”，而一个脱离了具体实现来引用的数字，就是一个没有分母的数字。

有一个值得指出的二阶效应：由于 harness 承担了实际的工作，两个模型版本之间 CyberGym 分数的提升，可能有一部分来自 harness 的改进；而厂商报告自家 harness 上的结果，报告的是系统能力，而非模型能力。两者都合理；但把二者混为一谈则不然。

如实解读追踪表

大多数人遇到的那张表是二次汇编，而且会标注自身来源——如果你细看标注，这正是其有用之处。29 行中，7 行来自基准所有者或独立运行，21 行是提供商自报，1 行是二次报告。该汇编明确表示，展示此表仅供参照，并不据此排名，并建议谨慎阅读，因为大多数行都是自报数据。它自己的饱和说明是页面上最有用的那一行：前三名相差约 70 分，而前十名则集中在约 10 分之内，因此该表仍能区分模型——但在区间顶部则不能，那里的排序很单薄。

提供商自报数据是一种可展示的证据。它不是独立测量，而这一区别在本基准测试中比在大多数情况下都更重要，因为 harness 变量给供应商留出了相当大的空间来调整其报告的数字。当自报结果与独立运行结果不一致时，以独立运行为准。当只存在自报结果时，诚实的解读是“未经核实、看似合理、没有可比基线”。

同样的谨慎在相反方向上同样适用于这个基准为读者设下的陷阱：没有 CyberGym 条目的模型并没有得零分。它尚未在那个评测框架中被测量，这是另一回事。把缺失当作失败，正是一张表不再是一项测量、而变成排行榜的方式。

高分对防守者意味着什么，又不意味着什么

安全团队真正要问的问题不是“哪个模型位居榜首”，而是“一个在此项上得分很高的智能体对我的风险意味着什么”。基准测试回答的问题比实际被问到的更狭窄，而这个差距值得点明。

这确实意味着该智能体能够在 90 分钟内、在已知构建中，定位真实开源代码中的内存安全缺陷，生成可用的崩溃输入，并编写一个既能阻止崩溃又不会破坏测试的更改。这是一种真实的能力，与漏洞分类和补丁工作直接相关，而且在这类任务中，一个称职的智能体能够切实缩短分析师的待处理队列。

这并不意味着智能体理解你的代码库、威胁模型或部署环境。任务取自公开的 OSS-Fuzz 目标，这些目标具有已知的真实漏洞，以及一个能告诉智能体何时完成的测试套件。生产代码没有这样的判定器。这也不意味着智能体会找到这个缺陷，而不是一个缺陷：第 4 阶段之所以存在，正是因为二者会分歧，而第 4 阶段不算数。

而且它并不会转移到攻击性用途上；在那一侧，同样的能力会被作出不同的解读。一个能够定位并复现内存安全缺陷的智能体，也能在未被授权测试的代码中这样做，这正是为什么这种量级的能力恰恰促使人们在模型层面实施访问控制，而不是在系统提示中写一句免责声明。

在信任 CyberGym 给出的数字之前，该问些什么

五个问题，一份写得好的报告能够回答，而一篇发布帖通常无法回答。

• 哪种实现？ RDI 的基准测试，还是第三方评估者过滤后的变体。如果报告没有说明，这个数字就无法与任何东西比较。

• 由谁运行？独立评估还是提供商自报。汇总表会逐行标注这一点；大多数营销材料则不会。

• 哪个测试框架，预算多少？ 如果该测试框架是供应商自有的且未作说明，则应将结果视为关于特定产品配置的系统级声明。

• 是否已查阅第 4 阶段？将报告的发生率与旁边的诊断信息一起看，就能判断补丁是真正修复了缺陷，还是仅仅压制了崩溃。

• 哪个任务集？ 按难度选出的每项目一个、共 131 个任务是常用集；不同的筛选条件就是不同的测试。

Cybergym 是一个构建良好的基准，用于一项艰难而真实的任务，而它的构建过程比它的排行榜更有意思。各个阶段告诉你一个智能体必须做什么；过滤机制告诉你这个分数衡量的是什么；评测框架告诉你功劳该归于谁。附带这三者的数字才真正有用。单独出现的数字，不过是带着百分号的新闻稿。