Tool-Using LLM 论文精读路线：从 ReAct 到可验证工具调用

Tool-Using LLM 论文精读路线：从 ReAct 到可验证工具调用

系列 ：AI 论文精读与复现训练营

日期 ：2026-08-08

适合读者：已经读过 LLM reasoning、RAG 或 agent 论文，想系统理解工具调用、函数调用、可验证执行和 agent benchmark 的研究生、科研新人和工程背景读者。

目录

1. 为什么这个主题重要
2. 核心阅读方法：把工具调用拆成六个问题
3. 代表论文路线图
4. 关键论文精读
5. 方法与实验对比表
6. 复现建议
7. 常见误区
8. 适合研究生继续做的选题
9. 总结
10. 参考资料

为什么这个主题重要

语言模型本身只是在生成文本。它能写出"我将搜索数据库""我会调用天气 API"，并不等于真的完成了任务。工具调用研究关心的是从自然语言意图到外部世界动作的转换：调用哪个函数、何时调用、参数是否符合 schema、执行结果是否被正确吸收、任务状态是否真的改变、当工具不适用时是否会拒绝或追问。

这正是 Tool-Using LLM 与普通问答、RAG、reasoning 的分界。RAG 主要把外部知识检索回来，工具调用则会改变环境或触发计算；reasoning 关注中间推理路径，工具调用还要求路径里的动作可以执行。一个 agent 可能看起来很会规划，但只要把 user_id 填错、把日期格式写错、在缺少必要参数时硬调用，最终就是失败。

2025-2026 年之后，研究重心明显转向"可验证"。BFCL 把函数调用评测从单轮选择推进到 AST 匹配、并行调用、拒调用和多步 agentic 设置；tau-bench 让 agent 与模拟用户在零售、航旅等有状态环境中对话，并用最终数据库状态对照目标状态；ToolSandbox 强调状态依赖、对话交互和动态里程碑；APIGen-MT 则把多轮工具数据构造成可执行、可验证的模拟交互。对科研训练来说，这个方向非常适合练习"从论文主张到可复现实验"的能力，因为每个结论都可以追问：工具执行了吗？状态对了吗？失败能定位吗？

核心阅读方法：把工具调用拆成六个问题

第一，工具接口如何表示。 ReAct 早期多用自然语言 action；Toolformer 把 API 调用插入文本；现代 function calling 通常使用 JSON schema、参数类型和工具描述。读论文时要记录工具描述是人工写的、自动抽取的，还是由协议或 SDK 生成的。schema 越严格，评测越容易；工具描述越开放，模型越容易幻觉参数。

第二，调用策略从哪里来。 ReAct 依赖少量轨迹示例；Toolformer 通过采样 API 调用并保留降低语言模型 loss 的样本来训练；ToolLLM 使用从 RapidAPI 收集的大规模工具和自动构造的 solution path；Gorilla / OpenFunctions 一类工作把 API 文档和调用格式作为训练对象；APIGen 和 APIGen-MT 更强调合成数据必须经过执行、格式和语义验证。读这条线，要分清 prompt 能力、SFT 数据能力和执行环境能力。

第三，工具选择和参数生成是否分开评测。 模型选对工具但参数错，和选错工具但格式正确，是两类失败。BFCL 的价值之一是把多语言、并行调用、多函数候选、相关性检测等场景纳入评测。做阅读笔记时，建议每篇论文都写一列：它主要测 tool selection、argument filling、multi-step planning、state tracking，还是 final outcome。

第四，工具结果如何进入下一步推理。 真正的 agent 不只是"一次调用"。它要读取 observation，更新工作记忆，判断是否继续调用、换工具、追问用户或停止。tau-bench、ToolSandbox、APIGen-MT 这类多轮环境的难点就在这里：模型可能前几步都正确，最后因为忘记政策约束、忽略数据库状态或错误吸收 API 返回而失败。

第五，评测是否执行或近似执行。 最弱的评测是让另一个 LLM 判断调用是否合理；更可靠的是 AST / schema 匹配；再进一步是实际执行函数，检查返回值、数据库状态、文件系统变化或任务目标。每篇论文的可信度很大程度取决于它的验证信号。如果工具本身是 live API，还要检查 API 版本、网络波动、权限和数据是否随时间变化。

第六，安全边界在哪里。 工具调用把模型输出变成动作，因此必须读拒调用、权限、用户确认、错误处理和审计日志。MCP 规范和主流 Agents SDK 都把工具 schema、调用控制和人工确认作为系统设计问题，而不是只靠模型"自觉"。科研复现时，安全边界可以简化，但不能从问题定义里消失。

