Soniox 发布 STT v6：让语音识别第一次「听见 AI 自己说了什么」

先讲结论： 11 月 3 日，语音识别公司 Soniox 上线了 STT v6（stt-rt-v6 实时版、stt-async-v6 文件版）。它这次改的不是"识别得更准一点"，而是一个接口层面的东西：允许开发者把 AI 助手正在说的话，同步喂给识别模型。

听起来像小事。但它一次性解决了语音 Agent 最丢人的两个毛病——自问自答（麦克风收到自己的喇叭声，把自己说的话当成用户说的）和听错短回答（用户只回一句「River Roast」，模型听成「River Road」）。

本文基于 Soniox 官方博客与官方文档整理，并交叉核对了 Voice AI Space、MarkTechPost 等多家媒体 11 月 3 日的转述，属于基于多家媒体转述整理，时间与核心事实一致。

3分钟看懂：它到底改了什么

老规矩先看问题。一个语音 Agent 的循环是这样的：用户说话 → 识别成文字 → 大模型想怎么回 → 合成语音播出去。

问题在于识别模型只听得见麦克风里的一半对话。AI 自己的声音是通过喇叭放出去的，声学回声消除（AEC）会尽量把它从麦克风信号里抠掉——但抠不干净。尤其 AI 刚开始说话那一瞬间，残留最多。

于是两个经典故障就来了：

• 自问自答：识别模型把残留的 AI 声音当成用户在说话，Agent 打断自己、回应自己，甚至进入死循环
• 短回答听错：用户只说"要"，模型没有上下文，这个字几乎无法判断。但如果它知道 AI 刚问的是"您要可乐还是雪碧"，"要"的正确率会完全不同

Soniox 的做法很直接：既然你的程序里本来就有 AI 要说的话（送给 TTS 的那份文本），那就顺手也送一份给识别模型。

这就是 v6 的两个新能力：

• Agent text input（助手文本输入）：把 AI 即将说出的文本按播放节奏分片，通过同一条 WebSocket 送进去，识别模型从此知道"用户在回答什么问题"
• Agent voice echo cancellation（助手语音回声消除）：用这份文本判断哪些声音是"自己的残留回声"，把它们从转写结果里剔除，同时继续听用户

关键一点：AI 说的话不会出现在转写结果里。你拿到的仍然只有用户说的话。这份文本只当"上下文"用，不当"内容"用。

它怎么判断"哪个声音是我自己"

这是我觉得这版最聪明的设计。

传统做法是纯信号处理：算回声路径、做自适应滤波。做得好能压掉 90% 多，但剩下的残余——尤其是 AI 开口的头几十毫秒——还是会被识别模型捡起来。

v6 换了个思路：我知道我要说什么，所以我能认出那是不是我。

• 开发者发送：{"type":"agent_text","text":"Which one would you like?","end_of_segment":true}
• 模型内部：这句话的音频如果出现在麦克风里 → 是我的回声，丢掉；其他声音 → 是用户，正常识别

官方文档里给了一个很典型的场景：AI 正在播报"我可以订今晚 7 点或 8 点的四人桌，您要哪个时间"，用户在 AI 还没说完时就插话说"8 点"。老方案里这几乎必然出问题——要么把用户的话当成回声滤掉，要么把 AI 的尾音当成用户的话。v6 能同时做对：滤掉自己的、保留用户的。

但有个前提不能省：原来的声学回声消除必须继续开着。 官方文档写得很明确——agent text 处理的是"AEC 漏掉的那部分"，不是替代 AEC。关掉 AEC 只靠这个功能，会把事情搞得更糟。

怎么用：三行配置 + 一个时序纪律

接入本身不复杂。开一个开关：

• 建立实时连接时，在 start request 里带上 "enable_agent_text_input": true
• 之后在同一条 WebSocket 上，正常发用户音频的二进制帧
• 同时把 AI 要说的话，按小段发文本帧：{"type": "agent_text", "text": "..."}，每段 AI 发言结束时带 "end_of_segment": true

真正难的是什么时候发。官方文档在这块写得比大多数 API 文档都实在，值得原样记住三条：

第一，跟播放走，不跟 LLM 走。 大模型出字速度远快于说话速度，如果你把整段回复一次性发过去，模型会以为 AI 一秒之内说完了全部内容，时序全乱。要跟着 TTS 实际播到哪儿发到哪儿。

