AI 为什么选择这个工具？从信息检索理解 TSO（工具选择优化）

文章目录

一、当 AI 开始替你订餐厅、买机票，谁决定哪个 App 被打开？

试想一个人人熟悉的场景：这周五晚上你想和三位朋友在台北聚餐，于是对手机里的 AI 助理说：“帮我找大安区这周五晚上七点、四个人、预算每人一千五以内的意式餐厅，确认有空位就直接订位，订好后把时间加进我的日历，再发消息通知朋友。”

过去完成这件事，你得亲自打开 Google 地图看评论、切到订位网站确认空档、打开日历输入行程，最后再打开通讯软件发链接。对具备工具调用能力的 AI 智能体（AI Agent）而言，这是一段连续的自动化工作流：系统先解析你的意图，接着寻找能查询餐厅与空位的工具，完成预订后，再依序调用日历与通讯软件。问题在于，大语言模型（LLM）本身只是一颗擅长理解语言与推理的大脑。它无法单凭模型参数得知哪家餐厅今晚还有空桌，也不能直接替你写入日历或刷卡付订金。这些与现实世界互动的动作，全部依赖外部工具（External Tools）。

近年备受瞩目的 Model Context Protocol（MCP）、OpenAI 的 Function Calling，以及各类插件与 API 集成，本质上都是替这颗大脑接上感官与四肢。这里先厘清三个常被混为一谈的概念：Function Calling 是模型与应用程序交换工具调用指令的机制；MCP 是让外部工具与数据源以标准化格式接入 AI 的开放协议；Agent 则是能按用户目标拆解任务、调用工具，并根据结果决定下一步的完整系统。

基础设施成熟后，新的问题随之浮现。假设你的 AI 助理同时连接了五种餐厅订位服务、八种机票比价工具，以及十几个旅游行程平台；放眼整个市场，更有数百个功能高度相似的 API 支持 MCP 接入。当你说“帮我订餐厅”或“买下周去东京的机票”，AI 究竟依什么逻辑把哪个服务放进候选名单，并替你按下预订键？

过去二十年，软件产品竞争的核心是人类的注意力。从搜索引擎排名（SEO）、App Store 排行榜到界面转化率设计，企业想尽办法说服人类点击自己的产品。当用户逐渐习惯只讲结果、不问过程，把执行权交给 AI 智能体，软件服务的第一线选择者就从人类变成了模型及其背后的检索系统。未来的竞争除了发生在人类看得见的搜索结果页，也会发生在 AI 内部的“工具候选清单”里。要看懂这场新博弈，得先理解 AI 是怎么学会挑选工具的。

二、从 5 个工具到 16,000 个 API：AI 如何通过“两阶段漏斗”找到工具？

语言模型并非天生就会使用外部工具。2023 年，Meta AI 团队在 NeurIPS 发表《Toolformer》，首次系统性地探讨这个问题。研究者观察到，语言模型很会写文章，却常在简单的四则运算或实时信息查询上出错，好比一位博学的文科教授心算不准大数乘法。团队于是利用自监督学习，训练 GPT-J 6.7B 模型操作计算器、搜索引擎、翻译、问答系统与日历五种工具，证明模型能自主判断“何时需要工具”、“该用哪个工具”以及“该传入什么参数”。

真实世界的软件生态远比五个工具复杂。2024 年清华大学等团队在 ICLR 发表《ToolLLM》，从 RapidAPI Hub 收集了 16,464 个真实的 RESTful API，涵盖美食、旅游、金融、影音等 49 个类别。工具规模从个位数暴增到上万个时，系统立刻撞上一道墙：上下文窗口（Context Window）限制与注意力稀释。如果用户只想订个披萨，系统却要把一万六千个工具的名称、说明与参数格式全部塞进提示词让模型挑选，每次对话都会消耗大量 Token，模型也更容易因信息过载而选错。

为了解决这个问题，ToolLLM 引入“神经网络 API 检索器（Neural API Retriever）”，把 AI 使用工具的过程拆成“先检索（Retrieval）、后决策（Selection）”的两阶段漏斗。这个架构与搜索引擎的信息检索（Information Retrieval, IR）逻辑高度相通，只是比对对象从长篇网页换成了工具的名称、功能描述与参数定义。

