State-Path：不改 Agent 架构，如何靠“工具菜单”让成功率提升至 0.898？

The Menu Is an Execution Prior: State-Path Tool Menus for Online Agents

论文原文 ↗ 论文发布 2026-09-08 解读发布 2026-09-12 解读：AI前沿分享

面对动辄包含数千甚至上万个接口的庞大工具库，大语言模型驱动的 Agent 往往无法在一次推理中感知所有 API。工业界和学术界的通用做法，是在执行前通过检索召回一个简短的候选子集，将其注入 Prompt 中作为 Agent 可调用的操作空间。这个在执行前固定下来的选项列表，被称为“工具菜单”（Tool Menu）。

ArXiv URL：https://arxiv.org/abs/2609.09395v1

然而，现有的工具菜单构建逻辑几乎完全被“语义相关度”（Relevance）主导。当用户发出“给客户发送今天的订单收据”时，文本匹配度最高的往往是 SendEmailReceipt 这样的终点接口。如果菜单构建算法只关注谁与任务描述更像，就会直接把终点工具摆在最显眼的第一位，却忽略了让它真正能够运行的前置接口——比如“查询订单详情”、“生成收据 PDF”以及“获取客户邮件地址”。结果便是，大模型拿到了终点钥匙，却发现根本没有开门所必需的入参数据，在线执行瞬间陷入僵局。

来自中佛罗里达大学（University of Central Florida）与罗切斯特大学（University of Rochester）的研究团队在论文《The Menu Is an Execution Prior: State-Path Tool Menus for Online Agents》中指出了这一结构性矛盾：单工具的语义相关度，无法等价于整条调用链路的执行连贯性。为此，他们提出了 State-Path Tool Menu 框架，将工具菜单的本质重新定义为针对执行路径的“执行先验”（Execution Prior）。在完全不改动下游 Agent 架构、不调整在线执行循环、也不增加调用预算的前提下，仅靠重构 32 个槽位的候选菜单，便在 ToolBench 基准上将 Qwen2.5-72B-AWQ 的在线执行成功率从 0.737 提升至 0.898，在两套菜单分歧的 51 个困难任务中以 50:1 几乎形成全胜。

为什么语义检索会把 Agent 带入死胡同？

要理解工具菜单的作用，必须先剖析 Agent 在多步复杂任务中的行为机制。Agent 执行不是单步问答，而是一个动态的状态转移过程：当前环境暴露初始字段，Agent 调用工具 A 获取新数据，将 A 的输出喂给工具 B，依此类推，直到最终工具 C 生成用户所需的结果。

在这个链条中，工具之间存在极强的输入输出因果依赖。以发送收据为例，如果 Prompt 中只提供 SendEmailReceipt，模型即使具有极强的推理能力，也会因为缺少参数而报错或开始胡说八道（Hallucination）。要让任务走通，菜单必须同时具备两项性质：

链路完整性（Route Completeness）：菜单不仅要包含最终目标工具（Target）和可直接运行的入口工具（Entry），还要包含中间负责传递关键字段的桥梁工具（Bridge）。
拓扑有序性（Topological Order）：大模型对上下文中的选项顺序高度敏感，先出现的工具天然具备更强的注意力先验。如果消费数据的工具被排在生产数据的工具之前，模型更容易产生过早调用的冲动错误。

过去针对工具调用的优化方案大多存在取舍。一类方法是“在线动态检索”（如 AutoTool、ToolTree 等），在 Agent 迈出每一步后，根据新的环境观察重新去检索库里拉取工具。这类方法虽然具备灵活性，但极大地拖慢了交互延迟，并且每次检索都会打乱模型的上下文连续性。另一类则是传统的预执行检索（如 ToolRet、ToolRerank 等），它们试图在执行前一步搞定，但其优化的目标函数依然是“查询语句与接口文档的匹配分数”，这注定了它们很难挑出那些语义低调却必不可少的“数据加工桥梁”。

State-Path 的核心切入点正在于此：既然在线交互成本高昂，能不能在执行发生之前的毫秒级时间内，直接为 Agent 编译出一份兼顾“依赖闭环”与“正确先后序”的执行先验菜单？

状态路径的三层解构：从状态到终点的确定性路由

论文将任务执行路径抽象为状态转移路径（State Path）。设整个工具库包含 $N$ 个工具 $\mathcal{T}={u_1, \ldots, u_N}$，每个工具具备说明文档 $d_i$、必需输入字段集合 $I_i$ 和产出字段集合 $O_i$。用户的请求 $q$ 在初始时刻暴露了一组可观测的状态字段 $F_0(q)$。

一条合法的执行链条，本质上遵循如下拓扑骨架：

\[s_0(q) \rightarrow \text{ENTRY} \rightarrow \text{BRIDGE}^* \rightarrow \text{TARGET} \, [\rightarrow \text{TERMINAL}]\]

为了在短短 32 个位置的有限预算内完整覆盖这个骨架，State-Path 将菜单生成解耦为三个递进的模块：状态感知编码器（Encoder）、角色覆盖检索器（Retriever） 和 依赖拓扑重排器（Reranker）。

