LLM如何通过递纸条调用AI工具

早期的 AI 大模型无法直接告诉你“今天天气如何”——但随着技术演进，LLM 已经逐步掌握了“调用外部工具”的能力。然而，这背后的技术逻辑远不止一次简单的 API 请求那么简单。

LLM 的本质是什么？

从技术层面看，并没有那么玄妙。

LLM 的核心任务从头到尾只有一件：根据已有上下文，预测最可能的下一个词汇。

输入1+1=，它预测后面是2。输入今天天气真，它预测下一个词是好。这就是 Next Token Prediction 机制——每次预测一个词，拼接后继续预测下一个，直到对话结束。

但问题来了：如果你问它“青岛啤酒今天的收盘价”，它该如何预测？

它无法预测。训练数据截止于去年，股价是实时变动的。它没有任何渠道获取当前信息。本质上，LLM 只是一堆运行在 GPU 上的矩阵运算，没有网络连接，没有文件系统，也没有数据库驱动。

那么，为什么现在的 AI 都能查天气、查股价、读取文件？

因为背后有人替它完成了这些操作。

为 LLM 提供一张“工具清单”

LLM 并不认识 API endpoint，也听不懂什么叫“调用接口”。

但它能够理解结构化的文字描述。

所以第一步很简单：将你的函数封装成一个 JSON 格式的工具声明，清晰说明它的名称、功能、所需参数。然后通过 API 的tools参数传递给模型。

{
  "type": "function",
  "function": {
    "name": "get_closing_price",
    "description": "获取指定股票在当日的收盘价",
    "parameters": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string",
          "description": "股票名称，如'青岛啤酒'"
        }
      },
      "required": ["name"]
    }
  }
}

这一步在工程上被称为“工具注册”——将一段函数签名“翻译”成 LLM 可读的语言，告知它：“有一个名为get_closing_price的工具，能够查询股价，你只需提供股票名称即可。”

听起来复杂？实际上就是将软件函数降维成一段文本，让 LLM 能够“理解”。唯一需要注意的是description字段必须描述清晰——如果你过于笼统地说“获取信息”，它可能在查询天气时也错误地调用这个工具；而你若明确写“获取指定股票的收盘价”，意图就锁定得十分精准。毕竟，LLM 的决策本质上是概率性的：输入越模糊，输出就越随机。

LLM 不执行，它只“描述”

用户问：“青岛啤酒的收盘价是多少？”

LLM 开始进行一系列判断：

• 训练数据中不包含实时股价 → 无法直接回答。
• tools参数中包含了get_closing_price → 该工具可以解决当前问题。
• 用户提及“青岛啤酒” → 参数应填name: "青岛啤酒"。
• 输出tool_calls，而不是直接输出文字。

于是 LLM 返回了如下结构：

{
  "id": "call_abc123",
  "type": "function",
  "function": {
    "name": "get_closing_price",
    "arguments": "{\"name\":\"青岛啤酒\"}"
  }
}

注意：content字段是空的。LLM 并没有直接回答用户，而是输出了一段“指令”，告诉外部系统：去调用这个函数，传入这个参数。

但它自己并不会执行——也根本无法执行。

打个比方：LLM 就像一个被反锁在房间里的人。门缝下面可以递出纸条。它把“帮我查青岛啤酒的股价”写在纸条上递出去，然后等待。外面的人查完后，将答案从门缝塞回来，它再根据答案组织语言回复用户。

这张纸条，就是tool_calls。

真正执行任务的是 Runtime

纸条递出来了，总得有人去执行。

这个人就是 Runtime——也就是开发者编写的代码。它的工作流程如下：