用户指令“帮我查下周五飞东京最便宜的早班机，要含 23kg 行李”

这句话会先被转成检索查询，再进入工具库比对。

第一阶段
候选工具检索
看不看得见1. 关键词检索（BM25）

比对“东京”“机票”“行李”等字词与工具说明的重叠程度。

第一阶段
候选工具检索2. 语义向量检索（Dense Retrieval）

把需求转成向量，计算与工具描述的语义距离。工具没写“早班机”，但写了“按起飞时段筛选航班”，也能命中。

第一阶段
候选工具检索3. 重排序模型（Reranker）

从召回的 30～50 个工具中，交叉比对是否真的支持“行李额度查询”，留下最匹配的 5 个工具定义。

第二阶段
模型决策与调用
选不选得对4. 工具选择（Selection）

模型只看到 Top-5 工具的名称、描述与参数结构。它排除“历史票价统计工具”，选中支持实时航班与行李额度查询的 API。

第二阶段
模型决策与调用5. 参数生成（Calling）

填入 destination="TYO"、departure_time="morning"、baggage_kg=23 后发出调用。

图解一：AI 智能体的“两阶段工具检索与决策漏斗”。召回与保留的数量为示意，各平台设置不同。

如图解一所示，第一阶段会通过三种机制把上万个工具浓缩成极少数的候选名单。最基础的是以 BM25 为代表的关键词检索（Sparse Retrieval），直接计算指令与工具说明之间的词汇重叠度。所以工具命名与描述不能只写抽象的品牌口号。用户想“订机票”时，一个描述写着“提供卓越的全球智慧出行解决方案”的航空工具，在关键词检索阶段就会因为没有字面交集而出局。

人类说话很口语，不会照着工程师写的规格书下指令。你对 AI 说“帮我找周末跟朋友聚餐不限时的店”，某个订位工具的说明写的是“按用餐时间限制与人数筛选合作餐饮店家”，两者用词不同，意思却高度一致。这时就轮到语义向量检索（Dense Retrieval）：系统通过向量嵌入（Embedding）模型把口语需求和工具描述都转成高维向量，以余弦相似度（Cosine Similarity）找出语义相近的工具。

然而，语义相近不等于工具适用。假设你急着请 AI“帮我买今晚八点台北回左营的高铁票”，在向量空间里，“查询高铁历史误点率统计”、“搜索高铁旅游美食博客文章”与“高铁实时余票查询与订票”三个工具的向量可能非常接近，因为它们都围绕着“高铁”与“班次”。只靠第一轮向量相似度，AI 可能拿一个只能看历史数据或美食游记的工具去执行买票任务。因此，大型检索系统通常会在召回前几十个候选后，再加一层重排序模型（Reranker），确认工具是否真的具备实时交易与订位能力，把真正能办事的选项推到前面，最后才交给语言模型做第二阶段的决策。

三、工具越多反而越难选？从 ToolScope 与 Anthropic 实证看检索瓶颈

理解两阶段漏斗后，就能明白一件事：你的工具没被 AI 使用，往往不是模型觉得产品不好，而是在第一阶段就已落选，模型从头到尾都没看见它。

随着接入生态的工具数量膨胀，工具之间的“撞名”与“描述重叠”也越来越严重。Oracle AI 研究团队在 ACL 2026 发表的《ToolScope》点出大型工具库的两个瓶颈：大量工具的功能描述高度雷同，让检索器与模型无法分辨差异；有限的上下文空间又容纳不了庞大的工具定义。

想象你的手机 AI 同时装了三个美食工具：第一个自称“全方位智慧餐饮助手”，第二个写着“热门餐厅探索与美食指南”，第三个标榜“一站式餐饮生活服务”。从文字看几乎一模一样，实际上第一个是外卖平台、第二个是美食点评网站，第三个才是堂食订位系统。当工具提供者都用模糊、包罗万象的词汇包装自己，检索系统就会陷入混乱。ToolScope 团队为此设计了自动化的工具合并（Tool Merging）与校正机制：先以向量相似度找出高度重叠的工具，再交由模型厘清能力边界，并搭配重排序模块。在 UltraTool 数据集上以 GPT-4o 测试的结果如下：

