OpenAI语音Agent能主动打电话了

OpenAI正式补上了语音 Agent 进入真实电话网络的关键一环：截至2026年11月7日，GPT-Live的外呼SIP能力已经向所有组织开放，开发者可以让语音 Agent 通过Twilio、Telnyx等SIP Trunk服务主动拨打电话号码，而不再局限于接听用户打来的电话。

这不是给语音模型增加一个“拨号按钮”，而是把模型、企业电话系统和公共电话网络真正接到了一起。过去，开发者要实现AI外呼，通常需要自己接收运营商音频流、转换音频格式、维护双向WebSocket，再将数据送进实时模型；现在，电话音频可以通过SIP直接进入OpenAI的语音会话，后端只需负责业务逻辑、工具调用和通话控制。

OpenAI官方文档已经明确写明：外呼SIP面向所有组织开放，但必须通过Live API创建会话，而不是使用Realtime API原有的通话创建接口。对应的会话端点为POST /v1/live/sessions，模型则使用gpt-live-1。(developers.openai.com)

SIP开放外呼，改变了什么

**SIP是一套用于建立、控制和结束互联网电话会话的标准协议。**它可以理解为电话网络里的HTTP：SIP负责告诉网络“给谁打电话、谁正在响铃、谁接听了、什么时候转接或挂断”，真正的语音数据则通过独立的媒体通道传输。

OpenAI此前已经支持通过SIP接听电话，但接听和主动外呼是两个完全不同的产品阶段。

接听电话时，Agent处于被动状态：用户先拨打企业号码，SIP服务商再将呼叫送到OpenAI。主动外呼则意味着Agent可以被业务事件触发，例如订单状态改变、预约即将到期、客户提交回访申请，或者系统检测到需要人工确认的信息。

| 能力 | SIP呼入 | SIP外呼 | |---|---|---| | 发起方 | 用户主动拨打 | 企业系统或Agent主动拨打 | | 会话入口 | 来电Webhook与接听请求 | POST /v1/live/sessions | | 是否需要接受来电 | 需要接受或拒绝 | 不需要 | | 典型场景 | 客服、总机、信息查询 | 预约确认、提醒、回访、通知 | | 通话状态 | 来电、接听、挂断 | 响铃、接听、失败、挂断 | | 主要风险 | 身份验证、提示注入 | 用户授权、频率控制、骚扰与欺诈 |

**外呼能力让语音 Agent 从“等人提问”变成了“主动完成任务”。**一个餐厅Agent不再只能等待顾客打电话订位，还可以在预约前两小时主动确认人数；一个售后Agent可以在维修完成后发起满意度回访；一个医疗预约系统可以提醒用户时间，并通过按键或自然语言完成确认。

这类流程过去当然也能做，但通常需要把电话平台、音频处理服务、语音识别、文本模型和语音合成拼成一条很长的链路。链路越长，延迟、故障点和状态同步问题就越多。

这次开放的核心，不只是“能拨出去”

**GPT-Live是一种全双工实时语音模型，可以在持续听取声音的同时生成语音。**它和传统的“语音识别—文本模型—语音合成”流水线不同，不必等用户彻底说完、转成文字后再组织答案，因此更容易处理插话、停顿、背景噪声和多人同时说话的情况。(developers.openai.com)

OpenAI此次给出的外呼SIP方案包含了几项生产环境真正需要的能力。

1. SIP信令和通话音频分别加密

OpenAI要求SIP服务商支持TLS信令和SDES-SRTP媒体传输。SIP服务商地址必须使用sips:协议，默认端口是5061；电话音频则通过SRTP加密传输。(developers.openai.com)

这项要求会挡住一部分老旧或配置不完整的企业电话系统。某些PBX虽然支持SIP，却仍然使用未加密的UDP信令和普通RTP音频，不能直接用于GPT-Live外呼。

2. 电话号码必须使用E.164格式

**E.164是国际电话号码的标准表示方式。**目标号码需要以国家或地区代码开头，例如美国号码写作+14155550123，而不是带空格、括号或本地拨号前缀的格式。

