ToolMenuBench：对可靠高效LLM代理的工具菜单过滤策略进行基准测试

# ToolMenuBench：用于可靠且高效LLM智能体的工具菜单过滤策略基准测试

来源：https://arxiv.org/html/2606.15508

###### 摘要

工具增强型大语言模型智能体越来越多地在大型工具库上运行，但现有评估通常关注模型能否正确调用工具，而非可见工具菜单如何影响可靠性、效率以及安全相关的风险暴露。我们引入了ToolMenuBench，这是一个用于评估多步LLM智能体中工具菜单构建的基准测试。ToolMenuBench改变了工具菜单的大小、干扰类型、状态依赖的任务结构以及风险暴露，并报告了过滤级别和下游智能体指标，包括可见工具数量、风险工具暴露、任务成功率、错误工具调用、过早操作以及token使用量。在跨七个模型后端、三种工具菜单大小、六种过滤方法和七种评估设置的控制评估中，CMTF将任务成功率从全工具暴露下的32.1%提升至85.7%，同时平均token使用量减少约98%。因果最小工具过滤实现了最强的整体权衡，与未过滤暴露、词法过滤、状态感知过滤以及更广泛的因果路径基线相比，减少了可见工具、错误工具调用、过早操作和风险工具暴露。ToolMenuBench提供了一个可复用的评估框架，用于研究智能体-接口问题：哪些工具应该可见、何时应该可见，以及在何种成本或风险约束下可见。

## 引言