表 1：ToolScope 在 UltraTool 数据集的结果（GPT-4o，Liu et al., 2026）
检索与选择方法	CSR@30（正确工具集合选中率）	相较前一行
BM25（关键词检索）	36.6%	基准线
Dense Retrieval（语义向量检索）	67.3%	较 BM25 高 30.7 个百分点
ToolScope＋自动校正	75.2%	较 Dense 高 7.9 个百分点

这组数据说明两件事。第一，从关键词检索升级到语义向量检索，正确选中率（CSR）提升超过 30 个百分点。第二，论文的消融实验显示，合并功能重叠的工具、减少语义重叠带来的提升最大，重排序只在大型、噪声多的工具库有小幅帮助。换句话说，把工具的能力边界写清楚，本身就是有效的检索优化。

商业平台也已经把这套做法变成基础设施。2025 年的预印本《RAG-MCP》指出，先以语义检索筛选 MCP 工具再交给模型，工具选择准确率从 13.62% 提高到 43.13%。同年 11 月，Anthropic 在 Claude 开发者平台推出 Tool Search Tool：工具可标记为延后加载，模型以 BM25 或正则表达式搜索后才加载需要的定义。Anthropic 公布的例子是，同时接入多个 MCP 服务器时，传统做法光是工具定义就约 72,000 个 Token（开始工作前总消耗约 77,000 个）；改用 Tool Search Tool 后总消耗降到约 8,700 个，Anthropic 称工具相关的 Token 开销约减少 85%。选对工具的准确率也同步上升：

表 2：Anthropic 内部 MCP 评测（厂商公布数据）
模型	未使用 Tool Search（全量加载）	使用 Tool Search（动态加载）
Claude Opus 4	49.0%	74.0%
Claude Opus 4.5	79.5%	88.1%

来源：Anthropic〈Introducing advanced tool use on the Claude Developer Platform〉。这是厂商内部评测，测试集未公开，不宜与学术基准直接比较。

当 Anthropic 与各大智能体框架都开始采用“先搜索、后加载”的动态工具检索，一个工具能否在第一轮搜索中出线，就成了决定它有没有机会被使用的分水岭。

四、拆解失败黑盒子：为什么 AI 找到了工具，任务还是失败？

谈优化之前，要先建立诊断框架：被检索出来（Tool Retrieval）不等于被模型选中（Tool Selection），被选中也不等于成功执行（Tool Calling）。ACL 2025 Findings 的《Retrieval Models Aren't Tool-Savvy》以涵盖约 43,000 个工具的 ToolRet 基准测试发现，擅长找网页文章的检索模型面对工具检索时表现明显下滑，进而拖累整个智能体的任务成功率。

在 LS-Labs 的 TSO 四段框架中，工具提供者完成第一段“工具接入”后，工具在实际任务里会依序经过三个断点，正好对应第二段“候选曝光”、第三段“模型选择”与第四段“调用与执行”。假设你请 AI 助理“帮我订这周六晚上七点、四个人的火锅店”，AI 却回报订位失败，可以用下面的诊断图找出卡在哪里：

用户任务：“帮我订这周六（11/7）晚上 7 点、4 个人的台北火锅店”

断点 1
工具检索目标：进入 Top-K 候选名单（对应“候选曝光”）
✕ 失败：某火锅订位 API 名称叫 service_v2，描述只写“提供餐饮数字化转型服务”。检索器找不到它和“订位”“餐厅”的关联，连候选池都没进去。
✓ 通过：描述清楚写明“查询餐厅空位并创建预约”，顺利进入前 5 名。

断点 2
工具选择目标：在候选名单中胜出（对应“模型选择”）
✕ 失败：候选池里同时有“火锅外卖 API”与“餐厅堂食订位 API”，两者都只写“提供火锅预订服务”，模型分不清外卖与堂食，误选了外卖工具。
✓ 通过：堂食订位工具标注“适用于餐厅现场座位预约，不含外卖”，模型选对。

