AI 是怎么“调用工具”的?用“脑和手”一个类比讲明白

你有没有想过：当你问 AI “明天北京天气怎么样”，它为什么以前答不上来，现在却能秒回？

结合下面的例子：

用 Deepseek 时，问同样的问题，为什么不开“智能搜索”，它就回答不了，开了之后，就能回答这个问题。

答案藏在一个叫 Function Calling（现在也常叫 Tool Calling，工具调用）的机制里。

一、先搞清两个角色：脑和手

很多人把“AI”当成一个整体，其实你用的每个 AI 产品里都藏着两个角色：

大模型（脑）：负责“想”。它本质上是个文本预测器——你给它一段文字，它预测“接下来最可能是什么字”。它只会吐文字，不会上网、不会算数、不会真的去干任何事。

AI 应用（手）：负责“做”。它是包在大模型外面的那层程序，负责把你的提问组装成提示词、调用模型、拿到结果、再显示给你。

关键点：模型自己永远碰不到真实世界。能联网、能查数据库、能下单的，是“手”（应用），不是“脑”（模型）。

模型只是个文本生成器，这带来两个表现：

1. 拿不到实时的数据：它训练完就“冻结”了，只知道当时训练时的那些数据，不知道明天的天气。

2. 做不了真实动作：它不能真的帮你发邮件、订机票。

Function Calling 就是中间的桥：让模型用一种固定格式“开口请求”，应用照着执行。注意——模型并没有因此获得新能力，它只是学会了一种“怎么跟应用提需求”的写法。

以“明天北京天气”为例，完整流程是：

1. 你在应用里输入问题，点击发送。

2. 应用把你的提问，连同一份工具清单一起喂给模型。清单里写明：有个 get_weather（获取天气）工具，调用时要两个参数（两类输入信息）——location（地点）和 date（日期）。

3. 模型读完，判断这个问题该用天气工具，于是输出一段结构化文本（就是“调用请求”）——这正是 Function Calling 的关键输出：

{    "name": "get_weather",     "arguments": {         "location": "北京",         "date": "明天"    }}

4. 应用解析这段请求，真正去调用天气 API，拿到结果（比如“晴，25°C”）。

5. 应用把结果拼回提示词，再丢给模型。

6. 模型把干巴巴的数据，组织成一句人话：“明天北京晴，气温 25 度，适合出门。”

7. 应用把答案显示给你。

“调用工具”的瞬间，是模型在写“申请单”；真正动手的，一直是应用。

讲完流程你可能会问：前面说模型自己并不会执行工具，那从“没有 Function Calling”到“有了它”，模型到底多出了什么本事？

答案可能和直觉相反：真正的难点，不在于应用去执行工具——那是普通代码，开发者写个函数就能做；真正的突破，在于模型被训练出了一种新能力。

回顾刚才的流程：应用拿到工具描述、再去调用真实方法，这部分并不稀奇。稀奇的是——当我们把上面那份工具清单交给大模型，它居然能：

1. 判断要不要调工具（这个问题用不用麻烦外部工具？）；

2. 挑出该用哪一个（查天气该调 get_weather，而不是 get_stock）；

3. 从你的话里抽出参数，并按工具描述的格式填好（就是那段 JSON 里的“北京”、“明天”）。

这三点，是靠对模型做监督微调练出来的，不是靠写几行提示词就能稳定搞定。一个没受过这种训练的模型，你硬让它输出 JSON，十次里有几次会瞎填或格式崩掉。

也就是说，Function Calling 给模型带来的能力提升，不是“它会调用工具”（它至今也不会亲手执行），而是“它能看着工具清单，听懂人话，点兵点将——知道用哪个工具、传什么参数，并且用标准格式吐出来”。

所谓“标准格式”，就是上面那段符合工具描述的结构化文本（JSON）。正是这个格式，让应用能稳稳解析、照着执行。回到脑和手的比喻：手（应用）本来就会干活；Function Calling 真正给脑（模型）新添的，是“看说明书点兵”的本事。

你点 Deepseek 的“智能搜索”时，背后就是 Function Calling：应用把 search 工具递给模型，模型决定要搜，应用真去搜网页，再把内容喂回模型总结。所谓“AI 会搜索了”，其实是“应用替它搜”。

大模型是军师（脑），只会出主意；AI 应用是执行者（手），替它办事。Function Calling，就是军师写便条、执行者照办的那套约定。