Soniox 新版语音识别引入 Agent 文本上下文

语音 Agent 刚问完问题，用户只回两三个词，识别系统却听错了；电脑扬声器漏回来的 Agent 声音，又被当成用户发言。这是 Soniox STT v6 想解决的两个问题：让语音转文字模型同时接收 Agent 的文本，用对话上下文辅助识别，并过滤残留回声。

这次更新值得看，但理由还不是「准确率领先」。原文没有给出 v6 的准确率和延迟实测。更有参考价值的是它的接入方式，以及语音应用需要如何处理播放时序、用户打断和输出格式。

识别用户回答，为什么还要传 Agent 的话

在级联语音系统里，STT 负责语音转文字，后面再接语言模型和语音合成。传统 STT 通常只收到来电者的音频，不知道用户在回答什么问题。

长句还能靠内部信息纠错，短回答提供的线索很少。Soniox 文档举出的例子是，「River Roast」被识别成「River Road」，「a tow」变成「a tour」。如果模型知道 Agent 刚问了什么，就多了一层判断依据。这些是文档示例，不能当作整体准确率提升的证明。

v6 提供流式模型 stt-rt-v6 和文件模型 stt-async-v6，覆盖 60+ 种语言。但 Agent 文本输入只支持前者，需要在启动请求里设置 "enable_agent_text_input": true。

随后，应用通过承载用户音频的同一个 WebSocket，发送 Agent 正在说的文本。消息格式如下：

{"type": "agent_text", "text": "...", "end_of_segment": true}

要留意 end_of_segment，它标记片段结束。Agent 文本用于帮助模型理解和过滤音频，不会出现在返回的转写结果里。

真正要接好的，是文本与播放的时序

这项能力不是把完整回复提前塞进接口就结束了。消息没有时间戳，模型根据文本抵达音频流的位置判断它对应哪段声音。

Soniox 建议按 TTS 时间戳控制发送节奏，每段文本比实际播放提前 500 ms 到 1 秒。这里的 TTS，就是把 Agent 回复合成为声音的环节。应用需要知道声音播到了哪里，才能把对应文本送过去。

用户中途插话时，应用应发送完已播放部分的文本，以 end_of_segment: true 结束片段，并丢弃尚未播放的剩余文本。否则模型收到的上下文会包含用户根本没听见的内容。

回声过滤也依赖这份文本。模型知道 Agent 正在说什么，便能把漏回麦克风的 Agent 声音与用户发言区分开，同时继续监听用户打断。

模型层的回声过滤仍需配合声学回声消除（AEC）使用。

原文明确要求保留 AEC：v6 处理的是现有 AEC 没清理干净的残留声音。对浏览器语音应用或 Node 编排服务来说，接入工作的重点因此包括播放进度、文本发送和打断事件的协调。

升级能直接换模型名，行为却要重新验收

原文称 v6 改善了数字、货币、单位、日期、ID、姓名和专业术语识别，也增强了会议转写、说话人区分、口音及句内语言切换。这些属于厂商描述，文章没有提供对应的量化验证。

其中一个变化会直接影响业务：说出「15 dollars and 20 cents」，v6 按口述形式输出，不再直接写成 $15.20；编码里的连字符也只有说出来才出现。「period」「new line」这类口述命令会作为词语返回，由应用执行标点或换行处理。

因此，依赖转写结果提取金额、校验编号或执行编辑命令的代码，都需要回归验证。

部署方面，它是专有托管模型，参数量未披露，只提供 Soniox cloud API，通过 WebSocket 流式接入或异步 REST 使用，未披露自托管和端侧方案。迁移入口是把模型名换成 stt-rt-v6 或 stt-async-v6。v5 将于 2026 年 12 月 15 日移除，之后请求自动路由到 v6。

价格按 token 计算，折合流式约 $0.12/小时、异步约 $0.10/小时，包含说话人区分和语言识别。实时 Agent 文本另按输入文本 token 收费，为 $4.00/百万 token。估算成本时，不能只乘音频时长。

我的判断

我认可它解决问题的方向：识别系统拿到 Agent 刚说的话，有助于理解短回答；把这些文本用于残留回声过滤，也贴近语音通话的实际故障。但「显著优于 v5」目前仍是厂商主张。

原文引用的 Pipecat 基准包含 1,000 个真实样本，测量语义词错误率（semantic WER）和最终片段返回耗时（TTFS）。stt-rt-v5 的成绩是 1.34%、完整正确转写占比 83.3%、TTFS 中位数 260 ms、P95 为 305 ms。其语义 WER 还高于 v4 的 1.25%。Azure 的平均 WER 为 1.21%，但延迟中位数为 1,016 ms。

这些数字只能说明旧模型的表现，不能证明 v6 的效果。

横向比较同样要谨慎：AssemblyAI Universal-3.5 Pro Realtime、Deepgram Nova-3、ElevenLabs Scribe v2 Realtime 的 Pipecat 平均语义 WER 分别是 1.44%、1.71%、3.16%，TTFS 中位数分别是 282、247、281 ms，但 Soniox 对应的仍是 v5。

「首次知道 Agent 在说什么」的宣传也需要限定。原文指出，AssemblyAI 已在 2026 年 7 月提供 agent_context。Soniox 更明确的差异，是文档描述了利用文本过滤 Agent 回声；AssemblyAI 相关文档没有描述这项过滤，不能据此推断它一定不具备。

与单纯升级 STT 或继续优化 AEC 相比，这个方案增加了上下文利用能力，也增加了时序维护工作。是否划算，要看自己的短回答和回声问题有多严重，文章没有给出足够的对照数据替团队下结论。

能拿来做什么

• 如果正在接入语音 Agent，先用短回答、扬声器外放和用户中途打断三类录音验收，同时记录识别错误与错误打断，避免只测安静环境下的长句。
• 在浏览器播放层或 Node 编排层维护已播放进度，再据此发送 agent_text；用户打断后，及时结束当前片段并丢弃未播放文本。
• 使用 v5 的项目应在 2026 年 12 月 15 日前检查金额、编号、连字符及口述命令的处理，并把 Agent 文本 token 纳入费用估算。