# 模型工具调用 - 00 原点

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

---

## 两个原点

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

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

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

差别只在三个维度:

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

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

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

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

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

---

## 通讯距离:两类 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 当作模型的"工作内存")

---

## 一句话总结

> **模型用工具 = 一个进程通过 IPC 调用另一个进程。** 剩下所有概念(MCP、function calling、agentic loop、tool schema)都是这个本质在不同维度上的展开。