工具发现架构之争：先规划还是先检索？

当大语言模型被赋予调用外部工具的能力，它们通常需要从一个规模庞大的API注册表中找出与用户需求相关的接口。然而，有限的上下文窗口根本无法一次性容纳所有工具定义。于是，一个核心的工程问题浮出水面：在工具发现这件事上，究竟应该先规划再检索，还是先检索再规划？

主流路线：Retrieve-then-Plan（RtP）

目前业界占据主导地位的方案，被研究者称为 Retrieve-then-Plan（RtP）。它的逻辑非常直接：先对用户查询做嵌入编码，然后通过近似最近邻搜索，从注册表中拉回一批语义相似度最高的候选工具，再将这些工具定义注入提示词，交由LLM完成后续的执行规划。

RtP 的工程实现相对成熟，向量数据库、嵌入模型、ANN索引等技术栈都可以直接复用。但它的隐含假设值得审视——语义相似的用户查询，就一定对应着功能上合适的工具吗？ 用户问“帮我分析一下这份财报”，嵌入空间中最接近的可能是某个“文本摘要”工具，而真正解决问题的或许是“表格提取”加“财务比率计算”的组合。相似不等于适用，这是RtP架构的根本张力。

近似最近邻搜索（ANN） 是向量检索的核心技术。在工具发现场景中，每个工具定义会被嵌入模型编码为高维向量并存入向量数据库，当用户查询到来时同样被编码为向量，ANN 算法负责在海量向量中快速找出与查询向量距离最近的若干个候选。常用的 ANN 索引包括 HNSW（分层可导航小世界图）、IVF（倒排文件）和 PQ（乘积量化）等，它们在检索速度与召回率之间做不同权衡。严格计算与查询向量的精确最近邻需要遍历全部向量，复杂度为 O(N)，在数万级注册表下延迟不可接受；ANN 通过牺牲少量召回率把复杂度降到近似 O(log N)，使毫秒级检索成为可能。理解 ANN 是理解 RtP 工程可行性的前提——正是因为它足够快，这种“先检索再规划”的流水线才能在生产环境中落地。

嵌入空间的语义相似度 指的是两个文本向量在向量空间中的距离（通常用余弦相似度或点积衡量），距离越近代表语义越接近。但嵌入模型本质上是在压缩词汇共现与上下文模式，它擅长捕捉“表面语义”，却难以精确表达“功能适配性”。例如“分析财报”与“文本摘要”在嵌入空间中可能很近，因为它们在语料中常共同出现，但真正的功能需求可能是“表格提取”与“比率计算”的组合。这种语义近邻与功能近邻之间的错位，正是 RtP 架构张力的技术根源。

替代方案：Plan-then-Retrieve（PtR）

针对这一问题，研究提出了一种反直觉的替代范式——Plan-then-Retrieve（PtR）。在PtR中，LLM不再被动地等待检索结果，而是先基于用户意图生成若干“抽象工具桩”（Abstract Tool Stubs）。这些工具桩本质上是假设性的函数签名，描述的是“我需要具备什么能力”而非“已有什么工具可用”。

打个比方：RtP像是拿着一句模糊的需求描述去仓库里翻找已有的成品工具；PtR则是先画出一张能力蓝图，标注清楚需要什么规格的功能，再拿着这张蓝图去仓库匹配。工具桩充当的是检索查询的角色，它们由LLM基于对任务的理解来构造，因此携带的语义信息更贴近功能需求本身，而非表面上的词汇相似度。

研究者在多个维度上对两种架构进行了规模化的对比评估。这一实验设计的价值在于，它没有停留在单一数据集或单一注册表规模的验证上，而是系统性地考察了不同条件对两种架构表现的影响。初步结论显示，PtR在特定场景下展现出可观的潜力，尤其是在工具注册表规模膨胀、查询意图复杂到无法用单一语义向量概括时，先规划的策略能够绕开“相似度陷阱”。