OpenAI目前的外呼目标只接受E.164电话号码，不支持将任意SIP URI直接填写为被叫地址。SIP URI仍然可以用于通话转接，但不能替代初始外呼号码。(developers.openai.com)

3. 具备完整的通话状态事件

创建会话返回200 OK，只代表OpenAI已经初始化语音会话，并不代表对方已经接听。

开发者需要监听三类关键事件：

| 事件 | 含义 | 业务系统应采取的动作 | |---|---|---| | transport.ringing | 电话正在响铃或播放早期媒体 | 更新为呼叫中，启动超时监控 | | transport.answered | 对方已经接听，音频通道建立 | 开始对话与任务执行 | | transport.failed | 呼叫建立失败 | 记录失败原因，决定是否重试 |

这种区分很重要。外呼系统最常见的错误之一，就是把“请求成功”误认为“电话接通”，随后提前写入回访完成、通知成功等业务状态。

OpenAI还规定，响铃阶段最长为3分钟，一次已接通的通话最长为2小时，这两个限制目前不能在创建会话时修改。(developers.openai.com)

4. 支持收发DTMF按键事件

**DTMF是电话按键产生的双音多频信号。**它就是客服电话里常见的“按1确认、按2取消”，也是语音 Agent 与传统IVR、门禁系统和会议系统交互的基础能力。

GPT-Live的侧带连接可以接收transport.dtmf.received事件，也可以发送transport.dtmf.send事件。这意味着Agent不仅能够听懂用户说“确认”，还可以识别用户实际按下的数字键；反过来，Agent也能替用户与另一套电话菜单交互。(developers.openai.com)

DTMF看起来是一个不起眼的功能，却决定了语音 Agent 能否进入现有电话基础设施。大量银行、物流、酒店和企业总机仍依赖按键菜单，单纯支持自然语言并不足以跑完整流程。

5. 可以转接人工和主动挂断

外呼Agent可以通过REFER机制把当前电话转给人工坐席、另一部电话或企业内部SIP地址，也可以由后端主动结束通话。

**SIP REFER是一种把当前通话交给另一个目标的标准转接机制。**OpenAI提供的转接控制允许目标使用tel:电话号码或sip:地址，具体转接流程由SIP服务商继续处理。(developers.openai.com)

这让“AI先处理、人工再接手”成为标准流程，而不是异常兜底。例如Agent可以先确认客户身份、收集问题和订单号，再将通话连同上下文交给人工坐席，减少人工重复询问。

架构变简单了，但没有简单到即插即用

**侧带连接是一条独立于电话音频的后端控制通道。**在GPT-Live的SIP架构里，SIP负责传输通话音频，后端则通过WebSocket接收会话事件、调用业务工具、发送按键、转接电话和结束通话。

这种架构的价值是把“媒体传输”和“业务执行”拆开。企业服务器不必持续搬运每一帧电话音频，却仍能观察对话、调用CRM、查询订单、写入预约结果。

| 架构 | 音频路径 | 后端工作量 | 适用场景 | |---|---|---|---| | OpenAI原生SIP | SIP服务商直接连接GPT-Live | 主要处理业务逻辑和控制事件 | 新建外呼Agent、标准电话工作流 | | Media Streams方案 | 电话平台把音频流发送给企业服务器，再连接模型 | 需要处理音频流、格式和连接状态 | 需要深度控制音频、录音或媒体处理 | | 传统ASR+LLM+TTS | 音频经过识别、文本推理和语音合成 | 组件多、状态复杂 | 强文本审计、可替换不同语音组件 |

原生SIP不是全面替代Media Streams。需要自定义降噪、混音、声纹处理、实时录音或特殊编解码器的团队，仍可能选择自己管理媒体链路。但对于预约、通知和标准客服任务，原生SIP明显更省工程成本，也减少了连接断开、音频积压和插话状态不同步的问题。

需要注意的是，侧带连接只会重放此前3秒内的事件。后端应在会话创建后立即连接，否则可能错过早期的响铃或接听事件；同一个事件还可能被重复观察，因此业务动作必须按照event_id做幂等处理。(developers.openai.com)

