GPT-Live-1：全双工语音 API 带来的工程变化

为什么全双工重要#

传统语音应用常见的链路是 语音识别 → 文本模型 → 语音合成。这条链路容易出现三个问题：模块之间要反复传递状态，用户打断时需要取消多个请求，系统还要自己判断什么时候算一句话结束。

全双工模型把输入和输出音频放在同一个交互循环中，打断处理变成模型能力的一部分。OpenAI 在发布说明中提到，早期评估里 Speak 的语言学习场景将打断次数降低了接近 80%；这类结果仍然需要结合自己的场景和指标复测。

接入时要注意什么#

• 把工具调用放到后端：语音模型负责对话节奏，订单、检索和写入等动作仍由服务端鉴权。
• 设置明确的打断策略：用户重新说话时，前端要立即停止播放，并保留未完成请求的取消信号。
• 记录音频延迟：拆分首包延迟、端到端响应延迟和用户打断恢复时间，不能只看模型生成速度。
• 给长会话做摘要：实时音频上下文会快速增长，应该按主题或任务生成短摘要，避免无限累积。

对于客服、语言练习和语音导航，降低等待感比增加一堆按钮更重要。全双工的价值最终要用“用户是否愿意继续说下去”来验证。

原始来源：Build more natural voice experiences with GPT-Live-1 in the API。