抽象工具桩（Abstract Tool Stubs） 可以理解为由 LLM 生成的“假设性函数签名”，它不指向注册表中任何已存在的具体工具，而是用结构化的方式声明“当前任务需要一种具备何种输入、输出与能力的功能”。例如面对财报分析需求，LLM 可能生成 extract_table(document) -> structured_data 和 compute_ratio(financials, metric) -> float 两个工具桩。这些桩随后被嵌入编码，作为检索查询去匹配注册表中的真实工具。工具桩的价值在于：它的语义来自对任务的功能性分解，而非用户原话的字面转述，因此能绕开“用户说的和用户要的不是一回事”这一根本困境。从实现角度看，工具桩通常在提示词中要求 LLM 以特定 schema（如 JSON 形式的函数签名）输出，便于后续解析与编码。

两种架构的本质分歧

RtP 和 PtR 的分歧，说到底是对“检索查询应该由什么构成”这个问题的两种回答。

RtP 用原始用户查询作为检索信号，它的优势是简单、无需额外推理开销；但它把用户语言的模糊性直接带入了检索环节。用户说的和用户要的，往往不是一回事。

PtR 用LLM生成的抽象工具桩作为检索信号，代价是多了一步推理调用，换来的是检索信号更贴近功能语义。LLM在这个过程中扮演的角色从一个“被动的工具消费者”变成了“主动的能力定义者”。

这两种范式并非非此即彼。在工具注册表较小、工具名称本身描述性强的场景下，RtP的额外推理开销可能不划算；而在大规模注册表、工具命名混乱、用户查询高度抽象的生产环境中，PtR的额外一步规划可能恰恰是关键。

检索信号 指的是在向量检索阶段实际被编码并用于查询的文本内容。RtP 中检索信号等于原始用户查询，PtR 中检索信号等于 LLM 生成的工具桩集合，这是两种架构最本质的技术差异。检索信号的质量直接决定召回候选工具的相关性：如果信号本身模糊、多义或与功能描述存在词汇鸿沟，再好的 ANN 索引也无法找回正确的工具。可以把检索信号理解为“给搜索引擎提的问题”——问得越贴近真实需求，答案越可靠。PtR 的额外推理调用本质上是在“改写问题”，把用户视角的语言翻译成功能视角的语言，这与数据库查询优化中“先重写查询再执行”的思路异曲同工。

对Agent工具链设计的启示

这项研究触及的是LLM Agent工具调用链路中一个容易被忽视的环节。当前大多数Agent框架把精力放在“如何用好检索到的工具”上，而对“检索什么”这个前置决策关注不足。

从工程视角看，PtR范式意味着Agent架构需要增加一个“能力抽象层”——在工具调用之前，先完成从用户意图到能力需求的翻译。这与人类专家解决问题的方式更接近：先想清楚需要什么，再去找什么可用。

随着MCP等工具协议推动API注册表规模持续增长，工具发现架构的选型将变得越来越关键。当注册表里只有几十个工具时，用什么检索策略差别不大；当工具数量达到数千甚至数万时，检索信号的质量直接决定了Agent能否找到正确的工具。

这项研究并没有给出“PtR全面优于RtP”的简单结论，而是揭示了两种架构各自的适用边界。对于正在构建工具增强Agent的团队来说，值得思考的问题是：你的检索查询，真的代表了你需要的能力吗？

MCP（Model Context Protocol） 是由 Anthropic 提出并逐步被业界采纳的开放协议，用于标准化大语言模型与外部工具、数据源之间的连接方式。在 MCP 之前，每个 Agent 框架都有自己定义工具接口的私有方式，工具难以跨框架复用；MCP 通过统一的协议描述工具的能力、参数与调用约定，使工具可以像插件一样被不同 Agent 加载。这一标准化直接推动了工具注册表规模的膨胀——当工具可以跨生态复用时，单个 Agent 面对的候选工具数量会从几十个迅速增长到数千甚至数万。工具数量的量级变化会改变检索架构的最优选择：小规模下 ANN 检索的噪声尚可容忍，大规模下检索信号的质量就成为决定 Agent 成败的关键变量，这也是 PtR 范式值得关注的时代背景。