对着电脑说“把这个页面的按钮放大一点”，AI 开始修改代码；接着问“改到哪了”，它能汇报进度；再补充“只改首页”，任务继续调整。这种体验需要同时处理两件事：及时接住人的话，以及持续执行需要时间的工作。
GPT-Live 负责实时交谈，任务模型负责执行工作。 官方文档明确：在已有 Codex 任务中，实际工作由该任务选定的模型执行。模型分工说明
本文依据 2026 年 9 月 9 日查阅的 OpenAI 官方资料，介绍 GPT-Live 已公开的产品分工，并以 Realtime API 展示实现类似体验的参考方案。
实时交谈与后台执行的分工
GPT-Live 支持的 ChatGPT Voice，可以发起较长的任务、查询进度、追加指令，并将结果带回语音对话。用户能够在工作继续时交谈。ChatGPT Voice 功能说明
下图展示实时对话与后台任务之间的职责关系。
两类工作对时间的要求不同。语音交互需要及时回应；修改代码、运行测试则可能持续数分钟。将它们分开，用户就能在任务执行期间继续提问、补充要求。
声音如何实时往返
语音系统常见的两种实现路线，主要区别在于声音如何进入模型、回答如何生成。
串联路线是“语音识别 → 文字模型 → 语音合成”：先把声音转为文字，再生成回答，最后读出来。它便于接入已有文字助手，也便于检查中间结果。
原生语音路线让模型直接处理音频输入并生成音频输出。OpenAI 的语音开发文档将其用于自然、低延迟的交谈。语音系统架构说明
OpenAI 面向开发者提供的 Realtime API，可以用于构建这样的实时音频应用。传输采用流式处理：麦克风持续上传小段音频，回答也分段返回，播放器收到可播放的数据后即可开始播放。其中，WebRTC 负责传输音频，数据通道可交换控制事件；OpenAI 推荐浏览器和移动客户端优先采用 WebRTC。WebRTC 接入说明
从工程上看，用户说完话后，到听见回复之间的等待，可以粗略拆成：
1 | 等待时间 ≈ 判断用户说完的耗时 |
按这个分解，模型生成速度和接话判断都会影响响应时间：即使生成很快，系统等待用户说完的时间过长，也会让人觉得反应慢。
接话与打断的处理
判断用户是否说完
“帮我把按钮改成……嗯……蓝色。”用户在停顿后补充了颜色要求，系统需要给这种思考过程留出时间。
Realtime API 提供两类判断方式：server_vad 根据声音活动和静默时长划分语音；semantic_vad 结合用户表达的内容，估计一句话是否结束。VAD 指语音活动检测，例如判断此时有没有人在讲话。
静默阈值越短，系统越容易快速接话，也越容易截断思考中的停顿；语义判断可以在“嗯……”这类表达后多等一会儿。接话判断说明
打断后同步已经听到的内容
用户插话时，系统需要协调三件事：停止当前回答的生成、停止播放剩余音频、修正对话中已播出的范围。
假设模型已经生成十秒音频，用户只听了前三秒就插话。如果历史仍把十秒内容都当成已经说过，后续就可能出现“刚才已经解释过”的错位。
Realtime API 将移除未播放部分称为截断。WebRTC 和 SIP 连接由服务端管理输出缓冲并处理自动截断；使用 WebSocket 时，客户端需要停止播放，并通过 conversation.item.truncate 告知播放位置。打断与截断说明
任务如何接住后续指令
回到“把按钮放大一点”的例子，下面的参考流程展示语音层与任务层如何配合。
- 语音层整理请求：从对话中确定要修改的页面和按钮，必要时追问。
- 任务层开始执行：创建任务并返回标识，例如“任务 A”；语音会话继续接收输入。
- 进度回到对话：任务层报告“已定位样式，正在检查效果”，语音层据此回答进度。
- 补充要求进入原任务：用户说“只改首页”时，系统把新约束送给任务 A，并接收处理结果。
实现时，系统需要记录当前讨论的是哪个任务，以及任务收到的是哪一版要求。用户插话后，语音层先停止播报、接收后续话语，再根据完整意图决定任务是继续、调整还是取消。
公开 Realtime API 提供一种可用的连接方式：客户端传输音频，应用服务器通过另一个控制连接接入同一会话，监听事件、更新指令、响应工具调用。这样，任务逻辑可以放在服务端。服务端控制说明
屏幕上下文如何补足语音
“把这个按钮放大”中的“这个”，需要与当前界面对应。官方说明，在 macOS 开启屏幕上下文后，用户可以请求查看当前窗口；ChatGPT 能获取包含窗口图像和可访问文本的 Appshot，作为上下文。屏幕上下文说明
窗口上下文为“这个按钮”提供具体对象，语音补充“放大”的要求，任务记录则明确修改发生在哪个页面。系统将这三部分关联起来，就能把一句简短的口头要求转化为具体的操作。