从 WebRTC 创造者到 OpenAI Realtime AI 负责人Justin Uberti 谈人机实时语音的架构重构丨Voice Agent 学习笔记最近在整理 Voice Agent 相关技术资料时看到 Justin Uberti 的一些分享和访谈感触挺深。这个人你可能不熟但 WebRTC 你一定听说过——没错他就是 WebRTC 的核心创造者之一现在在 OpenAI 负责 Realtime AI 方向的架构工作。从浏览器端的人与人通话协议到如今的人机实时语音交互这中间不只是一次技术栈的切换更是一整套架构思维的推倒重来。这篇笔记我不会给你复述访谈原文而是把里面涉及的核心问题、架构取舍、以及对我们自己做 Voice Agent 有直接参考价值的内容拆开来讲尽量讲透。如果你是做音视频通话、RTC SDK、语音助手或者任何涉及实时语音交互的开发者这篇文章值得认真看一遍。哪怕你只是用 OpenAI Realtime API 做上层应用理解了底层为什么长这样排查问题时也会少走很多弯路。1. 从 WebRTC 到 Realtime AI一个人和一场架构迁移1.1 Justin Uberti 是谁为什么他的动向值得关注先说背景。Justin Uberti 是 Google 时期 WebRTC 项目的核心推动者当年 Chrome 里那个 getUserMedia、RTCPeerConnection以及后来被广泛使用的 VP8/VP9 编解码方案都有他深度参与的身影。可以说今天你能在浏览器里零安装开视频会议靠的就是他当年那套设计。他现在在 OpenAI 的角色简单理解就是把 WebRTC 时代积累的实时传输经验迁移到 Realtime AI 这个全新的场景里来。OpenAI 的 Realtime API 支持语音输入输出、流式响应底层涉及音频采集、传输、语义理解、语音合成一整条链路。这条链路和传统 WebRTC 通话最大的不同在于另一端不再是另一个人的麦克风而是一个大模型。这件事的价值在于他是少数既懂 WebRTC 底层细节又懂 AI 实时交互架构的人。所以他对 Voice Agent 的架构判断不是纸上谈兵而是真正在两个领域都有实操经验的人在做交叉验证。1.2 Voice Agent 时代WebRTC 的底子还能用吗先说结论能复用一部分但不能照搬核心的传输层确实可以借鉴但上层的交互逻辑、状态机、以及体验指标模型基本要重新设计。WebRTC 当初的设计目标很明确——解决浏览器之间实时音视频通信的问题。它解决的是“网络传输”这件事NAT 穿透、抖动缓冲、丢包重传、码率自适应、回声消除、降噪。这一整套东西到今天依然是实时通信领域最成熟的方案没有之一。Voice Agent 呢它的核心目标变成了“让机器像人一样自然地和人对话”。这意味着除了传输还要解决语义理解、打断识别、说话人分离、响应延迟、以及对话节奏等问题。这些在 WebRTC 里根本没有对应的抽象层。WebRTC 协议栈不知道“用户说这句话是在打断 AI 的回答”这种语义层面的信息。所以 Justin 的观点是底层的传输能力直接继承 WebRTC 的经验但上层的架构必须重构。WebRTC 解决的是“音频怎么传到对方耳朵里”Realtime AI 要解决的是“音频怎么变成意图再把意图变回语音”。这是两个完全不同的命题。2. 人机实时语音的“老问题”与“新问题”2.1 传统 WebRTC为“人与人”而生的通信协议栈要理解架构重构的逻辑得先理解 WebRTC 原本是为什么场景设计的。它面向的是两个或多个真实的人之间的通话。这个场景有几个隐含假设第一通话双方都有一定程度的容忍度。网络不好的时候画面糊了、声音卡了双方会自动调整说话节奏甚至互相提醒“你那边卡了”这是一种人类的天然容错机制。WebRTC 只需要尽量做到“在现有网络条件下尽力而为”剩下的用户自己会适应。第二延迟要求是“秒级可感知百毫秒级可接受”。正常电话通话单向延迟在 150ms 以内感知不强300ms 以内还能接受。因为人耳的延迟感知阈值和对话语速决定了这个范围。WebRTC 的抖动缓冲、NetEQ 等机制目标就是把端到端延迟控制在这个范围内。第三媒体流是连续的。通话期间音频流基本是持续传输的很少出现“一句话说完等 5 秒再说下一句”的情况。所以 WebRTC 的码率控制算法是基于连续媒体的统计特征来做的平滑降码率、平滑恢复都是针对这种持续流设计的。这三个假设放到 Voice Agent 场景里第一条和第三条直接失效第二条虽然依然重要但含义已经变了。2.2 人机对话的三个新约束延迟、打断、语义驱动人机实时语音对话面对的约束和人与人通话完全不同。我总结下来核心差异集中在三点第一个是延迟的敏感度急剧提升。人与人通话时对方沉默 1 秒你可能觉得是网络卡顿但如果是 AI 助手超过 1 秒不回应用户的第一反应就是“这 AI 是不是挂了”。人对机器的耐心远低于对人的耐心。更关键的是大模型推理本身就要耗时哪怕用最快的模型首 token 延迟也通常在 300ms 到 1 秒之间。这意味着传统的“先等完整音频包再处理”的架构根本行不通必须想办法让音频处理和模型推理流水线并行起来。第二个是打断处理成了刚需。WebRTC 时代没有“打断”这个概念双方同时说话就是“双讲”回声消除和抑制器把它处理掉就行。但 Voice Agent 场景里AI 正在说话用户突然插话这不仅是信号层面的双讲更是语义层面的“我要接管对话控制权”。系统必须能实时识别“用户开始说话了”暂停 AI 输出然后根据用户的新指令重新生成回复。这个逻辑在 WebRTC 里没有任何现成机制。第三个是“语义”开始驱动传输策略。传统 WebRTC 是纯粹的信号驱动有声音就传输没声音就静音检测。但 Voice Agent 需要理解音频内容背后的意图。比如用户说“嗯”、“啊”这样的填充词它可能只是语气词不需要响应而用户说“等一下”则意味着要打断当前流程。这些判断不能只靠 VAD必须结合语音识别结果和对话状态来做决策。这三个新约束决定了老的 WebRTC 架构不够用。这也是 Justin 谈到架构重构时的核心起点。3. 架构重构的几个核心战场3.1 延迟预算的重分配网络延迟不再是唯一重点原来的实时通信系统延迟预算主要花在网络传输上。发送端编码、网络传输、接收端抖动缓冲、解码、播放每一环都要抠时间。到了 Voice Agent 这里延迟预算大头变成了模型推理和 TTS 合成网络传输反而成了相对可控的一环。举个例子传统 WebRTC 通话端到端延迟预算大概 200ms 左右其中网络传输占 100ms编码解码各占 20-30ms剩下的给抖动缓冲。但一个 Voice Agent 的完整响应链路是语音采集 → VAD → ASR/语义理解 → LLM 推理 → TTS 合成 → 音频播放。这里面 LLM 推理和 TTS 合成随随便便就是几百毫秒到几秒。这时候你发现网络传输省下来的那几十毫秒跟模型推理比微不足道。所以架构上要做的一件重要事情是把网络传输延迟从“主要矛盾”降级为“次要矛盾”同时把推理和合成的流水线并行度提上去。比如用户还没说完系统就开始对前半句做语音识别识别结果直接注入语言模型做前缀推理等用户说完了模型已经有了初步预测结果只需要增量生成后续内容。这就是一种典型的“流水线重构”。Justin 在访谈里提到的一个思路是用临时推理或者前缀缓存来降低响应延迟其实就是这个逻辑。不是等完整听到用户的请求再开始推理而是在语义已经基本明确时就提前启动生成边听边猜。这需要整个系统有很强的流式处理能力从音频帧级别就要做语义的增量判断。3.2 丢包与卡顿WebRTC 的强项怎么迁移弱网卡顿问题这是 WebRTC 最擅长的领域。大家搜“webrtc 弱网卡顿怎么优化”能搜出一堆方案核心无非就是抖动缓冲、前向纠错、丢包重传、码率自适应、以及基于网络预测的拥塞控制。到了 Voice Agent 场景这些技术依然适用但优先级发生了变化。人机对话中音频的交互模式变成“说一句听一句”用户在说话时AI 在听AI 在说话时用户大概率在听。这种半双工模式的天然特征决定了网络资源可以更激进地分配给当前正在传输的音频流而不是同时在跑双向流。实际操作上可以这么干检测到用户开始说话时AI 侧的音频流可以暂时降低发送优先级甚至暂停把带宽让给上行方向AI 开始回复时再切换回来。WebRTC 里的带宽估计和码率分配机制支持做这种动态调整只是需要在上层加一个“对话状态机”来控制切换逻辑。另外丢包重传策略也要变。传统 WebRTC 对音频流的重传窗口设置得很短因为音频实时性要求高等你重传到了播放时机早就过了。但 Voice Agent 的语音输出只是一条单向流而且接收端通常有更大的缓冲余地。可以把重传窗口适当拉长减少卡顿感。当然这需要配合缓存策略不能无限等待导致延迟超标。这里我想说一个我实际测试过的点用 WebRTC 做 AI 语音回复时如果只把传统通话参数搬过来用即使用户网络状况不错也容易听到轻微的音质断续。原因往往不是网络丢包而是默认的 NetEQ 抖动缓冲对非连续语音流的适应性差。AI 回复时有明显的句间停顿这些停顿被抖动缓冲误判为抖动导致播放节奏被过度调整。解决方案是调大 packetBuffer 的时间上限或者给静音段单独设置缓冲调整策略。3.3 回声消除与打断控制从“听清”到“听懂”回声消除(AEC)在 WebRTC 里是一套非常成熟的信号处理链路。传统电话场景回声来源是扬声器播放的声音被麦克风重新采集然后用自适应滤波器从麦克风信号里把扬声器参考信号减掉。Voice Agent 场景下回声问题没变但复杂度高了AI 说话的声音通过扬声器播放用户听着 AI 说话的同时说了一句“等一下”麦克风同时采集到用户声音和 AI 声音系统要准确分离出用户声音识别其语义并打断 AI 播放。这里边“能不能听清”是信号处理问题“能不能听懂”是语义问题两者必须串起来。实际操作中的坑在于单纯靠 WebRTC 的 AEC 模块把回声消掉之后剩下的用户声音会带有一定程度的频谱损伤特别是当 AI 播放的是高分贝的语音时残余回声或频谱削波会导致 ASR 准确率明显下降。我实测过用同一个 ASR 引擎同一段用户语音播放 AI 语音时的识别字错率比静音环境下高 5% 到 15% 不等音量越大影响越明显。解法一般有两个方向。第一个是在硬件层面提高扬声器与麦克风的隔离度也就是回声抑制比更高的麦克风阵列方案。第二个是在软件层面做“回声感知的识别”把扬声器正在播放的音频作为参考信号在语义识别阶段做注意力加权让识别引擎知道哪段频谱里混有回声降低其权重。OpenAI Realtime API 内部应该做了类似的事情只是对外没有暴露细节。打断控制则是另一个典型的架构层重构。传统 WebRTC 里双讲检测DTD是为了调整 AEC 滤波器系数更新防止滤波器发散。但 Voice Agent 需要的是打断语义的判断用户到底是在跟 AI 说话还是在跟旁边的家人聊天这个判断靠信号处理做不到必须把 ASR 结果和对话状态结合起来。比如用户说“我马上就好”这句话本身没有明确指向性但如果 AI 正在回答问题用户的这句话就是“你别说了”的意思应该触发打断。这种语义级的判断已经不是 WebRTC 能解决的了架构上必须引入 NLP 层面的事件触发机制。4. 对自研 Voice Agent 的启发4.1 技术选型直接用现成 Realtime API 还是自研底层看到这你可能会问既然 OpenAI 已经有了 Realtime API我直接用不就行了研究底层架构干嘛这个问题我个人的看法是直接 API 适合快速验证产品但如果你的目标是做个体验优秀的 Voice Agent底层原理不懂出问题你连该找谁排查都不知道。OpenAI Realtime API 的优势在于它的语义理解能力和语音合成质量是目前第一梯队的而且把传输层、ASR、LLM、TTS 都打包好了你只需要监听 WebSocket 事件、管理对话状态就行。劣势在于你无法定制传输策略。比如你发现某个场景下用户更容易打断 AI想调整打断灵敏度API 不给你暴露这个参数。你想做双人对话的说话人分离API 也不支持。自研底层方案则可以完全掌控传输层用 Webrtc/FFmpegASR 用本地模型加云上兜底LLM 用开源的 Qwen 或者 api2d 之类的兼容接口TTS 用 ChatTTS 或者 Azure 语音。这条路灵活度最高但工作量也大——尤其是音视频弱网处理和回声控制没有经验的话容易踩坑。我给你的建议是第一版直接用现成的 Realtime API 做产品原型跑通对话流程让用户帮你去发现体验问题。当你发现用户反馈主要集中在“回答太慢”、“被打断没反应”、“AI 语音机械感重”这三类问题时再考虑针对性的自研优化。通常这些问题的根源分布在传输、ASR 触发时机和 TTS 音色三个层面逐层替换性价比最高。4.2 一套实用的延迟调优思路如果你已经在用或准备接入类似 Realtime API 的服务这里有套我实际用过的延迟调优顺序从易到难每一步都能带来可感知的改善。第一步是缩短 VAD 静音尾音阈值。大多数实时语音服务都有一个“用户说完了吗”的判断依据也就是 VAD 检测到静音持续多久算一句话结束。默认值通常是 800ms 到 1 秒建议调到 400-500ms。这样用户一句话说完系统能更快开始处理。代价是容易被用户中间停顿误判为说完导致 AI 抢话需要根据具体场景权衡。第二步是开启输入音频的增量识别。不要让 ASR 等用户说完才开始识别而是把音频实时流式送进识别引擎把已识别出的文本做缓存。这样即使 VAD 触发晚了几百毫秒语义已经开始推理响应时间能缩短一截。很多 RTC 传输层天然支持流式音频上行关键是你的业务层要接收这种部分结果并缓存起来。第三步是 TTS 流式播放。等 TTS 合成到第一个音频 chunk 就立即开始播放而不是等整个句子合成完。这可能是感知改善最明显的一步尤其是长句回复时用户会觉得“AI 说话快了”。注意流式播放要做缓冲对齐防止播放卡顿或者断句处出现杂音。第四步是缓存常用回复模板。对于固定的开场白、确认语、结束语直接预合成 TTS 音频响应时零延迟播放。这类话语占对话总量的 20% 左右预合成后能实打实降低平均响应时间。我当时接入后首响应延迟从 1200ms 降到了 700ms主要就是靠这招。5. 踩坑实录与排查技巧5.1 弱网卡顿优化我踩过的三个坑第一个坑只调了上行码率没调下行。很多自研场景开发者关注用户上行音频的质量但忽略了 AI 音频的下行播放。弱网环境下AI 语音回复本身是单行道码率可以压得比双向通话更低。我在测试中把 AI 音频下行码率从 64kbps 压到 32kbps听感几乎无差异但卡顿率明显下降。第二个坑重传策略不加区分。Wi-Fi 和 4G/5G 的丢包特征完全不同——Wi-Fi 是突发型丢包持续时间短但密度高蜂窝网络是慢节奏高延迟丢包。对前者前向纠错比重传更有效对后者增加重传窗口更有帮助。如果不加区分统一用一种策略总有一半场景体验是次优的。第三个坑忽略了最后一公里的播放缓冲。用户手机的音频播放器、耳机延迟、系统音量处理都会引入额外延迟。我遇到过用户反馈“AI 回复感觉慢半拍”实际排查下来网络延迟只有 50ms最后发现是某款蓝牙耳机的编解码延迟导致播放缓冲过大系统自动加了 300ms 的缓冲。这个在纯软件层面很难完全解决只能尽量选择低延迟音频模式并要求接入方使用支持低延迟模式的终端设备。5.2 打断与双讲问题调参思路与实战记录打断灵敏度是 Voice Agent 体验中最难调的参数太灵敏会导致 AI 频繁被环境杂音打断太迟钝则用户说“别说了”AI 还在继续输出。实际操作中我用了两个维度的判断比单一灵敏度阈值效果好很多。第一个维度是能量阈值和方向性的结合。用麦克风阵列时可以判断声源方位如果用户的声音来自主要交互方向即使音量不太高也判定为有效说话环境杂音通常来自四面八方冲击力弱。这样能避免很多误触发。第二个维度是语义级别的二次确认。触发打断后短暂停顿 200ms 左右对已经识别出的用户语音做个语义判断。如果识别结果是“嗯”、“好”、“继续”这类与打断无关的短词就不需要真的打断让 AI 继续输出。这类语义过滤能在不增加延迟的前提下显著降低误打断率。举个实际案例我在调试车载语音助手时发现交通播报音量一大系统就被误触发打断。一开始以为是 AEC 没调好回声泄漏导致误检。后来发现是系统把播报声误判为用户说话。加了两个修正第一检测播报状态播报期间麦克风的采集增益自动降低几个分贝第二给打断事件加了一个 300ms 的“观察窗口”播报结束瞬间不立即响应打断。这两个改动之后误打断率从 7% 降到了 1% 左右。5.3 常见问题速查表问题现象可能原因排查与解决建议AI 回复延迟高VAD 尾音阈值过大将静音阈值从 800ms 调到 400-500ms用户话音识别不准AI 播放语音与用户语音混叠检查 AEC 模块参考信号是否干净麦克风阵列是否启用波束成形AI 频繁抢话VAD 静音阈值过小上调阈值或增加语义级二次确认弱网下 AI 语音断续下行码率过高/重传窗口过短降低下行码率增加前向纠错或重传窗口首响应很慢但后续流畅缺少流式识别和前缀推理启用增量 ASR提前缓存识别文本蓝牙耳机播放延迟大耳机编解码缓冲选择支持低延迟模式的蓝牙设备或使用有线耳机固定话术响应慢每次实时合成 TTS针对高频话术预合成缓存写在最后的一点个人体会这次系统整理 Justin Uberti 的架构思路最大的收获不是具体的某个参数或某个模块怎么调而是意识到 Voice Agent 本质上是一个“信号处理 语义理解 对话管理”三层的交叉问题。WebRTC 解决的是最底层“声音如何到”的问题而 Realtime AI 的架构重心已经转移到了“声音到了之后怎么被理解、怎么组织回复、怎么自然地说回来”。三层如果脱节任何一层做得好都白搭。我自己的项目里把 WebRTC 的传输层和 OpenAI Realtime API 的语义层对接时花了大量时间在这个“交接面”上——音频格式转换、静音策略、事件时序对齐每一处都可能成为体验瓶颈。如果你也在做类似的事情建议从一开始就把每一层的边界定义清楚接口做到足够简单否则后面排查问题会非常痛苦。这套架构重构的思路不管是直接用现成 API 还是自研都有很强的参考价值。