
-
论文标题:ToolOrchestra: Elevating Intelligence via Efficient Model and Tool Orchestration -
论文链接:https://arxiv.org/pdf/2511.21689
TL;DR
NVIDIA 最近提出了一种名为 ToolOrchestra 的方法,旨在通过训练小型编排器(Orchestrator)模型来协调包括强力 LLM 在内的多种工具,从而解决复杂的代理(Agentic)任务。研究表明,通过强化学习(RL)训练的 8B 参数模型(Orchestrator-8B),能够在保持较低推理成本的同时,在 Humanity’s Last Exam (HLE) 等高难度基准测试中超越 GPT-5 等前沿模型。该方法引入了统一的工具调用接口、包含结果/效率/偏好的多维奖励函数,以及一个名为 ToolScale 的大规模合成数据生成流水线。实验结果显示,Orchestrator-8B 有效缓解了现有 Prompt 工程中存在的模型调用偏差,实现了性能与成本的帕累托优化。
这里忍不住吐槽一下,Orchestrator 核心的一点是根据 cost 也就是价格来决策。模型厂商要是偷偷改了 API 定价,这训练好的 8B 模型是不是就傻了?
1. 引言
大型语言模型(LLM)在通用任务上表现优异,但在处理如 Humanity’s Last Exam (HLE) 等复杂的代理任务时,其概念推理能力和计算成本仍面临挑战。现有的工具使用(Tool Use)研究主要集中在为单个模型配备搜索或代码解释器等基础工具。这种单一模型范式(Monolithic Paradigm)存在局限性:它未能充分利用日益丰富的生态系统中的其他模型资源。人类在解决复杂问题时,往往会根据需求调用不同领域的专家或更高级的智能系统,而非仅依靠自身。
基于此观察,NVIDIA 与香港大学的研究团队提出了 编排范式(Orchestration Paradigm)。在此范式下,智能不再源于单一的巨型模型,而是涌现自一个复合系统。系统的核心是一个 编排器(Orchestrator) 模型,其职责是针对给定任务,动态地调用合适的工具(包括其他 LLM),并规划执行顺序。
与传统的工具使用不同,ToolOrchestra 将不同能力的模型(如专门的数学模型、编码模型以及更强的通用模型)视为“智能工具”。核心挑战在于如何训练编排器在多轮推理中平衡任务完成率、计算成本以及用户偏好。直接通过 Prompt 工程(Prompting)引导模型进行编排往往会导致严重的偏差,例如过度依赖自身的“自我增强偏差”(Self-enhancement bias)或盲目调用最强模型的倾向。
本文提出了 ToolOrchestra,这是一种利用强化学习端到端训练小型编排器的方法。通过设计包含结果正确性、资源效率和用户偏好的奖励函数,训练出的 Orchestrator-8B 在 HLE、FRAMES 和 -Bench 等基准上取得了优异成绩。

2. 代理问题形式化
2.1 任务定义
研究将多轮工具使用任务形式化为马尔可夫决策过程(MDP),表示为 。
-
:给定的指令。 -
:用户对特定动作的偏好。 -
:初始观察。 -
:环境状态空间。
在步骤 ,编排器根据策略 选择动作 ,其中 是交互历史。环境根据 进行转移,并产生观察 。
每个动作 都有对应的货币成本 和操作延迟 。动作与用户偏好的对齐程度记为 。
在 步交互后,编排器生成轨迹 ,环境根据其正确性提供奖励 。
优化的目标是最大化正确性奖励 和总体用户偏好对齐度 ,同时最小化总成本 和总延迟 。
2.2 多轮交互流程 (Multi-Turn Rollout)
编排器通过迭代的 Rollout 生成解决方案:
-
思维链(Reasoning): 编排器分析当前状态并规划下一步行动。 -
工具调用(Action): 基于推理,编排器从可用集合中选择工具(API、专用模型、代码解释器等)并指定参数。 -
工具响应(Observation): 环境执行工具调用,输出结果被追加到上下文中,反馈给模型进行下一轮处理。
该过程持续进行,直到编排器收到终止信号或达到最大轮数(例如 50 轮)。
3. ToolOrchestra 方法论
ToolOrchestra 的核心是训练一个小型语言模型(8B 参数),使其能够战略性地协调更智能的工具。

