mcp server vs rag：先想清楚自己要干什么的具体做法

两个词一起搜的人，多半是手上有个需求，还没定是查资料还是调工具。这俩经常被当成同一层的方案，实际上一个往上下文里塞内容，一个让模型去外面做事。这篇不给结论式站队，给一套判断顺序和动手前该问自己的几个问题，写完你能说清自己那件事该走哪条路，或者干脆两条都上但怎么分层。

搜这两个词的人，手头基本都压着一个还没定型的需求：要么是老板让「把公司资料接进模型」，要么是开发提了个「让模型能查订单」。听着都像「给模型接点东西」，但接的东西不一样，活儿的方向就完全分岔。

MCP Server 和 RAG 经常被放在同一层比，其实一个改的是模型能看到什么，另一个改的是模型能做什么。下面不给站队结论，给一套判断顺序：先标清自己缺的是资料还是动手能力，再决定是一条路还是两条一起上、怎么分层。

先把两件事的功能边界摆正

MCP Server 解决的是「模型够不着的东西怎么让它够着」。查数据库、读内部接口、改一条工单状态，这些动作发生在模型外面，模型只负责决定调哪个、传什么参数。它扩展的是模型的操作范围。

RAG 解决的是「模型不知道的东西怎么让它知道」。把私有文档切片、向量化、按提问召回几段，塞回上下文当依据。模型本身没变强，只是答案前面多了一叠参考材料。它改的是输入。

判断顺序：先问缺料还是缺手

别一上来就选技术栈，先按顺序回答三个问题，答完选路自己会浮出来。这个顺序的好处是：前面答「是」就不用往下看了，省掉很多无谓的对比。

1. 答案是不是已经写在某份文档里是，就走 RAG。政策、手册、合同这类内容改得慢、问法多变，正是检索的强项。别为了这种需求去包一层工具调用，纯属给自己加活。
2. 答案要不要实时查或写库存、工单、订单状态这类，答案压根不在文档里，得去系统里现问，甚至要改数据。这是 MCP 的活，检索再勤也追不上实时。
3. 文档里都有，但份数多、要反复翻可能两条都得有。先做 RAG 把资料能查通，再考虑要不要把「查资料」本身做成一个工具，让模型自己决定查几次。

有一类情况这套判断不适用：纯闲聊、纯生成、不需要外部事实的任务，两条都用不上。硬套只会多出一套向量库和一组工具描述，维护成本全落在自己头上。

选错了会卡在哪，怎么尽早发现

最常见的误判是拿 RAG 去做实时动作。资料永远滞后一步，你会开始加定时同步，从每小时加到每十分钟，最后发现自己其实在手工造一个很差的接口。这时候已经不是检索问题了，是拿错了工具。

反过来的坑也很典型：拿 MCP 做知识问答。每问一句调一次工具，延迟和费用都上去了，还因为每个工具返回的结构不一样，前端得写一堆适配代码。这个错在第一周就有味道。

发现得早，改法不用推倒重来。已经做好的那块可以降级成另一条链路的输入：检索层留着当工具的后备，工具层只负责真正要动手的部分。

两条都要上时，怎么分层不打架

真要两条都上，关键不是各做一套，而是让它们有主从关系。我建议把 RAG 当成一个检索工具注册进 MCP，模型只面对一套工具描述，不用知道背后是向量库还是业务接口。

工具粒度按业务动作切，别按数据表切。一个「查最近订单」比一个「执行任意 SQL」好维护得多，也顺手挡掉了越权查询。这条经验在内部系统对接上尤其值钱。

• 给检索和工具调用分别设次数上限，不然模型会在两者之间反复横跳，成本悄悄翻倍
• 上线前跑同一批问题，记下命中检索的次数和调用工具的次数，比例明显失衡就说明分工没切对
• 工具的返回结构先统一成一种，前端只写一套解析，后面加工具不用改页面
• 日志里把「走了检索」和「走了工具」分开记，出问题时能一眼看出是哪条链路慢了

延迟容忍度也得提前写下来。检索天然能扛分钟级更新，工具调用通常要压到秒级，两者混在一条链路上时，慢的那段会拖住整条链路，得单独做超时和降级。

动手前先填一张小表

不用写设计文档，拿张纸列三到五个真实问题就够了。每个问题标两栏：答案在哪、要不要动手改东西。标完你会发现分歧没想象中大，大部分问题其实落在同一侧。

再补两栏：能忍多久的延迟、资料或系统的更新频率。更新频率决定你是加定时同步还是干脆改实时查询，延迟容忍度决定你能不能把检索和工具串在一条链上。这四栏填完，选路基本没有争议了。

如果填表时发现同一个问题既要在文档里找、又要去系统里改，那它就是混合场景的样本，单独拎出来设计，别硬塞进一条链路里。