首页2026年10月5日，亚马逊在Bedrock上线了Amazon Nova 2.5 Sonic，内容是推理能力、指令遵循、工具调用准确性的提升，延迟也有所降低，公告原文没有给出任何百分比或毫秒数字，第三方媒体和开发者社区目前也没有人做过独立实测对比。同一天，AWS开源Agent框架Strands Agents新增的语音Agent模块。它的核心卖点是Nova Sonic、OpenAI Realtime、Google Gemini Live之间可以互换，换供应商只需要换模型对象。
一. “换个模型就行”，这句话没说的代价
统一接口确实存在：三家供应商背后，都要实现同一组标准动作，建立连接、发音频过去、把回应收回来、挂断连接。表面上看是一套接口，但往下查几个关键环节，差异没有被真正抹平。
输入这一端，Nova Sonic不支持图片，Gemini Live和OpenAI Realtime都支持。如果开发者用同一套代码给Nova Sonic传一张图，系统会直接报错，不是悄悄忽略或者自动降级处理，是明确告诉开发者”这个不行”。打断检测这件事三家做法也完全不同，各自看的信号都不一样，而且OpenAI这边有个前提，必须开启它自己的语音活动检测和自动打断响应，不然用不了。
更直接的一处取舍也在OpenAI身上：它原生支持把打断这件事完全交给开发者手动控制，但Strands的统一层做了强制要求，如果不把自动检测和自动打断全部打开，直接拒绝运行。OpenAI这项手动控制能力，在这套统一接口里是被关掉的。
工具调用这一层也不对等，这个不对等会在下面讲重连的时候被放大。连系统内部用来监控、排查问题的记录方式，三家之间也没完全对齐。统一接口还给开发者留了一条退路：遇到接口本身覆盖不到的能力，可以直接传一段厂商原生的专属设置进去，绕开统一层。这条退路恰好说明一件事：统一接口盖不住的地方，终究还是要靠这种”开后门”的方式单独补上，不是真的被磨平了。
二. 自动重连，三家给的不是同一个东西
Nova Sonic：连接被物理掐断，历史要重新”读”一遍
Nova Sonic单次连接大约8分钟就会被服务端切断，这是官方给的硬限制。Strands的做法是提前主动重启，不等真的撞到这个上限。重启的方式是物理意义上的重新连接：关掉旧的，建一个全新的，把此前对话里说过的内容（文字部分，包括已经转写完的内容）重新发给新连接，让模型重新”读”一遍，当作背景信息。原始的音频声音完全不会被重传，只有文字。这个重放还带着上限，历史文本攒多了会被截断，只留最近的一部分，太旧的内容会被丢掉。
还有一个容易被忽略的边界情况：如果重连前正好有个工具调用还没返回结果，新连接根本不认识旧连接里那次调用，Strands专门写了处理逻辑，把这个迟到的结果伪装成一句普通的用户发言，塞给新连接，等模型空下来再发，避免打断新一轮对话。
OpenAI Realtime：真实上限其实是60分钟
OpenAI Realtime的官方会话上限其实是60分钟，8分钟是针对Nova Sonic的限制，OpenAI这边宽松得多。
源码里特别提到一点：OpenAI接近这个上限时不会发出任何提示，所以Strands自己设了一个更早的时间点，主动提前重连，不指望OpenAI自己提醒。重放的内容比Nova Sonic更完整，因为OpenAI这边的消息格式能把工具调用和工具结果原样带过去，不用像Nova Sonic那样只能退化成一句干巴巴的文字描述。重连完成之后，Strands还会额外发一条系统消息，去”重新找回”对话的状态。
Gemini Live：唯一真正不用”重读一遍”的
Gemini Live是三家里唯一有服务端记忆机制的：服务端会主动给一个”认领凭证”，重连的时候把这个凭证带回去，服务端凭着它直接找回之前的会话状态，不需要客户端重发任何历史内容。只有在这个凭证还没拿到、或者服务端拒绝认领的情况下，才会退化成跟Nova Sonic、OpenAI一样的文字重放。另外它还有个专门设置，能把原本大约15分钟的纯语音会话上限也去掉，让认领之后的对话可以无限延续下去。
这三种做法说明的是同一件事：”自动重连延续上下文”这句宣传语底下，Nova Sonic和OpenAI实际上每次重连都要让模型重新”读”一遍对话历史，这是会产生额外成本的，对话越长、重连次数越多，这部分开销会累积；只有Gemini Live真正做到了不用重读、直接续上。
三. “内置WebRTC”说的是本地处理声音，不是网络怎么传
框架内置基于WebRTC的回声消除、噪声抑制、自动增益，这句话容易被读成”语音数据是走WebRTC这种网络连接传的”，实际这里的WebRTC指的是处理声音本身的算法，跟三家模型各自用什么协议传输数据没有关系。具体来说，这套本地处理功能背后装的是一个专门的开源扩展包，直接搬运了Google WebRTC项目里真正在用的回声消除、噪声抑制、自动增益代码，里面负责判断”有没有人在说话”的那部分，跟Chrome浏览器里用的是同一套训练好的神经网络。
这些处理都在本地机器上运行：麦克风收到的声音，加上扬声器正在播放的声音作对照，一起送进这套算法处理干净，再喂给模型。这个功能默认是关闭的，需要开发者手动打开才会跑。
四. 为什么盯着”第一声多久出来”这一个指标
可观测性这部分，官方给出的说法是：一次会话持续多久不是重点，第一个声音出来得慢，用户是能直接感觉到的。这个指标只在第一个声音出来的瞬间记一次。接下来这段是结合语音交互的工程常识做的推理，不是官方原文的说法：人对”对方有没有开始回应”这件事的感知阈值很低，但对回答要讲多久这件事相对不敏感，因为声音是边生成边播放、人会跟着听，只要对方开口了，”轮流对话”的感觉就成立了。完整回答讲多久这个指标，会把”这次回答内容本身有多长”这个业务变量也算进去，这跟系统本身快不快是两件事；只盯着第一个声音出来的时间，才是一个干净的、能当体检指标去盯的数字。
五. 写在最后
厂商互换、自动重连、内置声音处理，这三个功能拆开看都有没说出来的代价：换厂商要接受功能对不齐，重连要接受历史重新发一遍的成本，”内置WebRTC”说的也不是网络本身。这些代价不是设计上的失误，是语音Agent要真正能用起来，必须做的取舍。8分钟、60分钟这些会话时长上限，也只是模型接口自己定的业务规则，跟网络传输好不好没关系。
