Wiki Notes

Appearance

Realtime与语音工作流专题 ​

版本：v1.2

最后更新：2026-07-08

适用对象：正在做实时语音助手、电话机器人、语音陪练、会议 Copilot、边说边译、实时字幕和需要把语音会话接入工具、知识库、审批流的产品、平台与研发同学

很多团队第一次做语音 AI，会把它理解成：

  • 文本模型
  • 外加麦克风输入
  • 再外加一个播音喇叭

这种理解在 Demo 阶段可能够用，但一进入真实项目就会迅速失效。

因为 Realtime 语音真正难的不是：

  • 模型能不能答
  • TTS 声音自然不自然

而是：

  • 会话是持续的，不是一次请求一次响应
  • 用户会停顿、改口、打断
  • 工具调用会插进会话中间
  • 高风险动作不能只凭一段语音就直接执行
  • 延迟预算、状态同步、审批、回放、审计都得补齐

OpenAI 当前 Realtime and audio、Voice agents、Realtime conversations、Realtime transcription、Using realtime models 等官方资料在 2026-07-08 复核时都指向同一个工程结论：

  • Realtime 语音系统首先是会话系统，其次才是语音模型系统。

所以这篇专题真正要讨论的是：

  • 连接方式怎么选
  • 会话状态怎么管
  • turn detection 和 interruption 怎么做
  • 什么时候能自动调用工具、什么时候必须确认
  • 如何把语音链路做成可监控、可回放、可治理的工作流

1. 先分清 request-based 音频和 realtime 会话 ​

很多后续架构问题，其实在第一步就决定了。

OpenAI 当前 Speech to text 和 Realtime transcription 指南区分得很清楚：

  • 有边界的音频任务走 request-based
  • 连续、低延迟、带状态的语音会话走 realtime

1.1 更适合 request-based 的场景 ​

  • 文件转写
  • 批量字幕
  • 会议录音离线整理
  • 固定文本转语音播报
  • 离线语音分析

这些任务的共同点是：

  • 输入边界清楚
  • 容忍更高时延
  • 更适合重试和批量处理

1.2 更适合 realtime 的场景 ​

  • 语音助手
  • 电话机器人
  • 边说边译
  • 实时字幕
  • 会议 Copilot
  • 需要边听边理解边回复的语音 Agent

这些任务的共同点是：

  • 输入连续流动
  • 会话有状态
  • 用户随时会打断
  • 响应延迟直接影响主观自然度

一句话判断：

  • 有完整文件，优先 request-based；有人正在和系统持续说话，优先 realtime。

2. Realtime 语音工作流真正比拼的是会话控制 ​

一个典型的实时语音工作流可以粗略写成：

text
microphone
 -> session setup
 -> audio streaming
 -> turn detection
 -> transcription / speech reasoning
 -> retrieval / tools / approvals
 -> speech generation
 -> playback
 -> state update

看上去像一条链，但实际至少包含五个控制面：

  • 连接控制
  • 会话状态控制
  • 轮次控制
  • 工具与动作控制
  • 播放与中断控制

很多系统“不自然”，不是因为模型太差，而是因为这五个控制面有一个没设计好。

3. 浏览器语音、服务端媒体网关、电话系统不是同一种接法 ​

OpenAI 当前 Realtime API with WebRTC 和 Realtime API with WebSocket 指南给了很明确的推荐：

  • 浏览器和移动端客户端优先 WebRTC
  • server-to-server 场景优先 WebSocket

这背后不是“哪个更高级”，而是媒体链路形态不同。

3.1 更适合 WebRTC 的场景 ​

  • 浏览器语音助手
  • 移动端语音会话
  • 直接采集麦克风并播放语音回复
  • 强依赖低延迟双向媒体能力

更适合它的原因通常是：

  • 端侧媒体能力成熟
  • 采集、回放、双向音频更自然
  • 更贴近用户设备

3.2 更适合 WebSocket 的场景 ​

  • 服务端媒体管线
  • 音频流先进入后端再转发
  • 呼叫中心中间层
  • 录音、转写、路由和审计先经过服务网关

