RAG-MCP新架构，终结大模型提示词膨胀？

由于提示词的膨胀以及工具选择变得复杂，大语言模型（LLMs）很难高效地使用越来越多的外部工具，特别是那些由模型上下文协议（MCP）定义的工具。为此，需要新的架构来解决， RAG-MCP 框架正是解决这个提示词膨胀的问题。

LLand520

972人浏览 · 2025-07-07 09:52:41

LLand520 · 2025-07-07 09:52:41 发布

RAG-MCP 是一种“检索增强生成”的方法。它通过提前筛选出最相关的工具来解决这个问题。具体来说，在调用大语言模型之前，RAG-MCP 会先用语义检索技术，从外部的索引中找出和当前查询最相关的 MCP 工具。只有这些被选中的工具描述才会被传递给大语言模型。这样一来，提示词的长度大幅减少，决策过程也变得更加简单。

下文详细剖析之。

RAG-MCP 架构设计剖析

1、提示词膨胀（Prompt Bloat）问题剖析

提示词膨胀（Prompt Bloat）是一个严重的问题：如果在大模型的上下文中为每一个可能的工具都提供定义或使用说明，会占用大量的空间，并且可能会让大模型感到“压力山大”。

我们在 AI 应用落地中发现，随着工具数量的增加，很难在单个提示词中描述大量的 API 或工具。而且，许多 API 的功能非常相似，只有细微的差别。如果一次性把太多工具都塞进去，不仅会超出大模型的上下文长度限制，还可能让大模型感到困惑，分不清这些功能相似的工具。

这直接导致了第二个问题：决策成本太高。面对一长串功能相似的工具，大模型在选择是否调用以及调用哪个工具时，会面临更复杂的决策。工具越多，出错的可能性就越高。比如：大模型可能会选择了一个不太合适的工具，或者误解了某个工具的功能。实际上，即使是像 Qwen-3 这样的先进模型，在面对众多 API 选项时，也可能会“脑洞大开”，虚构出一个实际不存在的 API；而 Anthropic 的 Claude 可能会为用户请求选择错误的库。这些失败案例说明，简单地增加工具数量，可能会让大语言模型（LLM）的性能下降。

2、RAG-MCP 解决方案剖析

为了解决这些问题，提出了 RAG-MCP 新架构设计方案，这是一个将检索增强生成（RAG）与模型上下文协议框架结合起来的方法。它的核心思想是：不要一次性把所有工具都展示给大语言模型，而是根据用户的查询，动态地找出最相关的工具子集。

在 RAG-MCP 架构设计中，大量的工具描述（比如：MCP 函数模式、使用示例等）都存储在一个外部的语义索引中。当一个新的查询到来时，一个专门的检索器（比如：向量空间语义搜索）会先选出最有可能对这个查询有用的前k个候选工具。然后，只有这k个工具的描述会被注入到大语言模型（LLM）的提示词中（或者通过函数调用 AP I提供），这样就能大大减少上下文的长度和复杂性。这个检索步骤就像是一个“聚焦过滤器”，减少了提示词的冗余，帮助大模型更容易地做出选择。

这种方法有点像检索增强问答系统的工作方式：不是把整个维基百科都给的模型，而是只检索相关的文章。在这里，我们检索的不是静态的知识，而是实时的、可以操作的工具知识。还有一个额外的好处是可扩展性：因为工具信息存储在外部索引中，新工具或更新的 API 可以通过更新索引来整合，而不需要重新训练 LLM，这样就能确保系统始终保持最新状态。简单来说，检索的作用就是在正确的时间提供正确的工具，从而减轻模型的决策负担。

3、RAG-MCP 新架构设计

3.1、RAG-MCP框架

为了解决提示词膨胀问题，RAG-MC P将检索增强生成（RAG）原则应用于工具选择。我们不再将所有 MCP 描述一股脑地塞给大语言模型，而是维护一个包含所有可用 MCP 元数据的外部向量索引。在处理用户查询时，整个过程分为三个关键步骤：

步骤一、检索

一个轻量级的基于大语言模型的检索器会对用户的任务描述进行编码，并在 MCP 索引上执行语义搜索，返回与任务最相似的前k个候选 MCP。

步骤二、验证

对于每个检索到的 MCP，RAG-MCP 可以生成一个少样本示例查询，并测试其响应，以确保基本兼容性。这一步在调用之前起到了“合理性检查”的作用。

步骤三、调用

只有单个最佳的 MCP 描述（包括其工具使用参数）会被注入到大语言模型的提示中或通过函数调用 API 传递给大模型。然后，大模型在不考虑工具发现的情况下进行规划和执行。

这种设计带来了以下好处：

缩小提示词规模：通过仅提供相关的 MCP 元数据，即使完整的工具注册表很大，RAG-MCP 也能避免上下文窗口过载。
降低认知负担：大语言模型不再需要从数百个干扰项中筛选，从而提高了选择准确率并减少了幻觉现象。
资源高效：与传统的 MCP 客户端（比如：Claude 或早期的 GPT-4 集成）不同，它们在交互之前必须实例化所有已注册的 MCP 服务器，而 RAG-MCP 仅激活所选的 MCP，降低了启动成本，并能够在没有基础设施瓶颈的情况下支持任意大的工具集。
多轮稳健性：在跨越多个轮次的对话中，大语言模型无需重新纳入所有 MCP；基于检索增强生成的 RAG-MCP 检索器可动态处理工具调用，为特定任务推理腾出上下文空间。

3.2、新架构设计三步流程示意图

RAG-MCP 的操作可以概括为以下三个核心步骤，架构图如下图所示：

第一、任务输入 → 检索器

用户的自然语言任务被编码并提交给检索器。

第二、检索器 → MCP 选择与验证

检索器搜索 MCP模式的向量索引，根据语义相似度对候选对象进行排序，并可选择通过合成示例对每个候选对象进行测试。

第三、使用选定的 MCP 执行大语言模型

大语言模型仅接收选定的 MCP 模式和参数，并通过函数调用接口执行任务。

通过将工具发现与生成解耦，RAG-MCP 确保大语言模型能够扩展到数百或数千个 MCP，而不会出现提示膨胀或决策疲劳。这类似于 RAG 系统通过仅检索相关段落来避免用整个语料库使大语言模型不堪重负。

4、RAG-MCP 新架构测试验证

4.1、实验设置

我们在 MCPBench 的网络搜索子集上进行了评估，将其作为测试平台。每个基线方法进行20次独立试验，若产生超过10个正确答案，则认为该方法成功。每次试验中，大模型最多与 MCP 服务器进行10轮交互以得出最终响应。我们使用 Deepseek-v3 作为评估器，确保实验在可控网络环境下进行，避免因连接问题导致请求失败。所有试验由 qwen-max-0125 驱动。