AI为什么突然会干活了?工具调用的关键一跃

预计阅读 10 分钟　·　无代码门槛　·　系列第 6 篇

你对 AI 说：“看看北京明天冷不冷，低于 20℃ 就提醒我带外套。”

几秒后，它报出天气，还创建了一条提醒。

这个瞬间很容易让人产生错觉：屏幕里的模型刚刚查了天气、打开日历、敲下文字，最后按了保存。

其实，它一件都没有亲手做。

模型真正完成的是另一件事：它把你的话翻译成了一张结构化的“办事申请单”。 应用读懂申请单，检查权限，调用天气和日历服务，再把结果送回模型。

AI 看起来突然“会干活”，关键不在于它长出了一双虚拟的手，而在于它终于拥有了一套连接外部世界的受控接口。

01｜模型负责提议，应用负责动手

没有工具时，语言模型的世界基本停在对话框里。

它可以写一封措辞得体的邮件，却不知道你的联系人是谁；可以根据常识聊聊天气，却拿不到此刻的气象数据；可以给出一段 Python 代码，却不能天然在你的电脑上运行它。

这并不意味着模型“完全不会计算”或“只会骗人”。它能从训练中学到不少计算和推理模式，只是生成一个答案，与调用一个确定的计算器、数据库或业务系统，不是同一件事。前者可能出错，后者可以返回可核验的实时结果。

工具调用做的，就是把这两层拆开：

• • 模型层： 理解你想做什么，选择合适工具，给出参数；
• • 应用层： 校验参数和权限，决定是否执行，把结果返回；
• • 用户层： 对发送、付款、删除等重要动作作最终确认。

这条边界非常重要。以后看到“AI 帮你发了邮件”，更准确的理解是：模型提出了调用邮件工具的请求，宿主应用在获得授权后执行了它。

02｜所谓 Function Calling，就是让模型会填“办事单”

一个工具通常要先给模型一份说明书，至少写清三件事：

1. 1. 名字： 它叫什么，例如 get_weather；
2. 2. 用途： 什么情况下应该用它；
3. 3. 参数： 调用它必须提供哪些信息，例如城市和日期。

当用户说“明天下午去杭州，提醒我带伞”，模型可能先生成这样的请求：

工具：get_weather参数：城市=杭州，日期=明天

注意，这仍然只是一段结构化输出。它既没有偷偷访问天气网站，也没有自己执行某个函数。应用拿到请求后，可以拒绝、修正、补问，也可以真正调用天气 API。

2023 年 6 月，OpenAI 在 API 中推出 Function Calling，重要意义正是让模型更可靠地输出函数名称和参数，把自然语言与外部工具接在一起。后来出现的 Structured Outputs 又进一步约束输出符合开发者给定的 JSON Schema。

但“格式正确”不等于“内容一定正确”。模型可能把杭州识别成湖州，也可能选错日期。所以参数仍然要校验，关键动作仍然要确认。

03｜一次真正的工具调用，中间发生了什么？

把刚才的提醒拆开，会看到一个并不神秘、但很关键的循环：

1. 1. 用户提出目标，而不是手把手指定每一步；
2. 2. 模型判断需要天气工具，并生成城市、日期等参数；
3. 3. 应用检查参数是否完整、工具是否允许调用；
4. 4. 天气服务执行查询，把温度和降雨概率返回；
5. 5. 模型结合结果，判断是否需要创建提醒；
6. 6. 在用户授权范围内，应用写入日历并回传状态；
7. 7. 模型最后用自然语言告诉你发生了什么。

这里最容易被忽略的是第三步。模型说“我要调用”，系统不必立刻照做。成熟的产品会在中间加入参数验证、权限检查、频率限制，必要时弹出确认。

所谓“模型暂停等待工具”，更准确地说，是应用编排了多轮交互：模型先返回工具请求，应用执行后把结果作为新上下文再发给模型。暂停和继续，不是模型在后台默默工作，而是程序把这个循环接了起来。

04｜从调用函数，到操作一整台电脑

工具不只有 API。

