你想让语音助手帮你买张机票。 你刚说完出发地和目的地，手机屏幕就开始转圈。 在接下来的十几秒里，你盯着等待动画，不敢出声。 你在等，它也在等。 它在后台检索航班、对比价格，而你只能干等。
现在，你用上新的 ChatGPT 语音模式，感觉完全变了。 你说话的时候，它会回应“嗯”或者“对”。 你随时可以打断它。 当你想听复杂的旅行计划时，它不会停下来等。 它一边继续跟你聊天，一边在后台让大模型去检索网页。 搜到结果后，它把新信息自然地接进对话里。
能同时听和说的交互，在技术上叫做全双工（full-duplex）通信。 这个功能在 2026 年 7 月 8 日上线。它的背后是一个叫 GPT-Live 的新模型。根据 OpenAI 官方介绍页 的介绍，它现在支持了 ChatGPT 语音模式。
你可以通过手机端或者网页端体验它。它支持手机客户端（iOS、Android）与 ChatGPT.com 网页端。 Go、Plus 和 Pro 付费用户可以用 GPT-Live-1。免费用户可以用轻量版的 GPT-Live-1 mini。至于 Business、Enterprise 和 Edu 账户，现在还用不了。
用它聊天时，你会发现它分工明确。 负责跟你说话的语音层只管流畅对话。 网络检索、计算或深度推理等复杂任务，则由后台的 GPT-5.5 承担。
很多开发者想把这个能力接进自己的产品。 但目前 OpenAI 还没开放 API。 官方只承诺会尽快推出。
每次有新产品出来，大家都容易觉得技术有大突破。 有人觉得 GPT-Live 是 Realtime API 的直接升级。 其实两者完全独立。 实际上，该产品使用的多项技术早已在行业内应用。
先说全双工。 这并不是什么新发明。 学术界早就证明了这条路行得通。 开源机构 Kyutai 在 2024 年 9 月发布了 Moshi 模型。 相关成果可以看 Moshi 论文。 该模型证明了双流并行 token 生成方案的可行性。
在产品端，Google 之前便推出了 Gemini Live。 字节跳动也推出了豆包 Seeduplex 语音交互系统。 它们都能同时听和说。 GPT-Live 将该模式推广到了上亿用户的规模，但底层原理并无突破。
再说端到端音频。 这也早就不是新技术了。 GPT-4o 就能直接输入和输出音频。 它不需要经过文本中转。 官方在 System Card 中指出，将 GPT-4o 以前的语音模式归为轮次制。 并指出 GPT-Live 的目标是超越这种轮次制。 这表明 GPT-Live 将交互从半双工升级为了全双工。 该升级并非源于端到端技术的新突破。
最后看工具调用。 Realtime API 早就支持这个功能了。 它 2024 年就推出了，function calling 一直是标配。 开发者可以挂载工具，由语音模型在会话中直接调用。 这是目前构建 voice agent 的主流方案。 最新的 gpt-realtime-2.1 发布于 2026 年 6 月，细节见 Realtime API gpt-realtime-2.1 文档。 但工具调用功能自 2024 年起便已支持。
既然这些特征都不新鲜，那开发者的痛点在哪里？
使用 Realtime API 开发语音 agent 时，难点在于模型的推理能力。 若由语音模型自主决定工具调用与思考，其表现通常不佳。 其智力水平大约仅相当于 GPT-3.5 或 GPT-4，难以应对复杂任务。
为了解决这个问题，开发者通常会采用分层架构。 后台的 GPT-5 处理推理与工具调用。 前台的 Realtime API 则仅作为交互外壳。
这套方案实现了“交互层与工作层分离”的架构。 GPT-Live 的委托机制并非源于 OpenAI 发现了新需求。 官方看到开发者都在手动搭建该架构，索性将其作为平台默认功能。
既然这些特征都不新鲜，那 GPT-Live 到底带来了什么？
答案是委托（delegation）架构。 在实际体验中，这个设计带来了变化。
当用户提出需要联网搜索或复杂推理的问题时，传统的语音模型会立刻保持沉默。 它必须等待后台检索和推理完毕，才能重新开口。 这会导致较长时间的等待。
在 GPT-Live 里，语音层与工作层实现了彻底分离。 提问后，语音层将任务派发给后台，自身继续与用户交流。 语音层并非在做无意义的安抚，而是一个独立的交互层。 后台完成计算后，语音层会将结果融入对话并自然说出。
关键在于后台可以同时运行多个任务。 官方明确表示，GPT-Live 能够同时管理多个后台任务。 用户可以一边让其查询航班，一边计算汇率，同时继续聊行程。 语音层只管跟你交互，重活全派出去。 后台并行处理复杂任务，结果分批返回。 关于该机制的更多细节，可参考 marktechpost 报道。
这就是委托（delegation）。说话的归说话，干活的归干活，两边彻底分开。
这解决了传统语音交互中，响应速度与思考深度难以兼顾的矛盾。
该现象此前被称为延迟悖论（latency paradox）。
模型推理越深，开口响应就越慢。 开发者以往只能调整
reasoning_effort 参数。
用户也常在“快速但简单”与“缓慢但聪明”之间面临两难选择。
现在，GPT-Live 改变了规则。 它不要求用户在两者间做选择，而是通过分工解决问题。 一个角色专门负责交互，另一个角色专门负责计算。
架构对比图展示了语音系统从传统的三段式，演进到委托架构的过程：
需要指出的是，GPT-Live 本体的智力表现有限。 官方在 System Card 中指出，GPT-Live-1 和 mini 在多项评估中均不如 GPT-5.5 Thinking。
它主要充当交互外壳，深度推理能力仍由后台的大模型提供。 该模型改变的是编程模式，并未提高语音模型本身的智力上限。 它将开发者此前手动搭建的分层逻辑，直接转化为了平台底座。
这也为开发者带来了核心差异。
使用 Realtime API 时，工具调用完全由开发者控制。 开发者能决定提供哪些工具，以及具体的等待时间。
但在 GPT-Live 中，工具调用被封装进了官方的委托系统。 工具在 ChatGPT 的黑盒内部运行。 开发者无法接入，也无法观察数据的流动情况。 这构成了手搓 voice agent 与官方语音产品的界限。
OpenAI 未公布底层细节。 不过对照学术界方案，其实现原理可以大致推测。
首先，该模型能同时听和说，源于双流并行 token 生成方案。 模型在每个时间步，同时预测自身的输出与用户的输入。
这使插话、换人或语气词等交互，无需依赖固定的状态机进行调度。 这些交互是在生成 token 的过程中自然产生的。
开源的 Moshi 模型提供了参考。 其使用的 Mimi codec 运行在 12.5Hz 的帧率上。 这意味着它每 80ms 生成一帧音频，延迟约在 200ms 左右。 GPT-Live 的实现思路与此类似。
在这种设计下，语音模型持续进行高频的连续决策。 在生成每帧音频时，它都在实时判断当前状态。 包括是保持沉默、发出语气词，还是触发一次委托。
一旦触发委托，前后台任务将异步执行。
后台运行的模型为 GPT-5.5。 官方提供了 Instant、Medium 和 High 三个推理档位。 其中 Medium 与 High 档位会调用 GPT-5.5 Thinking。
后台进行检索或计算时，前台语音模型继续与用户交流。 后台完成计算并传回结果后，数据会融入前台模型的生成概率中。 最终由语音模型自然说出。
在技术细节上，语音模型本体并不具备工具调用和代码执行能力。 官方在 System Card 中写明，语音模型本体没有独立的工具访问权，也没有代码执行能力。
这也表明语音模型本体的结构较为简单。 它不直接调度工具或运行代码，所有复杂计算均由后台模型完成。
关于工具开放计划，System Card 提到，开放新工具前会重新评估网络安全防护。
这意味着即使未来 API 开放，其工具能力也会分阶段释放。
编程模式变化图展示了开发者手搓架构与官方原生委托架构的对比：
面对这些变化，语音应用开发者可以从三个方向进行规划。
第一，短期内可继续使用现有的 Realtime API。
Realtime API 仍是目前构建语音 agent 的主力工具。 其最新版本 gpt-realtime-2.1 细节见 Realtime API gpt-realtime-2.1 文档。 这些轮次制模型性能稳定，且支持完全控制 function calling。
以下是 gpt-realtime-2.1 模型每百万 token 的价格详情： 文本输入 $4.00，文本输出 $24.00。 音频输入 $32.00，音频输出 $64.00。
轻量版 gpt-realtime-2.1-mini 模型每百万 token 价格为： 文本输入 $0.60，文本输出 $2.40。 音频输入 $10.00，音频输出 $20.00。
这些 API 模型与 GPT-Live 属于平行产品，并无替代关系。 开发者可在生产环境中继续使用。
第二，关注 GPT-Live API 的登记渠道。
开发者可通过 API 登记表单 申请测试资格。 GPT-Live API 开放后，全双工与委托机制将成为核心能力。 届时，有两个关键点尚待明确：
第一，官方是否允许在委托层挂载自定义的外部工具。 第二，开发者对该委托黑盒拥有多少控制权。 这些因素将决定应用是仅能作为交互皮肤，还是能深入业务核心。
第三，重新评估语音产品的架构定位。
拼接 GPT-5 与 Realtime API 的方案，将被平台原生委托替代。
开发者需提前明确自身的核心价值。 哪些繁重的编排工作可交由平台处理，以降低延迟和成本？ 哪些核心能力是平台无法取代的？ 例如私有的工具链，或特定领域的知识编排。 这些核心优势需要被牢牢掌握。
此外，全双工与委托机制的结合，也带来了全新的应用场景。
例如，伴随式语音等新形态将成为可能。 在后台运行数分钟的长任务时，前台语音模型能持续播报进度。 播报期间，用户可随时打断并调整检索思路。 这种双向流动的体验，打破了传统“问、等、答”的单向轮次模式。
GPT-Live 并没有带来模型智力上的突破，而是理顺了语音计算的结构。
最核心的变化，在于它将负责说话的交互层与负责干活的推理层拆开。 此前，行业倾向于用单一模型解决两类任务，导致陷入延迟悖论。
支持同时听说的全双工在交互体验上确有提升。 但从技术原理看，其底层并无本质突破。
GPT-Live 真正的贡献在于其委托架构。 它将开发者手搓的分层设计，直接转化为了平台的原生默认能力。
对于语音应用开发者而言，这验证了分层设计路线的正确性。 此前的工程直觉与架构选择，得到了平台层面的印证。
当前阶段，继续使用 Realtime API 推进业务仍是稳妥的选择。 其性价比更高，且支持完全自主掌控。 同时，开发者应密切关注 GPT-Live 开发者生态的后续动向。 提前做好准备，迎接原生全双工委托时代的到来。