MCP vs RAG：核心区别、适用场景与组合方式

MCP 和 RAG 并不是互相替代的关系。RAG（检索增强生成）是一种技术：搜索知识库，把最相关的段落放进提示词，让模型基于它们作答。MCP（Model Context Protocol，模型上下文协议）是一种协议：AI 应用连接外部工具和数据源的标准方式，包括模型可以直接操作的实时系统。RAG 回答的是"我们的文档里怎么说？"；MCP 回答的是"现在的真实情况是什么，你能不能顺手处理一下？"——而最好的系统通常会通过 MCP 来暴露 RAG。

什么是 RAG

RAG 出自 2020 年的论文 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。这个模式分三步：

1. 索引 ——把文档切成块（chunk），为每个块生成 embedding，存入向量索引（通常还会配合关键词索引）。
2. 检索 ——问题到来时，对其做 embedding，取出最相似的 top-k 个块，必要时再做重排序。
3. 生成 ——把这些块插入提示词，让模型据此作答，最好附上引用来源。

当知识量大、以文本为主、变化缓慢且需要引用来源时，RAG 是正确的选择：产品文档、政策、工单、合同、论文。它的短板也同样明显：答案的新鲜度只取决于最近一次索引，检索质量高度依赖分块和 embedding，而且经典 RAG 无法执行任何动作。

什么是 MCP

MCP 是一个开放协议，规范发布在 modelcontextprotocol.io，它标准化了宿主应用（Claude、ChatGPT、Cursor、Codex 或你自己的 Agent）如何连接提供上下文和能力的服务器。服务器可以暴露三类内容：

• 工具（Tools） ——由模型控制的函数：模型决定何时调用（查询数据库、创建工单、发送消息）。
• 资源（Resources） ——通过 URI 标识、由应用驱动的数据：宿主决定如何纳入上下文（一个文件、一个 Schema、一条记录）。
• 提示词（Prompts） ——由用户控制的可复用模板，例如斜杠命令。

MCP 并不规定服务器如何获取数据。它可以调用实时 API、执行 SQL、读取文件——也可以运行一条 RAG 管线。关于前两种原语的详细对比，见 MCP 资源与工具的区别。

MCP vs RAG 对比表

什么时候用 RAG

• 大量、变化缓慢的文本 ——有数千篇文章的帮助中心、内部 Wiki、合同档案。你没法把它们全部塞进上下文，实时 API 查询也帮不上忙，因为问题是语义性的（"年付方案的退款政策是什么？"）。
• 答案需要引用 ——合规、法务和客服回答必须指向具体的原文段落。
• 语义搜索优于精确查找 ——用户的提问方式和文档的写法不一样。

什么时候用 MCP（不需要 RAG）

• 答案在业务系统里 ——"订单 4521 的状态是什么？"应该去查订单系统，而不是一份一周前的索引。像 Postgres MCP 这样的数据库服务器会返回当前的那一行数据。
• Agent 必须执行动作 ——创建 Issue、更新 CRM 记录、在 Slack 发消息、运行工作流。RAG 没有写入路径，MCP 工具有。示例可见我们的销售与营销 MCP 服务器清单。
• 结构化或体量小的数据 ——数据库 Schema、配置文件、单条记录。直接获取比做 embedding 更便宜也更准确。
• 一次集成、多个客户端使用 ——服务器只写一次，就能在 Claude Code、Cursor、Codex 和 ChatGPT 中使用（客户端列表）。

MCP 和 RAG 如何结合

这两层是叠加的。RAG 是位于 MCP 接口背后的实现；MCP 是让任何 Agent 都能使用它的接口。常见的组合方式有三种。

1. 把 RAG 做成 MCP 工具（Agentic RAG）

把检索器封装成一个 search_docs 工具。由模型决定何时搜索、写什么查询、是否换个更好的查询再搜一次——对于多步问题，这通常比每次都强制检索效果更好。目录里不少服务器已经采用了这种模式：Context7 和 DeepWiki 检索最新的库文档，Exa 则在整个网络上做检索。

2. 把检索到的文档作为 MCP 资源

搜索结果只返回轻量的引用，每篇完整文档则作为资源暴露，URI 形如 docs://refund-policy。宿主或用户只在需要时才拉取全文，从而让上下文窗口保持精简。资源模板（Resource Templates）让一个服务器就能覆盖整个语料库。

3. 混合：RAG 负责知识，MCP 工具负责实时数据和动作

一个客服 Agent 先搜索帮助中心（通过 MCP 调用 RAG），再查询客户的实时订阅状态（通过 MCP 调用计费 API），最后创建退款工单（通过 MCP 调用工单工具）。每一环都用了合适的技术，而 Agent 看到的是一套统一的工具接口。

架构示例：MCP 服务器背后的 RAG 管线

下面是一个使用官方 MCP Python SDK 的最小服务器，通过 uv add "mcp[cli]" 安装。search_index 和 load_document 代表你现有的向量库和文档存储。

from mcp.server import MCPServer

from my_rag import search_index, load_document  # your existing pipeline

mcp = MCPServer("docs-rag")


@mcp.tool()
def search_docs(query: str, k: int = 5) -> list[dict]:
    """Semantic search over the product docs. Returns titles, snippets and URIs."""
    hits = search_index(query, k=k)
    return [
        {"title": h.title, "snippet": h.text[:500], "uri": f"docs://{h.doc_id}"}
        for h in hits
    ]


@mcp.resource("docs://{doc_id}")
def get_doc(doc_id: str) -> str:
    """Full text of one document."""
    return load_document(doc_id)


if __name__ == "__main__":
    mcp.run()  # stdio by default

先用 uv run mcp dev server.py 在 MCP Inspector 中测试（详见 MCP Inspector 使用指南），再注册到客户端。在 Claude Code 中：

claude mcp add docs-rag -- uv run --directory /absolute/path/to/docs-rag server.py

更多客户端的具体步骤见我们的 Claude Code MCP 指南。

这种模式的设计建议：

• 返回摘要片段加 URI，而不是整篇文档。 只有片段不够时，才让模型读取完整资源。
• 工具描述要写给模型看。 说明它搜索的是哪个语料库，以及什么时候不该用它，避免模型去文档里找实时账户数据。
• 在服务器端执行权限控制。 返回结果前按调用用户的访问权限过滤；永远不要指望模型替你隐藏文档。
• 把检索到的文本视为不可信内容。 文档里可能藏有提示词注入；请阅读 MCP 安全最佳实践。

常见误解

• "MCP 取代了 RAG。" 并没有。MCP 免去了为每个应用单独开发集成的工作，但并没有免去对大规模文本做语义搜索的需求。
• "上下文窗口这么大，RAG 已经过时了。" 长上下文对中等规模语料有帮助，但成本、延迟以及超长输入下的召回率问题，使得检索对于大规模或需要按权限过滤的知识依然值得。
• "记忆服务器就是 RAG。" 像 Memory（知识图谱） 这样的服务器存储和回忆的是 Agent 自己写入的事实——两者密切相关，但它属于 Agent 记忆，而不是对你现有文档的检索。

下一步

如果你已经有一条 RAG 管线，把它放到 MCP 服务器后面，让公司里的每个 Agent 都能使用。如果你是从零开始，先看看你的数据源是否已有现成的服务器——动手之前，先浏览 MCP 服务器目录。