GPT-Live-1 接入 API：语音智能体不再只是“会聊天”

OpenAI 今天宣布，实时语音模型 GPT-Live-1 正式上线 API，开发者现在可以把它接入客服、电话外呼、预约、语音学习和企业内部流程，让语音智能体从“回答问题”进入“边听边判断、调用工具并完成任务”的阶段。

这次更新最关键的变化，不是又多了一个语音音色，而是 OpenAI 把 GPT-Live-1 定位成了一个可以直接嵌入业务流程的全双工语音层。它支持在说话时继续听用户输入，识别自然停顿、处理打断，并在必要时调用后端文本模型和业务工具。

简单说，过去的语音机器人更像对讲机：用户说完，系统再转写、思考、合成语音；GPT-Live-1 更接近电话里的真人，双方可以同时说话，系统也能判断什么时候该继续说、什么时候该停下来听。

全双工语音，解决的不只是延迟

全双工语音交互是指模型可以同时接收用户声音和输出自己的声音，而不是严格按照“用户说完—模型回答”的半双工流程工作。

传统语音应用通常由三段组件拼接而成：自动语音识别，也就是 ASR；文本大模型；文字转语音，也就是 TTS。用户说话后，音频先被转成文字，再交给大模型生成答案，最后由 TTS 合成语音。每一段都可能引入排队、网络传输和状态同步延迟。

更麻烦的是，传统系统需要自己判断用户是否说完。用户只是停顿半秒思考，系统可能就把这当成句末，立即抢答；用户真正想插话时，系统又可能继续播完整段答案。开发者通常需要额外维护端点检测、打断逻辑、音频缓冲、转写状态和会话状态，语音产品很容易变成一堆胶水代码。

GPT-Live-1 将语音理解与语音输出整合在同一个实时模型中，模型可以根据音频流和上下文持续判断当前轮次。它不仅关注用户说了什么，也判断用户是不是还在组织语言、是否真的结束、是否正在插话，以及自己的声音是否应该继续播放。

OpenAI 披露的早期评估显示，在 Speak 的语言学习场景中，学习者思考停顿期间的误打断次数较此前基于轮次的系统减少近 80%。这个指标比单纯的语音识别准确率更能说明问题：对于语音智能体来说，能否在正确的时机保持安静，和能否听懂内容同样重要。

OpenAI 在 Full Duplex Bench 测试中称，GPT-Live-1 的表现比 GPT-Realtime-2.1 高出 30 个百分点。不过，这一数字来自 OpenAI 自己公布的评测，测试集、任务分布和具体评分细节仍需要开发者结合真实业务验证，不能直接等同于所有场景中的 30% 性能提升。

从“回答”走向“执行任务”

工具调用是指语音模型在对话过程中把任务交给外部系统执行，而不是只用语言描述应该怎么做。

GPT-Live-1 可以连接后端文本模型、企业数据库和业务工具。例如，用户通过电话说“帮我订今晚七点、四个人的位置”，语音层负责听清需求、确认关键信息和维持自然对话，后端模型再负责复杂推理，工具则查询餐厅库存并提交预订。

OpenAI 提到，开发者可以将 GPT-Live-1 与 Codex 等工具连接，也可以通过 OpenAI Presence 构建能够查询企业系统、执行获批操作并在必要时转交人工的语音工作流。这里的重点不是让语音模型直接拥有所有权限，而是由开发者配置后端模型、可用工具和智能体框架，把高风险操作限制在明确的授权范围内。

这使它适合几类此前比较难做好的场景：

• 电话客服：识别来电意图、查询订单、修改预约，复杂或敏感问题转人工。
• 餐厅与服务预约：通过语音确认时间、人数、偏好，再调用预订系统完成操作。
• 医疗服务前台：查询已授权的就诊信息、安排回访，但不直接替代医生做诊断决策。
• 企业内部助手：查询 CRM、工单、库存或排班系统，并执行经过审批的操作。
• 语言学习：允许学习者停顿、纠正发音和随时插话，减少被机器抢话的挫败感。
• 电话销售与回访：根据脚本和客户回答动态调整话术，并把结果写回业务系统。

