提升工具使用智能体速度的推测性宏提交

# 通过推测性宏提交加速工具使用智能体
来源：https://arxiv.org/html/2609.03236
###### 摘要

使用工具的LLM智能体不仅在模型推理上花费实际时间，还消耗在串行的动作-观察循环中，每次工具调用、环境转换和观察结果都可能延迟后续决策。我们提出了推测性宏提交（Speculative Macro Commit, SMC），这是一种面向两层智能体系统的运行时机制：一个大型权威模型生成官方执行轨迹，而一个更快的推测模型则持续在隔离的环境快照上预测并执行未来的动作链。SMC从训练轨迹中挖掘重复出现的多动作骨架，将其存储于宏库中，用于在运行时匹配推测模型预测的动作链。当权威模型的下一个工具调用与预测的第一个动作匹配时，SMC会将剩余的预执行草稿步骤及其观察结果提交至官方轨迹。使用Qwen3.5-27B INT4作为权威模型，Qwen3.5-4B作为推测模型，在τ²-Bench电信子集上，SMC在保持与顺序智能体相当的总准确率的同时，相比推测动作（SA）基线降低了10.23%的延迟，相比顺序执行降低了18.59%。在AppWorld基准测试中，SMC相比SA基线将实际耗时减少了7.7%，相比顺序执行减少了44.9%，任务完成率仅有小幅下降。总体而言，SMC提供了一种实用的方法，可重用多步推测执行并减少智能体延迟，超越了单步推测动作的范畴。我们的代码在此公开（https://github.com/zeyuliu1037/speculative-macro-commit）。

Zeyu Liu⋆Souvik Kundu†Peter A. Beerel⋆
⋆ 南加州大学，洛杉矶，美国 † 英特尔实验室，圣地亚哥，美国
索引词—LLM智能体，推测性执行，推理延迟

## 1 引言

语言智能体正成为软件、数据、网页和客户服务工作流的实用接口[11,5,10]。与进行单次预测的模型不同，工具智能体运行一个循环：它调用模型选择一个动作，在环境中执行该动作，观察结果，并根据观察结果调整下一个决策[12]。这种迭代交互赋予了智能体极大的灵活性，但也造成了仅靠模型吞吐量无法反映的实际时间瓶颈：即使模型服务器批处理良好，单个任务也可能需要等待数十个串行轮次。

这种延迟有多个来源。重复的大模型调用会重新处理长上下文并给缓存管理带来压力[6]。工具编排增加了调度、状态和环境生命周期的开销[3]。工具和环境本身可能主导请求耗时；PASTE报告称，在代表性智能体中，工具执行占总延迟的35%到61%[8]。在这些来源中，主要约束是顺序依赖性：下一个提示通常必须等到前一个动作返回其观察结果后才能构建。基于token级的推测解码[4]使用廉价模型草拟几个token，然后用昂贵的模型进行验证，但它严格在一个模型调用内部操作，无法消除这种跨步骤依赖。

推测动作（Speculative Actions, SA）将草拟后验证的思想从token提升到动作层面[13]。一个快速的推测模型预测可能的未来动作，而一个较慢的权威模型计算下一个经过验证的动作；当权威模型后续同意时，已经启动的动作就可以被提交。然而，核心SA机制仅接受相邻动作步骤粒度的进展：正确的猜测让执行器可以重用下一步的工作，而朴素的更长前瞻带来的收益有限。因此，如何有效提交多步动作仍然是一个未被充分探索的领域。另一条互补的研究路线观察到，工具智能体轨迹包含重复的工具调用序列。例如，AWO[1]挖掘重复出现的工具调用序列，并将其转化为确定性的复合元工具，将多个动作捆绑到一次调用中。当模型选择正确的元工具时，这可以去除几个推理步骤。然而，在我们的实验中，简单地将挖掘出的动作序列作为额外的可调用工具暴露出来并不可靠：像Qwen3.5-27B[7]这样的开源模型很少选择这些挖掘出的宏。这引出了本文的核心问题：

> *重复出现的动作模式能否在不依赖模型选择新元工具的情况下降低智能体延迟？*

