团队要做个能回答问题、能查资料、还能动手干活的 AI 应用，讨论到一半常卡在「到底上 MCP Server 还是 RAG」。有人觉得都是喂资料给模型；有人把两者当成替代关系，选错之后要么检索链路白搭，要么工具调用接不上。这篇不做概念堆砌，给一条从需求出发的判断路径：先分清你的痛点是「缺私有知识」还是「缺操作能力」，什么条件下两者都要上，什么情况下单个方案更省事。
团队要做个能回答问题、能查资料、还能动手干活的 AI 应用，讨论到一半常卡在「到底上 MCP Server 还是 RAG」。有人觉得两者都是喂资料给模型，有人把两者当成替代关系，选错之后要么检索链路白搭，要么工具调用接不上。这篇不堆概念，只给一条从需求出发的判断路径：先分清痛点是「缺私有知识」还是「缺操作能力」，再看什么条件下两者都要上、什么情况下单个方案更省事。
给新手的建议是：别先选技术，先写清楚一句话——用户问完之后，你要的产出是「一段能指回原文的回答」，还是「系统里真的发生了一件事」。这句话写不出来，方案一定选偏。下面按四步走，每步都给了验证动作，走完基本能定路线。
先把两件事分清：一个补知识，一个补动作
RAG 的产出是给模型补上它没见过的资料：离线把文档切片、向量化入库，提问时先检索再拼进上下文，回答要能指回原文。MCP Server 的产出是给模型一套可调用的能力：把查询、写入、拉取外部系统这类动作按协议暴露成工具，由模型在对话中决定何时调用。一个管「知道什么」，一个管「能做什么」。
- RAG
- 把资料切块入库，回答前先检索，追求答案有出处、可核对
- MCP Server
- 把系统能力按协议包装成工具，追求模型能真正执行动作
- 常见误区
- 把两者当二选一，结果要么只会答不会做，要么能调工具却答不准
判断口诀很简单：答案在文档里、问题是「说了什么」，偏 RAG；动作在系统里、问题是「帮我做什么」，偏 MCP。两者也不互斥，RAG 负责事实来源，MCP Server 负责把检索本身和后续操作包装成工具，复杂场景常常是叠加使用，比如先查知识库、再按查到的单号去改工单状态。
四步判断流程：照着走一遍就有答案
这四步不用全做完才下结论，哪一步出现明确信号就可以先定方向，后面几步用来验证和维护成本评估。每步都配了一个可落地的动作，别只停在讨论。
| 判断问题 | 偏 RAG 的信号 | 偏 MCP 的信号 |
|---|---|---|
| 数据在哪 | 静态文档、FAQ、规范，以读为主 | 分散在多个业务系统，需实时查询 |
| 输出形态 | 只要一段带出处的回答 | 要写工单、改状态、发消息等有副作用的结果 |
| 更新频率 | 资料稳定、量大，入库划算 | 每天都在变，不想重建整条索引 |
| 维护成本 | 团队熟悉切片与召回调优 | 团队熟悉服务传输与鉴权 |
- 第一步：问数据在哪列出回答要用的全部资料，标出是文档还是系统接口。以文档为主先评估 RAG；需要跨系统实时取数先评估 MCP。
- 第二步：问输出形态把用户诉求写成动词。只有「看、查、解释」这类，RAG 单独够用；出现「改、建、发、批」，必须有 MCP 这类工具通道，否则模型答得再好也落不了地。
- 第三步：问更新频率资料每天在变又不想重建索引，可以用 MCP Server 包一层检索服务，读的时候现取；资料稳定且量大，入库更划算。验证方法：抽样一批最近变更的文档，看现取和入库两种方式哪个答得更准。
- 第四步：算维护成本RAG 多一条切片、嵌入、召回的链路，MCP 多一层传输、鉴权、工具描述的维护。谁的链路团队更熟就先上谁，另一条留作二期。
什么情况下不适用：几种常见误配
下面几种情况不是「做得不好」，而是「不该这么做」。判断标准是：如果最简单的办法已经能满足，就别为了架构好看加链路。每种误配都给了替代动作，照着改能少返工。
- 资料量很小、十几页文档就能塞进上下文：先别上 RAG，直接拼进提示词更省事，等量大到塞不下再改。验证方法：用小样本试拼，看回答质量是否够用。
- 答案只存在于内部数据库且必须精确实时：纯向量检索容易把数字查错，应走 MCP 暴露结构化查询工具，把 SQL 或接口查询包成只读工具，而不是硬塞进向量库。
- 需要强权限隔离、每一步操作都要审计：只用 RAG 无法满足，MCP 侧要配工具白名单与调用日志，权限粒度不够就别急着上线写操作。
- 团队没有一个人能维护嵌入模型或工具服务：先做最小验证，只挑一条链路，别一上来两套都铺开。
- 用户问题主要是闲聊和常识、几乎没有私有资料：两套都别上，先把提示词和评测集做好。
动手前的清单与最小验证顺序
方向定了之后，别直接开大工程。先攒小样本、跑通最小闭环、再决定投入。经验是：验证阶段的目标不是效果好，而是确认这条路走得通、哪一段最容易出问题。
- 先攒 20 到 30 条真实问题做小样本，看模型不看资料时错在哪，确认是知识缺口而非提示词问题。
- RAG 侧先跑通切片、嵌入、召回三段，用站内嵌入模型目录挑候选，再按命中率调切片粒度；各模型当时的参数和价格到站内模型库核对。
- MCP 侧先只做一个只读工具，用站内 MCP 服务器目录找现成实现，跑通传输与鉴权后再加写操作。
- 两条路都做时约定分工：检索走 RAG，动作走 MCP，避免同一个能力在两个地方各实现一遍。
- 上线前留一组回归问题，每次改切片或改工具描述都跑一遍，防止改动把原来的正确回答带崩。
常见问题
MCP Server 能替代 RAG 吗？
不能。MCP 解决的是「让模型能调用东西」，它不负责把资料切成可检索的块，也不管召回质量。你可以用 MCP 把检索服务包成工具，但底下仍然是一套 RAG 链路。反过来 RAG 也给不了模型动手改系统的能力。
小团队只能选一个，先上哪个？
看卡点。回答偏「不知道」、用户经常问文档里写过的内容，先上 RAG；卡点是要在人手不足时自动完成查询和录入，先上 MCP 的一个只读工具。先用小样本验证哪边投入产出更明显，再决定补另一套。
两个都上会不会太重？
会，但可以分阶段。先把 RAG 的检索接口独立出来，再用 MCP Server 把它和几个业务查询包成工具，这样只维护一条检索链路加一层工具壳，比各做一套轻。什么时候不建议这么干：团队没有稳定的部署和监控能力，叠加后故障面更大。
