菜单即执行先验：State-Path工具菜单助力在线代理

# 菜单即执行优先级：在线智能体的有状态路径工具菜单
来源：https://arxiv.org/html/2609.09395
**作者**  
**Bo Yan** | 单位：中佛罗里达大学计算机科学系与人工智能研究所 | 邮箱：[bo949643@ucf\.edu](mailto:)  
**Weikai Lin**  
**Song Wang**††thanks:通讯作者\. | 单位：中佛罗里达大学计算机科学系与人工智能研究所 | 邮箱：[wlin33@ur\.rochester\.edu](mailto:)

###### 摘要
语言模型通过工具执行操作，但实际智能体面对的工具库包含数千个接口。我们引入 **工具菜单** 概念，作为在执行前向智能体展示的简短、有序的可用工具子集。智能体只能调用此菜单中的工具。多步任务需要最终动作以及按可用顺序排列的、创建其输入的先决工具。当前构造方法按请求相关性对工具进行排序，这可能凸显最终动作，但忽略或延迟了不明显的生产者。我们引入 **状态路径** 概念，作为从可观察请求状态到期望结果的预执行路线，并提出 **有状态路径工具菜单** 来学习该路径。我们的框架将菜单视为这些路径的 **执行优先级**。其编码器表示哪些工具可以从当前状态运行、它们的输出如何满足后续输入，以及训练路径中哪些顺序会重复出现。检索器覆盖可执行入口、缺失输入的生产者以及最终动作。重排序器随后将生产者置于消费者之前。在 ToolBench 上，我们的菜单将在线成功率从 0\.737 提升至 0\.898，并在不改变智能体的情况下优于检索、重排序、生成和路由基线。有状态路径菜单用 32 个工具覆盖了比官方列表（使用 128 个工具）更完整的链条，且其成功率增益在不同模型容量的执行器家族中持续存在。

**参考图注**  
图 1：相关性菜单可能暴露目标，但没有可运行的路线。对于收据请求，面向答案的工具与文本匹配，但依赖于检索订单、创建收据和恢复收件人地址的早期工具。有状态路径工具菜单使用相同的菜单预算，以可执行顺序暴露该路线。在线智能体和调用预算保持不变。

## 1 引言
语言模型通过将指令转化为外部操作而成为智能体（Schick et al\.，2023；Yao et al\.，2023）。在每个步骤，智能体选择一个工具并使用其观察结果来选择下一个操作。随着操作空间的增长，这个循环变得困难。例如，ToolBench 公开了超过 16,000 个 API（Qin et al\.，2024）。因此，实际系统在执行前会检索一个小的候选集（Patil et al\.，2024；Trivedi et al\.，2024）。我们引入术语 **工具菜单** 来表示这个请求特定、有序的接口。它在整个执行过程中固定选定的接口及其显示顺序，同时保留智能体、其在线执行循环和原始调用预算。大多数菜单构造器按请求相关性对工具进行排序（Shi et al\.，2025；Qu et al\.，2024；Zheng et al\.，2024）。图 1 显示了为什么仅靠相关性在多步任务上会失败。左侧面板在收据和地址输入存在之前，将 **SendEmailReceipt** 排在第一位。中间面板恢复了其按可执行顺序排列的先决调用。右侧面板显示了在固定智能体和 32 个工具预算下的相应收益。冲突在于个体相关性与路线完整性（He et al\.，2026；Liang et al\.，2026）。这一差距激发了为有界菜单制定路线级构建目标。因此，我们提出 **状态路径**，即执行前经过工具诱导状态的路线。它从可见字段开始，经过产生缺失输入的工具，最终到达请求的结果。个体相关性无法表达这些调用是否构成完整路线。状态路径使这条路线显式化，并将菜单转变为首次调用前的 **执行优先级**。

为了学习这些路径，我们提出了 **有状态路径工具菜单**，包含编码器、检索器和重排序器。编码器从请求状态、工具模式和训练路径中学习关系感知的工具表示。检索器使用这些表示来选择 32 个具有互补路径角色的工具。重排序器将选定集合转换为生产者先于消费者的顺序。在操作所得菜单时，在线智能体保持其原始的执行循环和调用预算。我们的贡献有三点：
- • 我们将有界、有序的工具菜单表述为执行优先级，并指出状态路径完整性是基于相关性构建中缺失的目标。
- • 我们引入了有状态路径工具菜单，它共同表示状态兼容性，覆盖互补路径角色，并在不改变在线智能体或其调用预算的情况下，将生产者置于消费者之前。
- • 我们展示了有状态路径跨工具库、评估器和执行器家族，提高了端到端任务成功率、完整链覆盖率和可执行入口率。成对结果和受控变体将这些增益与相同菜单预算内的路线覆盖率和顺序联系起来。

