what is mcp and rag

很多人第一次听到 MCP 和 RAG，会觉得这两个词挨得很近，甚至以为选一个就行。真到动手时才发现：RAG 管的是「模型怎么读到你的资料」，MCP 管的是「模型怎么够到外部工具和数据源」，两者不在一个层面上，反而经常一起用。这篇不重复概念入门，只讲工程上怎么分工、怎么接、接完怎么验证。

很多人第一次听到 MCP 和 RAG，直觉是这俩挨得很近，甚至觉得选一个就行。真动手才发现不是一回事：RAG 管的是「模型怎么读到你的资料」，MCP 管的是「模型怎么够到外部工具和数据源」。一个偏数据通道，一个偏能力通道，层面不同，所以经常是一起用而不是二选一。

这篇不重复概念入门，只讲工程上怎么分工、怎么接、接完怎么验证。判断标准、接线步骤、排错顺序都会给到，具体到某个向量库的选型或者某家模型的效果，建议直接到站内页面核对当时的数字，别拿别人嘴里的结论当自己的基线。

先分清两层：RAG 是数据通道，MCP 是能力通道

把这两个东西摆在同一层比较，是大多数混乱的源头。RAG 解决的是「模型不知道你的私有内容」，动作发生在生成之前，重点在切块、召回和上下文拼装。MCP 解决的是「模型够不到外部系统」，动作发生在模型决定调用什么的那一刻，重点在接口描述和权限边界。

RAG

把资料切块、向量化、检索后塞进上下文，关注数据质量和召回率

MCP

把工具、资源、提示模板按统一协议暴露出去，关注接口描述和权限边界

判断口诀

答案本来就在某份文档里，偏 RAG；答案要去某个系统里现查现算，偏 MCP

交叉点

一个 MCP 服务器完全可以对外暴露一个检索工具，MCP 是外壳，RAG 是里面干活的逻辑

注意最后一条：这两者不是对立关系。你完全可以把检索能力包成一个 MCP 工具，让模型自己决定什么时候调用。这时候你既在做 RAG，也在用 MCP，只是分工不同——协议层负责「怎么调」，检索层负责「调完拿什么回来」。

什么情况下两个都要上

不是所有项目都需要两套。判断标准很简单：看你要回答的问题，答案的来源是不是单一的。如果答案永远在文档里，RAG 就够了；如果答案永远在某个系统的实时状态里，MCP 就够了。只有当这两类问题同时存在，才需要两套一起上。

• 资料既多又散、还经常更新，同时又要按用户身份实时查权限、查库存、查工单，单一方案会缺一块
• 团队里已有知识库，但业务系统是现成的 REST 或内部 API，不想为每个系统单独写一遍适配层
• 做 Agent 类产品，模型需要自己决定这次是查文档还是调接口，这属于工具编排问题，不是检索问题
• 需要按角色做权限隔离：文档检索可以全量，但业务接口必须带用户身份，这种边界只有工具层能卡住

接线顺序：先定数据流，再定工具边界

接线最容易犯的错是先选框架再想数据流。正确的顺序反过来：先把一次问答的完整链路画出来，再决定每个环节用什么实现。链路没画清就动手，后面每加一个组件都是在给排查加难度。

1. 画出完整链路用户问 → 判断意图 → 检索或调工具 → 拼上下文 → 生成 → 回填引用。每一步都要能说清输入输出是什么
2. 决定 MCP 暴露什么一个检索工具、一个写操作工具、还是把整个内部系统包一层。粒度越粗越难排查，建议一类能力一个工具
3. 收敛工具入参检索工具只留查询语句、条数、过滤条件这几个，别把向量库连接串或鉴权信息暴露给模型
4. 读写分离部署写操作类的工具单独放一个服务器，和只读检索分开部署，出问题好切断，也方便单独限流
5. 验证链路可测每一段都要能单独调用并拿到明确返回，不能全靠端到端跑一遍才知道哪段坏了

