从 Toolformer 到 RL Tool PolicyTool Learning / Agentic Tool Use 论文路线盘点系列AI 论文盘点 / 技术趋势日期2026-06-23适合读者研究生、LLM/Agent 方向研究者、正在建设工具调用系统的工程读者摘要过去一年Tool Learning 的主线从“让模型会调用函数”推进到“让模型在多轮环境中稳定完成任务”。早期工作关心 API 选择、参数填充和格式正确性近一年的重点转向交互状态、用户协作、长上下文工具说明、动态工具集合、RL 训练以及安全边界。本文按研究路线梳理代表论文与 benchmark经典基础包括 ReAct、Toolformer、API-Bank、Gorilla、ToolLLM近一年重点包括 BFCL V4、ToolSandbox、tau^2-Bench、ASTRA-bench、ComplexFuncBench、ACEBench、RAGEN、EGPO/RC-GRPO、EigenData 和 MCP 安全相关研究。工程结论很直接工具调用不是一个“prompt 技巧”而是一套可评测、可审计、可回滚的分布式系统接口。目录研究背景工具调用为什么重新变成核心问题近一年路线图从 schema matching 到交互式 agent代表论文分组解读方法对比表关键技术趋势工程落地启发局限与争议接下来值得关注的问题参考资料研究背景工具调用为什么重新变成核心问题LLM 本身擅长语言建模但真实应用往往需要外部能力查数据库、调用业务 API、写入工单、跑代码、检索文件、浏览网页、操作 UI。工具调用把“回答问题”改写成“选择工具、生成参数、执行动作、读取结果、继续决策”的闭环。OpenAI 的 function calling / tools 文档也把函数、内置工具、远程 MCP、tool search 放在同一套工具语义下模型生成 tool call应用执行并返回 tool output然后模型再继续生成回复或下一步调用。这带来两个研究难点。第一语言模型输出不再只是自然语言而是具备副作用的结构化动作任何参数错误都可能导致真实系统状态改变。第二agent 的成功不只取决于单次调用是否正确还取决于多轮状态追踪、错误恢复、用户澄清、权限控制和执行环境。也就是说Tool Learning 的问题边界正在从 NLP benchmark 向软件工程系统扩展。近一年路线图阶段一Prompt / ReAct 式工具使用。ReAct 将 reasoning trace 与 action 交替生成让模型一边推理一边调用外部环境。它的重要性不在于某个固定 prompt 模板而在于把“思考”和“行动”编排成轨迹。对今天的 agent 系统来说ReAct 仍是最常见的执行循环原型计划、调用、观察、修正。阶段二监督式工具学习。Toolformer 用少量示例和自监督筛选训练模型决定何时调用 API、传什么参数、如何利用结果。API-Bank、Gorilla、ToolLLM 则把研究焦点扩展到真实 API 集合、工具检索、调用格式和训练数据构造。这个阶段的核心问题是模型能否把自然语言意图映射到正确工具和参数。阶段三交互式与状态化评测。2024 到 2026 年的 benchmark 明显不再满足于单轮 JSON 是否匹配。ToolSandbox 引入 stateful tool execution、隐式状态依赖和用户模拟器tau^2-Bench 把用户也建模为会使用工具的参与方ASTRA-bench 强调个人上下文、时间演化事件和复杂意图BFCL V4 的官方页面也明确把方向扩展到 holistic agentic evaluation并标注榜单最后更新为 2026-04-12。阶段四RL 与过程奖励。近一年多篇论文把 tool calling 当作可强化学习的策略问题。RAGEN 关注多轮 agent RL 中的轨迹级训练、探索和奖励不稳定EGPO 试图用探索增强的 GRPO 训练更鲁棒的 function callingRC-GRPO 用 reward-conditioned trajectory policy 提高多轮 tool calling 的组内探索多样性ToolPRM 则把结构化工具调用的 inference scaling 与过程奖励模型结合。这里的共同判断是只靠 SFT 学“标准答案轨迹”不足以覆盖交互式环境中的失败恢复。代表论文分组解读1. 基础范式从语言生成到行动轨迹ReAct 提供了最小可用的 agent 执行循环模型显式生成推理轨迹并穿插动作。它适合工具数量少、环境反馈清晰的任务缺点是 prompt 暴露的中间推理不一定适合生产系统也容易把“解释性文本”与“可执行动作”混在一起。Toolformer 的贡献是把工具调用变成可学习的 token-level 行为模型不仅要知道答案还要判断何时借助计算器、搜索、翻译、日历等工具。它证明了工具使用可以通过数据筛选和训练内化到模型中。但今天看它的环境还比较理想化工具集合固定、调用风险低、交互深度有限。2. API 规模化检索、路由与参数生成API-Bank 构造了可运行 API 环境和工具使用对话提出规划、检索、调用等能力切分。Gorilla 强调大规模 API 连接和减少 API hallucinationToolLLM / ToolBench 则推进到 16000 真实 API 的 instruction tuning 和评测。它们奠定了今天 function calling 模型训练的三件套工具说明语料、工具检索器、调用轨迹数据。工程上这条路线提醒我们不要把所有工具一次性塞进上下文。官方工具文档也强调初始暴露函数过多会增加 token 与选择难度建议用更小的初始工具集、明确 schema、严格模式以及 tool search / allowed tools 等机制控制工具面。3. Benchmark 迁移从 AST 匹配到任务完成BFCL 早期用 AST 评估函数调用正确性V4 官方页面把重点描述为从 tool use 到 agentic evaluation覆盖真实数据、周期更新、成本与延迟等维度。ToolSandbox 进一步强调状态依赖和对话式 on-policy 评测ACEBench 把普通、特殊、Agent 三类工具使用场景分开分析不同错误类型ComplexFuncBench 关注长上下文、多步约束和参数填充IFEval-FC 则把参数描述中的格式指令作为评测对象指出“参数值对了但格式没严格遵守”也是生产故障。这一转变很关键单步 schema accuracy 只能证明模型会“写出一个函数调用”不能证明它能在业务状态变化、用户补充信息、权限限制和工具失败时完成任务。4. 交互式 agent用户不再是被动输入框tau^2-Bench 的 dual-control 设计非常有代表性在真实客服、IT 支持、运营系统里用户不是只回答问题也可能自己修改系统状态。agent 必须协调用户动作与工具动作解释下一步避免因为状态竞争而失败。ASTRA-bench 则把个人上下文、长期事件和复杂引用放进评测让工具调用进入“私人助理”场景。这类 benchmark 对工程架构的启发是agent memory、用户确认、状态锁、事务边界、观察刷新比单个模型的 function-call 准确率同样重要。5. RL 工具策略让模型学会探索与恢复SFT 往往复制训练轨迹适合稳定 API 和单轮任务但多轮工具环境会出现 sparse reward、错误传播和探索成本高的问题。RAGEN 把多轮 agent RL 的不稳定性作为研究对象指出缺少细粒度、reasoning-aware 奖励时模型可能学到浅层策略。EGPO、RC-GRPO、R2IF 等工作都在尝试把 GRPO 类训练迁移到 function calling有的改 advantage有的控制轨迹质量有的把推理过程与调用决策对齐。这些结果仍需谨慎看待许多论文报告的 benchmark 提升依赖特定模型、数据和评测实现是否能泛化到真实业务 API仍然需要复现实验和线上 A/B 验证。本文不把论文声称的 SOTA 排名作为稳定事实相关数字建议以论文版本与 leaderboard 当前页面再次核对。方法对比表路线代表工作主要解决什么工程启发Prompt / ReActReAct让推理与动作交替发生适合原型生产中要分离可执行动作与解释文本自监督工具学习Toolformer学会何时调用工具及如何利用结果可用少量 seed demonstrations 扩展训练数据API 检索与 SFTAPI-Bank, Gorilla, ToolLLM大规模工具选择、参数生成、API 幻觉工具说明质量和检索召回决定上限Function calling benchmarkBFCL, ACEBench, ComplexFuncBench, IFEval-FC结构化调用、格式、长上下文、多步约束不只评估 exact match也要评估执行后状态Stateful / conversational evalToolSandbox, tau^2-Bench, ASTRA-bench状态依赖、用户协作、个人上下文需要事务、回滚、用户确认和审计日志RL tool policyRAGEN, EGPO, RC-GRPO, ToolPRM多轮探索、稀疏奖励、过程监督奖励设计与环境模拟比算法名称更重要关键技术趋势第一工具 schema 正在从“文档”变成“控制面”。函数名、参数枚举、required 字段、additionalProperties、严格模式、参数描述中的格式要求都会直接影响模型行为。好的 schema 应该让非法状态尽量不可表达而不是期待模型凭常识补救。第二工具数量管理成为上下文工程问题。大量 API 会增加选择混淆、token 成本和延迟。tool search、命名空间、分层路由、基于任务的 allowed tools、缓存工具列表正在成为 agent runtime 的基础能力。第三评测从离线答案转向可执行环境。未来更有价值的 benchmark 会记录数据库状态、环境变化、用户模拟轨迹、失败恢复过程而不是只看模型是否生成了参考 JSON。第四安全研究开始追上协议生态。MCP 让工具接入更标准化但也扩大了工具权限、提示注入、跨工具数据泄露和恶意 server 描述的风险。MCP Safety Audit 等论文提示我们工具协议不是安全边界权限、隔离、审批和可观测性才是。工程落地启发把工具调用当作 RPC 系统设计。每个 tool 都需要 schema、幂等性说明、错误码、权限模型、超时、重试和审计字段。先做小工具集再做动态发现。默认暴露少量高置信工具长尾工具通过检索或 tool search 延迟加载。把“是否调用工具”纳入评测。很多失败不是参数错而是过度调用、漏调用、在信息不足时强行调用。记录完整轨迹但不要无条件展示完整推理。生产系统可保存工具调用、观察、状态差异和用户确认不必把内部 chain-of-thought 作为用户界面的一部分。对有副作用工具使用事务边界。写操作前做权限校验和用户确认失败时支持补偿或回滚高风险动作进入人工审批。建立本地 benchmark。公开榜单只能提供方向真正上线前要用自己的 API、数据分布、权限约束和异常路径构造任务集。局限与争议Tool Learning 目前最大的问题是评测碎片化。不同 benchmark 的工具集合、执行器、用户模拟器和评分函数差异很大榜单排名很难直接迁移到业务场景。第二个问题是合成数据质量大规模工具轨迹容易覆盖格式却未必覆盖真实用户的含糊表达、错误信息和状态竞争。第三个问题是安全边界模型能生成正确 tool call不代表它应该被授权执行该 call。还有一个容易被忽视的争议RL 是否一定优于 SFT。对固定、低风险、强 schema 的工具SFT 加严格校验可能已经足够对长程、多轮、状态变化明显的环境RL 或过程奖励才更可能体现价值。工程上不应为了“agent RL”而增加训练复杂度先用可执行评测定位瓶颈更稳妥。接下来值得关注的问题第一工具调用的 benchmark 会不会从“函数正确率”转向“业务状态正确率”。EigenData 对 BFCL-V3 的审计与修复工作已经指出 schema、实现和参考轨迹本身可能存在系统性错误这类 benchmark hygiene 会越来越重要。第二动态工具生态如何做安全隔离。MCP、插件、远程工具服务器让能力发现更灵活也让供应链风险进入 agent 系统。如何定义最小权限、工具信誉、沙箱和跨工具数据流是下一阶段关键问题。第三小模型和端侧 function calling 是否会成熟。Hammer、Granite Function Calling 等工作说明专门训练的小模型有机会在局部任务上具备实用价值但它们仍需要面对工具集合变化和复杂对话状态。第四RL 工具策略如何与可解释性结合。过程奖励、轨迹过滤、reward-conditioned exploration 都在解决同一个矛盾模型需要探索但生产系统需要可控。谁能把训练收益、可解释调用和执行安全放在同一框架内谁就更接近可部署 agent。总结Tool Learning 的研究重心已经从“模型会不会输出函数调用”升级为“agent 能不能在真实工具环境中稳定完成任务”。过去一年最值得关注的不是某个单点 SOTA而是范式变化工具面要被检索和治理调用轨迹要被执行和审计评测要覆盖状态与用户协作训练要处理探索和失败恢复。对工程团队来说最实用的策略是把 LLM 工具调用纳入常规软件工程纪律小工具集、强 schema、可执行评测、沙箱权限、日志审计和逐步放权。参考资料检索日期2026-06-23。Hu et al., “Agentic Tool Use in Large Language Models”, arXiv, 2026-04-01. https://arxiv.org/abs/2604.00835Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models”, arXiv / ICLR camera ready, 2022-2023. https://arxiv.org/abs/2210.03629Schick et al., “Toolformer: Language Models Can Teach Themselves to Use Tools”, arXiv, 2023-02-09. https://arxiv.org/abs/2302.04761Li et al., “API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs”, arXiv / EMNLP 2023. https://arxiv.org/abs/2304.08244Patil et al., “Gorilla: Large Language Model Connected with Massive APIs”, arXiv, 2023-05-24. https://arxiv.org/abs/2305.15334Qin et al., “ToolLLM: Facilitating Large Language Models to Master 16000 Real-world APIs”, arXiv, 2023-07-31. https://arxiv.org/abs/2307.16789Berkeley Function Calling Leaderboard (BFCL) V4, official leaderboard, last updated 2026-04-12 on page. https://gorilla.cs.berkeley.edu/leaderboard.htmlLu et al., “ToolSandbox: A Stateful, Conversational, Interactive Evaluation Benchmark for LLM Tool Use Capabilities”, arXiv, revised 2025-04-16. https://arxiv.org/abs/2408.04682Barres et al., “tau^2-Bench: Evaluating Conversational Agents in a Dual-Control Environment”, arXiv, 2025-06-09. https://arxiv.org/abs/2506.07982Xiu et al., “ASTRA-bench: Evaluating Tool-Use Agent Reasoning and Action Planning with Personal User Context”, arXiv, 2026-03-02. https://arxiv.org/abs/2603.01357Chen et al., “ACEBench: Who Wins the Match Point in Tool Usage?”, arXiv, 2025-01-22, revised 2025-11-20. https://arxiv.org/abs/2501.12851Zhong et al., “ComplexFuncBench: Exploring Multi-Step and Constrained Function Calling under Long-Context Scenario”, arXiv, 2025-01-17. https://arxiv.org/abs/2501.10132Wang et al., “RAGEN: Understanding Self-Evolution in LLM Agents via Multi-Turn Reinforcement Learning”, arXiv, 2025-04-24. https://arxiv.org/abs/2504.20073Hao et al., “Reasoning through Exploration: A Reinforcement Learning Framework for Robust Function Calling”, arXiv, submitted 2025-08-07, revised 2025-10-10. https://arxiv.org/abs/2508.05118Zhong et al., “RC-GRPO: Reward-Conditioned Group Relative Policy Optimization for Multi-Turn Tool Calling Agents”, arXiv, 2026-02-03. https://arxiv.org/abs/2602.03025Chen et al., “EigenData: A Self-Evolving Multi-Agent Platform for Function-Calling Data Synthesis, Auditing, and Repair”, arXiv, 2026-03-05. https://arxiv.org/abs/2603.05553Rabinovich and Anaby-Tavor, “On the Robustness of Agentic Function Calling”, arXiv, 2025-04-01. https://arxiv.org/abs/2504.00914“Function calling”, OpenAI API documentation, accessed 2026-06-23. https://developers.openai.com/api/docs/guides/function-calling“Using tools”, OpenAI API documentation, accessed 2026-06-23. https://developers.openai.com/api/docs/guides/tools“MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits”, arXiv, 2025-04-04. https://arxiv.org/abs/2504.03767