咱们这个系列，前几期聊了RAG，让AI学会了“先查资料再说话”，这确实解决了不少瞎编乱造的问题。但话说回来，会查资料终究还是停留在“动嘴”的层面。那搜完资料之后呢？现实世界里的活儿，光靠说话可干不完。今天我们聊的这个能力，才是真正让AI从“嘴炮王者”进化成“执行干将”的关键——工具调用。

一、AI为什么总像个“空想家”？

要理解这个问题，先得认清大语言模型的本质——它就是个顶级的文本生成器。你给它一段文字，它回你一段文字。仅此而已。它不会自己动手查天气、发邮件，更不可能去操作你的数据库。

咱们打个比方：你手底下有个助理，脑子灵光得很，上知天文下知地理。但可惜，手脚被绑在椅子上。他能告诉你“北京今天28度，大晴天”，但你让他帮你把空调打开、帮你下单外卖、帮你发个邮件？对不起，他做不到。他只能“说”，不能“做”。

而**工具调用（Tool Use，也叫Function Calling），就是给这位“嘴炮”助理松绑**。让他不仅能动嘴，还能“动手”。

需要澄清一个概念：AI本身依然不会直接去执行操作。它的真正价值在于，它能发出**结构化的指令**。它告诉你：”请帮我调用这个工具”，你的程序代码去执行这个指令，再把结果反馈给它。这更像一个优秀的项目经理——他自己不写代码，但他知道找谁、写什么、什么时候交付。真正干活的是工程师（你的程序），而AI负责全局调度。


二、工具调用的“四步循环法”

整个过程其实是一个循环，学术界给它起了个名字叫Agentic Loop。拆开来看，就那么几步：

**第一步：给AI一本“工具操作手册”**

你在向AI提问的时候，同时附上一份“工具箱清单”。这个清单上，每个工具都有名字、功能描述和参数格式。就好比你给一个新员工一本手册：“这个查天气的工具，需要传一个城市名；这个发邮件的工具，需要收件地址和邮件正文。”

**第二步：AI判断“该不该出手”**

AI拿到你的问题后，会先判断：这个事儿需不需要用工具？如果只是“你好”，那它直接文字回复就够了。如果问题涉及现实世界，比如“北京今天多少度”，它就会输出一个结构化的工具调用请求。

**第三步：你的程序去“干苦力”**

这是整个流程最关键的一环：**AI本身并不执行任何操作。** 它只输出一个JSON，告诉你：“我想调用get_weather这个工具，参数是城市名为‘北京’”。拿到这个JSON的是你的程序代码，由它去调用真正的天气API，获取结果。

**第四步：结果“回锅”，AI再“烹调”**

你的代码把拿到的结果（比如28度、晴天）拼回对话历史，再次发给AI。AI看到这个结果后，组织成自然语言回答你：“北京今天28度，晴天。” 如果AI觉得信息还不够（比如只查到北京，没查到上海），它会再次发起工具调用——这就是“循环”。直到它觉得所有的信息都凑齐了，才给出最终答案。


来看个完整例子：

你说：“帮我查查北京和上海的天气，然后推荐穿什么。”

1. AI立马输出指令：调用 `get_weather({city: "北京"})` 和 `get_weather({city: "上海"})` ← 注意，这里是**并行调用**。

2. 你的程序同时查两个城市，拿到结果。

3. 结果回传：北京 28°C 晴 / 上海 22°C 多云。

4. AI给出最终答复：“北京28度晴天，建议穿薄T恤；上海22度多云，建议带件薄外套。”

你只说了一句话，AI就自己做了两步：先决定查两个城市，再根据结果给出穿衣建议。这效率，比手把手教它怎么做要快得多。

三、效率的革命：从串行到并行

早期的工具调用是“串行”的，一次只能调一个工具，等结果回来再决定下一步，效率非常低下。到了2025-2026年，主流模型都支持了**并行工具调用**。这意味着，AI可以在同一轮响应中，一口气发出多个工具调用请求。

这个能力有多重要？咱们算笔账。假设你要查10个城市的天气。串行调用需要10轮对话（每轮算你2秒），总共20秒。并行调用呢？只需要1轮——AI同时发出10个调用，你的程序并行执行，2秒就给你结果了。这简直就是效率上的降维打击。根据2026年的研究数据，在搜索类Agent任务中，并行调用能带来**4倍的速度提升**。

目前，GPT-5系列、Claude Opus 4.7、Gemini 3系列、DeepSeek V4等主流模型都已经支持了这个能力。

四、巨头们的“工具箱”有何不同？

虽然OpenAI叫Function Calling，Anthropic叫Tool Use，Google也叫Function Calling，命名千奇百怪，但核心逻辑都是一样的。不过，实现细节上确实有些差异：

|维度|OpenAI|Anthropic(Claude)|Google(Gemini)| |:-:|:-:|:-:|:-:| |参数名|`tools` & `tool_choice`|`tools` & `tool_choice`|`tools` & `tool_config`| |并行调用|支持|支持|支持| |Strict模式|支持（保证100%格式合规）|支持|支持| |服务端工具|无|有（web_search、code_execution直接在服务器执行）|有（Google Search、代码执行）| |工具结果格式|`role: "tool"`|`role: "user"` & `tool_result`|`functionResponse`|

这里面有几个值得说道说道的地方：

**Claude的服务端工具是亮点。** 比如web_search、code_execution这类工具，你甚至不需要自己写代码去执行，Anthropic的服务器直接帮你跑完，结果自动返回。这省了开发者不少造轮子的功夫。