接口暴露的粒度，直接决定后面排障的成本。一个「万能工具」看起来很省事，但模型给错参数时你根本不知道是描述不清还是参数设计有问题。宁可拆成几个职责单一的小工具，每个工具的用途一句话能说清。

超时、并发和降级怎么定

检索和工具调用必须各自设独立超时，不要让检索的慢拖垮整条请求。连接、读取、整体三档分开配，具体取多少值，参考站内工具页量出的延迟基线，别拍脑袋。并发上限则按下游最弱的一环来定——向量库、业务接口、模型网关谁的 QPS 最低就以谁为准。

降级顺序的核心原则是：能确定的信息照常返回，不能确定的绝不编。工具超时就退回只用检索结果，检索超时就坦白说没查到。给每次请求打上「走了哪条路」的标记，事后统计各路径的成功率和耗时，比翻日志猜要快得多。

日志要记哪几栏，才能事后复盘

日志字段不是越多越好，而是要能按请求 ID 串起来。分开维度记，排查时才能定位到底是检索没召回、工具没调对，还是模型自己编了。所有字段落到结构化存储里，别只写进文本日志。

• 检索维度要记录重排前后的顺序，否则分不清是召回差还是排序差
• 工具失败原因要分类，网络超时和参数错误修法完全不同
• 成本里 token 和调用次数必须分开，混在一起就说不清贵在哪
• 用户身份要脱敏后再落库，权限相关信息单独存

接完之后怎么验，别只看「好像能答」

「好像能答」是最危险的验收标准。你需要一小组固定问题，覆盖三种情况：答案在文档里、答案要调工具、答案根本没有。每次改动检索参数或工具描述，都跑一遍这组问题，对比命中率和引用来源是否正确。

1. 准备固定问题集覆盖三类：文档可答、工具可答、根本无解。每类至少几条，别只测好答的
2. 分离两类错误把「没查到」和「查到了但答错」分开统计，前者的锅在检索，后者大概率在生成或提示
3. 做对照实验同一组问题，分别跑「固定走检索」和「模型自己选工具」两种模式，看差异在哪
4. 回归验证把改动前的问题集跑一遍，确认没有把原来能答对的问题改坏

每次调整工具描述、检索条数或重排策略，都要重跑这组问题。想省事的话，先按普通检索接一遍，再换成让模型自己选工具的方式，对比同一组问题的表现差异。两种模式的失败模式不一样，对比着看才能知道该往哪个方向调。

常见翻车点和排查顺序

线上出问题时，别从头到尾重新捋一遍，按固定顺序排查效率最高：先确认是检索还是工具的问题，再确认是数据问题还是描述问题，最后看并发和限流。下面这张表把常见现象和第一排查位置对应起来。

如果各环节单独测都过，整体却时好时坏，大概率是并发叠加导致下游限流。这时候别急着加机器，先按前面说的降级顺序加熔断，观察限流是否消失，再决定要不要扩容。

选型上的一句话判断

选型不需要复杂评分表，几个问题就能定方向：你要的答案主要在哪、团队有没有维护检索链路的人、外部系统是不是已经有一堆现成接口。回答完这几个问题，方向基本就清楚了。

• 团队没人维护向量库，但已经有一堆现成接口：优先 MCP，把接口包成工具，别急着上 RAG
• 文档多、更新快、答案主要在文档里：优先把检索做扎实，MCP 晚一步再上
• 两边都要：先上 RAG 再加 MCP，因为检索链路独立可测，反过来做容易两个变量同时动
• 不确定就先做最小闭环：一份小文档加一个检索工具，跑通再扩，别一上来就铺满基础设施

补一句反向判断：如果业务方的需求是「今天就要能查库存」，那 RAG 帮不上忙，先把 MCP 那条路打通；如果需求是「把过去三年的制度文件都能问答」，MCP 也不是重点。按需求的实时性来分，比按技术名词来分靠谱得多。