工具调用（Tool calling）

是什么

语言模型一次生成一个词元（token），答案里的算术、查证、换算，通常都得从自己的参数里挤出来。工具调用换了一条路：模型可以把一个子任务交给外部程序，比如计算器或搜索引擎，再把程序返回的结果用进回答里^[1]。干活的是程序，做决定的是模型——它判断什么时候需要动用工具、把需求写成程序能接受的形式、再把结果接回正在写的文字。

一次调用长什么样

调用不是另开一条通道，而是模型自己输出的文本，只是格式事先约定好：模型写下工具的名字和要传的参数，外层软件暂停生成、执行程序、把输出放回上下文，生成再带着这个结果继续往下写。问一句「3150 的 24% 是多少」，模型可以不猜，而是发出一次带上算式的计算器调用，拿到 756，再把数字写进句子。同样的形式也适用于发给搜索引擎的查询，或发给日历的日期。

另一种做法是把这类决定放在外层程序里：由一条固定的流程规定什么时候去检索、什么时候去计算。工具调用把决定权交给模型本身——这既是它吸引人的地方，也是它难以训练的地方。

从哪来

Schick 等人把这套想法写进论文 Toolformer，于 2023 年 2 月发表^[1]。出发点是：语言模型恰好在算术、事实查找这类基础功能上表现不佳，而一些更简单、更小的模型反而做得很好^[1]。所以论文给出的不是一份手写的规则表，而是一套训练办法：让模型自己学会调用哪些 API、什么时候调用、传什么参数，以及如何把结果融进后续的词元预测^[1]。训练是自监督的（self-supervised），除了每个 API 的少量示例之外，不需要人工标注^[1]。候选的 API 调用在构造训练数据时就被筛选出来，而不是运行的时候由外部规则临时决定^[1]。

论文用的工具集很平常：一个计算器、一个问答系统、两个不同的搜索引擎、一个翻译系统和一个日历^[1]。单拎出哪一个都不稀奇；关键在于，由模型而不是由流程来判断某个工具此刻值不值得用。

结果

训练后的模型在多种下游任务上零样本（zero-shot）表现明显提升，常常能与大得多的模型相比^[1]。零样本指的是这些任务并没有被专门训练过：模型只是带着自己的工具，以及关于何时该用工具的判断来到任务面前。这些提升还没有牺牲模型本身的语言建模能力^[1]——若用了计算器却把普通文本写差了，这笔账并不划算。

代价与局限

这套做法自带两项成本。候选 API 调用要在构造数据时挑选，每个工具还需要保留少量示例，因此开销随工具数量增长^[1]。工具集也是在构造训练数据时就定下来的：想再添一个计算器、第二个搜索引擎或一个日历，就得回到那一步重做^[1]。作为交换，模型把工具当成自己生成过程中的又一个可选项，并且学会了权衡这个选项，而不是照着脚本行事。