# 模型工具调用 - 00 原点

> 把"模型使用工具"这件事,完全用我已有的知识树(操作系统 / 进程 / IPC / 网络协议)来理解,不引入新的本体概念。

---

## 两个原点

整个"模型工具调用"机制,只需要两个原点就能展开:

### 原点 1:任何工具 = 一个进程

不管这个工具表面叫什么(`web_search`、`Gmail:search_threads`、`bash_tool`、`create_file`),背后都是某台机器上有一个**进程**在执行它。

差别只在三个维度:

- **位置**:进程在哪台主机上(本机 / 远程服务器)
- **生命周期**:常驻服务进程 / 一次性 fork 出来的子进程
- **特权级**:用户态业务进程 / 沙箱容器 / 受限子进程

### 原点 2:模型调用工具 = 进程间通讯(IPC)

模型本身也是一个进程——推理进程,通常跑在 GPU 服务器上。它"使用工具",本质就是**和另一个进程通讯**。

整个工具调用机制,就是在解决 IPC 的几个经典问题:

- **寻址**:怎么找到对方
- **编码**:参数和返回值怎么序列化
- **同步**:阻塞等结果还是异步回调
- **容错**:对方挂了 / 超时 / 网络断了怎么办

---

## 澄清:谁在调用工具?

这是一个非常容易被"模型调用工具"这个说法误导的关键认识。

### "模型调用工具"字面上是误导性的

模型本身是一个**纯函数**:输入 token → 输出 token。它不联网、不读文件、不开子进程。所谓"模型调用工具",物理上**模型只是输出了一段 JSON**,内容大致是:

```json
{"tool": "bash", "input": "ls -la"}
```

真正动手执行 `ls -la` 的,是**宿主进程 / 客户端**——也就是 Claude Code、Claude.ai 后端、或者用户自己写的 agent 程序。

### 三层分离的真实架构

```
[模型(纯推理函数)]      ← 远端 GPU 服务器,只做 token 进/出
        ↑↓ HTTPS(总是跨主机)
[客户端 / 宿主进程]      ← 本地或云端,负责"代理执行"工具
        ↑↓ 各种 IPC(本机 stdio / fork / 远程 HTTPS)
[工具进程]              ← bash、Drive API、文件系统、MCP server……
```

**关键点**:一次"工具调用"在物理上**至少涉及两段 IPC**:

- **第一段**:模型 ↔ 客户端(总是跨主机 HTTPS,因为模型在远端 GPU 上)
- **第二段**:客户端 ↔ 工具(可本机可跨主机,看工具部署位置)

### "客户端"这个词的歧义

"客户端"在不同语境下指**不同的东西**,这是混淆的根源:

- **网络架构里的"客户端"** = 相对于某个服务,发起请求的那一方(位置概念)
- **产品里的"客户端"** = 用户用的那个 App / 界面(产品概念)

这两个常常**不重合**。讨论工具调用时,要用第一种含义。

### 三种产品形态对比

| 形态 | 界面在哪 | 工具执行进程在哪 | 能读本地文件吗 |
|---|---|---|---|
| Claude.ai 网页 | 你的浏览器 | Anthropic 服务器 | 不能(除非上传) |
| Claude Desktop(不接本地 MCP) | 你的电脑(WebView) | Anthropic 服务器 | 不能(除非上传) |
| Claude Desktop(接本地 MCP) | 你的电脑 | **你的电脑**(MCP server) | **能** |
| Claude Code | 你的终端 | **你的电脑**(本身就是 agent) | **能** |

**关键洞察**:问的不是"客户端在哪",而是"工具执行进程在哪台机器上"。
界面在哪反而不重要——浏览器、WebView、终端都只是"输入输出通道",真正决定能力的是**工具进程的位置**。

### "客户端" vs "agent" 的区分

这两个概念经常混用,但不是一回事:

- **客户端(client)** 是**位置概念**——相对于模型推理服务,谁是发起请求的那一方
- **agent(智能体)** 是**行为概念**——指"在循环里反复调模型 + 执行工具,直到任务完成"的控制器逻辑

通常 agent 逻辑就跑在客户端里,所以两者经常重合,但不必然:

- 一个简单的客户端只调一次模型、不循环——它是客户端,但不是 agent
- Claude Code 既是客户端,**也**是 agent(它有完整的 loop)

