作者：Mingfei Zhang、Amit Surana、Ziauddin Majid、Chenxi Wang、Michael Xu
工具增强型 LLM（大语言模型） 智能体在规划执行之前会从大型注册表中发现相关 API（应用程序编程接口），然而有限的上下文窗口使得无法将所有工具定义注入单个提示中。主流方法（我们称之为 Retrieve-then-Plan，RtP）会嵌入用户查询，并通过近似最近邻搜索检索相似工具。我们研究了一种替代范式 Plan-then-Retrieve（PtR），其中 LLM 首先生成抽象工具桩（Abstract Tool Stubs，即描述所需能力的假设函数签名），然后将其作为针对注册表的检索查询。在 ToolBench（46,984 个唯一 API 端点，50 个类别）上，针对单工具（G1）、同类别多工具（G2）和跨类别多工具（G3）查询子集进行评估，我们发现了一个清晰的、依赖于复杂度的交叉现象：RtP 在单工具查询上优于 PtR，而 PtR 在多工具查询上优于 RtP。这一交叉现象在每个检索预算（k=1 到 20）下均成立，在 1k 到 47k 个 API 的注册表规模下保持稳健，并且在不同的模型系列（Gemini 2.5 Flash 和 gpt-oss-120b）上保持一致。我们刻画了一种桩幻觉失效模式（LLM 编造看似合理但并不存在的 API 名称），它是一把双刃剑：在简单查询上，PtR 的桩会抽象掉 RtP 直接匹配的专有名词信号，而在复杂查询上，同样的机制会将多层面意图分解为功能性子需求。我们进一步分析了 token 开销，并表明 PtR 额外的发现调用大约使推理成本翻倍，这在多工具查询上值得付出，但在单工具查询上会造成损失，从而推动复杂度自适应路由成为一个实用方向——该方向可以由流水线中已存在的零成本信号（RtP 的 top-1 检索分数）来驱动。
转载声明：本文为转载整理，原文版权归原作者及原站点所有。
原文来源：Apple ML Research
原创地址：https://machinelearning.apple.com/research/plan-retrieve-tool-discovery
原文作者：Apple ML Research；如有侵权，请联系管理员删除。
