Tool-R0：零数据也能训出工具调用高手——自进化LLM Agent的破局之路

论文标题：Tool-R0: Self-Evolving LLM Agents for Tool-Learning from Zero Data

作者：Emre Can Acikgoz, Cheng Qian, Jonas Hübotter, Heng Ji, Dilek Hakkani-Tür, Gokhan Tur

机构：University of Illinois Urbana-Champaign (UIUC)

论文链接：https://arxiv.org/abs/2602.21320

一句话总结：不用一条人工标注数据，通过"出题者"和"解题者"的自博弈强化学习，让小模型的工具调用能力超越使用数万条人工数据训练的方法。

🎯 这篇论文到底在解决什么问题？

大语言模型（LLM）越来越聪明，但有个致命短板：它们不会"用工具"。就像一个数学天才，心算很厉害，但不会用计算器——面对需要查天气、订机票、查数据库这类现实任务时，就抓瞎了。

为了让LLM学会调用工具（Tool Calling），目前主流做法是收集大量"人类示范数据"来做监督微调（SFT）。比如xLAM用了6万条、Hammer用了21万条人工标注数据。这就好比要教一个人开车，你得找几万个老司机录制驾驶视频给他看。

问题来了：这些数据贵、难标、而且覆盖面有限。更糟糕的是，模型学到的只是"模仿人类怎么调工具"，而不是"理解什么时候该调什么工具"。

Tool-R0 的思路很不一样：完全不用人工数据，让模型自己跟自己"对弈"来学会工具调用。这就像AlphaGo Zero——不看任何人类棋谱，纯靠左右互搏就成了围棋之神。

图1：Tool-R0整体框架

图1：Tool-R0 的核心理念——Generator（出题者）和 Solver（解题者）从同一个基础模型出发，在零人工数据的条件下通过自博弈循环共同进化。Generator 负责出题（合成有挑战性的工具调用任务），Solver 负责解题（学会正确调用工具），两者的能力在博弈中同步提升。

📖 背景知识：GRPO 和 Self-Play RL

在深入 Tool-R0 之前，先补两个前置知识。

GRPO：不需要"裁判"的强化学习

传统的强化学习（如PPO）需要训练一个额外的 Value Model 来评估每个状态的好坏，这个模型本身就很吃资源。DeepSeek 在 2024 年提出的 GRPO（Group Relative Policy Optimization） 另辟蹊径：对同一个问题采样一组回答（比如8个），然后用组内的相对排名来计算优势函数，而不是依赖外部裁判打分。

打个比方：PPO 像是每个考生都找了一个私人评委打分；GRPO 则是把一组考生的卷子放在一起比较——谁答得好谁就排在前面，省去了评委的成本。GRPO 的核心公式如下：

\[J_{GRPO}(\theta) = \mathbb{E}\_{q \sim P(Q)} \left[ \frac{1}{G} \sum_{i=1}^{G} \min\left( \frac{\pi_\theta(o_i|q)}{\pi_{ref}(o_i|q)} \hat{A}_i, \text{clip}(...) \hat{A}_i \right) - \beta D_{KL} \right]\]

其中 \(G\) 是每个问题的采样数量，\(\hat{A}_i\) 是归一化后的组内相对优势。这个方法在 DeepSeek-R1 的训练中大放异彩，也是 Tool-R0 的优化算法基础。

Self-Play：左右互搏的艺术

Self-Play（自博弈）在游戏AI领域早已证明了威力（AlphaGo Zero、OpenAI Five），核心思想是：让 agent 通过与自身或对手的对抗来提升能力，不需要外部专家数据。

在 LLM 领域，Self-Play 的应用还比较新。之前的工作如 SPIN（Self-Play Fine-Tuning）主要用于通用对话能力的提升。Tool-R0 把 Self-Play 带到了工具调用领域，而且设计了一个巧妙的"非对称博弈"：Generator 负责出题，Solver 负责解题，两者通过互补的奖励信号协同进化。

🏗️ Tool-R0 的方法设计：一场精心编排的"考试"

Tool-R0 的核心架构可以用一个类比来理解：想象一个自学考试系统，出卷老师和考生从同一个"白纸"状态出发，出卷老师不断学会出更有挑战性的题，考生不断学会解更难的题，两者共同成长。

图2：Tool-R0 详细流程

图2：Tool-R0 的完整训练流程。左侧的 Generator 根据任务规格（域、上下文类型、工具数、调用数）生成工具调用任务，经过格式/有效性/课程难度三重过滤后进入课程池；右侧的 Solver 从池中取任务进行推理和工具调用预测。Generator 的奖励包括格式、有效性和课程奖励，Solver 的奖励包括格式和准确率奖励。