一句话理解：

  • 人机直连优先 WebRTC，系统和系统直连优先 WebSocket。

4. 浏览器端必须使用短期凭证，而不是正式 API Key ​

OpenAI 当前 realtime 文档和 WebRTC 指南都明确建议：

  • 浏览器和移动端通过 /v1/realtime/client_secrets 获取 ephemeral credentials

典型流程通常是：

  1. 浏览器请求你的后端。
  2. 后端用正式 API key 申请短期会话凭证。
  3. 浏览器拿到短期凭证后，再去连 realtime 会话。

这一步最关键的不是“多了一次请求”，而是：

  • 不能把正式 API key 下发到客户端

如果浏览器或移动端直接持有正式 key，问题通常不会是“是否有风险”，而是：

  • 什么时候出事故

5. Realtime 会话不是“聊天记录”，而是一套状态机 ​

OpenAI 当前 Realtime conversations、Conversation state、Voice agents 指南都强调：

  • 实时会话是有生命周期和事件模型的

这意味着你不能只记：

  • 用户说了什么
  • 模型答了什么

你还必须记录：

  • 当前 turn 是否结束
  • 当前是否正在播放
  • 是否存在未完成工具调用
  • 是否有待确认动作
  • 当前 voice / language / persona / route
  • 是否发生打断、暂停、恢复

如果这些都混成“历史消息”，系统很快就会不可维护。

6. 实时语音的状态至少要拆成四层 ​

一个更可落地的拆法通常是：

6.1 会话级状态 ​

  • user / tenant
  • session id
  • language
  • 角色设定
  • 长期上下文摘要
  • 当前可用工具集

6.2 turn 级状态 ​

  • 当前用户 utterance
  • partial transcript
  • 是否判定结束
  • 当前推理目标

6.3 动作级状态 ​

  • 当前是否调用工具
  • 工具结果是否返回
  • 是否需要审批
  • 是否已进入人工接管

6.4 播放级状态 ​

  • 当前回复是否在播
  • 已播到哪里
  • 是否被用户打断
  • 是否需要停止或续播

这四层一旦拆开，你才能回答很多真实问题：

  • 为什么工具已经执行完了，但前端还在播旧答案
  • 为什么用户打断后系统还在后台继续发请求
  • 为什么同一个会话在不同节点看到的状态不一致

7. turn detection 决定的是体验下限 ​

Realtime 语音里的一个根本问题是：

  • 系统怎么知道用户什么时候说完

OpenAI 当前 Realtime transcription 和 Realtime conversations 文档都提到：

  • audio.input.turn_detection
  • VAD
  • transcript events

这说明 turn detection 不是“外围小功能”，而是主流程的一部分。

7.1 turn detection 出错会怎样 ​

  • 用户还没说完，系统就开始抢答
  • 用户停顿一下，系统误判结束
  • 工具调用过早触发
  • 翻译和字幕分段怪异

7.2 哪些场景应该把判定做得更保守 ​

  • 金额、联系人、删除、发送等高风险动作
  • 需要结构化参数提取的语音工具调用
  • 多步骤业务操作

因为此时宁愿慢一点，也不要误执行。

8. partial transcript 不是最终事实 ​

Realtime 语音场景里，很多输入都是增量出现的。

这意味着：

  • partial transcript 适合驱动界面反馈
  • 但不一定适合直接驱动高风险动作

更稳妥的经验通常是：

  • UI 可以用 partial text 显示“系统正在听到什么”
  • 真正发起工具调用、审批或外发动作时，尽量基于更稳定的 turn 结果

否则你很容易得到一种诡异行为：

  • 模型根据前半句就先开始行动
  • 用户后半句刚好把意图改掉

9. interruption 不只是“停播”，而是一次状态迁移 ​

用户打断系统时，平台至少要同时处理三件事：

  1. 音频播放是否立即停止
  2. 当前推理或工具执行是否继续
  3. 会话状态如何进入下一轮

