Files

T

chen d27f762d75 添加学习笔记：模型工具调用、学习方法论、律师视频Agent等

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-05-09 16:30:33 +08:00

6.2 KiB

Raw Blame History

模型工具调用 - 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)都是这个本质在不同维度上的展开。

6.2 KiB Raw Blame History