夜雨聆风生产级 Agent 的延迟问题，归根结底是一个等待问题。
Agent 在循环中调用 LLM → 生成工具调用 → 等待 API 返回 → 把结果送回 LLM 继续推理。这个循环每转一圈，用户就多等一次。当一个 Agent 调用三次工具、每次 API 返回耗时 1-2 秒，再加上 LLM 推理的 1-3 秒，单次交互轻松突破 10 秒。
这个等待是结构性的：LLM 必须先生成工具调用 token，系统才能发起执行。你无法让 LLM 跳过"思考"阶段，也无法让工具调用在 LLM 生成结束之前开始。除非——你预先知道 LLM 会调用什么工具。
推测执行的思路
推测式工具调用的核心假设很简单：在 LLM 生成完整的工具调用之前，用一个更轻量的方式预判接下来的动作，然后提前发起执行。
如果预判正确，工具结果已经在 LLM 需要的时候准备好了，延迟被隐藏。如果预判错误，丢弃或补偿预执行的结果，LLM 按正常路径走一遍。
这个思路在计算机体系结构里并不新鲜。CPU 的推测执行已经存在了几十年——分支预测器猜测下一条指令的走向，提前加载和计算，猜错就清空流水线。LLM 推理中的推测解码也是类似逻辑：用小模型快速生成候选 token，大模型验证。轮到 Agent 的工具调用，同样的模式开始出现。
几个团队在 2025-2026 年探索了这条路。有人用隐藏状态探针（hidden state probe）从 LLM 中间层提前读出工具调用的信号，有人用专用的小模型（1B-3B 参数）作为预测器，也有人纯粹从历史轨迹中做模式匹配。这些工作有两个共同结论：一是大多数 Agent 场景中工具调用的模式可预测性远比想象中高，二是即使只有 70% 的预测准确率，端到端延迟也能降低 30-50%。
架构拆解
一个完整的推测式工具调用系统包含四个组件：
预测器是核心。它接收当前的上下文（用户消息、之前的工具调用结果、对话历史），输出一组候选工具调用及其置信度。预测器可以是一个蒸馏后的小模型，可以是一个挂在 LLM 隐藏层上的线性分类器，也可以是一个基于历史轨迹的检索模型。
预执行引擎负责调度。收到预测结果后，它并行发起候选工具调用。对于确定性工具（如数据库查询、文件读取），执行结果可以直接缓存。对于有副作用的工具（如发送邮件、创建订单），预执行时需要特殊处理——比如只做校验不做提交，或者使用沙箱环境。
验证器就是主 LLM。它正常生成推理和工具调用，然后与预执行结果做比对。如果 LLM 生成的工具调用与预测一致，验证器直接使用预执行结果，跳过实际执行。如果不一致，触发回滚路径。
回滚处理器处理预测错误的后果。对于纯查询类工具，回滚只需要丢弃预取结果。对于有状态变更的工具，需要补偿操作——撤销已执行的动作，或者记录差异供人工审核。
三个预测路径
具体实现预测器，目前有几种不同的技术路线可选。
隐藏状态探针
这是开销最小的方案。在 LLM 推理过程中，模型在生成最终 token 之前，其内部隐藏状态已经包含了大量关于下一步决策的信息。训练一个轻量分类器，挂载在 LLM 的中间层或最后一层，就可以在模型生成工具调用 token 之前数百毫秒就预测出工具名称和关键参数。
这种方法不需要额外部署模型，推理时增加的开销可以忽略不计。但它的预测能力有限——只能预测出工具类型和部分参数，难以精确预测复杂参数结构。而且它和主 LLM 紧耦合，换模型就要重新训练探针。
专用草稿模型
部署一个独立的小模型（1B-3B 参数），专门用于预测工具调用。它在每次 Agent 循环中与主 LLM 并行运行，基于当前上下文输出候选工具调用。小模型的速度优势（通常比大模型快 3-5 倍）让它有足够的时间完成预测，主 LLM 甚至还没开始生成。
这个方案的预测精度远高于隐藏状态探针，可以输出完整的工具调用参数。而且小模型与主 LLM 解耦，可以独立优化和迭代。代价是额外的推理成本和部署复杂度——内存中多了一个模型，GPU 或 CPU 资源要多分配一份。
轨迹模式匹配
不做模型推理，而是基于历史 Agent 轨迹做检索匹配。维护一个工具调用模式库，记录过去 Agent 在类似上下文中调用过哪些工具。当前上下文到来时，通过 embedding 相似度检索最相似的轨迹，用其工具调用序列作为预测。
这个方案零推理成本，只需要一个向量数据库和 embedding 模型。但它的预测能力受限于历史数据的覆盖度——没见过的模式就无法预测。对于新场景或冷启动阶段，效果很差。
回滚策略的取舍
推测执行最棘手的部分是回滚。当一个预测错误的工具调用已经执行了一半，怎么办？
对于幂等工具，回滚很简单：丢弃结果，下次 LLM 真正需要时重新执行即可。对于只读工具，同样简单——预取的数据不会被使用，仅此而已。
问题出在有副作用的工具。假设预测器判定 Agent 将要调用"取消订单"工具，预执行引擎真的发送了取消请求。但 LLM 最终决定改为"修改订单"——订单已经被取消了。
处理这类场景有几种策略：
沙箱执行：在隔离环境中执行预判的工具调用，不对外部系统产生真实影响。比如数据库查询在 read replica 上执行，订单操作在测试环境执行。验证通过后再在真实环境重放。
预校验不提交：只执行工具调用的校验阶段，确认参数合法、资源可用，但不做最终提交。比如创建订单时只做库存检查，不实际扣减。验证通过后再执行完整的工具调用。
补偿操作：如果预执行已经产生了真实影响，立即执行补偿动作。取消订单→重新下单，发送通知→发送撤回通知。这要求每个工具定义好对应的补偿操作，类似于 Saga 模式中的补偿事务。
仅预测只读工具：这也是最保守但最安全的策略——预测器只对只读工具做推测执行，有副作用的工具永远等 LLM 确认后再执行。这牺牲了一部分优化空间，但彻底避免了回滚风险。
预测准确率的阈值
推测执行不是免费的。预测错误会产生额外的延迟开销——预执行本身消耗时间，回滚也需要时间。只有当预测准确率超过某个阈值时，推测执行才有意义。
这个阈值取决于工具调用的平均延迟和预测器自身的开销。假设一个工具平均耗时 2 秒，预测器耗时 300 毫秒，回滚开销 200 毫秒。那么当预测准确率 p 时，平均单次工具调用的等待时间期望为：
猜对时：300ms（预测器开销）+ 0ms（结果已就绪） 猜错时：300ms + 2s（安排执行）+ 200ms（回滚）
代入公式，p × 300 + (1-p) × 2500 < 2000（不回退的时间），解得 p > 0.77。也就是说，在这个假设下，预测准确率需要超过 77% 才有净收益。
实际工程中，不同工具的延迟差异很大。一个简单的缓存查询可能只需要 50ms，不值得推测执行。而一个需要调用外部 API 的搜索工具耗时 3 秒，推测执行的价值就很大。合理的做法是为每个工具单独配置预测准确率阈值，只有预测置信度超过该阈值时才触发预执行。
适合的场景
推测式工具调用并非适用于所有 Agent 场景。它的收益取决于三个因素：工具延迟、可预测性和副作用。
工具延迟是首要条件。如果工具调用本身很快（<200ms），推测执行引入的预测器开销可能超过节省的时间。只有当工具调用延迟超过 500ms-1s 时，推测执行才值得考虑。
可预测性决定了准确率上限。在以下场景中，工具调用模式的可预测性较高：
Agent 遵循固定工作流（如"先搜索、再总结、最后回复"） 工具调用基于用户输入中的结构化信息（如意图分类后再调用对应工具） 历史轨迹中有大量相似模式可参考
副作用决定了回滚成本。只读 API、缓存查询、数据读取等工具的回滚成本几乎为零，是推测执行的最佳候选。而涉及资金、权限、通知等操作的副作用工具，需要谨慎评估。
工程落地建议
如果你考虑在 Agent 系统中引入推测执行，建议从最保守的路径开始。
第一步，只对只读工具开启推测执行。在架构中引入预测器和预执行引擎，但限定在查询类工具范围内。这能规避大部分回滚风险，同时积累预测准确率数据。
第二步，建立预测准确率的监控体系。追踪每个场景、每个工具的预测准确率，以及推测执行带来的延迟节省和浪费。这些数据是后续决策的基础。
第三步，为有副作用的工具定义补偿操作。如果某个工具在业务上确实需要低延迟，且回滚风险可控，才将其纳入推测执行范围。补偿操作需要和工具本身一样经过测试和验证。
第四步，考虑动态策略。预测准确率不是固定的——同一个工具在不同上下文中的可预测性差异很大。可以根据当前预测置信度动态决定是否触发预执行，而不是对所有预测一视同仁。
推测式工具调用不会取代缓存、并行执行或流式输出这些传统优化手段。它是在这些手段之上，进一步压缩 Agent 等待时间的额外一层。如果你的 Agent 系统已经做了缓存和并行优化，但端到端延迟仍然无法满足 SLA，推测执行可能是下一个值得探索的方向。
但也要记住，推测执行引入的架构复杂度不容忽视。额外的预测器部署、回滚逻辑、监控体系，以及可能出现的预测错误导致的业务影响，都需要团队有足够的工程能力来承接。不是每个 Agent 系统都需要推测执行——但如果你的工具调用延迟正在成为瓶颈，至少现在有了一个更完整的选择清单。
#AI应用架构 #AI应用开发 #Agent应用架构 #Agent应用开发 #LLM应用架构