价格不是每分钟5美分这么简单

**GPT-Live的前端语音层按通话时长计费，当前价格是每分钟0.05美元，并按秒结算。**一通90秒的电话，对应的GPT-Live语音费用约为0.075美元，不会被向上取整为两分钟。(platform.openai.com)

但0.05美元并不是一通电话的全部成本。实际费用至少由三部分组成：

1. GPT-Live语音会话时长费用；
2. 后端推理模型、工具调用和数据查询费用；
3. SIP服务商收取的号码、线路和电话网络费用。

GPT-Live会把语音交互和后端推理分开计费。即便用户和Agent都没有说话，只要会话仍处于活动状态，静默等待和后端处理时间也会计入语音时长。因此，系统必须在任务完成后及时关闭会话，而不是只停止播放声音。(developers.openai.com)

以每天1万通、平均90秒的外呼为例，仅GPT-Live前端语音层的理论费用约为750美元；再加上电话线路和后端模型，规模化部署的成本控制重点会落在平均通话时长、接通率、静默时间和无效重试次数上。

真正的难点从语音技术转向运营治理

**外呼语音Agent是一种由软件主动发起电话并完成预设业务目标的自动化系统。**它的技术门槛正在下降，但产品责任比普通聊天机器人更重。

聊天机器人答错一句话，用户可以关闭页面；外呼Agent在错误的时间打给错误的人，影响会直接落到真实电话号码和现实生活中。OpenAI把能力开放给所有组织后，开发者至少需要补齐以下控制：

• 在拨号前验证电话号码、任务类型和用户授权状态；
• 设置本地时间段限制，避免在夜间或休息时间外呼；
• 为同一号码设置频率上限和拒绝联系名单；
• 明确告知用户正在与AI系统通话；
• 对录音、转写和数据保存设置独立授权；
• 对转账、身份验证和敏感信息操作增加人工确认；
• 对异常高频拨号、重复失败和提示词劫持进行监控。

外呼SIP最值得警惕的并不是模型会不会说错话，而是自动化系统能否以极低成本复制一次错误。一个错误的业务规则可以在几分钟内影响成千上万个号码，因此拨号队列必须具备暂停开关、批次限制和人工审批机制。

OpenAI真正瞄准的是企业电话工作流

**电话网络仍然是企业触达用户覆盖最广的实时渠道之一。**应用通知可能被关闭，邮件可能进入垃圾箱，但预约、物流、医疗和本地服务仍大量依赖电话确认。

OpenAI这次更新的意义，是把GPT-Live从一个“网页里的语音对话模型”推向电话系统基础设施。它不一定会立刻替代成熟呼叫中心，但已经足以处理结构清晰、目标明确、可以量化完成结果的任务。

最适合优先落地的不是开放式销售，而是预约确认、订单通知、到期提醒和用户主动申请的回访。这些场景具有明确上下文、确定目标和可验证结果，Agent完成任务后可以立即结束通话，既容易评估，也更容易控制风险。

反过来，让Agent随机拨打陌生号码、进行长时间自由推销，既无法体现GPT-Live全双工语音的真正价值，也会迅速放大合规和品牌风险。

从产品竞争看，OpenAI正在把自己从“提供实时语音模型”推进到“提供电话会话运行环境”。SIP、DTMF、转接、通话状态和侧带控制看起来都是传统通信能力，但正是这些并不炫目的功能，决定了语音Agent能不能离开演示视频，进入企业生产系统。

外呼开放之后，语音Agent终于不只是更自然地聊天，而是开始真正拨出电话、调用业务系统并完成一件具体的事。

参考来源

• OpenAI Agents Python：Twilio SIP实时语音示例——OpenAI官方Agents SDK仓库中的SIP接入示例，展示来电处理、Webhook验证和Agent交接流程。
• OpenAI Agents JS：Realtime Twilio SIP示例——OpenAI官方JavaScript Agents SDK中的SIP会话与通话事件处理实现。
• Twilio GPT-Live集成示例——展示GPT-Live全双工通话、后端委托和外呼流程的参考实现。