OpenAI 开发了 GPT-Live，这是一款以语音为核心的聊天机器人，能够同时进行倾听和表达，摒弃了大多数助手所使用的那种笨拙的“先说后听”式的停顿。该服务旨在实现像人类对话一样流畅的交流，而非断断续续的问答。
为什么旧模式让人感觉体验不佳
典型的语音助手工作方式就像对讲机：你讲完一句话，设备进行录音，将音频发送到云端，等待响应，然后播放出来。这种往返过程会产生明显的延迟，并迫使用户在可以进行中断之前必须先停顿。对于在即时通讯环境下成长起来的一代人来说，这种延迟显得非常过时。
OpenAI 通过一种无需轮替 (turn-less) 的架构给出了答案。每一秒钟，GPT-Live 都会决定是继续倾听、继续说话还是暂停，这让你可以在助手回答中途打断它，或者在无需等待完整响应周期的情况下提出后续问题。
通俗易懂地解释全双工技术栈
- 分离音频循环与推理路径 – 快速路径 (fast path) 处理持续的音频交换，而 慢速路径 (slow path) 则运行更繁重的任务，如网页搜索或工具调用。当慢速路径在工作时，快速路径能保持对话的活跃，从而消除了令人厌烦的“思考时的沉默”时刻。
- WARP 协议 – 传统的网络连接在音频传输之前需要进行多次握手，通常需要六次往返。OpenAI 的自定义协议将这些步骤压缩为单次往返，使会话启动几乎感觉是瞬时完成的。
- 弃用 Python 改用 Go 以保证延迟的一致性 – 团队将实时组件从以开发速度见长的 Python 迁移到了 Go，因为 Go 能提供更可预测的执行时间。在语音 AI 中，最坏情况下的延迟比平均速度更重要；一次卡顿就会破坏沉浸感，因此一致的延迟才是胜出的关键。
- 超越 GPU 的扩展性 – 随着数亿用户的涌入，瓶颈已从模型的计算核心转移到了周边基础设施。OpenAI 发现 CPU 和网络链路比 GPU 更早达到饱和，因此他们增加了更智能的路由和连接管理，以确保在不使整个技术栈过载的情况下，为 GPU 提供充足的数据。
这对开发者意味着什么
- 将音频处理与业务逻辑解耦 – 保持一个轻量级、始终开启的循环来处理麦克风输入和扬声器输出。将任何可以等待的任务（如数据库查询、外部 API 调用）卸载到独立的线程或服务中。
- 优先考虑延迟的稳定性 – 测量响应时间时，应关注最坏情况下的延迟，而非仅仅关注平均值。能够对调度提供更严密控制的语言和运行时（例如 Go、Rust）值得投入额外的工程努力。
- 减少连接开销 – 每一次额外的握手都会增加毫秒级的延迟，积少成多。将身份验证、流协商和编解码器选择整合到单次交换中，用户就能感受到差异。
权衡与悬而未决的问题
全双工设计增加了复杂性。