Tool-Star: Empowering LLM-Brained Multi-Tool Reasoner via Reinforcement Learning

Paper: arXiv:2505.16410 Code: dongguanting/Tool-Star Code reference: main @ df08f67a (2026-04-03)

0. 阅读定位

一句话：Tool-Star 把“会调用单个工具”的 Tool-Integrated Reasoning 推到“可在推理链中协调搜索、浏览器和 Python”的多工具 RL 后训练框架，并用数据合成、课程式筛选、层级奖励和 self-critic 偏好训练来稳定这个过程。
核心新意：它不是只给模型一个工具调用 prompt，也不是只蒸馏强模型轨迹，而是把工具反馈放进 roll-out 环境，再把答案正确性、格式合法性、多工具协同奖励组合成可执行 reward，并周期性用模型自己的 roll-out 生成偏好对来内化 reward 原则。
适用场景：需要同时查资料和算数/写代码的复杂问答、数学推理、开放域多跳问答、Web exploration，以及需要把工具调用可靠性纳入 RL 目标的 agentic LLM 后训练。
分类判断：主贡献是 LLM 后训练中的 multi-tool RL 训练算法与数据管线，因此放入 LLM & VLM/RL & Post-Training，而不是单纯 Agent 应用或检索增强。

1. 论文要解决的问题

现有 TIR 方法常见三类：prompting-based、SFT-based、single-tool RL-based。
Prompting 方法部署快，但工具调用时机、格式和纠错能力不稳定。
SFT 方法依赖高质量演示轨迹，容易学到“别人怎么调用工具”，但未必会在新问题上主动探索。
Single-tool RL 方法可通过 outcome reward 鼓励探索，却通常只围绕搜索或代码解释器之一优化。
真实复杂任务往往需要同时具备信息检索、网页解析、数学计算、代码执行和结果验证。
论文把这个缺口表述为 multi-tool collaborative reasoning：模型在同一条逐步推理链中选择多个外部工具，并利用实时工具反馈继续生成。
关键难点一是 rationality and efficiency of tool usage：工具越多越容易乱用、重复用、用错格式或浪费调用预算。
关键难点二是 multi-tool collaboration：搜索结果可能需要 Python 处理，Python 失败可能需要 debug，长推理链可能需要压缩，单一 reward 很难表达这些交互。
关键难点三是 数据稀缺：公开数据大多是 language-only QA 或单工具轨迹，很少有“合理地混合搜索和代码”的多工具推理链。
关键难点四是 训练稳定性：工具输出会进入上下文，但不应该被策略模型当作自己生成的 token 参与 loss，否则容易出现 reward hacking 或把外部结果当作可优化文本。

2. 方法总览

Tool-Star 由两个大部件构成。
第一部分是 Tool-Integrated Reasoning Data Synthesis Pipeline，负责从 language-only 数据和少量已有 TIR 数据中生成、过滤、分级工具轨迹。
第二部分是 Two-stage Multi-tool Collaborative Training Framework，先用冷启动 SFT 建立基本工具能力，再用 Multi-Tool Self-Critic RL 做困难样本上的策略对齐。
训练期核心工具是 Search Engine、Web Browser Agent、Code Interpreter。
推理期可靠性工具是 Code Debugger、Tool-Use Backtracer、Reasoning Chain Refiner。
论文里的“六种工具”不是六个同等训练动作，而是三种可被模型主动调用的外部能力加三种失败恢复/推理期优化机制。
模型在输出中用 <search>...</search>、<python>...</python>、<result>...</result>、<answer>...</answer> 等特殊标记组织工具调用和答案。
工具反馈 F^T 会动态拼接回 reasoning chain，使后续 token 条件化在历史工具结果上。
训练时会遮蔽工具返回结果，不让工具输出 token 进入策略 loss。
这个遮蔽设计很关键，因为 reward 应该优化“何时调用、如何提问、如何利用反馈”，而不是优化外部检索/执行器本身返回的文本。

2.1 问题形式化

输入是任务 query q 和工具集合 T。
模型在工具集成指令 I^T 约束下生成 reasoning chain R^c 和最终答案 y。
reasoning chain 的每一步都可以依赖此前的工具反馈 {F^T}_{<t}。
这意味着推理不是一次性 completion，而是“生成工具请求 → 执行工具 → 插回结果 → 继续生成”的闭环。
从概率分解看，论文把过程拆成两部分：多工具集成 reasoning token 的生成，以及最终 answer token 的生成。
这个形式化的意义在于：工具调用不是后处理，而是策略分布的一部分。
因此 RL 可以直接优化策略在工具调用标记、问题分解、调用顺序、最终答案上的行为。
也因此 reward 必须同时约束格式、答案和工具协作，否则策略会朝单一可钻空子的方向收敛。

