MCP Agent开始核验来源：答案正确还不够，证据链也要经得起追问

AI Agent 的检索验证正在从“答案对不对”转向“这句话到底来自哪里”。最近，Hugging Face 上发布的文章《Getting the Source Right, Not Just the Fact: Source-Aware Verification for MCP Agents》提出了一个值得工程团队重视的方向：让基于 MCP 的 Agent 不只验证最终事实，还要验证支撑事实的来源、引用和证据链。

这不是给回答末尾自动加几个链接那么简单。Source-Aware Verification 是一种来源感知验证机制，指 Agent 在生成结论时同时检查事实内容与证据来源之间是否存在真实、有效、可追溯的支持关系。

对开发者来说，变化的重点在于：以后一个 Agent 说“答案正确”，并不代表任务完成。它还需要回答三个问题——这个结论对应哪条原始材料？引用的材料是否真的支持这句话？这份材料在当前时间、权限和业务上下文中是否仍然可信？

从验证答案，到验证答案的来路

传统 RAG 或搜索型 Agent 的验证，通常围绕一个问题展开：模型给出的答案是否符合检索到的文本。Source-Aware Verification 则把验证对象拆成了两层：一层是 claim，也就是回答中的具体主张；另一层是 provenance，也就是这条主张的来源和生成路径。

**主张（claim）是可以被单独判断真假的最小陈述单元。**例如，“某个 SDK 在 2026 年 8 月发布了 2.1 版本”是一条主张，而不是一整段回答。把长回答拆成多个主张后，系统才能逐条判断哪些内容有证据、哪些内容只是模型补全。

**来源溯源（provenance）是记录一条信息从原始来源到最终回答所经过路径的机制。**它不仅包括网页 URL，还可能包括文档版本、仓库 commit、文件路径、检索时间、工具调用结果、权限范围以及中间转换过程。

这一区别很关键。一个回答可能在字面上是正确的，但引用关系是错的：模型从一篇讨论旧版本功能的文章中，拼出了新版本的结论；或者搜索结果摘要里出现了某个数字，模型却把数字归因给页面正文中并不存在的段落。最终答案看起来没有明显错误，但读者无法复核，系统也无法证明它是怎么得出的。

更麻烦的是，检索系统经常会把“相关”误判成“支持”。一篇文章谈到了某个产品，并不意味着它能证明该产品具备某项能力；一个 GitHub issue 提到某个 bug，也不意味着官方已经确认了修复方案；搜索摘要包含关键词，更不代表原文支持模型生成的完整判断。

因此，来源验证需要把下面几种关系分开：

| 检查对象 | 要回答的问题 | 常见失败方式 | |---|---|---| | 事实一致性 | 回答中的内容是否与材料相符？ | 数字、时间、版本号被模型改写 | | 引用支持性 | 引用材料是否真的支持这条主张？ | 相关页面被误当成证据页面 | | 来源权威性 | 材料是否来自适合该问题的权威来源？ | 博客转载替代官方文档 | | 来源新鲜度 | 材料是否仍处于有效时间范围？ | 用旧 API 文档回答新版本问题 | | 来源完整性 | 是否遗漏了限制条件和反例？ | 只引用成功案例，不提权限限制 | | 证据可追溯性 | 其他人能否复现检索和判断过程？ | 只有 URL，没有段落和版本信息 |

MCP 为什么适合承载来源验证

**MCP（Model Context Protocol）是让模型以统一方式发现并调用外部工具、数据源和上下文的协议。**它解决的是 Agent 如何连接文件系统、代码仓库、搜索服务、数据库和知识库的问题，但协议本身并不会自动保证返回内容可靠。

这正是 Source-Aware Verification 的切入点。MCP 工具不应该只返回一段适合模型阅读的文本，还应该返回足以验证来源的结构化元数据。例如，一个知识库搜索工具除了返回内容，还可以提供：

• 原始来源的稳定标识和 URL；
• 文档标题、作者、发布日期和最后更新时间；
• 文档版本、仓库分支或 commit；
• 命中的段落、页码、行号或代码范围；
• 检索时使用的查询词和过滤条件；
• 内容是否经过截断、摘要或二次生成；
• 数据源的权限状态和同步状态。

换句话说，MCP Server 不应只把结果包装成“模型可以读的文本”，还要把结果包装成“人和系统可以审计的证据”。

对于研发场景，这一要求尤其实际。Agent 如果回答“这个函数会导致竞态条件”，那么有价值的引用不应该只是仓库首页，而应当指向具体文件、函数、代码行和对应调用链。如果它建议修改配置，则需要说明结论来自哪个版本的配置文档，不能把旧分支的设置直接套到当前生产环境。

这也解释了为什么只在 prompt 中告诉 Agent “请给出可靠来源”通常不够。Prompt 可以要求格式，却很难保证底层工具真的提供了来源信息，更无法阻止模型在没有证据时编造看似合理的引用。来源验证必须进入工具返回结构、检索策略和运行时策略，而不是停留在提示词层面。

