GPT-Live 技术原理：实时语音如何驱动后台任务

对着电脑说“把这个页面的按钮放大一点”，AI 开始修改代码；接着问“改到哪了”，它能汇报进度；再补充“只改首页”，任务继续调整。这种体验需要同时处理两件事：及时接住人的话，以及持续执行需要时间的工作。

GPT-Live 的关键设计，可以从实时交谈与后台任务的分工来理解。 官方文档明确：GPT-Live 负责实时对话，在已有 Codex 任务中，实际工作由该任务选定的模型执行。模型分工说明

本文依据截至 2026 年 9 月 9 日查阅的 OpenAI 官方资料。公开文档尚不足以确认 GPT-Live 的网络结构、训练方法，或它与 Realtime API 模型的具体关系。下面先说明已公开的产品分工，再用公开 API 解释实现类似体验的工程机制。

实时交谈与后台执行的分工

GPT-Live 支持的 ChatGPT Voice，可以发起较长的任务、查询进度、追加指令，并将结果带回语音对话。用户能够在工作继续时交谈。ChatGPT Voice 功能说明

这张图是根据公开行为整理的职责示意，不代表 OpenAI 披露的内部服务结构或通信协议。

两类工作对时间的要求不同。语音交互需要及时回应；修改代码、运行测试则可能持续数分钟。将它们分开，可以让“任务还没完成”和“对话仍可继续”同时成立。这是由产品分工得出的工程解释。

也需要区分三个名称：

名称	本文涉及的职责
GPT-Live	桌面版 ChatGPT Voice 中的实时对话
Realtime API	面向开发者的实时音频交互接口
GPT-Live-Transcribe	从实时音频中持续输出文字的转写模型

最后一项的公开能力是语音转文字，不提供音频输出，不能仅凭名称将其视为完整的 GPT-Live 对话模型。转写模型说明

声音如何实时往返

要理解语音系统，可以先比较两种公开实现路线。

串联路线是“语音识别 → 文字模型 → 语音合成”：先把声音转为文字，再生成回答，最后读出来。它便于接入已有文字助手，也便于检查中间结果。

原生语音路线让模型直接处理音频输入并生成音频输出。OpenAI 的语音开发文档将其用于自然、低延迟的交谈。这里的“直接”描述输入输出路径，并不意味着音频不需要编码，或模型内部完全没有文字表示。语音系统架构说明

实时传输通常采用流式处理：麦克风持续上传小段音频，回答也分段返回，播放器收到可播放的数据后即可开始播放。在 Realtime API 中，WebRTC 负责传输音频，数据通道可交换控制事件；OpenAI 推荐浏览器和移动客户端优先采用 WebRTC。WebRTC 接入说明

从工程上看，用户说完话后，到听见回复之间的等待，可以粗略拆成：

等待时间 ≈ 判断用户说完的耗时
         + 网络与服务处理耗时
         + 生成首段音频的耗时
         + 播放缓冲耗时

这是一种分析延迟的方式，不是 GPT-Live 的实测数据。模型生成速度只影响其中一部分；即使生成很快，接话判断过于保守，也会让人觉得反应慢。

接话与打断的处理

判断用户是否说完

“帮我把按钮改成……嗯……蓝色。”中间的停顿，不一定表示用户已经说完。

Realtime API 提供两类判断方式：server_vad 根据声音活动和静默时长划分语音；semantic_vad 结合用户表达的内容，估计一句话是否结束。VAD 指语音活动检测，例如判断此时有没有人在讲话。

静默阈值越短，系统越容易快速接话，也越容易截断思考中的停顿；语义判断可以在“嗯……”这类表达后多等一会儿。接话判断说明

打断后同步已经听到的内容

用户插话时，系统需要协调三件事：停止当前回答的生成、停止播放剩余音频、修正对话中已播出的范围。

假设模型已经生成十秒音频，用户只听了前三秒就插话。如果历史仍把十秒内容都当成已经说过，后续就可能出现“刚才已经解释过”的错位。

Realtime API 将移除未播放部分称为截断。WebRTC 和 SIP 连接由服务端管理输出缓冲并处理自动截断；使用 WebSocket 时，客户端需要停止播放，并通过 conversation.item.truncate 告知播放位置。打断与截断说明

这些是公开 API 的机制。ChatGPT Voice 支持用户插话，但其是否使用上述相同配置和事件协议，公开资料尚未确认。

任务如何接住后续指令

回到“把按钮放大一点”的例子。一个可实现类似体验的应用，可以按以下流程组织；这是参考设计，不是 GPT-Live 的内部调用记录。

语音层整理请求：从对话中确定要修改的页面和按钮，必要时追问。
任务层开始执行：创建任务并返回标识，例如“任务 A”；语音会话继续接收输入。
进度回到对话：任务层报告“已定位样式，正在检查效果”，语音层据此回答进度。
补充要求进入原任务：用户说“只改首页”时，系统把新约束送给任务 A，并接收处理结果。

实现时，需要记录当前讨论的是哪个任务，以及任务收到的是哪一版要求。还要区分“停止播报”和“取消后台工作”：用户只是打断一句说明时，系统应继续理解后续话语，再决定是否改变任务。这些属于应用的状态管理设计。

公开 Realtime API 提供一种可用的连接方式：客户端传输音频，应用服务器通过另一个控制连接接入同一会话，监听事件、更新指令、响应工具调用。这样，任务逻辑可以放在服务端。服务端控制说明

屏幕上下文如何补足语音

“把这个按钮放大”中的“这个”，需要与当前界面对应。官方说明，在 macOS 开启屏幕上下文后，用户可以请求查看当前窗口；ChatGPT 能获取包含窗口图像和可访问文本的 Appshot，作为上下文。屏幕上下文说明

因此，理解这句话需要把语音中的要求、窗口里的对象，以及正在讨论的任务关联起来。仅凭这项功能，不能推断 GPT-Live 在持续接收屏幕视频，或知道它内部采用了怎样的视觉编码器。

从公开资料能确定的实现边界

GPT-Live 的产品分工已经比较清楚：实时对话负责交流和协调，任务模型负责持续执行。实现类似体验时，公开 API 已提供实时音频、接话判断、打断处理和服务端控制等基础能力。

尚不能从这些资料确定的，是 GPT-Live 自身的参数规模、音频编码方法、训练配方，以及是否与某个公开 Realtime 模型共享权重。把接口能力直接当作专有模型内部结构，会超出证据范围。

对开发者而言，最有用的启示是：让对话及时响应，让任务持续执行，再让双方共享准确的进度和用户要求。 语音体验的质量，取决于这几部分是否配合一致。

击壤而歌