2.2 工具设计

Search Engine：执行搜索 query，支持本地 Wikipedia 检索和 web search。
Web Browser Agent：访问搜索结果 URL，解析网页、清洗正文、提取与 query 相关的信息，再把摘要返回给推理链。
Code Interpreter：在沙箱中执行模型生成的代码片段，返回 stdout 或错误信息。
Code Debugger：当 Python 代码语法或运行失败时，使用原代码和 compiler/runtime error 生成修复后的代码。
Tool-Use Backtracer：当工具调用无效或 debug 失败时，回退到工具调用前的 reasoning step，让模型重走路径。
Reasoning Chain Refiner：当工具输出导致上下文过长时，压缩和重组推理链，删去冗余信息后继续推理。
训练工具负责提供能力，推理期工具负责提高鲁棒性。
这种拆分避免把所有失败恢复都塞进 RL reward，也让推理时可以用工程机制兜底。
但这也说明 Tool-Star 的效果并不只来自模型权重，系统级工具执行器和失败恢复代码同样是性能的一部分。

2.3 数据合成：Step 1 数据收集与采样

论文先收集约 90K language-only reasoning 数据 D_text 和约 1K 已有 TIR 数据 D_tool。
数据来源覆盖 NuminaMath、HotpotQA、2WikiMultihopQA、SimpleDeepSearch、WebWalker 等。
作者强调对 language-only 数据只使用 query，不依赖原数据中强模型生成的 reasoning chain。
第一个采样策略是 TIR Prompting-based Sampling。
模型在 tool-integrated prompt I^T 下对 D_text 中 query 生成响应。
生成过程中若出现 <search> 或 <python>，系统解析请求、调用外部工具、再把 <result> 插回上下文。
这个循环直到达到最大工具调用次数、长度上限或生成 <answer>。
之后只保留答案正确的样本，得到 D_tool^P。
第二个采样策略是 Hint-based Sampling。
先让模型对 query 做 language-only reasoning。
然后插入两类 hint：Logical Verification 和 Answer Reflection。
Logical Verification 会替换 reasoning chain 中类似 “maybe”、“wait”、“not sure” 的不确定表达，诱导模型调用工具验证。
Answer Reflection 会在答案之后插入 hint，诱导模型用工具反查或校验答案。
插入 hint 后截断原 reasoning chain，让模型从 hint 位置继续进行 tool-augmented reasoning。
只保留答案正确的 hint 轨迹，得到 D_tool^H。
最终把 prompt-based 和 hint-based 两类 TIR 数据合并成初版 D_tool^v1。

2.4 数据合成：Step 2 工具使用质量归一化

论文不是简单地把所有正确轨迹都拿去训练。
直觉上，答案正确但工具调用明显过多、格式混乱或调用无关工具的轨迹会误导模型。
所以 Step 2 做 Tool-Use Quality Normalization。
论文源码与附录说明会对工具调用频率设置阈值，附录给出的工具调用频率阈值 β=5。
这一阶段目标是过滤 unreasonable tool-use samples。
被保留下来的样本形成更干净的 D_tool^v2。
这个步骤的意义是把“能解题”与“合理用工具”区分开。
如果没有这一步，SFT 会模仿大量冗余工具调用，RL 初始策略会更难稳定。
该步骤也为后续 difficulty-aware 分类提供基础，因为分类依赖 direct reasoning 和 TIR 的相对成功/失败。

2.5 数据合成：Step 3 难度感知分类

作者先对 D_tool^v2 中每个问题跑一次 language-only direct reasoning，得到 D_text^v2。
然后根据 DR 和 TIR 是否正确，把样本分成四类。
类别 1 和类别 2 中，模型不借助工具也能做对，因此工具使用被视作不必要。
这两类从 direct reasoning 结果中抽取，形成 D_text^sub。
类别 3 中，TIR 正确而 DR 不正确，说明工具带来了明确收益。
类别 3 从工具轨迹中抽取，形成 D_tool^sub。
D_text^sub 与 D_tool^sub 合并成冷启动 SFT 数据 D_tool^SFT。
类别 4 是 DR 和 TIR 都困难的样本。
类别 4 被保留给 RL 阶段，形成 D_tool^RL。
这个 curriculum 设计的核心是：先让模型学会基本工具格式和简单收益，再把难题交给 RL 探索。
附录给出的最终数据量是约 54K cold-start 样本和约 10K RL 困难样本。

