What Is Tool Use in LLMs? How Tool Calling Works

你也可能会看到它被称为“工具调用”或“函数调用”。这些名称通常指的是同一种机制。不过，有些平台将“工具”作为更广泛的类别，除开发者定义的函数外，还包括托管搜索、代码执行、文件检索或计算机控制。

一个有用的思维模型

把模型看作调用方，而不是执行工作的机器。

模型可以生成类似“使用订单 ID 4821调用 get_order_status”这样的结构化请求。但该输出仍然只是模型响应；模型本身不会因此直接查询数据库。

周围的应用程序会接收该请求，并控制接下来发生的事情。它可以拒绝调用、要求用户确认、检查权限、运行代码或返回错误。如果它运行了工具，就会将结果作为新的上下文交回模型。模型随后可以解释结果，或请求另一个工具。

这种分离是工具使用的核心事实：

User request
    ↓
Model selects a tool and proposes inputs
    ↓
Application validates, authorizes, and executes
    ↓
Tool result returns to the model
    ↓
Model answers or requests another tool

一些提供商还提供由其服务器自行执行的托管工具。API 可能会隐藏循环中的某些部分，但逻辑阶段仍然不变：模型请求一项操作，执行系统运行该操作，结果进入对话。

工具使用的工作方式

1. 应用程序描述每个工具

工具定义通常包括：

一个名称，例如 get_order_status
关于何时使用它的自然语言描述
它接受的输入
每个输入的格式和类型规则

这些输入规则通常以 JSON Schema 表示。该模式可能规定 order_id 是必填字符串。描述告诉模型工具的含义；模式告诉模型如何格式化调用。

2. 模型接收请求和工具定义

模型会结合可用工具的描述来考虑用户消息。在 API 和应用程序允许的情况下，它可以正常回答、请求一个工具，或请求多个工具。

工具选择是一种预测，而不是有保证的计划。模型可能选择错误的工具、遗漏必要的调用，或提出格式正确但不合适的参数。

3. 模型返回结构化工具调用

响应中会包含机器可读的调用，可以替代普通文本，也可以与普通文本同时出现。简化后的形式可能如下：

{
  "name": "get_order_status",
  "arguments": {
    "order_id": "4821"
  }
}

不同提供商的 API 会使用不同的消息类型来编码这一调用，并附加一个标识符，以便将最终结果匹配到正确的调用。具体封装形式会有所不同，但名称加输入这一理念在各大 API 中是一致的。

4. 应用程序决定是否执行调用

拟议的操作是否会变成真实操作，取决于这一阶段。

应用程序会解析参数，并根据不止模式本身的内容进行检查。它可能验证登录用户、执行访问规则、限制取值、要求对副作用进行审批，或拒绝不可用的工具。只有之后，工具运行器才会调用数据库、API、计算器、文件系统或其他系统。

严格的模式可以提高结构可靠性，但它不是授权系统。"order_id": "4821"可以是有效 JSON，同时仍然指向他人的订单。

5. 工具结果返回模型

应用程序会在与原始调用关联的结果消息中发送输出。输出可能包含数据、错误，或权限被拒绝的说明。

模型将该结果作为额外上下文使用。它可以生成最终答案、纠正之前的假设，或再次调用工具。多步骤的AI 智能体可能会重复这一循环，直到达到停止条件。

示例：查询订单

假设一家商店提供一个只读工具：

Name: get_order_status
Purpose: Return shipping information for an order the current user owns
Input: order_id (required string)

用户提问：

订单 4821 在哪里？

模型请求：

{
  "name": "get_order_status",
  "arguments": {
    "order_id": "4821"
  }
}

在查询任何内容之前，应用程序会检查当前会话。如果用户拥有订单 4821，它就执行查询并返回：

{
  "status": "shipped",
  "estimated_delivery": "Friday"
}

模型现在可以回答：“订单 4821 已发货，预计周五送达。”

如果所有权检查失败，应用程序不应执行查询或透露订单状态。它可以返回权限错误，由模型进行解释，而不会泄露私密数据。

