mcp vs api vs rag

做架构评审时经常被问一句「这个功能到底走 MCP 还是 API，要不要上 RAG」。三者不在一个层面上：API 是调用通道，RAG 是给模型补外部知识的方法，MCP 是把工具和数据源按统一方式接给模型的标准。混着比就会得出错误结论。这篇按职责边界拆开讲，给一套能直接套到自己项目上的判断顺序。

做架构评审最怕把三个不同层面的东西摆在一起比。API 管的是请求怎么发出去，RAG 管的是模型上哪儿找它不知道的内容，MCP 管的是模型用什么统一方式去用外部工具和数据源。把它们当成三选一，讨论到最后一定跑偏。

更实用的做法是先定位自己卡在哪一层：发请求的链路不靠谱，问题在 API 层；模型答错了是因为它压根不知道你的内部资料，问题在数据层；模型需要主动去查、去改、去触发某个系统，问题在工具协议层。定位清楚了，再谈要不要组合，组合成什么样，下面的判断顺序可以直接套到自己项目上。

先分清三层：通道、数据、工具协议

这三层的职责边界其实很清楚：API 负责鉴权、协议、超时、重试，是请求能不能稳定送达的问题；RAG 负责检索、拼上下文、标注引用，是模型能不能拿到该拿的内容的问题；MCP 负责把工具和数据源暴露成统一接口给模型调用，是模型怎么规范地使用外部能力的问题。三者不是竞品，很多项目是 API 通道打底、RAG 补数据、MCP 接工具，叠着用。

API 层

把请求发到模型或后端，解决连通性和稳定性，不关心内容对不对

RAG 层

把私有内容检索出来塞进上下文，解决模型不知道的问题，不关心模型会不会用

MCP 层

把外部能力标准化地暴露给模型，解决模型主动调用的问题，不负责数据本身怎么取

• 卡在「请求老失败、超时、鉴权报错」——先查 API 层，别急着上检索
• 卡在「模型答的东西跟公司文档对不上」——先想 RAG，别怪模型不行
• 卡在「希望模型自己去查工单、发通知、改配置」——先看 MCP 这类工具协议
• 卡在「换了个模型，工具接入代码全得重写」——这是 MCP 标准化价值最明显的位置
• 卡在「什么都要，说不清哪层的问题」——按上面的顺序一层一层排查，别同时动三层

只做 API 的场景与边界

单轮问答、格式转换、代码补全这类无状态调用，直接接 API 最省事。这时候硬加一层 MCP 只是多一次转发，多一份调试成本，收益几乎看不见。判断标准很简单：这个请求是不是「发出去、拿回来、用完就完了」，是的话就在 API 层解决。

不适用的情况也要说清楚：需要跨会话记住业务数据、需要模型自己决定调哪个内部系统时，硬塞 API 会让调用方逻辑越写越厚，最后所有决策都堆在业务代码里，模型只当了个字符串处理器。落地动作上，先把 Base URL、鉴权方式、超时和重试策略定下来，协议细节和术语口径可以到 /ai-dict/category/infra 对照着看，避免团队内部叫法不统一。

1. 定协议底座把 Base URL、鉴权方式、超时和重试策略写进接入文档，验证方式是用一个最小请求跑通全链路。
2. 确认无状态问一句这个功能要不要跨请求记住上下文，不要的话就停在 API 层，别提前引入检索或工具协议。
3. 留好扩展点在调用封装里预留一层适配，将来要不要接检索或工具，改一处而不是改一片。

什么时候必须上 RAG

判断门槛就一句话：模型答错，是因为它不知道，还是因为它不会推理。只有前者才值得上检索。如果答案依赖你内部的文档、工单、代码库，而且这些内容还在持续更新，靠提示词塞不下也维护不住，这就是 RAG 的典型场景。

反向的不适用也很明确：数据量很小且变化慢，用固定上下文或者一次结构化查询更稳；纯计算、纯生成任务本来就不需要检索，硬加检索只会引入召回声和噪音。落地时先把「哪类问题该命中哪份资料」写清楚，再谈用什么检索方式，否则检索策略调来调去都是在解一个没定义好的问题。

• 内容会持续更新、且体量塞不进提示词——RAG 的主战场
• 答案需要标注来源、要能追溯到原文——RAG 顺手就能解决
• 数据量小、变化慢——固定上下文或结构化查询更省事
• 纯计算、纯生成——不需要检索，加了反而引入噪音
• 模型是「不会推理」而不是「不知道」——换更强的提示或换模型，别先上 RAG

检索解决的是「不知道」，不解决「不会」。方向搞反，检索调得再细也救不回来。

什么时候值得引入 MCP