### 用原点重新表述更准确的说法

> **模型推理是一个进程(在远端服务器),它本身不能执行任何工具。所谓"模型调用工具",物理上是:模型推理进程通过 IPC(HTTPS)把"调用意图"以 JSON 形式发给客户端进程;客户端进程作为代理,再通过另一次 IPC(本地 stdio / fork / 远程 HTTPS)去调用真正的工具进程,把结果回传给模型,继续下一轮推理。**

---

## 远程工具:不是都通过 MCP

容易误解的点:**MCP 不是远程工具的必经之路**。

### 远程工具的两条路

**路径 A:客户端直接调用远程 API**

客户端代码里写死了"这个工具叫 web_search,实现就是去调某个搜索 API",直接发 HTTPS 请求,不经过 MCP。

```
[模型] → [客户端] ─── HTTPS ───→ [远程 API 服务器]
```

典型例子:
- Claude.ai 内置的 `web_search`、`image_search`(Anthropic 后端直接调搜索后端)
- ChatGPT 的 web browsing、DALL·E
- 自己用 API + function calling 写的程序,工具实现是自己代码里调的某个 API

**路径 B:客户端通过 MCP server 调用**

客户端只懂 MCP 协议,具体工具是哪个 MCP server 实现的,客户端不关心。MCP server 自己再去调真正的后端 API。

```
[模型] → [客户端] ─ MCP 协议 ─→ [MCP server] ─ HTTPS ─→ [远程 API]
```

典型例子:Claude.ai 接 Google Drive、Gmail、Notion;Claude Desktop 接 Filesystem MCP、Obsidian MCP。

### MCP 的存在意义

**MCP 解决的是标准化问题**——让"工具的实现方"和"模型的使用方"解耦。任何 MCP server 都能被任何 MCP 兼容的客户端用,不用每家客户端都重新对接一遍 Gmail / Slack / Notion。这跟 USB 标准化、ODBC 标准化是一个思路。

但如果**工具实现方和模型使用方是同一家公司**,根本不需要 MCP。Anthropic 自己实现的 web_search,直接进程内调就完事了,套个 MCP 反而是给自己加一层 IPC 开销。

### IPC 跳数对比

| 路径 | IPC 跳数 | 跳的内容 |
|---|---|---|
| 客户端直连 API | 2 跳 | 模型↔客户端,客户端↔API |
| 经 MCP server | 3 跳 | 模型↔客户端,客户端↔MCP,MCP↔API |

MCP 增加的那一跳,**换来的是接入标准化**——值不值,看你是不是"第三方"。

---

## 通讯距离:两类 IPC

按通讯双方是否在同一个内核内,工具调用的 IPC 分两大类。

### A. 同主机 IPC(同一个内核)

模型宿主和工具执行进程跑在同一台机器,通讯走**内核提供的本地机制**。

| 内核机制 | 在工具调用里的体现 |
|---|---|
| 管道 / stdio | MCP 的 stdio 传输:宿主 fork 一个 MCP server 子进程,通过 stdin/stdout 收发 JSON-RPC |
| Unix domain socket | 部分 MCP server 用本地 socket,比 TCP 快、有文件系统权限控制 |
| 共享内存 | 推理框架内部传 KV cache 用,工具调用层基本不用 |
| fork + exec | `bash_tool` 执行命令:宿主 fork 出 bash 子进程,等它退出后读 stdout |
| 信号 | 超时 / 取消工具调用时,宿主给子进程发 SIGTERM |

**典型场景**:Claude Code 在我自己电脑上跑——所有工具(读文件、跑命令、编辑代码)都是本地进程间通讯,没有走网络。

### B. 跨主机 IPC(不同内核)

模型在一台机器,工具在另一台,走**网络协议栈**。

| 协议层 | 在工具调用里的体现 |
|---|---|
| 传输层 | TCP(可靠);几乎不用 UDP |
| 安全层 | TLS 加密(远程工具几乎强制) |
| 应用层 | HTTPS REST(主流);HTTP + SSE(MCP 远程模式);WebSocket(实时);gRPC(企业内部) |
| 编码 | JSON(主流);Protobuf(gRPC);MessagePack(罕见) |

**典型场景**:Claude.ai 调 Google Drive、Gmail、web_search 这类工具——全部是跨主机 HTTPS。

---

