返回 OpenAI 简报

深入 GPT-Realtime-2:语音代理与工具路由工作流

OpenAI Build Hour 将 GPT-Realtime-2 及其配套实时模型定位为从级联语音栈走向原生语音系统的转变:系统可以推理、调用工具、更新界面,并处理生产级约束。

处理日期:2026 年 5 月 26 日
GPT-Realtime-2 信息图,展示实时语音核心、工具路由循环和生产级护栏。

执行摘要

Build Hour 介绍了一个小型实时语音模型家族:GPT-Realtime-2、GPT-Realtime-Translate 和 GPT-Realtime-Whisper。这场分享将其描述为摆脱级联语音栈的转变,这类语音栈通常把语音转文字、语言模型和文字转语音串联起来。

实际的产品变化,是从语音聊天走向语音到行动系统。演示展示了模型如何路由并行工具调用、静默更新界面、使用外部上下文,并利用指令遵循和逐轮 VAD 控制来决定代理何时说话、聆听,或保护关键播放不被打断。

对构建者来说,难点不只是接入实时模型。生产级语音代理还需要轮次管理、自定义 VAD 行为、状态持久化、会话恢复、仿真评测和合规控制,才能在嘈杂且频繁打断的环境中保持工具执行可靠。

关键要点

  • 发布讨论涵盖三个相关模型:用于语音推理的 GPT-Realtime-2、用于实时翻译的 GPT-Realtime-Translate,以及用于流式转写的 GPT-Realtime-Whisper。
  • GPT-Realtime-2 被呈现为原生多模态语音系统,而不是把转写、推理和合成服务简单包在一起。
  • 这场分享把低延迟语音交互视为架构属性,而不只是模型基准。
  • 更大的上下文窗口被定位为支持更长通话、更丰富指令和活跃工具模式的能力。
  • 并行工具调用让语音代理可以更新多个系统,而不必把每个动作都塞进顺序口头轮次中。
  • 静默执行很重要:有些语音工作流应该更新仪表盘或筛选数据,而不是叙述每个中间步骤。
  • 动态语音和语调控制很重要,因为生产级语音代理需要管理表现力、说话者特征和用户信任。
  • 语音活动检测是产品控制界面。构建者可能需要为闲聊、支持电话和合规播放设置不同的打断策略。
  • 生产部署需要在实时连接之外管理状态,这样会话才能串联、恢复和审计。
  • 当代理需要推理、调用工具并从打断中恢复时,基于仿真的评测比孤立的音频质量检查更相关。
  • 跨语言和富表现力语音能力只有在真实用户切换语言、噪声和纠错下仍能稳定遵循工具调用时才有价值。

构建者启发

  • 把实时语音产品设计成事件驱动系统,并明确区分音频、工具、UI 和状态通道。
  • 将口头回应与副作用分离,让 UI 更新和后端调用可以进行,而不产生不必要的旁白。
  • 把 VAD 和打断策略视为可配置的工作流逻辑,而不是固定的模型默认值。
  • 在带外持久化会话状态,并为长对话、连接中断和交接建立状态恢复路径。
  • 在把演示视为可部署之前,先测试混乱的真实音频、部分纠错、串音和工具失败。
  • 谨慎使用监督者或上下文注入模式,因为它们可以提升可靠性,但也会带来延迟和治理问题。

待验证事项

  • GPT-Realtime-2 及相关实时组件的外部可用性、命名和模型特定 API 行为。
  • 长上下文语音会话在累积工具调用、音频 token 和注入上下文时的延迟与成本表现。
  • 报告中的延迟和响应时间改进在特定生产音频环境中能多可靠地保持。
  • 服务端轮次检测在噪声、串音、口音或短促附和声下会在哪些地方失效。
  • 跨语言用户是否能保持与单语言用户相同的工具调用准确性和参数保真度。