要解决的问题

会用工具的语音 agent 常在用户说完后让用户等：要先把语音转成文字，再判断意图、调用工具、等结果，最后组织回答。其实很多信息在用户说到一半时就已经出现，现有投机方法也开始提前干活，但按语音块截断、一有更新就打断的生成方式，常把工具调用截在半截，参数还没齐就被取消，计算时间和语音更新被绑死。

Heartbeat 的做法

  • 在听的过程中周期性触发 Thinker，读取最新部分转写和一份共享记录；记录里放已完成的推理与工具结果。
  • 多个 invocation 可以重叠：一个还在构造工具调用，另一个已经在处理更新后的输入；工具异步执行，结果回写共享记录。
  • 后续 invocation 能用已有结果补齐缺失参数、发起依赖调用，因此在转写没变化时也能继续推进准备。
  • 检测到说话结束后，Responder 拿到完整请求和交接时的准备快照，核对哪些仍然适用、哪些被后文推翻，再补齐剩余调用；未完成的投机任务全部取消。
  • Thinker 与 Responder 可以使用不同模型，按成本与能力分别选型。

评测结果

作者在三个基准上比较了 SHANKS 风格的 Window Thinking。FDBench v3 上，工具覆盖率从 34.67% 升到 50.67%，平均最终响应延迟从 6.90 秒降到 4.39 秒，降幅 36.4%，也比最快的级联基线 Pipecat 低 45.7%。在 SpeechFCEval 和 AudioCRAG 上，投机覆盖率或检索复用也有提升，但最终任务质量略低于 Window Thinking；FDBench 上质量则有提升。

为什么值得注意

这套方法把「等用户说完」重新定义成「边听边准备」，而且明确区分了准备与回答：准备可以错，错了就扔掉；回答必须基于完整请求重新核对。这个分离很关键——它让投机执行的风险可控，也让不同模型可以各干各的活。

限制

收益高度依赖工具类型和对话结构。查询类工具适合预跑，写操作和不可逆动作不适合；如果用户经常改口，预跑被复用的比例会下降，额外算力就白花了。论文也承认，如何解释和使用投机结果仍是独立问题，两个基准上的质量下降说明「预跑得多」不等于「答得更好」。

语音 agent 的等待时间，其实是可以拿来算的——前提是算错了要能扔掉。