第二，提前约 500 毫秒到 1 秒。 文本要比声音早一点到达，让模型有准备。文档建议的区间是 0.5–1 秒，示例代码里用的是 0.7 秒。可以用 TTS 返回的字符或词时间戳来算——Soniox 自己的 TTS 开 return_timestamps 就能拿到。

第三，用户打断时，只补"已经播出去的"。 用户插话、你掐掉播放，这时要补发"已播放但还没发送"的那一小段，然后立刻发 end_of_segment；没播出去的部分一个字都不要发，因为用户根本没听见。这条如果写错，模型会以为 AI 说了一些用户从没听过的话，识别质量反而下降。

还有两个容易踩的细节：发的内容要是真正会说出口的话，SSML、markdown、[laughs] 这类表达标签要去掉，不然模型会把它们当上下文；公司名、产品名这类"背景知识"应该走另一个 context 字段，不要塞进 agent text——两者的分工是：context 管整通电话的业务词汇，agent_text 管"AI 刚刚说了什么"。

除了这两个功能，v6 还改了什么

按官方说法，v6 是"一个统一模型覆盖 60+ 语言"，语言可以在一句话中间自由切换，不用切换模型。同时改进的还有：

• 语音输入（dictation）：数字、货币、单位、日期、字母数字 ID、人名和专业术语的书写更准；边说边出字，说完立刻定稿
• 会议转写：快速换人、抢话、重叠说话、相似音色、不同麦克风条件下的说话人分离（diarization）
• 实时翻译：动态调整"攒多少语音再翻"，官方点名的难点是德语和韩语——这两种语言里，句子后半段的信息会反过来决定前半段该怎么翻
• 语种识别、端点检测、上下文利用：全部有改进

价格：还是那条便宜路线

Soniox 一直靠低价打市场，v6 没改这个策略。按官方定价页：

• 输入音频：实时 $2.00 / 百万 token，异步 $1.50 / 百万 token
• 输入文本（context、agent_text）：实时 $4.00 / 百万 token，异步 $3.50 / 百万 token
• 输出文本：实时 $4.00 / 百万 token，异步 $3.50 / 百万 token
• 折算成小时：实时约 $0.12 / 小时音频，异步约 $0.10 / 小时音频

官方给的换算基准是：1 小时音频 ≈ 30,000 输入音频 token，1 小时语音 ≈ 15,000 输出文本 token。

Agent text 的计费方式说得很清楚：按输入文本 token 计，和其他输入文本同价；只算真正到达模型的文本。所以它不会变成一笔隐藏开销——一段 20 字的 AI 回复，大概几十个 token 的量级。

顺手算一笔：1000 小时录音，实时转写约 120 美元。这个价位对做大批量质检、会议归档的团队来说，基本不会成为决策瓶颈。

诚实说一句：v6 没有公开自己的跑分

这是全文最需要提醒的地方。

Soniox 的 benchmark 页面现在挂着一份很漂亮的数据：1.34% 语义 WER、83.3% 完整句、260 毫秒中位出字时间，在一份含 Azure、AssemblyAI、Deepgram、Cartesia、Google、OpenAI 的公开对比表里排在前列。

但页面上写得很清楚：这组数字是 2026 年 8 月测的，跑的是 stt-rt-v5——上一代模型。

也就是说，v6 目前只有"显著更准"这句定性描述，没有公开的新 WER 数字。Soniox 敢说"世界上最准的语音识别"，这是厂商自述；在第三方用同一套测试集复现之前，把它当方向性参考更稳妥。

顺带说个技术细节：那张表用的是 Pipecat 的公开 STT 基准，1000 条真实样本，真实流式模式下测延迟——这是目前语音圈相对公认的一套评测方式，比各家自己报的"实验室数字"可信。所以等它把这套基准在 v6 上重跑一遍，才是真正能下判断的时候。

另一个限制：agent_text 只支持实时模型 stt-rt-v6。文件转写（stt-async-v6）没有这个能力——这很合理，离线文件里本来就没有"AI 正在说话"这回事。

适用场景：谁现在就该看

1. 做电话/客服语音机器人的。 这是最直接的受益者。语料里全是"要"、"对"、"8 点"、"第二個"这种一两个字的回答，偏偏这些最短的回答最依赖上文。接上 agent text，识别准确率的提升会集中在最贵的那部分——需要用户重复一遍的对话。