断点 3
工具调用目标：正确生成参数并完成交易（对应“调用与执行”）
✕ 失败：模型选对工具，但 time_slot 字段没说明格式，模型传入 "晚上七点"，服务器只接受 "19:00"，API 报错。
✓ 通过：参数结构定义 date: "YYYY-MM-DD"、time: "HH:MM"，一次调用成功。

图解二：工具调用的三层断点诊断。情境为说明用的假设，不是 LS-Labs 观测。

这张图说明了为什么“只管曝光”的思维在智能体时代不够用。断点 1 落败，是可发现性（Discoverability）不足；断点 2 落败，是能力边界（Capability Boundary）模糊；断点 3 落败，则是参数规格（Schema Design）定义不良。三个环节都打通，工具才能真正完成用户的托付。

五、TSO（工具选择优化）是什么？做好 TSO 的四项优势

过去的学术研究大多站在模型开发者的角度，思考怎么训练更聪明的检索器与模型。把视角翻过来，站在提供服务的企业、SaaS 产品与工具开发者的立场：两家功能相同的订房网站、支付工具或电商服务同时接入 AI 生态系统时，谁能以更精确的工具定义被正确选用？

这就是 LS-Labs 提出 TSO（Tool Selection Optimization，工具选择优化）的出发点。本文采用的定义是：从工具提供者视角出发，通过真实、结构化且边界清晰的工具名称、能力描述、适用情境与参数设计，让工具在 AI 智能体的检索、决策与调用流程中被精准发现、正确理解与可靠执行的系统化方法。TSO 是本站的操作框架，不是任何 AI 平台公布的排名因子；LS-Labs 目前也还没有自己的实测结果，以下优势依据的是既有论文与平台文档。

要直观理解 TSO 在 MCP 工具定义或 OpenAI Function Calling 中的施力点，可以比较一份工具定义优化前后的差异：

✕ 未经 TSO 优化的工具定义

{
  "name": "travel_helper_api",
  "description": "提供全方位的智慧旅游体验，协助用户轻松搞定全球住宿与行程规划。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "date": { "type": "string" },
      "num":  { "type": "integer" }
    }
  }
}

name 空泛，看不出核心动作。
description 充满营销口号，没有输入输出说明，容易和机票、景点工具混淆。
参数命名模糊、没有格式规范，容易引发报错。

结果：检索难命中、选择易混淆、调用易失败

✓ 经过 TSO 优化的工具定义

{
  "name": "search_and_book_hotel_rooms",
  "description": "查询指定城市与日期的酒店空房价格，并可直接创建住宿预订。返回房型、含税总价与取消政策。使用限制：仅限住宿订房，不支持机票查询、餐厅订位或景点门票。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "check_in_date": {
        "type": "string",
        "description": "入住日期，格式 YYYY-MM-DD，例如 2026-11-07"
      },
      "guests_count": {
        "type": "integer",
        "description": "入住成人总数，不含婴幼儿"
      }
    },
    "required": ["check_in_date", "guests_count"]
  }
}

可发现性：动词＋宾语的名称，直接对上用户会说的任务。
能力与边界：说清楚“能做什么”与“不做什么”，参考 EASYTOOL 与 Tool-REX 的做法。
参数清晰：每个字段都有格式与示例，通过 OpenAI 的“实习生测试”。

目标：该用你的时候找得到、选得对、调用得成

图解三：从 MCP／Function Calling 工具定义看 TSO 的三个施力点。示例为示意，不代表改写后的选中率。

综合 NAACL 2025 的《EASYTOOL》、ICLR 2026 的《Tools are under-documented（Tool-REX）》与 EMNLP 2024 Findings 的《Re-Invoke》等研究，工具文档完成上述重构后，可以预期在四个层面取得优势：