2.6 两阶段训练：Cold-Start SFT

Cold-Start SFT 在 D_tool^SFT 上训练 backbone。
论文主表使用 Qwen2.5-3B-Instruct 和 Llama3.2-3B-Instruct 作为基础模型。
SFT 目标是标准自回归负对数似然：最大化训练轨迹中目标回答 y_i 在输入 x_i 下的概率。
这个阶段不追求最优探索，而是让模型掌握工具标记、工具反馈位置、答案格式和基本调用模式。
直觉上，若直接从 instruction model 做多工具 RL，策略空间太大，roll-out 里大量样本会因格式错误或工具调用失败得到负 reward。
Cold-start 先把策略推到“能输出可执行工具调用”的区域，降低 RL 的稀疏性。
附录训练设置：约 54K 样本，学习率 7e-6，batch size 128，weight decay 0.1，训练 3 epoch。
训练使用 DeepSpeed ZeRO-3、FlashAttention2、bf16，最大输入长度 4096。

2.7 两阶段训练：Multi-Tool Self-Critic RL

RL 阶段从 cold-start 模型 π̂_θ 出发，在 D_tool^RL 的困难样本上 roll out。
Roll-out 时使用多工具调用指令，模型生成 <search>、<python> 等特殊标记后，系统自动执行对应工具。
工具请求与输出会被缓存成 memory mapping。
如果同一个工具请求重复出现，可以直接从 memory 取结果，减少搜索和执行开销。
优化算法采用 GRPO。
GRPO 用同一 query 的一组 roll-out 估计 baseline，不显式训练 critic。
论文的 GRPO 目标包含 clipped ratio 项和 KL 项。
附录与代码都把 KL 系数设为 0，因此主要依靠 group-relative advantage 和 reward 约束。
每个训练样本 roll out 8 条响应。
论文附录说总 batch size 128、mini-batch size 16、最大输出长度 4096、最大训练期工具调用次数 3、RL 训练 2 epoch、8 张 A800。
当前公开训练脚本 Tool_Star_RL/scripts/train/train.sh 也显示 algorithm.adv_estimator=grpo、algorithm.kl_ctrl.kl_coef=0.0、rollout.n=${ROLLOUT_N}、reward_model.reward_manager=${REWARD_MANAGER}。
注意：论文附录中 RL 学习率写作 “8”，这很可能是排版或科学计数法缺失；公开脚本实际把 actor_rollout_ref.actor.optim.lr 设为 1e-6。
笔记中应把论文数值和代码数值分开记录，避免把疑似笔误自动修正成不存在的事实。

2.8 层级奖励设计

Tool-Star 的 reward 有三个层级：格式、答案正确性、多工具协作。
如果格式错误，reward 为 -1。
如果格式正确但答案分数为 0，reward 为 0。
如果格式正确且答案分数大于 0，reward 至少为答案准确分。
当答案和格式都正确，并且 reasoning chain 同时出现 <search> 和 <python>，额外给多工具奖励 r_M=0.1。
因此总 reward 可理解为 max(Acc + r_M, Acc)，其中 r_M 只在 search 与 python 同时出现时为 0.1。
这个设计不是鼓励无条件多工具调用。
只有在答案已经正确、格式已经正确的前提下，多工具协作才获得额外奖励。
这样能避免模型为了 0.1 奖励盲目调用两个工具却牺牲准确性。
公开代码 Tool_Star_RL/src/verl/verl/utils/reward_score/re_search.py 的实现与论文一致：格式校验失败返回 -1，答案 F1 大于 0 且同时含 </search> 与 </python> 时把 F1 加 0.1。
数学任务的 re_search_math.py 还会检查 boxed answer，并使用等价性判断来给数学答案打分。
reward manager ReSearchRewardManagerWithSave 只在 response 最后一个有效 token 位置写入标量 reward，符合 PPO/GRPO 中 sequence-level reward 的常见实现。

2.9 Self-Critic DPO

