GPT-Live-1语音智能体：会话模式、委托方式及实际电话线路成本。
OpenAI全双工语音模型的实用详解：会话运行流程、响应机制与客户端委托方式、成本估算实例以及文档中的陷阱。
来源: How to Use GPT-Live-1: Build a Voice Agent That Listens While It Talks
凡是打过电话给餐厅却接通语音机器人的人都知道那种情形：你说完话后会有短暂的停顿，紧接着机器人就开始回答你五秒钟前提出的问题，而你正试图纠正自己的话。大多数人最终都会按0来请求与真人通话。
这种尴尬的节奏其实是常规设计所固有的。传统的语音机器人会等待你停止说话，将音频转换为文本，经过处理后再将答案转回语音并播放出来。没有人能够打断另一个人的发言。
GPT-Live-1是OpenAI尝试推出的不同形态的产品。它是通过API提供的ChatGPT Voice背后的模型，具备边听边说的功能。本页面将介绍它的独特之处、会话的运行方式、它是如何将复杂问题转交给后端模型的，以及使用小型电话线路的成本是多少。
GPT-Live-1是什么
这是一种全双工语音模型。全双工意味着双方可以同时说话，就像普通电话通话一样。如果来电者打断说“其实要四个人参与”，该模型会暂停、调整后再继续。
该模型还将复杂的思考任务交给其他系统处理。每当需要耗费大量精力来完成某项任务，无论是搜索、查询预订系统还是进行复杂推理，这些工作都会交由独立的后端模型处理。OpenAI的发布资料中提到，任务切换的延迟约为0.8秒，而之前的语音模型这一数值约为1.4秒。此数据为厂商提供的数值。
实际效果是语音处理与逻辑思考变成了两项独立的工作。语音模块负责对话，而后端模块则负责推理和工具操作。
分工协作：负责对话的语音与负责思考的“大脑”
OpenAI将这种任务交接称为“委托”。在短短几分之一秒的时间里，语音模型会不断判断是保持安静倾听、停止说话，还是将任务转交给后台处理。在任务执行期间，通话永远不会卡住，因为语音模型可以说一句“让我查一下”，从而让对话继续进行。
想象一下，有位来电者询问餐厅是否在周五7点30分有可供四人使用的桌子。模型会回应“让我看看”，然后将座位可用性查询发送到后台，等结果返回后再告知来电者。
这种分离方式还解决了知识更新的问题。根据其模型介绍页面，语音模型的知识截止时间为2025年7月31日，因此所有最新信息都必须来自后台。
启动语音会话
浏览器应用可使用 WebRTC 进行连接，从服务器获取音频时可使用 WebSockets，而真实电话号码则适用 SIP 电话技术。无论选择哪种方式，相关事件的形式都相似，因此以下步骤均适用于这些情况。
步骤 1：将 API 密钥保存在服务器上
请将密钥与浏览器隔离开来。由您信任的服务器来创建会话，而浏览器仅负责处理麦克风和扬声器功能。由于不支持免费套餐，因此需要付费账户，且并发实时会话的数量会受到流量限制的影响，并会随着您的使用等级上升而增加。
步骤 2：启动会话
连接成功后，发送一个包含您所设置参数的 session.start 事件即可。
{
"type": "session.start",
"session": {
"model": "gpt-live-1",
"instructions": "Be concise and ask before taking an external action.",
"audio": { "output": { "voice": "marin" } },
"delegation": { "type": "client" }
}
}
该事件负责选择模型、提供指令、选定语音，并确定谁负责后台处理。在 session.started 返回之前请勿发言。一旦会话开始，模型、指令和语音参数就会被锁定，因此后续规则需通过 session.instructions.append 添加，而不能替换原有内容。
步骤 3：双向传输音频
使用 WebRTC 时，浏览器会处理音频部分。通过 WebSockets，您需要在 session.input_audio.append 事件中发送小块音频数据。其格式有严格要求：必须是原始的单声道 16 位 PCM 格式，经过 Base64 编码，不包含 WAV 头部信息，采样率需与启动时设置的相同（默认为 24 kHz）。模型的语音也会以相同方式返回，通过 session.output_audio.delta 事件传递。如果您的音频源采用不同的采样率，则需自行进行重采样，因为仅更改格式设置无法转换字节数据。
步骤 4：读取文字记录
双方的实时文字内容会通过 session.input_transcript.delta 和 session.output_transcript.delta 事件传来。由于双方可能同时发言，因此不存在“发言结束”事件。如果您的应用需要结构清晰的日志记录，可在本地对这些文字片段进行分组处理。
步骤 5：干净地关闭连接
调用session.close，然后持续读取直到出现session.closed。这个最终事件会包含用于计费的使用数据。如果在该事件出现之前连接就已断开，就无法获得确认的使用记录，这在对账单进行核对时非常重要。
人们最常忘记的步骤是第四步，即从转录片段中整理出可阅读的内容。
将任务交由后端处理
在此阶段，GPT-Live-1不再只是个悦耳的声音，而变成了一个实用的智能体。在会话开始时会选择两种委托模式中的一种，且中途无法更改。如需切换，需启动新的会话。
选项A：响应委托
你需要指定语音应调用的响应模型以及它可使用的工具。相关配置会与模型名称一同存储在会话对象中。
"delegation": {
"type": "responses",
"responses": {
"model": "gpt-5.5",
"instructions": "Use tools when current information is required.",
"tools": [{ "type": "web_search" }],
"tool_choice": "auto"
}
}
从那以后，需要搜索的来电者问题由后端处理，搜索结果会直接融入正在进行的对话中。而自定义函数则不同，像 check_table 这样的函数并非由后端执行，而是由您的应用程序接收调用、运行该函数、返回结果，然后再告知后端继续处理。
想象一下，有来电者询问周五晚上是否会下雨，因为他们打算在户外聚会。后端会进行网络搜索，语音系统会提示六点后可能有小雨，因此在室内可能更安全，这样来电者就无需面对漫长的沉默了。
选项 B：客户端委托
在这种模式下，您的应用程序本身就充当后端。当模型需要帮助时，您会收到一个包含编号的 session.delegation.created 事件，您可以按照自己的方式处理任务，然后用相同的编号将答案传回。
{
"type": "session.commentary.append",
"delegation_id": "item_delegation_123",
"content": "Table for 4 is confirmed at 7:30 pm Friday."
}
评论消息意味着模型应将该文本大声读出。如果模型需要默默知晓某些信息，则使用session.thinking.append来实现。每条消息的长度约为500个标记。原则上，客户端处理程序可以将任务交给您选择的代理框架，但在依赖该组合之前需要进行专门测试。
一个合理的做法是先从受管理的响应委托开始，一旦需要对权限、确认流程或工作流本身有更多控制，再转向客户端委托。
成本是多少
语音层的费用为每分钟0.05美元，按秒计费。这意味着每小时费用为3美元，若线路全天24小时保持开启状态，则每日费用为72美元。后端模型和工具则另行计费，因此实际总费用取决于需要辅助处理的调用频率。
以下是一个使用假设数值的示例：
- 假设一家餐厅的客服热线每月接到2,000通电话，每通电话时长约3分钟。那么总通话时间为6,000分钟，仅语音通信费用即为6,000乘以0.05美元，合计300美元。
- 接着假设每通电话需要两次任务交接，每次交接大约涉及3,000个输入标记和300个输出标记，后端处理费用为每百万输入标记10美元，每百万输出标记50美元。单次任务交接的费用为0.03美元加上0.015美元，合计0.045美元。两次交接则每通电话需0.09美元，2,000通电话的总费用为180美元。
- 总计每月费用约为480美元，即每通电话约24美分。
上述标记数量和后端费用都是针对简单预订流程的估算值，因此在依赖这些数据之前请先自行统计实际流量。语音通信费用相对容易预测，而后端处理费用才是需要重点关注的部分。
发布内容中省略的细节
中断通话并不会取消已进行的工作
根据文档说明，切断助手的讲话并不会自动停止后端工作。即使用户说“算了”，只要您的应用没有中断，搜索或预订流程仍可能继续完成。对于查询天气而言这并无大碍，但对于先说“预订”后又说“等等，不要”的情况则相当严重。
已接收但未被听到
虽然添加结果后会得到确认回复，但这并不能说明模型确实已经说出该内容，也无法证明有其他人听到了它。完成后端回复只是一个事件，而用户听到它则是另一个事件。对于任何需要确认的内容，比如预订时间，都应在输出记录中查找相关文字。
不同来源的基准数值存在差异
关于该模型在客户服务任务上的测试成绩，OpenAI官方发布的内容与媒体报道之间存在差异。无论哪种数据，其相比旧模型的提升幅度都相当大，但这些结果均由厂商提供，缺乏独立测试支撑。诸如某语言学习公司称用户思考暂停时的干扰显著减少之类的用户反馈，仅属于个案描述，并非正式研究结果。
安静的上下文环境并非保密的理想之地
通过session.thinking.append输入的任何内容都可能影响后续的输出。请勿将账号信息或私人笔记放入其中。
适用场景与不适用场景
它适合以下场景：
- 用于预订、订单处理及简单支持的电话线路
- 用户需要在句子间暂停思考的学习类应用
- 希望取代由三个独立模型组成的复杂处理流程的团队
请慎重考虑以下情况：
- 那些一个错误操作就会造成严重后果的通话，比如支付操作
- 目前就需要定制品牌语音的产品，因为这类需求要经过单独的审批流程
- 任何需要图片或视频输入的内容，该模型都无法处理
一种有风险的做法是，一旦通话者说“可以”，就立即让后端确认预订，而不去核实他们实际说了什么。更安全的方式是先复述确认内容，等待明确的肯定答复，如果通话者改变主意，则让您的应用取消待处理的操作。虽然语音效果可能很好，但安全检查仍应由您的应用来负责。
要点
- 由于模型会在通话过程中持续监听，通话者可以随时打断或改变话题
- 那些需要完成实质性任务的操作，无论是由OpenAI处理还是由您的应用处理，都会交由后端模型来执行
session.started、流式传输音频、从转录片段中整理对话内容，最后干净地结束。