全新思路！ACL2026解析《ToolOmni Enabling OpenWorld Tool Use via Agentic learning with...

WenJGo
0 阅读13分钟

image.png

一、这篇论文解决的问题

这篇论文研究的是 开放世界（open-world）工具使用。所谓开放世界，不是只有几个固定工具，而是面对一个规模很大、还会持续变化的工具库。论文里明确说，候选工具库可以大于 10,000 个工具；他们的实验基于 ToolBench，包含 16,464 个 API 、49 个类别、12.6 万以上工具使用 指令。

在这种场景下，传统方法主要有两类问题。

第一类是 检索式方法。先用 embedding/BM25 等从海量工具里找 top-k，再把这些工具交给执行模型。但这种方式是“被动检索”，检索过程和后续推理过程是分离的，模型不能在思考过程中主动改写查询、补查工具，所以很容易出现“语义像，但功能不对”的情况。论文第一页的图 1 就是在说明这个矛盾：面对海量工具时，浅层语义匹配很难精准命中真正需要的工具。

第二类是 参数记忆式方法。把工具文档直接灌进模型参数里，让模型学会直接生成工具 ID。这样做的问题是，一旦工具库更新，就要重新训练，而且对新工具泛化很差。图 1 的另一半就在强调这个问题：面对不断演化的工具库，单纯靠参数记忆并不稳。

Figure 1: Motivation for ToolOmni in Open-World

Scenarios: Embedding retrieval methods struggle with

Massive tools, often resulting in low retrieval accuracy

due to shallow matching; Parameter memory methods

fail to adapt to Evolving tools, suffering from poor generalization

to unseen tools. ToolOmni overcomes these

limitations via a unified agentic framework that couples

Proactive Retrieval with Grounded Execution , enabling

effective open-world tool use.

所以，这篇论文的核心问题可以概括成一句话：

如何让 LLM 在开放世界里，一边主动找工具，一边基于找到的工具真正把任务做完。

二、核心想法：把“找工具”和“用工具”放进同一个 agent 循环里

这篇论文提出的框架叫 ToolOmni。作者不是把“工具检索”和“工具执行”做成两个松散拼接的模块，而是把它们统一进一个 agentic reasoning loop 里。论文摘要和引言都把这个思想概括为：

Proactive Retrieval + Grounded Execution。

这里两个词非常关键。

Proactive Retrieval：主动检索

不是用户一来，系统就固定检一次 top-k 完事；而是模型自己判断：

  • 现在需不需要查工具
  • 应该怎么构造查询
  • 要不要继续再检一次
  • 什么时候停止检索

也就是说，检索变成了模型的一种“动作” ，而不再只是一个外部预处理步骤。

Grounded Execution：落地执行

当模型把所需工具收集得差不多之后，它再进入执行阶段，依据这些工具的文档、接口和返回结果进行多轮推理与调用，直到输出最终答案。这里“grounded”的意思是：推理不能飘在空中，而是要被真实工具上下文和执行反馈约束住。

三、流程：图 2 画是整篇论文的骨架

Figure 2: Overview of the ToolOmni framework. The pipeline operates in two decoupled phases: Proactive

Retrieval: The agent iteratively interacts with the retrieval server to curate a candidate tool set. Grounded

Execution: With retrieval results, the agent performs reasoning and tool invocation to generate the final answer.

论文第 4 页的 图 2 是全篇方法的总结构图。它把系统分成两个阶段：

左边是 Proactive Retrieval，右边是 Grounded Execution，中间还有一个 Trajectory Filter。图中底部还画出了两个独立的 reward 计算模块，以及“separate reward calculation and update within a single step”的训练思想。

如果把这张图翻译一下，流程就是：

用户问题进来

→ 模型先思考要搜索什么工具

→ 发出一个检索查询

→ 检索服务器返回一批候选工具

→ 模型继续判断：还缺不缺工具，要不要再检一轮

→ 当模型认为工具够了，就整理出一个最终工具子集

→ 只有当这个工具子集足以覆盖真值工具时，才进入执行 rollout

→ 然后模型在执行阶段“推理—调用工具—接收反馈—再推理”

