OpenAI Realtime API 做语音客服：难点在打断、确认与回放

OpenAI Realtime API 做语音客服：难点在打断、确认与回放

OpenAI Academy 在 9 月 2 日的 Builder Bootcamp 中把 Realtime API 放进了客服场景：开发者需要在语音到语音与“转写—文本模型—语音合成”的链式架构之间选择，并处理打断、轮次判断、工具调用、身份核验、动作确认、追踪和评测。这个议程比一次低延迟演示更有参考价值，因为语音 Agent 的失败往往发生在用户插话、环境噪声和外部系统响应之间。

官方 OpenAI 文档显示，Realtime API 可通过 WebRTC、WebSocket 或 SIP 建立低延迟会话，支持原生语音输入输出。会话可以使用 Server VAD 或 Semantic VAD 判断用户是否说完，新的语音开始时也可自动打断正在输出的回答。输入转写是独立的异步过程，只能作为参考；模型直接消费音频，因此转写文本可能与模型实际听到的内容存在偏差。客服系统若只保存转写，就可能漏掉定位故障所需的信息。

架构选择取决于业务动作

原生语音到语音路径轮次更自然，适合咨询、预约和简单分流。链式架构多了一次转写与合成，却便于在文本层插入关键词规则、知识检索和人工审核。两者没有统一优胜者。若场景需要准确记录保单号、药品名或序列号，可以把关键字段交给专用转写或二次确认；若用户重视交流流畅度，原生路径更容易减少机械停顿。

工具调用必须和口头回答分开。Agent 可以查询订单，但退款、改地址、取消服务等动作应先复述对象、金额或时间，并等待用户明确确认。工具返回失败时，语音层不能用自然措辞掩盖状态码；它需要说明未完成、保留幂等键并提供重试或转人工入口。对于多个并行工具，还要防止较晚返回的旧结果覆盖用户刚刚修改的意图。

打断测试也不能只看“能否停止播放”。系统要记录用户开始说话的时间、客户端实际停止音频的时间、被取消回答是否仍写入历史，以及下一轮是否错误携带未播完内容。Server VAD 依赖音量和静音长度，Semantic VAD 会结合语义估计轮次结束，后者可能更自然，也可能增加等待。真实测试应覆盖车内噪声、免提回声、口音、犹豫词和连续报数字。

语音 Agent 要能复盘一通失败电话

一次会话的日志至少应串联连接 ID、用户身份、模型与配置、VAD 事件、转写、工具参数、确认状态、播放时间和最终业务结果。OpenAI 文档支持为 Realtime 会话写入 trace，应用团队仍需把模型 trace 与订单、工单等业务日志关联。录音或文本是否保存、保存多久、谁能访问，则要根据用户告知、业务必要性与当地法规单独确定。

评测可以从二十到五十段高频对话起步，记录任务完成率、字段识别准确率、误打断率、P95 首音延迟、重复动作数和人工接管率。每次更换模型、VAD 参数或提示规则都回放同一批样本。涉及退款、医疗、安全等高风险动作时，另设独立模型或人工复核，防止对话听起来自然却执行了错误操作。

如果语音流程还会调用其他文本模型做检索、摘要或质检，可用统一模型网关保存各阶段用量与错误，避免把一通电话的成本拆散在多个供应商后台。接入前可查看 [AnyAIS API 文档](/docs)，先用脱敏录音完成端到端回放，再接入真实业务系统。

来源：[OpenAI Academy：Builder Bootcamp Realtime](https://academy.openai.com/public/clubs/builders-etkn1/events/builder-bootcamp-realtime-yckmdr6h4y)；[OpenAI 官方文档：GPT-Realtime-2](https://developers.openai.com/api/docs/models/gpt-realtime-2)