Agent工具调用分支预测：消除等待空档

Full translation

完整中文译文

Speculative tool execution 在模型还在推理时就能猜出下一个要调用的工具，并行运行它，把延迟藏起来——猜错了就丢弃结果。

太长不看版：Agent 的 think→act→observe 循环是串行的，所以工具运行时它有大把时间在空等。Speculative tool execution 借鉴了 CPU 的分支预测：一个廉价的预测器猜出下一个工具调用，在模型推理期间就把它跑起来。如果猜对了，结果已经在那儿，等待时间直接省掉；猜错了就丢弃，让真正的调用去跑——答案永远不会错。置信度门控避免在低概率猜测上浪费算力。在一个可运行的 Go 演示中，58% 的命中率将墙上时间缩短了 1.3 倍，且对正确性毫无影响。四篇 2026 年的论文（Speculative Actions、SPORK、PASTE、Speculate While You Reason）报告了 20–48% 的真实加速。

心智模型：一位厨师在顾客还在看菜单时就提前把有把握你会点的牛排煎上了。如果你点了，出餐提前；没点的话，他倒掉重来——你永远不会被上错菜，他们只是在后台多干了点活。

问题：Agent 循环在浪费自己的时间

Agent 运行的是一个严格串行的循环：推理、发出工具调用、等待结果、再推理。那段等待——一次 Web 请求、一次数据库查询、一次代码执行——是死时间。工具运行时 GPU（或者你的 API 预算）在空转。先前的研究测量到，在典型工作负载中这种空转占墙上时间的 16–37%，在工具密集型场景中高达 61%。对于一个多步交互的 Agent 来说，这是影响延迟最大的单一杠杆，再怎么调 prompt 也触碰不到。

问题的关键是，这个循环只是在逻辑上串行。模型并不需要完全结束推理才能运行工具——它只需要工具的结果在它推理完成时已经就位。

模式：预测、预执行、验证

CPU 用分支预测解决了这个问题：猜分支往哪个方向走，然后超前执行，错了就回滚。LLM 推理在 Speculative Decoding 中复用了这个思路。应用到 Agent 上就成了 Speculative Tool Execution：

根据迄今的轨迹预测下一个工具调用（可以是廉价的草稿模型、对 Agent 自身 logit 的探测，或者——如本演示——从反复出现的工具序列中学习到的模式）。

在模型继续推理的同时，并行预执行猜到的调用。

当模型发出真正的调用时进行验证。完全匹配 → 复用已就绪的结果。不匹配 → 丢弃，然后跑真正的调用。

正确性保证是整个方案的核心：Agent 的实际输出永远是 ground truth。推测只能用来消除等待，绝不会改变答案。

一个基于反复出现的工具模式的学习预测器：

func (p *predictor) predict(last string) (guess string, confidence float64) {
    row := p.counts[last]
    best, bestN, total := "", 0, 0
    for tool, n := range row {
        total += n
        if n > bestN { best, bestN = tool, n }
    }
    return best, float64(bestN) / float64(total)
}

以及边思考边推测的核心——猜到的工具在 goroutine 里运行，与模型的推理过程重叠；置信度门控在我们 Odds 不好时不进行推测：

guess, conf := pred.predict(last)
if guess != "" && conf >= gate {
    specCh = make(chan string, 1)
    go func(t string) { specCh <- runTool(t) }(guess) // runs in parallel with think
}
time.Sleep(thinkMS * time.Millisecond) // the model reasons

if specCh != nil && guess == actual {
    <-specCh          // correct: result already ready — latency hidden
    hits++
} else {
    runTool(actual)   // miss: discard the speculation, run the real tool
}

Speculative Tool Execution — guess the next tool and run it while the model thinks
  24-step agent loop; think=40ms, tool=60ms per step.

   serial agent loop        2.443s   (think, then wait for the tool, every step)
   speculative loop         1.869s   (14 hits / 4 misses / 1 gated out)

   next-tool hit rate          58%
   wall-clock speedup        1.31x  (tool latency hidden behind reasoning)
   wasted speculations          4   (discarded on a miss — never a wrong answer)

四次未命中付出了一些可丢弃的后台工作；一次被门控挡掉的步骤说明置信度门控选择不赌。四次命中每次都将一次工具调用藏在了本就要发生的推理背后。正确性分毫未损——每一次真正的工具调用依然跑了（或者被证明已经跑过了）。

为什么这是 2026 年的方向

这件事在 2026 年从理论跳变成了一波小型研究潮，而且设计思路收敛到了同一个形态。SPORK 从 Agent 自身的 KV cache 分叉出一个探测头来预测下一个工具，达到 74–99% 的准确率，并在置信度上门控分发——正是上面这套门控-丢弃结构。PASTE 挖掘反复出现的工具调用模式（本演示的预测器所编码的假设），报告任务完成时间降低最多 48%。Speculative Actions 把这个框架general 化了：一个快速模型把可能的行为提前准备好，这样关键路径就不是等待而是验证。Speculate While You Reason 则表明 Agent 自己就是最好的预测器。

这个可迁移的工程思路不需要任何训练：只要你的 Agent 有可预测的结构和空闲等待，你就可以让它们重叠。可预测的重复工具序列、已知的数据获取扇出、以及重试后重新打开的模式，今天都可以用一层控制器包装在普通 completion API 之上进行推测。

这个演示的忠实度如何

它模拟了控制流和时间，但没有模拟推理：「思考」和「工具延迟」是固定的 sleep，预测器是对工具名的“一阶马尔可夫计数”——真正的推测器还要预测工具参数（难得多）并需要为草稿模型付出代价。两点论文强调的注意事项：只有当工具延迟在步骤时间中占真实比重时推测才有帮助，而且预测错的副作用必须是安全可丢弃的（只读调用可以自由推测；charge_customer 可不行）。从你最可预测的循环上的幂等只读工具开始推测。

go run .   # standard library only

资料来源与进一步阅读

Zhou et al. — Speculative Actions: A Lossless Framework for Faster Agentic Systems (ICLR 2026) — 快速模型预测并暂存行为；下一动作准确率高达 55% → 延迟降低高达 20%，附有调优推测广度的成本-延迟分析。

SPORK: Self-Speculative Forking to Accelerate Agentic LLM Inference (arXiv 2607.03333) — 无需训练的控制器；一个前缀缓存分叉以 74.6–99.6% 的准确率预测下一工具，置信度门控过滤误预测，拒绝时串行回退。

Act While Thinking: Pattern-Aware Speculative Tool Execution (PASTE) (arXiv 2603.18897) — 利用反复出现的工具调用序列和参数依赖；任务完成时间降低 48.5%，工具吞吐量提升 1.8×。

Speculate While You Reason: Teaching Agents to Predict Their Next Tool Call via Joint Agent–Speculator RL (arXiv 2607.25816) — Agent 自身就是推测器；Hit@1 从约 44% 提升到约 61%，同时保持任务成功率。

Speculative decoding for LLMs and branch prediction in CPUs — 与本模式同源的预测-执行-验证传承。