OpenRocky 如何选择 Realtime Voice API的，四大厂商开发体验对比
菜之又菜约 11 分钟在开发 Rocky（一个 Voice-First 的 iPhone AI Agent）时，先后接入了 OpenAI、Google Gemini、智谱 GLM、豆包（火山引擎）四家的 Realtime Voice API，但是最后只保留了 OpenAI 和智谱的 GLM。这篇文章记录我们的真实接入体验，包括踩过的坑、最终效果、以及对国内开发者的建议。
当然，这篇文章也只是我们个人开发测试的结果。由于能力有限，可能存在不准确的情况。如果有错误，敬请指正。
什么是 Realtime Voice API？
传统的语音助手流程是这样的：
用户说话 → ASR 转文字 → LLM 生成文字回复 → TTS 合成语音 → 播放
这种"拼接式"流程延迟高（通常 2-5 秒），而且语音不自然 —— 因为 TTS 只是在"朗读"文字，没有语气、情感和上下文感知。
Realtime Voice API 则是端到端（End-to-End）的：
用户说话 → 模型直接生成语音回复 → 播放
模型同时理解语音和生成语音，延迟低（通常 < 1 秒），语气自然，还能被打断。OpenAI 在 2024 年推出的 GPT-4o Realtime API 开创了这条路，之后 Google、智谱等陆续跟进。
对比总览
OpenAI —— 标杆，但有门槛
背景
https://developers.openai.com/api/docs/guides/realtime
OpenAI 于 2024 年 10 月推出 Realtime API，是行业内第一个可用的端到端实时语音 API。基于 GPT-4o 模型，支持语音输入、语音输出、文字输出、Tool Calling，协议基于 WebSocket。
接入体验
一句话总结：让 AI 写代码，几次就搞定了。
OpenAI 的 Realtime API 文档清晰、协议设计合理、SDK 成熟（SwiftOpenAI 原生支持）。我们用 Claude Code 开发，基本是描述需求 → AI 写代码 → 一次跑通。整个接入过程不超过几句话。
Server VAD（服务端语音活动检测）工作正常 —— 用户说话时自动检测开始和结束，不需要客户端做任何额外处理。Tool Calling 直接在 Realtime Session 内完成，可以在对话中调用 iOS 原生功能（查天气、建日历、读联系人等）。
优势
最成熟稳定，基本没有坑 文档和 SDK 质量高，AI 辅助开发体验极好 Server VAD 可靠，Tool Calling 原生支持
劣势
需要翻墙，国内直连不了 价格较贵（Realtime Mini 也不便宜） 中文语音质量不如国产模型
Google Gemini —— 能力强，但不稳定
背景
https://ai.google.dev/gemini-api/docs/live-api
Google 在 2025 年推出 Gemini Live API（也叫 Native Audio），基于 Gemini 2.5 系列模型。支持多模态输入（音频 + 视频），价格比 OpenAI 低不少，也支持 Tool Calling。
接入体验
Gemini 的 WebSocket 协议和 OpenAI 不同，但整体思路类似。接入难度中等，主要挑战在于 Google 的 API 版本和 URL 格式经常变动。
但稳定性是最大的问题 —— 我们在实际测试中经常遇到 WebSocket 连接失败。错误信息通常是 "Socket is not connected"，TCP 层面就被拒绝了。这可能与 IPv6 路由、网络环境有关。
优势
模型能力强，支持 Native Audio + 视频 价格相对便宜 Tool Calling 原生支持
劣势
需要翻墙 连接稳定性不够 API 格式变动较频繁
GLM（智谱）—— 国内唯一的真正 Realtime Voice
背景
https://docs.bigmodel.cn/cn/guide/models/sound-and-video/glm-realtime
智谱 AI 是国内少数提供真正 End-to-End Realtime Voice API 的厂商。基于 GLM-Realtime 模型，支持实时语音交互、Tool Calling、多种中文音色。WebSocket 协议设计参考了 OpenAI 的模式，但有不少自己的特色（和坑）。
接入体验
一句话总结：能跑通，但过程艰辛。对，虽然能跑通，其实大家如果使用现在最新的 OpenRocky 的话，会发现每次回答前面都会出现两声“滴滴”的声音。
这两声“滴滴”声看起来挺简单，但模型始终去不掉。有时也可以去掉，但去掉后又会引入其他的问题，所以目前这个问题还没有彻底解决。如果你知道如何彻底解决，也非常欢迎，希望能告诉我。
这是我们接入时间最长的一个 Provider，前后废了非常多的口舌和测试自己打日志给AI看。和 OpenAI 的"几次就搞定"形成鲜明对比。主要原因：
1. 文档和 SDK 不完善
虽然有这两个 SDK 的 demo（包括 Python、Golang、TypeScript 以及前端的代码），但对于客户端开发来说，感觉还是有所缺失。再加上让 Codex 和 Claude Code 去参考这些代码进行开发，其中依然会存在一些坑。比如说 AI 仍然很难做到一次性搞定或者几次搞定，仍然需要不断地加日志调试，最后才能够开发完成。
GLM 的 Realtime API 文档缺少关键细节。比如 session.update 必须包含 beta_fields（含 chat_mode、tts_source、auto_search），但文档没有明确说明这是必填字段。没有 beta_fields，服务端会直接断开 WebSocket 连接，且没有任何错误提示。
我们最终是通过阅读智谱开源的前端 Demo（realtime-front）源码，才发现这个关键参数。
2. Server VAD 不可用
OpenAI 和 Gemini 的 Server VAD 工作正常 —— 服务端自动检测用户说话的开始和结束，然后生成回复。但 GLM 的 Server VAD 只能检测到 speech_started，永远不会触发 speech_stopped，导致模型不会生成回复。
我们不得不改用 Client VAD（客户端语音活动检测），自己在 iOS 端用 RMS 能量检测来判断用户是否停止说话，然后手动 commit 音频 + 发送 response.create。
3. 音频格式有坑
GLM 的前端 Demo 使用 16kHz 采样率录音。我们的 iOS App 录音是 24kHz（和 OpenAI 一致）。直接发 24kHz 的 PCM 数据给 GLM，Server VAD 能检测到语音但模型无法理解内容。最终需要在发送前做 24kHz → 16kHz 降采样，并包装为 WAV 格式。 输出音频是 24kHz PCM16，倒是和 OpenAI 一致，可以直接播放。
4. Tool 参数验证极其严格
GLM 对 Tool 定义的参数校验比 OpenAI 严格得多：
properties和 required字段不能是 null，也不能是空对象{}/ 空数组[]（服务端内部会把空值转为 null，然后 422）。不支持 tool_choice参数。工具数量不能太多（超过 10 个左右 response 会卡死不返回）。
最终的 workaround：给没有参数的工具添加 _placeholder 占位属性，限制发送 10 个工具。
5. AI 辅助开发体验差
由于文档不完善，Claude / Codex 在写 GLM 相关代码时经常"猜错"。很多问题需要人工阅读前端 Demo 源码、用 Python 脚本手动测试 WebSocket、逐步排查才能定位。整个过程和 OpenAI 的"一次搞定"形成鲜明对比。
这也反映了一个更深层的问题：AI 辅助开发的质量很大程度上取决于目标平台的文档和 SDK 质量。OpenAI 的文档好，AI 就能写出正确的代码；GLM 的文档有缺失，AI 就会反复试错。
优势
- 国内唯一
可直连的真正 E2E Realtime Voice API 中文语音质量优秀，7 种音色可选 价格便宜（Flash 版 ¥0.18/分钟） 支持 Tool Calling（虽然有限制） 支持自动问候语（ greeting_config）
劣势
文档不完善，关键参数需要看源码才知道 Server VAD 不可用（speech_stopped 永远不触发） 空 Tool 参数服务端处理有 bug 工具数量限制（超过约 10 个会导致 response 卡死） 每次回复音频前有一小段 TTS 前导噪音 AI 辅助开发体验较差
豆包（火山引擎）—— 不是真正的 Realtime
背景
https://console.volcengine.com/speech/service/10017
https://seed.bytedance.com/en/realtime_voice
我发现豆包虽然在 2025 年 1 月就发表了这样的论文，但是从 API 的开发体验上来看并不是特别好，尤其是文档，也是上个世纪的那种文档。
https://seed.bytedance.com/zh/seeduplex
当时也说是升级到了这个模型，但是好像不给用，没有办法开发，只是豆包自己在用。
字节跳动的豆包是国内最受欢迎的 AI 应用之一，语音对话体验在 App 端做得很好。火山引擎也提供了 Realtime Voice API（基于 doubao-e2e-voice 模型）。
接入体验
https://www.volcengine.com/docs/6561/1597643?lang=zh
然而，深入看代码就会发现，豆包的"Realtime Voice"并不是真正的端到端：
用户说话 → ASR 转文字 → 对话模型生成文字 → TTS 合成语音 → 播放
它本质上是把 ASR + LLM + TTS 三个步骤串联起来，通过 WebSocket 流式传输。虽然感知上延迟不高，但这不是 OpenAI / Gemini / GLM 那种"模型直接理解和生成语音"的方式。
更关键的是，Tool Calling 不在 Realtime Session 内 —— sendToolOutput() 是空实现。如果需要在对话中调用工具，需要走单独的 Chat API，这在语音交互场景下体验不好。
接入复杂度也不低：需要分别配置 appId、appKey、resourceId 三个凭证，比其他三家都麻烦。文档也是上个世纪的风格。
优势
国内可直连 中文语音质量好 豆包 App 本身的语音体验很好
劣势
不是真正的 E2E Realtime Voice Tool Calling 不在 Realtime Session 内 接入需要多个凭证
补充
公平地说，豆包 App 的语音对话体验确实不错，可能是字节在 App 层面做了很多优化。但从 API 层面看，目前开放的能力和 OpenAI / GLM 的真正 Realtime 还是有本质区别。也有可能是我们没有找到更好的接入方式。
不管怎么样吧，豆包这个看起来并不是一个实时的，并不是真正的端到端。而且它也不支持 Tool Call，反正 Codex 和 Claude Code 是没搞定。因为不是一个实时的，不支持 Function Calling，这样其实效果会大打折扣。
国内其他厂商呢？
https://help.aliyun.com/zh/model-studio/realtime
我们也测试过阿里的 Realtime Voice API。各厂商在宣传上都说得不错，但实际接入体验差距很大。主要是我和克拉特聊了非常久，经过各种测试，始终不能把阿里的这个 RTC One Click 调试通过，也可能是个人能力问题。
文档不完善，关键参数缺失 示例代码跑不通，或者只有 Python 版本 错误提示不清晰，很难定位问题 AI 辅助开发基本不可能（因为 AI 也没见过这些 API 的正确用法）
最终结论：在国内，智谱 GLM 是目前唯一一个我们成功跑通了真正 E2E Realtime Voice + Tool Calling 的 API。
给开发者的建议
如果你在海外或有稳定的翻墙环境
首选 OpenAI Realtime API。最成熟、最稳定、文档最好、AI 辅助开发体验最佳。如果预算有限，可以考虑 Gemini。
如果你面向国内用户
GLM 是目前的唯一选择（应该也有其他的，但是我没找到可用的）。虽然接入过程比 OpenAI 复杂不少，但跑通之后效果还可以。这篇文章记录的所有坑我们都已经在 OpenRocky 项目中解决了，你可以直接参考代码。当然，这个 GLM 还是有一些 bug 没特地解决。
关于 AI 辅助开发
这次接入体验让我们深刻感受到：API 的文档质量直接决定了 AI 辅助开发的效率。
以后所有 SDK 的标准都应该做到：让 AI 参考 SDK 文档或者是 Demo，能够一次性看懂并完成接入。这其实就是我觉得的新时代 SDK 的一个文档标准。
OpenAI：让 Claude 写代码，几次就搞定 → 半天完成 GLM：Claude 反复试错，大量需要人工测试辅助和阅读源码 → 一整天
如果你是 API 提供方，想让开发者（和他们的 AI 助手）快速接入，请：
写清楚必填参数和可选参数 提供完整的请求/响应示例 错误时返回清晰的错误信息（而不是静默断开连接） 保持 SDK 和文档与 API 同步更新
总结：OpenRocky 的最终选型
经过对四家厂商的完整接入和测试，我们在 OpenRocky 中做出了一个清晰的选择：只保留 OpenAI 和 GLM，移除 Gemini 和豆包。
移除 Gemini 的原因：连接不稳定，WebSocket 经常 "Socket is not connected"，在实际使用中体验不可靠。移除豆包的原因：不是真正的 E2E Realtime Voice，Tool Calling 也不在 Realtime Session 内。
这样做的好处是：海外用户用 OpenAI，体验最好；国内用户用 GLM，不需要翻墙。 两条路线覆盖了绝大多数用户场景，架构也更简洁。
选型的评估过程
我们的评估标准很简单，就三条：
- 是不是真正的 E2E？
—— 模型直接理解和生成语音，而不是 ASR+LLM+TTS 拼接。这决定了延迟和语音自然度的上限。 - 能不能在语音中调用 Tool？
—— Rocky 是一个 Agent，用户说"帮我查一下明天的天气"，需要在对话中直接调用 iOS 的天气 API，而不是让用户切到文字模式。 - 能不能稳定工作？
—— 演示能跑通不算数，日常使用不能三天两头连不上。
用这三条标准筛下来，只有 OpenAI 和 GLM 同时满足。
接入难度的真实差距
最后想说一个可能对开发者最有参考价值的点：AI 辅助开发的效率，几乎完全取决于目标 API 的文档质量。
OpenAI 的文档、SDK、错误提示都很完善，AI 读了文档就能写出正确的代码。GLM 的文档有关键信息缺失（比如 beta_fields 是必填的、Server VAD 不可用、空参数会 422），AI 只能反复试错，很多问题最终靠人工阅读官方 Demo 源码才解决。
这也给 API 厂商提了一个建议：在 AI 编程时代，文档质量不仅是开发者体验问题，更是 AI 能不能帮开发者用上你的 API 的问题。 文档好，开发者让 AI 一个小时就能接入；文档差，开发者自己调一天也不一定搞得定。
Realtime Voice API 是一个很新的领域，各家都在快速迭代。我们在 OpenRocky 项目中完整实现了 OpenAI 和 GLM 的 Realtime Voice Client，代码完全开源，希望能帮到有同样需求的开发者。
GitHub: github.com/openrocky/openrocky 官网: openrocky.org
最后还是要再说一遍，这也只是我个人测试的结果，当然也是在个人让 PowerCode 以及 Codex 测试的结果。
这并不一定代表模型厂商最新的真实情况，可能存在不准确的情况，如果大家发现有误，请尽情指正。