Multiverse Computing发布ProvenanceGuard：为MCP智能体做来源级事实核查
论文针对“跨来源混淆”——事实在证据池里存在、却被归到错误来源——提出后置验证层，在医疗智能体 361 条陈述测试中拦下专家认为不应通过的 139 条中的 138 条。
AI解读：ProvenanceGuard要解决的是MCP智能体一个容易被忽视的错误：事实本身没错，但被安到了错误的来源头上。比如客服机器人说“根据账户记录，本方案含 30 天退款期”，退款期可能是真的，却写在一份政策文档里，而不是它声称的账户记录。传统核查工具把证据合并成一个池子看，只要池子里有这条事实就放过，区分不出这种来源错配。
做法是不把工具输出揉成一团，而是顺着MCP调用轨迹保留每个输出的来源ID，逐条拆出答案中的陈述，找到最相关的来源，判断它是否真的支持该陈述，再和答案里明示或暗示的来源比对，最后给出逐条来源判定和整段答案的允许或拦截。被拦下的答案可以走RARR式修复再复核。论文用的本地模型组合不是硬性要求，换成云端托管模型需要重新测试和校准。
实测结果是这次最值得看的部分：医疗智能体 281 条真实轨迹、40 条答案中的 361 条陈述，专家判定 139 条不应通过，系统抓住 138 条；代价是把 67 条专家认为有支持的陈述也送去了复核或修复。在能识别来源的陈述里，选对来源的比例约 86%。和MiniCheck、RAGAS Faithfulness等只给二值结论的基线相比，它多了逐条来源记录。
局限也写得很直白：多个相似来源放在一起时，该拦哪些陈述的F1是 0.846，但精确指出是哪个来源只有 50.3%，官方称这是需要改进的方向。另外在被拦截答案的修复中，整轨迹运行有 144 条最终落到兜底文本而不是实质重写，等于选择回避而不是编造。对需要留痕、可复核的数据敏感场景，这种保守策略是有意为之；不追求最快出答案的普通场景则未必值得。
Multiverse Computing在Hugging Face博客发布论文《ProvenanceGuard: Source-Aware Factuality Verification for MCP-Based LLM Agents》，提出针对MCP智能体的来源感知事实核查方案，同时可在Hugging Face或arXiv上阅读全文。
论文针对的失败模式被命名为“跨来源混淆”（cross-source conflation）：一条陈述在证据中某处为真，却被归因到错误的来源。来源不敏感的核查器会因为该事实确实存在于合并后的证据池中而放行，来源感知的核查器则不应放行。
什么是来源不敏感核查漏掉的问题
博客给出的例子是一个客服智能体回答“根据账户记录，这个方案包含 30 天退款期”。退款期本身可能完全真实，但表述来自政策文档，而非答案所指的账户记录。把两者合并在一起，该陈述看起来有支持；把它们分开，归因就是错的。在数据敏感场景中，错误归因可能与错误事实同样有害。
同样的模式也出现在临床智能体中：从患者病史工具取来的患者特定用药细节，一旦被答案当作医学文献中的发现来呈现，就会产生误导。一条陈述可以由某个MCP来源支持，而答案却将其归因于另一个来源。
论文指出，从RAGAS faithfulness到MiniCheck、AlignScore、SummaC等细粒度核查器，通常的提问方式是：证据被汇总到一起后，某条陈述是否得到支持。它们在通常形式下不会说明哪个MCP工具输出支持了哪条陈述，也不会说明那是否是答案所指定的来源。
ProvenanceGuard的五个步骤与本地模型配置
ProvenanceGuard是一个后置生成验证层，运行在黑盒MCP智能体之上。它在智能体产出答案之后运行，不会把证据压缩成一个匿名上下文，而是让来源身份贯穿整个流程，读取捕获的MCP轨迹（包括工具输出及其来源ID），无需重新训练智能体。
它依次做五件事：把答案拆成具体陈述；为每条陈述找到最相关的来源；核查该来源是否真的支持它；把该来源与答案中明示或暗示的来源进行比较；最后输出逐条陈述的来源判定，以及整段答案级别的允许（allow）或拦截（block）决定。被拦截的答案可经过RARR式修复并重新验证。
论文实验使用的是本地模型，以便在受控的离线环境中处理捕获的轨迹：MiniLM帮助找到相关来源，DeBERTa NLI验证模型检查该来源是否支持陈述，一个本地语言模型帮助把答案拆分成陈述。验证器还会严格检查字面值：数字、日期或标识符如果不在来源中，不能仅因为句子听起来合理就通过。一个经过校准的决策步骤综合这些信号。
博客强调，这些模型是论文评估时使用的配置，不是ProvenanceGuard的必要条件。相同的陈述、来源和决策步骤可以适配到托管模型，但新配置需要自己的测试和校准；报告的结果来自本地配置。其保守的决策策略适合数据敏感复核，即把来源弄对比尽快出答案更重要。
医疗智能体测试：361 条陈述中的 138/139
测试对象是一个使用患者记录、研究文章和其他工具的医疗智能体，共 281 条真实轨迹。博客解释医学是有用的测试领域，因为来自患者记录的事实和来自一般研究的事实不能当作同一来源；该方法也可用于其他领域，只要智能体保留了工具输出和来源ID的记录。
主测试中，人类专家核查了从开发数据中留出的 40 条答案里的 361 条陈述。专家认为其中 139 条不应通过，ProvenanceGuard抓住了 138 条，放过了 1 条；同时它扣下了 67 条专家认为有支持的陈述，将其送去复核或修复。博客说明这反映了测试时的谨慎设置：宁可让部分有支持的陈述被二次检查，也不让无支持的陈述通过。
对于有可识别来源的陈述，该测试中选对来源的比例约为 86%。论文用自身指标衡量系统在抓出应拦截陈述的同时避免不必要拦截的能力，ProvenanceGuard得分最高，Verifier Reject/block F1为 0.802，高于MiniCheck的 0.783、RAGAS Faithfulness的 0.758、AlignScore的 0.662 和SummaC-ZS的 0.436。对比中的其他核查器都不会给出哪条工具输出支持哪条陈述，ProvenanceGuard记录了这一联系。
- ProvenanceGuard：Reject/block F1 0.802，输出陈述到来源ID
- MiniCheck：0.783，不输出
- RAGAS Faithfulness：0.758，不输出
- AlignScore：0.662，不输出
- SummaC-ZS：0.436，不输出
相似来源、错误归因与修复结果
在另一个更难的、包含多个相似来源的测试中，ProvenanceGuard决定拦截哪些陈述的F1为 0.846，但精确识别正确来源的比例只有 50.3%。博客称区分相似来源仍是重要的改进方向。
团队还做了一项聚焦错误归因的受控测试：在保留支持证据不变的情况下，把 50 个案例中答案指定的来源改掉，ProvenanceGuard全部 50 个替换都抓到了。博客认为这说明它能检测明确的来源错误，而更难的那个测试则显示了在多个看似合理的来源中做选择的挑战。
修复方面，接入RARR式修复循环后，完整轨迹运行解决了全部 173 条被拦截的答案，但其中 144 条最终落到兜底文本而非实质性重写——即系统选择回避无法验证的答案，而不是编造一个。在重建的多来源测试轨迹上，一次新的修复运行解决了全部 59 条最初被拦截的答案，其中只有 2 条最终兜底。
作为离线闸门，在报告的本地配置下开销不大：每条答案约半秒，NLI和路由调用本身在数十毫秒量级。
与Multiverse Computing的关系及NVIDIA NVFlow的采用
博客称，随着智能体从单段落RAG转向多工具MCP配置，一条事实究竟来自哪个来源不再只是脚注，而成为事实性含义的一部分。对Multiverse Computing来说，这意味着一种核查现有智能体的方式，并在需要时把敏感轨迹保留在受控环境中。医疗研究是一个用例，只要智能体的轨迹保留了工具和来源，同样的方法可以适配到别处。
这种适配已经出现在NVIDIA NVFlow中：它为金融智能体合并了一个可选的grounding验证阶段，用智能体检索到的SEC摘录核查已完成答案并保存独立决策，而不改变原始rollout或训练数据。博客说明，NVFlow的工作使用了ProvenanceGuard的来源感知验证方法，而上述修复循环属于更广泛的研究系统。
ProvenanceGuard还在加州大学伯克利分校的Agentic AI Summit 2026上以海报形式展示。博客邀请读者阅读Hugging Face上的完整论文，或联系团队讨论把来源感知验证应用到自己的智能体上，论文包含路由和NLI推导、校准消融、多来源压力切片及完整结果表。