语音 Agent 模型退役前的排查指南

语音 Agent 即使没有发布新版本，也可能因为供应商下线旧模型、自动转发请求或分批迁移流量而改变行为。原文梳理了 2026 年 11 月初的一批调整，最紧迫的是部分 Gemini 语音预览模型列出的 11 月 17 日停服日期。

作者的核心建议很具体：找全模型 ID，记录每通电话实际由谁响应，再通过真实电话复测。值得读的地方是，它把「模型迁移」拆成了配置检查、运行观测和听感验证三件能落地的事。

先分清：停服、自动转发和平台迁移是三回事

原文列出的变化，不能统一当成「换个模型名」。

第一类是停服。Google 的弃用页面为以下模型列出了 2026 年 11 月 17 日的关闭日期，同时注明这是最早可能关闭的日期：

• TTS 模型：gemini-2.5-flash-preview-tts、gemini-2.5-pro-preview-tts、gemini-3.1-flash-tts-preview，替代项是 gemini-3.8-flash-tts 或 gemini-3.8-flash-lite-tts。
• Live API 模型：gemini-3.1-flash-live-preview、gemini-2.5-flash-native-audio-preview-12-2025，替代项是 gemini-3.8-live。

这些被列为关闭，不是自动转发，不能指望旧 ID 到期后继续工作。

第二类是自动转发。按原文，Google 在 11 月 2 日弃用了 gemini-2.5-pro 和 gemini-2.5-flash。从 2026 年 12 月 1 日起，两者分别转向 gemini-3.8-flash 和 gemini-3.5-flash-lite，并按新模型价格计费。

麻烦在于，请求继续有响应，API 却可能不兼容：function calling 和 thought signatures 校验更严格，thinking-level 设置取代 thinking budget，部分采样参数和预填模型轮次被移除。原文没有给出完整参数清单，迁移时还得逐项检查。

第三类是托管平台调整。ElevenLabs 在 11 月 2 日更新中说明，新建且没有显式指定 LLM 的 Agent，默认从 gemini-2.5-flash 改为 gemini-3.5-flash，已有 Agent 不变。

它还安排了几组迁移：

• gpt-5、gpt-5-mini、gpt-5-nano 及其 2025-08-07 快照，流量向 gpt-5.6-sol、gpt-5.6-terra、gpt-5.6-luna 迁移，从 11 月 11 日的 10% 分阶段升至 12 月 6 日的 100%。原文没有逐一明确对应关系。
• gemini-2.5-flash 和 gemini-2.5-flash-lite 的 fallback 迁移起点从 11 月 1 日推迟到 11 月 8 日，11 月 30 日截止日期不变。
• Claude Sonnet 4.5 于 11 月 30 日弃用，由 Claude Sonnet 4.6 替代。

原文同时指出，OpenAI 列出的上述 GPT-5 系列移除日期是 2026 年 12 月 11 日。这里尤其要分清：gemini-2.5-flash-lite 没有被 Google 弃用，但 ElevenLabs 对它有自己的 fallback 迁移安排。

为什么电话还能接通，问题反而更难发现

语音 Agent 往往串着语音识别、LLM、TTS，还可能配置备用 LLM，或者使用统一处理语音的 realtime 模型。任何一环变化，都可能改变最终体验。

分批迁移尤其难排查。10% 的流量进入新模型时，同一份业务代码可能只有部分电话出现工具调用差异。只看录音，很容易把问题当成偶发故障。

自动转发则可能让成功率看起来正常。请求没有报错，但首次出声更慢、工具参数不同，或者声音变了。电话里没有加载动画，等待就是沉默，用户可能直接挂断。

调用成功，只能证明链路接通，不能证明行为保持一致。

Realtime 事件也有变化。ElevenLabs 此前从 10 月 19 日开始的 Eleven Realtime 推广，在这次更新中覆盖全部 workspace，并支持 OpenAI Realtime 客户端连接 Realtime WebSocket。与此同时：

• speech-started、speech-stopped 从每次停顿触发，改为每个已提交的用户轮次各发送一次。
• 每次手动提交输入音频缓冲区，只转写上次提交之后的语音。
• 空闲音频会话从 60 秒后关闭，改为 3 分钟后关闭，并返回 session idle timeout 错误。

