Plan or Retrieve First? A Scale Study of Tool Discovery Architectures
先规划还是先检索？大规模工具发现架构对比研究
🧭 Agent 工具发现架构对比与自适应路由 ★ 深度解读
Apple
在50k API规模下系统对比Retrieve-then-Plan与Plan-then-Retrieve，发现单工具查询RtP占优、多工具查询PtR占优的复杂度交叉
📌 工作参考价值（4 点）
- 复杂度自适应路由：用RtP的top-1检索相似度作为零成本路由信号，高相似度（查询直接包含API名/品牌名）走RtP，低相似度（抽象多步骤意图）走PtR，可节省约36%的discovery调用开销且无检索质量损失。
- 多意图查询分解：在电商/Agent场景中，对于“连衣裙+高跟鞋+包包”这类多面意图query，可以让LLM先生成多个Abstract Tool Stubs（或子意图桩），每个桩独立检索再合并，优于单embedding直接检索。
- Stub hallucination双刃剑管理：简单query包含明确的专有名词或品牌时，不要抽象成generic stub，否则丢失强匹配信号；复杂query则可以利用stub的分解能力。工程上可对stub生成加入专有名词保留策略。
- 检索是Agent行为的上界：实验显示planner轨迹保真度≥96%，即planner几乎只从检索结果中选择tools，所以优化检索架构比优化planner prompt更关键。在大规模工具注册表下应优先投入检索质量。