医疗服务平台的联合创始人兼首席技术官 Tony Stoyanov 表示，团队接入 GPT-Live-1 后代码量减少了 80%，删除约 2.3 万行代码。这个案例说明，模型能力的提升不只是让最终对话更自然，也可能直接改变开发成本：过去由业务方维护的一部分轮次检测和音频控制逻辑，现在可以交给模型处理。

不过，代码少并不意味着系统可以少做工程。电话录音合规、身份验证、权限边界、敏感操作二次确认和人工接管，仍然需要开发者在模型之外设计清楚。语音模型擅长处理模糊交流，但不应该成为未经约束的业务控制器。

GPT-Live-1 的能力和价格

GPT-Live-1 是 OpenAI 面向实时语音交互推出的模型，支持原生语音识别转写、语音回复、字母数字理解、关键词偏置和轮次检测。

其中，关键词偏置对电话和专业业务尤其重要。品牌名、人名、产品型号、订单号等词汇，在普通语音识别系统中经常因为发音相近或背景噪声而被识别错误。开发者可以通过配置关键词和领域上下文，提高这些关键实体的识别稳定性。

模型还支持通过系统提示词调整语气、语速和对话风格，并允许开发者配置后端模型、工具以及智能体框架。也就是说，GPT-Live-1 更像一个负责实时交流的语音前端，而不是一个必须独自完成所有推理的单体模型。

| 项目 | GPT-Live-1 | GPT-Realtime-2.1 | 传统语音链路 | |---|---|---|---| | 交互模式 | 全双工，可同时听和说 | 实时语音交互，但全双工能力与任务表现较弱 | 通常为半双工，严格轮流说话 | | 打断处理 | 支持自然停顿、插话和动态停说 | 支持实时交互，具体效果依赖实现 | 主要依赖端点检测和业务代码 | | 工具调用 | 支持连接后端模型和企业工具 | 支持实时应用能力，需按接口配置 | 需要自行串联 ASR、LLM、TTS 与工具 | | 语音理解 | 原生语音理解与转写 | 实时语音模型 | 先转文字，再交给文本模型 | | 电话任务 | 支持预约、客服和人工转接类场景 | 可用于实时应用，但需验证复杂任务表现 | 工程成本高，打断和状态同步复杂 | | 前端语音价格 | 每分钟 0.05 美元 | 需按官方实时模型价格核算 | 由 ASR、LLM、TTS 等多项费用组成 |

GPT-Live-1 前端语音层的价格为每分钟 0.05 美元。按每小时 60 分钟计算，纯语音前端成本约为 3 美元，按参考汇率约合 20.2 元人民币；后端模型、工具调用、电话线路、存储和其他基础设施费用另行计算。

因此，不能简单把每分钟 0.05 美元理解成一次完整电话任务的总成本。一个五分钟的客服通话，语音层费用约为 0.25 美元，但如果过程中调用高推理强度文本模型、检索企业知识库并执行多个外部工具，最终账单会更高。对于大规模呼叫中心，真正需要核算的是平均通话时长、并发量、工具调用比例和人工转接率。

下面这段配置示意了一个合理的产品拆分方式。它不是 API 调用代码，而是帮助开发者理解 GPT-Live-1 在系统中的职责边界：

agent:
  voice_model: GPT-Live-1
  mode: full_duplex
  turn_detection: natural_pause_and_interrupt
  transcription: native
  response_style:
    tone: calm
    speed: conversational
  backend_model: text_reasoning_model
  tools:
    - name: enterprise_customer_lookup
      permission: read_only
    - name: appointment_booking
      permission: user_confirmation_required
    - name: human_handoff
      permission: always_available

对开发者最重要的变化：少写状态机，但要多做权限设计

实时语音产品的复杂度，过去很大一部分集中在状态机上：什么时候开始录音，什么时候停止录音，用户打断后如何清空播放缓存，转写结果如何和模型上下文对齐，工具执行期间如何让用户知道系统没有卡住。

GPT-Live-1 把这些交互层问题部分内化到模型中，开发者可以把精力从“让它不要抢话”转向“它到底应该做什么”。这会明显降低原型开发门槛，尤其适合需要快速验证语音客服、语音导购和电话助手的团队。

但实时性也会放大错误。文本聊天里，模型把一个订单号写错，用户通常有机会回看；电话里，系统可能在用户没察觉的情况下听错一位数字并继续执行。全双工交互越自然，用户越容易把它当成真人，也越容易忽略模型其实仍可能误听、误判和误操作。