→ 最后给出答案。

说明：工具检索不是一次性的前处理，而是 agent 自己控制的、可迭代的决策过程；而执行也不是脱离检索单独训练，而是和检索共同优化。

四、公式说明

论文把整个 open-world tool-use 过程写成一个轨迹τ\tau ，其中既包含检索阶段的推理与动作，也包含执行阶段的推理与动作。

作者用式 (1) 表示：在每个 turn，agent 先做 proactive retrieval，再做 grounded execution，最终根据问题 Q 和轨迹 τ\tau 生成答案 a。

这在概念上等于说：一个会用工具的 agent，不只是“调用 API ”，而是在构造一条完整的行为轨迹。

这条轨迹里有两类状态变化：

  • 检索阶段：状态因为“搜到了什么工具”而变化
  • 执行阶段：状态因为“工具返回了什么结果”而变化

所以，这篇论文不是在优化单次 function calling，而是在优化整条工具使用轨迹。

为什么要分成两个子任务

作者认为，检索和执行虽然相互依赖，但学习信号不一样：

  • 检索更关注：有没有把正确工具找全
  • 执行更关注：有没有把问题真正做对

如果把它们混成一个单奖励，训练会很粗糙，因为你很难判断失败究竟是“没找到对的工具”，还是“找到了但没用好”。所以他们提出 Decoupled Multi-Objective GRPO：把检索奖励和执行奖励分开计算，再在一个训练步骤里分别更新。

五、第一阶段训练：Cold-start Tool Learning 在干什么

作者先做一个 SFT 冷启动阶段。因为如果模型连最基本的“怎么搜索工具、怎么调用工具、怎么按格式输出”都不会，直接上 RL 很容易崩。

他们的数据来自 ToolBench，并分成两部分：

一部分是检索轨迹。作者先从 80,000 个 query 中训练一个 retrieval-only 模型，再做 rejection sampling，筛掉低质量轨迹，最后得到约 28,000 条高质量检索轨迹。另一部分是执行轨迹，大约 33,000 条，既有正确路径，也有错误路径，还用 Qwen-2.5-32B 做自动评审筛查。最终 SFT 数据就是两者的并集。

这里有个很值得注意的点：论文在 SFT 时只对 agent 自己生成的 reasoning 和 action token 计算 loss，把外部 observation 全部 mask 掉。这个设计的目的，是防止模型把环境动态“背下来”，从而让后续策略梯度训练更稳定。

==》：SFT 阶段教模型“行为模板”，不是教它去背环境答案。

六、第二阶段训练：Open-world Tool Learning 真正的创新点

这部分是全文最核心的技术贡献。

主动工具检索

在检索阶段，模型不是直接输出工具 ID，而是先生成一个 <search> ... </search> 查询，再让检索服务器用预训练 embedding 模型把查询编码，和工具向量做余弦相似度，返回 top-k 候选工具。这个过程对应式 (3)。

然后模型可以继续下一轮检索，不断补查，最后从累计候选工具里选出一个排序后的工具子集 TsubT_{sub}，这对应式 (4)。

这个设计和传统 retriever 最大的区别在于：查询不是固定的，而是由 agent 在推理过程中逐步生成和修正的。

所以它更像“搜索型 agent”，而不是“静态向量召回器”。

Grounded Tool Execution

拿到工具子集之后，模型切换到执行 prompt，进入 <reasoning> → <tool_call> → <information> 的循环。作者用一个 LLM-based Tool Simulator 来模拟工具反馈，支持在 RL 训练中高效地产生执行结果。最终执行过程由式 (5) 表达。

这个阶段有一个关键过滤条件：只有当 当前检索得到的工具子集已经覆盖所有 ground-truth tools，也就是 Tgold⊆TsubT_{gold} \subseteq T_{sub} 时，才保留这条轨迹用于执行训练。

这一步很关键，因为它等于在说：如果检索本身已经错了，就不要拿错误上下文去训练执行器。

否则执行模型会学到一种坏习惯：工具没找全也硬做，最后靠幻觉补答案。

七、奖励函数怎么设计：分开奖励

