2511.21689_ToolOrchestra: Elevating Intelligence via Efficient Model and Tool Orchestration

总结

From Blog

  • 成绩

    • 在 GAIA Agent基准测试中排名第一，平均得分90.37%，超越使用GPT-5和Claude Opus等工具的竞争对手，突显协调架构在AI代理领域的潜力

    • 准确率——Orchestrator-8B：37.1%，GPT-5：35.1%

    • 成本——Orchestrator 只有GPT-5的 1/3

  • 三个关键角色：

    • Orchestrator（8B 模型）：不负责解题，只负责判断、调度、决策：下一步该用谁？

    • 工具池，包括：多款模型和外部工具。主要有：强但贵的大模型、便宜但快的小模型、搜索、函数、外部工具等。

    • 奖励系统。目标不只奖励“答对”，还奖励：用得省、用得合理、用得像人。即，光聪明还不够，你还得知道什么时候该让谁做。

  • Orchestrator唯一任务就是做出决策

    • • 选择工具和模型

    • • 排序多步骤工作流程

    • • 权衡准确性、成本和延迟之间的利弊，执行完全委托。

  • Agent开发新风向：智能，是管出来的。

    • 小模型可以管理大模型

From Moonlight

三句摘要

  1. 💡 ToolOrchestra提出了一种通过训练小型Orchestrator模型来协调各种工具和智能模型，以高效解决复杂Agentic任务的方法。

  2. ⚙️ 该方法采用强化学习，其奖励设计综合了任务结果的正确性、资源使用效率（成本和延迟）以及用户偏好，以实现高性能和可控性。

  3. 🏆 实验证明，仅8B参数的Orchestrator在HLE、FRAMES和τ2-Bench基准测试上超越了包括GPT-5在内的现有方法，同时成本显著降低且泛化能力强大。

关键词

  • ToolOrchestra: 是一种训练小型语言模型使其能够充当“协调者”的方法。该方法通过强化学习（Reinforcement Learning, RL）来训练一个模型，使其能够动态地选择和调用各种外部工具（如搜索引擎、代码解释器、其他专业模型或通用大型语言模型），以高效且符合用户偏好的方式解决复杂的多轮推理和代理任务。其核心在于通过精心设计的奖励机制，平衡任务的最终结果、执行效率和用户对工具选择的偏好。

  • Orchestrator: 是使用 ToolOrchestra 方法训练出来的模型。它是一个 80 亿参数（8B）的模型，被设计为异构工具使用代理的核心“大脑”。Orchestrator 的职责是理解用户请求，并在一系列推理步骤中，动态地决定调用哪些工具（包括基础工具、专业 LLM 和通用 LLM），以及如何组合它们来完成任务。它通过 RL 学习，目标是在保证任务正确性的前提下，最小化成本和延迟，同时最大化用户偏好的满足度。

  • Agentic Tasks: 指的是需要智能代理（Agent）通过与环境互动，在多个回合中做出决策并利用工具来达成目标的一类任务。这类任务通常比简单的问答更复杂，需要代理进行规划、推理、执行和反馈循环。例如，解决像“人类最后考试”（HLE）这样跨学科的复杂问题，或者执行需要一系列API调用的多步操作。

  • Tool Use: 指的是人工智能模型利用外部资源或函数（例如，搜索互联网、调用计算器、运行代码、使用特定领域的 API 或调用其他大型语言模型）来增强其推理和解决问题能力的过程。通过工具使用，模型可以访问超出其训练数据范围的信息和功能，从而提高准确性、减少幻觉，并处理更复杂的任务。

  • Reinforcement Learning: (强化学习，RL) 是一种机器学习范式，其中一个智能体（Agent）通过与环境互动来学习。智能体通过执行动作（Action）来改变环境状态（State），并根据环境反馈的奖励（Reward）或惩罚来调整其行为策略（Policy），目标是最大化累积奖励。在 ToolOrchestra 中，RL 被用来训练 Orchestrator 模型，使其学会如何最优地选择和使用工具。

  • Outcome Reward: (结果奖励) 是强化学习中的一种奖励信号，用于评估智能体执行任务的最终结果的正确性或成功度。在 ToolOrchestra 中，如果 Orchestrator 成功地解决了任务，它会获得一个积极的“结果奖励”（通常是二元的，如 1 代表成功，0 代表失败）。这是 RL 奖励设计的一个关键组成部分，确保智能体首先关注任务的完成质量。

  • Efficiency Reward: (效率奖励) 是强化学习奖励设计的一部分，旨在鼓励智能体以最小的资源消耗来完成任务。在 ToolOrchestra 中，它通过对计算成本（如 API 调用费用）和执行时间（如延迟）进行惩罚来实现。Orchestrator 通过最大化效率奖励，学会如何在保证结果质量的前提下，选择更经济、更快速的工具使用策略。

  • User Preference Reward: (用户偏好奖励) 是 ToolOrchestra 中一种特殊的奖励信号，用于训练 Orchestrator 遵循用户的具体偏好。这些偏好可能包括喜欢使用某种特定类型的工具（如开源模型而非闭源 API）、偏好低成本解决方案、或偏好低延迟。通过将用户偏好转化为奖励信号，Orchestrator 能够学习在工具选择时主动考虑并满足用户设定的各种偏好。

  • Cost-efficiency: (成本效益) 是衡量一个系统在完成特定任务时，在投入成本（如计算资源、API 调用费用、时间）与获得的性能（如准确率、任务完成度）之间取得的平衡。ToolOrchestra 的目标之一是提高 AI 系统的成本效益，使得 Orchestrator 能够以远低于大型单体模型（monolithic models）的成本，达到甚至超越它们的性能。

  • ToolScale: 是由论文作者为训练 ToolOrchestra 方法而合成的一个大规模数据集。它包含数千个可验证的多轮工具使用训练示例，涵盖了 10 个不同领域。该数据集通过模拟真实的用户-代理-工具环境，生成数据库模式、工具 API、多样化的用户任务以及对应的黄金行动（ground truth solutions）。ToolScale 的目的是为端到端的 RL 训练提供充足且高质量的数据，尤其是在缺乏真实世界复杂工具使用数据的场景下。

  • Humanity’s Last Exam (HLE): 是一个包含博士级别跨学科问题的基准测试集，涵盖数学、人文科学、自然科学等多个领域。它旨在评估模型进行迭代搜索和深度推理的能力。HLE 被认为是衡量大型语言模型在解决复杂、深层次问题方面能力的一个严峻挑战，而 ToolOrchestra 的 Orchestrator 模型在 HLE 上取得了显著的性能提升，证明了其在处理这类复杂任务上的有效性。

  • Generalization: (泛化能力) 指的是一个模型在训练过程中未曾见过的数据、任务或工具上，依然能够表现良好的能力。在 ToolOrchestra 中，作者通过在训练中随机化工具子集和定价模型，并用包含未见过的模型进行测试，来评估 Orchestrator 的泛化能力。实验表明，Orchestrator 能够有效地适应新的工具和定价环境，证明了其鲁棒性和广泛适用性。

  • Orchestration: (编排) 在此论文的语境下，是指一种智能系统设计范式，其中一个中心模型（Orchestrator）负责协调和管理一个由多种不同能力（包括计算工具、信息检索工具、以及不同规模和类型的其他语言模型）组成的异构系统。这种范式将整体智能视为一个组合系统（composite system），而非单一强大模型的“巨石”（monolith），旨在通过智能的工具调用和组合，实现比系统中任何单一工具更强的整体能力，并优化资源利用。

摘要

ToolOrchestra 是一项通过训练小型编排模型来提升智能和效率的方法，旨在解决大型语言模型（LLMs）在处理复杂代理任务时面临的挑战，例如 Humanity’s Last Exam (HLE)。该研究发现，一个小型编排器能够有效管理其他模型和各种工具，从而在解决复杂任务时提升智能上限并提高效率。

核心问题与挑战： LLMs 虽然强大，但在HLE等复杂代理任务中表现有限。工具使用虽能扩展其能力并减少幻觉，但现有方法主要集中于为单个强大模型配备通用工具，未能充分利用工具的潜力。人类在推理时会调用能力超人一等的资源，而目前的 LLM 方法则像“独石”系统，缺乏这种复合智能。此外，直接通过提示（prompting）来协调工具会导致模型出现偏见，例如过度使用自身或最强大的工具，而忽视成本和用户偏好。LLMs 工具使用代理在成本效益和用户偏好方面的可控性也未被充分探索。

