Switchcraft：用于智能体工具调用的 AI 模型路由

# Switchcraft：面向智能体工具调用的 AI 模型路由器

**来源**: https://arxiv.org/html/2605.07112

**作者**:
Sharad Agarwal, Microsoft Research, [email protected] &
Pooria Namyar, Microsoft Research, [email protected] &
Alec Wolman, Microsoft Research, [email protected] &
Rahul Ambavat, Microsoft, [email protected] &
Ankur Gupta, Microsoft, [email protected] &
Qizheng Zhang, Stanford, [email protected]

###### 摘要

调用外部工具的智能体 AI 系统虽然强大但成本高昂，导致开发者往往默认使用大型模型，从而造成推理预算的超支。模型路由可以缓解这一问题，但现有的路由器是为聊天补全而非工具使用而设计的。我们提出了 **Switchcraft**，据我们所知，这是首个专为智能体工具调用优化的模型路由器。Switchcraft 以内联方式运行，在确保正确性的前提下选择成本最低的模型。我们在五个函数调用基准测试上构建了一个评估框架，并训练了一个基于 DistilBERT 的分类器，在延迟预算约束下进行部署。Switchcraft 达到了 82.9% 的准确率——持平或超过最佳单个模型——同时将推理成本降低了 84%，每百万次查询节省超过 3,600 美元。我们发现，在工具使用任务中，大型模型并不总是优于小型模型，且名义上更便宜的模型可能因推理过程消耗大量令牌而导致更高的总成本。我们的工作使得在不牺牲正确性的前提下，实现成本感知的智能体 AI 部署。

## 1 引言