**表 1：工具使用方法族决策的比较。** 列显示了每个族选择的内容、选择发生的时间、它使用的依赖信息以及执行是否更新该选择。

## 2 相关工作
#### 工具增强语言模型和基准。
Toolformer 和 ReAct 将工具调用集成到语言模型的生成和推理中（Schick et al\.，2023；Yao et al\.，2023）。Gorilla、HuggingGPT、ToolACE 和 API-Bank 将工具使用扩展到更大和更多样化的接口（Patil et al\.，2024；Shen et al\.，2023；Liu et al\.，2025；Li et al\.，2023）。ToolBench 强调库规模，AppWorld 和 τ\-bench 需要有状态执行，而 UniToolCall 和 TRAJECT\-Bench 评估多步结构（Qin et al\.，2024；Trivedi et al\.，2024；Yao et al\.，2025；Liang et al\.，2026；He et al\.，2026）。这些设定使得执行前可见的工具本身成为研究对象。

#### 工具检索、生成和路由。
ToolRet 和 ToolRerank 通过任务特定检索和层次感知重排序改进查询到工具的匹配（Shi et al\.，2025；Zheng et al\.，2024）。Tool-REX 扩展文档不充分的工具文本，而 SkillRouter 研究注册表规模的全文路由（Lu et al\.，2025；Zheng et al\.，2026）。ToolGen 直接生成工具标识符并移除外部检索器（Wang et al\.，2025）。所有这些方法都改进了为请求选择的工具的标识或表示。COLT 是在处理覆盖率方面最接近的方法。它使用协作查询到工具的结构来恢复更完整的集合，尽管选定的工具仍然是无序的（Qu et al\.，2024）。有状态路径要求每个先决条件必须从可观察状态可达，并且必须在显示菜单中出现在其消费者之前。KELP 在知识图谱增强方面得出了一个相关见解，它根据输入对直接和间接证据路径进行评分（Liu et al\.，2024a）。KELP 使用这些路径提供事实背景。有状态路径使用状态和模式方向来组装一系列可执行的调用。表 1 在单一预执行视图下，比较了这些方法族的选择对象、决策时间、依赖信号和执行循环。

#### 轨迹结构和自适应工具规划。
动态工具依赖检索根据不断变化的函数调用计划调整检索条件（Patel et al\.，2026）。AutoTool 使用历史转换进行工具选择，ToolTree 使用执行反馈搜索前瞻性分支（Jia and Li，2026；Yang et al\.，2026）。这些规划器在智能体进行过程中更新工具选择。有状态路径研究的是在首次调用前可以暴露一次，同时保持在线循环不变的路线。预执行构建提供初始操作空间，而在线规划器可以在新观察后修改该路线。这两个决策发生在智能体循环的不同时间点，可以结合使用。一次选择菜单使得覆盖率和显示顺序直接可观察。附录 E 将已发表的依赖机制应用于该预执行接口，前提是其已发布的设计允许这样做。先前的证据表明模型对隐藏信息和选项顺序敏感，这也支持将菜单位置视为接口的一部分（Liu et al\.，2024b；Pezeshkpour and Hruschka，2024）。