ToolOrchestra 方法论： ToolOrchestra 提出了一种新的范式，即智能并非来源于单一整体，而是通过复合系统涌现。其核心是一个编排器模型，负责为给定任务调用正确的工具，并以正确的顺序执行。与传统设置的关键区别在于，它不仅提供确定性工具（如网络搜索、代码解释器），还将各种能力的模型作为智能工具提供给编排器。编排器的挑战在于动态决定调用哪些工具，以在解决任务的同时尊重用户偏好并最小化成本。

  1. 代理问题形式化（Agentic Problem Formulation）： 该研究将多轮工具使用代理任务形式化为一个马尔可夫决策过程 (MDP) \(\mathcal{M} = (\mathcal{U}, \mathcal{S}, \mathcal{A}, \mathcal{O}, \mathcal{T}, \mathcal{Z}, r, \rho, \gamma)\)：

    • \(\mathcal{U}\)：指令空间。

    • \(\mathcal{S}\)：环境状态空间。

    • \(\mathcal{A}\)：动作空间，包含工具调用。

    • \(\mathcal{O}\)：观察空间。

    • \(\mathcal{T}\)：状态转移函数。

    • \(\mathcal{Z}\)：观察函数。

    • \(r\)：奖励函数。

    • \(\rho\)：初始状态分布。

    • \(\gamma\)：折扣因子。 在第 \(k\) 步，编排器根据策略 \(\pi_\theta(a_k | h_k)\) 选择动作 \(a_k \in \mathcal{A}\)，其中 \(h_k = (u, o_0, a_0, o_1, \ldots, a_{k-1}, o_k)\) 是交互历史。每个动作 \(a_i\) 都有成本 \(c_i\) 和操作延迟 \(l_i\)，以及与用户偏好的一致性 \(p_{a_i}\)。经过 \(N\) 步交互后，编排器形成轨迹 \(\tau = h_N\)，环境根据其正确性提供奖励 \(r(\tau) \in [0, 1]\)。目标是最大化正确性奖励 \(r(\tau)\) 和总体用户偏好一致性，同时最小化总成本 \(\sum c_i\) 和聚合延迟 \(\sum l_i\)。

  2. 多轮执行（Multi-Turn Rollout）： 给定用户任务，编排器通过迭代执行生成解决方案，交替进行工具使用和环境反馈以形成轨迹。每轮遵循“思考-行动-观察”循环：

    • 链式思考（Reasoning）： 编排器分析当前状态并规划下一步行动。

    • 工具调用（Action）： 根据推理，编排器从可用工具集中选择一个工具（API、专用模型、代码解释器）并指定参数。

    • 工具响应（Observation）： 如果存在工具调用，工具调用块被提取并由环境执行；结果输出以用户角色附加到上下文中，并反馈给模型进行下一轮。此过程重复，直到编排器收到终止信号或达到最大 50 轮。

  3. 统一工具调用（Unified Tool Calling）： ToolOrchestra 拓宽了工具集，纳入了领域专用模型，并通过单一、统一的接口暴露所有工具。工具以 JSON 列表形式指定，每个对象定义工具名称、描述和带类型参数的模式。当 LLMs 被用作工具时，其描述通过以下步骤获取：随机抽取 10 个训练任务，获取 LLMs 完成这些任务的轨迹，然后由另一个 LLM 根据任务指令、LLM 轨迹以及 LLMs 是否完成任务来编写描述。

  4. 端到端代理强化学习（End-to-End Agentic Reinforcement Learning）： ToolOrchestra 使用强化学习对一个小型语言模型（8B 参数模型）进行端到端训练，使其作为编排器，学习生成最优的多步推理和工具使用轨迹。

    • 奖励设计（Reward Design）： 综合考虑了结果、效率和偏好。

      • 结果奖励（Outcome Reward）： \(r_{outcome}(\tau) \in \{0, 1\}\)，基于轨迹 \(\tau\) 是否解决了任务。GPT-5 被用作评判员来比较答案。

      • 效率奖励（Efficiency Rewards）： 惩罚过度计算或延迟。\(r_{compute}(\tau) = -\$(\tau)\) 和 \(r_{latency}(\tau) = -Clock(\tau)\)，其中 \(\$(\tau)\) 是轨迹的货币成本，\(Clock(\tau)\) 是消耗的挂钟时间。所有模型（开源和专有）的计算都转换为货币成本以实现统一衡量。

      • 偏好奖励（Preference Reward）： 鼓励模型在每一步选择工具时考虑用户偏好。对于给定工具集 \(\{t_1, t_2, \ldots, t_n\}\) 和轨迹 \(\tau\)，构建向量 \(M_\tau = [m_\tau^{t_1}, m_\tau^{t_2}, \ldots, m_\tau^{t_n}, r_{outcome}(\tau), r_{compute}(\tau), r_{latency}(\tau)]\)，其中 \(m_\tau^{t_k}\) 是工具 \(t_k\) 在 \(\tau\) 中被调用的次数。

      • 最终奖励（Final Reward）： \(R(\tau) = M_{\tau}^{\text{normalized}} \cdot P\) 如果 \(r_{outcome}(\tau)=1\)，否则为 \(0\)。其中 \(P = [p_{t_1}, p_{t_2}, \ldots, p_{t_n}, p_{outcome}, p_{compute}, p_{latency}]\) 是偏好向量，指示用户希望优化 \(M[\cdot]\) 的程度。在训练期间， \(M_{\tau}^{\text{normalized}}[k]\) 通过对批次中的 \(M[\cdot][k]\) 进行归一化计算：\(M_{\tau}^{\text{normalized}}[k] = (M_\tau[k] - M_T^{\text{min}}[k]) / (M_T^{\text{max}}[k] - M_T^{\text{min}}[k])\)。

    • 训练流程（Training Procedure）： 编排器使用策略梯度强化学习算法进行微调，具体是 Group Relative Policy Optimization (GRPO)。对于批次中的每个任务，策略 \(\pi_\theta\) 生成一批轨迹 \(\mathcal{T}\)。每个轨迹 \(\tau \in \mathcal{T}\) 被分配一个标量奖励 \(R(\tau)\)，GRPO 在其组内对奖励进行归一化以计算优势 \(A(\tau) = (R(\tau) - \text{mean}_{\tau \in T}R(\tau)) / \text{std}_{\tau \in T}R(\tau)\)。策略更新以最大化裁剪代理目标： \(\mathcal{L}_{\text{GRPO}}(\theta) = \mathbb{E}_{\tau \sim \pi_\theta} \left[ \min \left( \text{ratio}_\theta(\tau) A(\tau), \text{clip}(\text{ratio}_\theta(\tau), 1-\epsilon, 1+\epsilon) A(\tau) \right) \right]\) 其中 \(\text{ratio}_\theta(\tau) = \pi_\theta(\tau) / \pi_{\text{old}}(\tau)\) 是当前策略与旧策略之间的似然比。

    • 训练技巧（Training Techniques）： 为稳定 RL 训练并避免 KL 散度爆炸，进行了同质性过滤（奖励标准差小于0.1时过滤）、格式一致性过滤（输出与工具调用格式不符时过滤）和无效输出过滤。

  5. 数据合成（Data Synthesis）—— ToolScale： 为实现端到端 RL 训练，需要可验证的工具调用任务数据。研究设计了两步数据合成流程：

    • 模拟丰富用户-代理-工具环境： 从一个领域 \(D\) 开始，LLM 生成包含模式、主要主题和条目的数据库。再由 LLM 根据领域 \(D\) 提出常用工具。

    • 生成多样用户任务和黄金解决方案： LLM 首先提出领域 \(D\) 中常见的意图，然后根据详细数据库信息将其转换为特定任务。每个生成的任务包含指令 \(I\)、黄金函数调用 \(A = a_1, \ldots, a_l\) 和需要在解决任务过程中提及的简短信息 \(o\)。额外的 LLM 用于增加任务复杂性，如添加更多约束。

    • 数据质量过滤： 过滤掉执行黄金函数调用报告错误、LLMs 在 pass@8 中无法解决以及无需任何行动即可解决的任务。轨迹 \(\tau\) 解决任务的标准包括：执行正确性（数据库内容在执行黄金函数调用 \(A\) 和轨迹 \(\tau\) 后是否匹配）、过程忠实性（预定义信息 \(o\) 是否在 \(\tau\) 中提及）和操作完整性（地面真值轨迹 \(A\) 中操作的数据库条目是否也在 \(\tau\) 中操作）。

  6. 用户偏好和通用工具配置：

    • 用户偏好： 构建偏好指令 \(P_I\) 和偏好向量 \(P\) 对，指示用户希望优化特定功能或工具使用频率的程度。将生成的偏好指令连接到示例指令，并用用户偏好增强训练和测试数据。

    • 通用工具配置： 为增强泛化能力，通过随机抽样工具子集和改变定价方案来模拟异构用户访问和成本结构，以鼓励编排器在不同约束下进行优化。