智能体 AI 系统——其中大型语言模型（LLM）调用外部工具和 API 以执行复杂任务——正在多个领域成为强大的解决方案 [1 (https://arxiv.org/html/2605.07112#bib.bib1),15 (https://arxiv.org/html/2605.07112#bib.bib15)]，但它们带来了巨大的成本。在对十二个企业团队进行的访谈中，我们发现为辅助工具查询选择模型仍然具有挑战性：团队默认使用大型且广泛使用的模型，导致显著的过度支出——这不仅对支付过高的客户是一个问题，对面临 GPU 基础设施过载的服务提供商而言也是一个问题，即使较小的模型已经足够。

**模型路由** 通过动态为每个查询选择合适的 LLM 来解决这一问题，将简单请求路由到较小模型，并将大型模型保留用于更困难的请求。 prior 工作表明可以大幅节省成本；例如，一项 AWS 服务报告称，通过智能路由实现了 $\sim 43.9\%$ 的成本降低 [9 (https://arxiv.org/html/2605.07112#bib.bib9)]。然而，现有的路由器 [22 (https://arxiv.org/html/2605.07112#bib.bib22),7 (https://arxiv.org/html/2605.07112#bib.bib7),17 (https://arxiv.org/html/2605.07112#bib.bib17)] 针对的是聊天补全，并未解决智能体工具调用的问题。在工具调用中，模型必须在多个步骤中生成精确的工具调用——这与聊天任务的要求根本不同，使得现有路由器不适用。

为了支持智能体工具调用，我们整理了一套多样化的基准测试用于智能体工作负载，并利用它们微调了一个专门的路由模型。我们聚合了五个公开的函数调用基准测试——Berkeley Function Calling Leaderboard (BFCL v3) [24 (https://arxiv.org/html/2605.07112#bib.bib24)]、AWS ConFETTI [3 (https://arxiv.org/html/2605.07112#bib.bib3)]、Salesforce xLAM-60K [36 (https://arxiv.org/html/2605.07112#bib.bib36)]、Glaive Function Calling [11 (https://arxiv.org/html/2605.07112#bib.bib11)] 和 Hermes [20 (https://arxiv.org/html/2605.07112#bib.bib20)]——涵盖了工具使用、多轮交互和平行 API 调用。我们构建了一个统一的评估框架，标准化这些数据集中的数据，在候选 LLM 上执行每个查询，并使用基于抽象语法树（AST）的检查器对工具调用进行鲁棒评分。利用这些信号，我们微调了 **Switchcraft**，一个基于 DistilBERT 的路由器（66M 参数），它以智能体的查询和上下文作为输入，预测最适合执行任务的模型。

**主要结果**。 Switchcraft 达到了 82.9% 的准确率——持平或超过最佳单个模型（GPT-5.3-chat 为 82.3%）——同时将推理成本降低了 84%，每百万次查询节省超过 3,600 美元。相对于总是选择最便宜的正确模型的 oracle（89.4%），Switchcraft 缩小了 37% 的准确率差距。我们还发现，成本较高的模型并不总是优于成本较低的模型（GPT-5.4 以 81.3% 落后于 GPT-5.3-chat 的 82.3%），名义上更便宜的模型可能因输出冗长而产生更高成本，且相同架构的聊天微调路由器表现显著逊于 Switchcraft（附录 O (https://arxiv.org/html/2605.07112#A15)）。据我们所知，这是首个解决工具增强、多轮任务的 LLM 模型选择的系统。

我们的三个主要贡献如下：

-   我们为智能体用例制定了模型路由问题，并确定了关键挑战。
-   我们构建了用于智能体路由的统一评估框架，包括多基准测试标准化、修正的地面实况注释，以及用于鲁棒工具调用评估的基于 AST 的比较框架。
-   我们开发了 Switchcraft，一个基于 DistilBERT 的模型路由器，显著改善了成本与质量的权衡，在接近 oracle 准确率的同时将推理成本降低了 84%。

## 2 动机

**可用工具**: `get_symbol_by_name`, `add_to_watchlist`, `get_stock_info`, `place_order`, `get_order_details`, `send_message`, ...

**第 1 轮 – 用户**: “将 ‘Omega Industries’ 的股票有效地集成到我的观察列表中。”

**正确**:
`get_symbol_by_name(name="Omega Industries")` $\rightarrow$ `{"symbol": "OMEG"}`
`add_to_watchlist(stock="OMEG")`

**第 3 轮 – 用户**: “以当前市场价值执行我们刚添加的股票的 150 股交易。”

**正确**:
`get_stock_info(symbol="OMEG")` $\rightarrow$ `{"price": 457.23, ...}`
`place_order(order_type="Buy", symbol="OMEG", price=457.23, amount=150)`

**错误函数**:
`place_order(order_type="Buy", symbol="OMEG", price=557.23, amount=150)` $\times$
跳过 `get_stock_info` 并使用幻觉或过期的价格会导致订单以错误价格放置。

**错误参数**:
`place_order(order_type="Sell", symbol="OMEG", price=457.23, amount=150)` $\times$
卖出而不是买入：单个错误的参数值导致与预期动作 *相反* 的结果。

**错误数值**:
`place_order(order_type="Buy", symbol="OMEG", price=457.23, amount=1500)` $\times$
`amount` 的数量级错误导致财务承诺增加 10 倍。

**图 1**: 来自 BFCL v3 [24 (https://arxiv.org/html/2605.07112#bib.bib24)] 的动机示例。智能体查询要求在每一步都具有 *正确的函数* 和 *精确的参数值*；小错误（类型错误、值错误、顺序错误）会导致严重的失败。**图 1** (https://arxiv.org/html/2605.07112#S2.F1) 说明了为什么智能体工具调用的路由不同于聊天补全的路由。用户要求 AI 智能体将“Omega Industries”添加到观察列表并下单；完成此请求需要一系列工具调用（解析股票代码、添加到观察列表、获取价格、下单），其中每一步都依赖于前一步。与聊天不同（在聊天中， paraphrase 可能是可以接受的），智能体错误会累积且可能不可逆：幻觉价格会以错误值下单；混淆“Buy”和“Sell”会执行与用户意图 *相反* 的操作；`amount` 中的单个数字错误会导致十倍的财务承诺。

同时，并非所有差异都是错误——独立的并行调用可以以任何顺序发出，字符串参数通常允许语义上等效的形式（例如，“Illinois”与“IL”）；正确的评估器必须接受这些差异（完整讨论见附录 A (https://arxiv.org/html/2605.07112#A1)）。这些特性——顺序依赖性、严格的参数精度以及对差异的选择性容忍——促使我们专门在智能体数据上微调一个路由器，并使用能够捕捉工具调用独特正确性标准的评估指标。

## 3 设计

我们探索了大量的架构、输入表示、评分方法和路由策略（冻结嵌入的 MLP、更大的编码器、LLM-as-a-router、相似度路由、成本加权损失、BLEU 和 LLM-as-judge 评分）；被拒绝的替代方案详见附录 B (https://arxiv.org/html/2605.07112#A2)。**图 2** (https://arxiv.org/html/2605.07112#S3.F2) 显示了最终架构：一个微调管道，摄入函数调用基准测试，在每个候选 LLM 上运行每个查询，通过 AST 比较评分输出，并将生成的偏好数据蒸馏到一个轻量级的 DistilBERT 分类器中；以及一个推理管道，运行分类器和成本模型以选择预测正确的最便宜 LLM。

我们构建了一个专门用于函数调用的路由器，以避免其在聊天等异构工作负载中被稀释。分发到正确的路由器是微不足道的——函数调用请求通过请求体中是否存在 `tools` 参数来识别。

**微调管道**: BFCL, ConFETTI, xLAM, Glaive, Hermes $\rightarrow$ 数据摄入 $\rightarrow$ LLM 推理 (GPT-5.4-nano, Kimi-K2.5, GPT-5.4...) $\rightarrow$ AST 评分 $\rightarrow$ 偏好数据 $\rightarrow$ 路由器微调

**推理管道**: 智能体查询 $\rightarrow$ 智能体路由器 (DistilBERT) + 成本模型 $\rightarrow$ 选择预测正确的最便宜模型 (GPT-5.4-nano, Kimi-K2.5, GPT-5.4...) $\rightarrow$ 工具调用响应 $\rightarrow$ 部署

**图 2**: 系统架构。**左**: 微调管道（摄入基准测试，跨 LLM 运行推理，通过 AST 评分，微调路由器）。**右**: 推理时路由（DistilBERT 分类器和成本模型选择预测正确的最便宜 LLM）。

### 3.1 输入表示

一个关键的设计选择是如何将智能体查询——多轮对话、工具定义和元数据——打包到 DistilBERT 的 512 令牌窗口中。我们的打包操作分为五个步骤：

1.  **最新用户轮次**（即时意图，始终包含）。
2.  **工具签名** 转换为紧凑的 `func_name(param1, param2)` 形式（剥离描述和 JSON-schema 样板等；上限为 100 个子词令牌，超出部分用 `[truncated]` 标记）。
3.  **较早轮次** 以逆时间顺序贪婪添加，直到预算耗尽，优先考虑最近的上下文。
4.  **元数据前言**：三个数值特征：`length`、`num_tools`、`num_turns`，用于感知复杂性的路由，而不仅依赖文本。
5.  **拼接和标记化**（512 令牌截断，动态填充）。

### 3.2 工具调用评分

在我们规模下，执行每个 LLM 发出的工具调用是不可行的：查询涉及数千个不同的、通常是私有的第三方 API。相反，我们通过将其抽象语法树（AST）——函数名称、参数名称、类型和值——与地面实况调用的 AST 进行比较，对每个调用进行静态标记。AST 检查器确定路由器认为哪些（模型，查询）对是“正确”的。

然而，设计一个通用的评分器出乎意料地困难：(1) 同一个调用允许多种语义等效的形式（集合值 vs 列表值参数、省略默认值、替代字符串编码），(2) 工具调用参数可以是任意嵌套的对象，必须通过结构而非直接相等性进行比较，(3) 跨基准测试的相同语法结构（例如，列表的列表）可能具有不同的含义。

**表 1**: 在 GPT-5.3-chat 结果上的 AST 检查器比较。*FN*：我们的检查器接受但 BFCL 拒绝；*FP*：反之。† 仅单轮 BFCL 类别（Simple, Multiple, Parallel, Parallel+Multiple 及其 *Live* 变体）；多轮类别被排除，因为 BFCL 的检查器不在每轮评估记录上运行。

出于这些原因，来自 BFCL [24 (https://arxiv.org/html/2605.07112#bib.bib24)] 的现有 AST 检查器在处理其原生基准测试时表现良好，但在其他所有基准测试上都会失效：对相同的 GPT-5.3-chat 输出评分在其他四个非 BFCL 数据集上得出了低得多的准确率（**表 1** (https://arxiv.org/html/2605.07112#S3.T1)）。通过对所有五个数据集中被拒绝调用的系统研究，我们识别出 BFCL 的 AST 检查器中反复出现的偏差类别；我们在下面总结每一点，附录 D (https://arxiv.org/html/2605.07112#A4)（表 LABEL:tab:ast_checker_examples）中有示例。

1.  **数组顺序敏感性**。BFCL 逐元素比较数组，当模型以不同于地面实况的顺序发出集合值参数时拒绝。我们将扁平数组作为多重集比较，将字典列表作为集合比较。
2.  **无默认参数意识**。BFCL 将地面实况中列出的每个参数视为必需。我们从工具描述中解析默认值，当文档默认值与地面实况匹配时接受省略。
3.  **脆弱的字符串匹配**。大小写、空格、标点和 ISO-8601 时间戳格式的差异会导致虚假不匹配。我们规范化每个字符串，并对多词字符串回退到 DistilBERT 余弦相似度（阈值 0.85）。
4.  **无嵌套结构处理**。BFCL 不识别 JSON-Schema 的 "object" 类型并中止条目；即使修复，它也没有递归比较器。我们添加了缺失的类型，并递归验证每个嵌套对象与其子模式。
5.  **模糊的数组语义**。地面实况中的列表的列表可以意味着 *替代* 有效值的列表或真正的 *嵌套* 数组。我们使用工具调用模式来消除歧义。

使用我们的 AST 检查器，相同的模型在所有五个数据集上显示出更加一致的准确率（**表 1** (https://arxiv.org/html/2605.07112#S3.T1)）。我们通过单元测试、随机条目的手动审查和 LLM-as-judge 评分对其进行了验证。

### 3.3 路由逻辑

在推理时，路由器在两个阶段为每个传入查询选择单个 LLM：

#### 阶段 1：多标签分类。

DistilBERT 分类器为 $K$ 个候选模型中的每一个输出概率，表明该模型正确回答查询的可能性。这些概率以 0.5 为阈值，产生预测正确的模型的二进制向量。

#### 阶段 2：成本感知选择。

给定预测正确的模型集，路由器选择具有 *最低概况成本* 的那个：根据每个候选模型在回答训练查询时观察到的输入/输出令牌计数计算的实际美元成本，乘以其每百万令牌的列表价格（**表 3** (https://arxiv.org/html/2605.07112#S4.T3)；完整公式见附录 C (https://arxiv.org/html/2605.07112#A3)）。这自然地捕捉了 *话痨性*（chattiness）：生成广泛推理或冗长输出的模型比相同每令牌费率下的简洁模型积累更高的概况成本。我们在第 4.8 节 (https://arxiv.org/html/2605.07112#S4.SS8) 中详细分析话痨性。

如果没有模型被预测为正确（所有概率低于 0.5），路由器回退到概率最高的模型（argmax）。这确保了优雅降级：即使分类器不确定，它也会路由到其最佳猜测，而不是拒绝路由。

#### Oracle 路由器。

我们的 oracle 上限使用相同的双阶段逻辑，但拥有完美信息：对于所有查询，包括测试集，它知道哪些模型正确回答并选择最便宜的正确模型。当没有模型正确时，oracle 默认选择最昂贵的模型，为不改变底层模型答案的任何路由器提供紧致的上限。

## 4 评估

我们在五个函数调用基准测试（如下）上评估 Switchcraft，将其与单个 LLM、启发式基线和 oracle 上限进行比较。

### 4.1 数据集

我们结合了五个函数调用基准测试，涵盖了广泛的工具调用复杂度，总计 157,101 个示例（去重后为 122,267 个），跨越 14 个类别（**表 2** (https://arxiv.org/html/2605.07112#S4.T2)）；多样性对于避免过度拟合任何单一基准测试的分布至关重要