计算器适合精确运算，搜索工具适合取回新信息，代码执行环境适合分析数据，数据库工具适合读取业务记录。到了 Computer Use，模型还可以根据屏幕截图提出点击、输入和滚动等动作，由程序操作图形界面。

这条路线解决的是不同入口的问题：

• • 有稳定 API 的系统，直接调用通常更快、更可靠；
• • 需要计算和反复试验的任务，适合沙箱代码环境；
• • 没有 API 的旧软件，界面操作可能是一条补充通道。

它们不是一代淘汰一代，也没有客观的“最高级形态”。能直接调用天气接口时，让模型在网页上找按钮，反而更慢、更脆弱；而面对只有网页界面的内部老系统，Computer Use 又可能很实用。

真正的变化是：模型不再被要求把所有问题都“回答”出来。它可以把计算交给计算器，把查询交给数据库，把动作交给受控的执行环境，自己专注于理解目标、选择路径和整理结果。

05｜AI 能动手之后，更重要的是学会踩刹车

只会说错一句话，和转错一笔钱，不是同一个风险等级。

工具越强，权限设计越不能含糊。可以把常见动作分成三档：

• • 只读动作： 查天气、读日历、搜索资料，风险通常较低；
• • 可逆写入： 创建草稿、修改文档、添加日程，需要明确范围并保留撤销；
• • 高风险动作： 发送消息、公开发布、付款、删除数据，应在执行点再次确认。

除此之外，还有四条很朴素但很有效的护栏：

1. 1. 最小权限： 只开放完成当前任务所需的工具和数据；
2. 2. 参数校验： 不因为 JSON 长得规整，就直接相信里面的收件人、金额和路径；
3. 3. 可追溯： 记录谁在何时请求了什么、系统实际执行了什么；
4. 4. 防止重复： 超时重试时避免同一封邮件发两次、同一笔订单下两遍。

还要警惕一种更隐蔽的风险：工具返回的网页、文档或邮件里，可能混有诱导模型执行额外动作的文字。外部内容应该被当作“不可信输入”，不能因为它出现在搜索结果里，就获得指挥其他工具的权力。

06｜会调用工具，为什么还不等于“全能代理”？

给模型多装几个工具，并不会自动得到一个可靠的数字员工。

工具说明可能写得含糊，模型可能选错工具，外部服务会超时，权限会过期，返回数据也可能互相矛盾。真正稳定的系统还需要任务规划、状态管理、错误恢复、评估和人工接管。

所以，Function Calling 更像是一块关键积木，而不是整栋楼。

它解决了“模型怎样提出一个机器可读的动作请求”，却没有自动解决“工具从哪里发现、怎样认证、不同应用如何复用、上下文如何交换”。过去，接十个系统往往要写十套胶水代码；换一个模型平台，还可能重新适配一遍。

这正是下一篇要追问的事：当 AI 的工具越来越多，我们能不能给它们一套共同的插座？

一分钟复盘

记住下面四句话，就抓住了工具调用的骨架：

1. 1. 模型通常提出调用，宿主应用才是实际执行者；
2. 2. 工具说明让模型知道“什么时候用、需要哪些参数”；
3. 3. 工具结果会回到上下文，模型据此继续判断或回答；
4. 4. 现实影响越大，越需要最小权限、校验、确认和日志。

写在最后

AI 从“能聊”走向“能办事”，靠的并不是某个神秘开关。

中间多了一层看似工程化、其实极其关键的翻译：把人的模糊意图，变成机器能检查的工具请求；再由有权限的程序，把请求变成现实动作。

这也是理解今天各类 AI 助手最有用的一把钥匙。下次它说“已经帮你完成”，别只看结果，多问一句：用了什么工具？执行前检查了什么？出错后能不能撤回？

会回答，让 AI 显得聪明；会在边界内行动，才让它真正有用。

下一章预告：《MCP 是什么？为什么 AI 工具都在寻找同一种“插座”》

资料校对：OpenAI Function Calling 发布说明、OpenAI Structured Outputs、Anthropic Computer Use 发布说明、Anthropic MCP 发布说明。