GPT-Live-1接入API，OpenAI把全双工语音推向电话智能体

OpenAI今天宣布，GPT-Live-1正式进入API。开发者现在可以基于这一模型构建支持全双工语音交互的应用，包括能够处理用户打断、停顿、背景噪声和工具调用的电话语音智能体。

这不是把一个新的“语音输入输出模型”放进API那么简单。GPT-Live-1的关键变化在于，它不再把一段语音当作一条消息，等用户说完后再回答，而是让模型持续处在“听—说—判断”的状态中：用户说话时它可以倾听，合适时用简短回应表示自己在跟进；用户插话时可以及时停下；用户停顿时，也不会急着把沉默当成对话结束。

对于开发者而言，这意味着实时语音应用的核心难题，开始从业务代码转移到模型和基础设施本身。过去需要自己维护的轮次检测、打断处理、音频缓冲和状态机，现在有机会被统一收进实时语音模型中。

从“语音管线”到持续对话

传统语音智能体通常是一条串行流水线：先把用户音频通过ASR转换成文字，再交给大语言模型生成文本，最后由TTS合成为语音。工程上，这种架构容易拆分和调试，但每一个环节都会增加延迟，也会损失信息。

比如，用户说话时的语速、重音、犹豫、笑声，甚至一句话中间的停顿，都可能在“语音转文字”这一步被压缩掉。系统还要依赖轮次检测器判断用户是否已经说完。检测器过于积极，用户思考半秒就会被打断；检测器过于保守，用户又会感觉机器人反应迟钝。

GPT-Live-1采用的是全双工架构，能够同时接收和生成音频。这里的“全双工”可以理解为电话双方都不用轮流抢麦克风：模型在输出语音的同时，仍然持续监听输入，并且每秒多次判断自己应该继续说、暂停、继续听、回应插话，还是调用工具。

这使它更接近真实的人机对话，而不是“按下录音键—等待识别—等待回复”的语音问答。

OpenAI披露的早期评估显示，语言学习平台Speak接入GPT-Live-1后，学习者在思考停顿期间遭遇误打断的次数，相比此前基于轮次的系统减少了接近80%。这类指标对语言学习尤其重要：一个频繁抢话的AI，即使答案正确，也很难让用户愿意持续练习。

打断处理，才是实时语音的分水岭

语音模型的演示通常容易让人关注“声音像不像真人”，但真正决定产品能不能用的，往往是打断处理。

在餐厅预约、售后客服或电话销售场景中，用户不会严格等模型说完。他们会补充信息、纠正地址、改变需求，或者在模型误解后立刻插话。如果系统只是把整段音频录下来再批量处理，用户每次插话都可能变成一次新的请求，前后状态很容易错位。

GPT-Live-1的设计重点，就是让模型持续处理音频流。当它判断用户开始说话时，可以停止当前语音输出；当用户只是短暂停顿时，又不会过早结束轮次。模型还能够处理背景噪声，并通过“嗯”“对”等短促语句保持倾听反馈。

这类能力看起来是交互细节，背后其实涉及状态管理、音频流调度和推理路径设计。OpenAI在此前公布的工程说明中提到，GPT-Live的实时媒体路径与应用逻辑、工具调用进行了分离：音频持续走低延迟通道，而搜索、数据库查询和业务操作通过异步RPC执行。这样，后端工具哪怕需要几秒钟，也不必阻塞前端音频流。

这是一个重要的工程取舍。实时语音系统最怕的不是模型偶尔答错，而是一次数据库调用把整个对话卡住，最终表现为用户耳边一段明显的空白、杂音或机械等待。

语音负责交互，后端模型负责复杂任务

GPT-Live-1并不试图独自完成所有工作。OpenAI给出的架构是：让GPT-Live-1承担低延迟、连续性的语音交互，把搜索、复杂推理和更长链路的智能体任务交给后端文本模型处理。

这类似于把一个优秀的前台接待和后面的专家团队分开。前台负责让交流不中断，理解用户当下的意图；真正需要查系统、算账、检索知识库或执行多步计划时，再把任务异步交给后端模型。结果准备好后，实时语音模型继续用自然语言带回给用户。

