演示界面里，一个绿色构建的评估记分卡显示：检索（员工，样本数22）命中率1.00、召回率1.00、平均倒数排名1.00；拒答（样本数10）比率1.00（目标1.00）；泄漏0（必须为0）；脱敏0（必须为0）。评估门禁通过。

随后作者削弱了一项设置。两个环境变量把服务器的相关性门槛降到零，也就是对每个问题都返回最佳猜测而非承认无法回答。拒答比率跌到0.40，出现两条错误答案：客户退款政策被指向内部人力资源费用政策文档，办公室养狗政策同样被指向该文档。评估门禁失败，退出码为1，构建变红。没有人需要先注意到服务器开始编造内容，因为流水线先发现了。

打开网易新闻 查看精彩图片

为什么需要这道门禁

模型上下文协议让把知识库交给智能体变得异常容易。数百个服务器把笔记、维基和文档暴露为可搜索工具，大多数作为管道工作正常。但在让智能体依据公司手册回答问题之前，有三个管道从不回答的问题：返回的内容能否被信任？服务器返回片段时，智能体能否精确引用来源，让人可以核查？它是否知道自己不知道？

向知识库询问一个并不存在的政策，BM25仍会愉快地返回听起来最接近的笔记。被设定为信任工具的智能体，会把它变成一个关于不存在文档的自信答案。至于谁能看到什么，如果知识库有受限目录，搜索工具过滤掉那些结果并不是答案，而是事故报告的开端。

三个护栏与一个决定

作者构建了grounded-mcp：一个基于markdown文件夹的小型Python MCP服务器，Obsidian可直接使用，带三个护栏。每个承载内容的响应都携带稳定引用标识，包含路径、标题和行范围。搜索在没有任何内容越过相关性门槛时，明确且结构化地拒答。权限在索引层执行：某配置文件看不到的内容，从一开始就不会为其建立索引。

这些本身不值得写，除了一个决定：仓库自带评估套件，而套件就是CI门禁。这个决定在第一次运行时就收回了成本。

第一次诚实运行发现真实缺陷

评估套件针对一个提交的演示知识库运行四类测试：一个虚构公司手册，包含公开、内部和受限区域。四类分别是黄金检索集、答案故意不在知识库中的问题集、只能从受限内容回答的泄漏集，以及针对植入假凭据的脱敏检查。第一次运行：检索完美，泄漏为零，脱敏为零。拒答率0.30。十个无法回答的问题中有七个返回了自信的错误答案。

有趣的部分在于原因。作者原本假设BM25分数阈值能把真实答案与貌似合理的噪声分开。数据显示并非如此。