AI为何突然具备行动能力？工具调用背后的关键突破

AI 进化的因果链 · 06

核心转变并非 AI 表达更流畅，而是其输出开始与现实世界产生连接

工具调用如何将一句日常话语，转化为可验证、可拦截、可落实的具体操作。

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

你对 AI 说：“查一下北京明天气温，要是低于 20℃ 就提醒我带件外套。”

几秒后，它给出天气预报，并新建了一条提醒事项。

这一刻容易造成误解：屏幕中的模型刚刚查询了天气、打开了日历、输入了文字，最终完成了保存。

事实上，它没有亲手完成任何一步。

模型真正做的事情是：把你的语言转化成了一张结构化的“任务工单”。应用解析工单，核对权限，调用天气和日历接口，再将反馈传回模型。

AI 看似突然“能做事”，关键并非它长出了虚拟的双手，而是它终于获得了一套对接外部世界的可控通道。

先别往下滑：究竟是谁发出了邮件？

A．语言模型；B．接入邮箱的应用程序；C．邮件正文。

答案是 B。模型可以发出“发送”指令，但只有获得授权的应用程序才能真正把邮件投递出去。

没有工具时，语言模型的活动范围基本局限于对话框。

它能写出一封措辞讲究的邮件，却不知道你的联系人是谁；能依据常识谈论天气，却无法获取实时气象数据；能生成一段 Python 代码，却不能直接在你的电脑上运行。

这不代表模型“完全不会计算”或“只会胡扯”。它能从训练数据中习得许多计算与推理规律，但生成一个答案，与调用一个确定的计算器、数据库或业务系统，是两件不同的事。前者可能出错，后者能返回可核验的实时结果。

工具调用所做的，就是把这两层区分开来：

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

一个工具通常需要先向模型提供一份说明文档，至少明确三件事：

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

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

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

2023 年 6 月，OpenAI 在 API 中推出 Function Calling，核心价值在于让模型更稳定地输出函数名称和参数，将自然语言与外部工具衔接起来。后来出现的 Structured Outputs 又进一步约束输出符合开发者给定的 JSON Schema。

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

把刚才的提醒流程拆开，会看到一个并不玄妙、但非常关键的循环：

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

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

轮到你选工具

“找出下周三下午的空闲时段，并起草一封会议邀请。”至少需要哪些能力？

参考答案：读取日历 + 生成邮件草稿。若用户只说“起草”，就不应擅自发送。

工具不局限于 API。

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

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

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

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

说错一句话，与转错一笔钱，不是同一个风险层级。

工具越强大，权限设计越不能马虎。可以把常见操作分成三档：

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

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

安全判断题

读取天气、创建邮件草稿、发送邮件、永久删除文件，哪些应该在执行前再次确认？

至少包括发送邮件和永久删除。创建草稿通常可逆，但仍应限制收件箱、文件夹和内容范围。

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

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

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

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

这正是下一篇要探讨的问题：当 AI 的工具越来越多，我们能不能给它们一套通用的插座？

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

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

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

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

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

互动专栏｜你最想把哪件事交给 AI？

A．整理资料；B．处理邮件；C．分析表格；D．操作重复的办公流程。

欢迎在评论区留下选项，也说说你最担心它在哪一步出错。下一篇会用这些场景解释 MCP。

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

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