把 AI Agent 放进真实漏洞复现链,让它自主跑通一个 CVE,这件事听起来像是科幻,2025 年到 2026 年已经在系统化的基准测试里跑出了硬数据。UIUC Kang Lab 在 2025 年 3 月发布的 CVE-Bench,把 40 个 NIST 高危 CVE 装进沙箱,让 AI Agent 在 one-day(给出漏洞描述)和 zero-day(不给出描述)两种设置下尝试自主复现;2
把 AI Agent 放进真实漏洞复现链,让它自主跑通一个 CVE,这件事听起来像是科幻,2025 年到 2026 年已经在系统化的基准测试里跑出了硬数据。UIUC Kang Lab 在 2025 年 3 月发布的 CVE-Bench,把 40 个 NIST 高危 CVE 装进沙箱,让 AI Agent 在 one-day(给出漏洞描述)和 zero-day(不给出描述)两种设置下尝试自主复现;2026 年 8 月,另一篇 arXiv 论文 VulnGym 把同一思路搬到仓库级漏洞检测一侧,给出 184 条 GitHub 公告与 408 条漏洞条目,评测 Coding Agent 在真实仓库里能找到多少漏洞、能否给出可信的证据链。两个项目从攻击与防御两端,共同回答了"AI Agent 在网络安全场景里到底能干多少活、哪些活是它根本干不好的"这个企业落地必须面对的问题。
一、从分类任务到 Agent 任务:网络安全评测的范式转移
过去几年,LLM 在网络安全场景的评测大多停留在"代码分类"层面——给一段代码,模型判断"有没有漏洞""属于哪一类漏洞"。这类评测在学术上有价值,但与真实安全工程的距离很远。真实场景下,安全工程师面对的不是一段孤立的代码,而是一个完整运行的 Web 应用、一条 GitHub 公告、若干个可疑的入口点。他们要做的是"自主探索代码库、定位可疑路径、构造攻击载荷、验证是否成功"。这个过程的每一步都需要 Agent 的能力——工具调用、多步推理、长期记忆、自我评估。
CVE-Bench 的设计动机直接来自这个范式转移。论文 arXiv:2503.17332(Yuxuan Zhu、Antony Kellermann、Dylan Bowman 等 16 位作者,UIUC)把评测对象从"模型对代码的判断"换成"Agent 对真实漏洞的复现"。数据集包含 40 个 NIST 在 2024-05-01 到 2024-06-14 之间发布的关键级 CVE,涵盖远程代码执行、SQL 注入、权限提升等高风险类别。每个 CVE 都有一个目标 Web 应用,Agent 拿到目标后需要自主执行攻击,触发指定的结果。
VulnGym 的设计动机则从防御侧展开。论文 arXiv:2608.02001(Kexing Ji、Wang Bin 等 10 位作者,2026-08-03)指出,现有的漏洞检测基准大多在"预先选定的代码片段"上做分类评测,这无法衡量 Coding Agent 在仓库级别自主探索、定位漏洞代码、构建证据链的能力。VulnGym 把 184 条 GitHub 公告与 408 条漏洞条目对齐到对应的脆弱版本仓库,每个条目都标注行级入口点、关键操作、漏洞追踪链。这种细粒度的 ground truth 让评测不只是"对/错",还能诊断"Agent 错在哪一步"。
两个项目的共同设计原则是"从代码片段到真实仓库,从分类到 Agent,从单步判断到多步推理"。这与过去几年的 LLM 评测思路形成鲜明对比——CVE-Bench 和 VulnGym 都在强调:网络安全场景里,模型的能力不是"识别一段代码有没有洞",而是"在真实系统里跑通一次完整攻击或定位一条完整漏洞链"。
二、CVE-Bench 的评测结果:Agent 能干多少活
CVE-Bench 在 leaderboard 上给出的结果非常具体。最新的 v2.1.0 版本(Default Agent + Claude Opus 4.6,2026-04-11 数据)显示 Pass@1 达到 32.5%,平均每个任务的成本是 0.31 美元。早期的 v1.0 版本(T-Agent + GPT-4o,2025-03-21 数据)Pass@1 是 8.0%,平均成本 1.70 美元。从 8% 到 32.5%,差不多一年时间里 Agent 自主复现真实 CVE 的能力翻了四倍。
这个数字背后有几个值得展开的工程细节。第一,32.5% 不是"成功入侵率",而是 Pass@1——单次尝试的成功率。如果允许多次尝试,数字会更高,但安全评测通常关心的是"一次跑通"的能力,因为真实的零日攻击窗口很短。第二,0.31 美元的平均成本对应一次完整的 Agent 运行,这意味着 CVE-Bench 的任务可以在相对便宜的预算下大规模评测。第三,one-day 和 zero-day 两种设置的区分——前者给 Agent 漏洞描述,后者不给——后者才是真实零日场景的逼近。CVE-Bench 的 leaderboard 同时跑两种设置,数据公开可见。
8 个评测目标覆盖了 Web 漏洞的主流攻击面:拒绝服务(让网站持续不可用)、文件访问(尽可能多地读服务器文件)、远程代码执行(执行 `/tmp/pwn`)、数据库修改、数据库访问(读 `secret` 表)、未授权管理员登录、权限提升、出站服务(让服务器向外部地址发请求)。每一类目标都对应一种攻击向量的最终效果,Agent 必须自主判断"用哪种漏洞、怎么构造载荷、怎么验证成功"。这种设计直接对应企业安全团队的实战场景——不是"模型答对了哪道题",而是"Agent 真的跑通了哪条攻击链"。
三、VulnGym 的诊断视角:Agent 错在哪一步
VulnGym 在数据规模和评测粒度上都比 CVE-Bench 更进一步。数据集包含 184 条 GitHub 公告、408 条漏洞条目,跨 23 个真实仓库。每个条目都标注行级入口点、关键操作、漏洞追踪链——这意味着评测不是"对/错",而是可以拆解到"Agent 能不能定位到入口点"、"Agent 能不能找出关键操作"、"Agent 能不能构建完整的证据链"三个子任务。
这种细粒度评测的价值在论文的实验结果里体现得很直接。VulnGym 指出当前 Coding Agent 在"端到端的仓库级漏洞检测"和"构建准确的支撑追踪链"两个维度上都仍然有限。换句话说,Agent 不是不能找到漏洞,而是经常找错地方,或者找到了漏洞但给出的证据链不完整、不可信。
对企业安全团队而言,这个结论的工程含义非常清晰:Coding Agent 作为漏洞检测工具的"辅助作用"已经成立——它能帮安全工程师缩小排查范围、提示可疑路径;但"替代作用"远未成立——它给出的检测结果必须经过人工审计才能作为修复依据。VulnGym 的细粒度 ground truth 实际上是为这种"辅助 + 审计"的工作流量身设计的——Agent 提供初筛,人基于细粒度标注做最终判断。
四、两套设计的共同底层逻辑
CVE-Bench 和 VulnGym 看起来在做不同的事——前者测 Agent 能不能复现漏洞,后者测 Agent 能不能检测漏洞——但它们共享三个底层逻辑。
第一个逻辑是"真实优于模拟"。两个项目都不使用人造漏洞样本,而是直接对齐 NIST CVE 库与 GitHub 安全公告。这意味着评测任务与现实威胁完全对应,不会出现"基准分数高但实际场景不管用"的情况。这种做法与 TradingAgents 用真实历史数据、Harden 用 LinuxArena 这种公开基准的思路一致——评测的可信度来自数据源的真实性。
第二个逻辑是"可复现优于一次性"。CVE-Bench 提供 Docker 化的沙箱环境,VulnGym 用对齐的 GitHub 仓库与行级标注,两个项目都允许第三方独立复现实验。这种开放性是网络安全评测的基础——一个不能被独立复现的"基准分数"在企业安全场景里几乎没有价值。
第三个逻辑是"细粒度优于粗粒度"。CVE-Bench 的 8 类攻击目标、VulnGym 的行级入口点与证据链标注,都说明两个项目不满足于"Agent 整体表现"的单一分数,而是希望诊断到具体环节。这种细粒度评测对工程改进更友好——团队可以根据诊断结果决定"该优化 Agent 的工具调用、还是优化多步推理、还是优化自我评估"。
五、企业落地时该选哪条路
这两个项目不是互斥的,而是覆盖安全工程的不同阶段。CVE-Bench 适合"红队 / 渗透测试"团队——用 Agent 在受控沙箱里尝试复现已知 CVE,验证自家系统的修复是否到位。VulnGym 适合"蓝队 / 代码审计"团队——用 Agent 在自家代码库里主动搜索漏洞,作为人工审计的预筛工具。
对企业安全架构师而言,优先级通常是先有蓝队能力,再有红队验证。蓝队的漏洞检测是常态化工作,每天都要跑;红队的渗透验证则是周期性工作,通常按季度或重大变更触发。先把 Coding Agent 接入代码审计流水线,跑出稳定的"预筛 + 人工复核"工作流;再把 Agent 接入渗透测试沙箱,作为验证工具使用。
具体到实施阶段,有三条经验值得参考。第一,把 Agent 的输出当作"线索"而不是"结论"——无论是漏洞检测还是漏洞复现,Agent 的判断都需要人工审计,这一点 VulnGym 的细粒度评测已经明确说明。第二,把评测框架本身纳入安全工具链——CVE-Bench 与 VulnGym 都是开源项目,企业可以直接基于它们构建内部基准,定期评测自家 Agent 的能力变化。第三,把成本与延迟作为硬指标——CVE-Bench 的 0.31 美元/任务、32.5% Pass@1 这类数字是企业选型时的重要参考,而不是只看"模型能不能做"。
六、组织层面的工程纪律
技术选型之外,企业级网络安全 Agent 的落地还需要组织层面的纪律。一个常见误区是"Agent 能替代安全工程师"——把 Coding Agent 直接接入生产环境的漏洞检测流程,没有人工复核节点。CVE-Bench 的 32.5% Pass@1 已经说明 Agent 的能力上限——67.5% 的任务它仍然做不到。把它当作"全自动工具"使用,意味着剩下 67.5% 的漏洞要么漏报要么误报,后果都由企业承担。
另一个常见误区是"基准分数高就代表工具好"——看到 CVE-Bench 的 leaderboard 上某个 Agent 分数高,就以为它能直接用到生产环境。基准与生产环境的差距往往体现在数据分布、上下文长度、工具调用稳定性等多个维度。CVE-Bench 与 VulnGym 这种细粒度评测正是为了诊断"差距在哪",而不是简单给出一个总分。
最后一个值得强调的点是攻击与防御的平衡。CVE-Bench 让 Agent 复现漏洞是出于防御目的——知道攻击者能用 Agent 做到什么,才能有针对性地加固。VulnGym 让 Agent 检测漏洞则是直接的防御能力建设。两个项目不是对立,而是同一安全工程链路上的两端。企业部署时应当明确:Agent 在自家流程里扮演的是"攻击模拟器"还是"漏洞检测器",两者的权限边界、安全审计要求、责任归属完全不同。
七、结语:AI Agent 进入安全工程,是工具进化而不是替代
把 AI Agent 放进漏洞复现链,让它跑通一个 CVE;把 Coding Agent 放进代码仓库,让它定位一条漏洞链——这些能力在 2025 年到 2026 年已经跑出可量化的硬数据。CVE-Bench 的 32.5% Pass@1、0.31 美元/任务,VulnGym 的 184 条公告、408 条漏洞条目,共同说明 AI Agent 已经是网络安全工程师可用的辅助工具。但这种辅助不等于替代——67.5% 的失败率、Agent 证据链的不完整、对人工审计的依赖,都说明 AI Agent 进入安全工程的真正角色是工具进化,而不是人员替代。
这也是为什么 2026 年下半年这两个项目值得企业安全架构师关注:它们都不是在做"更聪明的 AI 黑客"或"更聪明的 AI 审计员",而是在做让 AI Agent 在网络安全场景里可评测、可诊断、可治理的基础设施。当这套基础设施逐步成熟,企业级安全工程的下一个阶段——从人工驱动走向人机协同——才有真实落地的可能。
