当 Agent 能调用工具、检索网页、读写文件时，验证的重点正在从“答案对不对”转向“答案是从哪儿来的”。
发生了什么
Hugging Face 上出现了一篇题为《Getting the Source Right, Not Just the Fact: Source-Aware Verification for MCP Agents》的工作，主题是面向 MCP（Model Context Protocol）Agent 的“来源感知验证”。从标题即可读出其核心主张：在验证 Agent 输出时，不能只检查事实是否成立，还要检查该事实是否来自正确的来源。
MCP 是让模型以统一协议连接外部工具与数据源的接口层。当 Agent 通过 MCP 调用搜索、数据库、文件系统或企业内部 API 时，它拿到的是一段段带来源的上下文。问题在于，现有验证流程大多只对最终答案做事实核查，而很少追问“这条信息究竟出自哪个工具、哪个文档、哪个版本”。
为什么重要
Agent 的错误往往不是凭空编造，而是来源错位。模型可能把 A 文档的结论安到 B 文档头上，把旧版本的数据当成最新值，或把某个工具返回的片段与另一个工具的上下文混在一起。这类错误在单轮问答里不明显，但在多步、多工具的 Agent 工作流中会被不断放大——每一步都“看起来有依据”，最终结论却建立在错误的来源链上。
传统的事实核查之所以不够，是因为它默认来源是给定的、可信的、唯一的。而在 MCP 场景下，来源本身就是一个需要被验证的对象：工具是否真的返回了这段内容？返回的内容是否被完整、无篡改地引用？引用的来源是否与当前任务相关？把验证前移到来源层，等于在事实核查之前先做一次“引用溯源”。
影响与看点
对开发者而言，这意味着 Agent 的评测与护栏需要增加一类新指标：来源一致性。它不只是准确率，而是“结论—引用—工具返回”三者能否对齐。对使用 MCP 构建企业级 Agent 的团队来说，来源感知验证直接关系到审计与合规——当 Agent 给出一个业务判断时，能否指出它依据的是哪次工具调用、哪份文档。
值得关注的还有它与现有可观测性工具的关系。日志和 trace 记录了工具调用，但记录不等于验证；来源感知验证要做的是在 trace 之上建立可判定的对齐关系。这可能会催生新的中间件层：在 Agent 与工具之间拦截、标注并校验来源。
一个独立判断：Agent 可信度的瓶颈，正在从模型能力转移到来源治理。谁能把来源链做扎实，谁才敢让 Agent 真正进入生产环境。