MCP 的价值体现在复用和替换成本上：有多个客户端要复用同一批工具，或者希望换模型时不用重写工具接入代码，标准化才划算。只有一两个内部接口、只服务一个应用，自己写函数调用更直接，省掉一层协议的调试成本。

风险点也要提前说：工具暴露得越多，模型误调用和越权的面就越大。白名单、步数上限、参数校验这些要提前设计，而不是等出了事再补。服务器挑哪家可以先翻 /mcp 看现成实现，别一上来就自己造，很多通用能力有现成的接入方式。

常见的三种组合形态

组合形态可以按两个轴来落位：答案是否依赖私有数据，模型是否需要主动执行动作。两个都不需要，就是纯 API 调用；只需要私有数据，就是 API 通道加 RAG；只需要执行动作，就是 API 通道加工具协议；两个都需要，才考虑混合型。

混合型的典型写法是把 RAG 检索本身封装成一个工具，让模型决定什么时候去查。适合问题类型杂、无法预先判断的场景。代价是多了一层不确定性：模型可能该查不查，也可能反复查同一件事，所以要在工具描述和步数上限上花心思。问答型形态模型基本不调工具，操作型形态检索需求很弱，先判断自己更像哪一种，再决定要不要上混合。

工程落地清单：超时、并发、降级、日志

选型定了不代表能跑稳，工程侧的四个点要先设计好。超时别用一个全局值兜底，检索、模型生成、工具调用分别设，检索和工具调用通常要留更长余量。并发上，检索和工具调用最容易打满内部系统，要按下游承受能力分档限流，而不是直接跟着模型请求数走。

降级和日志是排查的命根子。检索失败时退回无检索回答并明确标注，工具调用失败时给模型可读的错误信息而不是直接抛栈。日志里每一次请求都要记下走了哪条路径、检索命中了几条、调了哪个工具、耗时分布，方便复盘慢在哪。排查顺序建议是：先看是不是检索没召回，再看是不是工具参数不对，最后才怀疑模型本身。

• 超时：检索、生成、工具调用分开设，不要一个值兜底
• 并发：按下游系统承受能力分档限流，别跟着模型请求数走
• 降级：检索空了要显式标注，工具报错要给模型可读信息
• 日志：记录路径、命中条数、调用的工具、耗时分布
• 排查顺序：先怀疑检索没召回，再怀疑工具参数，最后才怀疑模型

# 排查一条异常请求的顺序示意：\n# 1. 看日志里走了哪条路径（检索 / 工具 / 直答）\n# 2. 看检索命中条数与分数分布\n# 3. 看工具调用的入参和返回\n# 4. 以上都正常，再换模型复测同一批用例

用评测代替争论：怎么验证选型对没对

选型争论往往是感觉之争，用评测来替代最省事。准备一批真实问题，覆盖三类：该检索的、该调工具的、都不该的。分别看准确率和误触发率。指标别只看答对没答对，还要看无谓的检索次数和工具调用次数，这类开销最容易被忽略又最贵。

改动检索策略或工具描述之后，重跑同一批用例，用固定基线对比，别凭感觉说变好了。样本量不用大，几十条稳定用例就能暴露方向性错误。具体模型的调用成本口径差异不小，可以到 /official-api 按当时的数字自己算，别用印象里的值做决策。

1. 建用例集覆盖该检索、该调工具、都不该三类，每类写清楚预期行为，几十条够用。
2. 跑基线固定当前方案跑一遍，记下准确率、误触发率、无谓调用次数，作为后续对比的基准。
3. 改一处再跑每次只改检索策略或工具描述中的一项，重跑同一批用例，避免多变量同时变。
4. 看成本口径到 /official-api 核对当时的价格与计费方式，把调用成本纳入选型结论。

选型时最容易想错的几件事

第一件，以为上了 RAG 模型就不会瞎编。检索不到的时候模型照样会补，必须显式处理空召回，比如让它回答「没查到」而不是硬答。第二件，以为 MCP 能替代业务后端。它只是暴露方式，权限、审计、事务还得自己在那一层管。

第三件，以为向量检索一定比关键词好。编号、专有名词、精确匹配的场景下关键词往往更准，混合检索更稳。第四件，以为方案定一次就不用改，数据规模、工具数量、客户端数量变化后都要重新评估这条边界。把这些想清楚，再回头看 MCP、API、RAG 三个词，就不会再拿它们互相替代了。

• 检索不到就显式说没查到，别放任模型补内容
• 工具协议不替代业务后端，权限和事务自己管
• 精确匹配场景下关键词检索未必输给向量检索
• 方案边界会随规模变化，定期重新评估
• 三者是叠加关系，不是三选一