GPT-Live 背后的真实难点：语音 Agent 为什么要重新设计整条实时链路？

OpenAI 8 月 3 日发布的 GPT-Live 工程文章，是这轮最值得写的技术更新。它表面上讲语音，实际讲的是 Agent 进入实时系统之后，整条链路都要重新设计。

过去很多语音助手是三段式：先 ASR 转文字，再把文字交给 LLM，再 TTS 合成语音。这套方案能做 demo，但天然有一个问题：每一步都在等上一环完成。用户说完，系统才开始想；系统想完，才开始说。对文本聊天来说几秒延迟还能接受，对电话和实时对话来说，半秒到一秒的差异就会被人感受到。

GPT-Live 的核心变化，是把语音模型放到连续音频流里。OpenAI 说它是 full-duplex voice model，可以同时听和说，不再依赖单独的 turn detector 判断“用户是不是说完了”。这不是一个小优化。它意味着模型不再把对话看成一块块离散音频，而是看成持续发生的交互。

真正有意思的是，OpenAI 把“说话”和“深度思考”拆开了。语音通路保持低延迟，工具调用和更复杂推理走异步 delegation。也就是说，GPT-Live 可以先保持自然对话，把场面接住，同时让 GPT-5.5 这类 frontier model 在后台搜索、推理或调用工具。结果回来后，再被语音模型自然纳入对话。

这对语音 Agent 很关键。一个电话客服不可能每次查订单都沉默好几秒，也不能为了不卡顿就完全不查。最好的体验是它可以边回应、边查、边确认，就像一个熟练的人类坐席。

文章里的系统细节也很硬。OpenAI 把媒体流和应用逻辑分离：音频走 dedicated fast path，工具、策略、业务后端走异步 RPC。这样慢工具不会拖垮语音流。媒体前端和推理逻辑从 Python asyncio 换成 Go，新系统的 p95 帧交付平滑度能接近旧系统的 p50。

长会话也是难点。语音会话可能持续很久，context 会增长，模型实例会扩缩容，KV cache 会失效。OpenAI 的处理方式是把实例切换和 context compaction 都做成 managed transition：先并行预热新实例、prefill 当前上下文，然后再切过去。用户听不到中间的系统搬家。

另一个值得注意的点是 WARP。OpenAI 针对 WebRTC 启动慢的问题提出 WebRTC Abridged Roundtrip Protocol，把媒体和数据启动从多轮网络往返压到接近一轮。这里的信号很明确：实时 AI 不只拼模型，也拼网络协议、地区路由、容量管理和可观测性。

这篇文章给开发者的启发是，语音 Agent 不能只问“用哪个模型”。更应该问：

• 语音路径和工具路径是否隔离？
• 模型能不能同时听和说？
• 工具调用是否会阻塞用户听感？
• 长会话如何压缩上下文？
• 断线、重连、实例迁移、区域延迟有没有被纳入设计？

我的判断是，2026 年的语音 Agent 会从“声音拟人”转向“实时工作流”。谁能在低延迟下维持状态、调用工具、处理打断、跨会话恢复，谁才更接近生产可用。

参考来源：OpenAI：How we built a realtime system for responsive voice AI in six months。