隨著Model Context Protocol（MCP）生態(tài)的興起，一個(gè)Assistant背后可能掛著數(shù)百個(gè)工具/子Agent。

• 把全部工具描述塞進(jìn)Prompt？→ 4 600+ tokens起步，貴到肉痛。
• 先選Agent再選工具？→ 粗粒度描述經(jīng)常把“隱藏的寶藏工具”埋沒。
• 只拿單工具？→ 多步任務(wù)需要的一組工具被活生生拆散。

作者用一張圖點(diǎn)破痛點(diǎn)：

               圖1：傳統(tǒng)“僅Agent”檢索（左）vs. Tool-to-Agent統(tǒng)一檢索（右）

核心思想：把“工具”和“Agent”拉進(jìn)同一個(gè)向量空間

Tool-to-Agent Retrieval（T2A） = 統(tǒng)一向量索引 + 元數(shù)據(jù)跳轉(zhuǎn)

1. 建一張二分圖：Agent ? 擁有的工具
2. 用同一套編碼器把Agent描述 & 工具描述都embed進(jìn)去
3. 檢索時(shí)先拿Top-N（工具+Agent），再通過(guò)??owner(·)??映射回唯一Agent集合
4. 最終返回Top-K Agent，即可單步完成“選工具 or 選Agent”決策

算法偽代碼一覽：

Algorithm 1：Combined Tool–Agent Top-K Retrieval

實(shí)驗(yàn)設(shè)計(jì)：8個(gè)編碼器 × 95條真實(shí)任務(wù) × 527個(gè)工具

數(shù)據(jù)集：LiveMCPBench

• 70個(gè)MCP Servers，527 tools，95條多輪用戶Query
• 每條Query人工標(biāo)注2.68步、2.82 tools、1.40 Agents

比較基線：

• BM25
• Q.Retrieval（dense）
• ScaleMCP（2025 SOTA）
• MCPZero（2025 SOTA）

評(píng)估指標(biāo)：Recall@K / mAP@K / nDCG@K，K∈{1,5,10}

結(jié)果速覽：指標(biāo)全面提升，最高+28%

Table 1：LiveMCPBench主指標(biāo)

再看8種embedding的穩(wěn)定性：

Table 2：逐模型對(duì)比（Recall@5）

• Amazon Titan v2提升最猛：0.66 → 0.85（+28%）
• 即使是輕量All-MiniLM-L6也+13%，說(shuō)明改進(jìn)來(lái)自框架而非大模型

消融洞察：工具級(jí)信號(hào)到底帶來(lái)了什么？

• 在Top-5返回里，**39%直接命中Agent描述，34%**是通過(guò)工具→Agent映射召回→ 證明“工具細(xì)節(jié)”確實(shí)補(bǔ)足了Agent摘要遺漏的語(yǔ)義
• Step-wise Querying（先分解再逐步檢索）比Direct Querying平均再+4–6 pts Recall
  → 復(fù)雜任務(wù)拆步檢索依舊有效

https://arxiv.org/pdf/2511.01854
Tool-to-Agent Retrieval: Bridging Tools and Agents for Scalable LLM Multi-Ag

本文轉(zhuǎn)載自??PaperAgent??