1. 状态路径编码器（Encoder）：捕获单向依赖特征

文本语义模型只知道两个单词近不近，却不知道参数能不能对得上。Encoder 引入了三个显式的方向性依赖信号，将状态与工具图谱的几何关系注入表征：

当前可执行度（Local State Fit）$\chi_i$：衡量工具 $u_i$ 的入参有多少比例已经被初始状态 $F_0(q)$ 满足：
\[\chi_i = \frac{\lvert I_i \cap F_0(q) \rvert + \mathbb{I}[I_i = \varnothing]}{\max\{1, \vert{}I_i\vert{}\}}\]
生产-消费兼容度（Input-Output Overlap）$\kappa_{ij}$：衡量工具 $u_i$ 的输出能覆盖工具 $u_j$ 多少所需入参，这构成了有向边权重：
\[\kappa_{ij} = \frac{\lvert O_i \cap I_j \rvert}{\max\{1, \vert{}I_j\vert{}\}}\]
历史转移先验（Transition Precedence）$\rho(i,j)$：从大量成功的离线轨迹中统计工具 $u_i$ 先于 $u_j$ 出现的对数胜率，用于修正文档未声明的隐式依赖习惯。

通过将这些关系标量构造成关系偏置矩阵 $\beta(r_{ij})$，Encoder 在计算注意力权重时进行显式引导：

\[\alpha_{ij} \propto \exp\left(\frac{\mathbf{q}_i^\top \mathbf{k}_j}{\sqrt{d}} + \beta(r_{ij})\right)\]

这样编码得到的工具向量，不再仅仅代表“它在讲什么”，而是代表了“它在整张状态网络中处于哪一层输入输出拓扑中”。

2. 状态路径检索器（Retriever）：用边际收益杜绝同质冗余

当工具库从成千上万个缩减到 32 个时，最大的陷阱就是“近义工具扎堆”。比如检索器发现用户想查天气，一口气塞进 8 个不同城市的天气 API，直接将后续发送短信的接口挤出菜单。

Retriever 采用步进贪心覆盖策略，每个槽位的打分机制为：

\[s_i^R = M_i + \lambda C_i - \eta D_i\]

其中 $M_i$ 是基础路径从属度得分；$C_i$ 是边际覆盖得分（Marginal Coverage），如果候选工具填补了当前已选集合尚未满足的输入字段、或是承担了尚未出现的路径角色（如 Entry 或 Bridge），它就会获得高额奖励；$D_i$ 则是冗余惩罚项（Redundancy），严厉抑制与已选工具功能重合的候选者。通过这种机制，即便桥梁工具在字面上与用户 Query 关联较弱，也能因其填补关键入参的能力被稳固保留在 32 个席位内。

3. 状态路径重排器（Reranker）：生产者必须站在消费者前面

把对的工具挑出来只是第一步。如果菜单展示顺序混乱，大模型往往在第一步就调用了处于中间态的工具，导致执行崩溃。

Reranker 接收检索出的 32 个工具，专门优化前 $L=8$ 个核心展示槽位的排列。针对第 $r$ 个槽位，工具 $u_i$ 的排序打分为：

\[s_i^O(r) = w_m m_i + w_p \phi_{i,r} + w_s P_i(s_{r-1}) + \mathbb{I}[r=1]w_e e_i + \frac{w_d}{\max\{1, r-1\}}\sum_{j < r}(b_{\pi_j i} - b_{i \pi_j})\]

这个公式清晰体现了作者对 Agent 认知特性的理解：

$e_i$ 强制要求排在首位的工具必须能从 $s_0$ 状态直接启动（Entry 工具），防止模型开局撞墙；
$P_i(s_{r-1})$ 检查当前工具所需的参数，是否能被排在它前面的工具集合 $s_{r-1}$ 所产出的状态所满足；
最后一项成对相对次序得分，则直接从数学上保障了“生产者永远在消费者之前”。

实验检验：当菜单变成确定性路由，Agent 究竟变强了多少？

测试基准选用工具调用领域最具代表性的 ToolBench，其 API 空间超过 16,000 个。下游执行模型统一采用 Qwen2.5-72B-AWQ，固定 8 次调用预算，采用官方 ToolEval 评测环境。所有基线方法与 State-Path 一律只输出 32 个工具给 Agent，执行框架完全锁死。

1. 突破性的在线执行率提升

在官方发布的 304 个测试任务中，官方默认菜单仅解决了 224 个，成功率为 0.737。而 State-Path 菜单直接将成功任务数推高至 273 个，成功率攀升到 0.898。在双方结果不一致的 51 个边缘任务中，State-Path 赢下了整整 50 个，仅丢掉 1 个。

对这 49 个净胜任务的归因分析显示，官方菜单的失败有 42% 是因为遗漏了关键前置桥梁工具，有 36% 是因为虽然包含了工具但排布顺序极其混乱导致模型过早调用消费者。State-Path 仅仅依靠修正这 32 个位置的选择与次序，就修补了这部分近乎结构性的执行断裂。

2. “32”胜过“128”：信息密度的质变