9.1 更适合立刻停播的场景 ​

  • 普通聊天
  • 陪练
  • 低风险问答

9.2 更适合后台继续执行的场景 ​

  • 已经发起检索
  • 已经在查业务状态
  • 正在生成复杂汇总

9.3 更适合必须显式确认的场景 ​

  • 支付
  • 删除
  • 修改权限
  • 对外发送邮件或消息

如果 interruption 只做了播放器 stop，没有处理推理和工具状态，系统就会出现：

  • 嘴上停了
  • 后台却还在继续做事

这既是体验问题，也是安全问题。

10. 语音工作流里的工具调用必须像状态机一样设计 ​

文本场景里，函数调用已经需要谨慎；到了语音场景，只会更难控。

因为这里多了：

  • 识别误差
  • 半句输入
  • 改口
  • 背景噪声
  • 更高的主观容错压力

一个更稳的工具调用状态机通常像这样：

text
hear intent
 -> decide if stable enough
 -> classify risk level
 -> confirm if needed
 -> call tool
 -> validate result
 -> speak success / failure / escalation

最关键的不是流程图，而是“稳定性判断”和“风险分层”。

11. 什么时候不适合直接自动执行语音动作 ​

以下信号通常都不适合直接自动执行：

  • partial transcript 还在快速变化
  • 识别到金额、联系人、日期、地址等关键字段，但置信度不稳
  • 用户说法模糊，存在多种解释
  • 当前环境噪声大
  • 会话已发生多次 interruption
  • 工具是写操作且不可逆

更实用的做法通常是：

  1. 先复述关键信息。
  2. 请求二次确认。
  3. 必要时进入审批或人工接管。

语音工作流越真实，越不能依赖“默认都自动执行”。

12. 高风险语音动作最好用三层门控 ​

对企业语音 Agent 来说，一个常见且很稳的拆法是：

12.1 低风险自动执行 ​

适合：

  • 只读查询
  • 检索 FAQ
  • 查询状态

12.2 中风险二次确认 ​

适合：

  • 创建草稿
  • 发起预约调整
  • 提交工单
  • 发送非最终内容

12.3 高风险审批或人工接管 ​

适合：

  • 转账
  • 删除
  • 导出敏感数据
  • 对外正式发送
  • 权限变更

这类分层和实时语音特别匹配，因为：

  • 语音输入的歧义性天然更高

13. 会话上下文不能无限增长，要主动压缩和分层 ​

OpenAI 当前 Conversation state 和 realtime 相关资料都在提醒一个现实：

  • 连续会话一定会遇到上下文管理问题

放到语音场景里，问题更严重，因为：

  • 语音轮次更密
  • 噪声和寒暄更多
  • 中断和复述会制造大量低价值历史

更实用的做法通常是：

  1. 保留最近几轮原始交互。
  2. 把较远历史压成任务摘要。
  3. 把业务关键状态单独持久化，不要只放在自然语言历史里。
  4. 把工具结果、审批结果、最终动作作为结构化状态，而不是仅当作对话文本。

否则长会话最终会变成：

  • 历史越来越长
  • 意图越来越脏
  • 延迟和成本越来越失控

14. 语音链路的延迟要按预算拆，不要只看总时长 ​

Realtime 体验里，最常见的错误是：

  • 只看“整轮响应耗时”

真正有用的，是按阶段拆预算。

例如：

  • 采集缓冲
  • VAD / turn detection
  • 转写或语音理解
  • 检索
  • 工具调用
  • 语音生成
  • 播放启动

14.1 为什么首字延迟尤其重要 ​

用户更敏感的是：

  • 系统多久开始回应

而不是：

  • 整段话总共花了几秒

14.2 为什么要把工具耗时单独切出来 ​

很多语音体验差，不是模型慢，而是：

  • 中途查库太慢
  • 审批等待太久
  • 服务网关抖动

不拆阶段预算，你很容易把所有锅都甩给“模型不够快”。

15. 语音工作流最好把事件流当成一等公民 ​