实验结果： Orchestrator-8B 在 HLE、FRAMES 和 \(\tau^2\)-Bench 等基准测试中超越了 GPT-5 和 Claude Opus 4.1 等最先进模型，同时显著降低了成本和延迟。例如，在 HLE 上，Orchestrator-8B 达到 37.1% 的得分，超越了 GPT-5 (35.1%)，且效率高出 2.5 倍。在 \(\tau^2\)-Bench 和 FRAMES 上，Orchestrator-8B 以更低的成本大幅超越了 GPT-5。分析表明，Orchestrator-8B 实现了性能和成本之间的最佳权衡，并且能够鲁棒地泛化到未见过的工具和定价配置。与其他模型相比，Orchestrator-8B 在工具调用上表现出更均衡的策略，而不是过度依赖昂贵或功能单一的工具。此外，它在测试时能更好地适应用户偏好。

结论： ToolOrchestra 提供了一种有效的方法，通过强化学习训练一个小型编排模型来统一各种工具和专用模型。该方法使代理能够学习适应性工具使用策略，并平衡结果质量、效率和人类偏好。ToolScale 数据集也为工具使用代理训练提供了支持。研究结果表明，通过轻量级编排模型组合多样化工具，比现有方法更高效和有效，为实用和可扩展的工具增强推理系统铺平了道路。未来工作将探索更复杂的递归编排器系统，以进一步提升智能上限和效率。

Abstract

本论文探讨了大型语言模型在解决复杂问题（如“人类终极考试”HLE）时所面临的效率与能力限制，提出了一种新的方法 ToolOrchestra，用于训练小型“协调者”（Orchestrator）模型，以高效地调度多个工具和模型来完成任务。

核心内容讲解：

  • 问题背景：

    • 尽管大语言模型具备广泛的能力，但在解决深度复杂问题时仍面临效率低、成本高的问题。

  • 方法创新：

    • 提出 ToolOrchestra，采用强化学习（Reinforcement Learning）方法，训练一个小型协调模型（8B参数）来管理多个工具和模型。

    • 奖励机制综合考虑了：

      • 任务结果（outcome-aware）

      • 计算效率（efficiency-aware）

      • 用户偏好（user-preference-aware）

  • 实验结果：

    • 在 HLE 数据集上，Orchestrator 得分 37.1%，超过 GPT-5 的 35.1%，同时计算效率提升 2.5 倍。

    • 在 τ²-Bench 和 FRAMES 上，Orchestrator 明显优于 GPT-5，仅使用约 30% 的成本。

    • 模型在多种指标下展现出性能与成本的最佳平衡，并能泛化到未见过的工具。

  • 结论意义：

    • 使用轻量级协调模型组合多种工具的方法，比现有方法更高效、更有效，为构建实用且可扩展的工具增强型推理系统提供了新路径。

1 Introduction

核心问题与背景

大型语言模型（LLMs）在多个领域展现出接近甚至超越人类的智能水平，但在复杂任务（如 Humanity’s Last Exam, HLE）中仍表现有限。为提升其能力，工具使用（tool use）成为一种有效手段，通过调用外部资源（如搜索引擎、代码解释器）来增强准确性并减少幻觉。

现有方法的局限

以往的工具使用研究主要集中在将单一强大模型（如 GPT-5）与工具结合。这种“单体式”方法虽然有效，但未能充分利用工具的潜力。人类在推理时会调用多种智能资源（如专家、软件系统），因此作者提出协调范式（orchestration paradigm）。

协调范式的核心思想

该范式认为智能应来自一个复合系统，而非单一模型。系统核心是一个协调器（orchestrator），负责：

  • 选择合适的工具；

  • 按照正确的顺序调用工具；

  • 在满足用户偏好和成本控制的前提下完成任务。

与传统方法的关键区别在于：协调器不仅调用确定性工具（如搜索、计算器），还调用不同能力等级的模型作为“智能工具”。

协调器的实现挑战

  • 直接提示现成模型（如 GPT-5、Qwen3-8B）存在系统性偏差：

    • 自我增强偏差（self-enhancement bias）：偏好调用与自身同源的小模型；

    • 过度依赖最强模型：不考虑成本或任务适配性。

  • 可控性问题：现有工具使用代理在成本效率和用户偏好方面控制能力有限。

ToolOrchestra 方法概述

为解决上述问题，作者提出 ToolOrchestra，训练一个小型语言模型（8B 参数）作为协调器，通过强化学习（RL）进行端到端优化。其特点包括：

  • 多轮推理与工具调用交替进行；

  • 工具集多样：基础工具（搜索、函数）、专用模型（代码、数学）、通用模型（GPT-5、Claude）；

  • 奖励设计：综合考虑三个目标：

    1. 最终结果的正确性；

    2. 资源使用的效率；

    3. 用户偏好对齐。

为支持 RL 训练，作者构建了一个自动数据合成管道，生成跨 10 个领域的数千个可验证多轮工具使用样本，形成公开数据集 ToolScale。

实验结果与贡献

在多个挑战性任务上的实验表明：

  • Orchestrator 在 HLE 上显著优于现有方法，且计算成本更低；

  • 在 τ²-Bench 上，仅在约 40% 的步骤中调用 GPT-5，其余使用更低成本工具，仍优于始终使用 GPT-5 的代理；

  • 在 FRAMES 上表现出良好的泛化能力，适应新任务和工具。

主要贡献总结

  1. 提出 ToolOrchestra 方法，训练小型模型作为协调器，整合多种工具与模型；

  2. 设计多目标奖励机制，兼顾结果正确性、效率与用户偏好；

  3. 实验证明 Orchestrator 在多个基准上达到 SOTA，计算资源消耗远低于前沿模型，且具备良好的泛化能力。

2 Agentic Problem Formulation

2.1 任务建模

本节将多轮工具调用的智能体任务形式化为一个马尔可夫决策过程（MDP），表示为：

\[ \mathcal{M}=(\mathcal{U},\mathcal{S},\mathcal{A},\mathcal{O},\mathcal{T},\mathcal{Z},r,\rho,\gamma) \]

其中：

  • \(\mathcal{U}\)：用户指令空间

  • \(\mathcal{S}\)：环境状态空间

  • \(\mathcal{A}\)：动作空间（即工具调用）

  • \(\mathcal{O}\)：观测空间

  • \(\mathcal{T}(s_{k+1}|s_k,a_k)\)：状态转移函数

  • \(\mathcal{Z}(\cdot|s_{k+1},a_k)\)：观测函数

  • \(r(\tau)\in[0,1]\)：轨迹\(\tau\)的正确性奖励

  • \(\rho(\cdot|u)\)：初始状态分布

  • \(\gamma\)：折扣因子（未在文中详细展开）

每个任务由用户指令 \(u\in\mathcal{U}\) 和用户动作偏好 \(p=(0 \leq p_a \leq 1 \text{ for } a\in\mathcal{A})\) 给定。智能体（Orchestrator）根据策略 \(\pi_\theta(a_k|h_k)\) 选择动作，其中 \(h_k\) 是历史交互序列：

\[ h_k = (u, o_0, a_0, o_1, \dots, a_{k-1}, o_k) \]

每一步动作 \(a_i\) 会带来以下指标：

  • 成本 \(c_i\)

  • 延迟 \(l_i\)

  • 用户偏好匹配度 \(p_{a_i}\)

最终目标是最大化：

  • 正确性奖励 \(r(\tau)\)

  • 用户偏好总和 \(\sum p_{a_i}\)

同时最小化：

  • 总成本 \(\sum c_i\)

  • 总延迟 \(\sum l_i\)

重点总结：本节将任务建模为标准MDP，强调了多目标优化：既要保证任务正确性，又要兼顾用户偏好、成本和延迟。

2.2 多轮交互流程

智能体通过**多轮交互流程（rollout）**逐步完成任务，流程如下：

初始化：

  • 给定系统提示词和用户问题

  • 模型生成以 <EOS> 结尾的初始步骤

每一轮交互包括三个步骤：

  1. 推理（Chain-of-thought）：智能体分析当前状态并规划下一步动作

  2. 动作（Tool call）：选择工具（如API、模型、代码解释器）并指定参数

  3. 观察（Tool response）：执行工具调用，将结果反馈给模型作为下一轮输入

终止条件：

  • 接收到环境的终止信号

  • 达到最大轮数（设定为50轮）