const response = await sendMessage(messages, tools);
// 1. 发起请求，传入工具列表
const message = response.choices[0].message;
if (message.tool_calls) {
  // 2. 检测 LLM 是否请求调用工具
  const toolCall = message.tool_calls[0];
  if (toolCall.function.name === 'get_closing_price') {
    const args = JSON.parse(toolCall.function.arguments);
    // 3. 解析参数
    const price = get_closing_price(args.name);
    // 4. 执行真实函数 → "67.92"
    messages.push(message);
    // 5. 将 LLM 的工具调用记录追加到上下文
    messages.push({
      role: 'tool',
      content: price,
      tool_call_id: toolCall.id
    });
    const finalRes = await sendMessage(messages);
    // 6. 再次调用 LLM，带上工具执行结果
    // → "青岛啤酒的收盘价是 67.92 元"
  }
}

第 4 步中的get_closing_price函数，与 AI 没有任何直接关系——它只是一段普通的 Ja vaScript：

function get_closing_price(name) {
  if (name === '青岛啤酒') return '67.92';
  if (name === '贵州茅台') return '1234.11';
  return '未找到股票';
}

上面是 Demo 中的模拟数据。在实际场景中，这个函数会查询数据库、调用第三方 API、读取文件——总之就是传统软件开发的标准操作。

新旧范式就在这里交汇。LLM 负责“声明要调用什么”，传统代码负责“真正去执行”。各司其职，然后通过role: "tool"那条消息重新连接起来。

整个流程，一张图

用户问："青岛啤酒收盘价？"
↓
第 1 次调用 LLM（附带 tools 参数）→ LLM 不直接回答，输出 tool_calls
↓
Runtime 检测到 tool_calls → 解析参数 → 执行 get_closing_price("青岛啤酒") → 得到 "67.92"
↓
Runtime 将 "67.92" 以 role: "tool" 拼回消息历史
↓
第 2 次调用 LLM（上下文中增加了工具返回结果）→ "青岛啤酒的收盘价是 67.92 元"

用户视角：问了一个问题，得到了正确答案。体验非常顺畅。

开发者视角：调用了两次 LLM，中间 Runtime 插了一脚，运行了一个真实函数。过程并不顺畅。

但产品层将中间的往返完全封装了。用户看到的只是一个“智能助手”——这就是 Tool Use 在产品设计上的精妙之处。

为什么 Tool Use 如此重要

没有 Tool Use 能力的 LLM 是“死”的。

它可以跟你聊哲学、写诗、解释量子力学——因为这些内容训练数据中都有。但你无法问它“今天我该不该带伞”，因为它没有实时天气信息。你无法让它“帮我把这封邮件发了”，因为它无法触及邮件服务器。

Tool Use 将 LLM 从“死”的状态变成了“活”的状态。

查天气、查股价、搜索网页、发送邮件、读取 Excel、操控电脑——你在网络上看到的那些 AI Agent 的炫酷演示，底层逻辑都是同一套三部曲：注册工具 → LLM 决策调用哪个 → Runtime 负责执行。

豆包的网页搜索功能就是这么实现的，Claude 的 Excel 分析能力也是如此构建，那些让 AI 自动操作电脑的“贾维斯”式演示，同样是在一层又一层的 Tool Use 基础上搭建起来的。

本质上是一层精心设计的“假象”

写这篇文章，并不是因为 Tool Use 技术本身有多难——拆解开来看，每一步都非常简单直接。

写它，是因为这个“假象”设计得实在太巧妙了。

用户觉得 LLM 无所不能。但 LLM 从头到尾只做了唯一一件事——预测下一个词。它凭借的是一套精巧的外围机制：工具注册告诉它能用什么，意图识别让它知道什么时候该用，Runtime 替它把无法完成的事情做了。

公式只有一个：

LLM + Tools = Agent

LLM 是大脑——只负责推理和语言。Tool 是手脚——只负责执行。Runtime 是中间的神经系统——把大脑的指令传递到手脚，再把手脚的结果传回大脑。

下次你对 AI 说“帮我查下今天的天气”时，可以想一想——正在对话的这一刻，它刚刚往门缝下面递出了一张纸条。