很多人在给模型接外部能力时卡在同一个岔路口：手上的需求到底该用 MCP 去调工具，还是先搭一套 RAG 把资料喂进去。两边都能让模型「知道得更多」，但实现方式、维护成本、出错模式完全不同。这篇不讲概念科普，只给判断顺序、对照维度和落地时要处理的超时、并发、降级与日志，帮你在动手前把方案定下来。
很多人在给模型接外部能力时卡在同一个岔路口：手上的需求到底该用 MCP 去调工具，还是先搭一套 RAG 把资料喂进去。两边都能让模型「知道得更多」，但实现方式、维护成本、出错模式完全不同。这篇不讲概念科普，只给判断顺序、对照维度和落地时要处理的超时、并发、降级与日志，帮你在动手前把方案定下来。
先给一个粗结论：这两样东西解决的不是同一层问题，所以「谁更好」这个问题本身问错了。MCP 管的是「让模型去动别人的系统」，RAG 管的是「把你自己的一堆资料变成能查的索引」。真正的选择不在于哪个更强，而在于你的数据现在长什么样、你对时效的要求有多硬、权限归谁管。把这三个问题答清楚，方案基本就定了。
先分清两者各修的是哪一段
MCP 的定位是让模型或客户端去调外部系统，数据仍然留在对方那边，模型拿到的是调用结果；RAG 是把资料预先切分、嵌入、入库，检索之后拼进上下文，答案完全依赖你喂进去的内容。一句话区分：前者在动别人的系统，后者在动你自己的资料。
- 要「做动作」，比如下单、发消息、改状态，选 MCP，RAG 做不了写操作
- 要「拿实时状态」，比如当前库存、此刻排队人数，选 MCP，索引再新也追不上秒级变化
- 要「查历史资料」，比如合同、手册、工单记录，选 RAG，这些内容通常没有可调接口
- 要「答私有文档问题」，选 RAG，前提是你这边能把文档整理干净
- 两者都要，比如先查规则再执行操作，那就混合，顺序是先检索后调工具
- 资料只存在于文档里、没有任何可调接口时，MCP 无从下手；需要执行写操作或调第三方接口时，RAG 也做不了
按六个维度做一次对照
把选型拆成六个能直接回答的维度，逐条打勾，哪边勾多就往哪边走。下面这张表可以直接当成团队内部的对齐工具，讨论时逐行确认，比空泛地说「我们上个 RAG 吧」有效得多。
| 维度 | 偏 MCP 的情况 | 偏 RAG 的情况 |
|---|---|---|
| 数据形态 | 结构化、已有现成接口 | 非结构化文档、PDF、网页 |
| 时效性 | 需要秒级最新值 | 能接受离线建索引的更新周期 |
| 权限 | 依赖对方系统的鉴权，要谈最小权限 | 权限在你这一侧，自己可控 |
| 成本结构 | 随调用次数线性增长 | 集中在入库、嵌入与每次检索的上下文 |
| 失败模式 | 超时、鉴权过期、参数不符 | 召回不到、切片切坏、答非所问 |
| 维护对象 | 跟着对方接口变 | 跟着你自己的资料变 |
成本这一栏别凭印象估，两边的计价口径不一样，到 /official-api 和 /tools/token-price-calculator 按当时的数字核对，再结合自己预估的调用量或文档量算一笔账。维护那栏尤其容易被忽略：接口方改一次字段，你的工具调用就可能集体失败；而资料侧更新慢，检索质量会悄悄下滑。
- 调用次数敏感型
- MCP 用得多花得多，适合低频但关键的动作
- 资料体量敏感型
- RAG 的入库与检索成本跟文档规模挂钩
- 混合型
- 两条链路都跑，成本要分开核算，别混在一个预算里
两者不冲突：混合落地的常见顺序
现实项目里大多数是混合方案，但顺序很重要。建议先把 RAG 做通，让模型能基于你的资料回答，顺便验证检索质量到底行不行；检索侧的具体组件可以在 /stacks/vector-dbs 里挑，不用一上来就纠结选型。
- 第一步：打通检索把资料切分入库，跑一批固定问题，看召回是否准确。验证方式是人工抽查命中片段，别只看最终答案像不像
- 第二步：抽一个工具出来把「需要实时状态或执行动作」的那部分做成 MCP 工具，一次只加一个，观察调用日志里的入参和返回是否符合预期
- 第三步：加路由命中文档类问题走检索，命中操作类问题走工具调用，两者都命中时先检索拿到规则再调工具
- 第四步：补降级工具不可用时回退到「只回答不执行」，检索不可用时回退到明说资料缺失，两条链路各自独立降级
什么情况下不用走这套混合流程：单人小项目、资料量很小的时候，直接拼进上下文可能比搭两套链路更省事；反过来，如果你的资料需要频繁更新且带权限隔离，或者动作调用涉及资金与外部系统，那该有的链路和审批一个都别省。
上线前必查的工程项
方案定了之后，真正让人翻车的是工程细节。下面这几项不分 MCP 还是 RAG，两条链路都要过一遍，建议当成上线前的固定清单逐条打勾。
- 超时分级：工具调用和检索分开设阈值，别用同一个值，先到 /tools/speed-test 量出各自的延迟基线
- 并发与限流：工具调用容易触发对方限流，检索侧是向量库并发，两边都要有排队和退避策略
- 降级路径：想清楚工具挂了、检索挂了分别返回什么，写进代码而不是靠临场发挥
- 日志字段：记请求 ID、走的哪条链路、检索命中片段、工具入参与返回、耗时与 token 数
- 评测集：准备一小批固定问题，改动切片或工具后重跑一遍，别凭感觉判断变好没有
- 权限审计：MCP 那边定期核对授权范围，RAG 那边核对谁的文件进了库，避免越权检索
日志这块值得多说一句：一次请求慢或者贵，复盘时得能一眼看出是检索拉长了上下文，还是工具调用重试了好几轮。字段留全了，排查就是从日志里读答案，而不是猜。
选型不是选更强的那个，而是选出错时你能接得住的那个。下一步把你手上的需求按上面六个维度过一遍，再去 /rankings 和 /price-watch 看一眼同类方案的实际口碑与价格走势，心里更有底。→
常见问题
MCP 是不是比 RAG 更先进，可以直接替代它？
不是替代关系。MCP 解决的是「让模型调外部系统」，RAG 解决的是「让模型用上你的资料」，两者面向的问题不同。文档类问答没有现成接口可调，MCP 帮不上；反过来要让模型下单、发消息，RAG 也做不到。真要比，应该是先看你的数据在哪、要不要执行动作。
小团队资源有限，先做哪个更划算？
先看最痛的那个问题。如果痛点是「模型答不准内部资料」，先做 RAG，链路可控、成本集中在入库；如果痛点是「模型拿不到实时数据、不能替人操作」，先做 MCP，从只读的单个工具开始。两边都痛就按上面混合顺序来，别一上来两套一起上。
两者一起用的时候，最容易出问题的地方在哪？
主要是链路过长带来的排错难。检索拿到的内容可能影响工具参数，工具返回又可能触发二次检索，出错时不知道是哪一环。做法是每一环都打上可追踪的日志字段，并且限制工具调用步数，超过就停下来报错，而不是让它自己一直循环。
