无需上下文，MCP新机制让大模型主动“提需”：节约 98% token 开销，并保持准确率基本不变！

正文

请到「今天看啥」查看全文

此外，本文也基于官方的 MCP 仓库，整理了现有的所有MCP servers信息，经过筛选得到 308 个服务器、2797 个工具，并结构化保存为统一的 json 格式，发布 MCP-tools 数据集。所提出的方法能够从数据集的全量工具中，更有效地通过“大海捞针”压力测试，同时大幅缩减上下文开销；在开源的评测集 APIbank 上， 该方法能够节约 98% token 开销，并保持准确率基本不变 。

现有工作的问题

当前基于 MCP 的工具调用流程存在显著缺陷：系统会将全部工具信息注入到模型的 system prompt 中，造成严重的上下文负担。以 Github MCP Server 为例，仅该服务器便包含 26 个工具功能，产生超过 4600 个 tokens 的上下文占用。这种实现方式不仅带来明显的成本压力，更对模型输出质量构成挑战——部分模型在处理长上下文时会出现性能显著劣化的现象。

为缓解上下文压力，既往研究采用预检索策略，仅筛选最匹配的一个或数个工具纳入上下文。具体实现中，模型利用用户输入与工具数据库进行匹配，识别最相关的工具子集。然而，此类方法面临两大挑战：

• （1）基于分类器的方案需要针对性训练模型，面对新场景时泛化能力受限；

• （2）基于语义匹配的方案容易产生语义错配，因为用户表述与服务器文档描述存在差异（如"查找xx日的信息"与"基于时间条件检索"的表达不一致）。

更重要的是，预定义工具的策略还存在单次匹配的局限性：根据用户语义选定特定领域工具，一方面无法应对复杂任务（比如用户要求"调试某个文件"，实际需要代码修改、文件保存、命令执行等多个工具协同，单一工具匹配无法满足需求）；另一方面，一旦工具匹配出现偏差，后续补救机制缺失。

综合来看，现有方案均遵循"被动配置"的工作模式，未能充分发挥大模型"主动理解"的核心优势。一方面，大模型被动接受工具配置，只能在预设的工具范围内进行调用；另一方面，当工具配置出现问题时，大模型缺乏主动询问、切换工具域的能力，缺少主动的错误处理机制。

本工作的流程

我们希望释放大模型的"主动决策"能力，摆脱传统方法中将模型局限在预设工具范围内的束缚，并节约上下文空间。为此，我们从如下两方面展开改进：

• 主动工具发现 ：大模型不再局限于"从既定工具中挑选"的模式，而是转向"主动表达所需工具"的新范式，不受上下文限制。
• 主动多轮交互 ：大模型能够采用多轮调用策略，每轮专注解决特定子任务，更贴合实际工具调用的应用特征。同时，当调用结果或返回工具存在问题时，大模型能够及时识别异常，启动新的尝试循环。

方法具体内容

请到「今天看啥」查看全文