Multiverse 开源 ProvenanceGuard：专治智能体「引错源」
Multiverse Computing 9 月 29 日在 Hugging Face 博客发布 ProvenanceGuard，并放出论文《ProvenanceGuard: Source-Aware Factuality Verification for MCP-Based LLM Agents》。它针对的失败模式叫「跨源混淆」（cross-source conflation）：一条断言在证据池里确实为真，却被归到了错误的来源上。典型例子是客服智能体说「按账户记录，这个套餐有 30 天退款期」——退款期是真的，只是写在政策文档里、不在它援引的账户记录里；把两份材料混进同一个上下文，「有支持」就成立了。这在数据敏感场景里和事实错误一样有害。
做法是一层事后核查：不改动智能体本身，而是读它被捕获的 MCP 调用轨迹（含工具输出与各自的 source ID），按顺序做五件事——把答案拆成一条条具体断言、为每条找最相关的来源、判断该来源是否真的支持它、比对「答案声称或暗示的来源」与「实际支持的来源」、最后给出每条断言的来源裁定，以及整条答案放行还是拦截。关键设计是它从不把证据揉成一个匿名上下文，而是让来源身份一路带着走。作者也把话说清：RAGAS faithfulness 到 MiniCheck、AlignScore、SumaC 这类检查器问的是「这条断言有没有被支持」，它们的常见形态不回答「是哪个 MCP 工具的输出在支持它、那是不是答案点名的那个来源」。
结果：在同一批留出断言上，专家认为 139 条不该通过，它拦下 138 条、放过 1 条；同时把 67 条专家认为成立、但来源容易混的断言送进复核或修复队列——作者说这是刻意偏保守的设定，宁可让一些成立的断言多看一眼，也不放不该通过的过去；对有可识别来源的断言，它挑对来源的比例约 86%。这条的价值在于把「忠实度」这个笼统概念对 MCP 智能体做了拆分：答案携带来源，而来源对不对是可以单独判的——这也正是把核查层做在智能体外面的理由。