Gemini 3.8 Live升级实时语音

谷歌把实时对话模型再往前推了一步

当地时间 9 月 15 日，谷歌发布 Gemini 3.8 Live 和 Gemini 3.8 Live Extended Thinking。前者面向大规模部署和成本优化，后者则把重点放在高复杂度任务、多步推理以及语音交互过程中的实时思考。

这不是一次简单的“模型参数升级”。Gemini Live 的产品方向正在发生变化：它不再只是一个能够把文字转成声音的聊天机器人，而是试图成为可以持续听、持续看、持续调用工具，并且在复杂任务中边想边说的语音智能体。

对于开发者来说，真正值得关注的也不是“支持 97 种语言”这一单项指标，而是谷歌正在解决实时语音应用最棘手的三个问题：延迟、打断和推理过程中的对话连续性。

两款模型，分别解决两类问题

Gemini 3.8 Live 和 Extended Thinking 的定位相当清楚。

• Gemini 3.8 Live：强调速度、成本和稳定性，适合客服、语音搜索、实时翻译、陪伴式应用以及需要规模化部署的语音代理。
• Gemini 3.8 Live Extended Thinking：强调复杂任务中的准确率和多步推理，适合金融客服、售后排障、复杂业务流程、研究助理和需要调用多个工具的企业智能体。

这种双模型策略并不新鲜，但对实时语音产品尤其重要。一个客服机器人可能每天处理数百万轮简单咨询，绝大多数请求并不值得调用昂贵的深度推理模型；但当用户开始描述一笔异常交易、一个跨系统订单，或者一套复杂设备的故障时，模型又必须有能力在后台完成多步判断。

过去，开发者通常需要自己搭建路由逻辑：简单问题交给快速模型，复杂问题切换到推理模型。Gemini 3.8 Live Extended Thinking 的价值，在于它试图把这部分能力直接放进实时交互流程里，让模型在对话不中断的情况下决定何时深入思考。

“边想边说”比单纯提速更重要

实时语音交互最怕两件事：一是停顿太久，用户以为系统失效；二是模型没想清楚就开始说，随后不断自我纠正。

谷歌给出的方案是让推理和发言并行进行。面对复杂任务，模型可以先用“让我确认一下……”之类的自然语言提示回应用户，同时在后台继续处理工具调用、检索和多步推理。它不需要等所有结果生成完毕后才一次性回答，也不会为了维持流畅而只能给出浅层结论。

这更像是一个经验丰富的人工客服：他会先告诉你“我查一下订单状态”，让你知道对话还在继续；与此同时，他在后台查询系统、核对规则，最后再给出完整处理结果。对于语音产品而言，这种“可感知的等待”通常比一段完全静默的等待更容易被用户接受。

不过，边思考边说也带来了新的工程挑战。模型必须区分哪些内容可以提前说，哪些内容必须等工具返回后再说；如果后台检索失败，还要能够自然地修正前面的承诺。否则，所谓的实时推理很容易变成“边说边改口”。

97 种语言自动切换，重点不只是覆盖面

Gemini 3.8 Live 可以在对话中自动检测并切换 97 种支持的语言。对于普通用户，这意味着可以在同一段对话里混用中文、英语、日语或其他语言，而不必每次手动修改设置。

对开发者而言，语言自动切换的价值更大。跨境客服、旅游助手和国际化教育产品不必为每种语言维护一套独立的会话状态，也不需要在客户端先做一次语言分类，再把请求路由到不同模型。语言识别、上下文维持和语音输出可以被放在同一条实时会话链路中处理。

但“支持语言数量”并不等于“所有语言体验相同”。实时语音系统还要面对口音、方言、代码混读、专有名词和行业术语等问题。尤其是在银行、医疗和企业客服场景，正确识别一个产品名、账号、金额或地址，往往比普通闲聊中的语音自然度更重要。

因此，97 种语言更像是能力上限，而不是交付质量的保证。真正落地时，开发者仍然需要针对目标市场做词表、术语提示、转写校正和人工兜底。

视觉输入和工具调用进入同一条对话流

Gemini 3.8 Live 支持近实时处理视觉输入。用户可以通过摄像头展示物体，也可以共享屏幕，让模型根据正在发生的内容进行回应。此前 Gemini Live 已经支持摄像头和屏幕共享，但 3.8 系列的变化在于，视觉理解、语音交流和后台工具调用被进一步组合到同一个连续会话里。

比如，用户可以让模型查看一张报错页面，口头描述刚才做过的操作，然后要求它调用知识库或工单系统给出下一步建议。模型不再需要把图像识别、语音转写和文本问答拆成三个互相独立的接口。

与此同时，模型可以在后台执行工具和 API 调用，并保持前台对话不中断。这是语音智能体从“问答”走向“办事”的关键一步。

一个合格的工具调用流程至少要处理以下问题：

1. 确认调用意图：用户只是询问余额，还是希望模型真的发起转账？
2. 管理权限边界：哪些工具可以自动执行，哪些操作必须二次确认？
3. 保持会话状态：工具返回结果时，模型是否还记得用户前面提到的约束？
4. 处理异常：接口超时、权限不足或返回脏数据时，模型如何向用户解释？
5. 控制延迟和成本：简单请求不能因为复杂的工具链而变得缓慢且昂贵。