在衡量长链覆盖能力时，一个反直觉的对比出现了：传统的语义检索方式即使把菜单预算放宽到 128 个工具，面对长调用链路时，其完整链覆盖率（Complete-Chain Coverage）依然低于 State-Path 仅使用 32 个工具的表现。

这种差距在长调用链路（依赖步数 $\ge 7$）的任务上尤为夸张。在短路径（3-4 步）上，State-Path 的完整覆盖率优势为 7.2 个百分点；而一旦链路延长到 7 步以上，优势迅速拉大至 26.2 个百分点。这证明随着任务逻辑深度增加，无脑堆砌语义相关的候选工具只会让噪声成倍放大，唯有以状态拓扑为主线的筛选，才能在有限的上下文内精准锚定完整调用链。

3. 跨评测器与跨模型族的泛化韧性

由于大模型作为评测器可能存在自身偏好，作者引入了 GPT-5.5、GPT-4o-mini 以及原生的 GPT-3.5-turbo-16k 进行三重独立评测。尽管不同评测大模型在严格程度上存在尺度差异（例如 GPT-5.5 给所有方法打出的绝对分普遍较低），但 State-Path 在三个评测器下始终稳居第一，且领先第二名外部基线至少 4 个百分点以上。

更关键的是模型族泛化测试。当底层执行 Agent 切换为不同参数量和架构的模型族时，State-Path 相对官方菜单带来的净增益分别达到了 16.1、12.8 和 6.9 个百分点。这说明该方法带来的收益并不是在特定模型过拟合，而是一种普适的界面赋能：只要大模型依然受限于上下文注意力分散和缺乏显式依赖规划，这种带有强前置约束的“菜单先验”就能稳定降低决策熵。

深入剖析：依赖信息与推理开销的权衡

很多工程落地团队最为关心的，是这种预执行计算会不会带来不可接受的延迟，以及它对工具文档质量的依赖程度有多深。

开销结构分解

在单张 B200 GPU 上、Batch Size 为 1 的极端交互延迟测试中，State-Path 构建完整菜单的 95 分位（P95）延迟始终压在 0.6 秒以内。深入拆解耗时可以发现，神经网络的两次 Forward 计算实际上只占用了约 6 毫秒，绝大部分时间消耗在基于规则的有向依赖图特征提取与约束解码上。

考虑到菜单是在任务发起时一次性构建完成并供后续多步执行复用，不到 0.6 秒的冷启动耗时相较于 Agent 在线多轮交互几秒甚至十几秒的等待，几乎可以忽略不计。

接口元数据的价值

论文针对工具文档的丰富程度进行了消融实验：

仅提供工具名称（Name Only）
提供名称加上结构化的入参/出参字段（Input & Output Fields）
提供完整的详细自然语言描述（Full Descriptions）

实验数据显示，从单纯的名字升级为提供清晰的 Input/Output 字段时，依赖边预测准确率提升了 4.8 个百分点，路径重放成功率提升了 5.0 个百分点；而在此基础上进一步添加长篇大论的自然语言文档，带来的边际提升却十分微弱。这表明，工具的输入与输出契约才是支撑依赖路由的基石，冗长的营销式功能介绍并不能帮 Agent 梳理清楚执行顺序。

此外，当研究人员从训练轨迹中完全抽离历史路径先验（仅依赖 Schema 结构）时，模型依然能维持 0.510 的完整链覆盖率；而注入 100% 的历史轨迹后，这一数值大幅上涨至 0.704。有趣的是，当对 50% 的历史轨迹人为制造单步噪声扰动时，覆盖率仅仅轻微下滑 1.0 个百分点。这体现出显式 Schema 约束与统计学路径先验的互补性：Schema 构筑了硬性底线，而高频统计特征则平滑了局部噪声。

从“检索上下文”走向“规划前置先验”

回顾当下大模型 Agent 的系统设计，学术界和工业界常常陷入两个极端：要么寄希望于底层大模型本身具有无限的 Reasoning 能力，通过几十轮的 ReAct 自行试错纠错；要么依赖复杂的动态在线规划器，走一步查一步。

State-Path 提供了一种极具实用价值的中间路线视角。它明确指出了当前交互界面的固有缺陷：给 Agent 呈现的菜单本身就是一种带有强烈暗示的执行先验。如果喂给 Agent 的先验本就是残缺且倒置的，把失败归咎于模型“推理不够聪明”无异于缘木求鱼。

这项研究的局限性同样清晰。由于其菜单在第一步执行前即告固化，如果真实环境返回了意料之外的状态突变（例如接口报错或返回了全新的未注册字段），完全静态的菜单将无法自适应调整。作者在文末也指出，将 State-Path 确立的全局路径先验与轻量级的在线局部自适应相结合，是未来 Agent 架构极为自然的发展方向。

对于构建企业级 Agent 系统或复杂 API 调度平台的工程师而言，这篇论文带来了非常直观的架构启示：在花大代价微调大模型或设计复杂的 Prompt 链条之前，不妨先审查一下喂给模型的工具列表——检查入参出参闭环，把那些必不可少的“数据桥梁”打捞出来，并将生产者坚定地排在消费者之前。很多困扰已久的执行断点，往往在菜单排定的那一刻就已经得到了解决。