核心概念与本质

1.1为什么 LLM 需要工具

工具是给冻结在训练时刻的模型，开一扇通向实时世界、私有数据和副作用的门。

底层机制比文档深一层：模型生成的是 token 上的概率分布，它没有任何机制能「访问外部世界」——除非外部世界以 token 的形式出现在它的 context（上下文，即喂给模型的全部文本）里。工具调用的全部把戏，就是把「访问外部世界」变成「往 context 里追加 token」的一套协议。所以模型不是「学会了查天气」，而是「学会了发出一个查天气的请求，并在结果作为 token 回到 context 后继续往下写」。

1.2本质：模型只请求，不执行

模型生成一段「我要调用 X，参数 Y」的结构化文本，然后停机；执行发生在模型之外。

这是整篇教程最该先扭转的一个认识：跨过去，后面三章都顺；跨不过去，后面会反复绊住。用一个查天气的场景，把往返的 5 步显式走一遍。

1. 用户问「旧金山现在天气怎样」。
2. 模型不知道实时天气，于是输出一个结构化请求：调用 get_weather，location="San Francisco"——然后停机（stop_reason 变成 tool_use，生成中止）。
3. 你的程序（harness）读到这个请求，真正去调天气 API，拿到 15°C, 多云。
4. harness 把这个结果作为 tool_result 塞回对话。
5. 模型读到 tool_result，生成「旧金山现在 15°C，多云」。

关键在这里：模型自始至终没碰过天气 API，它只产出了文本。第 3、4 步全是你的代码——模型既不会自己去调 API，也不会自己把结果接回来。

下面是这次往返在报文层的样子。assistant 先吐出一个 tool_use 块并把 stop_reason 标成 tool_use；harness 执行后，把结果作为 tool_result 接回去。

// 第 2 步：模型的输出（assistant 消息），随即停机
{
  "role": "assistant",
  "content": [
    {
      "type": "tool_use",
      "id": "toolu_01A",
      "name": "get_weather",
      "input": { "location": "San Francisco" }
    }
  ],
  "stop_reason": "tool_use"
}

// 第 4 步：harness 执行后，把结果作为 user 消息接回去
{
  "role": "user",
  "content": [
    {
      "type": "tool_result",
      "tool_use_id": "toolu_01A",
      "content": "15°C, 多云"
    }
  ]
}

1.3一次往返的 5 个角色

把 1.2 的 5 步抽象成 5 个固定角色，每个角色对应那一步里「谁在做什么」：

1. 工具定义——你提前声明有哪些工具（对应 1.2 之前的准备：name、description、参数 schema 都在请求里一次性给到模型）。
2. 模型决策——基于 description 选工具、填参数（对应第 2 步的前半）。
3. tool_use 请求——模型的输出 + 停机（对应第 2 步的后半，stop_reason = tool_use）。
4. harness 执行——你的代码真正干活，去调 API、查库、写文件（对应第 3 步）。
5. tool_result 回填——结果变成 context 里的 token，模型才「看得见」（对应第 4 步）。

底层机制一句话：这 5 个角色里，只有「模型决策 / tool_use 请求」发生在模型内部；其余三个都在模型外。图 1.1 底部的两条边界标签画的就是这条分界线。

1.4function calling 就是 tool use

「function calling」和「tool use」指的是同一套机制，只是不同厂商的叫法。

OpenAI 最早叫它 function calling，如今把 function 当作 tool 的一种 type；Anthropic 一直叫 tool use。机制完全相同：声明 → 模型请求 → 你执行 → 回填。读不同文档时别被名字绊住——同一张图 1.1，换个术语标签而已。