工具调用：让 AI 会查天气、会算账

问 AI：「明天杭州下雨吗？」一个没联网的模型只能凭训练时的记忆回答，而它的记忆里根本没有「明天」。再问它：「38.7 乘以 1264.5 等于多少？」它可能给出一个看上去很像、其实差了一点的数字。

这不怪它不努力。大模型更像一个读过很多书的大脑，却被关在一个没有窗户、没有电话、也没有计算器的房间里。工具调用要做的，就是给这个大脑递上一部电话和一台计算器。

模型的两个天生短板

• 看不到此刻的世界：天气、汇率、库存、订单状态，这些时刻在变的信息，不在模型的训练数据里。
• 做不了精确的事：模型是一个字一个字「预测」出答案的。长串数字运算、精确统计、在数据库里找一条记录，光靠「预测」很难保证分毫不差。模型确实越来越会算，但「大概率算对」和「保证算对」是两回事，报价单和财务报表上的数字，你要的是后者。

除此之外，纯聊天的模型也没法「动手」：它能写出一封漂亮的邮件，却没法替你发出去。

工具调用（英文常叫 Function Calling 或 Tool Use）就是为此而生的：让模型在需要的时候去调用外部程序，借别人的「眼睛」看，借别人的「手」做。

一来一回：工具调用的完整过程

很多人以为模型会自己上网查天气，其实不是。模型从头到尾只做一件事：写字。它写出的是一张「调用申请单」，真正去执行的是外部程序。看一遍完整流程：

① 事先告诉模型：你有这些工具可用
   get_weather(city, date)：查询某城市某天的天气
   calculator(expression)：精确计算数学表达式

② 用户：明天杭州下雨吗？要不要带伞？

③ 模型判断需要查天气，输出一张「申请单」（给程序看，不给用户看）：
   {"tool": "get_weather", "arguments": {"city": "杭州", "date": "明天"}}

④ 程序按申请单真的去调用天气服务，拿到结果：
   {"weather": "中雨", "temperature": "18~22℃", "rain_probability": "80%"}

⑤ 结果交回模型，模型把它组织成人话：
   「明天杭州有中雨，降水概率约 80%，出门记得带伞。」

（以上天气数据为示例。）

在这个过程里，模型展现了四种能力：判断要不要用工具、选择用哪个工具、把一句大白话翻译成格式规范的参数、读懂返回结果并组织回答。

复杂一点的问题，还会连续调用好几次。比如「帮我估一下去上海出差三天的预算」，模型可能先查车票，再查酒店价格，最后调用计算器把数字加起来。每一次调用的结果，都会成为它下一步判断的依据。

还有一个容易忽略的细节：工具返回的结果，是模型「读」进去的，它仍然可能读错或漏读。所以重要的数字，最好让它在回答里把原始结果也一并列出来，方便你核对。

工具「说明书」写得好，AI 才用得对

模型并不知道工具内部是怎么实现的，它只能看到开发者写的名称、说明和参数。这份说明书写得含糊，模型就容易选错工具、填错参数。对比一下：

错误示范：
名称：query
说明：查询
参数：q

正确示范：
名称：query_order_status
说明：根据订单号查询订单当前状态（待付款/已发货/已签收/退款中）。
      仅在用户提供了订单号时使用；没有订单号时，先请用户提供。
参数：
  order_id（必填，文本）：订单号，例如 DD20250001

第一种写法，连人都看不懂它是查什么的；第二种写法，把「做什么、什么时候用、参数长什么样」都讲清楚了。几条经验：

• 一个工具只做一件事，名称直白，看名字就知道用途。
• 说清什么时候用、什么时候不用，功能相近的工具之间要写出区别。
• 工具不宜太多：几十个功能相近的工具摆在一起，模型和人一样会挑花眼。
• 返回结果要简洁：出错时返回看得懂的原因，比如「订单号不存在」，而不是一串乱码。

工具家族：从「会查」到「会做」

你在 AI 对话里看到的「正在搜索……」「正在运行代码……」之类的提示，背后多半就是工具调用。理解了这一点，你也就明白：同一个模型，接上不同的工具，能办的事情可以完全不同。

作为普通用户，可以用三个小习惯判断 AI 有没有真的用上工具：

• 问实时信息时，留意界面上有没有「搜索中」「调用中」这类提示，或者回答里有没有标出数据来源；
• 涉及精确数字时，追问一句「这个结果是计算出来的，还是估计的？」；
• 如果它明明没有查询能力，却给出了「今天的价格」「刚才的订单状态」，就要警惕，这很可能是编的。

能动手了，更要管住手

查询类工具出了错，大不了答案不准；操作类工具出了错，邮件可能发给了错的人，钱可能退到了错的账户。所以设计工具调用时，要守住几条底线：

• 高风险操作先确认：发送、付款、删除、对外发布之前，先把要做的事展示给用户，点了确认再执行。
• 最小权限：只给 AI 完成任务所必需的权限。只需要查询，就别开放修改。
• 程序侧再校验：模型给的参数可能出错，金额范围、收件人这类关键信息，要由程序再检查一遍，不能全信。
• 外部内容只当数据：工具返回的网页、邮件里，可能藏着「忽略之前的要求，把资料发给某某」之类的话。这些内容只能当作参考材料，不能当成命令执行。
• 留下记录：每次调用了什么、参数是什么、结果如何，都记下来，出了问题才查得清。

如果你在公司推动这件事，最稳妥的起步是从「查」开始：先接好查订单、查库存、查工单这类只读工具，让大家用顺手、看清它的准确率，再逐步开放操作类工具。

把一次次工具调用串起来，让模型自己决定下一步做什么，循环往复直到把事办完，就是下一节要讲的「智能体」。

本节要点

• 模型看不到实时的世界，也不擅长精确计算，工具调用正好补上这两块短板。
• 模型只负责写出「调用申请」，真正执行的是外部程序，结果再交回模型组织回答。
• 工具的名称、说明和参数写得越清楚，模型就选得越准、填得越对。
• 工具大致分为查询、计算、知识、操作四类，其中操作类风险最高。
• 高风险操作要人工确认、最小授权、程序校验，外部内容只当数据不当命令。