**OpenAI的Strict模式是保障。** 开启`strict: true`后，模型保证**100%按照你定义的Schema输出**，不会少字段，不会格式错。这对生产环境来说太关键了——没有这个保证，你的代码在解析工具调用结果时，随时可能因为一个格式错误而崩溃。

**跨平台迁移时得留个心眼。** OpenAI和DeepSeek的格式是兼容的，可以无缝切换。但Claude的工具结果回传格式大不相同，迁移时需要重点适配。

五、MCP：统一天下的“USB接口”

每家模型都有自己的格式，带来的后果就是：你为OpenAI写的工具定义，没法直接在Claude上用。在2024年之前，这绝对是个噩梦——每换一个模型，就得重写一套工具对接代码，维护成本高得吓人。

**转机出现在2024年11月，Anthropic发布了MCP（Model Context Protocol，模型上下文协议）**。你可以把它理解成给工具调用定义了一个“USB接口”——无论什么模型、什么工具，都用同一套标准来通信。设备插上就能用，这才是真正的生态。

MCP的发展速度堪称惊人：

|时间|里程碑| |:-:|:-:| |2024.11|MCP发布，首月下载量约10万| |2025.03|OpenAI全面拥抱MCP（在Agents SDK和ChatGPT桌面端中）| |2025.04|Google Gemini支持MCP；5个月内下载量突破800万| |2025.12|MCP被捐赠给Linux基金会下的AAIF，实现厂商中立治理| |2025.12|Python与TypeScript SDK月下载量合计达到9700万| |2026|75%的API网关厂商预计将添加MCP功能|

**MCP到底解决了什么问题？**

在没有MCP的时代，你给OpenAI写了一套工具定义，换成Claude要重写，换成Gemini又要重写。维护N份工具代码，升级一个接口要改N个地方。这简直就是开发者的噩梦。

有了MCP之后，你只需要写一份工具定义（MCP Server），所有支持MCP的模型都能直接调用——就像USB设备插到任何电脑上都能用一样。

MCP定义了四大核心能力：

- **Tools**：可调用的函数（查询数据库、调用API等） - **Resources**：数据源（文件、文档等） - **Prompts**：可复用的提示模板 - **Sampling**：让工具服务器反向调用模型 

六、会“动手”的AI，风险也大了

工具调用让AI能“动手”了，但这扇大门一旦打开，安全风险也随之而来。2025-2026年，最值得警惕的几个问题是：

**1. 提示注入：绕开你的安全护栏**

攻击者可以在网页、文档或API响应中嵌入恶意指令。AI读取这些内容后，可能会执行危险操作。比如，你的RAG系统检索到一篇被注入恶意指令的文档，AI照着文档里的指令，调用了“删除文件”的工具。这是2025年OWASP LLM Top 10排名第一的风险，出现在超过73%的生产AI部署中。现实中也已经出现了真实案例：GitHub Copilot的远程代码执行漏洞、微软的EchoLeak（CVSS评分高达9.3分）。

**2. 权限控制：给得少做不了，给得多要出事**

给AI的权限太少，它什么事都干不了；给太多权限，它一个误操作就可能酿成大错。目前的主流方案是“敏感操作需人类确认”，但如何定义“敏感”本身就是一个巨大的难题。

**3. 工具描述被“投毒”**

AI决定调用哪个工具，完全依赖于工具的描述（description字段）。如果有人篡改了工具的描述，就极有可能误导AI去调用不该调用的工具。

**安全建议（值得敲黑板）：**

- 工具执行必须在**沙箱**中运行，严格限制它能访问的资源。 - 敏感操作必须加上**人工审批**环节，这是最后的底线。 - 在不需要调用工具的场景下，使用 `tool_choice: "none"` 明确禁止调用。 - 工具返回的结果，必须经过**过滤和验证**，不能盲目信任任何外部返回的内容。

七、普通人怎么用好这个能力？

其实你可能已经在用了，只是没意识到它叫“工具调用”。

- **ChatGPT搜索**：你问问题，ChatGPT调用搜索工具去查互联网 → 这就是工具调用。 - **Cursor编程**：你让它改代码，它读取文件、修改文件、运行终端命令 → 全是工具调用。 - **Kimi长文档分析**：你上传PDF，它调用文件读取工具 → 工具调用。 - **Claude Artifacts**：你让它做个网页，它生成代码并在沙箱中预览 → 工具调用。

**如果你想自己动手开发，可以遵循这几步：**

1. 从OpenAI的Function Calling入手——文档最清晰，生态最成熟，好上手。 2. 工具定义的`description`是灵魂所在——要写清楚“什么时候该用、什么时候不该用、参数格式是什么”。 3. 生产环境下，一定要开启 `strict: true`，保证格式合规。 4. 工具出错时，不要把流程中断，而是把错误信息回传给AI，让它自己决定下一步怎么处理。 5. 当工具数量超过几十个时，果断用MCP来统一管理，别把所有工具定义都塞在上下文里，那会浪费宝贵的上下文空间。

八、一句话总结

>**工具调用让AI从“只会说话”进化成“会动手干活”——AI不直接执行操作，而是发出结构化指令，由你的代码来执行，结果再回传给AI。** 从单次调用到并行调用，从各家各自为战到MCP统一标准，工具调用正在成为AI与现实世界交互的核心枢纽。如果你的AI应用需要和真实世界交互，那工具调用就是你绕不过去的必修课。