两个角色：Generator 和 Solver

Generator（出题者） 和 Solver（解题者） 都从同一个预训练模型初始化（比如 Qwen2.5-1.5B-Instruct），但分别承担不同的职责：

  • Generator：给定一个轻量级的任务规格 \(s = (d, c, m, n)\)，生成完整的工具调用任务。其中 \(d\) 是领域（如"天气"、"旅行"）、\(c\) 是上下文类型（单轮/多轮对话）、\(m\) 是可用工具数量、\(n\) 是标准答案中的工具调用次数。
  • Solver：拿到 Generator 出的题，通过推理 + 工具调用来给出答案。

一个关键的设计决策是：Generator 和 Solver 必须用独立的权重。如果让同一个模型既出题又解题，就像让一个人自己给自己出考试卷——他会无意识地出自己擅长的题，导致能力停滞不前。后面的消融实验证实了这一点：共享权重会导致 36.41% 的性能下降。

任务规格：防止"偏科"的妙招

Generator 不是随便出题的，它需要根据任务规格 \(s = (d, c, m, n)\) 来出题。这些规格从哪来？直接从已有的工具库中采样：随机选一个领域、选几个工具、决定单轮还是多轮对话、调用几次工具。

这招非常关键。如果不加限制，Generator 很容易陷入"模式坍塌"（Mode Collapse）——反复出同一种类型的题。就像一个出卷老师如果不给考试大纲，可能每次都只出选择题。有了任务规格的约束，Generator 被迫覆盖不同领域、不同复杂度的任务。

Generator 的三层奖励

Generator 出的题需要满足三个条件：

1. 格式奖励 \(r_{fmt}\)：输出必须符合指定的 JSON 格式（包含 question、available_tools、gold_tool_calls 等字段）。这是基本门槛——卷子连格式都不对，当然不行。

2. 有效性奖励 \(r_{valid}\)：生成的工具调用必须"能跑"——函数名存在、参数类型正确、必需参数不缺。就像出的数学题，答案不能是负数人口。

3. 课程奖励 \(r_{curr}\)：这是最精妙的部分。题目不能太难也不能太简单，要恰好在 Solver 当前能力的边界上。

课程奖励的带通滤波器

怎么判断一道题难度是否"刚刚好"？Tool-R0 用了一个漂亮的带通滤波器设计。

对于 Generator 生成的每道题 \(\tau\)，用当前的 Solver 采样 \(K=8\) 次尝试，统计成功率 \(\hat{p}_{succ}\)。然后用带通滤波器来计算难度奖励：

\[r_{diff}(\hat{p}_{succ}) = \begin{cases} \exp\left(-\frac{(\hat{p}_{succ} - P_{low})^2}{2\sigma^2}\right) & \text{if } \hat{p}_{succ} \lt P_{low} \\\\ 1.0 & \text{if } P_{low} \leq \hat{p}_{succ} \leq P_{high} \\\\ \exp\left(-\frac{(\hat{p}_{succ} - P_{high})^2}{2\sigma^2}\right) & \text{if } \hat{p}_{succ} > P_{high} \end{cases}\]

其中 \(P_{low} = 0.25\)，\(P_{high} = 0.75\)，\(\sigma = 0.12\)。

图3：带通滤波器

图3：课程难度奖励的带通滤波器可视化。横轴是 Solver 的成功率，纵轴是难度奖励。绿色区域（成功率25%~75%）是"最佳难度区"，奖励为1.0；粉色区域（太难）和蓝色区域（太简单）的奖励按高斯衰减。

翻译成大白话：如果 Solver 8次尝试里有2~6次能做对（成功率25%~75%），这道题难度刚好，给满分奖励。如果8次全做对或全做错，说明太简单或太难了，奖励就衰减。

这个设计的精髓在于：它是动态适应的。随着 Solver 变强，以前"刚刚好"的题会变得"太简单"，Generator 就被迫去出更难的题——自动实现了课程学习（Curriculum Learning）。

Solver 的奖励：简单直接

Solver 的奖励就两个：格式奖励 \(r_{fmt}\) 和准确率奖励 \(r_{acc}\)。准确率奖励通过比较 Solver 预测的工具调用与 Generator 提供的标准答案来计算，使用函数名 + 参数的精确匹配。

自进化循环