重点总结：该流程采用“推理-动作-观察”循环结构，模拟真实任务中工具调用与反馈的交互过程，具有较强的可执行性和现实意义。

总结

本章节从理论建模（MDP）和实际执行流程（多轮交互）两个层面定义了智能体任务。其中：

  • MDP建模清晰地定义了状态、动作、奖励等要素，并强调了多目标优化

  • 多轮交互流程则具体描述了智能体如何一步步调用工具、获取反馈并推进任务

两者结合，为后续方法设计和实验评估提供了理论基础和执行框架。

3 ToolOrchestra

本节介绍了 ToolOrchestra 的整体设计，其核心思想是训练一个小型语言模型作为智能代理，通过动态选择和使用多种外部工具来解决复杂任务。作者假设，只要模型能够战略性地协调更智能的工具，小型语言模型就足以胜任这一任务，因此选择了 8B 参数规模的模型进行训练。ToolOrchestra 基于端到端的强化学习框架，训练一个称为 Orchestrator 的模型，使其能够生成最优的多步推理和工具使用路径。

3.1 统一工具调用接口

与以往的工具使用代理不同，ToolOrchestra 扩展了工具集，包括领域专用模型，并通过统一接口暴露所有工具。工具以 JSON 格式定义，包括名称、描述和参数类型。

重点内容：

  • LLM 作为工具的描述生成方法：

    1. 随机选取 10 个训练任务；

    2. 获取 LLM 完成这些任务的轨迹；

    3. 使用另一个 LLM 根据任务指令和轨迹生成工具描述。

  • 附录 C 和 D 提供了工具描述示例和完整工具列表。

3.2 端到端代理强化学习

奖励设计

引入三种奖励机制：结果奖励、效率奖励和偏好奖励。

重点公式与内容：

  1. 结果奖励（Outcome Reward）： $\( r_{\text{outcome}}(\tau) = \begin{cases} 1 & \text{if } \text{solved}(\tau), \\ 0 & \text{otherwise}. \end{cases} \)$ 使用 GPT-5 作为评判器，判断任务是否被解决。

  2. 效率奖励（Efficiency Reward）：

    • 计算成本奖励：\( r_{\text{compute}}(\tau) = -\$(\tau) \)

    • 时间延迟奖励：\( r_{\text{latency}}(\tau) = -\text{Clock}(\tau) \)

    • 所有模型（包括闭源模型）的输入输出 token 均按第三方 API 定价系统换算为成本。

  3. 偏好奖励（Preference Reward）：

    • 构造向量 \( M^\tau = [m_{t_1}^\tau, ..., m_{t_n}^\tau, r_{\text{outcome}}, r_{\text{compute}}, r_{\text{latency}}] \)

    • 对每个元素进行归一化处理： $\( M^{\tau}_{\text{normalized}}[k] = \frac{M^\tau[k] - M^{\mathrm{T}}_{\text{min}}[k]}{M^{\mathrm{T}}_{\text{max}}[k] - M^{\mathrm{T}}_{\text{min}}[k]} \)$

    • 最终奖励计算： $\( R(\tau) = \begin{cases} M^{\tau}_{\text{normalized}} \cdot P & \text{if } r_{\text{outcome}}(\tau) = 1, \\ 0 & \text{otherwise}. \end{cases} \)$

    • 其中 \( P \) 是用户偏好向量，表示对各项指标的优化程度。

训练过程

使用 Group Relative Policy Optimization (GRPO) 算法进行策略梯度训练。

重点公式：

  • 优势函数计算： $\( A(\tau) = \frac{R(\tau) - \text{mean}_{\tau \in \mathrm{T}} R(\tau)}{\text{std}_{\tau \in \mathrm{T}} R(\tau)} \)$

  • 目标函数： $\( \mathcal{L}_{\text{GRPO}}(\theta) = \mathbb{E}_{\tau \sim \pi_{\theta}} \left[ \min\left( \text{ratio}_\theta(\tau) A(\tau), \text{clip}(\text{ratio}_\theta(\tau), 1-\epsilon, 1+\epsilon) A(\tau) \right) \right] \)\( 其中 \) \text{ratio}\theta(\tau) = \frac{\pi\theta(\tau)}{\pi_{\text{old}}(\tau)} $

训练技巧

为稳定训练过程，避免 KL 散度爆炸，采用以下过滤机制：

  1. 同质性过滤：当 rollout batch 中奖励标准差小于 0.1 时过滤；

  2. 格式一致性过滤：输出不符合工具调用格式时过滤；

  3. 无效输出过滤：未产生有效答案或输出时过滤。

3.3 数据合成

ToolScale 数据合成流程

由于缺乏验证的代理工具调用数据，作者设计了两步合成流程：

  1. 模拟用户-代理-工具环境：

    • 选择领域 D；

    • 使用 LLM 生成数据库（包括 schema、主体和条目）；

    • 生成常用工具。

  2. 生成多样化任务：

    • LLM 生成领域 D 中的常见意图并转化为具体任务；

    • 每个任务包含任务指令 I、黄金函数调用 A 和必须提及的信息 o；

    • 使用另一个 LLM 增加任务复杂度；

    • 数据过滤标准：

      • 黄金函数调用执行出错；

      • LLM 无法在 pass@88 下解决；

      • 无需任何操作即可解决。

任务解决判断标准：

  • 执行正确性：数据库内容匹配；

  • 过程保真度：必须提及的信息 o 被包含；

  • 操作完整性：操作的数据库条目一致。

用户偏好建模

不同用户对工具使用有不同偏好（如本地搜索 vs 网络搜索），为此构建了偏好指令（PI）与偏好向量（P）的配对。

关键步骤：

  • LLM 生成多样化的 (PI, P) 配对；

  • 另一个 LLM 验证一致性；

  • 分割为训练集 \( \text{Pairs}_{\text{train}} \) 和评估集 \( \text{Pairs}_{\text{eval}} \)；

  • 在训练中使用 Equation (2) 计算奖励，在评估中使用 Equation (6) 计算指标。

工具配置泛化

为增强 Orchestrator 的泛化能力，引入多样化的工具配置：

  • 工具子集随机化：每个训练实例中可用工具子集不同；

  • 价格策略变化：模拟不同用户面对的工具成本差异；

  • 目的是让模型在不同约束下优化策略，提升适应性。

总结

ToolOrchestra 提出了一种基于强化学习的小型语言模型训练框架，通过统一工具调用接口、多维度奖励机制和数据合成策略，使模型能够智能地选择和使用外部工具解决复杂任务。其核心创新包括：

  • 统一工具描述与调用接口；

  • 结合结果、效率和用户偏好的综合奖励机制；

  • 基于 GRPO 的端到端训练方法；

  • 自动化数据合成流程 ToolScale；

  • 用户偏好建模与工具配置泛化策略。

这些设计使得 Orchestrator 能够在不同任务和用户偏好下实现高效、准确的工具调用决策。

4 Experimental Setting

4.1 工具（Tools）

本节介绍了训练和评估中使用的工具集。训练时使用了大量综合工具集，但每个训练实例只采样其中一部分以构建多样化的工具配置（参考 §3.3 数据合成部分）。评估时则固定以下工具集以确保公平比较：

  • 基础工具（Basic tools）：

    • 使用 Tavily 搜索 API 进行网络搜索；

    • Python 沙箱用于代码解释；

    • 使用 Qwen3-Embedding-8B 构建 Faiss 索引进行本地搜索；

    • 还包括特定领域的函数，如 get_flight_status。

  • 专业 LLM（Specialized LLMs）：

    • GPT-5 和 GPT-5-mini 用于代码生成；

    • Qwen2.5-Coder-32B-Instruct 作为另一个代码生成模型；

    • Qwen2.5-Math-72B 和 Qwen2.5-Math-7B 用于数学任务。

  • 通用 LLM（Generalist LLMs）：

    • 包括 GPT-5、GPT-5-mini、Llama-3.3-70B-Instruct 和 Qwen3-32B。

这部分内容较为关键，展示了工具集的多样性，尤其是结合了基础功能、专业模型和通用模型，为后续实验打下基础。

4.2 基线模型（Baselines）

本节对比了 ToolOrchestra 生成的 Orchestrator-8B 与以下基线模型：

  • 基于提示的 LLM 构建的协调器（prompt-based orchestrators）；

  • 现成的单体 LLM 系统，分为三类：

    1. 无工具；

    2. 配备基础工具；

    3. 使用扩展工具集（包括专业模型和强通用模型）。