论文认为多工具 RL 的 reward 结构复杂，模型不一定能从标量 reward 中快速理解“什么行为被奖励”。
因此作者引入 self-critic reward fine-tuning。
流程从 D_tool^RL 中 rejection sampling 出 k 个样本，构成 D_tool^S。
对每个 query，RL initialized model π_θ^RL 自采样 n 个候选 response。
可执行的层级 reward 函数给每个 response 自动打分。
每个样本输出包含候选 response、reasoning trace 和 reward score。
reward 大于等于 1 的样本作为 positive，reward 小于 1 的样本作为 negative。
这些样本形成 preference dataset (x, y_w, y_l)。
模型再用 DPO objective 提高 preferred response 的 log-prob，降低 dispreferred response 的 log-prob。
参考模型固定为 self-critic 开始时的 π_θ^RL。
附录给出的 Self-Critic DPO 设置：学习率 5e-7、cosine scheduler、0.1 warmup、global batch size 64、sigmoid loss、beta 0.3、2 epoch、bf16、最大上下文 4096。
self-critic 每 0.5 个 RL epoch 触发一次，大约每 50 steps，然后用 DPO 后模型继续 vanilla RL。
直觉上，这相当于把 rule-based reward 从“外部打分器”转成一批显式偏好示范，让模型学会 reward 的文本化原则。
这个机制尤其适合多工具情形，因为同样正确的答案可能因工具格式、工具协作方式、长链管理不同而有不同 reward。

2.10 多工具协同推理

推理时模型仍按工具集成形式生成。
可主动使用的工具是 search engine、web browser agent、Python interpreter。
若 Python 执行失败，Code Debugger 会根据原代码与错误信息生成修复代码。
若工具调用失败或 debug 失败，Backtracer 会定位到工具调用前的陈述并回滚。
若上下文过长，Chain Refiner 会压缩冗余推理，保留必要状态继续生成。
公开 evaluation/run.py 中默认 max_python_times=3、max_search_times=3、max_debug_times=1、max_refine_times=1、max_rollback_times=1。
代码中 Python 执行成功时会把结果包进 <result>...</result>，失败时根据配置选择直接写入错误、debug 或 rollback。
搜索失败时也可以触发 rollback，成功时把 deep_search 或 local batch search 的结果写回 <result>。
这说明 Tool-Star 的推理框架是一个小型工具调度器，不是单纯调用 LLM API。
实际复现时，工具服务、Bing API、本地 Wikipedia 检索服务、Python 沙箱和 vLLM 服务都可能影响最终指标。

3. 实验设计

评估覆盖两大类 reasoning 数据集。
Computational reasoning 包括 AIME2024、AIME2025、MATH500、GSM8K、MATH。
Knowledge-intensive reasoning 包括 WebWalker、HotpotQA、2WikiMultihopQA、MuSiQue、Bamboogle。
额外 deep web exploration 评估包括 GAIA 和 HLE。
数学任务用 exact match 或等价性评估。
开放域 QA 任务用 token-level F1。
论文还提出 Tool-use Efficiency 指标 TE，用于衡量正确性与工具调用成本之间的关系。
Baseline 覆盖 backbone、单工具 RL、RAG、Search-o1、Search-R1、多工具 prompting 和 ReCall。
主表中所有 baseline 以 Qwen2.5-3B-Instruct 为 backbone；缺少 3B instruct 版本的 baseline 由作者按开源代码参数复现。
对知识密集任务中的 code-assistant model，作者报告 RAG top-5 docs 设置以保证公平。
主结果关注两个问题：Tool-Star 是否比单工具/多工具 prompt 更通用，以及它是否能在数学和知识任务之间保持均衡。

3.1 主结果：10 个 reasoning task

Qwen2.5-3B-Instruct backbone 平均分为 26.1。
Llama3.2-3B-Instruct backbone 平均分为 21.7。
单工具计算型 ToRL 平均 37.8，在 AIME24、MATH500、GSM8K、MATH 上很强，但知识任务较弱。
搜索型 Search-R1 在 HQA 和 Bamboogle 较强，但计算任务下降明显，平均 25.7。
Multi-Tool Prompting 平均 23.4，说明只靠 prompt 打开多个工具并不足以稳定提升。
ReCall 平均 39.1，是强 multi-tool baseline。
Tool-Star(Qwen2.5-3B) 平均 46.1，是主表第一。
Tool-Star(Llama3-3B) 平均 41.0，是主表第二。
Qwen 版 Tool-Star 在 AIME24=20.0、AIME25=16.7、MATH500=72.0、GSM8K=85.0、MATH=82.6。
Qwen 版 Tool-Star 在 WebWalker=20.8、HQA=51.9、2Wiki=40.0、MuSiQ=19.3、Bamboogle=52.5。
Llama 版 Tool-Star 在 WebWalker=24.0、2Wiki=43.2、Bamboogle=54.7 上也很强。
论文的关键结论不是某个单项全赢，而是平均性能和跨域稳健性最好。
这与方法设计一致：搜索和代码工具都被纳入 reward，但单工具偏科 baseline 往往在另一类任务上退化。