代表论文路线图

阶段	代表工作	精读抓手
推理-行动交错	ReAct	thought-action-observation 轨迹，错误是否可人工诊断
自监督工具学习	Toolformer	采样哪些 API 调用，如何筛选"有帮助"的调用
多模态/开放工具训练	GPT4Tools, ToolLLM	指令数据如何合成，seen/unseen tools 如何评测
API 函数调用专训	Gorilla, OpenFunctions, xLAM/APIGen	API 文档、schema、retriever、合成数据和执行验证
函数调用 benchmark	BFCL, ACEBench	AST 匹配、并行调用、拒调用、多轮和不完整指令
有状态 agent 评测	ToolSandbox, tau-bench, APIGen-MT	用户模拟、状态转移、pass^k、数据库目标状态
协议和运行时	MCP, Agents SDK, terminal-use benchmarks	工具发现、权限、日志、真实环境执行和可复现性

这张表不是论文排名，而是读文献时的坐标系。一个新工作如果声称"提升 tool use"，先判断它改的是接口、训练数据、检索、调用格式、执行器、环境模拟，还是评测协议。

关键论文精读

ReAct。 ReAct 的贡献是把 reasoning traces 和 task-specific actions 交错生成，让模型在"想一步、做一步、看反馈"之间循环。精读时不要停在 prompt 模板，而要看四类任务：HotpotQA、FEVER、ALFWorld、WebShop 分别代表知识检索、事实验证、交互环境和网页购物。复现可以从一个小型 Wikipedia search 或 WebShop-like 环境开始，重点记录 action 是否改变了 observation，以及错误能否通过轨迹定位。

Toolformer。 Toolformer 把工具使用改写成语言建模数据筛选问题：先给少量 API 示例，再让模型在文本中采样可能的调用，执行工具，保留能改善后续 token 预测的调用。它最值得学习的是"无需大量人工工具轨迹"的训练思路。阅读时要追问：保留下来的调用是否真的对任务有因果帮助？对搜索、计算器、翻译、日历等不同工具，收益机制是否一样？

ToolLLM / ToolBench。 ToolLLM 把问题规模放大到真实 API 集合，使用 API 收集、指令生成、solution path 标注和 ToolEval 评测。它适合训练你阅读数据构造论文：API 来自哪里，类别是否均衡，自动标注是否可验证，unseen API 的泛化如何定义。注意 ToolBench 依赖真实 API 时容易遇到 API 失效和不可复现问题，因此后续工作常引入虚拟 API 或可执行 sandbox。

Gorilla 与 BFCL。 Gorilla 关注把 LLM 连接到大量 API，减少调用幻觉；BFCL 则把函数调用能力做成更标准化的 benchmark。BFCL 的精读重点是评测设计：AST 匹配为什么比纯字符串匹配更稳，serial / parallel / multiple function call 如何区分，函数相关性检测如何测试拒调用。2025 的 ICML/PMLR 版本和 Berkeley 项目页都显示，BFCL 已从单轮函数调用延伸到更 agentic 的评测设置； live leaderboard 的具体名次和模型版本变化快，写论文或博客时应标注"检索日期"和"待人工核验"。

tau-bench。 tau-bench 的核心不是多了几个工具，而是把工具调用放进用户对话和业务规则中。它用模拟用户与 agent 对话，agent 调用 API 并遵守政策，最后比较数据库状态与目标状态，还提出 pass^k 来衡量多次运行的一致性。读这篇时要重点看两件事：第一，任务成功不是"回答听起来对"，而是环境状态真的对；第二，同一个任务多次运行是否稳定，比一次成功更接近可靠性。

ToolSandbox 与 APIGen-MT。 ToolSandbox 进一步强调 stateful、conversational、interactive：工具之间有隐含状态依赖，用户信息可能分多轮给出，评价包含中间里程碑和 minefield。APIGen-MT 则从数据生成角度解决多轮工具数据稀缺问题：先生成可验证任务蓝图，再模拟 human-agent-environment 轨迹，并用执行和语义检查过滤。两者适合放在一起读：一个告诉你好的评测环境长什么样，一个告诉你如何合成可验证多轮训练数据。

MCP 与现代 Agents SDK。 协议和 SDK 不是传统论文，但对 2025-2026 的工具调用研究很重要。MCP 标准化了工具如何暴露给模型，工具包含名称、描述和 schema；OpenAI Agents SDK 等运行时把 hosted tools、function tools、MCP servers、错误处理、审批和 tracing 放进统一 agent loop。读这些资料的目的不是学习某个产品，而是理解研究实验如何逐渐靠近真实运行时：工具发现、权限、日志和可审计性都会影响结果。

