AI-Wiki

定义

提示词膨胀 是指在把信息提供给大型语言模型时，系统将过多内容一次性塞入输入上下文，导致 token 消耗快速上升，并进一步压缩模型真正可用于理解任务、保留历史和展开推理的有效空间。

在本文讨论的特定语境里，它不是泛指一切长提示，而是特指：当系统接入越来越多模型上下文协议（MCP）工具后，采用“把所有工具描述、函数模式、参数要求、使用说明一次性全部注入提示”的朴素做法，由此产生的上下文膨胀问题。

也就是说，这里的核心矛盾不是“提示词长了一点”，而是工具库扩张时，全量工具 schema 注入会系统性挤占上下文窗口，并恶化工具选择质量。

文章讨论的是 LLM工具选择困境：为了让大模型完成现实任务，系统通常要给它接入外部工具，例如航班查询、酒店检索、天气服务、数据库访问、GitHub、Slack、Google Drive 等接口。

当工具数量很少时，把全部工具说明直接放进提示里通常还能工作；但当工具数从少量增长到 50、100，甚至 1000 级别时，这种方法会迅速恶化。

本文因此把 提示词膨胀 视为 RAG-MCP 的问题起点：

换言之，本文强调的不是单纯容量不足，而是容量、筛选和决策负担同时失衡。

提示词膨胀最直接的后果，不只是 token 数字变大，而是会挤占原本应该留给以下内容的空间：

文章明确指出，工具描述累积会大量消耗 token，占用 LLM 有限的上下文窗口，使实际用户问题、历史消息以及复杂推理可利用的空间都减少。

因此，提示词膨胀 的危害不能简化成“成本更高”或“输入更长”，它还意味着模型处理核心任务的注意力预算被无关工具信息稀释。

即便假设上下文窗口足够大，问题也不会自动消失。因为模型仍然要在数十到数百个工具描述之间进行筛选、比较和判断，尤其当这些工具功能重叠、差异细微时，认知负担会显著上升。

这种负担会带来多种后果：

因此，提示词膨胀 不只是“上下文被撑大”，还是候选项过多导致的决策退化。

在工程层面，全量注入还会带来额外计算与系统开销。模型需要阅读、比较大量并不相关的工具描述；在某些系统架构中，工具注册还可能伴随组件实例化或预初始化，进一步浪费资源。

文章据此指出：如果系统能只激活或准备检索出的少量相关工具，就能降低整体资源消耗。

本文强调了一个明显的规模效应：

也就是说，提示词膨胀 不是线性地“多一点负担”，而是随着工具库扩张，越来越快地演化成系统瓶颈。

文章在压力测试中还将候选规模进一步推到更极端的水平：模型每次面对 N 个 MCP 模式，其中仅 1 个是目标工具，其余都是干扰项，N 从 1 一直变化到 11100。测试结果显示，随着 MCP 数量增加，成功率明显下降，这定量证明了简单增加可用工具数量的方法难以持续。

从机制上看，本文中的 提示词膨胀 主要由三个因素叠加造成：

所以，哪怕模型理论上“看到了所有工具”，也不代表它就能更好地选择。恰恰相反，候选过多常常会让真正相关的那个工具被淹没。

RAG-MCP 的提出，正是为了缓解这种特定形式的 提示词膨胀。

它借用了 RAG 的“先检索、后生成”思想，但检索对象不是知识片段，而是工具描述。基本思路是：

这意味着 RAG-MCP 不是靠“给模型更大的提示框”来硬扛膨胀，而是通过把工具发现过程从主模型推理中解耦，主动减少无关工具进入上下文。

本文也据此强调一个重要判断：工具越多，单纯扩大上下文并不能根治选择质量问题。因为即使窗口足够容纳全部描述，模型在大量相似工具之间的筛选负担依然存在。

文章给出了直接的实验数字，用来说明 提示词膨胀 可以被显著缓解。

在 MCPBench 的网络搜索子集上，以 qwen-max-0125 为基础 LLM，比对朴素全量注入、关键词匹配与 RAG-MCP 后，结果显示：