我们如何为智能体构建 Redis 文档 MCP
内容提要
Redis团队推出公开的Redis Docs MCP服务器，提供search、fetch、ask三个工具，使AI编码代理能直接查询权威文档，避免依赖过时训练数据或网页抓取。项目采用规范驱动开发，由代理撰写大量代码，并强调评估检索证据而非答案，未来将构建可导航的实体关系层。
延伸解读
无鉴权设计的取舍
Redis Docs MCP 选择无鉴权公开访问，以服务开源社区和 Enterprise 客户。这带来隐私约束：无法识别调用者，因此请求文本不进入日志，遥测仅聚合，内部排名分数和不可获取的标识符不会外传。同时，由于所有工具通过单个 POST /mcp 端点到达，边缘无法区分 search 和 ask，速率限制必须在应用层实现。
工具数量与描述成本
服务器仅暴露 search、fetch、ask 三个工具。每个工具描述会在整个连接期间折叠进客户端上下文，增加第四个工具会让所有调用者在每次调用时都消耗额外 token，无论是否使用。因此团队刻意保持工具数量精简，并遵循 OpenAI 为文档 MCP 服务器建立的契约，使 ChatGPT Deep Research 等客户端无需集成即可工作。
评估检索证据而非答案
团队强调评估检索证据而非最终答案，因为强模型能将不完整证据转化为有说服力的文本。他们使用两个独立测试框架，针对同一标注数据集分别测量检索器和代理的贡献。例如，代理的查询重写将简单查找问题的 recall@5 从 0.545 提升到 0.818，但在多跳问题上降低了 top-5 块精度。
混合搜索的实测收益
原型使用纯向量搜索，但团队通过评估验证混合搜索的必要性。在 73 个查询上，混合搜索（FT.HYBRID）相比向量基线，Hit@3 提升 0.08，recall@8 提升 0.06，延迟保持 0.5-0.7 毫秒 p50。Hit@1 下降 0.04，因为排名融合有时会交换精确的顶部结果。评估还发现，混合搜索的收益主要来自弥补近似最近邻的遗漏，而非增加词汇匹配。
Q&A
Redis Docs MCP 是什么？它提供哪些工具？
Redis Docs MCP 是 Redis 团队推出的公开 MCP 服务器，地址为 redis.io/mcp，提供 search、fetch 和 ask 三个工具，无需认证，任何 MCP 客户端均可使用。
为什么 Redis 要构建 Docs MCP 而不是依赖网页搜索或客户端检索？
因为网页搜索返回的页面没有稳定标识符，代理无法引用或回溯；客户端检索则要求每个框架重新实现分块、嵌入和新鲜度维护，而语料库并不属于它们。Redis Docs MCP 提供权威、可引用的文档访问，避免依赖过时训练数据或网页抓取。
Redis Docs MCP 为什么选择无密钥（keyless）设计？
因为 Redis 文档同时服务于开源社区和企业客户，在文档查询前设置注册会排除大部分开源用户。无密钥意味着无法识别调用者，因此请求文本不会进入日志，遥测仅聚合，内部排名分数和不可获取的标识符不会传输。
ask 工具与 search、fetch 在架构上有何不同？
ask 是唯一接触 Context Retriever 和语言模型的工具，它运行与营销演示聊天端点相同的检索与合成管道，但作为共享库而非 HTTP 调用。模型持有 Context Retriever 生成的工具并决定调用哪个，驱动检索而非事后总结。search 和 fetch 则直接通过 RedisVL 查询 Redis 索引，不经过 Context Retriever。
Redis Docs MCP 如何确保 ask 返回的引用来源真实可靠？
ask 现在返回一个 sources 数组，该数组源自检索管道在当轮实际获取的内容，每个 id 都来自真实的工具调用，因此不会出现伪造的引用，且每个 id 都能通过 fetch 解析。此前模型自行编写 URL 曾导致引用不存在的页面。
在评估检索质量时，为什么强调“评估证据而非答案”？
因为强大的模型能将不完整的证据转化为有说服力的文字，所以评估答案本身很难判断检索是否正确。评估应聚焦于检索器提供的证据，但需注意证据评分高仍可能被糟糕地合成，因此这些数字只界定检索器提供了什么，而非调用者读到了什么。
混合搜索相比纯向量搜索在 Redis Docs MCP 中带来了哪些提升？
混合搜索（FT.HYBRID）在 73 个查询上评估，Hit@3 提升 0.08，recall@8 提升 0.06，检索延迟保持在 0.5-0.7 毫秒 p50 和低于 1.3 毫秒 p95。Hit@1 下降 0.04，因为排名融合有时会交换精确的顶部结果，但对于调用者会阅读全部八个结果并可获取任意一个的工具来说，这是可接受的权衡。
Redis Docs MCP 项目如何利用规范驱动开发和编码代理？
项目采用规范驱动开发，在 spec/ 目录下维护约三十份文档，涵盖提案、接口契约、评审和笔记。编码代理撰写了大量代码，374 次提交中有 135 次以代理为作者。代理还被用于评审循环，通过多个评审角色依次检查实现，例如一致性、信息泄露、对抗性破坏和文档同步。
Redis Docs MCP 未来的发展方向是什么？
未来将构建可导航的实体关系层，声明实体及其关系，使语料库成为代理可以导航而不仅仅是采样的对象。这是项目演变成的更大块工作，也是 Hillary Toh 撰写的配套文章的主题。