我们的答案是推测性宏提交（SMC），其中*宏*是从执行轨迹中挖掘出的重复多动作模式。*提交*意味着接受已执行的草稿工具调用及其返回结果，将其纳入智能体的真实执行历史，这样大模型就不需要再次选择和执行这些步骤。当在较长的动作链中识别出挖掘出的宏库中的某个宏，且该宏的第一个动作与权威动作匹配时，SMC会尝试进行*宏提交*：它将剩余的匹配草稿步骤及其观察结果提交至官方轨迹，从而跳过相应的大模型调用以及环境延迟。由于宏提交并不要求权威模型重新生成和验证每个被跳过的步骤，SMC是一种近似而非严格无损的优化，但经验表明它在降低延迟的同时保持了任务质量。

1. 1\. 动作级推测的端到端运行时。我们构建了一个两层运行时，其中权威模型和推测模型在整个长时间跨度的工具智能体任务中并发运行。执行器测量实际时间延迟，让模型在草拟的动作-观察链上提前运行，并在无法使用推测时回退到普通执行。
2. 2\. 推测性宏提交。我们引入了SMC，它将挖掘出的重复动作模式从模型侧的宏选择转移到执行器侧的验证。执行器首先在模型的预执行动作链中识别宏匹配；在权威模型同意第一个匹配的草稿动作后，SMC可以将剩余的匹配草稿步骤及其观察结果提交至官方轨迹。这跳过了相应的大模型调用，并避免了再次等待已经返回的工具结果，使SMC成为一种近似但受保护的延迟优化。
3. 3\. 在完整工具智能体基准测试上的评估。在τ²-bench电信子集上，使用Qwen3.5-27B INT4作为权威模型，Qwen3.5-4B作为推测模型，SMC运行在匹配单模型基线奖励的同时，将延迟降低了18.59%；相比SA，延迟降低了10.23%。在AppWorld基准测试中，SA相比基线将延迟降低了40.37%，而SMC在小幅牺牲准确率的情况下，进一步将实际耗时降低了7.64%。

## 2 相关工作

推测解码和推测性智能体执行。推测解码通过让一个廉价的草拟模型提出token，由目标模型批量验证，从而加速单次模型调用[4]。这条工作减少了单个模型调用内部的解码延迟，但一个ReAct风格的工具智能体（它在多步操作中交替进行模型推理和工具调用[12]）也会在调用之间产生延迟，因为每个工具结果必须返回后才能形成下一个提示。推测动作将草拟并验证的思想从token扩展到智能体动作，与权威模型并行启动预测的未来API调用，仅当预测匹配时才提交[13]。我们的SMC共享这种动作级视角，但在提交内容上有所不同：它不是一次验证一个动作，而是提交几个已经执行的草稿步骤，用受保护的多步近似换取了单步验证的无损保证。

SMC建立在相同的权威-推测设定之上，但使用了不同的提交规则。在权威模型验证了第一个草拟动作之后，SMC可以提交一个已执行的动作-观察对的匹配后缀，而无需用权威模型验证每个被跳过的动作。这使得多步运行时跳过成为可能，代价是使SMC成为近似而非严格无损。

推测性工具执行系统。近期的LLM服务系统从互补的角度攻击相同的串行LLM-工具循环。PASTE在模型仍在计算时推测性地执行可能的工具调用，利用稳定的应用层控制流和数据依赖[8]，而ThunderAgent[3]和KVFlow[6]通过程序感知的服务以及前缀/缓存管理来减少延迟，而不改变哪些动作进入轨迹。这些系统启发了我们工作的运行时设定：延迟取决于有用的工具工作是否可以移出串行关键路径，而不仅仅是模型调用。

工作流压缩和元工具。智能体工作流优化（AWO）从轨迹中挖掘重复的工具调用序列，并将生成的复合体注册为模型可用的元工具[1]。关键区别在于接口：AWO改变了模型可见的工具集，让模型选择何时调用复合工具，而我们的SMC将挖掘出的步骤作为隐藏的运行时状态，仅在锚点调用被验证后才提交。

## 3 推测性宏提交

### 3.1 执行器角色与状态

SMC在*智能体执行器*（即运行工具-智能体循环的程序）中实现。给定当前任务历史，执行器提示模型进行下一个工具调用，执行该调用，记录返回结果，并重复此过程直到任务完成或步数预算耗尽。因此，执行器不同于语言模型和工具环境：它单独决定哪些动作-结果对成为未来模型调用所见任务历史的一部分。

