6.1 KiB
AI工具调用机制学习笔记
本笔记针对薄弱环节整理,重点梳理 CLI、GUI、API、MCP、Function Calling、Agent 之间的关系。
一、CLI vs GUI —— 工具软件的两种交互方式
工具软件与用户的交互方式分两类:
| 类型 | 全称 | 本质 | 例子 |
|---|---|---|---|
| CLI | Command Line Interface(命令行界面) | 用文字命令操控软件 | git commit -m "fix" |
| GUI | Graphical User Interface(图形界面) | 用鼠标点击操控软件 | Photoshop、Word |
关键点: CLI 和 GUI 是同一个软件暴露给用户的不同"入口",不是两种软件。
二、并非所有软件都有 CLI
- 有 CLI 的软件: 开发工具(git、npm)、服务端软件(nginx、mysql)
- 没有 CLI 的软件: 创意设计类(Photoshop、Figma)、办公软件(Word、Excel)
Photoshop 的例子: Photoshop 是纯 GUI 软件,没有原生 CLI。只能通过脚本(ExtendScript/UXP)做有限自动化,或通过 GUI 模拟操控。
三、模型调用工具的三种方式
工具软件
├── CLI → 模型直接生成命令文本调用
├── GUI → 模型模拟人的鼠标/键盘操作(Computer Use)
└── MCP → 模型通过标准化协议调用
三者对比
| 方式 | 本质 | 稳定性 | 适用范围 |
|---|---|---|---|
| MCP | 标准化 API 协议 | 最高 | 支持 MCP 的工具 |
| CLI | 命令行文本调用 | 高 | 有 CLI 接口的工具 |
| GUI 模拟 | 模拟人操作(截图+点击) | 最低 | 几乎所有软件 |
MCP 是最优雅的方式,CLI 是最普遍的方式,GUI 模拟是最后的手段。
四、API、CLI、MCP 工具的本质是同一件事
一个 API 工具 ≈ 一条 CLI 命令
CLI 世界:
git commit -m "fix bug"
↑命令 ↑参数
API/Function Calling 世界:
{ "tool": "git_commit", "params": {"message": "fix bug"} }
↑函数名 ↑参数
| CLI 概念 | API/MCP 概念 |
|---|---|
| 一条命令 | 一个 tool/function |
| 命令参数 | parameters |
| 标准输出 stdout | 返回值 result |
管道串联 | |
Agent 多步调用 |
| Shell 脚本 | Agent 框架 |
工具就是工具,无论包装成命令、函数还是协议,内核都是输入 → 处理 → 输出。
五、MCP 是什么?谁来实现它?
MCP(Model Context Protocol) 是 Anthropic 在 2024 年提出的标准化协议,专门解决"AI 模型如何调用外部工具"的问题。
可以理解为:AI 世界的 USB 接口标准。
谁来实现?
- 工具方(MCP Server): 工具软件开发者按照 MCP 规范实现 Server 端,暴露工具能力
- 模型/客户端(MCP Client): Claude、Cursor 等按同一规范调用,无需为每个工具单独适配
传输方式
| 方式 | 场景 |
|---|---|
| 本地进程(stdio) | MCP Server 跑在本地,模型直接调用本地进程 |
| 远程 HTTP/SSE | MCP Server 部署在云端,模型通过网络请求调用 |
注意: 远程方式本质上就是网络 API 调用,所以 MCP 内置了 OAuth 认证来保障安全。
六、大模型是如何调用 API 的?
传统 API 调用 vs 大模型调用
| 传统代码调用 | 大模型调用 | |
|---|---|---|
| 调用时机 | 程序员硬编码决定 | 模型运行时动态决定 |
| 调用逻辑 | 确定性 | 概率性/推理性 |
| 输入参数 | 代码变量 | 从自然语言中提取 |
| 执行者 | 代码本身 | 外部系统代为执行 |
关键理解
模型输出的不是"执行",而是"调用意图"(结构化描述)。 真正的执行由外部系统完成。 模型做的是决策,不是执行。
七、Function Calling、MCP、Agent 框架的层次关系
┌─────────────────────────┐
│ Agent 框架 │ ← 调度层:决定做什么、做几步
│ LangChain / AutoGen 等 │ (多步循环:思考→行动→观察)
├─────────────────────────┤
│ Function Calling │ ← 协议层:模型表达调用意图
│ MCP │ (MCP 是 Function Calling 的标准化封装)
├─────────────────────────┤
│ 实际 API / 工具 │ ← 执行层:真正干活
│ 天气 / 搜索 / 邮件 / DB │
└─────────────────────────┘
Function Calling vs MCP
| Function Calling | MCP | |
|---|---|---|
| 定义工具的人 | 每个开发者自己写 | 工具方统一提供 |
| 执行工具的人 | 开发者自己实现 | MCP Server 负责 |
| 可复用性 | 低 | 高 |
| 适合场景 | 自定义工具 | 通用标准工具 |
Function Calling 是地基,MCP 是标准化建材。没有 MCP,Function Calling 照样能用,只是更零散。
Agent 框架的核心循环(ReAct 模式)
用户提问
→ 【思考】规划任务步骤
→ 【行动】调用工具 A
→ 【观察】获取结果
→ 【思考】是否需要继续?
→ 【行动】调用工具 B
→ 【观察】...
→ 直到任务完成,输出最终回答
Agent 框架(LangChain 等)负责管理这个循环,最终执行仍然靠 Function Calling 或 MCP。
八、GUI 是曾经的竞争力,未来可能是阻碍
| GUI 时代 | AI 时代 | |
|---|---|---|
| 谁在操作软件 | 人 | 越来越多是 AI |
| 交互方式 | 眼睛看、手点击 | 文字/语言指令 |
| GUI 的价值 | 降低人的使用门槛 | 反而成为 AI 的障碍 |
人需要 GUI,但 AI 不需要。
用户要的从来不是"使用 Photoshop",而是图像处理的结果。当 AI 可以直接调用代码/API 完成任务时,Photoshop 可能根本不会出现在链条里。
GUI 是为人看不懂代码而生的。 AI 时代,代码/协议才是第一公民, GUI 正在从入口退化为可选的展示层。
笔记生成时间:2026年5月