具体对比模型包括：

  • GPT-5、Claude Opus 4.1、Llama-3.3-70B-Instruct、Qwen3-235B-A22B、Llama-3_3-Nemotron-Super-49B-v1、Qwen3-8B。

该部分为实验对比提供了基准，是评估 Orchestrator 性能的重要参考。

4.3 评估配置（Evaluation Configuration）

实验在三个复杂推理基准上进行：

  • Humanity’s Last Exam (HLE)

  • FRAMES

  • τ²-Bench

详细信息见附录 B。评估中使用官方价格计算专有模型成本，开源模型使用 TogetherAI 的定价系统。推理温度设为 0，允许 Orchestrator 最多 50 轮完成任务。

此部分明确了评估环境和标准，是理解实验结果的基础。

4.4 训练配置（Training Configuration）

  • 使用 Qwen3-8B 作为基础模型；

  • 在 GeneralThought-430K 数据集和合成数据（参考 §3.3）上训练；

  • 训练参数：

    • 学习率：1e-6；

    • 最大输入序列长度：24,000；

    • 最大生成长度：8,000；

    • 训练 batch size：16；

    • rollout batch size：8；

    • rollout 阶段允许最多 50 轮完成任务；

    • 使用 16 块 NVIDIA H100 GPU 进行训练。

该部分提供了训练细节，有助于理解模型构建过程。

表格 1：Orchestrator-8B 与基线模型对比

表格展示了在 HLE、FRAMES 和 τ²-Bench 三个任务上的性能对比，包括准确率（↑越高越好）、成本（↓越低越好）和延迟（↓越低越好）。

关键观察：

  • 无工具模型：Qwen3-8B、Llama-Nemotron-49B 等在 HLE 和 FRAMES 上表现较差，说明工具的重要性。

  • 基础工具模型：性能有所提升，但仍然低于使用专业和通用模型的组合。

  • 基础工具 + 专业 + 通用模型：显著提升性能，GPT-5 和 Qwen3-235B-A22B 表现较好。

  • Orchestrator-8B：

    • 在所有任务上均优于其他模型，HLE 达到 37.1，FRAMES 76.3，τ²-Bench 80.2；

    • 成本和延迟也优于大多数模型，分别为 9.2 美分和 8.2 分钟。

备注：

  • GPT-5 的 τ²-Bench 表现未能完全复现（原报告为 84.2，实验中仅达 77.7）；

  • τ²-Bench 在无工具情况下无法解决；

  • HLE 的“现有 SOTA”结果基于完整数据集，而其他模型仅基于文本子集。

总结

本章节详细介绍了实验所用的工具集、基线模型、评估与训练配置，并通过表格展示了 Orchestrator-8B 相比其他模型在多个复杂推理任务上的优越性能。重点在于：

  • 工具的引入显著提升模型表现；

  • 结合基础工具、专业模型和通用模型的 Orchestrator-8B 在准确率、成本和延迟方面均优于现有模型；

  • 实验设计严谨，涵盖多个复杂推理基准，并考虑了成本与效率的平衡。

5 Experimental Results

本节主要展示了 Orchestrator 在多个基准测试（HLE、FRAMES 和 τ²-Bench）中与各种基线方法的对比结果。以下是详细分析：

1. 基线方法表现不佳

  • 无工具的提示方法：如 Qwen3-235B-A22B 和 Llama-3.3-70B 在多个任务中表现较差，说明这些基准任务本身具有挑战性，需要工具或额外推理机制。

  • 仅使用工具的小模型：如 Qwen3-8B 在 HLE 上仅得 4.7，表明仅靠工具无法弥补模型能力的不足。

2. 工具与模型结合提升性能

  • 部分模型结合工具后性能提升：

    • Claude Opus 4.1 在 HLE 上从 11.7 提升至 19.8，FRAMES 从 58.2 提升至 63.5；

    • 但代价是成本增加 2.8 倍，延迟增加 4 倍。

  • 结合工具与大模型（如 Qwen3-235B-A22B）：

    • HLE 从 14.0 提升至 32.8；

    • FRAMES 从 39.5 提升至 74.2；

    • 但成本和延迟也翻倍。

问题：不同模型在结合工具后的提升效果不一致，如 GPT-5 在使用工具和模型后反而性能下降，因其倾向于调用 GPT-5-mini（见 §6.1）。

3. Orchestrator-8B 表现突出

  • 在 HLE 和 FRAMES 上表现优异：

    • HLE 得分：37.1

    • FRAMES 得分：76.3

    • 超过所有基线方法。

  • 在 τ²-Bench 上：

    • 比 GPT-5 使用基础工具高出 2.5%，显示其强大的函数调用能力。

  • 与 GPT-5 和 Qwen3-235B-A22B 对比：

    • 相比 GPT-5 使用工具（HLE 35.1）和 Qwen3-235B-A22B 使用工具+模型（HLE 32.8），

    • Orchestrator-8B 提升了 +2 到 +4.3 个绝对点，

    • 同时仅消耗极低的成本和时间。

4. 关键优势

  • 参数量小但性能强：Orchestrator-8B 仅 80 亿参数，

    • 却能协调更强大的模型（如 GPT-5），

    • 实现更高性能和更低开销。

5. 结论

实验结果充分证明了：

  • ToolOrchestra 架构的有效性；

  • Orchestrator 模型在性能与效率上的双重优势；

  • 工具与模型协同调度策略的优越性。

总结：Orchestrator 在多个基准测试中显著优于现有方法，且资源消耗更低，验证了其作为高效模型与工具调度器的潜力。

6 Analysis

6.1 工具使用分析（Tool Use Analysis）

本节通过图5展示了不同模型作为“协调器”时调用各类工具的比例。重点发现如下：

  • GPT-5 和 Claude Opus 4.1 的调用偏好不同：

    • Claude Opus 4.1 主要依赖 GPT-5；

    • GPT-5 更倾向于使用 GPT-5-mini。

  • Orchestrator-8B 的策略更优：

    • 它能更均衡地调用不同工具，不偏向某一特定模型；

    • 在性能相当或更优的前提下，显著降低了调用成本。

图5展示了平均在 HLE、Frames 和 τ²-bench 任务中的工具调用比例，表15（附录）提供了详细统计数据。

6.2 成本分析（Cost Analysis）

图6展示了性能与成本之间的关系，评估了在不同任务回合数（turns）限制下的表现。

  • 随着允许的回合数增加（即成本增加），所有模型性能提升；

  • Orchestrator-8B 在相同预算下表现优于 GPT-5、Claude Opus 4.1 和 Qwen3-235B-A22B；

  • 在更低成本下达到相近或更优性能，说明其在异构工具管理上的高效性。

结论：Orchestrator-8B 能在控制成本的同时，提升整体系统的智能边界。

6.3 泛化能力（Generalization）

本节测试了 Orchestrator-8B 在训练中未见过的模型配置下的表现，包括：

  • 查询生成器：Claude Opus 4.1、o3-mini、GPT-4o；

  • 代码生成器：Claude Opus 4.1、Claude Sonnet 4.1、Codestral-22B；

  • 数学模型：OpenMath-Llama-2-70b、DeepSeek-Math-7b；

  • 通用模型：Claude Opus 4.1、Claude Sonnet 4.1、Gemma-3-27b-it。

表2展示了在 HLE、Frames 和 τ²-Bench 上的性能与成本对比：

模型

HLE（↑）

Frames（↑）

τ²-Bench（↑）

成本（↓）

延迟（↓）

Orchestrator-8B

22.0

73.8

48.8

34.8

8.2

结论：

  • Orchestrator-8B 能根据模型描述理解新模型的能力与局限；

  • 在未见过的模型配置下仍能实现最优性能和最低成本；

  • 训练中多样化的工具配置有效提升了其泛化能力。

6.4 用户偏好（User Preferences）

本节评估了 Orchestrator-8B 在测试时适应用户偏好的能力，使用了带有偏好指令的测试集，并通过附录L定义的“偏好感知奖励”来衡量。

表3展示了各模型在 HLE、Frames 和 τ²-Bench 上的偏好适应表现：

模型

HLE（↑）

Frames（↑）

τ²-Bench（↑）

Orchestrator-8B

46.7

68.4

79.5

结论：

  • 即使是 GPT-5 等强模型也难以完全遵循用户偏好；

  • Orchestrator-8B 显著优于其他模型，展现出更强的用户偏好适应能力。

总结

第6章通过四个维度全面分析了 Orchestrator-8B 的性能优势：

  1. 工具调用策略更均衡、更高效；

  2. 在相同性能下成本更低，具备更强的成本效益；

  3. 在未见过的模型配置下仍能保持高性能，泛化能力强；

  4. 对用户偏好的适应能力显著优于单体模型。