检索奖励

论文把检索奖励写成：

Rret=α1⋅rretfmt+α2⋅rrec⋅rconvR_{ret} = \alpha_1 \cdot r^{fmt}_{ret} + \alpha_2 \cdot r_{rec} \cdot r_{conv}

这里有三层意思：

第一，rretfmtr^{fmt}_{ret} 检查输出格式对不对，比如有没有正确使用 <search> 或最终工具列表格式。 第二，rrecr_{rec}衡量召回了多少真值工具，本质上是 recall 信号。 第三，rconvr_{conv}不是只看“搜到了”，还看“搜到之后有没有真正被选进最终工具集”。

这第三项很妙。因为它在奖励“有效检索”，而不是“乱搜一大堆”。

执行奖励

执行奖励写成：

Rexec=β1⋅rexecfmt+β2⋅ransR_{exec} = \beta_1 \cdot r^{fmt}_{exec} + \beta_2 \cdot r_{ans}

这里也分两部分：一部分是格式正确，另一部分是最终答案是否正确。

所以可以看到，检索奖励更偏中间过程，执行奖励更偏最终结果。作者正是用这种分工，让模型知道：

  • 检索阶段该把注意力放在“找到对的工具”
  • 执行阶段该把注意力放在“把事情做对”

八、为什么作者不用普通 GRPO，而要做 Decoupled Multi-Objective GRPO

这是这篇论文最值得你抓住的“方法学创新”。

Group-relative advantage 是什么

论文对每个 query 采样一组 G 个输出，然后分别对检索和执行计算 group-relative advantage：

Atask(i)=Rtask(i)−mean({Rtask}G)std({Rtask}G)+ϵA^{(i)}_{task} = \frac{R^{(i)}_{task} - mean(\{R_{task}\}^G)}{std(\{R_{task}\}^G)+\epsilon}

这里的 task 可以是 ret 或 exec。

它的意思是：不是看这条轨迹 绝对 好不好，而是看它在这一组候选里 相对 好不好。这样能更稳定地提取学习信号。

为什么“分开算 advantage”很重要

如果把检索和执行混在一起算一个 advantage，会有两个问题：

第一，执行奖励更稀疏，容易压过检索信号。

第二，检索和执行的优化方向不完全一致，混合后可能相互冲突。

所以作者做了两件事：

  • Separated Update：同一个训练 step 里，先更新 retrieval，再更新 execution，而不是把梯度直接相加。
  • Selective Rollout：只有检索成功覆盖真值工具时，才做 execution rollout。

这两个设计，本质上分别解决了：

  • 梯度冲突问题
  • 错误上下文污染问题

也正因为如此，作者在消融实验里能明确证明：去掉 filtering 或把更新合并，性能都会掉。

九、实验怎么做：这篇论文到底测了什么

实验主要在 ToolBench 上做。检索指标用 NDCG@k，执行指标用 SoPR（Solvable Pass Rate） 和 SoWR（Solvable Win Rate） 。模型初始化自 Qwen3-4B-Instruct，在 8 张 H100 上训练。

检索任务分两种设置：

  • In-Domain：只在相关子集里找工具
  • Multi-Domain：在整个 16K+ 工具库里找工具

后者更接近真正的开放世界。

执行任务则分两种：

  • With Ground-Truth Tools：给你正确工具，看你会不会用
  • With Retriever / End-to-End：工具也得你自己找，再自己执行

第二种才是最难也最有价值的设置。

十、实验结果

检索结果

在 Multi-Domain 设置下，ToolOmni 的平均 NDCG 达到 78.29，高于 ToolRetriever 的 76.44，也高于 ToolGen 的 68.64。尤其在 @1 和 @3 上更强，说明它更擅长在大工具库里把“真正关键的工具”排到前面。

论文还专门解释了一个现象：ToolOmni 有时在 NDCG@5 上并不绝对最优。原因不是它差，而是它会主动停止搜索。如果任务只需要 1–2 个工具，它不会为了凑 top-5 而塞很多无关工具，所以在某些固定 top-k 指标上看起来不占便宜。