所以，生产环境至少需要三层保护：

1. 识别层保护：对订单号、金额、日期、电话号码和药品名称等关键字段进行重复确认。
2. 执行层保护：把查询权限和写入权限分开，高风险操作必须获得用户明确确认。
3. 交互层保护：提供实时人工接管、通话中止和错误回滚机制，不能只依赖模型自我判断。

OpenAI Presence 所代表的方向也值得关注：语音模型不再只是一个独立聊天窗口，而是企业软件的入口。用户不需要知道背后调用了哪个 CRM 接口、哪个知识库或哪个推理模型，只需要说出目标。对开发者来说，这意味着语音交互正在从前端体验问题，变成权限、审计和业务编排问题。

语音自然了，但“像真人”不是唯一指标

OpenAI 同时扩大了实时语音选项，新增 Quartz、Ripple、Vesper、Willow、Stone、Gleam、Meridian、Bossa、Tempo、Beacon、Delta 和 Cinder 等声音，并表示未来数月还会继续增加语音和语言支持。

更多音色有助于覆盖客服、教育、陪伴和企业品牌等不同场景，但声音自然度并不等于交互质量。此前 GPT-Live 在 ChatGPT 端的早期反馈中，有用户认为模型频繁使用“嗯”“我明白”等回应词，反而造成注意力干扰。真人会用这些短促反馈确认自己仍在听，但 AI 如果在每次停顿都插入回应，就可能从“自然”变成“喋喋不休”。

多语言表现也需要谨慎看待。实时翻译和跨语言对话是语音模型最容易展示效果的场景，但口音、语域、专业词和文化语境仍会影响真实体验。开发者如果面向中文用户提供服务，不能只看英文演示或平均指标，必须单独测试普通话、方言、夹杂英文、数字串和嘈杂电话环境。

此外，OpenAI 已为 GPT-Live 生成的音频加入 SynthID 水印，并提供公开验证工具和验证接口，帮助开发者和组织识别音频中的 OpenAI 来源信号。对于客服录音、教育内容和媒体生产来说，这有助于建立内容溯源，但水印不能替代用户告知、录音授权和隐私合规。

我们的判断：GPT-Live-1 值得关注，但不是“电话客服自动化完成”

GPT-Live-1 的真正价值，在于它把全双工交互、打断处理和工具调用放到了同一套实时语音产品里。相比单独购买 ASR、文本模型和 TTS，再自行拼接状态机，它更接近一个可直接部署的语音智能体底座。

从性能看，Full Duplex Bench 领先 GPT-Realtime-2.1 30 个百分点，Speak 的误打断减少近 80%，这些数据足以证明它解决了实时语音交互中的几个核心痛点。从成本看，前端语音层每分钟 0.05 美元并不算离谱，但最终是否划算，要看后端推理和业务工具占总成本的比例。

我们不建议开发者把它理解成“接入后就能自动接管呼叫中心”的万能模型。它更适合先从低风险、可回滚、流程边界清晰的任务开始：查询订单、预约时间、收集信息、生成工单，再逐步开放修改和执行权限。

今天 API 正式开放后，GPT-Live-1 的竞争重点也会从演示效果转向三个指标：真实通话中的平均响应延迟、复杂噪声环境下的关键字段准确率，以及工具调用失败后的恢复能力。谁能把这三件事做稳，谁才真正拥有可用的语音智能体，而不是一段听起来很像真人的产品演示。

对关注 AI 应用的开发者而言，GPT-Live-1 值得立刻测试；对准备将它用于生产环境的企业而言，建议先做一轮包含打断、沉默、口音、数字确认、权限校验和人工转接的端到端压测。语音智能体的下一步已经不是“能不能说话”，而是“能不能在不出错的前提下完成事情”。

参考来源

• IT之家：OpenAI 扩大实时语音模型能力，GPT-Live-1 上线 API —— 提供 GPT-Live-1 API 上线、全双工能力、工具调用、评测数据和价格信息。
• 知乎专栏：实时语音模型与全双工架构整理 —— 补充实时语音交互、端点检测和行业技术背景。
• IT之家：GPT-Live 相关产品动态 —— 用于交叉了解 OpenAI 语音产品的后续报道与行业进展。