先计划还是先检索？工具发现架构的规模研究

arXiv:2610.19068v1 Announce Type: new Abstract: Tool-augmented LLM agents discover relevant APIs from large registries before planning execution, yet finite context windows prohibit injecting all tool definitions into a single prompt.主要方法，我们称之为“检索然后计划”(RtP)，嵌入用户查询并通过近似最近邻搜索检索类似的工具。我们研究了另一种计划然后检索（PtR）范例，其中法学硕士首先生成抽象工具存根（描述所需功能的假设函数签名），然后将其用作针对注册表的检索查询。通过对单工具 (G1)、类别内多工具 (G2) 和跨类别多工具 (G3) 查询子集的 ToolBench（46,984 个唯一 API 端点，50 个类别）进行评估，我们发现了一个明显的依赖于复杂性的交叉：RtP 在单工具查询上优于 PtR，而 PtR 在多工具查询上优于 RtP。这种交叉适用于每个检索预算（k=1 到 20），在 1k 到 47k API 的注册表大小中保持稳健，并且在模型系列（Gemini 2.5 Flash 和 gpt-oss-120b）之间保持一致。 We characterize a stub-hallucination failure mode (the LLM invents plausible but non-existent API names) that acts as a double-edged sword: on simple queries PtR's stubs abstract away proper-noun signals that RtP matches directly, yet on complex queries the same mechanism decomposes multi-faceted intent into functional sub-needs. We further analyze token overhead and show that PtR's extra discovery call roughly doubles inference cost, which pays off on multi-tool queries but hurts on single-tool ones, motivating complexity-adaptive routing as a practical direction, one that can be driven by a zero-cost signal already present in the pipeline (RtP's top-1 retrieval score).