只修改 Tool Description，能不能改变 AI 的工具选择？

周五晚上的订位，AI 挑了别家

周五下班前，你对手机里的 AI 助手说：“帮我查一下大安区的晴丘小馆，这周五晚上七点、四个人还有没有位子？”AI 很快答应帮忙，接着却打开了另一家订位服务，或者干脆回复“目前没有找到合适工具”。对用户来说，这只是一次不太顺畅的使用体验。但站在工具开发者的角度，事情就没那么简单了。API 健康检查正常，工具也确实在安装列表中，连功能描述都写得清清楚楚，模型却没有发出任何调用。后台没有错误信息，也没有失败的请求记录，因为这个工具根本没有得到被执行的机会。

在 AI 应用逐渐具备自主使用工具的能力后，这类问题值得重新审视。过去开发者通常关注 API 能否正常运行、参数是否正确，如今还多了一个前提条件：模型是否愿意选择你的工具？工具名称、功能描述与参数结构，都可能影响模型对工具能力的判断。其中，Tool Description 是开发者相对容易调整的字段，也因此成为一个值得验证的切入点。LS-Labs 据此设计了一组受控实验，试图回答：在工具功能与参数结构不变的情况下，只修改 Tool Description，能不能改变 AI 的工具选择？

结果相当明显。在一组等长描述对照中，两段文字同样只有 22 个汉字，明确写出任务输入的版本，在 96 次适用题测试中被首选 71 次；内容较为空泛的版本则只有 41 次，相差 31.25 个百分点。不过，模型最终有没有调用工具，其实是多个阶段共同作用的结果。如果不先弄清工具是在哪个环节失去机会，单靠修改 Description，未必能解决问题。

工具没被调用，不代表模型不喜欢它

一个工具从接入系统到真正被执行，中间可能经过数次筛选。假设 AI 应用接入了数十个甚至上百个工具，系统未必会在每次对话时，都把所有工具的完整定义交给模型。有些应用采取直接加载的方式，让模型从固定列表中挑选；另一些则会先根据用户需求搜索工具目录，只加载少数相关候选。这种分流不只影响工具能否被看见，也决定开发者该先修检索、描述，还是后端的执行流程。

这使得“没有调用”至少存在两种解释。第一种是工具没有进入本轮候选列表，模型根本不知道它可以使用。第二种则是工具已经被加载，但模型比较了几个选项后，选择调用其他工具。前者涉及候选召回，后者才是模型选择。两者的差异，可以借用信息检索的概念来理解。搜索引擎必须先找出可能相关的网页，才能进一步排序；同样地，一个工具如果没有被纳入候选，后续描述写得再完整，也没有机会影响这次决策。因此，本文将工具调用前后的过程，拆成四个便于观察的阶段。

首先是需求表示。用户说“今晚四个人还有没有位子”，模型需要理解这是查询空位；如果改成“取消我原来订的那桌”，任务就变成修改既有订位。两句话虽然都与餐厅有关，对应的操作却截然不同。接着是候选召回。系统根据可用工具列表与当前需求，决定哪些工具有机会进入模型的工作范围。这个步骤可以由外部检索器完成，也可能根本不存在独立的检索流程。当候选工具确实出现在模型上下文中，才进入这份研究关注的语义匹配。模型需要从名称、Description 与参数 Schema 等信息，理解每个工具的用途与使用条件。

例如，同样是餐厅服务，party_size 暗示工具需要用餐人数，reservation_id 则通常意味着操作对象是一条已经存在的订位记录。最后是最终决策。模型依照任务与候选信息，决定是否提出工具调用，以及选择哪个工具、填入哪些参数。真正的权限验证、API 执行与结果回传，仍由外部系统负责。这四个阶段并非所有 AI 平台都会明确切分的执行流程，而是用来定位问题的分析框架。

对照 LS-Labs 的 TSO 四环节，候选召回大致属于“候选曝光”；语义匹配与最终挑选则涉及“模型选择”。模型提出工具调用后，才会进一步涉及参数填写、调用验证与实际执行。如果没有先确认工具在哪一关失去机会，就很容易把曝光不足误判成描述不够吸引人；反过来，也可能花了大量时间改文案，却没有处理真正挡住工具的检索条件。

Tool Calling、App 与 MCP，分别影响哪个环节？

这里还有一个经常被混淆的问题：工具接入方式，不等于工具选择机制。Tool Calling 通常指模型通过既定格式提出函数调用，由应用程序接手执行的能力。开发者可以直接提供工具定义，让模型从中选择，也可以搭配其他工具检索机制。Plugin 或 App 则偏向产品层。用户可能通过安装、链接、授权或直接指定某个应用，改变模型可使用的服务范围。但即使用户已经链接某个 App，也不代表该 App 下的每一项功能都会在每轮对话中加载。