如果你根据这些事件停止播放、处理插话或启动监听计时器，升级后就需要重新验证状态流转。事件名称没变，不代表触发语义没变。

三步排查，要从仓库一直查到电话线路

第一步是找全模型 ID，而且要完整匹配。

除了主配置，还要查环境文件、fallback 列表、辅助函数里的硬编码默认值、评测配置和导出的 Agent 定义。搜 gemini-2.5-flash 时，不能把 gemini-2.5-flash-lite 和 gemini-2.5-flash-preview-tts 当成同一个命中。

把命中项整理成清单，记录供应商日期、到期动作和替代模型，再按日期排序。作者在一个小型演示 Agent 中，最先排到的是 11 月 17 日关闭的 Live native-audio 预览模型和 TTS 预览模型，其后才是 12 月 1 日转发的 gemini-2.5-flash、12 月 11 日移除的 gpt-5-mini。

作者建议把检查接入构建：在用模型距离截止日期不超过 30 天就让构建失败。但清单只能识别已经录入的 ID；托管平台内部选用的模型，也可能根本不在仓库里。

第二步是在每通电话旁边同时记录「配置请求的模型」和「响应报告的模型」。

按配置模型分组，统计实际响应模型不同的比例，再对比首次音频耗时、工具调用错误、转人工和通话时长。作者举的例子是 40 通电话中有 4 通换了模型，占 10%，并明确说明这是虚构日志，不是实测结果。

原文还建议把缺失响应模型的电话计入漂移检查。这里需要理解它的目的：缺失不证明模型换了，但证明这通电话缺少可追查的证据。

第三步是通过真实电话重听。

作者建议用 8 kHz 电话链路，最好再配一部便宜手机，对比迁移前后的声音。电脑上 24 kHz 的高质量样本，可能掩盖电话线路对气声细节和快速语速的影响。使用 LiveKit 时，可以给测试房间接入真实号码；Vobiz SIP trunk 是作者提供的一种接法。

Google 在 11 月 4 日发布的 voice remixing，也被作者视为迁移后的调音工具：输入预置、声音库或自行设计的基础声音，加上「年龄稍大、语速稍慢」之类指令，得到新的、可保存的 voice ID，供 Gemini 3.8 Flash TTS 和 Flash-Lite TTS 使用。它能调整声音，不保证精确复刻旧声音。

我的判断

我赞同把模型 ID 当成需要维护的外部依赖。尤其是备用模型和平台默认值，它们平时不显眼，出问题时却直接影响用户。

不过，显式指定 ID 只能减少默认值变化带来的意外，挡不住供应商对这个 ID 自动转发。静态扫描和逐通电话记录需要同时存在。

作者没有提供迁移前后的延迟、工具调用成功率或挂断率对照。小型演示只展示了排查顺序，40 通电话的数据也是示例，因此这是一套有解释力的运维建议，还不是经过对照实验验证的收益结论。

原文也披露，作者在 Vobiz 负责电话线路相关工作，公司每天处理超过 11M 通电话。这能解释他为何强调真实电话复测，也说明其中的接入方案带有供应商视角。团队可以沿用已有电话服务完成同样的验证。

对一般团队，构建失败的门槛还要结合替代模型可用性安排。比起一次性卡住所有发布，先把清单、责任人和迁移日期补齐，才能让检查真正推动处理。

能拿来做什么

• 给维护语音 Agent 的 Node 服务整理一份模型清单，覆盖主模型、fallback、TTS、Live API 和评测配置，先处理原文列出的 11 月 17 日预览模型。
• 在调用封装和通话日志中关联 call ID、配置模型、响应模型；响应模型缺失时单独标记，方便后续追查。
• 对会自动转发的模型，用现有工具调用用例检查参数校验和 thinking 设置；依赖 realtime 事件的逻辑，再回放录制轮次验证插话与计时器。
• 更换 TTS 后通过真实号码做 8 kHz 对比试听；需要调整语速或音色时，再评估 voice remixing，并保存确定使用的 voice ID。