工具增强型大语言模型智能体越来越依赖外部工具来搜索信息、访问文件、更新日历、起草邮件、执行代码、查询数据库以及与结构化服务交互[10 (https://arxiv.org/html/2606.15508#bib.bib1),8 (https://arxiv.org/html/2606.15508#bib.bib2),7 (https://arxiv.org/html/2606.15508#bib.bib3),4 (https://arxiv.org/html/2606.15508#bib.bib4)]。随着这些智能体从小规模演示扩展到更大的工具生态系统，可见工具菜单成为智能体接口的核心部分。模型可能能够正确调用单个工具，但若必须在众多语义相似、部分重叠、过早、有风险或不相关的工具中进行选择，仍可能失败。

现有的工具使用基准测试在评估函数调用、API使用、参数生成和多步工具执行方面取得了实质性进展[7 (https://arxiv.org/html/2606.15508#bib.bib3),4 (https://arxiv.org/html/2606.15508#bib.bib4),6 (https://arxiv.org/html/2606.15508#bib.bib5)]。然而，许多评估将可用的工具集视为固定、精选或给定的。它们并未完全分离出工具菜单设计问题：在每个决策步骤中哪些工具应对智能体可见、可见菜单应多大、干扰物如何影响可靠性，以及过滤如何在任务成功、token成本和安全相关风险暴露之间进行权衡。

这种区分之所以重要，是因为工具暴露不仅仅是一个提示长度问题。暴露所有工具为智能体提供了最大的灵活性，但也增加了错误工具调用、过早操作和不必要的token使用的可能性。语义检索和工具剪枝方法可以减少菜单大小，但语义相关的工具并不总是对当前任务状态具有因果适用性[9 (https://arxiv.org/html/2606.15508#bib.bib6),5 (https://arxiv.org/html/2606.15508#bib.bib7)]。例如，一个日历任务可能包含搜索事件、创建事件、更新事件、删除事件和发送通知等工具。其中许多工具在领域内是相关的，但根据当前状态和目标，可能只有一个是正确的下一步操作。

最近关于因果工具过滤的工作认为，工具菜单应受前提条件、效果和任务状态进展的影响，而非仅仅基于语义相关性[3 (https://arxiv.org/html/2606.15508#bib.bib8)]。后续关于契约学习的工作研究了如何从模式、文档和执行轨迹中推断此类前提-效果契约[2 (https://arxiv.org/html/2606.15508#bib.bib9)]。这些方法表明，可靠的智能体不仅需要更好的工具调用语法：还需要对决定模型能看到和选择什么的接口进行系统评估。

我们引入了ToolMenuBench，一个用于评估多步LLM智能体中工具菜单构建的基准测试。ToolMenuBench将可见工具菜单本身作为评估对象。它测试智能体在工具库增长、干扰物变得更真实、以及过滤方法施加不同相关性、可执行性、因果必要性、效率和风险暴露概念时的行为。该基准测试支持过滤级别评估（衡量智能体在行动前被允许看到什么）和下游智能体评估（衡量执行过程中的任务成功、错误工具调用、过早操作、token使用和风险工具暴露）。

在本文中，我们报告了六种已实现过滤方法的核心控制评估：全工具暴露、关键字前5过滤、关键字前10过滤、状态感知过滤、完整因果路径暴露和因果最小工具过滤（CMTF）。ToolMenuBench也设计用于支持多种扩展，包括基于嵌入的检索、模式感知过滤、学习契约过滤、恢复菜单过滤以及成本或风险感知过滤。更广泛的目标是使工具菜单设计成为工具增强型智能体的首要评估目标。

贡献。本文做出以下贡献：

1. 1. 我们引入了ToolMenuBench，一个用于评估可见工具菜单构建如何影响多步LLM智能体可靠性、效率和安全相关暴露的基准测试。
2. 2. 我们定义了一个干扰物分类法，涵盖语义干扰物、近似重复工具、模式兼容的错误工具、过早工具、风险工具和跨领域干扰物。
3. 3. 我们定义了工具菜单评估的过滤级和下游指标，包括可见工具数量、风险工具暴露、任务成功、错误工具调用、过早操作和token使用量。
4. 4. 我们报告了跨多个模型后端、工具菜单大小、过滤方法和干扰物设置的核心控制评估，表明因果对齐的菜单可以提高成功率，同时减少工具暴露和token使用量。
5. 5. 我们提供了基准测试工件，包括任务定义、工具注册表、金轨迹、工具契约、干扰物注释、过滤基线、评估脚本和结果生成实用程序。

## II 背景与相关工作

### II-A 工具增强型LLM智能体

工具使用已成为将大语言模型扩展到文本生成之外的核心机制。ReAct引入了交错推理和行动，使模型能够将基于语言的推理与外部动作结合起来[10 (https://arxiv.org/html/2606.15508#bib.bib1)]。Toolformer表明语言模型可以在推理过程中学习调用外部API[8 (https://arxiv.org/html/2606.15508#bib.bib2)]。ToolLLM和ToolBench将此设置扩展到大量真实世界API和多步工具使用任务[7 (https://arxiv.org/html/2606.15508#bib.bib3)]，而API-Bank则在受控设置中评估了工具增强对话和API使用[4 (https://arxiv.org/html/2606.15508#bib.bib4)]。这些工作确立了工具使用作为核心智能体能力，通常使用固定、精选或任务提供的工具集。ToolMenuBench研究一个补充性的系统问题：当有许多工具可用时，应如何构建可见工具菜单？

### II-B 函数调用与工具使用基准测试

函数调用基准测试评估模型能否生成有效且有用的工具调用。API-Bank、ToolBench和伯克利函数调用排行榜衡量诸如工具选择、参数构建、多轮函数调用和代理工具使用等能力[4 (https://arxiv.org/html/2606.15508#bib.bib4),7 (https://arxiv.org/html/2606.15508#bib.bib3),6 (https://arxiv.org/html/2606.15508#bib.bib5)]。这些基准测试对于衡量模型级别的工具使用能力至关重要，但它们通常假设候选工具集已被选定。一个在小型精选工具集上测试的模型，当暴露于包含近似重复项、模式兼容的错误工具、过早操作和风险操作的大型注册表时，其行为可能会不同。ToolMenuBench通过评估不同菜单构建策略如何影响过滤级别和下游智能体行为，来分离这个接口变量。

### II-C 工具检索与语义过滤

随着工具库的增长，需要检索和剪枝方法来减少提示大小和歧义。工具检索方法使用词法匹配、嵌入相似性或学习到的检索模型来选择候选工具。最近的工作表明，即使检索模型在传统检索任务上表现良好，它们也并非总是工具精明的[9 (https://arxiv.org/html/2606.15508#bib.bib6)]。ToolScope通过合并重叠工具并应用上下文感知过滤来解决相关的可扩展性和歧义问题[5 (https://arxiv.org/html/2606.15508#bib.bib7)]。这些方法很有用，但它们主要将过滤视为一个相关性或冗余减少问题。ToolMenuBench旨在将检索式过滤与状态感知和因果过滤一起评估，因为一个工具可能在语义上相关，但在当前步骤仍然过早、不必要或不安全。

### II-D 状态感知与因果工具过滤

状态感知过滤会暴露那些所需参数或前提条件在当前任务状态下已满足的工具。这可以减少无效调用，但可执行性并不等同于有用性：一个可调用的工具可能无法推进当前目标。因果过滤用轻量级前提条件和效果来表示工具，然后根据工具在将当前状态移向目标中的角色来暴露工具[3 (https://arxiv.org/html/2606.15508#bib.bib8)]。因果最小工具过滤（CMTF）仅暴露下一个因果必要的边界，而Contract2Tool研究如何从模式、文档和执行轨迹中学习这种前提-效果契约[2 (https://arxiv.org/html/2606.15508#bib.bib9)]。ToolMenuBench基于这些思想，在共享基准测试下评估状态感知和因果过滤，同时也为学习契约设置定义了基准测试扩展。

### II-E 风险、成本与现实干扰物

现实世界的工具菜单包含的不只是不相关的工具。它们通常包括近似重复的API、模式兼容的错误工具、过早操作、跨领域干扰物以及高风险操作，例如删除文件、发送消息、共享文档、更改权限或修改外部状态。关于自修复代理编排器的补充工作研究了工具使用失败发生后的运行时可靠性，包括失败分类、预算恢复和验证器引导的轨迹修复[1 (https://arxiv.org/html/2606.15508#bib.bib11)]。ToolMenuBench侧重于更早的接口层：在模型选择之前哪些操作是可见的。它通过分类法显式建模现实干扰物，并不仅衡量任务成功和token使用，还衡量正确下一步工具暴露、额外暴露的工具、风险工具暴露以及未授权的风险工具暴露。

### II-F 基准测试空白

现有基准测试推进了模型级别函数调用和多步API使用的评估，而检索、因果过滤和运行时可靠性工作从不同角度改进了工具选择和恢复。仍然缺少的是一个将可见工具菜单本身作为评估对象的基准测试。ToolMenuBench通过跨菜单大小、干扰物类型、任务状态依赖、token成本和风险暴露来评估工具菜单构建，并支持契约质量评估和策略感知评估的扩展，填补了这一空白。它将工具菜单设计定位为可靠工具增强型LLM智能体的首要系统问题。

## III 基准测试设计

ToolMenuBench旨在评估多步LLM智能体中的工具菜单构建。该基准测试将工具使用评估中经常混淆的三个问题分开：正确的下一步工具是否可见、模型是否选择了它、以及由此产生的轨迹是否完成了任务。为了支持这种分离，ToolMenuBench包含一个受控的工具注册表、多步任务、金轨迹、前提-效果契约、干扰物注释、风险标签、可选成本标签以及评估脚本。

### III-A 基准测试概述

每个基准测试实例由一个用户任务、一个初始符号状态、一个目标状态、一个工具注册表和一个过滤方法组成。在每个决策步骤，过滤方法将任务、当前状态、目标和注册表映射到可见工具子集。智能体接收任务、当前状态和可见工具菜单，然后选择一个工具调用。一个确定性的环境执行所选工具，根据工具效果更新符号状态，并返回观察结果。该过程持续进行，直到达到目标状态或耗尽步骤预算。

这种设计支持过滤级别和下游评估。过滤级别评估询问过滤方法是否在模型行动前暴露了正确的下一步工具。下游评估询问模型在操作于该过滤菜单下时是否完成任务。

### III-B 任务领域

ToolMenuBench专注于工作流领域，在这些领域中多步工具使用很自然，并且工具混淆可能导致有意义的失败。该基准测试包括：

- •日历工作流：搜索事件、阅读事件详情、创建事件、更新事件、删除事件和发送事件通知。
- •电子邮件工作流：搜索消息、阅读消息、起草回复、发送电子邮件、转发消息和应用标签。
- •文件和文档工作流：定位文件、阅读文档、总结内容、编辑文件、共享文档和删除文件。
- •联系人和身份工作流：查找联系人、解析歧义收件人、检查确认或授权状态。

选择这些领域是因为它们需要有序的状态转换。例如，智能体可能需要先搜索事件才能更新它，先阅读文件才能总结它，或者先起草电子邮件才能发送它。

### III-C 工具注册表

该基准测试使用一个合成但结构化的工具注册表，旨在隔离受控的工具菜单条件。每个工具都用名称、自然语言描述、输入模式、输出模式、所需状态变量、产生的状态变量、风险标签、可选成本标签、领域标签以及适用的干扰物类别来表示。

注册表包含任务相关工具和干扰物工具。任务相关工具至少在一个金轨迹中需要。干扰物工具被设计为在某些任务状态下看似合理但实际不正确。这使得基准测试对现实工具菜单失败而非仅仅是随机无关噪声敏感。

### III-D 金轨迹与状态变量

每个任务包含一个金轨迹，指定了预期的工具序列以及每一步后产生的状态变量。令 \(s_t\) 表示步骤 \(t\) 之前的符号状态，\(g\) 表示目标条件。一个金轨迹由以下序列组成：

\(a_1, a_2, ..., a_k\)，\(a_1, a_2, ..., a_k\)，