mcp server 和 rag 怎么选

团队要做一个内部知识问答，一搜方案就看到 MCP Server 和 RAG，两拨人各说各的好，谁也说服不了谁。其实这两个东西压根不在同一层：一个管「模型怎么够到外部系统」，一个管「资料怎么被找出来喂给模型」。这篇不讲概念科普，只讲工程团队怎么定边界、怎么分工、怎么验收，以及什么情况下你其实两个都要。

做内部知识问答的团队几乎都会撞上这个选择题：一边有人说上 RAG，一边有人说直接接 MCP Server，两边都能讲出一堆理由，会议开到第三次还是没结论。问题出在把两件事放在一起比了——它们解决的根本不是同一个环节。RAG 管的是资料怎么被找出来、按什么顺序喂给模型；MCP Server 管的是模型怎么够到外部的系统、在需要的时候把真实数据取回来。一个偏「找得准」，一个偏「拿得到」。

所以这篇不讲概念科普，只讲工程团队怎么落地：先给两套方案划清边界，再按数据形态、权限风险、成本延迟、维护成本四条线逐条过，最后给一张能直接对号的表。核心思路是——先别问选哪个，先问你的问题答案到底存在哪。

先破一个误区：它俩不在同一层比

最常见的争论是「RAG 准不准」对上「MCP 灵不灵」，但这两个评价维度压根不交叉。RAG 的产出是一段上下文，它的好坏标准是召回的内容对不对、全不全；MCP Server 的产出是一次工具调用的结果，它的好坏标准是接口调得通不通、数据是不是最新的。拿检索质量去否定工具调用能力，或者反过来，都是无效比较。

RAG 的职责

把散落在文档里的静态知识切好、索引好、按问题召回出来，拼进上下文

MCP Server 的职责

把外部系统的能力按标准协议暴露成工具，让模型自己判断什么时候调、调哪个

判断口径

答案是「已经沉淀在文档里的知识」偏 RAG；答案是「必须现查现算、数据在别人系统里」偏 MCP Server

• 先写一份问题清单，不要先看方案文档，问题清单才是选型的输入
• 每条问题标注「答案是文档里写的，还是系统里查的，还是两处都要」
• 统计三类问题各占多少条，占比最高的那类决定主路径
• 拿不准的条目先归到「文档里没有」那一类，宁可高估实时查询需求

看数据长什么样：静态沉淀还是活体查询

数据形态基本决定了主路径。静态沉淀的资料——手册、规范、历史工单、产品文档——变化慢、以读为主，天然适合 RAG；活体查询的对象——库存、订单状态、排期、账号权限——每次问都可能不一样，塞进索引当天就过期，必须走 MCP Server 实时拿。

混合场景很常见：用户问「这个型号还有货吗，保修政策是什么」。前半句得实时查，后半句在文档里。这时不要硬塞进一个方案，做法是先把 MCP 拉回当次的真实数据，再拿这份数据的关键词去检索相关文档，两步串起来。链路清楚，出问题也容易定位是哪一步坏了。

看权限边界：谁能看到什么、能改什么

RAG 天然是只读的，风险集中在「不该被检索到的内容进了索引」。控制点在两处：切片和入库阶段按权限分区，别把全公司的资料混在一个索引里；召回之后再按当前用户的身份做一次过滤，别指望入库时过滤一次就够。这两处任何一处漏掉，都可能让一份本该只有主管能看的文档出现在普通员工的答案里。

MCP Server 的风险面大得多，因为它可能是写操作——下单、改状态、发消息。写了就不能撤销，这类能力必须配工具白名单和操作确认，模型不能自己决定直接提交。

• 只读查询的 Server 和写操作的 Server 分开部署、分开审计，别图省事合在一个里
• 工具白名单按角色配，普通用户看不到写工具，从工具列表层面就没有
• 写操作一律要二次确认或不自动执行，改由人在旁边点一下就放行
• 每次工具调用都记调用方、参数、结果，出问题能回溯到具体哪一次

算一遍成本和延迟：谁在每次请求上都要花钱

