这篇和现在的 tool calling 不太一样
现在说工具调用，大家很容易想到 function calling、ReAct、Agent loop。Toolformer 读起来不是这个方向。它更像是一个早期后训练思路：让模型从普通文本里自动挖出“哪里应该调用 API”，再用这些自动生成的数据微调模型。
所以它关心的不是运行时怎么调度工具，而是模型能不能通过自监督方式学会何时、如何、调用什么工具。
方法的核心
Toolformer 的流程可以拆成几步：
- 从普通文本中采样候选 API 调用；
- 执行这些 API，拿到工具返回；
- 判断工具返回是否真的帮助模型预测原文后续 token；
- 只保留有帮助的 API 调用样本；
- 把这些带 API 调用的文本混回训练数据中微调模型。
这里最聪明的地方是过滤标准。不是人手工标注“这个工具调用有用”，而是看工具结果是否降低语言模型预测后续文本的 loss。
比如文本里有一句“400 / 1400 约等于 29%”，模型在 29% 前面生成 Calculator(400 / 1400)。如果给它计算结果 0.29 后，预测 29% 的 loss 明显下降，这条调用就值得保留。
为什么这个思路有价值
这篇论文想解决两个问题。
第一，人工标注工具调用数据太贵，而且人认为有用的工具调用，不一定是模型真正需要的。第二，工具使用不应该只绑定到某个固定任务上。模型最好能保留通用性，在不同上下文中自己决定要不要调用工具。
这和现在很多 agent 系统不一样。现在常见做法是把工具 schema 暴露给模型，让模型在线决定调用。Toolformer 更像是在训练阶段把“工具使用习惯”写进模型行为里。
局限也很早就暴露了
Toolformer 不能很好地链式调用工具。每个 API 调用基本是独立样本，不能把一个工具的输出作为另一个工具的输入。这就限制了它处理多步任务的能力。
它也不是交互式工具使用。对于搜索这类工具，如果返回很多结果，模型不能像浏览器 agent 那样继续浏览、改 query、再搜索。它更像是在文本生成中插入一次工具响应。
还有一个现实问题：样本效率可能很低。为了得到几千个有用的计算器调用，可能要处理大量文档。模型是否调用 API 还会对输入措辞很敏感。
我现在怎么理解它
Toolformer 最值得保留的不是具体实现，而是一个问题意识：工具调用能不能从数据中自举出来，而不是靠人手工写大量规则。
今天看，它和 ReAct、ReWOO、LLMCompiler 是不同层面的东西。Toolformer 偏训练数据和模型习惯；ReAct 偏运行时闭环；ReWOO 偏减少观察交错；LLMCompiler 偏依赖图和并行调度。
如果要做产品，我不会直接照搬 Toolformer。但我会借用它的思想：工具调用样本应该被评估和过滤，不能只要模型喊了工具就当作正确行为。一个好的工具调用数据集，应该能证明“调用这个工具让后续预测或任务结果更好”。
小结
Toolformer 像是工具使用路线里的早期分岔口：不是让模型每次在线摸索，而是让模型从普通文本中学习工具调用的时机。
它解决不了复杂 agent 的多轮执行，但它提醒我：工具使用不只是 prompt 和接口问题，也是数据构造和行为学习问题。