3.1 统一工具调用
为了支持异构工具集,ToolOrchestra 将所有工具通过统一的接口暴露给模型。工具定义为 JSON 对象列表,包含名称、描述和类型化的参数 Schema。
特别地,对于作为工具使用的 LLM,其描述是通过以下步骤生成的:
-
随机采样训练任务。 -
获取 LLM 完成这些任务的轨迹。 -
利用另一个 LLM 根据任务指令、轨迹及完成情况撰写描述。
这种方法使得编排器能够理解不同模型的能力边界(例如 Qwen3-32B 在数学推理上的优势或特定领域的劣势)。
3.2 端到端代理强化学习
奖励设计 (Reward Design)
训练引入了三类奖励:结果(Outcome)、效率(Efficiency)和偏好(Preference)。
1. 结果奖励
对于 Rollout 批次 中的每条轨迹 ,根据是否解决任务给予二值奖励:
研究利用 GPT-5 作为裁判来评估答案的正确性,以处理多样化的预测输出。
2. 效率奖励
为了惩罚过度的计算和延迟:
其中 是轨迹的货币成本(通过 Token 价格计算), 是消耗的墙钟时间。这建立了统一的计算成本度量。
3. 偏好奖励
给定工具集 ,定义轨迹 的向量 :
其中 是工具 在 中被调用的次数。
在 RL 训练期间,对批次 中的 进行归一化处理得到 。
最终奖励计算结合了用户偏好向量 :
,取值在 之间,表示用户希望优化该维度的程度。例如, 且 表示用户只关心准确率而不计成本。
训练过程
编排器使用策略梯度算法 Group Relative Policy Optimization (GRPO) 进行微调。
对于批次中的每个任务,策略 生成一组轨迹 。每条轨迹 分配一个标量奖励 ,GRPO 通过组内归一化计算优势(Advantage):
策略更新目标为最大化裁剪后的代理目标函数(Clipped Surrogate Objective):
其中 。
训练技巧
为了稳定训练并避免 KL 散度爆炸,采用了以下过滤机制:
-
同质性过滤(Homogeneity filtering): 当 Batch 内奖励标准差小于 0.1 时过滤,因为此时提供的训练信号较弱。 -
格式一致性过滤: 过滤不符合工具调用格式的输出。 -
无效输出过滤: 过滤未产生有效答案的样本。
4. 数据合成:ToolScale
为了进行端到端的 RL 训练,需要大量高质量的代理工具调用数据。由于此类真实数据稀缺,本文设计了 ToolScale 数据合成流水线。

4.1 合成流程
该过程分为两步:
-
环境模拟:
-
对于选定的领域 (如电影预订),利用 LLM 生成包含 Schema、主要实体和条目的数据库。 -
基于领域 ,LLM 提议常用的工具(API)。 -
通过此步骤,构建了包含数据库和工具接口的丰富环境。
-
-
任务生成:
-
LLM 首先提出该领域常见的用户意图(Intents)。 -
结合数据库的详细信息,将意图转化为具体任务。 -
生成的每个任务包含:指令 ,黄金函数调用序列 ,以及必须在解决过程中提及的简短信息 。 -
任务进化: 使用额外的 LLM 增加任务复杂度(如添加约束条件)。
-
4.2 数据过滤与验证
为了保证质量,生成的任务需经过严格过滤:
-
黄金函数调用执行报错则剔除。 -
LLM 在 pass@8 设置下无法解决的任务剔除(太难)。 -
无需任何动作即可解决的任务剔除(太简单)。
此外,定义了轨迹 是否解决任务的三条标准:
-
执行正确性(Execution Correctness): 执行 后数据库状态与执行黄金序列 后一致。 -
过程保真度(Process Fidelity): 轨迹 中提及了预定义信息 。 -
操作完整性(Operation Completeness): 黄金序列 中操作的数据库条目在 中也被操作。
该流水线在 10 个领域生成了数千个可验证的多轮工具使用训练样本。
5. 实验设置
5.1 工具配置
训练阶段准备了全面的工具集,并随机采样子集以模拟异构环境。评估阶段固定使用以下工具集:
-
基础工具: Tavily 搜索 API、Python 代码解释器、基于 Faiss 的本地搜索(使用 Qwen3-Embedding-8B)。 -
专用 LLM(作为工具): -
代码编写:Prompted GPT-5, GPT-5-mini, Qwen2.5-Coder-32B-Instruct。 -
数学模型:Qwen2.5-Math-72B, Qwen2.5-Math-7B。
-
-
通用 LLM(作为工具): GPT-5, GPT-5-mini, Llama-3.3-70B-Instruct, Qwen3-32B。
5.2 基线模型
对比了以下几类基线:
-
无工具的单一模型: GPT-5, Claude Opus 4.1 等。 -
仅配备基础工具的模型。 -
配备扩展工具集(含模型工具)的 Prompted Orchestrator: 通过 Prompt 工程让 LLM 充当编排器。
5.3 评估基准
-
Humanity’s Last Exam (HLE): 包含数学、人文、自然科学等领域的博士级难题。使用纯文本子集。 -
FRAMES: 针对 RAG 的端到端评估,涉及多跳推理、多约束和表格/时间推理。 -
-Bench: 评估在对话中解决零售、航空等领域问题的能力。
6. 实验结果与分析
6.1 主要性能对比