两套方案的钱花在不同地方，混在一起算很容易算错。RAG 的固定开销在入库阶段，切一遍嵌一遍，是一次性的；每次问答的开销在召回加长上下文，检索条数直接决定 token 花多少。MCP Server 的每次调用则是一轮额外的模型决策加一次接口往返，链路更长，延迟更容易抖。

1. 列出两条链路的参数RAG 侧记：切片长度、检索条数、重排开不开；MCP 侧记：平均几步决策、每步几个候选工具、接口平均往返多长。参数不列全，后面算出来的数没意义。
2. 把参数代进站内计算器到 /tools/model-cost-calculator 和 /tools/token-price-calculator 把你自己那套参数代进去算当时的数字。不要抄别人的示例值，模型和单价一换结论就变。
3. 各留一个可关的开关两条链路都要有降级版本，出问题时能一键退回只有文档检索的模式，先保住问答能用，再慢慢修。
4. 压测最坏情况模拟接口慢十倍、检索返回空、模型不调工具这三种情况，看整轮问答多久返回、返回什么，别只在顺利路径上测。

判断标准很简单：如果每次问答都必须走一遍工具调用，而其中大部分调用其实返回的是同一批稳定数据，那说明这些数据本来就该进索引，走 RAG 更划算。反过来，如果检索回来的文档八成已经过期，那省下的那点检索开销迟早要在纠错上还回去。

超时、重试、降级：把默认路径写死

工具调用的最大隐患不是调不通，是调得很慢还一直不返回。模型等在那儿，用户也等在那儿，最后要么超时报个错，要么模型自己编一个看起来合理的数值。这两种结果比直接说「查不到」糟糕得多，因为用户分辨不出来。

• MCP 调用必须设超时和步数上限，超过就直接退回「只用文档答，并说明数据没查到现在」
• 重试只对幂等的只读查询开，写操作一律不自动重试，避免重复提交
• 降级要有固定话术，明确告诉用户这条数据是实时的还是文档里的，别混着说
• 日志至少记：走的是检索还是工具、调了哪个 Server、耗时、命中几条文档、最后有没有降级
• 把降级次数做成监控指标，突增往往说明某个接口或索引出了问题

# 排查顺序，从外到内逐层看
# 1. 看这轮问答走的是检索还是工具
# 2. 看命中了哪几条文档 / 调了哪个 Server
# 3. 看调用耗时，和基线比是不是异常
# 4. 看是不是触发了降级，降级的触发条件是什么
# 5. 到站内工具目录对照该 Server 的说明，确认参数和权限没配错

上线前先跑一轮小评测，别靠感觉验收

这类系统最容易在演示阶段表现很好、上线之后慢慢跑偏，因为验收靠的是「看起来答得不错」。要有一套固定的小评测，改一次参数就重跑一次，不然你改好一处坏一处根本发现不了。

1. 准备二三十条真实问题从真实提问里挑，覆盖三类：文档里有的、文档里没有但系统里有的、两处都没有的。三类比例按你实际的提问分布来配，别全挑好答的。
2. 给每条问题标预期结果文档类的标应该命中哪一份资料；实时类的标应该调哪个工具；两处都没有的标「应当拒答」。预期先写下来，再看输出，顺序反过来就会被结果带偏。
3. 跑两条链路各一遍同一套题分别跑纯 RAG 和带 MCP 的版本，比较的是哪条更省事、哪条降级更少，不是哪条看起来更聪明。
4. 记录正确率和拒答率拒答率不能当负面指标看，宁可说不知道也别编。两处都没有的那类问题，正确行为就是明确拒答。
5. 改参数就重跑换了切片长度、改了检索条数、动了提示词，都重跑一遍。小评测的价值就在于它能被反复跑，跑一次的成本必须低。

一张对照表收尾：按你的条件直接对号

选型定下来之后还要定期回看：数据形态会变，接口会变，团队人手也会变，上个月合适的方案这个月可能就不合适了。模型侧的价格和可用情况去 /official-api 核对当时的数字，向量库选型到 /stacks/vector-dbs 对一遍再定，中转服务的稳定性参考 /sites 里的记录。具体数字都会变，判断方法不会。

选型不是比哪个方案更强，是看你的问题清单落在哪一边。