大型语言模型 (LLM) 正迅速从简单的聊天机器人演进为复杂的推理引擎。其中最令人振奋的前沿之一，是多智能体系统的开发——这种架构中，一个主 LLM 负责协调整个由专业子智能体组成的团队: 一个智能体可能专注于代码分析，另一个负责数据库查询，再一个聚焦于网页搜索。每个智能体都可以配备数十甚至上千个工具——也就是它们能调用的函数或 API，用以完成任务。

这种可扩展性虽然强大，却带来了一个关键瓶颈: 路由问题 。 当用户提出类似于“上个季度我们在东北地区的畅销产品有哪些？与主要竞争对手的新闻稿相比如何？”这样的复杂查询时，系统该如何判断由哪个智能体或工具来响应？

编排器是否该去寻找一个“数据库智能体”？看起来合理，但若最相关的函数——比如一个 quarterly_sales_report(region) 工具——隐藏在一个名称笼统为“商业分析”的智能体中呢？系统可能完全忽略它。反之，如果将所有智能体的工具描述都传送给 LLM，则会极度低效，消耗数千个 token。

这正是普华永道 (PwC) 研究团队在论文 《工具到智能体检索: 为可扩展的 LLM 多智能体系统桥接工具与智能体》 中所解决的问题。他们提出的 *工具到智能体检索 (Tool-to-Agent Retrieval) * 方法，避免了这种“全有或全无”的权衡。通过创建一个统一系统，让工具和智能体共存于一个共享的可搜索空间中，从而在单次操作中实现既细粒度又高层次的检索。

传统方法: 智能体优先 vs. 纯工具检索

在探讨新方法之前，先了解以往方法为何失效。

  1. 智能体优先检索 (Agent-First Retrieval) – 系统仅索引智能体级描述。当查询进入时，它会搜索该列表并选出最相关的智能体。 这就像你去前台问: “谁能帮我修电脑？”被指向“IT 部门”，但真正懂你电脑的人可能埋在该部门深处。 这种方式存在上下文稀释 (context dilution) 问题: 当一个智能体捆绑数百工具时，其概述会变得笼统，导致具体工具的独特能力被淹没。

  2. 纯工具检索 (Tool-Only Retrieval) – 相反的策略是将一切扁平化，忽略智能体分组，只索引所有工具。 虽然能捕捉细节，却失去了上下文 。 许多任务需要一连串操作，而这些操作通常集中在同一个智能体中——例如数据库智能体能够依次执行 connect_to_database、run_sql_query 和 format_results。纯工具搜索可能只匹配其中一个步骤，却错过了使整个工作流连贯的其他部分。

一张对比“仅智能体检索”和“工具到智能体检索”的图表。左侧显示智能体各自孤立的搜索空间；右侧展示工具与智能体在共同的共享空间中共存，查询可先匹配工具再通过链接找到对应的父智能体。

图1. 传统的仅智能体检索 (左) 与工具到智能体检索 (右) 。新方法将工具和智能体嵌入共享向量空间，实现联合检索与元数据遍历。

核心方法: 工具到智能体检索

研究人员的核心洞见是: 应将工具与智能体视为相互关联的实体 , 共同存在于一个统一的搜索空间中。系统不再为工具和智能体分别执行检索，而是在共享向量空间中同时嵌入二者，并通过元数据进行互联。

1. 构建统一目录

团队首先构建了一个结合细粒度与宏观描述的工具–智能体目录:

  • 智能体语料库 (\(C_A\)) – 智能体的名称及其高层次描述 (如“一个可进行代码风格检查、调试并执行 Python 脚本的代码分析智能体。”) 。
  • 工具语料库 (\(C_T\)) – 单个工具的详细描述 (如“函数 execute_python_script，接收 Python 代码作为输入并返回标准输出。”) 。

在 \(C_T\) 中，每个工具条目都包含一个指向所属智能体的元数据链接，可形象地理解为员工目录中每个人档案都标明所属部门:

\[ owner(tool) = agent \]

这个简单的映射就是连接细粒度与上下文检索的桥梁。

2. 嵌入共享向量空间

目录中的每个条目——无论是智能体还是工具——都通过嵌入模型转换为数值向量。这些嵌入使实体位于一个高维语义空间中: 意义相近的实体会彼此聚集。

在该空间里，查询“运行这段 Python 代码”会与工具 execute_python_script 的向量更接近；而较宽泛的查询“帮我解决程序问题”则会贴近“代码分析智能体”。这种统一空间允许同时处理特定与泛化意图的灵活匹配。

3. 检索算法

