获取正确的来源而非仅事实：面向 MCP 智能体的源感知验证方法

我们最新的论文《ProvenanceGuard：面向基于 MCP 的 LLM 智能体的源感知事实性验证》（可在 Hugging Face 上阅读，或暂时在 arXiv 上查阅）旨在填补这一空白。我们所关注的失败模式是一种称为“跨源混淆”的现象：即某项主张在证据中的某处为真，却被归因于错误的来源。源盲验证器可能会通过它，因为该事实确实存在于证据池中；而源感知验证器则不应通过。

问题在于：“在某处得到支持”并不等同于“由正确的来源得到支持”。

考虑一个客服智能体回答称：“根据账户记录，此计划包含 30 天退款窗口。”退款窗口可能完全真实，但它陈述于政策文档中，而非答案所指向的账户记录中。将两者混为一谈，该主张看起来得到了支持；若将它们分开，则归因错误，而在数据敏感的场景下，错误的归因可能与错误的事实一样具有破坏性。同样的模式也出现在临床智能体中，当从患者历史工具中提取的患者特定药物细节被答案呈现为来自医学文献的发现时，就会变得具有误导性。

一项主张可能由一个 MCP 来源支持，但答案却将其归因于另一个来源。源盲评分会在合并的证据中看到支持并予以通过；ProvenanceGuard 则单独检查支持来源是否与答案所述或暗示的来源匹配。来源：论文图 1。

这就是为什么忠实度分数（faithfulness scores）尽管有用，但对于 MCP 智能体而言仍不够用的原因。答案带有溯源信息，有时是显式的（如“根据账户记录”），有时是隐式的。ProvenanceGuard 保留了主张与来源之间的连接，以便进行检查。

ProvenanceGuard 的功能

ProvenanceGuard 是一个位于黑盒 MCP 智能体之上的生成后验证层。它在智能体生成答案后运行，且从不将证据坍缩为一个匿名上下文。相反，它将来源身份贯穿整个流程。它读取捕获的 MCP 轨迹，包括工具输出及其来源 ID，而无需对智能体进行重新训练。然后，它按顺序执行以下五项操作：将答案分解为具体主张，找到与每个主张最相关的来源，检查该来源是否实际上支持该主张，将来源与答案命名或暗示的来源进行比较，最后输出针对每个主张的来源判定以及全局的、答案级别的允许或阻止决策。

验证流程。来源身份在分解、路由、支持评分、归因检查和修复过程中得以保留，而非被合并。被阻止的答案可以通过类似 RARR 的修复步骤进行修复并重新验证。来源：论文图 2。

有几个设计选择值得指出。在我们论文的实验中，我们使用了本地模型，以便在受控的离线环境中处理捕获的轨迹：MiniLM 用于查找相关来源，DeBERTa NLI 验证器模型用于检查该来源是否支持该主张，本地语言模型用于帮助将答案分解为主张。验证器还仔细检查字面值：如果数字、日期或标识符在来源中缺失，仅凭句子听起来合理是无法通过的。经过校准的决策步骤会结合这些信号。如果答案被阻止，类似 RARR 的修复步骤可以尝试基于来源的修订或安全回退，随后验证器会再次对其进行检查。

那些命名的模型是我们评估的配置，并非 ProvenanceGuard 的要求。相同的声明、来源和决策步骤可以适应托管模型，即团队更倾向于使用云服务的情况；新的配置需要其自身的测试和校准。我们报告的结果来自本地配置。其保守的决策策略适合数据敏感审查，在这种场景下，确保来源正确比生成尽可能快的答案更为重要。

结果

我们在一个使用了患者病历、研究文章和其他工具的医疗代理生成的答案上测试了 ProvenanceGuard。这为我们提供了 281 个真实轨迹供研究。医学是一个有用的测试领域，因为来自患者病历的事实和来自一般研究的事实不能被视为同一来源。当代理保留其工具输出和源 ID 的记录时，该方法也可用于其他领域。在主要测试中，人类专家检查了从用于开发系统的数据中分离出来的 40 个答案中的 361 项声明。

最直接的结果是：专家称有 139 项声明不应通过，ProvenanceGuard 捕获了其中的 138 项。它让一项通过了。它还扣留了 67 项专家认为得到支持的声明，并将它们发送回审查或修复。这反映了我们测试的谨慎设置：它倾向于对某些得到支持的声明进行二次查看，而不是让未得到支持的声明通过。对于具有可识别来源的声明，在此测试中，它也大约 86% 的时间选择了正确的来源。

我们在相同的声明上运行了另外四种支持检查器。ProvenanceGuard 在论文衡量系统阻止应被阻止的声明同时避免不必要阻止的效果方面得分最高。此次比较中的其他检查器并未告诉我们哪个工具输出了支持每个声明。ProvenanceGuard 记录了这种连接，因此审查者可以看到为每个声明检查的来源及其产生的决定。

相同预留声明包上的二元支持指标。ProvenanceGuard 在阻止方面匹配或优于源盲基线，同时还生成针对每个声明的源裁决。来源：论文摘要和表 III。

检查来源相似的声明

在另一个涉及多个相似来源的更困难测试中，ProvenanceGuard 在决定阻止哪些声明方面的 F1 得分为 0.846，但在 50.3% 的声明中正确识别了确切来源。区分相似来源仍然是需要改进的重要领域。

我们还运行了一个专注于错误归因的控制测试：我们在 50 种情况下更改了命名来源，而保留了支持证据不变。ProvenanceGuard 捕获了所有 50 次交换。这表明它可以检测出明显的来源错误，而更困难的测试则展示了在众多合理来源中进行选择的挑战。

修复被阻止的答案

如果对被阻止的答案有所作为，阻止才有用。连接到 RARR 风格的修复循环，完整轨迹运行解决了所有 173 个被阻止的答案，尽管其中 144 个以回退文本结束，而不是实质性重写，这是系统选择避免不可验证的答案，而不是制造一个答案。在重建的多源测试轨迹上，新的修复运行解决了所有 59 个最初被阻止的答案，只有两个终端回退。作为离线门控，开销适中，在报告的本地配置下，每个答案大约需要半秒时间，NLI 和路由调用本身仅需几十毫秒。

为什么这适合 Multiverse Computing

随着代理从单段落 RAG 转向多工具 MCP 设置，事实实际来自哪个来源的问题不再只是附注，而是成为事实性含义的一部分。ProvenanceGuard 逐声明地使这种来源连接可见。对于 Multiverse Computing 而言，这意味着一种检查现有代理的方法，同时在需要时将敏感轨迹保持在受控环境中。医学研究是一个用例； wherever an agent's trace preserves its tools and sources，同样的方法可以适应任何地方。

这种适应性已在 NVIDIA NVFlow 中初见端倪，后者为其金融代理合并了一个可选的接地验证阶段。该阶段将代理检索到的 SEC 摘录与已完成的答案进行比对，并保存独立的决策，而不改变原始的 rollout 或训练数据。NVFlow 的贡献采用了 ProvenanceGuard 的源感知验证方法；而上述修复循环则属于更广泛的研究系统。

ProvenanceGuard 也在加州大学伯克利分校举办的 Agentic AI Summit 2026 上作为海报展示。

想要获取完整的技术细节，包括路由和自然语言推理（NLI）推导、校准消融实验、多源压力切片以及完整的結果表格？请在 Hugging Face 上阅读全文，或与我们的团队联系，探讨如何将源感知验证应用于您自己的代理。