方法与实验对比表

方法	主要变量	适合任务	复现风险
ReAct prompting	示例轨迹、action 格式、observation 设计	搜索问答、网页导航、小型交互环境	prompt 泄漏，轨迹格式脆弱
Toolformer 式自监督	API 示例、采样位置、执行结果、loss 筛选	计算、检索、翻译、日历等工具	"有帮助"信号可能只适配局部分布
Tool instruction tuning	API 文档、合成指令、solution path	大工具集、seen/unseen API 泛化	自动标注错误和真实 API 失效
Function calling SFT	schema、参数类型、拒调用样本	工程函数调用、并行调用	只学格式，不学任务状态
AST/schema 评测	解析器、等价规则、参数容差	大规模函数调用 leaderboard	与真实执行结果仍有差距
Stateful sandbox	用户模拟、数据库状态、里程碑	客服、日程、文件、终端任务	环境构造成本高，任务设计需人工审查
MCP/agent runtime	工具发现、权限、日志、错误处理	真实 agent 系统和长期实验	版本变化快，需要锁定协议和依赖

读实验表时，至少记录四类指标：调用格式正确率、工具选择正确率、任务最终成功率、稳定性或 pass^k。只报告 final answer 或 LLM judge 分数，无法说明工具调用能力。

复现建议

不要一开始复现完整 tau-bench 或 BFCL。更适合训练营的是搭一个小型可执行 tool-use lab。

1. 定义 10-20 个本地函数。 例如查询课程表、读写 JSON 数据库、计算统计量、生成文件、校验日期。每个函数写清 schema、参数类型、错误返回和权限。
2. 构造 100 条任务。 覆盖单工具、多工具、并行工具、缺少参数、错误参数、无合适工具、需要追问、需要拒绝等类别。
3. 实现三个基线。 Direct answer、ReAct text action、structured function calling。所有基线使用同一模型、同一任务集和同一执行器。
4. 设计执行验证器。 不要只看模型输出。对每题检查函数调用序列、参数、返回值利用、最终数据库或文件状态。
5. 记录完整日志。 保存 prompt、model、temperature、tool schema、每轮消息、tool call、tool output、错误栈、最终状态和评分脚本版本。
6. 做 failure taxonomy。 至少区分：工具选择错、参数错、缺参未追问、调用顺序错、忽略 observation、状态更新错、应该拒绝却调用、格式解析失败。
7. 做 ablation。 去掉工具描述细节、打乱工具顺序、加入相似工具、加入无关工具、限制最大调用步数，观察失败类型如何变化。

最终 reproduction report 不必追求大榜分数，而要能回答一个研究问题：结构化 schema、执行反馈和状态验证分别减少了哪类错误？

常见误区

1. 把"能输出函数名"当成会用工具。 真正的工具调用还包括参数、顺序、执行反馈和最终状态。
2. 只测单轮干净指令。 真实用户经常缺参数、改需求、说错信息或请求越权；这些才是工具 agent 的关键难点。
3. 混淆检索和行动。 搜索是工具的一种，但写数据库、下订单、发邮件、改文件需要更强的权限和验证。
4. 用 live API 做不可复现实验。 API 版本、额度、网络和数据都会变。严肃复现应优先使用 mock server、fixture 或本地 sandbox。
5. 忽略拒调用。 好的工具 agent 不只是多调用，还要知道什么时候不调用、追问或请求人工确认。
6. 迷信 leaderboard 名次。 BFCL、tau-bench、MCP 相关榜单更新很快，具体模型排名必须按检索日期核对，不能写成长期结论。

适合研究生继续做的选题

1. 工具描述鲁棒性。 系统研究 schema 描述长度、参数示例、错误提示和工具顺序对调用结果的影响。
2. 拒调用数据集。 构造缺参、越权、无工具可用、工具结果冲突的样本，评估模型何时应该停止或追问。
3. 执行反馈学习。 比较只用 final state、完整轨迹、错误栈和人工 failure label 对后续 SFT/RL 的贡献。
4. 状态压缩记忆。 多轮工具任务中，哪些状态必须保留在上下文，哪些可以通过重新查询恢复。
5. 工具调用 reward model。 研究 reward model 是否能识别参数错误、顺序错误和无效调用，而不是只偏好流畅解释。
6. MCP-enabled agent benchmark。 在可控本地 MCP server 上设计小而真实的任务，评估工具发现、权限确认和日志审计。

总结