论文中的算法 1 对整个过程进行了总结，主要分为两个阶段:

  1. 初始检索: 将用户查询转化为向量，在统一目录中搜索，检索出与查询最相似的前 \(N\) 个实体 (可能包含工具和智能体) 。

  2. 聚合与排序: 从这 \(N\) 个实体中，提取前 \(K\) 个唯一智能体:

  • 若检索结果为智能体 , 直接加入候选列表。
  • 若结果为工具 , 则通过元数据链接找到其父智能体。
  • 去重后按相似度排序，输出最终的前 \(K\) 个智能体。

这种方法巧妙结合了精度与效率: 它能判断当某个具体工具最符合用户需求时，自动提升至其所属智能体，实现合适层级的路由。对于多步骤查询，同样的机制会循序运行( 分步查询 )，随任务进展动态切换智能体。

实验与结果: 它真的奏效吗？

为了验证该假设，研究团队在真实场景数据集上，将工具到智能体检索与主流智能体检索器进行对比。

评估基准: LiveMCPBench

他们使用 LiveMCPBench——一个用于评估 LLM 智能体检索的数据集，具体包括:

  • 70 个 MCP 服务器 (智能体)
  • 527 个工具
  • 95 个真实世界的多步骤任务，附带步骤级分解及工具与智能体对应关系

平均每个问题包含 2.68 个步骤，涉及 2.82 个工具和 1.4 个智能体——这正是细粒度上下文至关重要的场景。

成功指标

评估采用标准的信息检索指标:

  • Recall@K – 衡量正确智能体出现在前 K 个结果中的频率。
  • mAP@K – 奖励将正确智能体更靠前排列的算法。
  • nDCG@K – 衡量整体排序质量，突出高位的正确结果。

性能提升

表1展示了 LiveMCPBench 基准测试结果。“工具到智能体检索”在底部一行，在几乎所有指标中表现最佳，尤其是 Recall@5 (0.83) 和 nDCG@5 (0.46)，显著优于 MCPZero 和 ScaleMCP 等基线模型。

表1. LiveMCPBench 基准结果。与基线模型相比，工具到智能体检索在 Recall、mAP 和 nDCG 指标上均获得领先。

如图 2 所示，工具到智能体检索带来了显著改进——Recall@5 达到 0.83 , 比 MCPZero 提升 19.4% ; nDCG@5 达到 0.46 , 提升 17.7% 。 不仅正确智能体发现率更高，排序也更加合理。

跨嵌入模型验证通用性

一个自然的问题是: 这些提升是否仅源于更优的嵌入模型？为验证稳健性，团队分别在来自 Google (Vertex AI、Gemini) 、Amazon (Titan) 、OpenAI 及开源 MiniLM 系列的八种模型上进行了重复实验。

表2展示了八种不同嵌入模型的比较结果。对于每种模型，“Ours” (工具到智能体检索) 列在 Recall@5、nDCG@5 和 mAP@5 上的 scores 均高于 “MCPZero” 基线。

表2. 八种嵌入模型下的结果。无论使用哪种嵌入架构，工具到智能体检索在 Recall、nDCG 和 mAP 指标上均优于 MCPZero。

无论模型种类，性能提升均保持稳定。以 Amazon Titan v2 为例，Recall@5 从 0.66 跃升至 0.85——相对提升 28%。即使轻量级开源嵌入模型也有显著增长。这一一致性证明其优势源于检索架构本身 , 而非模型差异。

值得注意的是，仍有 39% 的最佳结果来自直接的智能体匹配，这表明系统在细粒度与抽象层之间达到了平衡: 在需要时可依赖智能体的高层描述，同时保留工具级的精准匹配能力。

结论: 为 LLM 系统打造更智能的统一路由

工具到智能体检索 (Tool-to-Agent Retrieval) 提供了一个精简、可扩展的解决方案，以应对 LLM 多智能体编排中最大的挑战之一。通过在共享向量空间中嵌入工具与智能体，并借助元数据连接它们，实现灵活且高效的一次检索，同时兼顾细节与上下文。

关键要点:

  • 统一搜索优势明显: 将工具和智能体整合成统一目录进行搜索，始终优于单独搜索任一层级。
  • 元数据链接至关重要: 工具到智能体的显式连接，使得具体匹配能为整体路由决策提供依据。
  • 消除上下文稀释: 细粒度的工具语义在一致的智能体框架中得到保留。

随着 LLM 系统逐步扩展至协调数千个 API 与 MCP 服务器，像工具到智能体检索这样的架构将愈发关键。它使模型能够在宏观智能体与微观工具之间兼顾思考与行动——将工具选择从系统瓶颈转化为连接可扩展 AI 推理的桥梁。