在ChatGPT语音体验中，OpenAI此前提到GPT-Live可以在后台委派给前沿模型，早期使用的后端模型为GPT-5.5。对API开发者而言，更有价值的是这种“前端语音模型+后端推理模型+工具”的组合可以进行配置：开发者能够调整系统提示词、语气、语速、对话风格，也可以决定使用什么后端模型、哪些工具和哪套智能体框架。

这意味着语音层和业务智能层可以分别迭代。企业不必为了更换知识库、工单系统或审批流程，重新改造整套音频交互；同样，也可以在成本敏感的场景使用较轻量的后端模型，把更强的推理模型留给高价值任务。

电话智能体终于有了更现实的落点

OpenAI明确提到，GPT-Live-1可用于电话场景，例如餐厅预订和客户服务。电话智能体一直是语音AI最容易被讨论、也最难真正落地的方向，因为电话交互包含大量非结构化因素：用户说话含糊、会反复修改需求、环境噪声复杂，还经常在对话中途改变目标。

GPT-Live-1的全双工能力，至少解决了其中一部分基础问题。开发者可以让它接听电话、确认用户意图、查询企业系统，并执行经过授权的操作。对于涉及退款、账户变更或高风险决策的请求，系统还可以在必要时转交人工，而不是让模型一路自动执行。

OpenAI还表示，GPT-Live-1可以连接Codex等工具，并通过OpenAI Presence构建能够查询企业系统、执行获批操作和人工转接的语音工作流。这里的重点不是“模型会打电话”，而是语音已经开始成为智能体调用企业软件的入口。

一个更实际的客服流程可能是：用户通过电话描述问题，GPT-Live-1负责实时澄清；后端模型查询订单和售后政策；工具层执行符合权限的换货操作；如果涉及异常金额或身份验证失败，再把当前对话上下文交给人工客服。整个过程不需要用户在语音、网页和人工热线之间重复描述一遍。

当然，电话智能体离大规模替代人工还有距离。身份验证、权限边界、录音合规、敏感信息脱敏和错误操作回滚，仍然是产品方必须自行承担的责任。全双工只解决了交互自然度，不能自动解决企业流程的安全性。

评测数据亮眼，但成本要算清楚

OpenAI公布的评测结果显示，GPT-Live-1在Full Duplex Bench测试中的表现比GPT-Realtime-2.1高出30个百分点；在搭配GPT-6 Astra中等推理强度时，Tau3端到端语音智能体任务测试排名第一。

这些结果说明，GPT-Live-1的优势不只是音色或首字节延迟，而是覆盖了打断、持续对话、工具使用和端到端任务完成。不过，开发者在选型时仍然不能只看榜单。实时语音产品的真实成本，往往取决于通话时长、并发量、后端推理次数、工具调用次数以及人工兜底比例。

目前GPT-Live-1前端语音层的价格为每分钟0.05美元。按每小时60分钟计算，单纯语音前端成本约为3美元，约合20元人民币；后端模型和智能体工具费用另行计算。

这意味着一次短客服通话的语音成本并不算高，但如果一个企业每天处理数万通电话，后端检索、推理、录音存储和电话线路费用会迅速成为主要支出。尤其是模型在用户思考时仍维持实时监听，产品方需要评估“等待时间”是否也会计入音频处理成本，以及长时间静默场景如何进行资源控制。

换句话说，GPT-Live-1降低了实时语音的工程门槛，但没有让语音智能体变成免费基础设施。适合它的第一批场景，应该是人工成本高、流程相对标准化、每次交互价值足够高的业务，而不是所有电话都直接自动化。

代码量减少，是比Demo更重要的信号

医疗服务平台联合创始人兼CTO Tony Stoyanov表示，团队接入GPT-Live-1后代码量减少了80%，删除约2.3万行代码。

这个数字的意义在于，实时语音应用过去有大量“胶水代码”：音频缓冲、轮次判断、打断回滚、上下文同步、状态转移、异常重连，以及各种针对边界情况的补丁。模型原生承担更多交互控制后，团队可以把精力转回业务逻辑和安全策略。

