一句话定义：工具检索（Tool RAG）是在把工具交给大模型之前，先用检索的方式从成百上千个工具里挑出最相关的几个，只把这几个的工具定义塞进提示词。
为什么需要它
模型要调用外部工具（AI 词典：Function Calling">Function Calling，也叫 Tool Use），提示词里就得写清楚每个工具叫什么、能干什么、参数长什么样——这份说明书通常叫工具定义（schema）。十几个工具时，全量贴进去完全没问题；一旦涨到几百个，问题就来了：上下文被占满、成本变高、模型注意力被大量无关描述稀释，最后反而更容易选错、编参数。
Tool RAG 的思路和检索增强生成（Retrieval-Augmented Generation, RAG）同源，只是把"检索知识文档"换成了"检索工具定义"。
打个比方
家里水管漏了，请师傅上门。五金店里有三千种工具，你不可能把整家店搬进客厅。正常做法是：先弄清"是水管的问题"，再从墙上取下扳手、生料带和一把小刀递过去。Tool RAG 就是那个在仓库里按标签取货的人。
技术上也类似：把每个工具的名称、描述、参数说明做成可检索的索引（向量检索、关键词检索或两者混合），用户请求进来时先算一遍相似度，取前 k 个候选，再拼进提示词让模型做最终决策。
和相邻概念的区别
| 概念 | 检索/处理什么 | 目的 |
|---|---|---|
| RAG | 知识文档 | 让模型答得准 |
| Tool RAG | 工具定义 | 让模型选得对 |
| Function Calling | 工具 schema | 按格式执行调用 |
| 语义路由（semantic routing） | 少量预定义类别 | 把请求分到某条流程 |
关键差别在两点：语义路由通常是从几条固定、互斥的路径里选一条；Tool RAG 面对的是数量大、边界模糊、还在持续增长的工具集合，返回的是 top-k 候选而不是唯一答案，选完之后模型还得自己把参数组装好。
对从业者和普通人的意义
对做 Agent 的人：工具数量从几十涨到几百，就是这道工序的分水岭。几个实操要点——工具描述就是索引，写清楚"什么时候用它、什么时候别用"比写漂亮的营销文案有用；要盯 top-k 召回率，该用的工具没被捞出来，后面模型再强也白搭；k 不是越大越好，取太大等于没做检索；工具特别多时可以分层，先选工具集或领域，再选具体工具。工具一多，命名与描述的一致性往往比换模型更影响体验。
对普通用户：你看不到这层，但助手接入的应用从几个变成几百个之后，它能不能在该用日历的时候想起日历、而不是翻出备忘录，靠的正是这层筛选。具体各家平台的接口规范与限制，以官方文档为准。