夜雨聆风如果你过去一年试过用 OpenAI 的 Realtime API 做点真的东西，大概率撞上过这几堵墙。延迟不稳，全球用户体验差异大；模型推理一般，复杂请求兜不住；function calling 跟语音流生硬地拼在一起，工具调用一多就乱；语种支持窄，国际化得自己折腾 STT。
今天 OpenAI 一次发了三个语音模型加一篇基础设施公告，把上面这些坑一起填了。GPT-Realtime-2 把 GPT-5 的推理接到语音上，GPT-Realtime-Translate 把实时同传打到 $0.034 一分钟，GPT-Realtime-Whisper 做流式 STT，外加他们重写的 WebRTC 栈跑在 Cloudflare 边缘。
拼起来是一句话：voice agent 终于可以做事，不只是聊天。
GPT-Realtime-2
主菜是 GPT-Realtime-2。它把 GPT-5 那一档的推理能力直接接到语音模型，128K context（之前是 32K），推理强度可调（minimal / low / medium / high / xhigh），还引入了 preamble 这种新行为 - 模型会先说一句 “让我查一下”，然后真的去调工具，调完再讲结果。
听上去是细节，做过 voice 项目的人会知道这是关键的体验改造。语音对话最怕的是 awkward silence - 用户问一个复杂问题，模型背后在调工具，前端两秒钟没声音。Preamble 把这个空隙填了，保持对话节奏的同时给后台留时间。再加上 parallel tool calls 是 native 支持的，多步骤的复杂请求一次会话就能走通。
数字层面：
Big Bench Audio 比 v1.5 高 15.2 个百分点（high reasoning） Audio MultiChallenge 高 13.8（xhigh，instruction following） 价格 64 per 1M audio tokens（cached input 只要 $0.40）
15 个百分点的 audio 推理提升不是小数字 - 它跨过了一些任务从 “勉强能用” 到 “可以发版” 的临界线。
Translate 和 Whisper
另外两个模型瞄准两个早就该工业化的场景。
GPT-Realtime-Translate 做实时同传，70+ 输入语种，13 输出。$0.034 一分钟，约 ¥0.25 一分钟全负荷。这个价格往前看，国际客服、跨境会议、边缘场景的国际化做起来，从 “得开专项” 变成 “加个调用就行”。同传以前是 SDK 加自定义模型加专属 infra 的活，现在是个 API。
GPT-Realtime-Whisper 是流式 STT，$0.017 一分钟。意义不在 Whisper 这个名字本身 - Whisper 大家都熟 - 而在它现在跟 Realtime-2 加 Translate 共享一套 Realtime 协议栈。同一个 WebSocket 连接，同一套 SDK，同一套延迟特征。做混合场景（半 STT 半语音 agent）省一大堆胶水代码。
Voice-to-Action 才是真正的范式变化
发布最重要的一段不在模型 spec，在 customer story 里。
Zillow 用 GPT-Realtime-2 做了一个语音助手，用户可以说 “在我能买得起的范围里找房，避开闹市，周六约个看房” - 模型听懂、推理、调工具、完成预约。Zillow 公布的数字是：通话成功率从 69% 涨到 95%，提升 26 个百分点。
这不是 “chatbot 加上语音”。这是 voice-to-action - 用户用语音描述意图，agent 自己拆解、规划、调工具、完成事务。三件事在一个对话里走通。
其他案例形状一致：Healthify 让 AI 营养师 Ria 跟用户对话，复杂问题转人工 dietitian；Genspark 用 mini 版做双语翻译加意图分流；两家牙医诊所做预约和改约。共同特征是：
多步骤 调外部工具或系统 完成事务而不只是回答问题
ChatBot 时代的语音是 “用户说话 - 模型回话”。Voice agent 时代是 “用户说话 - 模型理解加决策加调工具加反馈”。这两件事看起来差不多，工程难度差一个数量级。
你的应用如果还停在第一种，过去一年的 voice 投入大概率没有产出业务价值。Zillow 95% vs 69% 这 26 个点的差距，几乎完全来自第二种。
那篇被埋掉的 WebRTC 重写
最低调的发布是那篇基础设施 post，但即便你不做语音也值得看一眼。它讲的是 OpenAI 怎么把语音服务做到 9 亿周活全球低延迟。
大部分 builder 不会自己重写 WebRTC。但这篇文章值得读，因为它揭示了 voice 工程的真正难点 - 不是模型，是分布式系统。
OpenAI 的解法叫 split relay 加 transceiver。简单说：
relay 是轻量 UDP 转发层，公开端口少，只读 STUN 元数据决定路由，不解密媒体不管 WebRTC 状态 transceiver 是有状态的 WebRTC 端点，处理握手、ICE、DTLS、SRTP、会话生命周期 路由信息塞在 ICE ufrag 里 - 客户端首次 STUN 请求带 ufrag，relay 解析它直接转给对应的 transceiver
为什么这么设计？传统 WebRTC 一会话一端口的模式不适合云原生 - 几千个 UDP 端口暴露给公网是运维灾难。Split 之后，relay 是 stateless 浅层服务可以 Kubernetes 化横向扩展，transceiver 有状态但端口集中。Cloudflare 的 geo steering 让信令第一跳就近落地，整体延迟稳定。
这套架构的意义不限于 OpenAI 自己。它在告诉所有正在做实时语音的 team：你需要的不是更聪明的模型，是一套像 OpenAI 这样的传输栈。如果你正在自己搭，从他们这篇文章能少走半年弯路。
如果你直接用 OpenAI 的 Realtime API，那就是在享受这套基础设施的成果 - 它是为什么用户说 “感觉延迟比之前低了” 的实际原因。
几条该重新评估的判断
Voice 不再是 demo 阶段的技术。 95% 的通话成功率说明可以承担真实业务，是时候把 voice 推到生产环境。
做语音应用，先想 voice-to-action 而不是 voice-chatbot。 用户用语音不是为了跟 AI 闲聊，是要它做事。能完成事务的产品和能聊天的产品，留存差异是数量级的。
Tool calling 是核心能力，不是加分项。 Realtime-2 把 parallel tool calls 提到前台，preamble 让等待时间不尴尬。如果你的语音 agent 还没接外部工具，这是该补的功课。
国际化的成本下来了。 Translate $0.034/min 把同传从专项变成一个 API call。如果你的产品有海外用户，多语种路径里少了一段重投入。
别自己 reinvent 传输栈。 直接用 Realtime API。他们已经替你跑通了 9 亿周活规模的延迟工程，这是 startup 几乎不可能复刻的优势。