SMC为这个执行器增加了两个并发运行的模型。*权威模型*是大模型，其工具调用定义了智能体的真实执行。*推测模型*是一个更小、更快的模型，它领先于权威模型运行，试图从已提交的历史H中推测短期的未来工具调用序列。执行器维护H（包含工具调用和返回结果，未来的权威提示将基于此）以及一个实时任务状态E（通过执行H中的调用达到的状态）。模型的调用在一个隔离的草稿状态Eⁱ中执行，因此它们产生返回结果，但不会立即改变实时任务状态。我们将模型的当前输出表示为草稿链Q=(q₁,...,q_D)，其中每个qᵢ包含一个草拟的工具调用及其在草稿状态下执行的结果。一个*宏*是从过去执行中挖掘出的重复多动作模式。一次*提交*是执行器操作，它将已执行的工具调用和结果对追加到H，并相应地推进E。当没有进行宏提交时，H以通常的单步方式增长：执行器追加权威模型的工具调用及其返回结果。SMC通过一个单一的添加改变了这个循环，即第3.3节的*宏提交规则*，它在特定条件下允许一个权威步骤后跟上几个已经执行的草稿步骤。

当宏提交规则被禁用时，相同的执行器仍然并发运行权威模型和推测模型，并且仍然重用单步推测工作：每当权威模型提出与第一个草稿步骤相同的调用时，模型已经执行的调用和结果就被直接提交。我们称此配置为*仅SA基线*，并在第4节中用作匹配运行时的比较。

### 3.2 宏挖掘

SMC首先从成功的训练轨迹中提取候选多动作模式。然后，它使用从采样训练状态得出的模型预测来评估这些候选模式，并仅保留满足以下选择标准的模式。选中的候选模式构成运行时*宏库*M。每个宏记录一个有序的工具调用序列以及匹配所需的参数结构，用槽位替换特定任务的值（如用户ID、文档ID或时间戳）。这种规范化使得一个宏可以覆盖跨任务的重复行为，而无需完全相同的参数。

由于宏只有在模型能够在部署时重现它时才有用，我们使用与运行时相同的权威-推测设置对候选模式进行标记。对于每个采样的训练状态，模型提出一个短期未来动作链，我们将其与该状态的参考未来轨迹进行比较。当一个提议的工具调用序列在按照上述描述标准化任务特定参数值后与参考未来轨迹匹配时，该提议被标记为正确。因此，每个候选宏包含两类证据：该模式出现的频率，以及当遇到相关状态时模型重现它的可靠性。

对于一个候选宏m，令nₘ为标记的机会数量，kₘ为正确的模型提议数量。我们使用Beta后验分布的下δ分位数计算一个保守的可靠性估计：

p̲ₘ = F⁻¹_{Beta(kₘ+1, nₘ-kₘ+1)}(δ)

并仅在nₘ ≥ n_min 且 p̲ₘ ≥ τ 时保留m。阈值n_min和τ在使用与最终评估相同的执行器配置的保留任务上选择。

这些标准仅用于筛选候选宏。一个保留的宏是否被提交，由运行时的宏提交规则单独决定。

### 3.3 宏提交规则

在运行时，模型持续从当前H扩展草稿链Q。考虑一个保留的宏m = (u₁,...,u_K)。运行时对齐将u₁,...,u_j匹配到H的后缀，并将剩余的ℓ = K-j个动作匹配到草稿前缀q₁,...,q_ℓ。库中存储一次m；j和ℓ由运行时达到的状态决定。对齐只是一个提交候选项；它本身并不改变H。执行器等待权威模型的下一个工具调用。如果该调用匹配q₁，我们将q₁称为*锚点调用*。模型已经执行了q₁，因此执行器将其连同模型的返回结果一起提交；只有q₂,...,q_ℓ被提交而无需每个动作都经过权威确认。这跳过了ℓ-1个权威决策，因此候选选择要求ℓ-1 ≥ L_min。这不能仅从K来强制执行：对于相同的四动作宏，对齐一个或两个动作到H会留下三个或两个草稿动作，因此跳过两个或一个权威决策。

在线检查随后丢弃过时的...