3.2 Deep web exploration：GAIA/HLE

GAIA 上 Tool-Star 得到 15.5，优于 Search-R1 的 9.7、ToRL/RAG 的 8.7、多工具 prompting 的 5.8。
HLE 上 Tool-Star 得到 8.0，略高于 Search-R1 的 7.8 和 Qwen backbone 的 7.4。
GAIA 的提升更明显，因为它常需要网页探索和信息整合。
HLE 的绝对提升较小，可能因为任务覆盖极宽、外部知识不稳定、评分更难。
这个结果支持论文关于“多工具协作更适合深网探索”的论点。
但 HLE 的小幅提升也提醒我们，Tool-Star 不是万能搜索 agent；底层检索质量、浏览器摘要质量和任务本身难度仍然是瓶颈。

3.3 消融实验

完整 Tool-Star(3B) 在 HQA/Bamboogle/GSM8K/MATH 上分别为 51.9/52.5/85.0/82.6。
去掉 Cold-Start 后变成 43.5/40.8/77.8/74.2，四项都下降，Bamboogle 降 11.7，HQA 和 MATH 都降 8.4。
去掉 RL stage 后变成 47.5/43.9/80.2/78.4，说明 SFT 能建立工具能力，但泛化和困难样本处理不足。
去掉 Reward 后变成 50.4/50.3/83.1/80.2，下降较小但稳定存在。
去掉 Self-Critic 后变成 49.8/48.3/82.8/77.8，MATH 和 Bamboogle 下降更明显。
消融说明两个训练阶段互补。
Cold-start 对基础工具行为最关键。
RL stage 对困难样本和泛化能力重要。
层级 reward 和 self-critic 都是增益组件，但增益幅度小于两阶段训练本身。
如果资源有限，优先保证高质量 SFT 数据和标准 GRPO；如果追求最后几分，再加入 self-critic DPO。

3.4 工具效率与推理期工具分析

Figure 4 左侧比较 TIR 方法的 tool-use efficiency。
Tool-Star 的核心主张是正确率提升的同时不依赖无限工具调用。
Figure 4 中部和右侧分析 inference-time tools 对 DotaMath 与 Tool-Star 的影响。
论文称 inference-time tool 优化能减少工具使用错误，并提升性能。
DotaMath 在 GSM8K 上的提升超过 20%，因为它原本 coding 能力较弱，debug/backtrace/refiner 的空间更大。
Tool-Star 的增益较小，因为 RL 后模型本身更少出现工具相关错误。
这表明推理期工程机制更像弱工具模型的补丁，而不是替代 RL 训练。
对已训练好的 Tool-Star，推理期工具主要提升鲁棒性和失败恢复。

3.5 参数规模与训练曲线

论文展示 Qwen2.5 0.5B、1.5B、3B 等规模的训练曲线。
观察重点包括 reward、response length 和 validation score 的变化。
训练曲线用于证明 Tool-Star 在不同参数规模下都能获得 RL 增益。
小模型更依赖工具和格式约束，大模型更容易在已有 reasoning 能力基础上学会工具协作。
但曲线也提示：response length 随训练变化，长推理链并不必然代表更好工具使用。
因此 reward 设计需要同时控制答案、格式和工具协作，而不是只看长链。

3.6 Tool-call masking

Tool-call masking 是本文非常实用的细节。
训练中工具返回结果被插入上下文，但这些结果不是策略模型生成的。
如果把工具结果也纳入 loss，模型可能被迫拟合检索器或 Python executor 的输出。
附录中作者报告：去掉 masking 会让 reward 快速崩到 -1，并出现持续 strategy hacking。
这个发现与部分单工具 RL 工作不同。
作者推测多工具场景中工具输出更复杂、组合更多，因此不 mask 更容易污染策略更新。
公开训练代码的 roll-out 和 reward 文件也表明，奖励只在响应最后 token 写入，而工具结果作为上下文反馈存在。
复现时应检查 trainer 是否正确区分 model-generated tokens、tool request tokens 和 tool output tokens。

4. 代码搜索与实现映射

Code reference: main @ df08f67a (2026-04-03)