整个训练过程按"迭代"进行：

  1. 用当前 Generator 生成一批任务，经三层过滤后入池
  2. 用当前 Solver 在池中的任务上做 GRPO 训练
  3. 用 Solver 在池中任务上的表现计算 Generator 的课程奖励
  4. 用三层奖励对 Generator 做 GRPO 训练
  5. 回到步骤1，开始下一轮迭代

每轮迭代后，Generator 学会出更合适的题，Solver 学会解更难的题，形成良性循环。

🧪 实验结果：零数据打败万条标注

实验设置

基座模型：Qwen2.5-0.5B/1.5B/3B-Instruct，以及 Llama-3.2-3B-Instruct。

评测基准：5个工具调用 benchmark——ToolAlpaca、SealTool、NexusRaven、API-Bank、SNIPS。

对比方法： - 通用模型：GPT-4o、Claude-3.5-Sonnet、Qwen2.5-72B 等闭源/大参数模型 - SFT 方法：xLAM（6万条数据）、Hammer（21万条）、ToolACE（1.2万条）、ToolRL（4千条）

主实验结果

论文的实验分两个维度：Table 1 展示 Tool-R0 在不同基座模型上相对于 base model 的提升；Table 2 展示 Tool-R0 与使用人工标注数据训练的 SFT 方法的直接对比。这里合并呈现核心数据：

Tool-R0 vs SFT Baselines（均基于 Qwen2.5-1.5B-Instruct）：

模型 训练数据 ToolAlpaca SealTool NexusRaven API-Bank SNIPS 平均
Qwen2.5-1.5B (base) 0 35.96 47.27 17.61 10.13 4.29 24.85
w/ xLAM 60k 51.75 69.05 38.68 34.65 23.85 43.60
w/ Hammer 210k 45.61 68.70 51.88 33.10 19.42 43.74
w/ ToolACE 12k 45.61 67.01 43.08 53.71 14.14 44.71
w/ ToolRL 4k 46.49 72.78 34.14 62.04 14.86 46.06
Tool-R0 (Ours) 0 47.36 83.00 34.59 50.62 20.86 47.84

这个结果相当惊人。来看几个关键数字：

  • Qwen2.5-1.5B 基座模型的平均准确率只有 24.85，工具调用能力接近"裸奔"。
  • 用了6万~21万条人工数据训练的 SFT 方法，平均在 43~46 分左右——确实比 base 模型强很多。
  • Tool-R0 不用一条人工数据，直接把平均准确率拉到 47.84，相对于 base 提升 92.52%，超过所有 SFT 方法。
  • 尤其在 SealTool 上，Tool-R0 达到了 83.00，比最好的 SFT 方法（ToolRL 的 72.78）还高出 10 个点以上。

一个 1.5B 的小模型，零数据训练后超越了用 21 万条标注数据训练的同参数模型——这说明工具调用能力的获取，关键不在数据量，而在训练方法的设计。

跨模型泛化

Tool-R0 不只在 Qwen 系列上有效。在 Llama-3.2-3B-Instruct 上，Tool-R0 把平均准确率从 36.12 提升到 40.47（+4.35pp，相对提升 12.04%）。虽然绝对增幅没有 Qwen 那么大，但考虑到 Llama-3.2-3B 的 base 模型本身已经比 Qwen2.5-1.5B 的 base 强不少（36.12 vs 24.85），提升空间本就有限。

模型 ToolAlpaca SealTool NexusRaven API-Bank SNIPS 平均
Llama-3.2-3B (base) 35.96 68.70 45.60 27.08 12.29 36.12
Tool-R0 (Llama-3.2-3B) 43.86 77.21 46.86 30.24 14.42 40.47

为什么 Tool-R0 能泛化得更好？

一个自然的疑问：SFT 方法用了那么多数据，为什么反而不如零数据的 Tool-R0？

作者做了一个数据相似度分析，答案令人恍然大悟：

图4：训练数据与测试集的相似度热力图

图4：不同训练数据集（xLAM、Hammer、ToolACE、Tool-R0）与5个测试基准之间的余弦相似度。Tool-R0 自动合成的数据在所有测试集上都保持了最高的相似度（0.423~0.532），说明自进化机制天然能生成分布更广泛、更贴近下游任务的训练数据。

Tool-R0 合成的训练数据与5个 benchmark 的相似度全面领先：ToolAlpaca 0.476、SealTool 0.474、NexusRaven 0.423、API-Bank 0.532、SNIPS 0.471。而人工标注数据集（xLAM 最高 0.456、Hammer 最高 0.434）的覆盖面明显不如。