一个成熟的 realtime 语音系统，真正需要的不是“最后一段答案”，而是一串事件。

至少应该能表达：

  • session started
  • user speech started
  • partial transcript updated
  • turn ended
  • model responding
  • tool requested
  • tool completed
  • approval required
  • playback started
  • playback interrupted
  • session ended

这类事件流既服务前端，也服务回放、审计和运维。

如果只保留最终文本，很多故障根本复盘不出来。

16. 语音场景的可观测性至少要覆盖哪些指标 ​

16.1 交互体验指标 ​

  • 首字延迟
  • 首包延迟
  • turn 切换自然度
  • interruption 响应时间
  • 播放启动时延

16.2 语义与任务指标 ​

  • 转写准确率
  • 意图识别正确率
  • 工具调用正确率
  • 任务完成率

16.3 系统稳定性指标 ​

  • 会话中断率
  • 重连成功率
  • 工具超时率
  • 审批超时率
  • P95 / P99 时延

16.4 风险治理指标 ​

  • 误触发工具率
  • 未确认高风险动作率
  • 人工接管率
  • 拒答或追问比例

这四类指标一起看，才更接近真实生产状态。

17. Realtime 语音和 request-based 音频最好分别建评测集 ​

不要把：

  • 文件转写
  • 实时对话
  • 语音播报

全混成一个“语音能力测试集”。

更合理的拆法通常是：

17.1 request-based 转写集 ​

关注：

  • WER / CER
  • 术语识别
  • 数字与专有词

17.2 realtime turn 集 ​

关注：

  • VAD / turn detection
  • interruption
  • partial transcript 稳定性

17.3 语音工具流集 ​

关注：

  • 参数提取
  • 风险确认
  • 写操作门控

17.4 语音体验集 ​

关注：

  • 首字延迟
  • 自然度
  • 说话节奏
  • 用户主观可懂度

如果这些评测全混在一起，你很难知道问题到底在哪一层。

18. 企业里更常见的三类 realtime 工作流 ​

18.1 纯语音对话流 ​

链路：

  • 语音输入
  • 实时理解
  • 语音播报

适合：

  • 陪练
  • 讲解
  • 普通语音助手

18.2 语音 + 检索 / 工具流 ​

链路：

  • 语音输入
  • 意图判断
  • 检索或工具调用
  • 语音回复

适合：

  • 客服
  • 企业助手
  • 设备控制

18.3 语音 + 审批 / 人工接管流 ​

链路：

  • 语音输入
  • 风险识别
  • 二次确认或审批
  • 执行 / 转人工

适合：

  • 企业外呼
  • 电话运营
  • 高风险自动化场景

这三类流的关键差异不只在模型，而在：

  • 风险策略
  • 状态管理
  • 是否允许自动执行

19. 常见反模式 ​

  • 把 realtime 当普通文本接口外面包一层麦克风
  • 浏览器直接持有正式 API key
  • 只做播放，不做状态机
  • turn detection 没策略
  • interruption 只停播，不停动作
  • partial transcript 直接驱动高风险工具调用
  • 不区分只读查询和有副作用动作
  • 不保留事件流与 trace，故障时无法回放

20. 推荐搭配阅读 ​

21. 重点官方资源 ​

以下入口在 2026-07-08 复核时可访问：

22. 落地检查清单 ​

  • 是否先区分了 request-based 音频和 realtime 会话，而不是一套链路全做
  • 浏览器 / 移动端是否使用了短期凭证，而不是暴露正式 key
  • 是否把会话、turn、动作、播放四层状态分开管理
  • 是否对 turn detection 和 interruption 设计了明确策略
  • 是否避免用 partial transcript 直接驱动高风险动作
  • 是否对工具调用按只读、确认、审批做风险分层
  • 是否拆分了各阶段延迟预算，而不是只看总响应时长
  • 是否保留了足够的事件流、trace 和回放证据
  • 是否把 realtime turn、语音工具流和 request-based 转写分成不同评测集