Paper Concept	Source File	Key Class/Function
RL 训练入口	`Tool_Star_RL/scripts/train/run_tool_star.sh`	调用 `train.sh`，设置 `rollout_n=8`、prompt template、train/test parquet
GRPO trainer 配置	`Tool_Star_RL/scripts/train/train.sh`	`python3 -m verl.trainer.main_ppo`，`algorithm.adv_estimator=grpo`
KL 与 rollout 设置	`Tool_Star_RL/scripts/train/train.sh`	`algorithm.kl_ctrl.kl_coef=0.0`，`actor_rollout_ref.rollout.name=vllm_with_search`
Reward manager	`Tool_Star_RL/src/verl/verl/workers/reward_manager/re_search.py`	`ReSearchRewardManagerWithSave.__call__`
知识类 reward	`Tool_Star_RL/src/verl/verl/utils/reward_score/re_search.py`	`validate_format`、`extract_answer`、`compute_score`
数学类 reward	`Tool_Star_RL/src/verl/verl/utils/reward_score/re_search_math.py`	`correctness_score_default`、`correctness_score_v2`、`compute_score`
推理期主循环	`evaluation/run.py`	`LLM_Inference` 初始化与工具调用循环
Python executor	`evaluation/python_executor.py`	`PythonExecutor.execute`、`PythonExecutor.apply`
搜索工具	`evaluation/tools/web_search_main.py`	`deep_search`
代码修复	`evaluation/tools/debug_code.py`	`debug_code_function`
工具失败回退	`evaluation/tools/rollback_code.py`	`rollback`
长链压缩	`evaluation/tools/refine_code.py`	`refine`
本地检索服务	`evaluation/search/host_wiki.py`	Wikipedia 检索服务启动逻辑
SFT 框架	`LLaMA-Factory-main/src/train.py`	LLaMA-Factory 训练入口

4.1 代码仓库状态

代码仓库公开可访问，URL 为 https://github.com/dongguanting/Tool-Star。
本次锚定的本地 clone 是 main@df08f67a，提交日期 2026-04-03。
README 已包含 2026 年 SIGIR 版本和后续 ARPO/AEPO 新闻，因此它不是论文 2025 arXiv v1 的静态快照。
这份笔记以 arXiv:2505.16410 的 paper 内容为主，以当前公开代码解释可复现实现。
README 释放了 Tool-Star-Qwen-0.5B、1.5B、3B、7B checkpoint 和 Tool-Star-SFT-54K、Multi-Tool-RL-10K 数据链接。
RL 代码基于 VERL 和 ReCall。
SFT 阶段依赖 LLaMA-Factory。
推理评估代码位于 evaluation/，训练代码位于 Tool_Star_RL/。
仓库还包含 search_cache_1k.json、本地 search 配置、FlashRAG 相关检索模块。
复现时必须单独配置 Bing search API、本地 Wikipedia search URL、vLLM 服务和模型路径。

4.2 Reward 伪代码

def tool_star_reward(response, ground_truth):
    ok, reason = validate_format(response)
    if not ok:
        return -1
 
    answer = extract_boxed_answer(response)
    acc = evaluate_answer(answer, ground_truth)
 
    if acc == 0:
        return 0
 
    multi_tool_bonus = 0.1 if ("</search>" in response and "</python>" in response) else 0.0
    return max(acc + multi_tool_bonus, acc)

这个伪代码对应论文公式和 reward_score/re_search.py。
validate_format 会检查 <think>、<search>、<python>、<result>、<answer> 是否成对且顺序正确。
<search> 或 <python> 后必须出现对应 <result>。
<answer> 需要包含 \boxed{}。
知识 QA reward 用 token-level F1。
数学 reward 用 boxed answer 和等价性验证。
多工具奖励只看 response 中是否同时包含搜索和 Python 工具结束标记。
实现上 bonus 是在答案 F1 大于 0 时加 0.1。
这和论文中的 r_M 一致，但代码层面更具体地绑定到标签字符串。

4.3 推理工具循环伪代码

while sample_is_generating:
    model_continues_text()
 
    if new_text_contains_python_call and python_rounds < 3:
        code = extract_python_content(new_text)
        result, report = PythonExecutor.apply(code)
        if report == "Done":
            append_result(result)
        elif use_debug and debug_rounds < 1:
            fixed_code = debug_code_function(code, report)
            retry_python(fixed_code)
        elif use_rollback and rollback_rounds < 1:
            rollback_to_before_tool_call()
        else:
            append_result(report)
 
    if new_text_contains_search_call and search_rounds < 3:
        query = extract_search_content(new_text)
        try:
            result = deep_search(query)
            append_result(result)
        except Exception:
            rollback_or_append_empty_result()
 
    if context_length_exceeds_limit and use_refiner:
        concat_prompt_output = refine(concat_prompt_output)
 
    if answer_tag_complete:
        stop_and_extract_final_answer()