模型的调用并没有证明所有权。工具模式描述了一个有效请求；应用程序才执行了真正的规则。

工具使用为何重要

工具使用使语言模型能够受控地访问仅凭文本生成无法提供的能力。

最新或私有数据：工具可以检索当前信息，或模型训练材料中从未包含的数据。
精确操作：计算器、数据库查询或程序可以执行不应依赖貌似合理的估算的工作。
实际操作：工具可以创建记录、发送消息、安排事件或操作其他软件。
现有系统：工具可以将自然语言请求转换为对现有业务 API 的调用。
多步骤工作：一次调用的结果可以指导下一次调用。

工具使用不会消除模型的局限性。它只是将部分任务转移给更适合处理这些任务的系统，并在概率性决策与确定性软件之间建立接口。

可靠性和安全性取决于周围的系统

模型的输出即使符合模式，也不意味着它是可信的命令来源。生产环境中的工具使用需要在模型周围设置控制措施。

验证含义，而不只是验证格式。检查标识符、范围、必要状态和业务规则。结构验证无法判断拟议交易是否符合用户请求。

在执行时进行授权。使用应用程序持有的身份和权限。不要让模型通过在工具参数中放入用户 ID 或角色来授予自己访问权限。

限制每个工具的权限。一个范围狭窄的 get_order_status工具比通用数据库工具更容易控制。当风险不同时，读工具和写工具应当分开。

将工具输出视为不可信数据。外部内容可能是错误的，也可能包含旨在引导模型偏离方向的文本。返回的文档是需要检查的信息，而不是可以取代用户请求或系统规则的新权威。

谨慎处理副作用。发送消息或发放退款不同于查询状态。敏感操作可能需要确认、防止重复执行的幂等保护以及审计记录。

清晰地返回失败。超时、服务不可用、权限被拒绝和参数无效都应成为明确的工具结果。否则，模型可能会用虚构的成功来填补空白。

常见误解

“LLM 调用了我的 API”

通常情况下，LLM 生成了请求，而应用程序调用了 API。说模型“调用”了工具是一种方便的简写，但会掩盖执行边界和安全边界。

“函数调用和工具调用始终不同”

对于开发者定义的函数，提供商和框架通常会交替使用这些术语。当平台将“工具”作为函数与搜索或代码执行等内置能力的总称时，二者才会出现差异。应查看平台自身的分类方式，而不要假定存在普遍适用的区别。

“有效的模式意味着正确的调用”

模式可以要求字符串、数字、列表或对象，并拒绝格式错误的输出。但它无法保证模型选择了正确的工具、推断出了正确的值，或遵守了业务规则。

“添加工具就会创建智能体”

工具使用是一种能力。智能体则是更大的系统，能够进行决策、采取行动、观察结果、保留相关状态、重复循环并停止。一次性的结构化调用可以使用同一种机制，却不一定会成为自主工作流。

“工具结果一定是真的”

模型可能会忠实地总结错误结果。工具可靠性、数据新鲜度、访问控制以及抵抗恶意内容的能力，都是整个系统的属性，而不仅仅是语言模型的属性。

工具使用在 AI 系统中的位置

工具使用位于语言模型与其周围系统的边界上。

模型理解语言并提出结构化的下一步。应用程序提供工具定义、维护对话状态、验证调用、管理权限、执行操作并返回观测结果。工具提供范围狭窄的能力。智能体可以重复使用这一安排来完成更大的任务。

这就是为什么工具使用质量不只是模型属性。清晰的工具描述、明确区分的模式、执行控制、有用的错误消息以及合理的停止规则，都会影响系统能否正常工作。

接下来阅读什么

阅读“什么是 AI 智能体？”，了解工具调用如何成为具有状态和停止规则的重复计划—行动—观察循环的一部分。阅读“什么是 AI Harness？”，了解用于验证和执行这些调用的软件；然后阅读“AI 模型 vs. 聊天机器人 vs. Harness vs. 智能体”，将工具使用置于更广泛的系统中。