chen/AI-document
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
2730adf5e8ccc75474a8d906c92f0a6a1b3d78f0
AI-document/学习笔记/00-模型工具调用-原点.md
T

12 KiB
Raw Blame History

模型工具调用 - 00 原点

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

两个原点

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

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

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

差别只在三个维度:

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

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

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

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

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

澄清:谁在调用工具?

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

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

模型本身是一个纯函数:输入 token → 输出 token。它不联网、不读文件、不开子进程。所谓"模型调用工具",物理上模型只是输出了一段 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)都是这个本质在不同维度上的展开。

Reference in New Issue View Git Blame Copy Permalink