你给一个 AI Agent 配了十几个 Tool：搜索、查数据库、读文件、发邮件、查天气、创建日程。代码跑起来后，一个很常见的问题出现了。
明明应该搜索，它却直接回答；明明应该调用数据库，它选了文件检索；更麻烦的是，两个 Tool 功能稍微接近一点，模型就像在"猜"。
于是很多人会问：模型到底是怎么知道什么时候该调用 Tool，又怎么知道该选哪一个？
答案没有想象中神秘。模型并不是突然拥有了一个"工具调度器"。对模型来说，Tool 本身也是上下文的一部分。它看到工具的名称、描述、参数，再结合用户当前的问题，预测下一步最合适的动作。
所以，Tool Calling 做得好不好，很大程度上不是模型能力问题，而是你有没有把工具"介绍清楚"。
模型不是"知道"要调用 Tool，而是在判断下一步该做什么
可以把模型想象成一个刚加入公司的新同事。
你告诉他：
你可以直接回答问题，也可以使用下面这些系统。
然后给他几张说明卡：
-
search_web：搜索互联网最新信息 -
query_database：查询公司内部业务数据 -
get_weather：获取指定城市天气
用户问："今天上海天气怎么样？"
模型看到问题里包含"今天""上海""天气"，同时看到一个 Tool 的描述恰好说明它能够获取城市天气，于是调用 get_weather，就成了非常自然的下一步。
这里没有一个隐藏的 if weather: call_tool()。
模型做的仍然是语言模型最擅长的事情：根据上下文预测合理输出。区别只是它现在可以输出两类结果：普通文本，或者结构化的 Tool Call。
这也解释了一个常见现象。
如果用户问："法国首都是什么？"
即使系统里有 search_web，模型也可能直接回答巴黎。因为这个问题依靠已有知识就足够完成，调用搜索反而增加成本。
但用户问："法国总统今天发表了什么讲话？"
"今天"意味着答案依赖最新信息。这时搜索 Tool 的价值明显上升。
所以判断"什么时候调用 Tool"，通常来自三个信息：用户要完成什么任务、模型当前是否拥有足够信息，以及 Tool Description 告诉它这个工具能补充什么信息。
选择哪个 Tool，本质是在做语义匹配
假设一个系统里有两个工具：
用户问：
"我们公司的报销标准是多少？"
模型并不需要知道这两个 Tool 背后用了什么搜索引擎，也不关心它们分别调用 Elasticsearch 还是某个 API。
它只需要识别两个语义：
"我们公司的"对应 internal。
"报销标准"通常存在于企业制度或内部文档。
因此第二个工具匹配度更高。
这也是 Tool Calling 设计中非常重要的一点：模型选择的是工具的语义边界，不是代码实现。
很多开发者习惯从程序员视角给工具命名，例如：execute_v2
这些名字对代码组织也许没有问题，对模型却几乎没有提供有效信息。
如果把 Tool 当成给模型看的 API，那么 Tool Name 和 Description，其实就是这个 API 的用户界面。
Tool Name 最好让模型"一眼知道它是干什么的"
好的 Tool Name 通常不需要聪明，只需要明确。
例如：
get_weather
search_web
这些名字有一个共同特点：动词 + 对象。
模型很容易建立"用户意图 → 工具动作"的映射。
问题不是模型完全理解不了，而是名字没有帮助它缩小选择范围。
假设你有 30 个 Tool，每个名字都很模糊，那么模型只能更加依赖 Description 去区分。工具越多，这种歧义越容易累积。
还有一个常见误区，是试图把所有规则塞进 Tool Name
名字太长并不会自动变得更准确。Tool Name 最重要的任务，是建立一个稳定、清晰的概念。真正的使用条件，应该交给 Description。
Tool Description 决定了工具的"使用说明书"
同样一个 search_web，包含三个关键问题：
它能做什么；
什么时候应该使用；
什么时候不应该使用。
这就是优秀 Tool Description 的核心。
尤其在复杂 Agent 中，"不要什么时候用"往往和"什么时候用"同样重要。
比如有两个工具：
search_web
search_company_docs
模型就很难知道所谓 documents 是用户上传文件、公司知识库，还是互联网上的 PDF。
更好的写法是明确边界
模型的选择空间立刻清晰很多。
两个 Tool 很像时，不要指望模型自己理解你的架构
Tool Calling 最容易出问题的场景之一，就是两个工具能力高度重叠。
例如：
search_web
deep_search_web
一个普通搜索，一个深度搜索。
如果 Description 分别只是：
Search the web.
和：
Search the web deeply.
你可能觉得区别很明显，模型却需要猜测"deeply"到底意味着什么。
真正应该描述的是使用条件。
例如普通搜索适合寻找单个事实、网页或最新状态；深度搜索适合需要多个来源、比较、综合分析的问题，并且耗时和成本更高。
这样，当用户问"OpenAI 官网最新的 API 价格是多少"，模型更可能使用普通搜索。
如果用户问"比较过去两年主要 AI 编程工具的商业模式变化"，深度搜索才更合理。
如果两个 Tool 连你自己都无法用一句话解释清楚"什么时候用 A、什么时候用 B"，那通常说明工具边界本身就值得重新设计。
有时最好的优化并不是继续改 Prompt，而是合并工具。
Description 也不是越长越好
既然 Description 很重要，一个自然的想法就是：那我把所有规则都写进去。
这同样会出问题。
假设系统里有 50 个 Tool，每个 Description 都有几百字。模型每次处理用户请求，都要同时阅读这些工具说明。
结果可能出现三件事。
第一，上下文变长，Token 成本增加。
第二，真正重要的区别被大量细节淹没。
第三，多个 Tool Description 中出现相似甚至冲突的规则，模型反而更难判断。
好的 Tool Description 更像机场指示牌，而不是产品说明书。
它应该优先回答：
"这个工具解决什么问题？"
"典型什么时候使用？"
"最容易和哪个工具混淆？"
"关键限制是什么？"
至于 API 内部用了什么数据库、请求经过几层服务、返回结果如何缓存，除非这些信息会影响模型决策，否则通常没有必要告诉模型。
设计 Tool，真正要优化的是"决策边界"
很多人在做 Agent 时，会不停增加 Tool。
搜索不够，就加一个高级搜索；数据库查询不够，再加一个智能查询；文件读取之外，再加一个文档理解 Tool。
工具数量越来越多，Agent 却未必越来越聪明。
因为模型面对的其实是一个分类问题：对于当前任务，我应该选择哪个动作？
类别越多、边界越模糊，分类当然越困难。
所以设计 Tool 时，可以做一个很简单的检查：把所有 Tool Name 和 Description 单独列出来，不看代码实现，然后问自己------如果我是第一次看到这些说明，我能不能快速判断每个工具分别什么时候使用？
如果答案是否定的，模型大概率也会犹豫。
一个可靠的 Tool 系统，往往不是拥有最多工具的系统，而是每个工具都有清晰职责：名字告诉模型"它是谁"，Description 告诉模型"什么时候找它"，参数定义告诉模型"找它时需要提供什么"。
模型为什么知道什么时候调用 Tool？
因为我们把"可选动作"放进了它的上下文。
模型为什么知道调用哪个？
因为 Tool Name、Description、参数和当前任务共同提供了判断线索。
这也意味着，调试 Tool Calling 时，不要只盯着模型输出。把 Tool 定义重新读一遍，检查重复能力、模糊命名和缺失的使用边界，往往更有效。
你不是在给模型写一份 API 文档。
你是在设计它做决定时看到的那张地图。