Gemini 3.8 Live 双延迟评测：语音 Agent 的轮次与任务完成合同

评测 Gemini 3.8 Live 需要两只时钟。第一只测用户说完后多久听到有意义的回应，第二只测推理和工具何时真正交付可验证结果。把两者压成一个平均延迟，会掩盖 Gemini 3.8 Live 与 Extended Thinking 最关键的系统差异。

阅读时间：约 8 分钟

核心结论

• 对话延迟与任务完成延迟必须分开统计。
• Extended Thinking 中，turnComplete: true 只代表一次发声结束。客户端需要继续读取 interaction_status，直到 IDLE 才能确认整项工作结束。
• 直接问答、快速工具、慢工具、多步推理、打断、弱网和重连属于不同任务形状，应分别评测。
• 口头进度提示只有在及时、真实并且后续确有进展时才有价值。
• 发布 P50、P95、P99、失败率、任务成功率和单次成功任务成本。单一延迟数字无法支持选型。

两种模型对应两份延迟预算

Google 将 gemini-3.8-live 定位为低延迟对话和直接任务，将 gemini-3.8-live-extended-thinking 定位为复杂规划、后台推理和异步工具调用。区别落在交互生命周期上。

标准 Live 通常在一个轮次结束后回到空闲。Extended Thinking 可以先说正在查询，结束这次发声，然后继续推理、调用工具，稍后再给结果。因此，首段音频很快，只能证明系统及时开口；它不能证明任务已经完成。

建议定义两个顶层指标：

1. 对话延迟：从用户语音结束到第一段有意义的模型音频。
2. 结果延迟：从用户语音结束到答案或外部动作通过验证。

第一项守住自然轮次，第二项守住实际价值。只优化其中一项，瓶颈会转移到端点判断、工具执行、后台推理或语音合成。

把端到端链路拆成事件

为每个边界记录时间戳：

用户语音结束
  → 客户端提交音频
  → 服务端确认轮次边界
  → 首段模型音频到达
  → 首句有效信息播出
  → 本次发声结束
  → interaction_status 变为 IDLE
  → 外部结果通过验证

最低指标集如下：

计时起点应使用人工标注或离线检测得到的真实声学结束时间。如果从客户端 VAD 事件开始计时，会把用户已经感受到的端点等待隐藏掉。Live API 提供自动与混合 VAD 控制，但 Google 没有为这两个 GA 模型端点公布通用的 P50 或 P95 端到端延迟。静音阈值和延迟预算应作为业务 SLO 实测，不能当作厂商常数。

语音交互对尾部异常非常敏感。偶发长静默、抢话和重复确认都会直接破坏体验，所以 P95、P99 与平均值同样重要。

把填充语当作协议事件

Extended Thinking 会在推理或等待工具时说出正在检查之类的提示。这能减少无反馈的静默，也可能制造一种假进展：系统听起来很忙，任务却没有推进。

每段中间发声至少检查三件事：

• 及时性：是否在用户感到停顿前出现。
• 真实性：是否准确描述当前状态，没有暗示尚未完成的动作已经完成。
• 进展关联：其后是否出现工具调用、状态变化或在预算内给出最终结果。

把音频、turnComplete、interaction_status、工具事件和最终验收放进同一条 trace。Extended Thinking 下，如果 UI 在第一次 turnComplete: true 后就显示空闲，会向用户报告错误状态。官方文档要求客户端持续监听，直到 interaction_status: IDLE。

冻结任务形状，而不是混成一套题

两种模型的选择取决于任务形状：

Extended Thinking 还要分别测 low、medium、high 三档 thinking level。提示词、录音、工具返回、网络条件和答案检查器必须冻结。标准 Live 不提供同一套 thinking level，因此结果应按两种产品模式解释，而不是伪装成只改一个参数的对照实验。

让音频和工具都可重放

音频集应覆盖口音、语速、停顿、背景噪声、中英切换、数字、专有名词、多人抢话和句中长停顿。相同文件重复输入两种模型，从采集、上传到播放保留完整时间戳。

工具侧先用可控 mock：固定 50 毫秒、500 毫秒、3 秒和 10 秒延迟，并加入超时、错误格式和重复响应。这样能把模型编排问题与第三方服务波动分开。通过后，再用真实工具做小规模生产复测。

网络至少覆盖稳定宽带、带抖动与丢包的移动网络、连接中断后三种状态。Google 文档说明，Live API 单连接时长约十分钟；未启用压缩时，纯音频会话限十五分钟。上下文压缩与 session resumption 会改变长会话路径，所以恢复能力必须进入评测矩阵。

用结果验收语音表现

Google 发布材料列出 Extended Thinking 的多项结果，包括 Artificial Analysis Speech-to-Speech Quality Index 82.6、τ-Voice 68.6%、Sierra τ-Voice banking 35.1% 和 Big Bench Audio 97.7%。这些数字适合证明值得测试，仍需保留证据边界：它们来自 Google 发布材料及其引用的评测方，无法替代目标业务中的冻结实验。

每种任务都需要确定性或可人工复核的检查器：

• 外部动作是否执行一次且仅一次。
• 最终答案是否使用最新工具结果。
• 被打断后是否保留新约束并放弃旧请求。
• 无法确认时是否表达不确定，而非虚构完成。
• 会话是否从 IN_PROGRESS 正常收敛到 IDLE。

成本按单次成功任务计算。快速模型如果经常要求用户重复，整体成本会升高；Extended Thinking 只有在成功率提升足以覆盖额外等待和费用时才值得启用。

一份可执行的发布合同

先写阈值，再跑测试：

1. P95 首句有效音频处于产品的对话预算内。
2. P95 打断停声和恢复时间低于既定上限。
3. 关键动作在外部验收前不能标记完成。
4. 重连和打断不会造成重复工具调用。
5. Extended Thinking 的成功率增益能够补偿更长的结果延迟。
6. 超时、幻觉和长期停留在 IN_PROGRESS 的比例低于门槛。
7. Extended Thinking 客户端以 interaction_status 管理生命周期。

官方模型卡将幻觉、偶发缓慢和超时列为已知限制。这些限制应直接变成测试用例。模型卡还给出 128K 输入和 64K 输出上限；它们是容量边界，无法代替长会话稳定性测试。

常见问题

Gemini 3.8 Live 与 Extended Thinking 的核心区别是什么？

Live 面向即时对话和直接任务。Extended Thinking 增加可配置的后台推理，只支持异步非阻塞工具，并可能在一次请求中多次发声。

首包延迟能代表语音 Agent 的速度吗？

它只能代表开始回应的速度。还需要同时记录首句有效信息、到 IDLE 的时间、任务完成时间和成功率。

为什么 turnComplete: true 不能直接当作完成？

标准 Live 中它结束轮次；Extended Thinking 中它可能只结束一次中间发声。整项任务完成要看 interaction_status: IDLE。

怎样测试打断？

分别在开头、中段、尾段以及工具运行时打断，检查停声延迟、重复动作、状态一致性和新请求是否成为权威输入。

生产环境应该选哪个模型？

按任务形状路由。即时轮次优先使用 Live；复杂任务在成功率收益足够时使用 Extended Thinking。两者都要通过同一套冻结工作负载。

参考资料

• Google：Gemini 3.8 Live 与 Extended Thinking 发布说明
• Google AI for Developers：Live API 中的 Thinking
• Google AI for Developers：Gemini 3.8 Live Extended Thinking
• Google AI for Developers：Live API 概览
• Google AI for Developers：Live API capabilities
• Google AI for Developers：Session management
• Google DeepMind：Gemini 3.8 Audio 模型卡
• 站内相关文章：语音 Agent 的实时转写协议合同
• 站内相关文章：OpenAI 低延迟语音 AI 架构

真正需要回答的问题，是哪种模式既能维持自然对话，又能在真实故障和用户打断下完成正确任务。双延迟合同让这个选择从演示观感变成可复算的工程决策。