很多开发者第一次听到 MCP 和 RAG，会觉得它们都在「给模型补信息」，于是纠结选哪个。真动手才发现卡点不在选型，而在不知道该把哪段逻辑放在哪一层。这篇按请求链路拆开讲：谁负责取工具、谁负责取资料、边界在哪，最后给一份按场景判断的对照清单。
很多开发者第一次听到 MCP 和 RAG，会觉得它们都在「给模型补信息」，于是纠结选哪个。真动手才发现卡点不在选型，而在不知道该把哪段逻辑放在哪一层。这篇按一次请求的链路拆开讲：谁负责取工具、谁负责取资料、边界画在哪，最后给一份按场景判断的对照清单。
先给个粗结论：这两个东西不在同一个赛道上竞争，解决的问题不一样。把它们当成二选一，通常是在需求阶段就没把「资料」和「动作」分开。下面每一节都会落到具体的判断标准和排查动作上，方便你对着自己的项目过一遍。
先看两者各自解决的是哪一类问题
RAG 解决的是「模型不知道你的私有内容」：把文档切片、向量化、检索、拼进上下文，输出仍然是模型生成的文字。MCP 解决的是「模型碰不到你的系统和动作」：通过标准协议把工具、资源、提示模板暴露给模型，让它去读、去查、去执行。一句话区分：RAG 是往上下文里塞资料，MCP 是给模型一双手去够外部能力。
- RAG
- 离线把私有资料处理成可检索的索引，提问时按相似度召回片段拼进提示词，本质是「提前备料」
- MCP
- 运行时通过协议把外部工具和资源暴露给模型，由模型决定调哪个、传什么参数，本质是「现场取用」
- 共同点
- 两者都在弥补模型的知识与能力边界，但一个补文字信息，一个补操作能力
- 不适用场景
- 数据量极小、几页文档直接粘进提示词就够，硬上 RAG 是过度设计；只读资料、不需要任何动作，也不一定需要 MCP
按一次请求的链路，看两者插在哪一步
把一次问答拆成时间线会更清楚。RAG 的动作大部分发生在提问之前：进料清洗、切片、嵌入、入库；提问瞬间再走召回、重排、拼装进上下文，最后才生成。整条链路是你的代码在驱动，检索什么时候触发、召回多少条，都由你写死或配置。
MCP 正好相反，它的重心在提问之后。客户端与服务器建立连接、列出可用工具和资源，然后模型自己决定要不要调、调哪个、传什么参数，参数校验通过才真正执行，结果回灌进上下文，必要时再调一轮。控制权从你的代码交到了模型手里，这也是为什么 MCP 必须额外配白名单、步数上限和成本约束。
- 先画请求时间线拿一张纸，把一次问答从前到后画成时间线，标出哪些步骤在提问前完成、哪些在提问中完成、哪些在提问后完成
- 标注触发方在每一步旁边写清是「代码触发」还是「模型决定」，这是区分 RAG 与 MCP 最直接的信号
- 清点外部依赖列出这一步依赖了哪些外部系统：向量库、业务数据库、内部接口、第三方 API，依赖不同，稳定性和权限设计也不同
- 验证边界用一个最简问题跑一遍，看模型有没有在不需要外部能力时也去调工具，如果没有约束就频繁触发，说明边界画糊了
| 对比维度 | RAG | MCP |
|---|---|---|
| 主要作用 | 把私有资料找出来喂给模型 | 把外部工具和资源接到模型手上 |
| 触发时机 | 提问前建索引，提问时召回 | 连接建立后，由模型按需调用 |
| 控制权 | 检索逻辑由你的代码决定 | 调用决策部分交给模型 |
| 主要风险 | 资料过期、召回不准、出处缺失 | 权限过大、调用失控、成本上涨 |
| 典型配套 | 切片策略、重排、出处展示 | 工具白名单、步数上限、参数校验 |
想看清进料和召回各环节的具体选项，可以对照站内 /stacks/vector-dbs 挑向量库，再去 /ai-dict/category/tech 把嵌入、召回这类底层词过一遍，选型时心里会有底。
两者不是二选一：什么时候该一起上
最常见的组合是把 RAG 当成其中一个 MCP 工具：把检索接口包装成工具暴露出去，模型需要资料时才调，不需要就不调。这样既省上下文，又避免每次对话都无条件检索。另一种组合方向相反，先用 MCP 从多个系统取回原始数据，再统一走一遍 RAG 的入库流程，适合资料分散、格式不一的场景。
- 出现「动态数据 + 需要动作」——倾向 MCP，比如查实时订单状态并触发退款流程；
- 出现「静态资料 + 需要引用出处」——倾向 RAG，比如产品手册问答要标出原文位置；
- 两者都出现——把检索封装成 MCP 工具，让模型自己决定何时查资料；
- 如果团队没有稳定的文档更新节奏，RAG 会很快腐化，召回结果越来越不可信；
- 如果没有明确的工具权限设计，MCP 会把风险面放大，一次误调用可能改数据；
- 无论走哪条路，都要先确认出错代价：能回滚的动作可以放宽，不可逆动作必须加确认环节。
判断口径可以再压缩成一句：只要回答必须给出处，就说明资料层要独立设计；只要模型要改变外部世界的状态，就说明动作层要独立设计。两层各自建好，再决定这一期先上哪一层。
落地前的判断清单与常见坑
动手前先回答四个问题：资料是静态还是动态、模型要不要执行动作、回答是否必须给出处、出错的代价有多大。这四个问题的答案组合，基本就决定了这一期该先上 RAG 还是先接 MCP，或者两个都上但分两个迭代做。
| 排查项 | 检查方法 | 不通过怎么办 |
|---|---|---|
| 检索逻辑是否被写死 | 看代码里检索调用是否和工具实现耦合 | 先抽成独立模块，再决定包装成工具还是内部调用 |
| 工具权限是否收敛 | 列出每个工具能读写的资源范围 | 超出当前需求的读写权限先关掉，按需开 |
| 上下文是否被灌满 | 统计单次对话附带的资源体积 | 改成按需检索或按需取数，不要全量塞 |
| 拒答策略是否存在 | 构造一个资料里没有的问题观察回答 | 补上兜底话术和出处校验，别让模型硬编 |
两个最常见的坑值得单独说。一是把 MCP 当成检索方案，结果每次对话都把全部资源塞进上下文，成本和延迟一起涨；二是把 RAG 当成万能事实来源，不做出处校验和拒答策略，模型照样会基于检索片段编内容，只是编得更像真的。前者靠约束调用和按需取数解决，后者靠出处展示加置信度判断解决。
RAG 决定模型能看到什么，MCP 决定模型能做什么。能看和能做，本来就是两件事。
相关概念和目录可以先翻 /mcp 和 /stacks/agent-apis，选型阶段对着 /embeddings 看嵌入模型口径。具体到接口价格、延迟和可用性这些会变的数字，别凭印象，直接到站内对应页面看当时的记录。
下一步如果你正在纠结先做哪一层，可以先到 /mcp 看看现在有哪些可接入的服务和工具形态，再对着 /stacks/vector-dbs 确认资料层的技术选型，两边都过一遍，判断会清楚很多。→常见问题
只做知识库问答，需要 MCP 吗？
通常不需要。静态文档问答走标准 RAG 链路就够，引入 MCP 只会多一层协议和排错成本。除非你的知识库还需要模型主动去调外部系统拉最新数据，或者要把检索结果触发后续动作，这时才值得把检索包成 MCP 工具。
MCP 能替代 RAG 吗？
不能。MCP 只是把能力和数据源标准化地暴露出去，它不负责切片、向量化、召回排序这些检索环节。真要让它干 RAG 的活，你还是得在 MCP 服务器后面接一套检索实现，只是换了个调用入口。
两个都上会不会很复杂？
复杂度主要来自三处：协议连接与权限、检索质量、以及模型调用工具时的步数和成本控制。建议分两步走，先把 RAG 的召回质量调稳，再把检索包成工具接进 MCP，这样出问题能分清是哪一层。