这个流程对应 evaluation/run.py。
默认最多 3 次 Python、3 次搜索、1 次 debug、1 次 refine、1 次 rollback。
Python executor 会拒绝包含 input( 或 os.system( 的代码片段，降低执行风险。
推理中所有工具结果都以 <result> 写回模型上下文。
Debugger、Backtracer、Refiner 都是推理期工程模块，而非训练期 reward 本身。
如果这些模块不可用，论文指标可能无法直接复现。

4.4 GRPO 训练配置伪代码

python3 -m verl.trainer.main_ppo \
  algorithm.adv_estimator=grpo \
  algorithm.kl_ctrl.kl_coef=0.0 \
  data.train_batch_size=128 \
  data.max_prompt_length=1536 \
  data.max_response_length=4096 \
  actor_rollout_ref.actor.optim.lr=1e-6 \
  actor_rollout_ref.rollout.name=vllm_with_search \
  actor_rollout_ref.rollout.n=8 \
  reward_model.reward_manager=re_search

公开脚本默认 prompt key 是 question。
默认 prompt template 是 re_search_template_sys。
默认 MAX_RESPONSE_LENGTH=4096 与论文附录一致。
train.sh 默认 PPO_MINI_BATCH_SIZE=128，但 run_tool_star.sh 和 README 示例传入 --ppo_mini_batch_size 16。
论文附录给出的 mini-batch size 是 16，因此复现应以 launch script 参数为准，而不是只看 train.sh 默认值。
公开脚本默认 N_GPUS_PER_NODE=4，README 示例使用 8，论文实验写 8 张 A800。
这些差异说明仓库脚本是可配置模板，不是唯一实验配置。

4.5 Self-Critic 伪代码

for each self_critic_interval:
    sampled_queries = rejection_sample(D_tool_RL, k)
    candidates = []
    for q in sampled_queries:
        responses = pi_RL.self_sample(q, n)
        for a in responses:
            r = executable_hierarchical_reward(a)
            candidates.append((q, a, trace(a), r))
 
    preferences = []
    for same_query_group in group_by_query(candidates):
        positives = [x for x in group if x.reward >= 1]
        negatives = [x for x in group if x.reward < 1]
        preferences.extend(pair(positives, negatives))
 
    pi_RL = dpo_finetune(pi_RL, preferences, ref_model=frozen_pi_RL)
    resume_vanilla_grpo(pi_RL)

论文没有把 self-critic 描述成一个外部 judge LLM。
它的关键是把层级 rule-based reward 当成 executable program 来给模型自己的响应打分。
这能产出正负偏好对，并让 DPO 显式学习 reward 原则。
这个机制比只用标量 reward 更容易让模型理解“格式正确、答案正确、多工具合理协作”的组合目标。
但这也依赖 reward 函数本身没有系统性偏差。

5. 复现风险、局限与可迁移启发

工具环境依赖重：搜索 API、网页解析、Python 沙箱、本地 Wikipedia 检索、vLLM 服务都会影响结果。
代码与论文时间点不完全一致：仓库 README 已更新至 2026 年后续版本，paper 是 2025-05-22 的 arXiv v1。
训练成本不低：论文 RL 阶段用约 10K 困难样本、8 rollouts、8 张 A800、2 epoch；self-critic 还要周期性 DPO。
reward 仍有可钻空子空间：只要同时出现 search 和 python 标签且答案正确，就有 0.1 bonus，模型可能学会在不必要场景中插入最小化工具调用。
多工具 bonus 很小但有方向性：0.1 不会压过答案正确性，但足以在正确样本之间偏好协作行为。
对检索质量敏感：GAIA/HLE 之类任务的瓶颈不一定在 LLM，而可能在搜索结果召回和网页摘要。
HLE 增益有限：说明面对极难广域任务，Tool-Star 的 web search + browser agent 仍不等于完整 Deep Research。
SFT 数据质量关键：消融中去掉 cold-start 的下降最大，说明 RL 前策略初始化比很多 reward tweak 更重要。
tool-call masking 是硬要求：多工具场景中不 mask 工具输出会导致 reward 崩溃，复现实验必须核查 loss mask。
self-critic 是可迁移模式：对任何 rule-based reward 复杂、标量反馈难学的 agent RL，都可以考虑把规则打分转成偏好对做间歇 DPO。
数据课程设计有启发性：用 DR/TIR 成败把样本分成 easy/useful/hard，比简单混合所有数据更适合工具学习。
推理期工程不可忽略：Debugger、Backtracer、Refiner 的存在说明最终 agent 能力来自模型权重与 runtime 共同设计。

6. 我会如何复用这篇论文

如果要训练一个能同时查资料和写代码的 LLM agent，我会先复刻它的三段式数据筛选：prompt 采样、hint 采样、DR/TIR 分类。
如果已有单工具 RL 框架，我会先加入格式 reward 和工具输出 masking，而不是立即上复杂 self-critic。
如果任务答案可以自动验证，我会把 multi-tool bonus 设计成小额附加奖励，只在答案正确之后生效。
如果任务答案不能自动验证，我会谨慎使用 Tool-Star 的 reward 形式，因为它高度依赖准确答案或 F1。
对推理系统，我会把 debug、rollback、refine 设计成 runtime policy，而不是都交给模型自己学。
对评估，我会同时看 accuracy/F1、工具调用次数、错误工具调用率和推理时延。
对长链 agent，我会把工具返回结果排除出 policy loss，并只训练模型生成的 reasoning token 和工具请求 token。
对偏好训练，我会优先使用模型自己的 roll-out 生成正负例，因为这比静态人写 preference 更贴近当前策略的错误分布。

7. 图表索引

Figure 1：整体性能对比，展示 Tool-Star 相对 TIR baseline 的准确率和 10 个任务表现。
Figure 2：三步数据合成管线，包括 TIR prompting、hint-based sampling、质量归一化和难度分类。
Figure 3：Multi-Tool Self-Critic RL 框架，包括 roll-out、层级 reward、GRPO 和 self-critic DPO。
Figure 4：工具效率、推理期工具增益、工具调用错误统计。
Figure 5/附录图：local search 与 web search 模式性能比较。
Figure 6：不同参数规模下 reward、response length、validation score 的训练曲线。
Figure 7/附录图：训练过程指标，用于观察 KL、reward 和验证分数。
Masking 图：去掉 tool-call masking 后 reward 崩溃到 -1，支持遮蔽工具输出的必要性。
Table 1：10 个 reasoning task 主结果，Tool-Star(Qwen2.5-3B) 平均 46.1。
Table 2：GAIA/HLE deep web exploration，Tool-Star 在 GAIA=15.5、HLE=8.0。
Table 3：数据来源，NuminaMath 72.4K、HotpotQA 8.1K、2Wiki 10K、SimpleDeepSearch 0.9K、WebWalker 3K。
Ablation wraptable：Cold-start、RL stage、Reward、Self-Critic 均有贡献，其中 cold-start 移除影响最大。

8. 结论

Tool-Star 的贡献不是单一算法技巧，而是一套把多工具 agent 行为放入 RL 后训练闭环的系统方案。
数据侧，它用 prompt sampling 与 hint sampling 扩展工具轨迹，并用 DR/TIR 成败做课程式分流。
训练侧，它用 cold-start 降低探索难度，用 GRPO 在困难样本上对齐策略，用层级 reward 约束答案、格式和协作。
自我批判侧，它把 reward rule 执行结果转为偏好数据，让模型更直接学习 reward 原则。
系统侧，它承认多工具推理需要 debugger、backtracer、refiner 等 runtime 模块。
实验侧，它在数学和知识任务之间取得更均衡的平均性能，避免了单工具 RL 的领域偏科。
实践侧，最值得优先复用的三点是：高质量 cold-start、tool output loss masking、只在答案正确后给小额多工具协作 bonus。

Paper Notes

探索

Tool-Star: Empowering LLM-Brained Multi-Tool Reasoner via Reinforcement Learning

Tool-Star: Empowering LLM-Brained Multi-Tool Reasoner via Reinforcement Learning

0. 阅读定位

1. 论文要解决的问题

2. 方法总览

2.1 问题形式化

2.2 工具设计

2.3 数据合成：Step 1 数据收集与采样

2.4 数据合成：Step 2 工具使用质量归一化

2.5 数据合成：Step 3 难度感知分类

2.6 两阶段训练：Cold-Start SFT

2.7 两阶段训练：Multi-Tool Self-Critic RL

2.8 层级奖励设计

2.9 Self-Critic DPO

2.10 多工具协同推理

3. 实验设计

3.1 主结果：10 个 reasoning task

3.2 Deep web exploration：GAIA/HLE

3.3 消融实验

3.4 工具效率与推理期工具分析

3.5 参数规模与训练曲线

3.6 Tool-call masking

4. 代码搜索与实现映射

4.1 代码仓库状态

4.2 Reward 伪代码

4.3 推理工具循环伪代码

4.4 GRPO 训练配置伪代码

4.5 Self-Critic 伪代码

5. 复现风险、局限与可迁移启发

6. 我会如何复用这篇论文

7. 图表索引

8. 结论

目录