speech-to-speech 模型直接处理音频输入输出，省去中间转换链路，延迟从秒级降到百毫秒级。
背景
上个月接到一个需求：给客服系统加一个语音交互功能。用户打电话进来，AI 直接用语音回答问题。
听起来不复杂对吧？实际做起来才发现坑有多深。
传统方案是三件套：STT（语音转文字）→ LLM（生成回复）→ TTS（文字转语音）。三个服务串联，每个都有延迟。用户说完话，等两三秒才听到回复，体验跟打国际长途电话似的。
更麻烦的是工程复杂度。WebRTC 连接管理、音频流缓冲、断线重连、浏览器兼容性……光基础设施代码就比业务逻辑多好几倍。
最近发现亚马逊云科技的 Nova 2 Sonic 模型走了一条不同的路——speech-to-speech，音频进音频出，省掉中间的文字转换环节。配合开源框架 Stream Vision Agents，搭建过程比我预想的简单不少。
Nova 2 Sonic 是什么
Nova 2 Sonic 是亚马逊云科技通过 Amazon Bedrock 提供的 speech-to-speech 基础模型。
关键特性：
- 双向实时音频流：不是录完一段话再处理，而是边说边理解边回复
- 原生轮次检测：模型自己判断用户说完了没有，不需要额外的 VAD（Voice Activity Detection）组件
- Function Calling：语音交互过程中可以调用外部工具（查数据库、调 API）
- 多语言支持：不只是英文，中文、日文、西班牙文等都支持
说白了，传统方案需要三个服务各司其职，Nova 2 Sonic 一个模型全包了。
这带来两个直接好处：
- 延迟大幅降低。省掉 STT 和 TTS 两次转换，端到端延迟从 2-3 秒压到几百毫秒。对话感觉像跟真人聊天。
- 工程复杂度降低。不需要对接三个不同的服务，错误处理和状态管理简单很多。
Stream Vision Agents 框架
光有模型还不够。实时语音应用还需要：
- WebRTC 音频传输
- 客户端 SDK（Web、iOS、Android）
- 连接生命周期管理
- 断线重连
- 多房间/多会话支持
这些基础设施代码写起来又臭又长。
Stream Vision Agents 是一个开源 Python 框架，专门干这个脏活。它提供了：
- 插件架构：25+ 集成，包括 Amazon Bedrock
- 客户端 SDK：React、iOS、Android、Flutter、React Native 全覆盖
- 生产部署工具：不是 demo 级别，是可以直接上生产的
- 装饰器 API：几行代码定义一个语音 Agent
架构大概长这样：
用户设备（麦克风 + 扬声器）↕ WebRTC
Stream 边缘网络↕
Vision Agents（Python 后端）↕ Bedrock API
Amazon Nova 2 Sonic
核心集成逻辑
Vision Agents 和 Nova 2 Sonic 的集成点在 Bedrock 插件。框架把音频流管理、WebRTC 连接这些脏活封装好了，开发者只需要关注业务逻辑。
一个基本的语音 Agent 定义大概是这个样子（伪代码）：
from vision_agents import Agent, function_call
from vision_agents.plugins.bedrock import NovaSonicPluginagent = Agent()
agent.use(NovaSonicPlugin(model_id="amazon.nova-sonic-v2",region="us-east-1"
))@agent.on_session_start
async def on_start(session):session.set_system_prompt("你是一个客服助手，帮用户查询订单状态。")@function_call("查询订单")
async def query_order(order_id: str):# 调用内部 API 查订单result = await internal_api.get_order(order_id)return f"订单 {order_id} 状态：{result.status}"agent.run(port=8080)
几个关键点：
Function Calling 在语音交互中的实现
用户说"帮我查一下订单 12345"，Nova 2 Sonic 识别出意图后，会触发 query_order 函数。函数返回结果后，模型直接用语音播报给用户。整个过程用户只听到语音，不感知中间有函数调用。
自动重连
网络抖动在移动端太常见了。Vision Agents 内置了重连机制，WebRTC 断了会自动重建连接，音频流恢复后对话继续。用户基本感知不到中断。
轮次管理
Nova 2 Sonic 自带轮次检测。用户说话时模型在听，检测到用户说完了才开始回复。不需要开发者手动判断什么时候该切换说话方。
这个能力解决了语音交互中一个老大难问题：打断处理。用户可以随时打断 AI 的回复，模型会停止当前输出，开始处理新的输入。
延迟对比
我做了一个粗略对比：
| 方案 | 端到端延迟 | 组件数 |
|---|---|---|
| STT + LLM + TTS | 2-3 秒 | 3 个服务 |
| Nova 2 Sonic | 200-500 毫秒 | 1 个模型 |
延迟差异主要来自两个地方：
- 省掉了 STT 和 TTS 的处理时间（各 300-800 毫秒）
- 省掉了三个服务之间的网络往返
对于实时对话场景，这个差距是质变级别的。2 秒的延迟让人觉得在跟机器说话，500 毫秒以内就接近真人对话的感觉了。
多语言支持
这个对中文场景特别有意义。
传统三件套方案做中文语音，STT 和 TTS 都需要单独找中文模型。而且中英混杂的场景（技术领域太常见了）处理起来很头疼。
Nova 2 Sonic 原生支持多语言。用户用中文问，它用中文答。中间夹几个英文术语也能正确处理。不需要额外配置语言参数。
生产部署考虑
Demo 跑通和上生产之间差距很大。几个需要注意的点：
并发处理
每个语音会话是一个持续的双向流。100 个同时在线用户就是 100 个并发流。Bedrock 的配额和 Vision Agents 的服务器资源都需要提前评估。
成本
Nova 2 Sonic 通过 Bedrock 按量计费。语音场景的特点是会话时间长（几分钟到几十分钟），token 消耗和文本场景不在一个量级。上线前一定要算清楚单次会话成本。
录音和审计
客服场景通常需要保留通话录音。Vision Agents 支持会话录制，但存储和合规要求需要自己处理。
降级策略
模型服务偶尔会有抖动。需要有降级方案——比如切回传统三件套，或者给用户文字输入的选项。
适用场景
这套方案适合：
- 智能客服：电话/语音客服的 AI 升级
- 语音助手：APP 内嵌的语音交互功能
- 远程协作：语音驱动的工作流自动化
- 无障碍：为视障用户提供语音交互界面
不太适合：
- 纯文本场景（杀鸡用牛刀）
- 对延迟不敏感的离线处理场景
- 需要精确逐字转写的场景（speech-to-speech 不输出中间文本）
我的看法
语音 AI 这个领域折腾了好几年，一直没有特别顺手的方案。三件套方案能用但不好用，延迟和工程复杂度是两个老问题。
Nova 2 Sonic 的 speech-to-speech 思路确实解决了核心痛点。一个模型替代三个服务，延迟和复杂度同时降低。加上 Vision Agents 把基础设施封装好了，从零到可用的时间大幅缩短。
需要关注的是成本。语音场景的会话时长远超文本，Bedrock 的按量计费模型下成本可能不低。建议先用小规模流量测试，摸清单会话成本后再决定大规模上线。
参考
- AWS 官博原文：https://aws.amazon.com/blogs/machine-learning/real-time-voice-agents-with-stream-vision-agents-and-amazon-nova-2-sonic/
- Amazon Nova 模型：https://aws.amazon.com/nova/models/
- Amazon Bedrock：https://aws.amazon.com/bedrock/
- Vision Agents 文档：https://docs.aws.amazon.com/bedrock/latest/userguide/nova-sonic.html