一个把仓库里每个文件都标红的漏洞定位智能体，召回率是满分；而任何只给「找到」打分的基准，都会把它排在靠前的位置。Cisco 的 VLoc Bench 之所以不寻常，是因为它的规范里就带着解药——第二个阶段让智能体去跑已打补丁的那份仓库，并按「正确地报告没问题」来给它打分；而它之所以有教益，是因为这个阶段写在规范里、却不在已发表的数字里。大家引用的那份排行榜，量的既是本领也是热情，而它没法告诉你自己看的是哪一个。
一览
同一个团队的两件产物：一个 2026 年 9 月发表的基准，以及一个 10 月发布、用来跑它的智能体评测外壳。
| 产物 | 它是什么 | 形态 | 状态 |
|---|---|---|---|
| VLoc Bench | 仓库规模的漏洞定位基准 | 500 个任务、290 个仓库、6 个包生态、147 个 CWE 类别 | 阶段 A 已评测并发表；阶段 B 已写进规范、未被评测 |
| Agentic FAITH | 把 FAITH 评测框架扩展到多步、使用工具的智能体 | 本地用 Docker，或经 Agent Sandbox 跑在 Kubernetes 上；由环境强制仓库只读 | 2026 年 10 月发布，VulnLoc 是第一个被集成进来的基准 |
阶段 A：0.229 到底告诉了你什么
这个任务比它的表述更难
交给智能体的是一段 CWE 描述和一份仓库的只读访问权，别的什么都没有：没有公告正文、没有文件提示、没有调用栈。它必须返回漏洞所在的那组文件，并按与标准答案比对的文件集 F1 来打分。这个设置有意贴近一个真实的定级工程师的活：手上有一条扫描器告警和一个巨型仓库。而它比「AI 能找漏洞」那一类说法所暗示的要难得多，因为任务不是找到某个 bug，而是在正确的文件里找到那个 bug。
发表的结果是：27 个语言模型与 4 个静态分析工具在同一份提示词、同一套只读工具、同一份命令预算下运行，最好的那个拿到 0.229 的 File F1。而比排名更该传开的那个数字是：在这 500 个任务里有 38.4%，没有任何被评测的模型能找出哪怕一个正确文件。不是分数低——是零分，接近十次里的四次。
千分之六的差距才是有意思的那次测量
第二名是 Antares-3B，一个为此专门训练的专用模型，成绩 0.223。一个三十亿参数的模型，在一项仓库规模的推理任务上只落后最好的通用前沿系统千分之六——这是一句关于任务的论断，而不是关于哪个模型的论断：这里缺的那样东西不是参数。诚实的读法是，仓库规模的定位被别的东西卡住了——搜索策略、上下文预算、以及证据散落在任何单次检索都取不回来的那些文件里——而这正是搜索策略那一支文献反复撞上的同一道上限。
有一条须明说的保留：这些数字出自该团队自己的发布与技术报告，而不是独立评测；而 Antares-3B 的权重尚未释出（已开放权重的是 350M 与 1B 两个模型）。一家机构在自家基准上报告自家第二名模型的数字，不等于编造，但也不等于复现；而当被声称的差距只有 0.006 时，这个区别就重要了。
阶段 B：惩罚一次误报的能力
第二个阶段做的是什么
阶段 B 把修复之后的那份仓库交给智能体——同一份代码库，补丁已打上——并按真负率给它打分：它有没有正确地报告这里不存在这一类漏洞？这一项添加改变了这个基准所测量的东西。单有阶段 A，会被一种完全不含判断的策略拿到最高分：把每个看起来沾边的文件都返回、接受精确率上的扣分、把召回率收进口袋。F1 确实会惩罚这种做法，但它把惩罚压进了一个数字里，而你没法从那个数字里反推出智能体差的是哪一半。阶段 B 把第二半外显出来，而且是在一份「正确答案是沉默」的输入上做的。
沉默是几乎没有哪个智能体基准会打分的输出，却是一个生产中的定级工具大部分时间都在产出的输出。一个在每个 pull request 上都跑的扫描器，只在极少数上会看见一个漏洞；而决定有没有人愿意继续开着这个集成的，是它在绝大多数「这里什么都没有」的情形下做了什么。那正是阶段 B 所定义的那个数字。
而它还没有被报告
缺口就在这里。Antares 的技术报告写明：阶段 B 包含在基准规范之内，但在该工作中未被评测。所以设计存在、从 10 月起跑它的外壳也存在，而那个能让你按误报行为去比较各个智能体的数字，对名单上的任何系统都还不公开。目前在流通的每一份排名，都是一份阶段 A 的排名。
这不是对造出它的那个团队的批评——把这个阶段写进规范、并明说自己还没跑过，比悄悄省掉它要规范得多。这是对这些数字将被如何使用的批评。阶段 A 上那个 0.229 会被引用为「智能体化漏洞分析的当前最高水平」，而那项能告诉你这些系统里有没有哪个能上线、而不至于把一个安全团队淹没在噪声里的测量，眼下还不存在。
一个没有真负能力的基准，分不出一个谨慎的智能体和一个不分青红皂白的智能体。把这项能力写进规范是一半工作；另一半是把它跑出来。
这套外壳也在作出一个论断
10 月发布的 Agentic FAITH 是会留得最久的那部分，因为一个基准的可复用程度，上限就是跑它的那件东西。它的三个取舍值得照抄进你自己的评测装置。
- 仓库只读，由环境强制。不是一句提示词里的指令——是沙箱的一项性质。一个能改仓库的智能体可以让阶段 B 轻易通过，而排除这件事的唯一办法，是让那次写入不可能发生，而不是不被鼓励。这就是最简形式的评测完整性问题。
- 两个执行目标。可信输入在本地用 Docker，其余一切经 Agent Sandbox 跑在 Kubernetes 上。跑一个安全基准意味着执行来自 290 个真实仓库的代码，而这就是沙箱问题，不是事后再说的事。
- 任务带检查点。执行记录会被保存、已完成的任务会被打上检查点，于是一次被打断的运行会复用符合条件的结果，而不是从头再来。很枯燥，而它正是「每改一次就重跑一遍的 500 任务基准」与「一年跑两次的基准」之间的差别——见评测的成本。
对每个系统施加同一份命令预算是第四个取舍，也是多数私有评测最容易做错的那个。没有它，一个被允许 40 次工具调用的智能体与一个被允许 400 次的智能体之间的比较，比的是预算；预算对齐的评测是这个问题的一般形式。
该带进你自己评测集的东西
你大概并不在给漏洞定位做基准。可迁移的那部分是结构性的，而它适用于任何「职责是察觉某件事」的智能体。
每一个检测器评测都需要一个负样本的那一半。如果你的评测集里只有「确实有问题」的用例，那你的分数是一项灵敏度的度量，而没有一项与之配对的克制度的度量；于是在它上面进步最快的那个智能体，会是学会了永远说「是」的那一个。请有意去构造干净的用例：同一份输入、把问题移走，按「正确地沉默」来打分。把两个数字分别报告，因为一个混合出来的分数是一笔你反推不出来的取舍。
把「未发现」做成一等输出。它需要一个 schema、一个置信度，以及在轨迹里某处记下检查了什么——否则「没有发现」和「没去看」在你的日志里就是同一个字符串。评测护栏与检测器详细讲了这种不对称，而校准才是你真正想测的那项性质。
预料到零分，并且把它报出来。0.229 的平均 F1 是个比「有 38.4% 的任务没有任何模型做出来」友好得多的数字，而后者才是能预测你周一的那一个。请报告「每个系统都是零分」的任务占比；这是基准报告里能买到的最便宜的诚实。
常见问题
VLoc Bench 与 VulnLoc 有什么区别？
它们是同一个任务族的两个名字：该团队在 2026 年 9 月以 VLoc Bench 的名义发表了这个基准，而 VulnLoc 是它在 10 月作为第一个被集成进 Agentic FAITH 的基准时的叫法。如果你在比数字，请确认它们出自哪个阶段、哪个版本的外壳。
0.229 的 File F1 算差吗？
它很低，而且它对一项确实很难的任务很诚实。更有用的说法是那个零分率：在 500 个任务里有 38.4%，没有任何被评测的模型找出哪怕一个正确文件。正是这个数字告诉你，仓库规模的定位不是一个已被解决、正在被产品化的问题，而是一个还敞着的问题。
为什么一个 3B 的专用模型几乎追平了最好的前沿系统？
因为卡住它的那条约束看起来不像模型容量。仓库规模的定位是一个在散落于许多文件的证据之上的搜索问题，而一个更大的模型并不会自动获得更好的搜索策略或更大的有效上下文。请把 0.006 这个差距当作一句关于任务的论断。
我能在自己的代码库上跑它吗？
这套外壳是为一个带标准答案的固定任务集而建的，所以没有被标注的漏洞，你就没法给自己的仓库打分。今天你可以照抄的是那个两阶段的形态：拿你已经有的任何检测器评测，为每个用例做一份打过补丁的副本，并把「正确地沉默」作为它自己的一个数字来打分。
加一个真负阶段会让评测变慢吗？
它大致会把运行次数翻倍——而这恰恰是检查点与对齐的命令预算之所以在这套外壳里的原因。它同时也是最便宜的办法，让你在一个安全团队之前先知道：你那个召回率 90% 的检测器有 40% 的误报率。
延伸阅读
本站：
- 评测护栏与检测器——负样本那一半的一般化。
- 评测完整性与刷分——为什么只读必须是强制的、而不是请求的。
- 预算对齐的评测——给每个系统同一份命令预算。
- 漏洞修复智能体——一次正确的定位之后，下游会发生什么。
- 批判地阅读基准——本文就是这个习惯的一个实例。
来源：
- VLoc Bench——基准页面、任务计数与排行榜。
- Introducing Agentic Evaluation in FAITH——外壳、两个阶段与执行目标。
- Antares 技术报告——0.223 这个数字，以及「阶段 B 未被评测」的那句说明。