什么是工具调用（Tool Use）？
工具调用（Tool Use）指语言模型自行决定调用哪些外部 API、何时调用、传什么参数，并把返回结果并入后续的 token 预测。arXiv 论文 Toolformer 提出用自监督方式让模型学会这一能力，接入计算器、问答系统、搜索引擎、翻译系统与日历等工具，在不牺牲核心语言建模能力的前提下提升零样本表现。
工具调用（Tool Use）指语言模型在生成文本的过程中，自行判断是否需要借助外部程序或服务，并决定调用哪一个接口、在什么位置调用、传入什么参数，以及如何把返回结果并入后续的 token 预测。它要解决的问题是：语言模型虽然能从少量示例或文本指令中完成新任务，却在算术、事实查询这类基础功能上表现不佳，而这些恰恰是更简单、更小的模型所擅长的。工具调用试图让模型把这类工作交给外部工具，从而兼顾语言能力与精确计算、检索能力。
为什么重要
在工具调用这一思路被系统提出之前，语言模型处理算术或事实查询的方式，基本依赖参数中存储的知识与模式补全。论文指出，语言模型在规模扩大后展现出从少量示例或文本指令中解决新任务的能力，但同时也存在一个看似矛盾的现象：它们在算术或事实查询等基础功能上表现吃力，而远比它们简单、小巧的模型却能在这些任务上做得更好。
这种落差的根源在于任务性质不同。语言建模的目标是预测下一个 token，模型学到的是文本分布，而不是可靠的数值运算过程或可核验的事实来源。当问题需要精确计算或需要查询训练数据之外的信息时，仅靠参数内的统计规律容易出错，且错误难以被模型自身察觉。若把这类请求交给计算器、问答系统或搜索引擎，模型只需负责理解问题、组织调用、解读结果，就能绕开自身不擅长的环节。
因此，工具调用的价值不在于让模型变得更大，而在于让模型学会在合适的时机把任务外包出去。论文称，这种方式可以让模型兼得两者的长处：既保留语言理解与生成能力，又获得外部工具在特定功能上的可靠性。
工作机制
论文提出的 Toolformer 是一个被训练来决定 API 调用行为的模型。按照论文的描述，它需要学会四件事：调用哪些 API、何时调用、传入什么参数，以及如何最好地把结果并入未来的 token 预测。其训练方式为自监督，对每个 API 只需要少量示例演示，而不需要人工为每条语料标注调用位置。
可以把这一过程拆成几个要点来理解：
- 候选调用位置的生成。模型在文本中试探性地插入可能调用某个 API 的位置，并写出候选参数。这一步决定了「何时调用」与「传什么参数」的候选集合。
- 执行与结果获取。候选调用被真正送到对应的 API 上执行，取回返回结果。这一步让模型看到外部工具的真实输出，而不是自己臆测的内容。
- 结果是否有用的筛选。论文的核心做法是自监督：只有当把 API 返回结果加入上下文后，模型对后续 token 的预测损失相比不加结果时有所下降，这次调用才被认为是有帮助的，才会被保留为训练样本。也就是说，判断标准不是调用本身看起来是否合理，而是它是否真的让模型更容易预测接下来的文本。
- 训练数据的组装与微调。经过筛选的调用被保留在文本中，形成带有 API 调用标注的训练语料，模型在此基础上学习在生成时自主决定是否发起调用。
这一机制的关键在于筛选环节。它把「调用是否有用」转化为一个可用语言建模目标衡量的量，从而避免了对每一步调用进行人工标注。论文强调，整个过程是自监督的，每个 API 只需要少量演示。
典型例子
论文中纳入的工具范围包括：一个计算器、一个问答系统、两个不同的搜索引擎、一个翻译系统，以及一个日历。这些工具覆盖了语言模型相对薄弱的几类功能：数值计算、事实查询、信息检索、跨语言转换与时间相关查询。
论文报告的结果是，Toolformer 在多种下游任务上取得了显著提升的零样本（zero-shot）表现，往往能与规模大得多的模型相竞争，同时没有牺牲其核心的语言建模能力。这里需要明确的是，这些结论来自该论文自身的实验与表述，属于该研究提出的主张，而非已被普遍验证的行业共识。
从任务类型上看，这些例子也说明了工具调用的适用面：当问题涉及精确算术时，计算器承担运算；当问题涉及模型参数中未必包含的事实或时效性信息时，问答系统与搜索引擎承担检索；当问题涉及语言转换时，翻译系统承担转换；当问题涉及日期与时间安排时，日历承担查询。模型自身则负责判断该不该调用、调用哪一个、参数怎么写，以及如何把结果自然地接回文本。
边界与常见误解
首先需要区分「工具调用」与「模型自己知道答案」。工具调用的前提是承认模型在某些功能上不可靠，并把可靠性寄托在外部组件上。因此，工具本身的质量、可用性与返回格式会直接影响最终效果；如果 API 返回错误或不可用，模型并不能自动纠正。
其次，工具调用不等于让模型无条件地频繁调用。论文的筛选机制表明，只有那些确实降低了后续 token 预测损失的调用才会被保留。这暗示了一个边界：对模型本来就能很好预测的文本，插入调用并不会带来收益，反而可能增加开销。调用是有代价的，包括额外的执行时间与外部依赖。
第三，容易把论文的结论过度推广。论文报告的是在特定工具集合与特定评测设置下，零样本表现得到提升、且核心语言建模能力未被牺牲。这并不等于任意模型、任意工具、任意任务上都能获得同样收益，也不等于工具调用可以替代模型自身的能力建设。论文的表述是「往往能与大得多的模型相竞争」，这是一个有条件的比较，而非普遍结论。
第四，自监督筛选依赖「预测损失下降」这一信号，它衡量的是调用对语言建模的帮助，而不是调用在语义上是否正确、是否符合用户意图。二者并不总是重合。因此，把工具调用直接等同于「模型会正确使用工具」是一种误解。
最后，工具调用涉及对外部服务的实际请求，参数由模型生成，这意味着调用内容可能包含上下文中的信息。论文本身聚焦于方法与效果，未对部署层面的数据流向作出规定；在实际系统中，这一环节需要单独考虑。