突破上下文限制，拿到首轮候选池的入场券（Top-K Recall）。在 Tool Search 与 RAG-MCP 这类架构下，AI 每次只把最相关的少数工具加载进上下文。描述涵盖明确的动词、目标宾语与用户常说的任务情境，无论用户说“找旅馆”、“订民宿”还是“查周末住宿空房”，工具都比较有机会在 BM25 与向量检索阶段进入 Top-K，不至于还没比较就出局。Tool-REX 与 Re-Invoke 的结果都显示，补足工具文档或改写查询能提高工具检索的召回。
消除语义碰撞，在同类工具中提高正确获选率（CSR）。ToolScope 的实验显示，市场上十几个旅游或餐饮工具都写“智慧生活助手”，只会让向量空间严重重叠。明确交代输入条件、返回数据与负向边界（Negative Constraints），能让重排序模型与 LLM 更快判断哪个工具最契合当前子任务。
降低参数幻觉与 API 报错，减少重试成本。OpenAI 在官方文档中提出“实习生测试”：一位刚报到的实习生只看你给模型的参数说明，能不能一次填对所有字段？inputSchema 写清楚，模型就更可能一次传出正确的日期格式与参数，避免调用失败后重试，或转而改用其他工具。至于平台是否会把任务完成率纳入工具排序，目前没有平台公开这类机制。
在零界面（Zero-UI）场景中，成为智能体直接调用的服务。传统 SEO 争取的是让人类看见网页链接，GEO 争取的是让 AI 在回答里提到品牌；TSO 关心的是智能体执行任务时有没有调用你的服务。当消费者只对手机说“帮我叫车去机场”或“帮我买划算的旅游保险”，中间可能已经没有网页浏览与比价画面。这也是 B2A（Business-to-Agent）讨论的核心场景。

TSO 与现有优化概念的分工，可以用下表对照：

表 3：SEO、GEO、TSO 与 AX 的分工
优化维度	对象与载体	核心问题	对应结果
SEO（搜索引擎优化）	搜索引擎爬虫／网页内容	搜索结果页能否排在前面让人点击？	网站自然流量与曝光
GEO（生成式引擎优化）	生成式 AI／品牌知识与评测	AI 汇总回答时是否引用并提及品牌？	对话中的品牌提及与引用
TSO（工具选择优化）	AI 智能体检索器／API 与 MCP	智能体执行任务时是否选用我的工具？	实际的 API 调用与任务完成
AX（智能体体验）	AI 智能体系统／产品全流程	智能体从发现、授权、调用到错误恢复是否顺畅？	智能体能否在产品上把事情办完

六、如何验证 TSO 成效？兼论 ToolTweak 揭露的操纵风险

TSO 如果只停在“把文案写清楚”，很容易沦为玄学。验证成效要遵循控制变量与分层观测：固定模型版本、工具池规模与权限，再用三层指标做 A/B 测试。

三层验证指标

第一层候选检索召回率（Recall@k）
针对同一个工具，设计 20 到 50 种不同口语的指令（例如“订位”、“找餐厅”、“预约周六晚餐”、“确认有没有四人桌”），比较改写描述前后，目标工具出现在检索器前 k 名的比例。

第二层决策精准度与边界防御力（Precision／False Positive Rate）
除了看被选中几次，也要看它有没有在不该出场时乱入。测试集同时放正向任务（查询餐厅空位并订位）与负向诱饵任务（火锅外卖送到家、修改已刷卡的订金）。理想的结果是正向任务选中率高，负向任务则“正确地不被选中”。

第三层端到端任务完成率（End-to-End Pass Rate）
观察选中后参数一次通过的比例，以及最终是否真的完成预订、没有发生非预期错误。

为什么这么强调“正确地不被选中”与诚实描述能力边界？因为工具描述一旦能左右 AI 的决策，恶意操纵也会跟着出现。

2025 年 10 月的预印本《ToolTweak: An Attack on Tool Selection in LLM-based Agents》揭露了这个风险。研究团队发现，攻击者只要以算法反复微调工具的名称与描述，手法类似早期的关键词堆砌与提示注入，就能系统性地拉偏智能体的选择。在实验环境中，目标工具的选中率从约 20% 的基准被拉高到最高约 81%，而且效果能跨越开源与闭源模型。

