先规划还是先检索？工具发现架构的规模研究
内容提要
研究比较了工具增强LLM智能体的两种工具发现架构：先检索后规划（RtP）与先规划后检索（PtR）。在ToolBench（约4.7万API）上测试发现，单工具查询RtP更优，多工具查询PtR更优，该交叉现象在不同检索预算、注册表规模和模型家族下均稳健。PtR存在虚构API的“存根幻觉”，既会丢失专名信号，也能分解复杂意图。PtR额外发现调用约使推理成本翻倍，适合多工具查询，故宜采用复杂度自适应路由。
延伸解读
复杂度决定架构选择
研究显示，工具发现架构的优劣取决于查询复杂度：单工具查询时，先检索后规划（RtP）表现更好；多工具查询时，先规划后检索（PtR）更优。这一交叉现象在检索预算k=1到20、注册表规模1k到47k API以及不同模型家族（Gemini 2.5 Flash和gpt-oss-120b）下均稳健。因此，没有一种架构在所有场景下占优，需根据查询复杂度动态选择。
存根幻觉的双刃剑效应
PtR要求LLM先生成抽象工具存根（假设的函数签名）作为检索查询，这可能导致“存根幻觉”——LLM虚构看似合理但不存在的API名称。这种幻觉在简单查询中会抽象掉专名信号，而RtP能直接匹配这些信号，因此PtR表现较差；但在复杂查询中，同一机制能将多面意图分解为功能性子需求，反而提升效果。
推理成本与自适应路由
PtR的额外发现调用大约使推理成本翻倍。这在多工具查询中因效果提升而值得，但在单工具查询中则造成浪费。研究建议采用复杂度自适应路由，并指出可利用管道中已有的零成本信号——RtP的top-1检索分数——来驱动路由决策，从而在效果与成本间取得平衡。
Q&A
工具增强LLM智能体在规划执行前如何从大规模API注册表中发现相关工具？
由于上下文窗口有限，无法将所有工具定义注入单个提示，主流方法是先检索后规划（RtP）：将用户查询嵌入，并通过近似最近邻搜索检索相似工具。另一种范式是先规划后检索（PtR）：LLM首先生成抽象工具存根（假设的函数签名），然后将其作为检索查询。
先检索后规划（RtP）和先规划后检索（PtR）在性能上有什么差异？
在ToolBench上评估发现，RtP在单工具查询上优于PtR，而PtR在多工具查询上优于RtP。这种交叉现象在所有检索预算（k=1到20）、注册表规模（1k到47k API）和模型家族（Gemini 2.5 Flash和gpt-oss-120b）下均稳健。
什么是存根幻觉？它对PtR有什么影响？
存根幻觉是PtR的一种失败模式，指LLM虚构看似合理但不存在的API名称。它是一把双刃剑：在简单查询上，PtR的存根会抽象掉RtP能直接匹配的专名信号；在复杂查询上，同一机制能将多面意图分解为功能性子需求。
PtR的额外发现调用对推理成本有什么影响？
PtR的额外发现调用大约使推理成本翻倍。这种成本在多工具查询上能带来收益，但在单工具查询上反而有害，因此需要复杂度自适应路由。
如何根据查询复杂度选择工具发现架构？
可以采用复杂度自适应路由：对于单工具查询使用RtP，对于多工具查询使用PtR。这种路由可以由管道中已有的零成本信号驱动，即RtP的top-1检索分数。
这项研究在哪些数据集和模型上进行了评估？
研究在ToolBench上进行评估，该数据集包含46,984个唯一API端点和50个类别，涵盖单工具（G1）、类别内多工具（G2）和跨类别多工具（G3）查询子集。使用的模型包括Gemini 2.5 Flash和gpt-oss-120b。