说明：这是真正可执行的精确工具集，而不是指标导向的“凑数式召回”。

端到端执行结果

在最关键的 With Retriever (End-to-End) 场景下，ToolOmni 的平均 SoPR 为 54.13，相比 GPT-3.5 pipeline 的 42.35 提高了约 +11.78；平均 SoWR 为 50.16，相比 GPT-3.5 pipeline 的 39.77 也高很多。论文摘要里把这个概括为 end-to-end execution success rate +10.8% 。

说明 ToolOmni 的优势不只是“工具找得准”，而是：找得准之后，真的能把任务做成。

泛化能力

在 Tool Generalization 上，ToolOmni 的 SoPR 是 52.20；在更难的 Category Generalization 上达到 55.95，比 ChatGPT pipeline 的 42.10 高出 13.85。作者据此认为，ToolOmni 学到的是更通用的工具使用元能力，比如参数推断、错误恢复，而不只是训练集里的工具记忆。

抗噪声能力

论文还往上下文里故意加入 adversarial tools。结果 ToolLlama-v2 会随着噪声增加持续退化，而 ToolOmni 在初期下降后又回升，在 N=15 时达到 58.2% 。这说明它不是只会死盯某个“标准答案工具”，而是能在噪声里找到功能相近的替代路径。

十一、消融实验

第一，去掉 RL，只保留 SFT，检索 NDCG 会从 78.3 降到 49.3；说明检索能力主要来自 RL 驱动的主动探索。但如果去掉 SFT，执行 SoPR 会从 52.5 降到 43.4；说明执行阶段又很依赖 SFT 冷启动提供的基本推理能力。

第二，迭代检索优于 one-shot retrieval，平均 NDCG@5 提升 +4.5。这证明“多轮改写搜索意图”确实有效。

第三，去掉 trajectory filtering，SoPR 会掉到 38.5；把 retrieval 和 execution 的更新合并，SoPR 也会掉到 42.6；换回 vanilla GRPO 也会退化到 50.8。

结果支持作者的核心 claim：decoupled optimization 和 selective rollout 不是装饰，而是性能来源。

十二、参数和效率

作者也讨论了这一点。

在检索数量 k 上，性能呈现倒 U 型： k=1 太少，召回不足； k=5 最好，平均 NDCG 78.29； k=9 又下降到 73.16，因为上下文里噪声工具太多。

在效率上，ToolOmni 平均每个 query 搜索 3.02 次，确实比静态 baseline 的 1 次更多；但它平均只做 2.47 次实际工具调用，少于 ChatGPT 的 3.98 次。

作者的观点是：本地 embedding 检索便宜，而真实 API 调用贵，所以“多查几次、少错调几次”在系统层面是划算的。

这个论点挺有现实意义，因为真实部署里最贵的常常不是 token，而是：

  • 网络延迟
  • API rate limit
  • 错误重试成本

十三、这篇论文的局限性

作者自己也承认两点限制。

第一，它仍然采用一种级联 式架构：先检索，再执行。这个结构很稳定，但在某些超复杂任务里，真正理想的情况可能是“执行一半发现要补工具，再回去搜新工具”，而不是 rigid cascade。第二，当前实验只在 Qwen3-4B 上做，尚未验证更大模型规模下会不会出现更强的能力涌现。

十四、总结

论文的主线：

过去的方法，要么把工具检索做成静态前处理，要么把工具知识硬塞进模型参数。前者不够主动，后者不够泛化。于是作者提出 ToolOmni，把“主动搜工具”和“基于工具执行”统一到一个 reasoning loop 里；再通过“先 SFT 冷启动、后 decoupled multi-objective GRPO 强化”的两阶段训练，让模型既会找工具，也会用工具。实验表明，它在开放世界大工具库上的检索更准，在端到端工具执行上也更强，而且对新工具、新类别、噪声工具都更稳。

ToolOmni 不是简单提出了一个更强的 retriever，也不是只做了一个更会 function calling 的执行器，而是把“工具搜索”本身变成了 agent 行为的一部分，并用 decoupled RL 同时优化“找对工具”和“用对工具”。

avatar
文章
阅读
粉丝