一条可落地的 Source-Aware Verification 流程

一个可用的来源感知 Agent，至少需要把检索和回答拆成几个相互独立的阶段。

1. 先把问题拆成可验证主张

Agent 首先不应急着生成完整答案，而是判断用户问题包含哪些需要证据支撑的陈述。例如，“比较三个模型的上下文长度、价格和代码能力”至少包含三类主张：参数主张、价格主张和能力主张。

不同主张需要不同来源。价格最好查官方定价页，模型能力可以参考官方技术报告和可复现评测，实际代码表现则应引用测试环境、数据集和评测版本。把所有结论交给同一个搜索结果集合，是来源错配的主要来源之一。

2. 选择来源，而不是只选择文档

**来源选择是根据主张类型、权威性、时效性和可访问性，为每条主张匹配证据的过程。**生产环境中的路由策略，至少应考虑数据源、更新时间、地区、成本、延迟、认证状态和允许操作。

一个简单的优先级通常是：官方文档和公告优先于官方代码仓库，官方代码仓库优先于维护者说明，经过复现的社区资料优先于未经验证的转载内容。对于价格、版本、兼容性等容易变化的信息，来源新鲜度的重要性可能高于文章的长短和搜索排名。

3. 进行证据—主张对齐

检索到材料后，验证器需要判断证据是否真正支持主张，而不是只做关键词匹配。最简单的判断可以分为三类：支持、反驳和无法判断。

例如，文档写的是“支持流式输出”，可以支持“该版本支持流式输出”；但不能自动支持“流式输出在所有工具调用场景下都可用”。如果原文附带“仅限实验性接口”或“需要额外权限”，这些限制也必须进入最终结论。

这一步实际上接近自然语言推理中的蕴含判断，但工程上更重要的是保守。证据不足时，系统应返回“当前材料无法确认”，而不是利用模型常识补齐缺口。

4. 检查来源的时间和版本

版本错配是 Agent 检索中最容易被忽略、又最容易造成实际事故的问题。一个页面可能在搜索引擎中仍然排名靠前，但对应的 SDK 已经在几个月前改变了参数和行为。

因此，验证器应把“来源版本”作为一等字段处理。对于代码仓库，commit、tag 和分支比仓库 URL 更有意义；对于在线文档，发布日期、更新时间和文档版本比页面标题更有意义；对于新闻和产品动态，事件发生时间与页面更新时间也不能混为一谈。

5. 输出带边界的答案

可信回答不等于引用数量最多的回答。理想输出应该让读者知道：哪些结论已被来源直接证实，哪些是多份材料综合后的推断，哪些问题仍然缺乏足够证据。

Agent 可以把最终结论分成“已验证”“部分验证”和“未验证”三类，并在每条主张后附上最小充分引用。这样做比在文章末尾堆几十个链接更有用，因为读者能够快速判断每个结论的证据强度。

MCP Agent 的评测指标也要换一套

过去评估检索 Agent，常看答案准确率、召回率、引用率和响应时间。但在来源感知场景下，这些指标不够用了。

**来源支持率是被引用来源真正支持的主张数，占全部可验证主张数的比例。**它比“回答中包含链接的比例”严格得多。一个答案有十个链接，但只有三个链接真正支持对应结论，引用率看起来很高，来源支持率却只有 30%。

还可以增加以下指标：

| 指标 | 含义 | 适用场景 | |---|---|---| | 主张覆盖率 | 有明确证据支撑的主张占比 | 长报告、研究型问答 | | 来源支持率 | 引用真正支持主张的比例 | 搜索与 Deep Research | | 权威来源率 | 引用中达到来源等级要求的比例 | 技术文档、合规问答 | | 版本匹配率 | 来源版本与问题目标版本一致的比例 | SDK、框架、代码 Agent | | 过时引用率 | 使用超过有效期材料的比例 | 新闻、价格、产品能力 | | 无证据断言率 | 没有证据却被明确陈述的主张比例 | 高风险业务问答 | | 证据定位成功率 | 用户能否定位到具体段落或代码范围 | 研发协作和审计 |

这些指标能直接暴露一些传统评测看不见的问题。比如，某个 Agent 的最终答案准确率达到 85%，但来源支持率只有 52%，说明它可能经常“答对了，但引用错了”。在金融、医疗、法律和生产代码场景中，这种系统仍然不够可靠。

对 Agent 架构的影响：检索工具要返回证据对象

来源感知验证会推动 MCP 工具从“文本接口”变成“证据接口”。一个成熟的搜索工具，返回结果时至少应区分原始内容、定位信息和生成内容，避免把摘要与原文混在一起。

从架构上看，可以将系统拆为四层：

1. 数据源层：官方文档、代码仓库、内部知识库、数据库和网页。
2. MCP 能力层：负责搜索、读取、过滤、版本查询和同步状态检查。
3. 验证层：负责主张拆分、证据对齐、来源打分、冲突检测和时效判断。
4. 回答层：负责生成结论、展示引用、标注不确定性和记录审计轨迹。