## 完整链路示例:`create_file` 的一次调用

以"用 Google Drive 工具创建一个 .md 文件"为例,完整 IPC 链路:

```
[模型推理进程]                                          GPU 服务器
       │
       │ ① 输出 tool_use JSON(进程内,序列化)
       ▼
[Anthropic 宿主进程 / 编排器]                           Anthropic 数据中心
       │
       │ ② 路由:这个工具属于 Google Drive MCP
       │ ③ HTTPS 请求(跨主机 IPC,TLS 加密)
       ▼
[Google Drive MCP Server 进程]                          Google 数据中心
       │
       │ ④ 翻译成 Drive REST API 调用(又一次跨主机 IPC)
       ▼
[Drive 后端服务进程集群]                                Google 数据中心
       │
       │ ⑤ 写入存储(底层又是无数 IPC,略)
       │ ⑥ 返回 file metadata,原路 JSON 回传
       ▼
[模型上下文窗口]   ← tool_result 塞回这里,模型继续推理
```

**关键认识**:每一根箭头都是一次 IPC,只是距离不同、协议不同、可靠性不同。一次"模型用工具",在物理上可能涉及 5~10 次 IPC。

---

## 这个抽象的威力

一旦接受"工具 = 进程,调用 = IPC",很多看起来花哨的东西就回到熟悉的地盘:

- **工具调用为什么有超时** → 远程 IPC 必然有超时,本地阻塞 IPC 也得设上限,跟写网络程序一样
- **为什么要有权限沙箱** → fork 出去的子进程默认继承父进程权限,不限制就是安全漏洞
- **MCP 为什么要分 stdio 和 SSE 两种传输** → 对应"同主机 IPC"和"跨主机 IPC",底层机制完全不同
- **agentic loop 怎么处理工具失败** → 跟写网络程序处理 connection refused / timeout 一模一样
- **为什么所有大模型 API 都要 JSON 序列化** → IPC 必须有 wire format,JSON 是当前最低公共分母
- **为什么模型不能直接联网** → 推理进程没有网络栈访问权限(沙箱限制),必须通过宿主进程代理,这就是"工具"的存在意义

---

## 与已有知识树的对照

| 我已有的知识点 | 在工具调用中的对应 |
|---|---|
| 进程 | 模型推理进程 + 客户端宿主进程 + 工具执行进程(三层分离) |
| 内存 | 上下文窗口 = 工作内存;KV cache = 缓存 |
| shell / 命令行 | agentic loop 就是 LLM 版的 shell;每次工具调用 = 执行一条命令 |
| 系统库 | tool 定义 = 库函数声明;调用约定 = JSON Schema |
| 应用架构 | 客户端 = 模型宿主(实际执行者);服务端 = 工具实现 |
| 网络协议 | MCP over stdio / SSE / HTTP;OpenAI tool calling over HTTPS |
| 客户端进程 | LLM runtime,负责把模型输出解析成工具调用并代理执行 |
| 服务器端进程 | MCP server / 工具后端 |
| 监听端口 | 远程 MCP server 监听 HTTPS 端口;本地 MCP 用 stdio 不占端口 |
| 内核 | 类比"宿主调度器"——决定何时调用工具、何时返回模型 |

---

## 后续要展开的子节点

- `01-本机IPC在工具调用中的体现.md`
  - stdio(MCP local)
  - fork+exec(bash 类工具)
  - Unix socket
- `02-跨主机IPC在工具调用中的体现.md`
  - HTTPS REST(主流)
  - HTTP + SSE(MCP remote)
  - gRPC(企业)
- `03-编码与协议.md`
  - JSON Schema(契约)
  - JSON-RPC(MCP 用)
- `04-控制流-agentic-loop.md`
  - 本质 = REPL + 多轮 IPC
- `05-横切关注点.md`
  - 超时
  - 权限 / 沙箱
  - 失败重试
  - 上下文管理(KV cache 当作模型的"工作内存")

平级旁支(更底层的通用基础):
- `06-互联网作为IPC基础设施.md`

---

## 一句话总结

> **模型用工具 = 一个进程通过 IPC 调用另一个进程。** 但要注意:模型本身不执行工具,执行者是客户端宿主进程;模型只是输出"调用意图"的 JSON。剩下所有概念(MCP、function calling、agentic loop、tool schema)都是这个本质在不同维度上的展开。