至于 MCP（Model Context Protocol），主要解决的是 AI 应用如何与外部工具服务器通信。它定义了工具描述、参数 Schema、工具列表与调用等接口，却没有规定模型必须如何排序候选工具。换句话说，MCP 可以让宿主获取工具列表，但宿主是否进一步筛选、何时加载工具，以及模型最终如何选择，都可能取决于应用程序的设计。例如，同一套餐厅查空位服务，同时接入两个 AI 应用。甲每轮都直接提供完整工具定义；乙则先搜索工具目录，再将符合需求的候选加载进模型。

即使两边使用完全相同的 Description，一旦没有发生调用，原因也可能不同。在甲的情况中，工具已经出现在模型面前，应优先调查模型的选择行为；在乙的情况中，则必须先确认工具有没有通过前面的检索程序。这也是本次研究决定将“候选召回”与“模型首选”分开测量的原因。相关平台机制参考 OpenAI Function Calling、ChatGPT Apps 说明及 MCP Tools 规格。文档核对日期为 2026 年 11 月 5 日。

如何测试 Tool Description 的影响？

研究的控制原则很简单：尽可能不改变工具真正能做的事情，只改变模型与检索器看到的信息。实验分成两部分。第一部分通过本地检索器，测试不同 Description 是否影响工具进入候选列表的机会。第二部分则直接把候选工具交给语言模型，观察它在功能相同的选项中，是否会因为描述不同而改变首选。两组实验刻意不串成同一套完整系统，目的是避免把检索结果与模型偏好混在一起解读。

先测工具能不能被找到

召回测试使用 60 个繁体中文合成工具，全部以代号命名，并建立 12 道测试题目。目标工具各准备两种 Description。一种使用明确的任务语言，直接说明工具能处理的操作、对象与条件；另一种则采取偏向宣传的写法，强调服务体验，却没有清楚交代实际能力。换句话说，这一阶段测的不是 Description 写得优不优美，而是它能不能在用户的日常说法里留下足够的检索线索。

检索器使用本地 BM25，索引内容包含工具名称、功能描述、参数名称与参数说明。每次查询最多取回前五个工具，得分为零的工具不纳入候选。以 Recall@5 衡量结果，也就是在测试题中，有多少题成功把目标工具召回前五名。此外，为了观察中文分词的影响，测试分别采用空白与标点切分，以及连续两字切分。这个实验不涉及语言模型，单纯观察工具描述在字面检索时能否与用户需求建立关联。

再让模型从三个工具中做选择

第二部分使用 Gemini 3.1 Flash-Lite，提供三个功能相同的餐厅查空位工具，并直接将完整定义加载进模型，不经过额外的工具搜索。测试包含八道适合使用工具解决的题目，以及四道超出工具能力范围的题目。每道题目在六种工具声明顺序下各执行两轮，因此每个测试条件包含 96 条适用题观测与 48 条超出能力题观测。三批实验合计发出 1,440 次正式 API 请求。三批实验分别检验不同的信号。第一批比较基本描述、同义改写，以及补齐任务输入信息的版本。

第二批进一步控制描述长度，将具体说明与等长中性描述对照，降低文字长度造成的干扰。第三批则将比较范围扩展至 Tool Name、参数 Schema 说明与使用示例，观察不同元数据字段对选择的影响。所有实验都记录模型提出的第一个函数调用。如果模型决定不调用工具，该次观测仍保留在分母中。本文所称的“指定工具首选率”，指的是某个测试条件下，模型第一次选中指定目标工具的比例。它不代表 API 已经成功执行，更不能直接解读为最终任务成功率。

实验一：工具描述太空泛，可能连候选名单都进不去

第一组结果显示，Description 是否包含用户可能使用的任务词汇，会直接影响字面检索结果。在连续两字切分的设置下，任务语言版本在 12 道日常口语题中成功召回 3 题，口号式版本只有 1 题；换成第二版需求单后，两者分别提高到 5 题与 2 题。但如果只按空白与标点切分中文，两个版本在合计 24 道题中的召回数都是零。

从个别题目可以看得更清楚。Q04 的提问是：“明天一早想从台北回台南，高铁还买得到票吗？”任务语言版本写的是“查询指定起止站与日期的高铁班次及剩余座位”。因为描述包含“高铁”，检索器成功建立字面匹配，让它排到第一名。另一个版本使用城市漫游、美好旅程之类的描述，虽然可以让人联想到旅游服务，却没有提供足够的检索线索。在这道题目中，60 个工具都没有取得有效匹配分数。这不是模型理解能力不足，而是 BM25 本来就主要依赖词项匹配。即使两段文字在人类看来含义相近，字面上没有建立联系，检索器也不一定能找到它。