如果开发者通过OpenAI兼容接口接入OpenAI Hub，实时语音部分可以按平台提供的Realtime协议配置。下面是一个偏配置化的示意，实际事件字段、可用声音和工具格式应以当前API文档为准：

curl -N -X POST "https://api.openai-hub.com/v1/realtime/sessions" \\
  -H "Authorization: Bearer $OPENAI_HUB_API_KEY" \\
  -H "Content-Type: application/json" \\
  -d '{
    "model": "gpt-live-1",
    "voice": "Quartz",
    "modalities": ["audio", "text"],
    "instructions": "你是餐厅电话预订助手。遇到身份、付款或异常订单问题时转接人工。",
    "backend_model": "gpt-6-astra",
    "tools": [
      {
        "type": "function",
        "name": "check_reservation",
        "description": "查询餐厅预约空位",
        "parameters": {
          "type": "object",
          "properties": {
            "date": {"type": "string"},
            "guests": {"type": "integer"}
          },
          "required": ["date", "guests"]
        }
      }
    ]
  }'

这段配置体现了GPT-Live-1的使用方式：实时语音层负责对话节奏，后端模型负责更复杂的判断，工具负责连接企业系统。对于已经使用OpenAI格式构建模型网关的团队，迁移成本会低于重新接入一套完全不同的语音协议。OpenAI Hub目前也提供GPT、Claude、Gemini、DeepSeek等主流模型的统一API入口，适合把实时语音模型和后端推理、检索模型放进同一套调用体系中，但具体可用模型和实时接口能力仍应以平台当日文档为准。

新声音和内容溯源也被纳入产品路线

除了GPT-Live-1，OpenAI这次还新增了Quartz、Ripple、Vesper、Willow、Stone、Gleam、Meridian、Bossa、Tempo、Beacon、Delta和Cinder等声音，并表示未来数月将继续增加声音和语言支持。

声音数量增加对开发者并非单纯的“音色更新”。电话客服、教育陪练、车载助手和无障碍应用对语速、辨识度、情绪表达和长时间耐听程度的要求不同。声音选择越丰富，产品越有机会针对场景做差异化，但也会带来品牌一致性、用户告知和语音冒充风险等问题。

OpenAI此前还宣布，ChatGPT语音和API中由GPT-Live生成的受支持音频加入SynthID水印，并提供公开验证工具及API验证能力。对于媒体、客服录音和企业工作流来说，这为后续识别AI生成音频提供了基础。不过，水印更像是来源验证能力，而不是一套完整的反诈骗方案，企业仍需配合身份认证、权限系统和人工复核。

判断：实时语音的竞争点，已经从“像真人”转向“能办成事”

GPT-Live-1接入API，最值得关注的不是OpenAI又发布了一个更自然的声音，而是它把实时语音模型从应用内置能力推进成了可编排的基础设施。

此前，开发者往往需要在三类方案之间权衡：自己拼接ASR、LLM和TTS，获得更强的可控性但承担复杂工程；使用传统Realtime API，降低延迟但仍要自己处理大量边界状态；或者直接调用封装好的电话机器人平台，快速上线但业务定制和模型选择受限。

GPT-Live-1试图把第三种体验带入模型API，同时保留工具调用、后端模型和智能体框架的可配置性。它对客服、预约、语言学习、销售线索筛选和企业内部语音助手都有实际价值，尤其适合那些“对话必须连续，但任务又不能只靠闲聊完成”的场景。

但它也不会自动消除语音智能体的所有问题。延迟只是第一关，真正影响上线效果的还包括识别准确率、领域术语、异常流程、权限控制、合规审计和人工接管体验。一个能自然说话、却在退款时调用错工具的智能体，仍然不是合格的生产系统。

因此，GPT-Live-1更像是一次架构升级，而不是一个可以直接替换人工客服的按钮。对开发者来说，最合理的切入方式是先挑选边界清晰、可回滚、工具权限有限的电话流程，验证打断处理和端到端任务完成率，再逐步扩大自动化范围。

截至今天，GPT-Live-1已经在API中提供。实时语音应用的门槛正在下降，但真正的竞争，接下来会落在谁能把这套“持续对话+异步推理+工具执行”的能力，嵌入具体业务，并且让它在出错时足够可控。