Gemini Live API 提供的是底层实时连接能力，而不是一套自动解决所有业务问题的智能体框架。开发者仍然需要自己设计状态机、工具权限、日志审计和人工接管机制。

基准测试成绩不错，但落地要看端到端表现

谷歌公布的数据显示，Gemini 3.8 Live Extended Thinking 在 Artificial Analysis 语音对语音质量指数中排名第一，得分为 82.6%；在 τ-Voice 智能体任务完成率中达到 68.6%，在 Sierra 的 τ-Voice-banking 基准测试中达到 35.1%。它在 Big Bench Audio 上的得分为 97.7%。

Gemini 3.8 Live 则在 Speech Agent Arena 排名第二，并强调成本效益和规模部署能力。两款模型在 ServiceNow EVA-Bench 语音智能体测试中，也试图在准确率和对话质量之间取得平衡。

这些成绩说明，谷歌并没有只追求“说话像真人”，而是把语音质量、任务完成率、推理能力和部署成本放到了一张成绩单里。这是正确方向，因为企业真正购买的不是悦耳的声音，而是更少转人工、更高一次解决率和更低的每次会话成本。

但开发者不应直接把基准排名等同于生产效果。语音智能体的实际体验由多个环节共同决定：网络往返时间、音频编码、端侧采集、WebSocket 稳定性、工具响应时间、模型首字节延迟，以及最终语音合成速度。模型本身在基准测试中快 200 毫秒，放到一个需要连续调用三个企业 API 的工作流里，可能仍然不够快。

更值得观察的是谷歌是否会公开足够完整的价格、速率限制、会话时长和区域可用性信息。对于大规模语音业务，这些参数往往比排行榜上的几个百分点更能决定项目是否值得上线。

Gemini Live API：开发门槛降低，但架构工作不会消失

谷歌表示，开发者可以通过 Gemini Live API 构建低延迟、双向的语音和视频交互。该 API 基于有状态的 WebSocket 会话，支持连续音频、视频或文本流，并可配合函数调用等工具能力。

简单示意代码如下。实际模型名称、区域、价格和权限，需要以 Gemini Live API 或 OpenAI Hub 的最新文档为准：

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_OPENAI_HUB_KEY",
    base_url="https://openai-hub.com/v1"
)

response = client.responses.create(
    model="gemini-3.8-live",
    input=[
        {
            "role": "user",
            "content": [
                {
                    "type": "input_text",
                    "text": "请用中文回答，并帮我判断这段客服对话是否需要转人工。"
                }
            ]
        }
    ],
    modalities=["text", "audio"]
)

print(response.output_text)

需要注意，这段代码主要用于说明兼容 OpenAI 格式的调用方式。真正的实时语音应用通常需要使用 WebSocket 或 SDK 的流式接口，持续发送音频帧并接收模型返回的音频事件，而不是等待一个完整的同步响应。

如果团队已经在使用 OpenAI 风格的客户端，OpenAI Hub 可以作为统一接入层，在同一套接口习惯下管理 GPT、Claude、Gemini、DeepSeek 等模型。这样做的优势是便于切换模型和做成本对比，但实时语音场景仍需重点验证音频协议、流式事件格式、工具调用兼容性和会话保持能力，不能只看文本接口是否“能调通”。

在谷歌公布的合作生态中，声网、Fishjam、LiveKit、Pipecat、Vercel 和 Vision Agents 等平台都可以帮助开发者搭建语音驱动界面。对于不想从底层处理音频流、打断检测和会话恢复的团队，这类基础设施会比直接裸接模型更现实。

谷歌真正想争的是语音智能体入口

从产品路线看，Gemini 3.8 Live 的目标并不是推出一个更会聊天的语音助手，而是抢占语音智能体的基础模型入口。

文本智能体已经进入工具调用、工作流编排和企业系统集成阶段，语音智能体也正在经历同样的迁移。过去的语音产品主要解决“听懂”和“回答”，下一阶段要解决的是“理解上下文、执行任务、解释过程，并在出错时负责”。

Gemini 3.8 Live Extended Thinking 试图用实时推理降低复杂任务中的机械感，Gemini 3.8 Live 则用较低成本覆盖更多并发请求。两者配合起来，比较适合企业按照任务难度动态分层，而不是让所有请求都使用同一款昂贵模型。

当然，谷歌仍需证明三件事：第一，Extended Thinking 的推理延迟是否足以应对真实业务；第二，97 种语言在非英语市场是否能保持稳定质量；第三，模型在银行、客服等高风险工作流中是否具备可审计、可回滚的工具执行能力。

如果这三个问题能够解决，Gemini 3.8 Live 就不只是 Gemini 应用的一次功能更新，而可能成为谷歌向开发者市场输出实时智能体能力的重要节点。对开发者来说，现在可以开始测试，但不建议只做一个“能和模型聊天”的演示。更值得投入的是把它放进真实业务链路，测量端到端延迟、任务完成率、转人工率、工具失败率和单次会话成本。这些指标，才是实时语音模型最终能否产生商业价值的答案。