AI 工具调用到底是怎么运作的？

给模型的是一份菜单，不是一个键盘

在发送请求之前，应用会把可用的工具描述给模型：一个名称、每个工具做什么的说明，以及所需参数的结构定义。模型收到的不是能运行的代码，也不是对任何东西的实时连接——它收到的只是一份描述，就像一个人在读菜单，却接触不到厨房。

模型自己从来不会执行任何操作

当模型判断某个工具会有帮助时，它会生成一个结构化输出——通常是一个工具名称加一组参数——然后就此停下。这时候还没有任何东西被查询、调用或改动过。发出请求的应用会读取这个结构化输出，决定是否据此行动；如果决定行动，就在自己的基础设施上真正执行那个函数或 API 调用。

一次完整的交互是一个循环，不是一步到位

典型的流程是：应用发送一个提示词，连同可用工具的列表；模型要么给出回答，要么提出一次工具调用；如果是工具调用，应用就执行它，并把结果作为对话的一部分发回去；模型接着继续，往往会给出一个用到这个结果的最终回答。多步骤的任务可能会把这个循环重复好几次，用户才会看到最终的回复。

被提出的调用是一个合理的猜测，不是保证正确

模型可能提出错误的工具，编造一个从未出现在结构定义里的参数，或者在根本不需要调用任何东西的时候调用了工具——生成其他任何输出的那种概率性过程，同样也在生成工具调用。这个机制本身没有任何东西能让一次被提出的调用天然就可以安全执行。一个不对照结构定义校验参数、也不确认这次调用真正能触碰到什么就直接执行的应用，等于把真实的访问权限交给了一个猜测。

结构定义是模型实际能看到的唯一接口

一个工具的名称、说明和参数结构定义，就是模型可以依据的全部规格——它没有别的办法知道一个工具做什么、或者该如何正确填写它的参数。同一个底层函数，如果描述得清晰而具体，被正确调用的概率往往远高于描述含糊、或者和不相关选项混在一起的版本，因为模型完全是仅凭这份描述来选择工具并填写参数的。

为什么这和让模型写代码不是一回事

让模型生成一段能运行的脚本，和让它调用一个预先定义好的工具，并不是同一种请求。工具调用被限制在一个名称和一组参数上，而这些是你的应用早就知道该如何安全处理的；自由生成的代码则可能试图做运行环境允许的任何事情，这是一个规模大得多、性质也完全不同的安全问题。工具调用把模型能提出的请求收窄成一组固定的、可以检查的选项。

常见问题

模型会自己执行工具吗？

不会。模型输出的是一个结构化请求，指明一个工具的名称和参数。发出请求的应用决定是否执行它，真正的函数或 API 调用是在应用自己的基础设施上运行的，而不是在模型内部。

模型能不能用编造出来的参数调用工具？

能。模型给出的值可能从来不在结构定义里，或者对这个工具根本没有意义，因为这次调用和其他任何输出一样，都是生成出来的。在执行任何真实操作之前校验参数，是应用自己的责任，而不是模型能保证的事。

如果模型调用了错误的工具会怎样？

这完全取决于应用是怎么构建的。构建得好的应用会在执行调用前先检查它是否合理，可以向模型返回一个错误或需要澄清的结果，而不是直接按照不匹配的请求行事；构建得差的应用则会执行它收到的任何东西。

工具调用和 AI agent 是一回事吗？

不是，但 agent 通常就是建立在它之上的。工具调用是底层的请求-响应机制；agent 通常会把这个循环重复很多次，再加上额外的逻辑，根据每次的结果决定接下来该尝试什么。