## 3 方法
我们设计有状态路径工具菜单来解决短菜单造成的 2 个失败。覆盖失败发生在个体相关的工具遗漏了创建所需输入的安静桥梁时。顺序失败发生在正确的工具都存在，但消费者出现在使其可执行的生产者之前时。我们的框架将路线成员资格和显示顺序作为一个预执行决策来共同学习。图 2 追踪了这一一次性构建过程。左上角面板显示训练轨迹如何教构造器哪些工具进入路线以及哪些调用先于其他调用。右上角面板将这些学习到的关系应用于目标轨迹隐藏的新请求。我们的编码器首先构建状态和关系感知的工具表示。我们的检索器使用它们来覆盖互补路径角色。我们的重排序器将选定的集合转换为可执行前缀。下方横条显示在线智能体仅接收最终菜单，而其执行循环保持不变。完整的映射为：
\[
\mathcal{C}_{0} = \mathrm{Encode}(q, s_{0}(q), \mathcal{T}, \mathcal{M}),
\]
\[
\mathcal{C}_{K} = \mathrm{Cover}_{R_{\theta}}(\mathcal{C}_{0}, K),
\]
\[
\pi_{K} = \mathrm{Order}_{O_{\psi}}(\mathcal{C}_{K}, q, \mathcal{M}).
\]
训练轨迹提供监督和路径统计。当构建最终菜单时，目标轨迹保持隐藏。我们使用路线成员资格、入口和路径角色目标来训练编码器和检索器。我们使用来自相同轨迹的槽位和成对优先级目标来训练重排序器。这种分工赋予了检索器决定哪些工具进入菜单的责任。它赋予了重排序器决定这些工具出现在哪里的责任。附录表 11 记录了每个阶段可用的数据。附录 B 通过所有三个组件追踪了收据示例。

### 3.1 问题表述
令 \(\mathcal{T} = \{u_{1}, \ldots, u_{N}\}\) 为一个工具库。每个工具 \(u_{i}\) 携带文档 \(d_{i}\)、必需输入 \(I_{i}\) 和产生的输出 \(O_{i}\)。一个请求 \(q\) 暴露初始状态 \(s_{0}(q)\)，包含在任何调用前可用的字段、对象和约束。构造器返回一个菜单 \(\pi(q) = (u_{\pi_{1}}, \ldots, u_{\pi_{K}})\)，其中 \(K=32\)。智能体只能调用此有序接口中的工具。当工具的必需输入已被观察到或由先前调用产生时，该工具是可执行的。我们定义 **状态路径** 作为关于可执行链的预执行假设。
\[
s_{0}(q) \rightarrow \textsc{Entry} \rightarrow \textsc{Bridge}^{*} \rightarrow \textsc{Target} \, [\rightarrow \textsc{Terminal}].
\]
我们为此路线中的每个工具分配四种角色之一。**入口** 工具可以从 \(s_{0}(q)\) 运行。**桥梁** 工具创建链中稍后需要的输入。**目标** 工具解决主要请求。可选的 **终点** 工具交付或提交结果。当单个调用既解决又提交请求的结果时，目标和终点角色重合。对于收据请求，**LookupOrder** 可以使用可见的订单号。**CreateReceipt** 和 **GetCustomerEmail** 产生 **SendEmailReceipt** 所需的字段。发送工具同时作为目标和终点操作。其紧密的词汇匹配在早期调用提供其输入后变得有用。此示例将文本相关性与可执行性分开。最终动作很容易检索，而桥梁工具决定了路线是否能运行。我们将每个成功的训练轨迹写为 \(\tau = (g_{1}, \ldots, g_{T_{\tau}})\)。我们从这些轨迹中学习成员资格、入口、角色和优先级，并收集它们的路径统计信息于 \(\mathcal{M}\) 中。对于一个新请求，构造器必须从 \(q\)、\(s_{0}(q)\)、工具模式和 \(\mathcal{M}\) 推断隐藏的路径。然后将有序菜单暴露给智能体。附录 C 收集了符号和张量定义。

**图 2：有状态路径在执行前构建可运行路线。** 检索器选择 32 个覆盖入口、桥梁、目标和终点角色的工具。重排序器将生产者置于消费者之前，而在线智能体在首次调用前接收完成的菜单。

### 3.2 有状态路径编码器
为了恢复被词汇相似性隐藏的依赖关系，我们在编码器中引入 3 个方向信号。它们表示一个工具是否可以现在运行、它是否产生稍后需要的字段，以及哪种顺序在训练路径中重复出现。对于可见字段 \(F_{0}(q)\) 以及工具输入和输出 \(I_{i}, O_{i}\)，这些信号是：
\[
\chi_{i} = \frac{\|I_{i} \cap F_{0}(q)\| + \mathbb{I}[I_{i} = \varnothing]}{\max\{1, \|I_{i}\|\}},
\]
\[
\kappa_{ij} = \frac{\|O_{i} \cap I_{j}\|}{\max\{1, \|I_{j}\|\}},
\]
\[
\rho(i, j) = \log \frac{c(i \prec j) + 1}{c(j \prec i) + 1}.
\]
这里 \(\chi_{i}\) 衡量 \(u_{i}\) 是否可以利用初始状态。没有必需...