更有意思的是餐厅题。Q01 使用“位子”、“吃饭”等日常说法，目标工具 Description 却使用“订位”与“用餐”。在连续两字切分下，两种描述都没有成功召回目标工具。也就是说，Description 即使已经使用正确的专业词汇，也可能因为与用户实际用语不同，而错失检索机会。反过来，将分词切得更细，也可能产生没有实际语义关联的匹配。例如宣传词中的单个汉字，恰好与用户提问中的名称重叠，让原本不相关的工具意外取得分数。

这说明，检索结果不能只看有没有进入前五名，还需要检查实际命中的字段与词项。不过，这组结果也有明确的适用范围。它证明的是：在本地 BM25 字面检索环境中，描述用语与分词策略都会影响候选召回。它没有测量任何商用 AI 平台的实际工具曝光率，也不能直接推论语义检索器会得到相同比例的改善。但对采用字面检索或混合检索的工具目录而言，这是一个值得注意的问题。工具不只需要说明自己能做什么，也需要让检索系统有机会从用户的语言中找到它。

实验二：三个功能相同的工具，模型会选哪一个？

接下来排除候选召回的干扰。这次模型每轮都能看到三个功能相同的餐厅查空位工具。三者具备相同的执行能力，差异主要来自实验刻意调整的名称、描述或参数信息。如果模型的选择分布发生变化，便能更直接地观察元数据对首次工具选择的影响。三批实验的结果整理如下。为了让差异只反映元数据，而不是任务或候选数量改变，后续三批实验都维持相同的题库、模型设置与三个候选工具。

注：各行只比较同一批实验内的条件，不应将不同批次的百分点差值直接当成统一的效果排名。

同样 22 个字，差别不在写得多，而在说得清不清楚

这份研究最关注的是第二批等长对照。为了避免“描述比较长，所以模型更容易选中”这种解释，实验将两组 Description 控制在相同的 22 个汉字，且每组配对请求的输入 token 数一致。其中一个版本明确列出“餐厅名称、用餐日期、人数”三项输入信息；另一个版本则使用较为中性的服务介绍，没有具体交代操作条件。两者的工具功能、参数结构与测试题目都没有改变。结果，前者在 96 次适用题观测中获得 71 次首选，后者只有 41 次。31.25 个百分点的差距，不能用单纯的文字长度解释。

Description 提供的信息越具体，模型就越容易把用户需求与工具能力对上。例如，用户提到四个人用餐，而描述恰好说明需要提供用餐人数，这两个信号之间便形成了直接关联。相比之下，“提供便捷且优质的餐饮服务”这类文字，即使对人类读者具有宣传效果，也不一定能帮助模型判断这个工具是否适合眼前的任务。这不代表模型一定是在进行某种固定的字段比对，也无法据此还原它的内部推理过程。

能确认的是，在这组控制条件下，描述是否明确包含任务所需信息，确实改变了模型的首选分布。同义改写则没有带来相近的效果。第一批实验中，基本描述被首选 30 次，同义改写版为 31 次，只增加 1.04 个百分点，95% 区间也跨过零。因此，本次结果并不支持“只要换一种说法，就能明显提高工具首选率”的推论。真正拉开差距的是信息内容，而非单纯润色语句。

Tool Name 与参数说明，影响同样明显

第三批实验把范围扩大到 Description 之外。首先是工具名称。当一个原本使用 service_a 这类代号的工具，改以 find_available_tables 命名后，在该批 96 次适用题观测中，指定工具全部获得首选；基本条件下则只有 32 次。这是本次信号实验中幅度最大的变化。这也是后续诊断要把名称、描述、参数与示例分开观察的原因。

不过，这里需要特别注意：三个工具原本都使用代号命名，改成动词式名称，不仅增加了语义，也让它在候选列表中显得更加突出。因此，实验尚不能确定首选增加有多少来自名称与任务的语义匹配，又有多少来自模型对特殊命名形式的偏好。参数 Schema 的效果则比较容易理解。原本只提供 date、party_size 等字段名称；加入“用餐日期，YYYY-MM-DD”及“用餐人数，含儿童”等说明后，指定工具首选从 32／96 提高到 61／96。

工具功能并未改变，但输入字段的含义与使用方式变得更明确。使用示例也产生了影响。在 Description 结尾加入“例如：查询某餐厅某日四人可订的时段”，首选由 32／96 增加到 54／96。综合三批实验可以看到，模型并不是只凭工具名称或单一描述做决策。名称、Description、Schema 说明与使用示例，都可能成为判断工具适用性的线索。这也解释了为什么工具能力完全相同，模型依然可能表现出明显偏好。对模型而言，它接触到的不是工具背后完整的代码，而是应用程序交给它的工具定义。当这些定义发生改变，即使后端服务丝毫未动，模型理解到的能力与适用情境仍可能不同。

首选率上升，不等于任务完成率上升

