AI 工程实践
OpenAI Realtime API 公测复盘：低延迟语音 Agent 要同时处理打断、工具与成本
复盘 Realtime API 首发时的 WebSocket、流式音频、自动打断与函数调用边界，并把语音 Agent 拆成可测延迟、会话状态、副作用和隐私控制。
时间与证据
事件日是 2024 年 10 月 1 日。OpenAI 当天宣布 Realtime API 进入 public beta，面向付费开发者逐步开放。本文只允许使用到 10 月 3 日已经存在的资料：发布页的发布日快照，以及官方 Realtime Console 在发布日固定的代码树 8f4a39ed5b189de92911ed7207df30eced3d52fd。Wayback 快照保留的是同一 host 与 path 的 http 原始目标；它避免当前 https 回放地址的归档重定向环，不改变捕获时刻或页面身份。
首发证据能够确认：
- API 通过持久 WebSocket 与 GPT-4o 交换事件和音频流。
- 支持直接 speech-to-speech、文本/音频输入输出与 function calling。
- 服务可以处理自动打断；参考控制台同时展示 push-to-talk 与 server VAD 两种模式。
- 参考客户端有 conversation item、增量音频/转写/参数、函数调用输出、truncate 和 cancel 等状态事件。
- 公告给出当日 token 价格，但价格只代表首发计费表，不是一个完整会话的实际账单。
一个重要边界是：T+2 证据写的是 WebSocket，不是 WebRTC。 WebRTC 后来成为浏览器实时连接的重要路径，但不能为了描述今天的最佳实践把后续能力写回 10 月 1 日。本文若提到 WebRTC，只能作为事后演化；首发工程判断按 WebSocket 建模。
证据等级为 sourced。本站没有在首发窗口调用该 API，也没有测量端到端语音延迟、识别准确率或成本。发布页中的低延迟、价格和演示属于官方材料；下文是基于同期协议形态提出的系统设计与验收方案。
当时发生了什么
此前常见语音链路是 ASR -> 文本模型 -> TTS。它的优点是边界清晰，每一段可以替换和审计；缺点是每段都增加等待，文本中间表示还可能丢失语气、重音和节奏。Realtime API 的首发信号是把音频输入、模型推理和音频输出放入一个持续会话，让输入与输出能够边到边流动。
这不是“把 HTTP 改成 WebSocket”那么简单。长连接里同时存在几种状态：
- transport state：连接、重连、心跳和背压。
- input state：麦克风采样、音频缓冲、VAD 起止和提交边界。
- conversation state：user、assistant、function call 与 function output item。
- playback state：已生成、已接收、已排队和用户实际听到的音频并不相同。
- side-effect state：函数参数可能仍在流式生成，工具也可能已经派发或提交。
官方参考控制台最有价值的细节不是界面，而是 cancelResponse(id, sampleCount)：打断时不仅停止播放，还按用户已经听到的 sample offset 截断 conversation item，避免模型在后续回合“记得”用户从未听到的尾部内容。它揭示了语音 Agent 的核心一致性问题：服务端生成历史、客户端播放历史和用户认知历史必须重新对齐。
参考控制台也明确警告其 relay 只是简单消息转发；隐藏密钥、限制事件和保护 instructions 需要业务方自己实现。Demo 把 API key 放入浏览器 localStorage 便于试用，不应被复制为生产凭证方案。
任务判断
假设要构建一个售后语音助手，用户可以查询订单、修改送货时间，但退款和改地址需要明确确认。任务不是“自然地说话”，而是完成一段可验收会话：
用户表达目标
-> 系统确认身份与订单范围
-> 读取信息或提出澄清
-> 涉及写操作时复述关键参数并等待确认
-> 执行工具
-> 读取权威结果
-> 向用户播报结果与下一步
验收对象至少包括：
| 维度 | 可检查的标准 |
|---|---|
| 交互 | 用户开口后能打断；停止播放不会继续污染下一回合 |
| 延迟 | VAD、上行、模型首音频、播放缓冲分别记录 P50/P95 |
| 工具 | 流式参数完成后才校验；写操作有确认、幂等键和权威回读 |
| 身份 | 会话只能访问当前 principal 与 tenant 的订单 |
| 隐私 | 原始音频、转写、工具参数有最小采集和保留期 |
| 成本 | 按完成且正确的会话计费，不只统计每分钟音频价格 |
| 降级 | 弱网、无麦克风、模型超时和工具失败都有文本或人工接管 |
“首音频很快”只能证明一个局部指标。若 VAD 频繁误切、工具在打断后仍修改订单，或用户必须重复三次身份信息，这个产品仍不合格。
工程影响
延迟预算必须按可控阶段分账
语音系统的感知延迟可以拆成：
用户停顿确认
+ VAD / push-to-talk 决策
+ 音频上行与队列
+ 模型首个可播放音频
+ jitter buffer
+ 本地播放调度
只记录 WebSocket request duration 没有诊断价值。客户端要发出带单调时钟的 speech_started、speech_stopped、first audio received、first audio played 和 interruption markers；服务端记录 session、response、conversation item 与 tool call 的关联。跨端时钟不能直接相减时，以客户端单端阶段和服务端单端阶段分别统计，避免伪精确。
P95 还应按网络类型、设备、会话轮次和是否调用工具分层。一次纯问候与一次查询订单的延迟预算不同，混在一起的平均值会隐藏真正慢的工具回合。
打断是一项分布式状态转换
用户在助手播报中途开口时，系统至少要决定四件事：
- 停止扬声器播放并记录已听 sample offset。
- 取消或截断仍在生成的 response。
- 修正 conversation history，使下一轮只基于用户实际听到的部分。
- 判断关联工具是否尚未派发、可取消、已提交或结果未知。
前三项可以在参考客户端看到协议线索，第四项属于业务控制面。对只读查询，旧结果可以丢弃或标记 stale；对写操作，不能因为用户打断就盲目重发。工具调用必须带 idempotency key、expected version 和审计 ID；超时后先向权威系统对账，再决定重试或人工接管。
打断状态机应区分 playing、interrupted、tool_pending、tool_dispatched、outcome_unknown 与 reconciled。若界面只有“正在思考/已完成”，无法表达真实风险。
VAD 是产品政策，不是一个开关
server VAD 能减少用户手动按键，但阈值、静音时长、背景噪声和说话习惯会改变 turn boundary。切得太早，模型在用户句子中间开始回答；切得太晚，低延迟优势被静音等待抵消。电话、车载、开放办公室和语言学习的阈值不应共用。
实验设计需要保存用户同意后的匿名化音频片段或合成回放，标注真正 turn end、插话和非语音噪声。指标包括 false start、missed interruption、平均额外等待、被截断句比例和用户重复率。没有这些标注，调 VAD 只能靠演示印象。
流式函数参数必须在边界处校验
参考事件中函数参数可以增量到达。应用不能在 JSON 尚未完成时执行，也不能把模型给出的坐标、订单号或金额当成可信身份。完整参数到达后仍需执行 schema 校验、主体授权、业务规则和用户确认。
推荐把语音层和执行层分开：Realtime session 产生一个 proposed_action；policy gateway 绑定 principal、tenant、tool、规范化参数摘要和会话轮次；高风险动作返回待确认 challenge；只有用户明确确认且 challenge 未过期时才派发。模型不能自行生成“已确认”字段绕过控制。
长连接需要可恢复而不是假装无故障
WebSocket 断开时要知道哪些事件已被服务端接受。客户端序号、server event ID、conversation item ID 和 tool call ID 应持久化到短期 session ledger。重连后若协议不支持精确续传，就明确创建新 session，并从经过筛选的业务摘要恢复，而不是重放全部原始音频和旧工具调用。
网络背压也必须有上限。上行音频比网络发送快时，缓冲应限制长度并显示降级；下行播放慢时，不能无限堆积已经过时的音频。超过阈值后停止生成、切换文本或请求用户重试，比几秒后继续播放旧回答更一致。
成本单位应是完成会话
首发公告给出音频与文本 token 价格，并换算每分钟音频输入/输出。这个换算有助于预算，但不等于业务成本。一次会话还包含静音、被打断输出、重复问题、工具调用、失败重试、转写存储和人工接管。
更可靠的指标是：
单位合格会话成本
= 模型音频/文本 + 工具 + 网络/存储 + 失败重试 + 人工接管
----------------------------------------------------------
完成目标、无越权、满足延迟且用户无需重复的会话数
需要同时记录 generated_audio_ms 与 played_audio_ms。用户打断后未播放的生成内容仍可能计费；差值是可以通过更快 cancel 和更短缓冲优化的浪费。
商业价值
最可能付费的是本来就有同步语音流程的团队：客服中心、预约、语言练习、车载助手和无障碍交互。Realtime 能增强这些流程，让系统在一个会话中听取、回应并查工具，而不是把用户在多个菜单和等待音之间转移。
收益成立需要四个条件：任务边界清晰、工具接口可授权、语音确实比文本更适合场景、自动处理成本低于现有人工或 IVR。价值不能只用“更自然”描述，应该比较完成率、平均处理时长、转人工率、重复表达次数、错误副作用和单位合格会话成本。
不适合的场景也很明确：需要逐字审阅的合同、高噪声环境中的高风险操作、用户不能确认系统复述内容、或工具系统没有幂等与审计。此时文本表单或人工流程可能更慢，却更可验证。
一个季度内的可证伪预测可以是：在低风险查询队列中，语音助手降低平均处理时间，同时没有提高重复联系、投诉和越权率。若成本下降来自缩短播报，却导致用户理解错误或更多转人工，结论失效。
局限与风险
第一，本站没有复现首发 API。公告的低延迟与价格是官方表述，真实体验受地区、网络、设备、会话长度和服务变化影响。
第二，官方参考控制台是 inspector 和交互式参考，不是安全架构。浏览器保存 API key、简单 relay、示例天气工具和内存工具都不能直接进入生产。密钥必须留在受控服务端，客户端拿短期、最小权限会话凭证。
第三，音频比文本携带更多敏感信息，包括声纹、背景谈话和环境。即使转写已脱敏，原始录音仍可能泄露身份。采集提示、用途限制、保留期、删除、区域和供应商处理条款必须单独设计。
第四，自动打断可能误判。背景声触发 VAD 会截断关键说明；模型音频与用户声音回声还可能互相触发。声学回声消除、设备测试和人工回退属于完整产品成本。
第五，函数调用把低延迟直接连接到副作用。速度越快，错误动作留给用户阻止的时间越少。高风险操作应牺牲一部分自然感，加入明确复述、确认和权威回读。
第六，本文没有把后来 WebRTC、SIP 或模型更新写进同期结论。它们可能改变连接和部署选择，但需要以各自发布日期和版本重新评估。
面试表达
30 秒结论： Realtime API 首发的关键不是语音听起来更像人，而是音频、对话 item、打断和函数调用进入同一个持久事件流。生产语音 Agent 必须让用户实际听到的历史与模型状态一致，并把工具副作用放到独立授权和幂等控制面。低延迟只是一道门，完成率、越权、重复和单位合格会话成本才是交付指标。
3 分钟架构说明： 客户端采集音频和 VAD 事件，经短期会话凭证连接 Realtime gateway；gateway 维护 session ledger、限流和事件序号。模型事件进入 conversation reducer；音频走有上限的播放缓冲；函数调用先生成 proposed action，再经过 schema、主体、租户、审批和幂等检查。打断同时停止播放、truncate conversation，并对已派发工具做对账。trace 分开记录 speech stop、首音频、first played、tool dispatch 与权威结果。
追问：为什么打断要 truncate？ 因为服务端可能已经生成并写入对话历史，但用户只听到前半段。只停止扬声器会让下一轮模型依据用户从未听到的内容继续回答，形成认知状态与系统状态分叉。
追问：WebSocket 断了能否直接重连重放？ 不能默认。先用事件 ID 和业务 ledger 判断服务端接受到哪里；工具结果要向权威系统对账。无法精确续传时创建新 session，从最小可信摘要恢复，禁止重放不确定的写调用。
复盘
T+2 内最强的工程信号是参考控制台暴露了 conversation item 与 sample-level truncate。它说明语音 Agent 的难点不只是声学质量，而是 用户认知、播放进度、模型记忆和工具状态的一致性。
当时容易误判的是把 speech-to-speech 等同于端到端产品。API 缩短了模型路径，却没有替业务完成身份、授权、重试、审计、隐私和人工接管。下一次评估实时接口，应先找是否存在明确事件模型、取消语义、状态恢复、短期凭证和分段观测，再看演示流畅度。
对 Workbench 的具体输入是一个 realtime session ledger 和统一 action gateway：语音、文本或 GUI Agent 都可以提出动作，但最终授权、幂等、权威回读与未知终态处理共用同一套控制面。
方法披露
本文由 AI 辅助整理结构，作者逐项核对 OpenAI 发布日快照和官方参考控制台完整 commit。没有调用 Realtime API，没有采集音频，也没有生成延迟或成本结果。正文中的状态机、指标、故障注入和商业验证均为实验设计；首发价格只按官方当日表述引用，未作为本站账单。
修订记录
2024-10-04：初版发布，记录首发 WebSocket、打断、函数调用和计费边界。2024-10-25：复核参考控制台的 cancel/truncate、relay 安全提示和来源链接，明确不把后来 WebRTC 能力倒灌进同期判断。
Source ledger
来源账本
以下来源用于核对事实、日期与当时可用范围。厂商自报性能不视为本站独立复现。
讨论