把一份漏洞描述交给智能体，它在代码仓里查找十几次，最后报出正确文件。项目负责人看到“答对了”，会不会放心把它接进生产线？思科Foundation AI 10月23日介绍的Agentic FAITH，恰好把这个问题拆开：同样的最终答案，可能来自扎实的证据链，也可能是偶然猜中；一个模型在有漏洞的仓库里能报对文件，却可能在修复后的仓库继续制造误报。[1] 企业采购安全智能体，应该看它做过什么、何时停下来，以及怎样处理“没有漏洞”的情形。
从一问一答到会动手的评测
FAITH原来用统一流程组织网络威胁情报、漏洞分类和安全知识等问答测评。Agentic FAITH是在这一框架中加入多步任务与工具使用：query执行并存档、eval评分、summarize汇总，run-all可串起整套流程。[1][2] 研究人员可以在可重复的任务条件下查看模型的工具调用、错误与停止原因，定位最终答案背后的失败环节。
问答题通常只有一个输入和一个回答；代码仓排查却会分叉。智能体先决定搜文件名还是调用终端查符号，看到返回结果后决定读函数定义、查看调用链还是停止。搜索路径一变，最终提交就可能不同。如果只保留最后那一行答案，失败时很难知道是仓库没有被正确挂载、模型没有查到文件，还是它查到了却误读了代码。思科官方介绍称，FAITH会保存对话、工具调用及返回、提交答案、执行错误和任务停止原因。[1] 对一家要持续部署代理的企业，这些字段比一张平均准确率表更便于排障。
项目文档还明确了一个技术约束：现有智能体运行需要支持结构化工具调用的OpenAI兼容Chat Completions端点，使用openai引擎、chat_comp生成模式和chat提示格式；普通问答评测支持的模型后端范围更宽。[2][3] 技术人员集成前要检查模型与网关能否稳定表达工具调用，而不是仅凭“接口兼容”四个字推定任何模型都能跑所有基准。
VulnLoc的两段考题：找到它，再确认它已消失
首个整合的多步基准是VulnLoc。每个任务给出代码仓快照和一类漏洞的文字描述，允许模型通过终端工具在只读仓库中探索，最后交出可疑文件列表，或者明确回答没有匹配漏洞。[1] 公开的Vulnerability Localization Benchmark项目介绍了500项来自GitHub Security Advisories的真实漏洞、npm、pip、Maven、Go、Rust与Composer六类生态，以及漏洞修复前后的仓库快照。[4] 样本覆盖不同生态与严重程度，但它仍是经过筛选的公开漏洞数据，不代表某家企业内部遗留代码的分布。
第一阶段，智能体拿到修复前版本，需要找出受影响文件，以文件集合F1作为主要成绩。假设真值为三个文件，模型只报一个，精确率可能很高，召回却差；如果报十个相关度很低的文件，也会因误选受罚。F1兼顾两头，适合衡量“定位了哪些文件”，但不会单独说明缺陷能否利用，更不能据此认为模型已经生成正确补丁。[1][4]
第二阶段换成修复后的仓库。模型应识别指定漏洞已不存在，其主要指标是真阴性率。这个设计贴近安全团队的日常困难：漏洞修好后，扫描器仍不停报同一个旧问题，开发者会花时间解释，最终还可能逐渐忽略警报。第二阶段的存在，让“能发现问题”与“知道何时别报警”同时接受检验。官方特别记录完成状态，以区分模型主动报告无漏洞、未提交答案，以及执行失败。[1] 三者若在统计时混成“空输出”，结果就会误导。
举一个不涉及真实攻击操作的工作例子：仓库升级了依赖包，函数名仍在，但校验流程改由新模块承担。只按关键词搜索的智能体可能看到旧函数就继续标红；查过调用关系和修复提交的智能体，可能判断最初的漏洞描述已不适用。VulnLoc的双阶段设置会把这种“看到名字就报警”的习惯暴露出来。它衡量的是指定任务条件下的定位与辨识，并非对生产系统整体安全性的认证。
让评测有可追问的条件
代理成绩很依赖环境。搜文件一次算不算工具调用？工具响应超时后能否重试？模型可阅读整个仓库还是只能访问子目录？思科说基准作者可以定义任务加载、可用工具、执行位置、答案提取与评分，并配置提示词、轮数、工具调用预算和超时；部署配置还能覆盖默认执行环境。[1] 当两次评测预算不同，数字上的差距未必归因于模型本身。
VulnLoc独立项目的默认说明包含每个任务15次终端调用、最多20轮生成等限制。[4] 这属于该项目公布的配置说明，具体跑在FAITH整合框架下仍应读取当次配置，不该把它误写成所有FAITH任务通用上限。企业内部复测最好把模型版本、温度、提示词、仓库提交、容器镜像摘要、工具配额、网络条件和重试策略一起存档。即使同一模型得分提高，也先确认是否换了任务样本或工具实现。
日志里的“终止原因”尤其能解释失败。一个智能体不提交答案，可能因为它选择谨慎，也可能是耗尽时间、命中工具预算或反复调用失败。FAITH把这类信息与提交结果分别保存，使评分者能把模型决策失败和平台执行失败分开。官方文档的快速起步流程建议先跑一个VulnLoc任务，检查日志和错误数，再扩大样本；单次命令成功退出并不代表评测设置正确。[1][3] 对评测平台而言，这是一条很朴素、但很少被排行榜呈现的纪律。
只读隔离不是装饰
思科介绍，VulnLoc可在本地Docker里运行受信任输入，或在Kubernetes中通过Agent Sandbox执行；仓库以只读方式提供给智能体。[1] 文档也要求自定义部署满足只读工作区条件。[3] 模型在评测时需要运行终端命令，这与普通语言问答的风险面不同。只读挂载减少它修改源代码、改变测试对象的机会；隔离运行则限制任务之间的相互影响。准备引入内部仓库的团队，还要决定容器能否访问公司网络、工具输出是否包含凭据，以及日志能保存多久。这些部署治理要求属于企业应用推演，不是FAITH自动替企业完成的承诺。
只读也让分数更可解释。假如模型一边检查一边更改待检文件，评测对象会变；两个模型即使面对同一初始提交，最后读到的仓库状态也可能不同。固定输入、限制写入、记录每步返回，才能把“哪一步导致误判”追到具体证据。外部模型API处理内部源代码时还涉及数据流转审批，评测者不能因为任务跑在本地容器中，就默认代码没有离开企业边界。
企业怎么复用这套思路
第一步选一批已经人工核定的真实问题，保留修复前后两个版本，去除秘密和不必要的客户信息。标注受影响文件及依据，约定多文件漏洞怎样判分。不要只选答案藏在文件名里的简单样本，最好纳入重命名、依赖升级和补丁跨模块的情况；同时为无漏洞仓库准备充足的阴性样本。
第二步锁定任务权限。先只读、离线、有限工具预算，记录模型请求、工具结果和版本号；观察代理最常在哪一类任务上耗时、重复搜索或漏报。基准报告分开列出文件集合F1、修复后真阴性率、未完成率、错误率、平均工具次数，以及人工复核一条告警所需的时间。这些指标从不同方向衡量业务价值，不能揉成一个含糊的“安全能力分”。
第三步才谈接入研发流程。低风险的第一站可以是代码审查提示或升级后的旧漏洞复查，输出附带文件路径与可核对证据，由人确认后进入工单。若希望代理修改仓库，要另设能写入的隔离环境和补丁验收指标；VulnLoc的只读定位成绩无法代替自动修复测评。上线后将误报案例回灌到评测集，按月检查回归，但要把训练数据污染和历史样本泄漏单独考虑。
思科的FAITH GitHub 1.0.0发布记录列出代理评测核心、工具注册、Docker与Kubernetes环境、VulnLoc整合和已完成任务的检查点机制等改动。[5] 检查点允许长评测中断后在任务边界恢复已完成结果，减少重复调用费用；前提是存储还在，且复用条件匹配。研究人员若修改任务定义、仓库快照或评分器，应另开实验，避免把两种条件混成一次“续跑”。[1]
安全智能体面对不完整线索时的行动过程，和最后提交的文件名一样需要检验。Agentic FAITH目前给出的，是一套把动作、错误和停止条件纳入成绩解释的工具链；首个VulnLoc基准让修复前后的判断同时落到可衡量的指标上。评测平台可以帮助团队看清模型在哪里失败。是否准许代理接触真实系统、是否接受它的发现并采取行动，仍要由企业自己的权限设计和复核流程决定。
当分数相同，逐条日志会讲出不同的故事
设想甲乙两个智能体在十个修复前仓库里都找对八个，表面成绩相近。甲先看漏洞描述，定位相关包，再读调用链，提交两个文件；乙把整仓库的文件名扫过一遍，频繁碰到终端预算上限，最后也报了两个名字。如果只保留提交文件，管理者可能把它们当成同一水平。逐轮记录工具入参、返回和结束原因后，差别就能被复核：甲在明确证据上停下，乙离预算耗尽只差一步。面对一个更大的私有仓库，后者的行为更需要预警。这里是假设性的解释示例，并非官方给出的两款模型结果。
对修复后的样本还应再看一次。能在修复前找到问题、修复后继续报同一文件的代理，可能在组织内产生大量重复工单；修复后从不报警、修复前也经常漏掉的代理，则会拿到看似不错的阴性结果。两阶段指标必须并列读，连同未完成任务的比例一起展示。工单系统里还有一项容易被忽略的成本：开发者为逐条确认模型告警花费的时间。企业评估时可以随机抽取若干条模型报告，让不同审查者按同一规则复核，记录分歧原因；若连人类标注者都无法达成一致，就不应要求模型给出单一的绝对分数。
为了减少样本泄漏，需要把训练中可能出现的公开修复与内部新漏洞分层统计。公开GHSA样本适合建立可比基线，保密的历史缺陷可以检验迁移情况，但必须先走数据审批；内部测试不应未经授权发布有可利用细节的日志。每次基准升级，把新增样本和保留样本分开出报告，防止某个版本只因见过旧题而显得更强。给仓库附上提交哈希和修复日期，也方便后来追查一项任务究竟测试了哪个状态。
安全运营还要给智能体设定停止条件和人工交接方式。预算耗尽时，代理应明确写出已查过的路径和尚未核实的文件，把任务交给人；工具报错时，应保留错误而非把“未检出”当成阴性；面对模糊漏洞描述，应说明需要哪一类补充证据。FAITH存储停止原因和工具记录，为这种交接质量的检查提供基础数据。[1] 但平台保存记录不等于已经实现人工审批、访问控制或证据保全，后几项仍需企业在自己的工单与审计系统里落实。
参考资料
- Cisco Foundation AI, Introducing Agentic Evaluation in FAITH，2026-10-23（架构、VulnLoc两阶段、执行记录与环境）。
- Cisco Foundation AI, FAITH official documentation（统一命令管线及支持后端）。
- Cisco Foundation AI, Agentic FAITH quickstart（运行条件、只读要求、结果检查）。
- Cisco Foundation AI, Vulnerability Localization Benchmark repository（样本构成、两阶段、独立项目默认预算；项目README数据应另行按具体快照核验）。
- Cisco Foundation AI, FAITH 1.0.0 release notes（代理框架、隔离执行与检查点实现线索）。
配图为概念示意；企业实施建议为编辑分析，未声称已运行模型或复现基准成绩。