这组实验还有一个容易被忽略的地方。在这组测试条件下，所有适用题都产生了符合测试要求的工具调用提案；超出工具能力范围的题目，也没有发生误调用。因此，表 2 的差距主要反映的是：当多个工具都能完成相同任务时，模型把第一次调用交给谁。这与模型是否具备正确判断工具适用性的能力，是两个不同的问题。因此，首选率只能回答偏好问题，不能回答任务成果。

如果三个工具的功能完全相同，模型从 A 改选 B，并不代表用户一定获得更好的结果。只有在真实服务情境下，候选工具的价格、延迟、数据质量、权限或执行能力存在差异时，选择偏好才可能进一步影响任务成果。此外，实验没有连接真实餐厅系统，也没有实际完成查询或订位。测试检查的是模型提出的调用提案与参数是否符合测试定义，而非外部系统是否成功执行。另一个需要注意的变量是模型既有的选择偏好。在功能相同的工具之间，代号、声明顺序或命名方式，都可能影响模型的首选。这也是实验采用多种声明排列，并让不同测试条件在相同题目中比较的原因。

如果只挑选少数问题测试，很容易把某个工具恰好被选中的结果，误认为 Description 优化奏效。更完整的验证方式，应该在同一组题目与候选配置下反复比较，并记录未调用、选择其他工具与选中目标工具等不同结果。只有这样，才能判断观察到的差异究竟来自描述调整，还是原本就存在的模型偏好。调用之后的参数与回传判读，可接着阅读TCC 的 152 条验收测试；网站如何提供授权与完成凭据，则可对照AX 的本地订位实验。

从实验回到实务，开发者应该先改什么？

如果只看本次实验，最容易得出的结论是：把工具描述写具体一点，并尽量使用语义清晰的名称与参数说明。这个方向没有问题，但它仍然缺少一个前提。不是每一次没有调用，都适合通过修改 Description 来解决。假设开发者发现某个订位工具几乎没有使用记录，第一件事应该是确认它有没有实际进入模型的候选列表。如果工具在检索阶段就被排除，应优先检查索引内容、检索用语、召回门槛与工具加载策略。这时候只修改模型看得到的 Description，却没有同步更新检索索引，可能根本不会影响结果。

如果工具已经被加载，却经常输给其他功能相近的工具，才适合进一步比较名称、Description、参数 Schema 与示例。例如，与其描述“整合各式餐饮需求，提供优质用餐体验”，不如直接说明工具可以“查询指定餐厅、用餐日期与人数的可订时段”。但具体不代表把所有关键词都塞进 Description。工具真正能处理的任务、必要输入与限制条件，仍然必须保持一致。尤其是查询与写入类操作。

“查询当前可订时段”、“创建订位”和“取消既有订位”可能涉及同一套后端服务，但代表完全不同的权限与操作风险。若描述没有交代能力边界，模型即使选中了工具，也可能在错误的情境下提出调用。至于工具已经被选中、却没有完成用户需求的情况，问题则可能出在参数解析、授权、外部 API 或执行结果。这些都不是首选率能回答的问题。因此，与其只在后台显示一个总调用次数，不如为工具调用流程保留四类记录：

1. 任务适用性：这道题是否应该使用该工具，还是应先追问或拒绝调用？
2. 候选曝光：工具是否实际进入这一轮加载给模型的候选列表？
3. 模型选择：第一次调用选了哪个工具？是否发生未调用或错选？
4. 执行结果：参数是否正确，外部服务是否执行成功，用户任务是否完成？

这四类信息可以让开发者辨认，同样一条“没有成功使用工具”的结果，究竟是哪个环节出了问题。也只有在知道问题发生在哪里之后，Description 的修改才有明确的验证目标。换句话说，四栏记录不是为了做报表，而是把优化目标从“让调用变多”改成“让每一个失败都有可定位的原因”。只有先分清问题层次，Description 的调整才不会变成盲目试错。

回到那个周五晚上

对准备订餐厅的用户来说，他不会知道背后有多少工具参与竞争，也不会在意开发者为了 Description 修改了几个字。他只在意 AI 能否理解需求，找到正确的服务，并确实完成查询。但对工具开发者而言，这些看不见的选择过程，可能决定一项服务有没有机会被使用。本次实验显示，即使不修改后端功能，仅调整工具描述中的任务信息，就能显著改变模型的首选分布。这并不意味着所有工具都应该立刻重写 Description。更值得先做的，是确定工具究竟在哪个环节失去了机会。

如果没有进入候选名单，应处理检索与曝光；如果进入候选却没有被选中，才需要检查模型如何理解工具定义；如果已经被调用，则必须回到参数与实际执行结果。当工具选择逐渐成为 AI 应用的常态，Tool Description 也不再只是写给开发者阅读的 API 文档。它同时是模型理解外部能力、判断使用时机的一部分。哪怕只是短短几十个字，都可能改变一个工具被使用的机会。