LLM 工具使用的技术演进：从 Toolformer 到 ToolLLM

为什么关注工具使用

大语言模型在很多经典的 NLP 领域取得了杰出的效果，但在算术问题和事实回答等场景上的性能却不尽人意——模型无法及时更新内部参数，且存在幻觉问题。通过赋予 LLM 使用外部工具的能力，我们可以让它们访问实时、准确的知识库，并完成复杂的计算任务。

关于 Tool Use，最值得工程界关注的可能是 MCP（Model Context Protocol）协议。MCP 提供了一个标准化的工具定义与描述通信协议，让模型能够以统一的方式发现和调用工具。关于 MCP 的详细介绍，可以参考本博客此前的文章。了解 Tool Use 的相关论文，更多是为了理解其中的发展脉络与技术思路的演变。

Toolformer：自监督学习工具调用

Schick et al., Toolformer: Language Models Can Teach Themselves to Use Tools, NeurIPS 2023.

Toolformer 考虑对原始模型进行微调，借助微调来增强其在 Tool Use 上的能力，同时学习给出的工具。其微调用数据集使用了自监督的方式来生成，并且在单次解码中一次性完成对工具的使用。

关于自监督生成的微调数据集：使用上下文学习的方式让模型主动请求使用工具。当模型使用工具后，通过对比使用工具/不使用工具的解码损失来衡量工具使用是否有价值，然后将有价值的结果组织成微调用数据集
关于解码中的工具调用：执行常规解码，当解码得到请求 API 调用的 token 符号时，请求调用 API，并将结果返回到解码序列中，然后继续解码流程

Toolformer 是对引入外部工具的一种早期尝试，但由于没有能够结合现在模型的推理能力而依赖解码上的修改，效果有限。同时由于单次解码的策略，Toolformer 无法链式地利用工具，无法满足多智能体的工具调用需求。其最值得学习的部分可能是自监督学习的策略。

Gorilla：微调与检索的结合

Patil et al., Gorilla: Large Language Model Connected with Massive APIs, 2023.

先前的大部分工作在将工具集成到 LLM 时，考虑的是一组小型、文档完善的 API，这些 API 可以轻松注入到提示中。然而，支持一个超大型的、具有重叠功能的 API 仓库需要新的技术来解决。

本文考虑了使用 Self-Instruct Fine-Tuning（对原始模型进行参数微调）以及 Retrieval（通过检索手段来获得上下文提示，类似 MCP 但没有全部注入 Prompt）来加强模型对大规模 API 库的正确调用能力，以规避提示词注入的方法。

将直接的 Fine-Tune 和 Retrieval 结合起来进行是本文较为重要的改进，即 Retrieval-Aware Training。实验证明：

有好的检索器时，Retrieval-Aware Training 比单纯的微调更好
Retrieval-Aware Training 可以适应 API 文档的快速更改
涉及 API 的调用约束（需权衡多种需求来决定选择哪个 API）时，所有模型的性能都产生了显著下降

考虑使用微调以及简单的检索来实现工具调用。由于不涉及多轮推理和调用，对指令检索后得到的相关 API 会作为上下文交给模型处理。

Tulip Agent：递归任务分解与语义检索

Ruis et al., Tulip Agent: Enabling LLM-Based Agents to Solve Tasks Using Large Tool Libraries, 2024.

Tulip Agent 不会将所有可用工具的描述编码在系统提示中（这会占用模型的上下文窗口），也不会嵌入整个提示以检索合适的工具。而是将整个任务分解成递归的多个子任务，每个子任务单独进行语义级别的向量数据库检索，以匹配合适的工具，并且允许动态的工具管理。

相比于前面的技术：

放弃了将全部工具描述以提示词的形式注入 LLM，以规避过长上下文的问题
放弃将提示一次性嵌入寻找工具，而是将任务进行推理规划后进行嵌入、检索、进一步推理思考
使用向量数据库、Embedding 以及类似 RAG 的技术进行工具的检索
允许工具的动态管理

本技术中，检索器在每个推理规划的步骤结束后被激活来检索相关 API，然后以上下文的形式提供给模型参考应该调用哪些 API。

ToolLLM：通用工具使用框架

Qin et al., ToolLLM: Facilitating Large Language Models to Master 16000+ Real-World APIs, ICLR 2024.

ToolLLM 引入了一个涵盖数据构建、模型训练和评估的通用工具使用框架，是一个较为完善的系统工程。在 Tool Use 方面作为开源项目获取了大量关注，是 LLM Agents 工具使用方面最好的项目之一。

闭源模型已经具备较强的工具调用能力，但开源社区现有研究存在不足：

API 数量有限，可能覆盖范围太小、多样性不足
局限于单工具调用，经常假设用户手动给定理想的 API 集
规划和推理能力不足，包括 CoT 推理或 ReAct 的推理与行动

核心组件

API 收集：从 RapidAPI 平台收集了 16,464 个 REST API，涵盖 49 个不同类别，包含详细文档供 LLM 学习。

指令生成：从整个 API 集合中采样，提示 ChatGPT 生成多样化的指令，涉及单工具和多工具场景（Self-Instruct）。

解决方案路径标注：每个解决方案路径可能包含多轮模型推理和实时 API 调用。为此开发了基于深度优先搜索的决策树（DFSDT）来增强 LLM 的计划和推理能力。

评估（ToolEval）：开发了自动评估器 ToolEval 来评估 LLM 的工具使用能力。

微调（ToolLLaMA）：通过在 ToolBench 上微调 LLaMA 得到指令生成模型。

关键发现

ToolLLaMA 展示了处理单工具和复杂多工具指令的强大能力
ToolLLaMA 对未见过的 API 表现出强大的泛化能力，只需 API 文档即可有效适应新 API
DFSDT 通过考虑多个推理轨迹扩展了搜索空间，比 ReAct 实现了显著更好的性能——这是对推理策略的研究

在本研究中，检索只对用户指令进行一次，搜索得到相关 API 会在多轮推理中交给模型作为上下文参考，方便其思考推理策略。

本文给出的 DFSDT 作为一种决策推理策略，和 ReAct 联系紧密。也就是说本文不仅局限于工具调用的性能，还思考了包含工具调用的整个推理来解决问题的流程。

结语

回顾 Tool Use 的研究脉络，从 Toolformer 的自监督微调、Gorilla 的检索增强训练、Tulip Agent 的递归分解检索，到 ToolLLM 的大规模系统工程，这条研究路线围绕的核心问题始终是：如何让模型在海量工具中找到正确的那一个，并正确地调用它。

然而，随着基础模型能力的快速提升和 MCP（Model Context Protocol）的出现，Tool Calling 作为独立研究方向的价值正在迅速消退。 当前的前沿模型（如 GPT-4、Claude 等）已经原生具备了强大的函数调用能力，不再需要额外的微调或复杂的检索管线来实现工具使用。而 MCP 作为标准化的工具通信协议，直接在工程层面解决了工具描述、发现与调用的统一问题——它让工具使用从一个需要训练的能力退化为一个标准的通信接口。

曾经困扰 Tool Use 研究的核心难题——上下文膨胀、工具检索、多轮调用——正在被更长的上下文窗口、更强的原生推理能力和标准化协议所自然消解。学术界在 Tool Use 上的研究贡献已经完成了它的历史使命，后续的工作将更多发生在工程实践和协议标准层面，而非算法和模型训练层面。 本文不再更新。