这些分析验证了 Orchestrator-8B 在多模型、多工具协同中的优越性与实用性。

8 Conclusion

本章节总结了论文的主要研究成果与未来展望：

主要内容总结：

1. 方法概述

作者提出了 ToolOrchestra，一种通过端到端强化学习训练的小型“协调模型”（Orchestrator），用于统一调用各种工具和专用模型。该方法不依赖静态规则或监督学习，而是通过强化学习让模型自主学习如何根据任务需求动态选择工具。

2. 核心贡献

  • Orchestrator 的训练方式：通过结合以下三种奖励机制进行强化学习：

    • 结果质量（Outcome quality）

    • 执行效率（Efficiency）

    • 人类偏好（Human preference） 这使得模型能够在性能与成本之间进行动态权衡。

  • 数据集贡献：为了支持强化学习训练，作者构建了一个复杂的合成数据集 ToolScale，模拟用户-代理-工具之间的交互场景。

3. 实验结果

在多个具有挑战性的基准任务上进行了实验，结果显示：

  • 所提出的 Orchestrator-8B 模型在性能上达到了最先进水平（state-of-the-art）。

  • 相比于更大参数量的模型，Orchestrator-8B 在成本（计算资源、推理开销）方面显著更低。

4. 未来展望

作者提出未来的研究方向是构建更复杂的递归式协调系统（recursive orchestrator systems），以提升智能上限，同时增强处理日益复杂“代理任务”（agentic tasks）的效率。

重点内容强调：

  • 强化学习策略：通过多目标奖励机制训练 Orchestrator 是本研究的核心创新。

  • 成本与性能的平衡：在保证性能的同时显著降低模型使用成本，是该方法的重要优势。

  • ToolScale 数据集：为后续研究提供了高质量的合成训练与评估环境。

数学/算法相关说明：

虽然本节未详细列出数学公式，但提到了强化学习的奖励机制设计，包括：

  • 结果质量奖励 \( R_{\text{quality}} \)

  • 效率奖励 \( R_{\text{efficiency}} \)

  • 人类偏好奖励 \( R_{\text{preference}} \)

这些奖励函数共同构成了强化学习的目标函数，用于优化 Orchestrator 的策略。

总结：

本章强调了 ToolOrchestra 在工具调用与模型协调方面的创新性，展示了其在性能、效率和成本控制方面的优势，并为未来研究指明了方向。

Appendix A Pilot Study

本节旨在评估**简单提示（simple prompting）**方法在配置现成语言模型作为“协调器（orchestrator）”时的有效性。

实验设置

  • 使用了 GPT-5 和 Qwen3-8B 作为候选协调器。

  • 提示模板与正文第4节相同。

  • 可调用的工具模型包括：GPT-5、GPT-5-mini、Qwen3-32B、Qwen2.5-Coder-32B。

  • 目标是让协调器在保证效果的同时，尽可能降低成本。

  • 在300个HLE问题上运行，设置为 max_tokens=32,000 和 temperature=0。

  • 监控每个协调器调用不同工具模型的频率。

实验结果

  • 当Qwen3-8B作为协调器时：

    • 有 73% 的情况调用了 GPT-5。

    • 表现出一种自我增强偏见（self-enhancement bias），即偏好调用与自身相似或更高级的模型。

  • 当GPT-5作为协调器时：

    • 有 98% 的情况调用 GPT-5 或 GPT-5-mini。

    • 表现出一种他人增强偏见（other-enhancement bias），即偏好调用更强的模型，而不考虑成本。

关键结论

  • 简单提示方法导致协调器的调用模式严重失衡。

  • 这些偏见表明，现成模型作为协调器时，其决策缺乏平衡性与成本意识，从而影响整体协调效果。

  • 因此，作者提出 ToolOrchestra 方法：训练一个专用的小型协调器，以更智能地决定何时、如何调用更强大的语言模型。

重点强调

  • 数学与数据：

    • 实验参数明确：max_tokens=32,000、T=0。

    • 调用比例具体：73% 和 98%，具有显著统计意义。

  • 术语：

    • 提出了两个新概念：自我增强偏见与他人增强偏见，用于解释模型的非理性调用行为。

  • 动机驱动：

    • 本研究直接推动了 ToolOrchestra 的设计动机：通过训练专用协调器来克服这些偏见。

Appendix B Evaluation Benchmarks

本节介绍了三个用于评估模型能力的基准测试数据集，分别侧重于复杂推理、检索增强生成和工具使用能力。

1. Humanity’s Last Exam (HLE)

  • 简介：HLE 是一个大规模基准测试集，包含博士级别水平的题目，涵盖数学、人文、自然科学等多个领域。

  • 重点内容：

    • 用于评估模型在迭代搜索和深度推理方面的能力。

    • 题型包括选择题和简答题，其中10–14%的题目需要图像理解。

    • 本研究使用的是纯文本子集，设计上具有歧义性低、不能通过简单网页搜索解决的特点。

  • 不重要内容精简：数据来源和构建细节未详细展开。

2. FRAMES

  • 简介：用于端到端评估检索增强生成（RAG）的性能。

  • 重点内容：

    • 覆盖事实性、检索准确性和推理能力三大维度。

    • 包含824个多跳问题（multi-hop questions），每个问题需要结合2–15篇维基百科文章进行解答。

    • 问题类型多样，包括数值推理、表格理解、时间推理和多约束条件推理。

  • 不重要内容精简：未详细说明数据集的构建过程。

3. τ²-Bench（τ²-Bench）

  • 简介：用于评估模型在与用户对话中使用工具和解决问题的能力。

  • 重点内容：

    • 涉及三个实际领域：电信、零售和航空。

    • 强调模型在真实场景下的交互式问题解决能力。

  • 不重要内容精简：具体任务示例未展开说明。

总结：本节介绍了三个不同侧重点的评估基准，分别用于测试模型的复杂推理能力、检索增强生成能力以及工具使用与对话解决问题能力。每个数据集都强调了任务的复杂性和现实性，具有较高的挑战性。

Appendix C Model description for Qwen3-32B

本节主要介绍了Qwen3-32B模型在多个领域的性能表现，包括数学、科学、逻辑推理、人文学科以及编程能力等方面。

数学与定量推理

模型在数学和定量推理方面表现出色，能够解决复杂的数学问题，仅在高度专业化或计算密集型任务中表现不佳。

科学领域知识

  • 生物学：表现出较强的理解和应用能力。

  • 物理与工程：表现良好，具备扎实的知识基础。

  • 化学：整体表现一般，尤其在精确命名法和InChI输出方面存在明显不足。

逻辑推理能力

模型在逻辑问题解决方面能力较强，显示出良好的分析与推理水平。

人文学科知识

在人文学科方面表现中等偏下，知识掌握不均衡，尤其在一些冷门学术细节上存在明显空白。

编程与函数调用能力

编程能力中等，能够完成基本的代码生成和函数调用任务，但偶尔会在参数使用上出错。

总体评价

Qwen3-32B具有广泛的知识面和较强的分析能力，但在以下任务中准确性下降：

  • 非常狭窄或专业化的任务

  • 最新研究成果的应用

  • 需要精确记忆或计算的任务，尤其是化学信息学相关任务

（注：本节未包含数学公式、算法步骤或表格数据。）

Appendix D Tools in training

本节列出了在训练过程中使用的所有工具，并通过在每次示例回放（rollout）时随机选择其中一部分，来模拟工具在实际应用中可能存在的异构可用性。

• Query Writer（查询生成器）

该工具用于生成查询语句，使用的模型包括：

  • GPT-5、GPT-5-mini [23]

  • meta-llama/Llama-3.3-70B-Instruct、meta-llama/Llama-3.1-8B-Instruct [26]

  • deepseek-ai/DeepSeek-R1 [57]

  • nvidia/Llama-3_1-Nemotron-Ultra-253B-v1 [29]

  • microsoft/Phi-4-mini-instruct [58]

  • google/gemma-3-27b-it [33]

  • Qwen/Qwen3-32B [27]

这些模型主要用于生成高质量的查询语句，支持多模型混合使用，增强训练的多样性。

• Code Writer + Interpreter（代码生成与执行）

代码生成使用以下模型：

  • GPT-5、GPT-5-mini [23]

  • bigcode/starcoder2-15b [59]

  • Qwen/Qwen2.5-Coder-32B-Instruct [24]

此外，还实现了一个 Python 沙箱环境，用于执行生成的代码并验证其正确性。

• Math Models（数学模型）