实验结果表明,Orchestrator-8B 在多个维度上显著优于基线:
-
HLE: Orchestrator-8B 达到 37.1% 的准确率,超过了 GPT-5 (35.1%),且成本仅为 GPT-5 的约 30%。 -
FRAMES: 得分 76.3% ,优于 GPT-5 (74.0%)。 -
-Bench: 得分 80.2% ,优于 GPT-5 (77.7%)。
与简单的 Prompt 方法相比(如 Qwen3-8B 配备工具仅在 HLE 上得分 30.6%),RL 训练带来了显著提升。即使是像 Claude Opus 4.1 这样的强模型,在使用工具时虽然性能提升,但成本极其高昂(76.2 美分),而 Orchestrator-8B 仅需 9.2 美分。
6.2 工具使用分析与偏差
研究发现,基于 Prompt 的编排器存在严重的偏差:
-
自我增强偏差: 较弱的模型(如 Qwen3-8B)倾向于过度调用其变体或特定模型,而不是根据任务难度选择最合适的模型。 -
他者增强偏差: 像 GPT-5 这样的强模型作为编排器时,倾向于调用 GPT-5-mini(占比 52.3%),表现出固定的调用模式。

相比之下,Orchestrator-8B 的工具调用分布更加均衡且符合策略。在 -Bench 中,它仅在约 40% 的步骤中调用 GPT-5,其余时间使用更便宜的模型或工具,却取得了比全程使用 GPT-5 更好的效果。这证明了它学会了根据任务需求动态调度资源。
6.3 成本效率分析

通过限制最大轮数(即限制预算),研究绘制了性能-成本曲线。结果显示,在给定的预算下,Orchestrator-8B 始终优于 GPT-5 和 Claude Opus 4.1。它能够在大幅降低成本的同时,推动系统整体的智能边界。
6.4 泛化能力
未见工具的泛化:
研究测试了训练中未见过的工具配置(例如引入 Claude Opus, GPT-4o, DeepSeek-Math 等)。

结果显示,Orchestrator-8B 能够通过阅读模型描述,理解新工具的优劣势,并在 HLE 上达到 22.0% 的准确率,优于 GPT-5 的 16.4%,且保持了最低的成本。
未见价格配置的泛化:
研究还测试了不同的定价策略(模拟不同用户的成本约束)。Orchestrator-8B 能够根据新的价格信号调整策略,始终保持最佳的成本效益比。
6.5 用户偏好对齐
在测试时,向模型输入额外的偏好指令(例如“尽可能节省成本”或“不惜一切代价保证准确”)。

Orchestrator-8B 在遵循用户偏好方面表现最佳,其偏好奖励得分显著高于 GPT-5。这表明该模型不仅学会了解决任务,还学会了如何在多维约束空间中进行权衡。
7. 相关工作
从工具学习到通用代理
早期的工具学习(Tool Learning)如 Toolformer 使用自监督或 SFT。随后的研究如 WebGPT、Search-R1 引入了强化学习。ToolOrchestra 的区别在于它不再局限于搜索或计算器,而是将“模型”本身作为工具进行编排,实现了更高级的复合智能。
效率与可控性
现有的提升效率的方法通常依赖 Prompt 工程(如 Self Divide-and-Conquer)或简单的启发式规则。ToolOrchestra 通过在奖励函数中显式建模成本和偏好,并利用 GRPO 进行端到端优化,提供了一种更加灵活和鲁棒的解决方案。与 OTC 等相关工作相比,ToolOrchestra 处理的工具集更广泛,且更强调用户偏好的细粒度对齐。
8. 结论
ToolOrchestra 展示了一种通过训练小型编排模型来统一多样化工具和专用模型的方法。通过强化学习,Orchestrator-8B 学会了在结果质量、效率和用户偏好之间进行动态权衡。实验证明,这种编排范式能够在大幅降低计算成本的同时,在极具挑战性的 HLE 等基准上超越前沿的单一模型系统。
附录:技术细节补充
A. 训练配置
-
基座模型: Qwen3-8B。 -
数据集: GeneralThought-430K 混合合成数据 ToolScale。 -
超参数: 学习率 1e-6,最大序列长度 24,000,Batch Size 16,Rollout Batch Size 8。 -
硬件: 16 张 NVIDIA H100 GPU。
B. 定价与转换
为了在奖励函数中统一计算成本,研究将所有模型的 Input/Output Token 转换为美元成本。对于开源模型,采用了 Together AI 等第三方 API 的定价作为参考。
C. 偏好向量示例
如果用户偏好指令为:“我是公司员工,服务器里有机密信息...我有许多 GPU,可以托管开源模型...希望能尽量避免 API 调用。”
对应的偏好向量 可能为 (假设前几位对应本地工具,后几位对应 API 工具),意味着用户强烈偏好本地搜索和本地模型,而对 API 工具的权重设为 0。这种细粒度的控制是 ToolOrchestra 的一大特色。
更多细节请阅读原论文。
往期文章:
