Google Gemini 3.8 Live 将延展思考带入语音 AI 竞赛

Google 于 9 月 15 日推出 Gemini 3.8 Live，并同步发布了一款可在语音对话持续进行时推理的 Extended Thinking 模型。此次发布瞄准了语音代理长期存在的矛盾：更复杂的任务需要更多算力，但更长的停顿会让助手显得不那么自然。

标准模型侧重响应迅速的对话、视觉上下文和高效部署。Gemini 3.8 Live Extended Thinking 则通过后台推理和异步工具处理多步骤工作。它可以先确认请求、保持交互活跃、汇报进度，随后再给出最终答案。

这一设计让 Google 与 OpenAI 及其他构建原生语音到语音系统的厂商展开更直接的竞争。竞争已不再局限于语音质量，而是关乎助手能否同时行动、推理并维持自然的对话节奏。

Gemini 3.8 Live 将语音 AI 分为两种运行模式

Google 将快速对话和更深入的语音推理视为两项独立的产品需求，而非同一项可调节的设置。

该公司通过 9 月 15 日的 Gemini 发布公告推出了两款模型。Gemini 3.8 Live 是低延迟对话、直接请求和快速返回结果工具的默认选择。

Gemini 3.8 Live Extended Thinking 面向需要规划、并行工具调用或多项相互依赖决策的请求。Google 将两者描述为原生音频模型，即它们在模型内部处理和生成音频，而非完全依赖独立的转录与语音系统。

这种分离反映出一个艰难的设计选择。语音助手必须足够快地回应，才能保持对话流畅；然而，立即作答的模型可能没有足够时间审查证据、比较选项或协调外部系统。

标准模型在固定的延迟配置下使用交错式推理。开发者无法设置其思考级别。这一限制让它在每一次停顿都会影响用户体验的应用中表现得更可预测。

Extended Thinking 提供低、中、高三个推理级别。它可以为问题投入更多计算资源，同时通过语音状态更新保持会话活跃。这种方式给予开发者更多控制权，但也带来了需要管理的新应用状态。

两款模型都接受文本、图像、音频和视频输入，返回文本或音频，支持函数调用，并通过 Google 的 Live API 运行。根据模型文档，标准模型的输入上限为 131,072 个 token，输出上限为 65,536 个 token。

Google 表示，标准模型可在一次对话中识别并切换 97 种支持的语言，也能近乎实时地处理视觉信息。用户可在提出语音问题时，将摄像头对准设备、软件或文档。

该公司通过员工入职、视觉棋类对弈和实时故障排查展示了这一组合能力。其他示例包括根据草图和语音反馈生成 React 组件、协调预订，以及通过语音整理商业材料。

这些演示之所以重要，是因为它们让此次发布超越了“更会说话的聊天机器人”。这些模型被定位为涉及感知、决策、工具和动态上下文工作的交互界面。

Gemini 3.8 Live 正通过 Gemini API、Google AI Studio 和 Search Live 推出。企业访问则将通过 Gemini Enterprise Agent Platform 的私密预览启动。

Extended Thinking 也可通过 API 和 AI Studio 使用。Google 正将其引入 Gemini Live，以及 Docs、Gmail 和 Keep 中部分 Workspace 体验。一些企业和客户体验部署仍处于预览阶段，或被列为即将推出。

这种并不均衡的可用性带来了一个重要区别。开发者可以立即开始评估底层模型，但更广泛的生产环境访问取决于具体产品和客户类别。

因此，Google 同时推出了一个模型系列和一套部署策略。标准版本追求规模化，而 Extended Thinking 则在测试更深入的代理行为能否在实时对话中保持舒适自然。

Gemini Live Extended Thinking 让等待成为对话的一部分

核心技术变化不只是隐藏式推理，而是一种新的交互生命周期：工作可在模型开始说话后继续进行。

传统语音助手通常遵循简单的顺序：用户说话，模型回应，应用将该轮交互标记为完成。外部工具可能打断这一流程，因为助手必须等待工具返回结果。

Extended Thinking 用更长的交互取代单次回应。模型可以确认请求、开始推理、调用工具、叙述进度，最后再给出结论。

Google 的 Live thinking 指南将这些中间消息称为 conversational fillers。它们可以是“正在查询航班选项”这样的有用陈述，而不是空泛的犹豫声。

这一区别对用户和开发者都很重要。模型并非只因一次停止说话就已完成任务。当一个请求仍处于活跃状态时，它可以产生多段话语。

Google 新增了一个交互状态来表示这一过程。IN_PROGRESS 状态意味着模型仍在推理或等待工具；IDLE 状态则告知客户端，完整交互已经结束。

使用标准模型的应用仍可将 turnComplete 视为用户一轮交互的结束。Extended Thinking 客户端则必须改为跟踪更广泛的交互状态。否则，界面可能过早重新打开麦克风或接受新指令。

工具执行方式也发生了变化。Extended Thinking 要求函数采用非阻塞行为，即应用以异步方式运行它们。同步工具会返回错误，因为它们会冻结交互。

这一机制可支持同时搜索航班和酒店的旅行助手。它可以确认请求，解释自己正在比较哪些选项，随后再给出综合推荐。

技术支持代理可以在告知用户自己正在检查什么的同时，查看日志、核对配置细节并比较错误代码。导师则可以先验证公式，再解释计算在哪一步出错。

这些示例揭示了 Gemini Live Extended Thinking 真正的潜力。该模型旨在掩盖运营延迟，而不是假装工作已经完成。

这种差异很容易被低估。在语音界面中，沉默会带来不确定性。除非产品提供加载指示器，否则用户看不到它，也可能无法判断连接是否已经失败。

语音进度更新可以在长任务期间维持信任。不过，只有当更新对应真实活动时才有效。重复或不准确的叙述会让人觉得是在用对话掩饰延迟。

因此，开发者必须协调模型语音与应用状态。他们需要为中断、重复命令、已取消的工具、部分结果和失败请求制定清晰策略。

界面还必须决定当用户在后台推理期间说话时该如何处理。有些中断应当停止任务，另一些则应修改任务，例如在预订搜索继续进行时新增偏好。

这种复杂性意味着 Extended Thinking 不只是一次模型替换。它改变了应用的事件模型。从 Gemini 3.1 Flash Live 迁移的团队必须更新客户端判断交互何时真正结束的方式。

标准模型提供了更简单的迁移路径。开发者只需更新模型字符串并移除不受支持的思考配置。现有的轮次完成行为总体上仍较为熟悉。

Extended Thinking 则需要有意识地调整客户端。团队必须跟踪交互状态、声明非阻塞函数，并在一次请求内处理多次语音回应。

这种划分为产品团队提供了实际选择。语言练习应用可能更看重快速轮流对话，而不是延展规划；处理理赔或预订的服务代理，则可能愿意接受额外复杂性，以换取更强的任务完成能力。

Google 实际上认为，语音系统需要多种延迟预算。即时对话需要一种预算，而重要的多步骤工作需要另一种。Extended Thinking 试图在不让用户陷入沉默的前提下连接两者。

Gemini 3.8 Live 加大了对 OpenAI Realtime 技术栈的压力

Google 正在挑战这样一种假设：开发者必须在自然语音与持续的代理式推理之间二选一。

OpenAI 仍是原生语音代理的重要参照。其 Realtime API支持通过 WebRTC、WebSocket 和 SIP 实现语音到语音交互，同时支持文本、图像和音频输入。

OpenAI 还提供服务器端和语义语音活动检测。这些系统会估计说话者何时结束发言，让模型无需手动发送操作即可回应。

这套技术栈覆盖了实时对话的多个基础能力，支持中断、工具选择、音频配置，以及面向呼叫应用的直接连接。其当前模型目录还包含具备推理和工具使用能力的实时模型。

Google 的新挑战聚焦于长时间运行的工作如何出现在对话中。Extended Thinking 在一个有文档说明的生命周期中，正式整合了后台推理、中间语音、异步工具和交互级状态。

这比简单地说一家公司拥有推理能力、另一家没有要更细致。两个生态系统都支持能力日益增强的实时代理。真正有意义的问题是，开发者能否以多么可预测的方式编排这些能力。

对 Google 而言，广泛的集成增强了这一优势。模型可出现在 Search、Workspace、Gemini app 和企业代理产品中。同一套底层行为能够触达消费者、员工和第三方开发者。

OpenAI 也有自身优势。其实时平台支持 WebRTC 和 SIP，这对浏览器体验和电话系统尤为重要。其音频技术栈还为轮次检测、降噪、转录和语音行为提供了细致控制。

因此，竞争取决于完整工作流程，而非单一基准测试。客户服务部署需要可靠的音频传输、工具执行、可观测性、区域控制以及可预测的故障处理。

对于已经使用 Workspace 或 Google Cloud 的组织，Google 的分发能力可能降低使用门槛。Gmail 或 Docs 中的语音助手可在用户已管理的信息附近运行。

这种接近性也带来了另一项担忧。更强大的语音代理可能在一次交互中访问消息、文档、日历和业务系统。权限边界会变得与模型智能同样重要。

OpenAI 和 Google 都必须证明，它们的实时系统可以在复杂的工具链中遵循授权规则。一个选择了正确操作却使用了错误账户的模型，依然是不安全的。

竞争压力也延伸到了 OpenAI 之外。Artificial Analysis 跟踪 Google、OpenAI、xAI、Qwen、StepFun 等提供商的原生语音模型。多款模型在速度或对话行为等单项指标上领先。

这种多样性削弱了“仅由两家公司主导”的简单叙事。不过，Google 和 OpenAI 仍拥有不同寻常的影响力，因为它们同时具备模型、开发者平台、消费者产品和企业分发能力。

Google 推出两个端点的决定，也迫使竞争对手进一步明确各自产品的边界。开发者需要知道，一款实时模型究竟优先追求即时语音、深度推理，还是可配置的平衡。

单凭“语音模型”这一标签已无法提供足够信息。团队如今需要了解首段音频延迟、打断处理、函数行为、状态管理，以及在多步骤任务中的表现。

Google 相对明确地呈现了这些权衡。Standard Live 偏向直接交互。Extended Thinking 则接受更高复杂度，以处理需要规划和调用较慢工具的任务。

这一定位或许比任何短暂的排行榜名次都更重要。它为开发者提供了一套判断何时应将深度推理置于对话之中的语言体系。

不过，这也提高了预期。一旦模型开始播报进展，用户就会默认它清楚当前发生的情况。错误的状态更新将成为产品故障，而不只是措辞尴尬。

竞争对手可以通过提供更快的推理、更清晰的状态事件、更便捷的电话集成，或更出色的打断控制来回应。语音 AI 的下一阶段，将奖励能可靠整合这些能力的提供商。

Google 的发布让这场竞争更加直观。实时智能正从“模型能否自然交谈？”转向“它能否在不丢失对话上下文的情况下完成有用的工作？”

Gemini 3.8 Live 基准测试尚未解决的问题

早期成绩支持 Google 的定位，但受控基准测试无法证明语音代理能在生产工作流中持续保持可靠。

Google 表示，Extended Thinking 在 Artificial Analysis 的 Speech to Speech Quality Index 中取得了 82.6 的综合得分。该模型在该机构的 τ-Voice 代理式任务指标中也获得了 68.6%。

它在通过音频呈现的推理基准 Big Bench Audio 中取得了 97.7%。Google 还单独报告称，其在 Sierra 面向银行业的 τ-Voice 评估中获得了 35.1%。

独立的语音排行榜提供了有用的背景信息。榜单显示，Extended Thinking 的综合得分高于标准版 Gemini 3.8 Live，后者得分为 76.0。

结果也揭示了预期中的权衡。标准版 Gemini 3.8 Live 在对话动态方面获得 96.1%，且首段音频响应时间低于 Extended Thinking。

Extended Thinking 在代理式任务完成方面表现更好，但开始说话所需时间更长。这与一款旨在复杂工作前后投入更多计算的模型相一致。

没有任何单一分数能够概括完整体验。Big Bench Audio 衡量的是模型能否回答通过语音提出的推理问题。它并不代表呼叫中心或工作场所中的每一种问题。

Full Duplex Bench 考察暂停、打断、反馈语，以及何时开口等行为。这些行为很重要，因为即使答案正确，也可能通过令人不适的对话方式传达出来。

τ-Voice 更直接聚焦于任务完成。然而，基准环境无法复现每一次身份验证失败、缓慢的供应商 API、含糊的用户请求，或损坏的业务记录。

这些比较也是动态变化的目标。随着提供商增加模型并调整端点，Artificial Analysis 会更新其指数。发布时的领先位置应被视为当前测量结果，而非永久排名。

Google 自身的演示同样需要谨慎看待。将草图转换为 React 组件，是多模态推理的有用示例。它并不能证明每个生成的界面都能满足生产要求。

预订演示可以展示协调的函数调用。它无法证明当库存变化、支付失败，或两个工具返回相互矛盾的信息时，代理会如何表现。

生产就绪的说法同样存在这种差距。Google 提供了支持生产部署的基础设施和模型功能。每家公司仍需要自行建立评估、监控和升级处理路径。

安全性尤其值得严格审视。语音代理可能听错姓名、接受背景音频中的指令，或以非预期参数调用工具。额外的推理并不会自动消除这些风险。

多语言切换带来了另一项考验。支持 97 种语言对全球服务很有价值，但语言覆盖并不保证在不同口音、领域和嘈杂环境下拥有同等准确性。

开发者还应区分口头进度播报与暴露推理过程。Extended Thinking 向用户提供简短状态更新，而不是保证提供模型内部推理过程的完整记录。

这种区分是健康的。流畅的解释可能不完整，也可能是在作出决策后重新构建的。产品团队应通过结构化日志验证操作，而不是将口头叙述视为审计轨迹。

Google 的音频模型卡是查阅预期用途、安全评估和已知限制的官方入口。这些披露应与性能图表一同为部署决策提供参考。

据该公司称，Google AI 产品生成的所有音频都会获得 SynthID 水印。该水印旨在让合成音频可被识别，同时不会给听众带来明显变化。

水印解决的是来源问题，但无法解决授权或事实准确性问题。可识别的合成语音仍可能给出错误答案，或执行用户不希望的操作。

因此，对此次发布最恰当的解读应保持审慎。Gemini 3.8 Live 在对话方面似乎具备竞争力，而 Extended Thinking 提升了可衡量的推理和任务完成表现。

尚未解决的问题是一致性。企业需要了解，这些提升能否在长时间会话、混合语言对话、工具故障，以及涉及财务或法律后果的请求中持续有效。

企业机会取决于工作流设计

只有当组织围绕语音、权限和人工审核重新设计工作方式时，Gemini 3.8 Live 才会创造价值。

最明显的应用场景是客户服务，但 Google 的发布不止于呼叫分流。语音代理可以引导用户完成入门流程、检查视觉上下文、查询业务系统，并在一次会话中解释结果。

这种组合适合无法持续打字的一线工作。技术人员可以展示受损部件、描述其症状，并在不离开设备的情况下请求正确的处理流程。

仓库员工可以在共享摄像头画面的同时询问某件商品。助手或许能够识别产品、检查库存，并说明下一步处理方式。

员工还可以使用 Docs Live 或 Gmail Live 讨论草稿、查找相关邮件并安排后续工作。价值来自减少界面切换，而不只是语音本身。

这些场景要求审慎的数据边界。模型不应仅因用户提出了宽泛问题，就搜索所有已连接的数据源。工具需要狭窄的作用范围和明确授权。

组织应将每一次函数调用视为一项运营事件。应用程序应记录运行了哪个工具、适用了哪些权限，以及结果是否改变了外部系统。

高影响操作需要确认。读取日历不同于取消会议。比较航班不同于购买机票。

语音界面让确认设计更具难度，因为用户无法在提交前浏览表单。代理应在执行前重述关键姓名、日期、数量和目的地。

视觉定位也带来类似义务。摄像头输入可以帮助助手理解即时环境，但也可能拍到私人文件或旁观者。

应用程序需要明确的录制提示和保留政策。它们应尽量减少进入模型的信息，并避免保留不必要的音频或视频。

团队还必须决定何时使用 Extended Thinking 才合理。对每一次问候或简单查询都运行深度推理，只会增加延迟和运营成本，而不会改善结果。

路由层可以将直接任务发送给标准版 Gemini 3.8 Live。它可以将 Extended Thinking 留给涉及多个工具、证据相互冲突或需要作出实质性决策的请求。

这种架构映射了人工支持的工作方式。简单问题会立即得到回答。复杂案例则进入包含调查和状态更新的较长流程。

不同之处在于，用户可能看不到这一交接。设计良好的系统应说明请求何时进入更深层的工作流，以及用户如何停止它。

知识质量仍是另一项约束。模型无法依据过时政策或不完整文档提供可靠指导。语音的流畅性可能让薄弱的信息听起来更确定。

企业需要受治理的数据源、检索测试和明确的纠错责任归属。可搜索的AI 知识库可以帮助组织源材料，但无法替代访问控制。

评估应聚焦于完成的工作，而非令人印象深刻的对话。团队可以衡量工具选择是否正确、任务是否成功完成、能否从失败中恢复，以及人工升级率。

他们还应测试打断行为。用户会改变主意、增加约束条件，并在助手说话时插话。只能在有序对话中表现良好的系统，尚未准备好投入使用。

延迟需要在每个阶段分别衡量。首段音频响应时间描述代理开始回应的速度，却不能说明完整任务需要多久。

一款模型可能很快开口，但缓慢完成工作流。另一款模型可能在给出更完整答案前停顿更久。产品团队需要设定与实际用户旅程相关的阈值。

Google 的合作伙伴名单包括语音基础设施提供商和企业软件公司。这表明该公司希望 Gemini 3.8 Live 嵌入更广泛的系统中，而非局限于 Google 自身的界面。

这些合作伙伴可以简化媒体传输、编排和部署，但无法免除针对具体应用的安全防护需求。

最可信的早期部署将采用结果可观察、范围受限的任务。它们不会一开始就给予通用语音代理访问整家公司的不受限制权限。

Gemini 3.8 Live 让雄心勃勃的体验更容易制作原型。企业机会取决于这些原型能否转化为受控、可测试的工作流。

三个信号将表明 Extended Thinking 是否有效

下一项考验是在真实运营压力下的采用情况，而不是又一次精心打磨的语音演示。

第一个信号来自使用新 API 端点的开发者的生产表现。团队应关注错误率、会话稳定性、打断处理，以及异步函数调用的可靠性。

Extended Thinking 要求客户端在单次语音轮次之外持续跟踪交互。若出现重复调用、过早进入空闲状态或令人困惑的状态播报等报告，将削弱 Google 的设计论据。

开发者能够顺利迁移并维持稳定的长时会话，将进一步增强这一判断。来自 LiveKit、LangChain 和 Pipecat 等平台的可复用编排模式，也将降低采用门槛。

第二个信号是其在 Google 企业与生产力产品中的更广泛可用性。目前，多项体验正通过预览或有限客户访问的方式推出。

若能在 Workspace 和 Gemini Enterprise Agent Platform 中更大范围发布，将表明 Google 对模型的运营控制能力抱有信心。若长期停留在预览阶段，则可能意味着集成和治理仍有待完善。

在 Docs、Gmail、Keep、Search 以及客户体验系统中的使用情况，将揭示哪些任务适合通过语音推理完成。持续复用比因新鲜感驱动的尝试更重要。

第三个信号是竞争对手的回应。OpenAI、xAI 及其他提供商可以通过更低延迟、更高的智能体任务完成率、更清晰的生命周期控制或更强的电话支持来应对。

排行榜变化将提供一个观察视角，但开发者行为更具说明力。只有当团队足够信任一款模型，愿意将真实工具接入其中并持续运行时，它才算真正胜出。

Google 的双模型策略提出了一个明确假设：快速对话与更深入的推理应继续作为独立选项，因为两者分别服务于不同的交互时间预算。

如果开发者认为路由过于繁琐，或用户不喜欢被旁白式等待打断，这一假设就会被削弱。若应用能够完成更困难的任务，同时避免造成漫长而不确定的沉默，它就会得到强化。

对于采购方而言，眼下应进行一次受控对比。在同一组具有代表性的通话场景中测试两款模型，包括打断、工具调用失败、模糊请求和敏感操作。

将任务完成情况与对话质量分开记录。衡量首段音频延迟、总解决时间、工具准确率和升级处理频率。

开发者还应测试 Extended Thinking 相比标准 Live 何时能真正带来价值。更深入的模型应凭借更好的结果证明自身价值，而非仅仅提供更复杂的回应。

Gemini 3.8 Live 改变了语音 AI 的竞争格局，因为它将持续推理视为用户体验的一部分。但这并不意味着每一项困难任务都适合放在语音界面中完成。

未来一到三个月应能厘清：后台推理究竟能改善真实工作流，还是仅仅让等待听起来更顺畅。对你的产品而言，哪一种结果最重要：更快的语音响应、更强的任务完成能力，还是对两者都拥有更清晰的控制？