原因在于：人工标注数据受标注者认知和偏好的限制，很容易集中在某些模式上。而 Tool-R0 的 Generator 受任务规格约束，被迫探索各种领域和复杂度的组合，天然形成了更均匀的分布。

🔬 消融实验：每个组件都不可或缺

架构设计的消融

配置 平均准确率 相对变化
Tool-R0 (完整版) 47.84 -
共享权重（Generator=Solver） 30.42 -36.41%
冻结 Generator（不训练） 41.65 -12.94%
去掉课程难度奖励 43.54 -8.99%

三个发现都很有说服力：

共享权重是灾难性的（-36.41%）。这验证了前面的直觉——自己给自己出题，会无意识地回避难题，导致能力天花板很低。

Generator 必须跟着一起进化（-12.94%）。如果把 Generator 冻结在初始状态，它出的题很快就会变得"太简单"，Solver 学不到新东西。

课程难度奖励很有用（-8.99%）。没有带通滤波器来引导难度，Generator 倾向于出两极化的题——要么太简单全做对，要么太难全做错——两种情况下 Solver 都学不到东西。

自进化迭代的效果

图5：不同模型规模的自进化迭代曲线

图5：三种模型规模（Qwen2.5-0.5B/1.5B/3B）在多轮自进化迭代中的平均准确率变化。所有模型在第1轮迭代后都有一个巨大的跳跃，之后增长趋于平缓。1.5B 模型在第3轮迭代左右达到峰值（约48分），3B 模型持续到第5轮（约51分），0.5B 在第3轮达到峰值（约30.5分）后略有下降。

有意思的是，大部分收益来自第1轮迭代——这说明从"完全不会用工具"到"基本会用工具"的跨越，不需要太多轮训练。后续迭代更多是在打磨边角 case。

另一个有趣的观察：0.5B 模型在第3轮后开始轻微下降，这可能是因为模型容量太小，更多的训练反而导致了过拟合或灾难性遗忘。这暗示 Tool-R0 对模型规模有一个下限要求——太小的模型可能"脑容量"不够，撑不住持续进化。

📊 深度分析：Tool-R0 作为中间训练阶段

Tool-R0 和 SFT 并不是非此即彼的关系。作者尝试了一个"先 Tool-R0 再 SFT"的组合策略：

图6：中间训练策略效果

图5：中间训练（Mid-Training）策略的效果。Base模型直接SFT达到44.6分；而先经过Tool-R0训练1~3轮迭代，再做SFT，最终达到48.1分——比纯SFT高出3.5个百分点，比Base模型总共提升了25.0个百分点。

策略 平均准确率
Base (Qwen2.5-1.5B) 23.4
SFT only 44.6
Tool-R0 Iter-1 + SFT 45.6
Tool-R0 Iter-2 + SFT 47.1
Tool-R0 Iter-3 + SFT 48.1

这说明 Tool-R0 可以作为一种"预热"训练：先让模型通过自博弈建立工具调用的基本能力和推理模式，然后再用少量高质量人工数据做精调。这个套路其实跟 DeepSeek-R1 的思路异曲同工——先用 RL 建立推理能力，再用 SFT 打磨格式和质量。

🔧 训练动态：Generator 和 Solver 的"军备竞赛"

图7：训练过程中的奖励动态

图6：6个子图展示了3轮自进化迭代中 Generator 和 Solver 的奖励变化。可以看到：Generator 的总奖励在每轮迭代中稳步上升（学会出更好的题）；Solver 的准确率奖励也在上升（学会解更多题）；课程奖励的波动反映了 Generator 不断调整出题难度以适应 Solver 的当前水平。

训练动态图揭示了几个有趣的模式：

  1. Generator 的格式奖励最先收敛——学会"按格式出题"是最简单的任务
  2. 有效性奖励随后跟上——学会出"能跑通"的题稍微难一些
  3. 课程奖励波动最大——因为这个奖励依赖 Solver 的实时水平，而 Solver 也在不断变化，所以始终在动态调整

这种动态平衡很像生物进化中的"红皇后效应"：猎物跑得更快了，捕食者就得跑得更快；出题者出的题更难了，解题者就得变得更强。

📉 错误分析：Tool-R0 到底修复了什么？

图8：错误类型分析

图7：Base 模型和 Tool-R0 在三种错误类型上的对比。结构性错误（Structural）从约99降到约52——大幅减少了"完全不知道怎么调工具"的情况；语义错误（Semantic）从约70降到约55——对工具参数的理解也有提升；格式错误（Format）从约13降到约5——格式问题基本解决。