专门用于处理数学问题的模型：

  • Qwen/Qwen2.5-Math-72B

  • Qwen/Qwen2.5-Math-7B [25]

这两个模型经过专门优化，适合处理复杂数学推理任务。

• Generalist Models（通用模型）

用于处理多种任务的通用大模型，包括：

  • GPT-5、GPT-5-mini [23]

  • meta-llama/Llama-3.3-70B-Instruct、meta-llama/Llama-3.1-8B-Instruct [26]

  • deepseek-ai/DeepSeek-R1 [57]

  • nvidia/Llama-3_1-Nemotron-Ultra-253B-v1 [29]

  • microsoft/Phi-4-mini-instruct [58]

  • Qwen/Qwen3-32B [27]

这些模型在多个领域表现良好，适用于多样化任务的训练。

总结

本附录详细列出了训练中使用的各类工具，包括查询生成、网络搜索、本地检索、代码编写与执行、数学推理和通用任务处理模型。通过在训练中随机选择不同子集，模拟了工具在实际部署中可能存在的异构性与不确定性。其中，GPT-5、Qwen系列模型、Llama系列模型等被多次使用，体现了其在多任务训练中的通用性和重要性。

Appendix E Third-party API

本节列出了我们用于训练的第三方 API 及其定价配置，具体如下：

  • TogetherAI：https://www.together.ai/

  • Venice AI：https://docs.venice.ai/overview/about-venice

  • Chutes：https://chutes.ai/

  • NEBIUS：https://nebius.com/

  • Lambda：https://lambda.ai/

  • Hyperbolic：https://docs.hyperbolic.xyz/docs/welcome-to-hyperbolic

  • Cloudflare：https://developers.cloudflare.com/

  • Novita：https://novita.ai/

  • AIML：https://aimlapi.com/

  • Fireworks AI：https://fireworks.ai/

在评估过程中，为了实现公平比较，我们统一使用 Together AI 的定价标准进行分析。

总结说明：

  • 本节主要提供第三方 API 的链接和使用背景，没有涉及数学公式、算法步骤或表格数据。

  • 重点在于：Together AI 的定价被用作评估基准，其余 API 主要用于训练阶段。

Appendix F Humane preference example

内容总结：

本节提供了一个具体的人类偏好示例，用于说明用户如何根据自身需求对工具和模型进行选择。

工具列表（Tools）

  • 工具列表 TT 包括以下工具（按顺序）：

    1. Web search（网络搜索）

    2. Local search（本地搜索）

    3. Qwen/Qwen3-235B-A22B

    4. meta-llama/Llama-3.3-70B-Instruct

    5. o3-mini

    6. o3

这部分内容主要是工具的列举，属于背景信息，不涉及重点内容，因此可以简要了解。

偏好指令（Preference instruction, PIPI）

  • 用户身份：公司员工

  • 场景描述：服务器中包含敏感信息，且服务器拥有大量 GPU，因此可以部署开源模型或检索器

  • 偏好目标：尽可能避免使用 API 调用

这是本节的重点内容之一，明确表达了用户的实际使用场景和偏好倾向。

偏好向量（Preference vector, PP）

  • 偏好向量为：PP = [0,1,1,1,0,0,0,0,0]

  • 向量解释：

    • 前6位分别对应 TT 中的6个工具（1表示偏好使用，0表示不偏好）

    • 后3位对应 §3.2 中定义的三个指标：准确性（accuracy）、成本（cost）、延迟（latency）

偏好工具分析：

  • 偏好的工具为：

    • 第2项：local search（本地搜索）

    • 第3项：Qwen/Qwen3-235B-A22B

    • 第4项：meta-llama/Llama-3.3-70B-Instruct

  • 不偏好使用：

    • Web search、o3-mini、o3 等工具

  • 对性能指标（准确性、成本、延迟）没有特别偏好（后三位为0）

这是本节的核心内容，通过偏好向量清晰地表达了用户对不同工具的选择倾向。

总结

本节通过一个具体的例子，展示了如何将用户的实际需求转化为对工具的偏好向量。重点在于：

  • 用户希望避免使用 API（如 Web search）

  • 倾向于使用本地部署或开源模型（如 local search、Qwen、Llama）

  • 偏好向量 PP 明确指出了用户偏好的工具

该示例为理解用户偏好建模提供了具体参考，有助于在实际应用中设计更符合用户需求的工具调度策略。

Appendix G Use of LLMs Disclosure

本节内容较为简短，主要说明了在论文撰写过程中使用大语言模型（LLMs）的情况：

  • 使用情况：作者使用了 GPT-5 对论文的多个部分进行了语言润色，包括 摘要（Abstract）、引言（Introduction）、方法论（Methodology） 和 实验（Experiments） 部分，目的是提升语法准确性、表达清晰度和整体可读性。

  • 研究原创性声明：尽管使用了 GPT-5 进行语言优化，但论文中的研究思路、方法设计、实验实施与结果分析全部由作者独立完成，确保了研究工作的原创性和学术诚信。

本节内容属于补充说明性质，没有涉及数学公式、算法步骤或表格数据。

Appendix H Generalization of pricing configurations

在正文第6.3节中，作者已经探讨了 Orchestrator-8B 模型对未见过的工具的泛化能力。
本附录则进一步研究该模型在不同定价机制下的泛化能力，即在工具种类不变但其使用成本不同的情况下，模型是否能够调整其调用策略，以实现更优的性能、效率和用户偏好对齐。

实验设置与方法

  • 测试方式：在训练过程中未见过的定价配置下测试 Orchestrator-8B 的表现。

  • 具体配置：采用来自 deepinfra 的定价方案（见表4）。

  • 目标：模拟现实场景中不同用户面对不同工具成本的情况，验证模型是否能自适应调整策略。

实验结果

根据表4的结果，Orchestrator-8B 在该定价配置下：

  • 性能优异；

  • 成本效率高；

  • 准确率良好。

结论

这些结果表明，通过在多种定价配置下进行训练，Orchestrator-8B 能够学习到更通用的调度策略，不依赖于特定的工具成本设定，从而在多种用户场景中都具有良好的泛化能力。

📌 重点总结：

  • 模型具备在不同工具成本下自动调整策略的能力；

  • 表4展示了模型在 deepinfra 定价配置下的优异表现；

  • 说明模型训练中引入多样化定价配置的有效性，增强了其实际应用的适应性。

Appendix I Data Synthesis

内容概述：

为了支持 Orchestrator 的端到端强化学习（Reinforcement Learning, RL）训练，需要大量用户-代理-工具交互的高质量数据。由于真实数据稀缺，作者设计了一个两步数据生成流程：

  1. 模拟用户-代理-工具环境：

    • 选择一个领域 \( D \)，使用大语言模型（LLM）生成数据库，包括数据库模式（schema）、主要关注的主题和数据库条目。

    • 每个数据库条目经过严格检查，确保其一致性、符合模式要求，并在内容、逻辑和实体之间保持一致。

    • 基于领域 \( D \)，LLM 还生成常用工具的 API。

  2. 生成多样化的任务和解决方案：

    • LLM 提出该领域常见的任务意图，并基于数据库信息将其转化为具体任务。

    • 每个任务包含：

      • 任务指令 \( I \)

      • 黄金函数调用序列 \( A = a_1, a_2, ..., a_l \)

      • 必须提及的信息 \( o \)，在解决任务过程中需在对话中体现

    • 使用另一个 LLM 对任务进行复杂化，例如增加约束条件，以提升任务难度。

数据质量控制：

为确保合成数据质量，作者对生成的数据进行过滤，剔除以下情况：

  1. 黄金函数调用执行报错的任务；

  2. LLM 在 pass@8 测试中无法解决的任务；

  3. 不需要任何操作即可完成的任务。

任务解决评估标准：

定义轨迹 \( \tau \) 是否成功解决任务的三个标准：

  1. 执行正确性（Execution Correctness）： 轨迹 \( \tau \) 与黄金函数调用 \( A \) 执行后的数据库内容一致；

  2. 过程保真度（Process Fidelity）： 轨迹 \( \tau \) 中必须提及预定义信息 \( o \)；

  3. 操作完整性（Operation Completeness）： 轨迹 \( \tau \) 中应包含黄金轨迹 \( A \) 中涉及的所有数据库操作。

只有满足以上三项标准，才认为任务被成功解决。

实验结果（表4）：

表4展示了不同模型在性能、成本和延迟方面的对比，其中 Orchestrator-8B 表现最优：

模型名称

HLE (↑)

Frames (↑)

τ²-Bench (↑)

成本 (↓)

延迟 (↓)

Qwen3-8B

