新上线昨天178 投票
OpenAI 的 WebRTC 困境：为什么语音 AI 不该盲目跟随
核心观点：WebRTC 并非语音 AI 的最佳选择
一位曾在 Twitch 和 Discord 重写 WebRTC 的资深工程师，在看到 OpenAI 的技术博客后忍不住发声：别学 OpenAI，别在语音 AI 中用 WebRTC。
为什么 WebRTC 不适合语音 AI？
WebRTC 最初为实时音视频会议设计，核心目标是低延迟、即时交互。为此，它会在网络不佳时主动丢弃音频包，甚至禁止重传。这在人类对话中尚可接受——听不清可以让对方重复，但对 AI 语音交互是灾难：
- 用户要求精准：一个“开车还是走路去洗车”的指令，如果因丢包变成“开车还是走路”，AI 可能给出错误回答。用户宁愿多等 200ms，也不愿得到错误结果。
- 无法重传：浏览器中的 WebRTC 实现甚至不允许音频 NACK（否定确认重传），工程师尝试通过 SDP 修改开启未果。
- 抖动缓冲过小：为保持低延迟，WebRTC 的抖动缓冲会丢弃迟到的包，这在 AI 场景中意味着输入不完整。
WebRTC 的技术债
WebRTC 涉及约 45 个 RFC（部分可追溯到 2000 年代初），外加一些仍为草案的事实标准（如 TWCC、REMB）。实现完整栈极其复杂，甚至作者本人——这位“认证 WebRTC 专家”——都表示再也不想碰它。
对 OpenAI 的反思
OpenAI 选用 WebRTC 可能出于浏览器兼容性和实时性的考虑，但作者认为这属于路径依赖。语音 AI 需要的是可靠传输而非激进降质，更合适的方案可能是自定义协议或基于 QUIC 的传输。
作者感叹：“你注意到趋势了吗？每次我都要重写 WebRTC，因为原生实现根本无法满足需求。”
行业启示
- 不要盲目复制大厂：OpenAI 的选择未必最优，尤其在底层技术选型上。
- 场景决定协议：语音 AI 的交互模式（长指令、高精度要求）与传统会议完全不同，需要重新审视传输需求。
- WebRTC 的未来：或许需要推出“语音 AI 模式”，允许更宽松的延迟预算和丢包重传。
小结
WebRTC 成就了实时通信，却可能成为语音 AI 的绊脚石。当“实时”不再是最高优先级，“准确”才是，我们是否该重新定义传输协议？