错误分析的结果很直观：

  • 结构性错误（调了不存在的函数、参数结构完全错误）减少了约48%——这是最大的改善方向，说明 Tool-R0 帮模型建立了"工具长什么样"的基本认知
  • 语义错误（函数调对了但参数值不对）减少了约21%——这部分更难，因为涉及对任务语义的深层理解
  • 格式错误（JSON 格式不合规）减少了约62%——GRPO 的格式奖励在这方面功不可没

不过，语义错误的降幅相对较小，这也指出了 Tool-R0 的一个改进方向：当前的准确率奖励是二元的（对或错），没有细粒度地区分"差一点对"和"完全离谱"。如果引入更精细的 reward shaping，语义理解可能还能更进一步。

💡 我的思考和启发

这篇论文最打动我的地方

零数据 > 万条数据这个结论，表面上反直觉，但细想其实很合理。人工标注数据的问题不在于数量少，而在于分布偏——标注者倾向于构造自己熟悉的、常见的场景，导致训练数据和测试数据之间存在分布 gap。Tool-R0 的 Generator 被任务规格驱动着去探索各种组合，天然就形成了更好的覆盖。

这给我一个启发：在 LLM 训练中，数据的多样性可能比数据的数量更重要。与其花大力气标注更多同质化的数据，不如设计更好的数据生成机制来覆盖长尾分布。

工程落地的思考

如果要在生产环境中使用 Tool-R0，我觉得有几个值得注意的点：

  1. 训练成本不算高。作者用了 8 台 A100-80G，每轮迭代大约 3-4 小时，5 轮迭代总共不到 1 天。相比标注 6 万条数据的人力成本，这个计算成本相当划算。

  2. 最佳实践可能是 Tool-R0 + 少量 SFT。中间训练实验已经证明了这条路的可行性：先用 Tool-R0 "预热"，再用几百条高质量标注数据做精调，可能是性价比最高的方案。

  3. 工具库的质量是前提。Tool-R0 的 Generator 依赖工具库来生成任务规格，如果工具库本身定义不清（比如参数描述模糊、功能重叠），Generator 生成的任务质量也会受影响。

局限性

说几点我看到的不足：

  • 评测覆盖面有限。5 个 benchmark 都偏向"单轮工具调用"，缺少多步推理、多工具组合使用的复杂场景。真实世界的 tool-use 往往需要"先查 A，再用 A 的结果调 B"这种链式调用，当前评测没有覆盖。

  • Generator 生成的"标准答案"可能有噪声。Generator 自己出题自己给答案，这个答案的质量依赖 Generator 的能力——但 Generator 本身也在学习中。虽然有效性奖励能过滤掉格式错误的答案，但语义层面的错误（比如参数值不合理）可能逃过检测。

  • 缺少与 R1-style RL 方法的对比。论文发表时 DeepSeek-R1 和相关的推理 RL 方法正当红，但 Tool-R0 没有与这些方法做直接对比。考虑到 Tool-R0 也使用 GRPO，如果在同样的工具调用任务上与 R1-style 的纯 Solver RL（不要 Generator，直接在固定数据集上做 GRPO）对比，会更有说服力。

🔗 相关工作对比

方法 数据需求 训练方式 核心特点 局限
xLAM 60k 人工数据 SFT 大规模标注 数据成本高，分布受限
Hammer 210k 人工数据 SFT 最大规模标注 更多数据未带来显著提升
ToolACE 12k 人工数据 SFT 自动化生成+人工校验 仍需人工介入
ToolRL 4k 人工数据 SFT + RL 少量数据+强化学习 依赖初始标注质量
Tool-R0 0 Self-Play RL 零数据自进化 Generator 标准答案可能有噪声

📝 总结

Tool-R0 证明了一个令人振奋的观点：LLM 的工具调用能力可以通过纯自博弈强化学习来"无中生有"。不需要一条人工标注数据，通过 Generator-Solver 的协同进化，1.5B 参数的小模型就能超越使用多达 21 万条人工标注数据训练的同参数 SFT 方法。

这项工作的启示远不止工具调用领域。它展示了一种更通用的范式：用自博弈机制替代人工数据收集，让 LLM 在自我对抗中学会新技能。从 AlphaGo Zero 到 DeepSeek-R1 再到 Tool-R0，这条"无师自通"的路线正在从游戏、推理延伸到更广阔的 AI Agent 能力构建。

如果你正在做 LLM 工具调用相关的工作，这篇论文非常值得细读——特别是课程难度奖励的带通滤波器设计和 Generator-Solver 非对称博弈的架构，都是可以直接借鉴的好思路。