本章包含6个知识点，围绕一个统一案例"出差准备"层层展开：
假设你对AI说：
"我明天要去北京出差，帮我准备一下。"
两年前的AI只能这样回答：
"好的，出差前您需要注意以下几点：1. 提前查看天气预报… 2. 预订机票… 3. 准备好身份证…"
这只是一篇"出差攻略"——AI在给你建议，但什么都没帮你做。
今天的AI可以这样：
"好的，我来帮您准备：
- 已查询：明天是3月9日（周日）
- 已查询：北京明天多云，8-15℃，建议带外套
- 已搜索：明天从上海到北京的航班，最早7:30，最便宜￥680
需要我帮您预订航班吗？"
这就是AI最重要的一次进化：从"给建议"到"帮你做"。
AI本身的能力其实没变——它依然只会"生成文字"。变化在于：AI学会了一种特殊的"文字"——工具调用指令。
以前，AI生成的是自然语言（给人看的）。现在，AI还能生成结构化的指令（给程序看的）。当AI需要查天气时，它不再"猜"一个答案，而是输出一条指令：
{"tool": "get_weather", "city": "北京", "date": "明天"}
后台程序收到这条指令，去真正调用天气服务，把真实数据返回给AI，AI再用自然语言告诉你结果。
AI从头到尾只做了一件事：生成文字。 只不过这次生成的不是一篇文章，而是一条"工具调用指令"。
想象你是一个老板，坐在办公室里不出门。你不会修电脑、不会做饭、不会开车——但你会写工单。
AI就是这个"老板"。它不会做任何事，但它会写精准的工单，让专业的系统去执行。
这种"写工单"的能力，技术上叫做 Function Calling（函数调用），也常被简称为工具调用（Tool Use）。2023年7月，OpenAI首次在GPT模型中引入了这个能力，随后Claude、Gemini、DeepSeek等主流模型纷纷跟进。
你说："我明天要去北京出差，帮我准备一下。"
AI理解到：要准备出差，需要知道具体日期、目的地天气、以及可选的航班。于是AI决定分三步调用工具。
AI不是自己去查，而是输出一条条"指令"：
指令一：查日期（调用系统工具）
{"tool": "get_date"}
→ 系统返回："2026-03-09"
指令二：查天气（调用外部天气服务）
{"tool": "get_weather", "city": "北京", "date": "2026-03-09"}
→ 天气服务返回："多云，8-15℃，东北风3级"
指令三：搜航班（调用航班预订系统）
{"tool": "search_flights", "from": "上海", "to": "北京", "date": "2026-03-09"}
→ 航班系统返回：[{航班: "CA1234", 时间: "07:30", 价格: 680}, ...]
注意AI输出的格式——这不是给你看的自然语言，而是给程序看的结构化指令（JSON格式）。程序能精确地解析出"调用哪个工具"和"传什么参数"。
AI拿到所有真实数据后，用自然语言组织成回答：
"明天是3月9日，北京天气多云，8-15℃，建议带外套。最早的航班是CA1234，7:30出发，￥680。需要帮您预订吗？"
整个过程中有三个角色：
| 角色 | 做了什么 | 类比 |
|---|---|---|
| 你（用户） | 说出需求 | 客户 |
| AI | 分析需求 → 写工单 → 整合结果 | 老板 |
| 后台系统 | 收到工单 → 执行操作 → 返回结果 | 员工 |
AI从不直接执行任何操作。 查天气的是天气服务，搜航班的是航班系统，AI只是写了"工单"（调用指令），然后把"回执"（返回结果）翻译成你能懂的话。
"AI帮我查了天气"——其实AI没查。
AI只是输出了 {"tool": "get_weather", "city": "北京"} 这行指令。真正调用天气接口的是后台程序。AI就像一个只会写便签的人——它写了"查北京天气"这张便签，有人拿着便签去做了，然后把结果带回来。
理解这个"决策与执行分离"的设计非常重要——它解释了为什么AI能"做这么多事"（它只是在写不同的工单），也解释了为什么AI偶尔"做错事"（工单写错了，但执行本身是准确的）。
| 类别 | 举例 | 说明 | 出差例子 |
|---|---|---|---|
| 系统工具 | get_date、get_time | 读取电脑本地信息，不需联网 | 查日期 ✓ |
| 信息查询 | get_weather、search_web | 连接外部服务获取实时数据 | 查天气 ✓ |
| 文件操作 | read_file、write_file | 读写你电脑上的文件 | — |
| 代码执行 | run_command、run_python | 执行代码和终端命令 | — |
| 通讯操作 | send_email、send_message | 发送邮件、消息 | — |
| 业务操作 | search_flights、create_order | 连接特定业务系统 | 搜航班 ✓ |
出差准备涉及的三个工具，恰好覆盖了不同复杂度：
get_date（系统工具） → 最简单，读本地信息，不需联网 get_weather（信息查询） → 需要联网，调用天气API search_flights（业务操作） → 最复杂，需要连接航班系统，涉及认证和权限
工具越复杂，需要的"连接工作"就越多。当工具多了、AI平台也多了，一个新问题就出现了——
出差例子中的 get_weather 看起来很简单，但背后有个大问题：
如果你用的是ChatGPT，天气工具是ChatGPT团队开发的插件。换成Claude？这个插件用不了——因为ChatGPT和Claude的工具接口完全不同。天气工具的开发者如果想同时支持两个平台，就得写两套代码。
假设市场上有10个AI平台，100个工具：
10 × 100 = 1000套适配代码 —— 这太疯狂了。
MCP（Model Context Protocol，模型上下文协议） 是Anthropic在2024年11月发布的开放标准，目标很简单：让每个工具只开发一次，所有AI平台都能用。
有了MCP：每个AI平台实现1个MCP客户端，每个工具实现1个MCP服务器。
10 + 100 = 110套代码 —— 从乘法变成加法。
以前的手机充电线各不相同——iPhone用Lightning，安卓用Micro USB，华为用Type-C，出门要带一堆线。现在有了USB-C统一标准，一根线给所有设备充电。
MCP就是AI工具世界的USB-C。 有了它：开发者做一个"USB-C接口"的工具，所有支持MCP的AI平台都能直接使用。
没有MCP时，天气工具要适配每个AI平台：
天气工具 ──适配──→ ChatGPT ✗ 代码不同 天气工具 ──适配──→ Claude ✗ 代码不同 天气工具 ──适配──→ Gemini ✗ 代码不同 （每个平台都要写不同的适配代码）
有了MCP，天气工具只需开发一个"MCP天气服务器"：
MCP天气服务器（开发一次） │ ├── ChatGPT → 能用 ✓ ├── Claude → 能用 ✓ ├── Gemini → 能用 ✓ └── DeepSeek → 能用 ✓
航班搜索、邮件发送……所有工具都一样。开发一次，到处可用。
MCP发布后获得了行业快速跟进：
| 时间 | 里程碑 |
|---|---|
| 2024年11月 | Anthropic发布MCP协议 |
| 2025年3月 | OpenAI宣布支持MCP |
| 2025年4月 | 支付宝、百度地图、高德地图等国内厂商接入MCP |
| 至今 | 社区已有数千个MCP服务器，覆盖天气、地图、支付、文件管理等各类场景 |
MCP的野心甚至更大——Anthropic的目标是让它成为AI领域的"HTTP协议"。就像HTTP让所有浏览器都能访问所有网站，MCP要让所有AI都能使用所有工具。
┌───────────────────────────────────────────────┐
│ 第四层：Skills（用户自定义快捷指令） │ ← 你能直接用
│ 例：/出差准备 北京 明天 │
├───────────────────────────────────────────────┤
│ 第三层：产品化集成（开箱即用的工具） │ ← 产品替你封装好的
│ 例：Claude Code内置工具、ChatGPT插件 │
├───────────────────────────────────────────────┤
│ 第二层：MCP（统一标准） │ ← 开发者关心的
│ 让所有工具用同一种接口 │
├───────────────────────────────────────────────┤
│ 第一层：Function Calling（底层机制） │ ← AI模型的核心能力
│ AI输出 {"tool": "get_weather"} 这类指令 │
└───────────────────────────────────────────────┘
这是最底层。AI输出一条条JSON指令：
{"tool": "get_date"}
{"tool": "get_weather", "city": "北京", "date": "2026-03-09"}
{"tool": "search_flights", "from": "上海", "to": "北京", "date": "2026-03-09"}
这是AI模型本身的能力——理解你的需求，然后写出精确的调用指令。你在8.2已经看过了。
你通常看不到这一层，但它在背后工作。MCP确保天气服务、航班服务以统一的接口提供给AI平台。无论底层是GPT、Claude还是其他模型，工具的接入方式都一样。你在8.4已经了解了它的作用。
这是你在Claude Code、ChatGPT等产品中直接体验到的。你不需要自己去找天气MCP服务器、自己配置接口——产品已经帮你集成好了。你只需要说"查一下北京天气"，AI就能调用工具。
Claude Code就是一个极好的例子：它内置了文件读写、代码执行、终端命令、Git操作等几十种工具，你不需要做任何配置就能使用。在后续的第十一、十二课中，你会亲手体验这些工具。
如果你发现自己经常让AI"准备出差"，每次都要说一遍需求，那可以把整个流程封装成一个 Skill（技能/快捷指令）。
在Claude Code中，Skills就像一键快捷方式：
你输入：/出差准备 北京 明天 AI自动执行： 1. 查询日期 ✓ 2. 查询目的地天气 ✓ 3. 搜索航班信息 ✓ 4. 整理成出差准备报告 ✓
一条指令，完成了原本需要多轮对话才能做完的工作。Skills的具体配置方法会在第十二课详细介绍。
越往上层，用户越轻松，但灵活性越低；越往下层，越灵活，但需要越多技术知识。
| 层级 | 谁在用 | 体验 |
|---|---|---|
| Skills | 普通用户 | 一键执行，最简单 |
| 产品集成 | 普通用户 | 说需求就行，不用配置 |
| MCP | 开发者 | 需要了解接口标准 |
| Function Calling | AI模型厂商 | 需要深入技术实现 |
对大多数人来说，只需要关心上面两层就够了。但理解下面两层，能让你更清楚AI工具的能力边界——知道它能做什么、做不了什么、为什么偶尔会出错。
在课程前面的章节里，我们讨论了AI的多种能力：
| 能力 | 章节 | 比喻 |
|---|---|---|
| 语言能力 | 第4-5课 | AI是个"语言天才"，能理解和生成文字 |
| 知识能力 | 第9课 | AI是本"百科全书"，能检索和整合信息 |
| 工具调用 | 本课 | AI是个"有手有脚的助手"，能执行操作 |
工具调用是最关键的一步——它让AI从"知识库"变成了"执行者"。有了它，AI不再只是一本能对话的百科全书，而是一个能查数据、写文件、发邮件、执行代码的"数字员工"。
这就是我们在第五、六课讲的 AI Agent 能"干活"的核心机制。
AI能读文件、写文件、执行代码——这些能力如果失控，后果很严重。所以现代AI工具都设计了权限控制：
这也是工具调用采用"决策与执行分离"设计的好处——AI只是写"工单"，最终是否执行、怎么执行，由系统和人来控制。
| 概念 | 一句话总结 |
|---|---|
| 工具调用 | AI不直接做事，它只"写工单"——输出指令让后台系统执行 |
| Function Calling | AI输出结构化调用指令的底层机制，是一切工具调用的基础 |
| MCP | AI工具的"USB-C标准"，让工具开发一次、所有AI平台都能用 |
| 层层封装 | Function Calling → MCP → 产品集成 → Skills，越上层越易用 |
核心认知：AI本身只会"生成文字"。工具调用的秘密在于，AI生成的不是给你看的文章，而是给程序执行的指令。理解了这一点，你就理解了AI Agent"能干活"的全部秘密。
你的"出差准备"：除了查天气和搜航班，如果你真的要准备一次出差，还希望AI帮你做什么？试着列出3-5个工具调用，并标注每个属于哪个类别（系统工具、信息查询、文件操作、通讯操作、业务操作）。
MCP的意义：如果MCP不存在，AI工具生态会变成什么样？对使用AI工具的普通用户来说，最直接的影响是什么？
打开你常用的AI产品（如ChatGPT、Claude），分别问它两个问题："今天北京天气怎么样？"和"帮我写一首关于春天的诗"。对比两次回答——哪次AI调用了工具获取真实数据？哪次纯粹依靠自己的语言能力？你是怎么判断的？