很多人一开始把 MCP Server 和 RAG 当成二选一的技术栈，结果要么拿检索方案硬做动作调用，要么给一个查文档的需求套上了服务器。这篇不比较谁先进，只给一张判断表和两条各自能跑通的最小流程：什么信号出现就该走哪条路，走错了会在哪一步卡住，以及两条路同时用的时候边界画在哪。
很多人一上来就把 MCP Server 和 RAG 当成二选一的技术栈，结果要么拿检索方案硬做动作调用，要么给一个查文档的需求套上了服务器。这篇不比较谁先进，只给一张判断表和两条各自能跑通的最小流程：什么信号出现就该走哪条路，走错了会在哪一步卡住，以及两条路同时用的时候边界画在哪。
先记住一个前提：这两件事解决的不是同一类问题。取数那条路关心的是「模型怎么知道你的私有资料」，动手那条路关心的是「模型怎么安全地操作你的系统」。分不清这个，后面选什么都别扭。下面按四个小节走一遍，每节都给能直接照做的动作。
先把两件事说清楚：一个管取数，一个管动手
MCP Server 是把外部系统的能力以标准方式暴露给模型，核心是能执行动作、能返回实时结果，模型看到的是一份工具清单；RAG 是模型不知道你的私有语料，核心是把资料切片、向量化、按问题召回再拼进上下文，模型看到的是几段文字。判断问句很简单：需求是查资料回答，还是替我操作某个系统。前者偏 RAG，后者偏 MCP Server。
- MCP Server
- 把外部系统封装成模型可调用的工具，模型按需选择调用并拿到结构化结果
- RAG
- 把私有资料切块入库，按问题召回片段拼进上下文，让模型基于片段作答
- 走错的表现
- 用 RAG 做写操作会停在「模型只能描述、没法真正提交」；用 MCP 做文档问答会卡在「工具返回值拼不成一段完整答案」
五问判断表：照着答一遍再动手
别凭感觉选。把下面五个问题按顺序答一遍，答案偏向哪边就先用哪条路；两边都有信号，先做能独立跑通的那条，而不是同时开工。
| 判断问句 | 偏 RAG 的信号 | 偏 MCP Server 的信号 |
|---|---|---|
| 数据是静态文档还是实时业务系统 | 手册、政策、产品说明类文档 | 订单、库存、工单这类业务系统 |
| 答案要不要可核对出处 | 需要引用原文位置、要求能翻回来源 | 结果以状态或数值为准，不需要长引用 |
| 有没有写操作、发请求、改状态 | 只读问答，不改任何东西 | 要提交、修改、触发流程 |
| 语料变化频率 | 相对稳定，可以定期重建索引 | 天天变，最好直接查源系统 |
| 团队能不能维护索引和召回质量 | 有人能持续盯召回命中率 | 没人愿意长期维护向量库 |
- 问一，数据是静态文档还是实时业务系统：文档偏 RAG，系统偏 MCP。
- 问二，答案需要引用出处、要求可核对吗：需要则 RAG 更自然，工具返回的结果很难直接当引用。
- 问三，要不要写操作、发请求、改状态：只要涉及写，RAG 就不合适，必须走工具调用类方案。
- 问四，语料会不会天天变：变化频繁且要即时性，考虑 MCP Server 直接查源系统，省掉重灌向量库。
- 问五，团队有没有人维护索引和召回质量：没人维护就别急着上 RAG，召回坏了比没有更误导。
五问里有两条以上落在同一侧，就不用再纠结了。如果两边各占一半，说明需求本身没拆干净，先把它拆成「查」和「做」两个子任务，再分别选路。
走 RAG 的最小可跑流程
RAG 最容易翻车的不是模型，是语料和切块。下面这条流程不追求一步到位，只求每一步都有可验证的产出，跑不通时知道卡在哪。
- 第一步，整理语料先做清洗，把表格、扫描件、页码噪声处理掉，别把脏数据灌进库；清洗后抽查十几条原文，确认没有串页和断句。
- 第二步，选嵌入模型与向量库到 /embeddings 和 /stacks/vector-dbs 按语种、规模、部署方式挑，个人项目起步不需要分布式方案；先选一个能本地跑起来的组合。
- 第三步，切块与入库切块大小、重叠和元数据字段先定死一版，留好回溯原文的字段；入库后随机抽几条命中，确认能定位回原文档。
- 第四步，接生成把召回片段拼进提示，要求模型标注来源；用几十条真实问题测一遍召回命中率，再谈优化。
- 第五步，看效果召回不准先查切块和嵌入模型，别一上来就加 rerank；单次问答的开销量级到 /tools/model-cost-calculator 粗算一遍。
走 MCP Server 的最小可跑流程
MCP Server 的坑集中在工具描述和错误处理上。模型不是人，它只能靠工具描述和返回文本判断下一步，这两样写不清楚，接得再通也用不好。
- 第一步，定能力边界一个 Server 只暴露一组相关动作，工具描述要写给模型看，不是写给同事看；参数名和说明里把单位、可选项写全。
- 第二步，选传输方式本地进程用 stdio，跨机器用 HTTP 类传输，先确认客户端支持哪种；不确定就先用本地 stdio 把链路跑通。
- 第三步，最小实现先做一个只读工具跑通握手和调用，再接写操作；只读都调不通，别急着上写能力。
- 第四步，加护栏写操作要有人工确认或幂等键，调用失败要有明确错误文本让模型能读懂；错误信息里别只回一个错误码。
- 第五步，接客户端验证到 /mcp 找现成服务器对照实现，接不上时按连接、命令路径、权限顺序排查，一次只改一个变量。
两条路一起用：边界怎么画
成熟一点的场景往往是两条路都要。常见组合是：RAG 负责答「是什么、怎么写」，MCP Server 负责「现在是多少、帮我提交」。混合本身不难，难的是别让检索结果去驱动动作。
- 边界原则：检索结果只进上下文，不直接触发动作；动作调用前必须由模型显式决定并留下参数记录。
- 组合示例：一家 5 人小团队做客服助手，政策类问题走 RAG，查订单状态走工具调用。
- 成本注意：两条路都会放大上下文和调用次数，先用 /tools/model-cost-calculator 粗算一遍单次问答的量级。
- 别混用的情况：任务单一、资料量小、动作只有一个，混用只会让排查变难，先跑通一条再说。
常见问题
只会上一种，先学哪个更划算？
看手上第一个真实需求。如果第一件事是让模型回答公司文档里的问题，先学 RAG，链路短、见效快；如果第一件事是让模型去查订单、建工单，直接学 MCP Server，别绕检索。两头都学不如先把一个跑通。
RAG 能不能代替 MCP Server 去查数据库？
只读、且答案是从文档里能找出来的，可以用检索把结果拼进上下文，但数据一变就要重灌。涉及实时数值、权限隔离、写操作，还是走工具调用，让模型显式带着参数去请求，出错也容易定位。
两条都上了，结果答错该先查哪边？
先看模型拿到的是什么：只拿到几段文本就是检索问题，去查切块、嵌入和召回；看到工具调用记录就是工具问题，去查参数、返回值和错误文本。分不清就先把两条链路分开单独测一遍。
