W
AI-Wiki
CONCEPT

LLM工具选择

定义

LLM工具选择 是指大型语言模型在可调用的多个外部工具之间，依据用户任务意图选择最合适工具并完成调用决策的过程。

这里的“选择”不只是输出一个工具名称，还包括几个不可分割的判断：

  • 识别任务真正需要哪类外部能力，而不是仅凭表面关键词匹配。
  • 理解各个工具的功能边界，区分哪些工具“看起来相似”但实际职责不同。
  • 判断调用该工具需要哪些参数、参数缺了什么、哪些信息要先向用户追问。
  • 在候选工具语义相近、描述重叠或响应不稳定时，决定是否需要先做验证再执行。

因此，LLM工具选择 本质上是“任务理解 + 工具发现 + 候选排序 + 参数适配 + 可选验证”的组合问题，而不只是 函数调用 接口层的一次路由。

在本文语境中的含义

在本文语境中，LLM工具选择 被视为构建 AI 代理时的核心瓶颈之一。

原因在于：大语言模型 虽然具备文本生成、逻辑推理和编程能力，但仍受两类基础约束影响：

  • 训练数据是固化的，不能天然掌握实时外部世界状态。
  • 上下文窗口有限，无法无代价地阅读和比较大量工具说明。

这意味着，LLM 本身不能替代真实外部服务。它可以理解“我要规划一次旅行”这样的需求，但若要真正完成任务，仍需要调用外部工具访问实时数据与业务系统。

文中的典型场景是旅行规划：用户希望系统帮忙安排出行时，代理可能需要同时访问航班信息、酒店可用性、目的地天气等不同服务。即便模型表达能力很强，如果没有对应 API 或工具，它也不能真的查询机票库存、酒店空房或未来天气。因此，工具不是可有可无的附属物，而是让代理具备功能性服务能力的前提。

与 模型上下文协议、函数调用 的关系

函数调用 与 模型上下文协议 解决的核心是“怎么接入工具”的标准化问题，而不是“在大量工具中怎么找到最合适那个”的问题。

文中明确提到，Anthropic 提出的 模型上下文协议（Model Context Protocol, MCP）旨在建立 AI 系统连接外部数据源与服务的通用标准，让 LLM 可以与云盘、聊天系统、代码托管平台、数据库等外部能力交互。它更像一种统一适配器。

但统一了接入方式，并不等于自动解决了工具发现与选择问题。即使所有工具都以 MCP 或函数调用 schema 的形式暴露给模型，模型仍然要面对下列困难：

  • 工具总量可能从几个扩展到几十、几百甚至上千。
  • 很多工具功能重叠，只在适用条件或参数要求上存在细微差异。
  • 模型需要在有限上下文内比较所有描述，成本和错误率都会上升。

所以，模型上下文协议 与 函数调用 更偏向“工具接入标准”；而 LLM工具选择 则是“工具发现、筛选、决策和执行”的上层系统能力。

关键困难：提示词膨胀与决策退化

文中讨论的直接痛点是提示词膨胀。

在简单做法中，开发者会把所有可用工具的描述——包括功能定义、参数需求、使用方式——一次性放进提示中交给 LLM。工具数量较少时，这种方式通常还能工作；但当工具数扩展到 50、100，甚至 1000 个时，问题会迅速恶化。

主要退化体现在两个方面：

1. 上下文被工具描述挤占

大量工具说明会消耗大量 token，占据原本应该留给用户问题、对话历史和推理过程的上下文窗口。结果是模型可用于理解真实任务的信息空间反而被压缩。

2. 比较成本和误判率上升

即使上下文窗口足够大，要求 LLM 直接阅读并比较数百个工具描述，本身也会造成明显的效率和准确率下降。尤其在功能重叠、差异细微的工具之间，模型更容易：

  • 选到次优工具；
  • 把相似描述误认为正确工具；
  • 甚至幻觉出并不存在的工具或接口。

也就是说，工具越多，并不意味着代理能力线性增强；如果缺少有效筛选机制，反而会因为信息过载导致整体性能下降。

理想机制：先缩小候选范围，再做最终决策

文中对理想机制的描述非常明确：系统不应让主 LLM 先看完整个工具库，而应先通过独立步骤缩小候选工具范围，再让主 LLM 在聚焦后的上下文中完成最终选择。

这也是 RAG-MCP 所体现的基本思想：把工具选择从“全量阅读后判断”改为“先检索，再生成”。

具体来说，这种机制包含两层分工：

  • 第一层由检索器或语义搜索模块负责，在外部工具索引中找出与当前任务最相关的前 k 个候选工具。
  • 第二层由主 LLM 在较小、较聚焦的候选集合中，结合工具 schema、参数需求和任务上下文做最终调用决策。

这种设计的关键价值，不只是减少 token，更在于把“工具发现”与“任务执行”解耦。主 LLM 不再承担从上千个工具里做初筛的负担，而是聚焦在更接近自己优势的推理、参数组织和执行判断上。

典型机制组成

结合文中的 RAG-MCP 方案，LLM工具选择 可以拆成以下几个组成环节：

1. 工具索引构建

把所有工具描述存入外部索引系统，通常是向量数据库。索引内容不仅可以包含工具 schema，也可以包含使用示例等辅助描述。每个工具会被转换为向量表示，用于保留其语义特征。

2. 查询编码与候选检索

当用户提出任务，例如“帮我预订下周二去伦敦的航班”，系统先对任务做语义编码，然后在工具索引中搜索语义最相关的工具。文中提到这一检索器可以是较轻量的 LLM，也可以是语义搜索算法；实验实现中使用过类似 Qwen-max 的模型进行编码和检索。

3. 候选排序

检索出来的候选工具并不是平铺直叙地交给主模型，而是先按相关度排序。这样主 LLM 接收到的上下文已经经过第一轮压缩。

4. 可选验证

文中还强调了一个重要但常被忽略的步骤：验证。系统可以为排名靠前的候选工具生成合成示例查询，测试它们的兼容性与响应能力，以排除那些语义上看似相关、但实际不兼容或无响应的工具。

这说明 LLM工具选择 不应被理解为一次静态分类任务，而应被理解为一个带反馈的决策流程。

5. 最终执行

在候选范围被压缩后，主 LLM 只接收最优或前几个工具的模式与参数信息，再通过 函数调用 接口完成具体任务执行。

可量化评估，不只是主观体验

文中一个重要结论是：LLM工具选择 能力可以被定量评估，而不只是凭“感觉更聪明”来判断。

研究团队设计了专门的“MCP 压力测试”来测量模型在干扰工具数量不断增加时的表现。测试方式是：

  • 每次给模型 N 个 MCP 模式；
  • 其中只有 1 个是完成 WebSearch 任务真正需要的目标工具；