Tool-Using LLM 的研究主线可以概括为：先用 ReAct 把思考和行动交错起来，再用 Toolformer / ToolLLM / Gorilla 让模型学会 API 格式和大规模工具集合，最后用 BFCL、ToolSandbox、tau-bench、APIGen-MT、MCP 和真实运行时把"会调用"推进到"可验证、可审计、可复现"。读这类论文时，最重要的不是记住某个榜单第一，而是建立一套检查框架：接口是否结构化，调用是否执行，状态是否正确，失败是否可定位，权限是否可控，实验是否能在未来重跑。

如果只读五篇，建议从 ReAct、Toolformer、ToolLLM、BFCL、tau-bench 开始；如果要做一个可发表的小选题，则从本地 sandbox 和 failure taxonomy 开始。工具调用不是 agent 的全部，但它是 agent 从"会说"走向"会做"时最容易被严格验证的一段路径。

参考资料

检索日期：2026-08-08。

1. Shunyu Yao et al. "ReAct: Synergizing Reasoning and Acting in Language Models." Project page, arXiv 2022, ICLR 2023. https://react-lm.github.io/
2. Timo Schick et al. "Toolformer: Language Models Can Teach Themselves to Use Tools." NeurIPS 2023. https://proceedings.neurips.cc/paper/2023/hash/d842425e4bf79ba039352da0f658a906-Abstract-Conference.html
3. Rui Yang et al. "GPT4Tools: Teaching Large Language Model to Use Tools via Self-instruction." NeurIPS 2023. https://papers.neurips.cc/paper_files/paper/2023/hash/e393677793767624f2821cec8bdd02f1-Abstract-Conference.html
4. Yujia Qin et al. "ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs." ICLR 2024. https://proceedings.iclr.cc/paper_files/paper/2024/hash/28e50ee5b72e90b50e7196fde8ea260e-Abstract-Conference.html
5. Shishir G. Patil et al. "Gorilla: Large Language Model Connected with Massive APIs." Project page and official GitHub. https://gorilla.cs.berkeley.edu/ ; https://github.com/ShishirPatil/gorilla/
6. Shishir G. Patil et al. "The Berkeley Function Calling Leaderboard (BFCL): From Tool Use to Agentic Evaluation of Large Language Models." ICML 2025, PMLR. https://proceedings.mlr.press/v267/patil25a.html
7. Berkeley Sky Computing Lab. "Berkeley Function-Calling Leaderboard." Project page, updated 2025. https://sky.cs.berkeley.edu/project/berkeley-function-calling-leaderboard/
8. Shunyu Yao et al. "tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains." ICLR 2025. https://proceedings.iclr.cc/paper_files/paper/2025/hash/1b126cc38b8638e07bef37e7b2bb72bf-Abstract-Conference.html
9. tau-bench official site and benchmark evolution notes. https://taubench.com/
10. Jiarui Lu et al. "ToolSandbox: A Stateful, Conversational, Interactive Evaluation Benchmark for LLM Tool Use Capabilities." arXiv 2024; official repository linked in paper. https://arxiv.org/abs/2408.04682 ; https://github.com/apple/ToolSandbox
11. Zuxin Liu et al. "APIGen: Automated Pipeline for Generating Verifiable and Diverse Function-Calling Datasets." arXiv 2024; project page. https://arxiv.org/abs/2406.18518 ; https://apigen-pipeline.github.io/
12. Akshara Prabhakar et al. "APIGen-MT: Agentic Pipeline for Multi-Turn Data Generation via Simulated Agent-Human Interplay." arXiv 2025; project page. https://apigen-mt.github.io/
13. Zhengliang Shi et al. "Tool Learning in the Wild: Empowering Language Models as Automatic Tool Agents." WWW 2025, OpenReview. https://openreview.net/forum?id=T4wMdeFEjX
14. OpenAI Help Center. "Function Calling in the OpenAI API." Updated 2026. https://help.openai.com/en/articles/8555517
15. OpenAI Agents SDK. "Tools." Official documentation. https://openai.github.io/openai-agents-python/tools/
16. Model Context Protocol. "Tools." Specification 2025-06-18. https://modelcontextprotocol.io/specification/2025-06-18/server/tools
17. TUA-Bench. "A Benchmark for General-Purpose Terminal-Use Agents." Official site, arXiv citation shown on page. https://tuabench.ai/
18. Huanzhi Mao et al. "MFCL Vision: Benchmarking Tool Use in Multimodal Large Language Models for Visual Reasoning Tasks." NeurIPS 2025 Workshop, OpenReview. https://openreview.net/forum?id=vV4tC5rhw6