ProvenanceGuard：为 MCP 智能体核查结论的来源归属

问题：事实在某处成立，不等于它来自答案所指的来源

MCP 智能体会同时调用搜索工具、结构化的患者或账户记录、数据库和元数据，再把多路输出合成一个答案。常见的忠实度检查（如 RAGAS Faithfulness、MiniCheck、AlignScore、SummaC）通常先把证据合并成一个整体，再判断结论是否有证据支持，因此无法说明每条结论由哪个工具输出支持，也无法判断这是否就是答案所声明的来源。

论文把这种失效称为跨源混淆：一条结论在证据池中确实成立，却被归到错误的来源。例如答案称“根据账户记录，该方案有 30 天退款期”，退款期可能真实存在，但出自政策文档而非账户记录。在医疗场景中，把患者病史工具里的用药细节表述成文献发现，同样会产生误导。

方法：保留来源身份的后置核查层

ProvenanceGuard 是运行在黑盒 MCP 智能体之上的后置验证层。它不重新训练智能体，而是读取捕获的 MCP 轨迹（含工具输出与来源 ID），按顺序完成五步：拆分答案中的结论、为每条结论找到最相关的来源、判断该来源是否真正支持它、比对来源与答案明示或暗示的来源，最后输出逐条来源判定和答案级放行或拦截决定。

论文实验采用本地模型：MiniLM 负责来源路由，DeBERTa NLI 验证器判断支持关系，本地语言模型负责结论拆分，并对数字、日期、标识符等字面值做严格检查；被拦截的答案可经 RARR 式修复后再次验证。作者说明这些模型是本次评测的配置而非必需条件，换用托管模型需要另行测试和校准；其保守策略适合对来源准确性要求高于响应速度的数据敏感场景。

结果（均为论文自报条件）

• 医疗智能体真实轨迹 281 条；主测试由人类专家核查 40 个答案中的 361 条结论。专家认为应拦截 139 条，系统拦下 138 条；同时把 67 条专家认为有支持的结论送去人工复核或修复。可识别来源的结论中，约 86% 选对了来源。
• 在论文的拦截 F1 指标上为 0.802，高于 MiniCheck 0.783、RAGAS Faithfulness 0.758、AlignScore 0.662、SummaC-ZS 0.436；只有它输出逐条结论到来源 ID 的对应。
• 多相似来源的更难测试中，拦截 F1 为 0.846，但精确指认来源仅 50.3%。在 50 例保留证据、仅改动署名来源的受控测试中，50 例全部被检出。
• 接入修复循环后，全轨迹运行解决了全部 173 个被拦截答案，其中 144 个以回退文本收尾；重建多源轨迹上的新修复运行解决 59 个，仅 2 个终态回退。作者报告的本地配置开销约每条答案半秒，NLI 与路由调用本身为数十毫秒。

作者在评论中回应称，论文未与更廉价的“源感知 LLM 裁判”做直接对比，并认为该对比值得进一步研究。NVIDIA NVFlow 的金融智能体已合并一个可选的 grounding 校验阶段，采用该来源感知验证思路；RARR 式修复属于更广的研究系统。

边界

方法依赖智能体保留工具输出与来源 ID 的轨迹；作者未给出部署步骤，也未验证托管模型配置的效果。