首页2026 年 10 月 19 日，Google Developers Blog 发布了一篇关于实时 Voice Agent 的实践文章。Google 使用 ADK 和 Gemini 3.8 Live 测试一个销售数据查询场景：后台数据库查询本身需要约 13 秒。
采用传统 Blocking Tool Calling 时，Agent 必须等待工具执行结束，才能继续生成语音，结果首次开口时间达到 14.4 秒。而将工具改成 Streaming / Non-blocking 模式后，Agent 可以一边执行后台任务，一边继续和用户交流，首次语音反馈缩短到了 1.2 秒。
值得注意的是，Google 并没有把原本 13 秒的数据库查询优化到 1 秒。真正改变的是后台任务仍然需要时间，但 Voice Agent 不再因为“做事”而突然从对话里消失。
这其实揭示了 Voice Agent 进入生产环境之后一个越来越重要的问题：低延迟，不只是模型回答得快，而是整个任务执行过程中，对话都不能失去实时性。
一. Voice Agent 的延迟，已经不只是“模型有多快”
过去讨论 Voice AI 延迟，通常会关注几个指标：
- ASR 多久识别出用户的话；
- LLM 首 Token 延迟是多少；
- TTS 多久生成第一段音频；
- 语音从生成到用户听见需要多久。
这些当然重要。但当 Voice AI 从简单问答升级成 Voice Agent 后，链路里开始出现另一个不可忽视的环节：Tool Calling。
今天的 Voice Agent 不只是聊天，它还可能需要：
- 查询数据库；
- 搜索知识库；
- 运行 RAG；
- 查询 CRM；
- 调用搜索引擎；
- 访问 MCP Server；
- 调用其他 Agent；
- 执行订单、预订、支付等业务流程。
一次真实的 Voice Agent 请求因此可能变成：用户语音 → 语音理解 → Agent 判断 → Tool Calling → 外部系统执行 → 返回结果 → Agent 组织回答 → 语音输出
问题就在中间的 Tool。如果一个数据库查询需要 10 秒，即使前面的语音识别只用了几百毫秒、模型首 Token 也非常快，用户最终还是可能面对长时间等待。所以到了 Agent 阶段，Voice AI 的延迟问题开始从单纯的模型延迟，扩展到整个交互延迟。
二. 为什么文字 Agent 可以等，Voice Agent 却不能一直等？
网页和文字聊天有一个天然优势：它们可以用视觉反馈告诉用户，系统还在工作。
比如：
- Loading…
- 正在搜索
- Thinking…
- 进度条
- 任务状态提示
即使结果还没有返回，用户至少知道：“它正在处理任务。”语音对话没有这么多天然的视觉提示。
如果 Voice Agent 突然沉默，用户很难判断：
- AI 是不是没听见；
- AI 是不是没听懂；
- 网络是不是卡住了；
- 电话是不是断了；
- 系统到底还在不在工作。
Google 在文章中把这种体验直接称为 Dead Air。这也是 Voice Agent 和文本 Agent 一个非常重要的差别。
一个网页加载 10 秒，用户会认为：“这个页面有点慢。”但一次语音对话突然沉默 10 秒，用户更容易认为：“它是不是挂了？”
因此，实时语音 Agent 有一条很重要的产品原则：任务可以慢，但对话不能消失。
三. Blocking Tool 为什么会让 Voice Agent “突然失联”？
传统 Tool Calling 的执行逻辑通常比较直接。Agent 决定调用工具以后：
调用 Tool → 等待 Tool 返回 → 模型拿到结果 → 继续生成回答
如果工具只需要几十毫秒，通常不会造成明显问题。
但如果它调用的是：
- 复杂数据库；
- 企业知识库；
- 长时间 RAG Pipeline；
- 多个内部系统；
- 外部第三方 API；
执行时间就可能从几百毫秒变成几秒甚至十几秒。Google 的测试场景中，销售数据库查询大约需要 13 秒。传统 Blocking Tool 模式下，模型的实时会话执行流程需要等待这个工具返回。
于是：
Tool 没结束 → 模型无法继续说话 → 用户听到的就是一段完整的沉默。
这时候，即使在 Prompt 里告诉模型：“查询过程中记得告诉用户你还在工作。”也无法真正解决问题。
因为模型本身已经被 Tool 阻塞，它根本没有机会再生成新的语音。所以这个问题不是 Prompt Engineering 能解决的。它是架构问题。
四. Google 的解决思路：Tool 在后台跑，对话继续进行
Google 在 ADK 中给出的核心解决思路，是将任务执行和实时对话拆开。
传统逻辑是：
调用 Tool → 等待 → Tool 返回 → Agent 开口
Non-blocking 模式则更接近：
调用 Tool → Tool 后台执行
与此同时：
Agent 可以立即反馈 → 用户可以继续说话 → Tool 后台继续运行 → 结果返回后再进入对话
这样一来，原本串行的过程开始变成并行。
Google 主要给出了两类处理方式。
1. Streaming Tool：等待过程本身也可以“说出来”
有些长任务不是单纯等待，中间其实包含多个有意义的阶段。
比如查询一份销售报告：
连接数据库 → 查询订单 → 汇总数据 → 核对结果 → 生成报告
Streaming Tool 可以在这些阶段不断返回中间状态。于是 Agent 不必等待最终结果出现，才能第一次开口。
它可以先告诉用户：
“正在帮你查询销售数据。”
随后根据任务进度继续反馈：
“数据已经找到了，我正在做汇总。”
最终查询完成后，再给出完整结果。
用户感受到的就不再是：
13 秒沉默 → 突然得到答案
而是：
立即确认 → 持续知道进度 → 获得最终结果
Google 对这种模式给出的经验很直观：
如果等待过程本身有值得告诉用户的进展，就把它 Streaming 出来。
2. Background Tool：如果只是等待，就让它在后台完成
另一类任务没有那么多值得播报的中间状态。
例如：
“帮我查一下这个订单什么时候发货。”
系统可能只是需要等待一个内部 API 返回结果。
这时候如果 Agent 每隔几秒重复：
“还在查询。”
“仍然在查询。”
反而会让对话显得机械。
因此另一种方式，是让 Tool 直接在后台执行。
Agent 可以继续和用户交流其他内容。
等后台结果真正返回以后，再选择适当的时机告诉用户。
这就产生了 Voice Agent 的另一个重要问题：结果出来了，什么时候说？
五. Tool 查完了，也不能想什么时候说就什么时候说
假设用户让 Agent 查询一笔订单。
等待过程中，用户又开始询问另外一个问题。
就在用户说到一半时，订单查询结果返回了。
Agent 应该怎么办？马上插话？等用户说完？
还是暂时不播报，只把结果保存下来？
Google ADK 为此提供了不同的 Response Scheduling 策略。
1. WHEN_IDLE：等对话空闲下来再说
这是最接近自然人类交流的一种方式。
Tool 即使已经返回，也不会立即抢话，而是等当前会话进入空闲状态以后再提供结果。
适合：
- 普通数据库查询；
- 订单查询；
- 报告生成；
- 非紧急后台任务。
2. INTERRUPT：结果足够重要，立即插入
如果 Tool 返回的是紧急结果，系统可以主动打断当前对话。
例如：
- 安全告警；
- 异常交易；
- 重要实时状态变化。
这时候“礼貌地等待”反而不是最合适的策略。
3. SILENT：只更新上下文，不主动说出来
还有一些结果没有必要立即通知用户。
系统可以把 Tool 返回的信息写入当前 Conversation Context，让 Agent 后续需要时使用，但不主动生成一段语音。
这意味着 Voice Agent 不只是需要知道：
“答案是什么？”
还要判断：
“什么时候告诉用户，才最自然？”
到了这一步，Voice Agent 的问题已经明显超出了普通 API 调用。
它开始接近一个真正的实时会话系统。
六. 用户打断 AI，不等于用户取消了任务
Google 这次实践中，还有一个很容易被忽略的细节。Barge-in 和 Tool Cancellation 并不是同一件事。
例如用户说：“帮我查一下上个月华东区的销售数据。”
Agent 开始查询：“好的，我正在帮你查询……”
这时候用户突然插话：“对了，今天上海天气怎么样？”
这里发生了一个对话打断。
Agent 可以停止当前正在播放的语音，开始回答新问题。
但这并不意味着：“刚才的销售查询已经没用了。”
销售查询完全可以继续在后台运行。
等用户问完天气后，如果数据已经返回，Agent 再继续：“刚才的销售数据也查到了……”
因此 Voice Agent 里至少存在两种不同状态：
Conversation State 和 Task State
用户打断的是当前说话行为，并不一定是在取消任务。
只有当用户明确表示：“算了，不用查了。”
系统才应该真正终止后台任务。
这也是为什么 Agent 进入实时语音以后，任务生命周期管理会变得比传统聊天机器人复杂得多。
七. 从 14.4 秒到 1.2 秒，真正降低的是“感知延迟”
Google 这个案例里最容易被误解的一点是：数据库查询并没有从 13 秒优化到 1 秒。
它仍然需要原来的执行时间。真正发生变化的是，Agent 不再等到所有事情完成以后才第一次回应用户。
采用 Streaming Tool 后，测试中的首次语音反馈从 14.4 秒降到了 1.2 秒。这意味着 Voice Agent 的延迟其实可以拆成两个不同维度。
1. 计算延迟
包括：
- ASR 延迟；
- 模型推理延迟；
- 数据库查询时间；
- RAG 执行时间；
- Tool 调用时间；
- TTS 生成延迟。
2. 交互感知延迟
包括：
- 用户说完以后多久能听到反馈；
- AI 是否能立即确认已经收到任务；
- 等待过程中有没有自然反馈；
- 用户能否随时继续说话；
- Tool 返回结果以后什么时候进入对话。
前者决定系统实际需要多少计算时间。
后者则决定用户觉得：“这个 Agent 到底快不快？”
对于 Voice Agent 来说，两者并不完全是一回事。
八. Voice Agent 的低延迟，需要看整条实时链路
Google 这次重点解决的是 Tool Calling 阶段的阻塞问题。
但如果把视角继续拉远，一次完整的实时语音交互其实要经过更多环节：
用户语音 → 音频采集与传输 → VAD / Turn Detection → ASR 或实时语音模型 → LLM / Agent → Tool / RAG / MCP → TTS → 音频传输与播放
任何一个环节出现长时间等待，都可能影响最终体验。
例如：
- 音频网络传输不稳定，会直接影响识别和播放；
- Turn Detection 判断过慢，会让 AI 迟迟不开口；
- Tool Calling 阻塞，会导致长时间 Dead Air；
- TTS 首包慢，会让已经生成好的答案仍然无法及时播放；
- 打断反应慢，会让 AI 在用户已经开口后继续说话。
因此，Voice Agent 真正要优化的，并不是某一个单独模型的 Benchmark。
而是从用户开口到 AI 持续反馈的整条实时交互链路。
九. 从“请求—响应”到“持续会话”，Voice Agent 的架构正在变化
传统 AI API 很像一个标准请求：
Request → Processing → Response
用户发出一个请求，系统处理完，再返回最终结果。
但 Voice Agent 越来越不像这种模式。
它更接近一个持续存在的 Session：
持续音频输入 → 实时理解 → Agent 决策 → 多个 Tool 并行运行 → 用户继续说话 → 用户随时打断 → Tool 异步返回 → 实时语音输出
在这个过程中：
- Conversation 一直存在；
- Tool 可能同时执行；
- 用户可以不断改变任务；
- 不同结果可以异步进入会话；
- 语音输入和输出需要始终保持低延迟。
这也是为什么 Voice Agent 越来越需要实时通信能力。
它需要的不是一次性的 API 请求，而是一条持续存在的实时连接。
从这个角度看，Voice Agent 的技术栈也正在从：
AI API
逐渐向：
Realtime AI Infrastructure
演进。
十. 声网对话式 AI：优化的不只是模型，而是整条实时对话链路
当 Voice Agent 开始接入数据库、RAG、MCP、企业业务系统和其他 Agent 后，后台任务只会越来越复杂。
这意味着，未来 Voice Agent 很难依靠“把所有接口都优化到亚秒级”来解决体验问题。
更加现实的方向，是让任务执行与实时对话协同工作。
这也是声网对话式 AI 服务重点解决的问题之一。
在一套完整的 Voice Agent 系统里，模型负责理解和推理，Tool 负责执行业务任务，而实时对话层还需要解决：
- 音频低延迟传输；
- 什么时候判断用户真正说完；
- 什么时候让 Agent 开口；
- 用户插话时如何快速停止当前播报；
- 复杂网络环境下如何保证语音连续性；
- 多轮交互中的实时状态如何持续同步；
- 不同 ASR、LLM、TTS 与业务 Agent 如何协同。
模型解决的是“Agent 想说什么、要做什么”，实时交互系统解决的是“什么时候说、怎么说，以及用户能不能随时插话”。
当 Voice Agent 只负责简单问答时，这种差别可能并不明显。但当 Agent 真正开始“做事”，整个对话就会变成长连接、多任务、可打断、持续变化的实时过程。
这也是 RTC 和对话式 AI 开始越来越紧密结合的原因。
十一. Voice Agent 的下一阶段，不是回答更快，而是“等待得更自然”
Google 这次测试中的 14.4 秒到 1.2 秒，是一个很吸引人的数字。
但它背后真正重要的并不是“数据库突然快了十几倍”。
相反，后台任务根本没有变快。
变化的是 Voice Agent 学会了：
- 任务没完成时先确认；
- 有进展时适时反馈；
- 后台执行任务时继续交流；
- 用户插话时允许被打断；
- 任务完成后选择合适时机再说。
这其实越来越接近人与人的真实交流。
对方可能需要找资料、查询系统或者处理另一件事情，但不会因此突然从对话里“消失”。
所以 Voice Agent 真正走向生产以后，衡量体验的指标可能不再只有：
“多久得到最终答案？”
还应该包括：
“用户多久能感受到 Agent 已经听见自己，并且仍然在线？”
从这个意义上说，Google 这次解决的并不只是一个 Tool Calling 的性能问题。
它触碰到的是实时 Voice Agent 一个更核心的问题：
当一个 AI 一边和人说话、一边执行任务时，怎样让它始终保持“在场”。而随着 Voice Agent 接入越来越多真实业务系统，这可能会比单纯再降低几十毫秒的模型推理延迟，更直接地决定用户是否愿意继续和 AI 说下去。
