工具增强的 LLM Agent 需要从大型 API 注册表中发现相关工具，但上下文窗口限制使所有工具定义无法一次性注入。当前主流做法是先检索后规划（RtP）：嵌入用户查询，用近似最近邻搜索召回相似工具。这篇研究讨论另一种顺序——先规划后检索（PtR）：让 LLM 先生成抽象工具桩（Abstract Tool Stubs，即假设的函数签名），再用它们作为检索查询去匹配注册表。

评估基于 ToolBench（46,984 个唯一 API 端点、50 个类别），覆盖单工具（G1）、类内多工具（G2）、跨类多工具（G3）三类查询子集。核心发现是一个随复杂度变化的交叉点：单工具查询上 RtP 优于 PtR，多工具查询上 PtR 优于 RtP。这个交叉在检索预算 k=1 到 20 的每个档位都存在；注册表规模从 1k 到 47k 时依然稳健；在 Gemini 2.5 Flash 和 gpt-oss-120b 两个模型家族上一致复现。

论文还刻画了一种“桩幻觉”（stub-hallucination）失败模式：LLM 会编造看似合理但实际不存在的 API 名称。这像是双刃剑：简单查询上，PtR 的抽象桩丢掉了 RtP 能直接匹配的专有名词信号；复杂查询上，同样的机制反而把多面意图拆解成功能性子需求，有利于检索。

开销方面，PtR 多一次工具发现调用，推理成本大约翻倍。在多工具查询上这笔开销值得，在单工具查询上则是负收益。因此作者提出复杂度自适应路由作为实用方向——可以用流程中已有的零成本信号来驱动，即 RtP 的 top-1 检索分数。