试想一个危险的情境：市面上出现一个来路不明的第三方换汇或购票工具，在 MCP 描述中塞满“官方授权、零手续费、全网最安全即时出票首选”等诱导字眼，让你的 AI 助理弃用银行或航空公司的官方 API，转而把信用卡数据传给它。这正是工具选择和网页搜索在风险上的根本差异：SEO 点错链接，用户顶多关掉网页；TSO 选错工具，AI 可能直接执行错误转账、删除文件或泄露个人信息。

所以方法论上要画出红线：TSO 的目标是让真实能力与任务意图正确匹配，不是用夸大的词汇换取最高选中率。一个只能查询历史股价的工具，若为了流量把自己描述成能“提供最新股市报价”，只会让智能体做出错误的交易决策，对智能体背后的用户造成伤害，也让工具本身失去信任。

LS-Labs 的研究进度本站正在设计把“候选曝光”与“模型选择”分开观察的受控实验，尚未执行，因此本文不主张任何改写能提高特定工具的被调用比例。实验结果出来后会另文发布，包括没有发现差异的结果。

七、结论：当 AI 成为软件服务的代理操作者，产品需要新的“被理解方式”

从 2023 年 Toolformer 让模型学会按计算器、2024 年 ToolLLM 处理上万个 API 的检索难题，到 2025 年 Anthropic 把工具搜索做成平台功能，以及 2026 年 ToolScope 处理工具库的语义重叠，软件服务的入口正在移动。

过去，打造一款优秀的订位系统、比价网站或理财工具，企业主要思考如何让人类觉得界面好看、广告吸引人。在智能体时代，产品多了一位只看结构化文档、又握有实际执行权的用户：大语言模型与它的检索系统。人会被视觉设计与品牌口号打动；AI 智能体在意的是工具名称是否明确、功能边界是否清晰、参数格式是否没有歧义。

对开发者与企业而言，过去藏在工程部门角落、只为方便对接而写的 API 与 MCP 说明文档，如今走到了竞争前线，成为产品能否被 AI 发现、理解与选用的核心资产。未来的软件市场，除了比谁在人类世界更有知名度，也会比当用户说出需求的那一秒，哪个产品能让 AI 确信：“这就是完成这项任务最可靠的工具。”

想先掌握 TSO 的定义与四段框架，可以从 TSO 主题页开始；工具选用之后智能体能不能把事情办完，则属于 AX（智能体体验）的范围。

参考文献

学术研究

Schick, T., et al. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. NeurIPS 2023. arXiv:2302.04761
Qin, Y., et al. (2024). ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs. ICLR 2024. arXiv:2307.16789
Shi, Z., et al. (2025). Retrieval Models Aren't Tool-Savvy: Benchmarking Tool Retrieval for Large Language Models. Findings of ACL 2025. arXiv:2503.01763
Liu, M. M., et al. (2026). ToolScope: Enhancing LLM Agent Tool Use through Tool Merging and Context-Aware Filtering. ACL 2026, 34095–34119. arXiv:2510.20036
Gan, T., & Sun, Q. (2025). RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation. arXiv 预印本. arXiv:2505.03275
Yuan, S., et al. (2025). EASYTOOL: Enhancing LLM-based Agents with Concise Tool Instruction. NAACL 2025. arXiv:2401.06201
Lu, X., et al. (2026). Tools are under-documented: Simple Document Expansion Boosts Tool Retrieval. ICLR 2026. arXiv:2510.22670
Chen, Y., et al. (2024). Re-Invoke: Tool Invocation Rewriting for Zero-Shot Tool Retrieval. Findings of EMNLP 2024. arXiv:2408.01875
Sneh, J., et al. (2025). ToolTweak: An Attack on Tool Selection in LLM-based Agents. arXiv 预印本. arXiv:2510.02554

官方技术文档与行业资料

Anthropic (2025). Introducing advanced tool use on the Claude Developer Platform. anthropic.com
Anthropic. Tool search tool. platform.claude.com
Model Context Protocol (2026). Specification: Server Tools (2026-07-28). modelcontextprotocol.io
OpenAI. Function calling. platform.openai.com
Biilmann, M. (2025). Introducing AX: Why Agent Experience Matters. biilmann.blog