溯源正确，而非仅事实正确：面向MCP智能体的来源感知验证

大模型智能体（Agent）的“事实核查”正在暴露一个被忽视的盲区：答案里的每句话也许都真实存在，但可能被安到了错误的来源头上。HuggingFace博客近日刊出的一篇论文介绍，研究团队来自MultiverseComputingCAI，提出了名为ProvenanceGuard的来源感知验证方案，专门针对基于MCP（模型上下文协议）的智能体。 事情的背景是，如今调用工具的LLM智能体早已不是只读一段检索文本。通过MCP，智能体可以同时调用搜索工具、查看结构化的患者或账户记录、查询数据库、拉取元数据，再把所有信息编织成一个答案。这让“事实性”的判断变得比表面复杂得多。现有的核查系统，从RAGAS的忠实度评分到MiniCheck、AlignScore、SummaC等细粒度检查器，问的都是“这句话在现有证据里有没有支撑”，而证据是被汇总到一起的。它们通常不会告诉你，到底是哪个MCP工具的输出支撑了这句话，也不会核对这是否就是答案所声称的来源。研究团队把这种失败模式称为“跨来源混淆”：一句话在证据池里某处是真的，但被归因给了错误的来源。来源盲区的验证器会放行，因为事实确实存在于池子里；而来源感知的验证器不应该放行。 举个例子，一个客服智能体回答“根据账户记录，该套餐包含30天退款窗口”。退款窗口可能完全属实，但它写在政策文档里，而不是答案所指的账户记录里。把两者混在一起，这句话看起来就有支撑；分开来看，归因就是错的。在数据敏感的场景下，错误的归因和错误的事实一样具有破坏性。同样的模式也出现在临床智能体中：一条来自患者病史工具的具体用药信息，一旦被答案说成是医学文献的发现，就会产生误导。 ProvenanceGuard的定位是生成后的验证层，架在黑盒MCP智能体之上。它在智能体产出答案之后运行，不会把证据坍缩成一个匿名的上下文，而是让来源身份贯穿整条流水线。它读取捕获的MCP调用轨迹，包括工具输出及其来源ID，无需重新训练智能体，然后依次做五件事：把答案拆解成具体的主张，为每条主张找到最相关的来源，检查该来源是否真的支撑它，把该来源与答案明示或暗示的来源做比对，最后同时输出逐条主张的来源裁决和答案级别的全局放行或拦截决定。被拦截的答案可以走RARR风格的修复流程并重新验证。论文中的实验使用了本地模型，以便在可控的离线环境中处理捕获的轨迹。 对做跨境电商的中国卖家和出海团队来说，这件事的现实意义在于：当你的客服、选品、合规或财务智能体开始同时调用多个数据源时，答案“看起来对”已经不够了。一条把平台政策说成店铺后台记录、把行业报告说成自家销售数据的回复，可能让你在纠纷、审计或平台合规审查中吃暗亏。来源感知验证提供的思路是，在智能体输出之后加一道核查，把每条结论和它真正的出处绑定起来，而不是只检查结论本身是否在某个角落成立。