当WebRTC的“低延迟”执念，遇上AI语音交互的“准确性”刚需
WebRTC为保持低延迟而丢包的机制，与AI语音交互中用户宁愿等待也要保证提示词准确的核心需求产生了根本性冲突。
核心要点
- WebRTC的核心设计哲学是“宁可丢包，不可延迟”，以保证实时通话的流畅感。
- AI语音交互中，用户发送的提示词（prompt）是昂贵且关键的，准确性远比几百毫秒的延迟重要。
- 当前浏览器中WebRTC的实现是硬编码的，无法为AI场景进行重传等可靠性优化。
- 这揭示了将传统实时通信技术直接套用于AI原生应用时可能存在的“水土不服”。
深度解读
起因：一个来自OpenAI工程师的“抱怨”
事情的起因是OpenAI的工程师Luke Curley在讨论公司如何大规模交付低延迟语音AI时，抛出了一个尖锐的“wtf”。他指出，WebRTC这个为实时音视频通话设计的协议，其核心行为——在网络不佳时主动丢弃音频包以保持低延迟——与AI语音交互的需求背道而驰。对于支付了不菲费用、希望用复杂提示词“煮沸海洋”（boil the ocean，意指处理复杂任务）的用户来说，宁可多等200毫秒，也要确保发送给AI的每一个字都准确无误。然而，WebRTC的浏览器实现是硬编码的，连重传一个丢弃的数据包都做不到。这并非技术能力问题，而是底层设计哲学的根本冲突。
拆解：两种“时间观”的碰撞
要理解这个矛盾，我们需要拆解两种截然不同的“时间观”。
对于传统实时通话（如Zoom、腾讯会议），用户体验的黄金标准是“即时性”。对话的节奏、打断和情绪的传递都依赖于极低的延迟。偶尔的音频失真或丢字，只要对话能继续，用户通常可以忍受。WebRTC正是为此而生，它的“激进丢包”策略就像一个果断的交通调度员，宁可让几辆车（数据包）消失，也要保证主干道（对话流）的绝对畅通。
但对于AI语音交互，场景变了。用户不是在和另一个人进行快速来回的对话，而是在向一个“超级大脑”提交一份可能包含复杂指令、长上下文或关键信息的“查询订单”。这份订单（即prompt）的质量直接决定了AI回复的质量。在这里，准确性压倒了即时性。用户心理模型是“我发起请求 -> 等待 -> 获得高质量回复”。中间那段等待时间，只要不是长得离谱，用户是完全接受且有预期的。Luke的吐槽精准地抓住了这一点：AI本来就不怎么“即时”，你WebRTC瞎操什么心？
趋势洞察：AI原生应用需要“协议级”的重新思考
这件事绝不仅仅是一个技术选型的小插曲。它揭示了一个更深层的趋势：当我们把AI作为核心引擎构建应用时，许多为“前AI时代”设计的技术栈和协议都需要被重新审视。
我们正在从“连接人与人”（实时通信）的时代，迈向“连接人与AI”（智能交互）的时代。后者的通信模式可能更像是一种“异步的、可靠的、高保真的请求-响应”模式，而不是纯粹的“实时流”。这可能意味着：
- 需要新的传输协议或扩展：业界可能需要为AI语音/视频输入专门设计或扩展协议，在保持可接受延迟（比如500毫秒内）的前提下，优先保证数据的完整性和准确性，支持智能重传和纠错。
- 边缘计算与智能缓冲：在客户端或边缘节点对用户的语音输入进行更智能的缓冲和预处理，确保在发送到云端大模型之前，数据包是完整、有序的。
- 应用层补偿：在现有协议限制下，应用开发者可能需要设计更巧妙的方案，比如在检测到网络波动时，主动提示用户“正在确保您的指令完整送达”，甚至允许用户手动选择“优先保证准确”或“优先保证速度”的模式。
实用价值与反常识
对于正在开发AI语音功能或智能体（Agent）的团队，这是一个重要的警示：不要想当然地认为最适合“实时”的技术就最适合“AI实时”。 在技术选型时，必须深入理解AI交互的本质需求。直接套用WebRTC可能会在底层就埋下用户体验的隐患。
而这件事最反常识的一点在于：我们通常认为“快”就是好，但在AI交互的特定环节，“准”比“快”重要得多。这迫使我们去重新定义什么是AI时代的“好”的通信体验——它可能不再是毫秒级的延迟竞赛，而是在用户可接受的延迟范围内，实现100%的意图保真传输。Luke的抱怨，或许正是吹响了这场协议层变革的第一声号角。
原文地址: Quoting Luke Curley