这种拆分的好处是，回答模型可以更换，验证策略也可以独立升级。企业不必因为换了一个模型，就重新相信一套无法解释的引用结果。

在代码知识库中，工具可以提供类似 kb_search、kb_read_page、kb_sync_status 的能力：前者检索候选材料，中者精确读取来源页面或代码范围，后者确认知识库是否处于最新同步状态。重点不在于工具名字，而在于它们是否能返回可复核的证据和状态。

另一个重要原则是把读取和执行分开。业务问答、逻辑确认和代码分析可以默认只读；创建 worktree、修改文件、提交 MR 或触发部署，则必须进入更严格的执行链路。只有当 Agent 能说明修改依据、引用代码位置并通过验证，才适合进入下一步。

这不是“多放几个引用”

Source-Aware Verification 最容易被误解成引用格式升级，但它真正改变的是 Agent 的决策方式。

第一，它会让 Agent 在证据不足时主动停下来。当前很多系统把“没有找到答案”视为失败，于是模型会根据相似材料进行推断。来源感知机制则允许“不确定”成为正常输出，甚至把补充检索请求交还给用户。

第二，它会让来源冲突变得可见。当官方文档、代码实现和社区讨论说法不一致时，系统不应随意选择一条，而应报告冲突、标注版本并说明采用某个来源的理由。

第三，它会让搜索成本变得可管理。不是所有问题都需要深度研究。对已验证且未过期的来源，可以复用已有证据；对高风险或高变化主张，再提高检索和验证预算。这比让每次问答都重新调用多个搜索工具更有效。

第四，它会改善 Agent 的失败方式。一个无法定位证据的回答，比一个明确指出“当前材料无法证明该结论”的回答更危险。对开发者而言，后者反而更容易调试，因为系统暴露了证据链的断点。

仍然存在的三个难题

来源验证并不能自动解决事实真实性。第一方来源可能写错，官方文档也可能滞后，多个网站还可能互相转载同一个错误信息。因此，来源权威性只能提高可信度，不能替代交叉验证和实际测试。

第二个问题是主张拆分本身也可能出错。模型如果把一条复杂结论拆成过于宽泛的主张，验证器就会错误地认为证据充分；如果拆得过细，系统又会产生过高的检索成本。主张粒度需要结合领域和任务类型调节。

第三个问题是来源评分容易被形式化指标绑架。域名、发布时间和引用数量都可以作为信号，但不能简单加权后当作真相。一个最新的博客未必比三年前、但仍然有效的规范文档更可靠；一份官方营销材料也未必能证明实际性能。

所以，Source-Aware Verification 更像一套工程纪律，而不是一个可以一次部署的模型插件。它需要工具 schema、数据同步、权限管理、评测集、运行日志和人工反馈共同配合。

开发者现在可以怎么做

如果团队正在搭建 MCP Agent，不必一开始就实现复杂的自动审计系统，可以先从四个动作开始：

• **让每个检索结果携带稳定来源标识。**至少记录 URL、标题、更新时间、版本和命中片段。
• **把“回答”和“证据”分开存储。**不要让模型生成的摘要覆盖原始内容，也不要只保存最终文本。
• **为主张设置支持状态。**明确区分已支持、部分支持、冲突和无法判断。
• **用已知答案、无效输入、权限拒绝和超时四类测试检查工具。**一次成功调用不能证明 MCP 服务适合生产环境。

此外，还应建立一套小规模的来源评测集，专门收集版本错配、引用错位、搜索摘要误导、文档冲突和证据不足等案例。相比盯着单次演示效果，这些反例更能检验 Agent 是否真的具备来源意识。

判断：这是检索 Agent 走向生产的必要一步

MCP 让 Agent 更容易接触外部世界，但连接能力越强，错误来源带来的风险也越大。一个能查到十个系统、调用五种工具的 Agent，如果无法解释每条结论从哪里来，实际上只是把不可见的不确定性扩散到了更多业务环节。

Source-Aware Verification 的价值，不是让每个回答都变成长篇论文，而是把“相信模型”改成“检查证据”。它把来源、版本、时间、权限和主张之间的关系显式化，也让检索系统拥有了可度量、可回放、可修复的失败路径。

对 MCP Agent 来说，下一阶段的竞争点不会只是能连接多少工具、能检索多少文档，而是谁能在低延迟和可控成本下，稳定交付一条经得起复核的证据链。答案正确是起点，来源正确才是生产可用性的门槛。

参考来源

• Getting the Source Right, Not Just the Fact: Source-Aware Verification for MCP Agents：本文讨论 Source-Aware Verification 如何扩展 MCP Agent 的事实核验能力。
• 一文读懂：大模型 Deep Research 背后的技术原理：介绍 Deep Research 中的检索、证据链和迭代验证思路。
• Agent Search MCP 产品架构研究：讨论本地优先、证据优先和 Token 预算下的搜索策略层设计。
• MCP 集成指南：将 AI Agent 连接到工具：补充 MCP 工具发现、权限、Schema 检查和连接测试实践。