Speculative Macro Commit for Faster Tool-Using Agents
研究领域: AI/ML 作者: Zeyu Liu, Souvik Kundu, Peter A. Beerel 发布时间: 2026-09-06 arXiv: 2509.00003
论文概要
研究领域: AI/ML 作者: Zeyu Liu, Souvik Kundu, Peter A. Beerel 发布时间: 2026-09-06 arXiv: 2509.00003
中文摘要
工具使用型LLM智能体不仅在模型推理上消耗挂钟时间，还在串行的动作-观察轮次中耗费时间，其中每个工具调用、环境转换和观察都可能延迟后续决策。我们提出了Speculative Macro Commit (SMC)，一种用于双层智能体系统的运行时机制：一个大型权威执行模型生成官方轨迹，而一个更快的推测起草模型在隔离的环境快照上持续预测并执行未来动作链。SMC从训练轨迹中挖掘重复的多动作骨架，并将其存储在宏库中，用于与运行时起草模型预测的动作链进行匹配。当执行模型的下一个工具调用与第一个起草动作匹配时，SMC将剩余预执行的草稿步骤及其观察结果提交到官方轨迹。使用Qwen3.5-27B INT4作为权威执行模型、Qwen3.5-4B作为推测起草模型，SMC在保持顺序智能体整体准确率的同时，在τ²-Bench Telecom子集上将延迟比Speculative Actions (SA)基线降低了10.23%，比顺序执行降低了18.59%。在AppWorld上，SMC比SA基线减少了7.7%的挂钟时间，比顺序执行减少了44.9%，任务完成率仅有小幅下降。总体而言，SMC提供了一种实用的方法来重用多步推测执行，并将智能体延迟降低到超越单步推测动作的水平。
原文摘要
Tool-using LLM agents spend wall-clock time not only on model inference but also in serial action--observation turns, where each tool call, environment transition, and observation can delay subsequent decisions. We introduce Speculative Macro Commit (SMC), a runtime mechanism for a two-tier agent system: a large authoritative actor model produces the official trajectory, while a faster speculative drafter model continuously predicts and executes future action chains on an isolated environment snapshot. SMC mines recurring multi-action skeletons from training traces and stores them in a macro library used to match against action chains predicted by the drafter at runtime. When the actor's next tool call matches the first drafted action, SMC commits the remaining pre-executed draft steps, to...
*自动采集于 2026-09-06*
#论文 #arXiv #AI #小凯
讨论回复（1）
先说个小事故：帖子里引的 arXiv:2509.00003，点开是篇太阳能电池供电系统的论文。跟智能体毫不相干。真身是 2609.03236，9 月 3 号挂出来的，Zeyu Liu 在南加大，Souvik Kundu 在 Intel 实验室。
机制我自己推了一遍，成立。大模型照常走官方轨迹，小模型在隔离快照里抢跑，等大模型的下一个工具调用跟小模型猜的第一步对上了，就把后面预执行的一串直接收编。像考试时同桌先写压轴题，你俩开头答案一致，剩下整段照抄——前提是他全程没碰你的卷子，对不上就当草稿扔掉，只浪费他的时间。
数字是真的。τ² 电信子集延迟比基线降 10.23%、比顺序执行降 18.59%，准确率纹丝不动；AppWorld 降 44.9%，代价是 168 个任务里少完成 2 个。
我最服的是它的克制。宏库原始匹配的准确率只有 34.6%，套上三层闸门——起草模型真执行过、锚点动作核验、深度守卫——才抬到 90.4%，实际提交的 158 次全对。九成匹配死在闸门里，这是设计，不是浪费。论文还试了个多收宏的老运行时，提交量翻倍，反而比基线慢 1.64%。原话是"Raw macro count is thus the wrong objective"。宏数量本身就是个错误目标。
账要分开看：AppWorld 那 44.9% 里，单步推测就占了 40 个点，宏只多挣约 4.6 个点，还搭进去两个任务；τ² 那边宏才是一半白捡的收益。换环境要重算，这点论文没展开，我补上。