2. 用喇叭外放的设备。 车载、智能音箱、会议室的免提电话、笔记本外放。这类场景回声残留最严重，自问自答的 bug 也最多。官方点名了这几类设备。

3. 做语音输入法 / 听写工具的。 v6 在数字、单位、日期、ID 上的书写改进是实打实的痛点——"一千二百三十四"写成 1234 还是 1,234，"三点五"写成 3.5 还是 3月5日，这些错一次用户就要改一次。

4. 多语言会议记录。 单模型 60+ 语言、支持句内混语，对跨国团队来说省掉"这通会议该用哪个语言模型"的判断。

不适用场景：别指望它做的事

1. 别指望它替你做回声消除。 它处理的是残余，前提是你已经有 AEC。没有 AEC 的设备，先解决硬件和信号层的问题
2. 别指望离线文件转写也有这功能。 stt-async-v6 没有 agent text，只有 stt-rt-v6 有
3. 别指望它替你管对话状态。 agent text 只是把文本同步过去，发早了、发晚了、打断后没截断，全是你应用层的事。它是"更聪明的耳朵"，不是"更聪明的大脑"
4. 别拿 v6 当"已验证最强"。 官方没公开 v6 的新基准，第三方也还没复现。要选型，用自己的真实音频跑一遍，别信榜单

避坑：四个最容易犯的错

1. 一次性把整段回复发过去。 大模型出字是毫秒级的，说话是秒级的。不同步就会让模型的时间感知错乱。必须按 TTS 时间戳分片
2. 用户打断后忘了停。 只补"已播出"的部分，剩下的必须丢弃，并且立刻发 end_of_segment
3. 把背景知识塞进 agent text。 公司名、产品名、行业术语走 context；agent text 只放"AI 会说出口的话"。混在一起会让模型把没说过的话当成说过了
4. 关掉原有 AEC 图省事。 官方明确说不行。这个功能是补丁，不是替代品

行动建议

1. 先量一下你的痛点占比。 翻最近 200 通对话，统计"用户重复一遍"和"Agent 打断自己"各占多少。如果加起来不到 5%，这版对你的边际收益有限
2. 做一个 A/B：同一批真实通话录音，一半走旧模型，一半走 v6 + agent text，只比"短回答（≤3 字）的识别准确率"这一项。这是最能体现差异的指标
3. 时序先跑通再谈优化：先用固定的 700 毫秒提前量，能跑通再换成按 TTS 时间戳精确发送
4. 注意迁移窗口：v5 在 12 月 15 日下线，stt-rt-v5 / stt-async-v5 都是。别等到 12 月中才发现代码写死了旧模型名
5. 别急着全量替换：agent_text 是新增能力，不是必须开的开关。先在一个场景开，观察错误率变化，再决定推广

一句话总结：语音 Agent 以前是"闭着眼睛对话"——只能听见用户，听不见自己。v6 给它补上了另一只耳朵，顺便把"自说自话"这个老毛病从接口层治了。

参考来源

• Soniox 官方博客《Introducing Soniox STT v6》（2026-11-03）：https://soniox.com/blog/soniox-stt-v6
• Soniox 官方文档 · Models / Changelog（v6 上线、v5 弃用日期）：https://docs.soniox.com/stt/models
• Soniox 官方文档 · Agent text input（参数、消息格式、时序要求、计费）：https://docs.soniox.com/stt/rt/agent-text-input
• Soniox 官方定价页（实时/异步 token 单价、换算基准）：https://soniox.com/pricing
• Soniox 官方基准页（2026 年 8 月，v5 成绩，Pipecat STT benchmark）：https://soniox.com/benchmarks
• Voice AI Space 报道（2026-11-03）：https://www.voiceaispace.com/articles/soniox-stt-v6-agent-text-input-echo-cancellation
• MarkTechPost 报道（2026-11-03）：https://www.marktechpost.com/2026/11/03/soniox-stt-v6-agent-text-input-echo-cancellation/

事实部分以 Soniox 官方博客与官方文档为准；发布时间与核心功能经 Voice AI Space、MarkTechPost 等多家媒体同日转述交叉印证。

参考来源

• https://soniox.com/blog/soniox-stt-v6
• https://docs.soniox.com/stt/models
• https://docs.soniox.com/stt/rt/agent-text-input