29.7

68.2

71.9

27.4

17.9

Nemotron-49B

25.6

57.8

66.3

24.3

17.2

Llama-3.3-70B

19.6

52.2

55.4

17.9

12.0

Qwen3-235B-A22B

32.4

74.1

75.3

27.9

20.8

Claude Opus 4.1

34.5

72.3

76.4

52.3

25.1

GPT-5

20.8

57.3

61.9

17.5

13.2

Orchestrator-8B

36.9

76.6

80.4

7.5

7.8

重点总结：

  • Orchestrator-8B 在所有指标上均优于其他模型，尤其在成本和延迟方面显著降低，说明其具有良好的性价比和高效性。

  • 数据合成流程强调了任务多样性与质量控制，确保生成数据适合强化学习训练。

  • 评估标准（执行正确性、过程保真度、操作完整性）为任务解决提供了全面的衡量方式。

Appendix J Breakdown of ToolScale

该表格展示了 ToolScale 数据集在十个不同领域中的分布情况，包括工具数量、数据库条目数量和任务数量。这些领域包括金融（Finance）、体育（Sport）、电子商务（E-commerce）、医学（Medicine）、娱乐（Entertainment）、铁路（Railway）、餐饮（Restaurant）、教育（Education）、旅游（Travel）和天气（Weather）。

重点分析：

  • 工具数量：

    • 娱乐领域（Entertainment）工具最多，为 24 个；

    • 天气领域（Weather）工具最少，为 14 个；

    • 其他领域工具数量大多集中在 15~25 之间。

  • 数据库条目数量：

    • 医学领域（Medicine）数据库条目最多，达到 920 条；

    • 天气领域（Weather）最少，为 549 条；

    • 数据库规模反映了各领域信息复杂度的差异。

  • 任务数量：

    • 医学领域（Medicine）任务最多（622 个），表明该领域应用场景广泛；

    • 天气领域（Weather）任务数量相对适中（375 个），但工具较少，可能意味着任务与工具之间的复用性较高。

总结：

表 5 提供了 ToolScale 数据集的详细统计，展示了不同领域在工具数量、数据规模和任务复杂度上的差异。其中医学和娱乐领域具有较高的复杂度，而天气和餐饮领域则相对简洁。这些数据为后续模型评估和跨领域分析提供了基础。

Appendix K Data synthesis prompts and examples

表6：生成领域主题的模型提示

内容总结：
该表提供了一个提示模板，用于让模型生成某个特定领域的主要主题（subjects）。

  • 输入格式： Generate a list of major subjects in {domain}.

  • 输出格式： 使用列表形式，如 [[subject1, subject2, ...]]。

  • 重点： 用于构建数据库和任务生成的基础知识框架。

表7：生成数据库模式的模型提示

内容总结：
该表提供了一个模板，用于根据已有示例模式（{demo_schema}）生成新的模式。

  • 输入格式： 提供一个示例模式，要求模型生成类似格式的模式。

  • 输出格式： 使用代码块包裹的模式定义。

  • 重点： 保证生成的模式结构统一，便于后续数据条目生成与验证。

表8：生成数据库条目的模型提示

内容总结：
该表定义了如何根据给定的模式生成数据库记录。

  • 输入格式： 提供模式 {schema} 和主题 {subject}。

  • 输出格式： 使用 JSON 格式，如 { "...": ..., ... }，并用代码块包裹。

  • 关键要求： 数据值必须与模式定义一致，并在不同字段中保持一致性。

表9：验证数据库条目的模型提示

内容总结：
该表提供了一个验证数据库条目是否符合要求的提示模板。

  • 输入格式： 提供模式 {schema} 和数据库条目 {db_entry}。

  • 检查条件：

    1. 条目是否符合模式字段和类型定义。

    2. 条目中的值是否一致（如 id、name）。

    3. 内容是否合理、自然。

  • 输出格式： 以 JSON 形式返回每个条件是否满足。

表10：生成函数的模型提示

内容总结：
该表用于生成某个领域中常用函数的提示。

  • 输入格式： 提供一个示范函数 {demo_function}。

  • 输出要求： 按照示范格式生成函数代码。

  • 重点： 生成的函数应能支持后续任务和意图的实现。

表11：生成意图的模型提示

内容总结：
该表用于基于已有函数生成实际应用场景中的意图（intents）。

  • 输入格式： 提供一组函数 {functions}。

  • 输出格式： 列表形式的意图，如 ["purpose 1", "purpose 2", ...]。

  • 重点： 意图应真实、实用，能通过函数实现。

表12：生成任务的模型提示

内容总结：
该表用于根据函数、数据库和意图生成具体任务。

  • 输入格式： 函数、数据库和意图。

  • 输出格式： 使用预定义任务模板 {task_template}。

  • 作用： 构建可用于测试或训练的结构化任务数据。

表13：演化任务的模型提示

内容总结：
该表用于对已有任务进行扩展，增加复杂性。

  • 输入格式： 函数、数据库和旧任务 {task}。

  • 输出要求： 在旧任务基础上添加约束、实体或复杂情境。

  • 目的： 生成更具挑战性的任务，提升系统泛化能力。

表14：数据库模式示例

内容总结：
该表提供了一个电影领域的数据库模式示例。

  • 结构说明： 包含电影 ID、标题、类型、时长、评级、语言、字幕、格式、上映日期、演员表、工作人员、简介等字段。

  • 重点字段：

    • genres：枚举类型，如动作、喜剧、科幻等。

    • cast：包含演员姓名和角色的列表。

    • crew：导演、编剧、制片人、配乐等信息。

  • 用途： 作为表7中模式生成的参考示例。

总结：
本附录提供了一整套用于合成结构化数据的提示模板，涵盖从领域主题提取、模式设计、数据生成、验证、函数与意图生成，到任务构建与演化。这些模板可用于自动化构建高质量的数据库与任务集，适用于数据生成、系统测试、模型训练等场景。

Appendix L Calculation of rewards for preference-aware benchmark

附录 L 偏好感知基准奖励的计算

奖励计算方法

在训练过程中，直接使用论文中的公式（2）来计算奖励。在评估过程中，采用以下步骤：

  1. 定义工具集和轨迹向量：

    • 给定工具集 {t₁, t₂, …, tₙ} 和轨迹 τ，定义向量 Mτ = [mₜ₁τ, mₜ₂τ, …, mₜₙτ, routcomeτ, rcomputeτ, rlatencyτ]，其中 mₜ∙τ 表示工具 t∙ 在轨迹 τ 中被调用的次数。

  2. 获取基线向量：

    • 使用初始检查点（如 Qwen3-8B）运行基准测试，记录基线向量 M₀。

  3. 获取评估模型的向量：

    • 运行训练后的检查点 CKPTs，得到向量 Msτ(e)。

  4. 归一化处理：

    • 对 Msτ(e) 进行归一化处理，公式如下： $\( M_{\text{normalized},s}^{\tau(e)}[k] = \begin{cases} \frac{M_s^{\tau(e)}[k]}{\max(1, M_0^{\tau(e)}[k])} & \text{if } 1 \leq k \leq n+1 \\ \frac{M_0^{\tau(e)}[k]}{\max(1, M_s^{\tau(e)}[k])} & \text{otherwise} \end{cases} \)$

  5. 计算偏好感知奖励：

    • 最终奖励计算公式如下： $\( R^e(\tau) = \begin{cases} M_{\text{normalized},s}^{\tau(e)} \cdot P & \text{if } r_{\text{outcome}}(\tau) \\ 0 & \text{otherwise} \end{cases} \)$

    • 奖励结果为所有示例的 Re(τ) 之和。

表格分析

表15：工具调用次数

  • 模型对比：Qwen3-8B、Nemontron-49B、Llama-3.3-70B、Qwen3-235B-A22B、Claude Opus 4.1、GPT-5 和 Orchestrator-8B。

  • 结果：Orchestrator-8B 在调用 GPT-5 次数上显著少于其他模型，同时在性能上表现更好。

表16：成本和延迟

  • 模型对比：Qwen3-8B、Llama-Nemotron-49B、Llama-3.3-70B、Qwen3-235B-A22B、Claude Opus 4.1、GPT-5 和 Orchestrator-8B。

  • 结果：Orchestrator-8B 在 τ²-Bench 测试中表现最佳，成本和延迟最低。

总结

本附录详细描述了偏好感知基准奖励的计算方法，并通过表格展示了不同模型在工具调用次数、成本和延迟方面的对比。Orchestrator-8B 在多个指标上表现优异，尤其是在减少 GPT-5 调用次数和降低延迟方面。