Voice Agent 不只是低延遲：OpenAI WebRTC 架構與「LLM 需要完整輸入」的張力

這篇 Threads 的重點是對 OpenAI voice agent WebRTC 架構的一個反向批評：前 Twitch / Discord 的 WebRTC 專家認為，OpenAI 為 voice agent 重寫 WebRTC，可能從根本上就是錯的方向。

背景是 OpenAI 近期公開了他們如何重構 WebRTC stack，以支撐 ChatGPT Voice / Realtime API 這類低延遲 voice AI。官方敘事裡的技術點包含：Pion + Go、Kubernetes、relay + transceiver split、用 ICE ufrag 做 first-packet routing、SO_REUSEPORT、Go OS thread pinning、pre-allocated buffers 等。這套架構目標是讓即時語音對話在全球規模下更低延遲、更穩定。

Threads 作者轉述的批評點是：WebRTC 的設計初衷是視訊 / 語音通話。通話場景裡，網路差時可以丟包，因為人類通常寧願聲音偶爾破一下，也不要整通電話延遲太高。WebRTC 的取捨是保即時性、低 latency、可容忍部分品質下降。

但 LLM voice agent 的輸入不是一般人類通話。對模型來說，語音內容會被轉成 transcript / prompt，再進入推理流程。這時候「漏字」和「誤聽」不是單純音質問題，而是 prompt corruption：

• 少聽一個否定詞，意思可能完全相反。 • 漏掉數字、日期、金額，任務結果會錯。 • 指令被截斷，agent 可能執行錯操作。 • 沒有完整 transcript，就很難審計與回放。

所以這個批評的核心句是：使用者可能寧願多等 200ms，也不要 prompt 漏字。

這個觀點值得收進 KB，因為它把 voice agent 的問題從「低延遲語音串流」拉回到「可靠的人機任務介面」。如果只是閒聊，WebRTC 的低延遲優先很合理；但如果 voice agent 要訂票、填表、交易、操作企業系統、控制設備或處理客服工單，正確性、可確認性與可追溯性會比極限低延遲更重要。

我查到的外部資料顯示，OpenAI 官方文章確實是在解決大規模低延遲 WebRTC ingress 的工程問題：傳統 one-port-per-session media termination 不適合 OpenAI 的 Kubernetes / autoscaling / security model；stateful ICE / DTLS sessions 需要穩定 ownership；global routing 需要在第一個封包就知道該送到哪個 transceiver。OpenAI 採用的是 thin UDP relay + stateful Go/Pion transceiver 的 split architecture，用 ICE ufrag 帶 routing metadata，讓 relay 在不查外部服務的情況下轉送第一個 STUN binding。

這套設計在 OpenAI 規模下合理：900M weekly active users 的產品，必須處理全球入口、連線建立、turn-taking、barge-in、packet routing 與成本。但這不等於所有 voice agent 都該照抄 WebRTC stack，也不等於「線路低延遲」就是 voice agent 的主要瓶頸。

另一篇對 OpenAI 文章的分析指出，OpenAI 的 4000 字低延遲工程文章幾乎沒有提供明確 p50 / p99 / jitter / setup time / before-after millisecond 數字。這很有訊號意義：對一般 builder 來說，真正該追問的不是架構圖看起來多厲害，而是端到端指標。

Voice agent 平台選型應該看這幾個數字：

p50 / p99 end-to-end latency

不是只看 network latency，而是從使用者說完，到 ASR、LLM、TTS、播放開始的整體延遲。

TTFT / time-to-first-token

語音 AI 的感覺常常卡在模型開始回應的時間，而不是 UDP relay 少了幾毫秒。

VAD / barge-in budget

Voice activity detection 判斷使用者是否講完，以及使用者打斷 agent 時是否能立刻停下。VAD 200ms 的錯誤感受，可能比網路 200ms 更糟。

Packet loss 下的表現

在 2% packet loss、行動網路、Wi-Fi 抖動、背景噪音下，transcript 是否完整？是否會漏掉關鍵字？是否能回補、要求確認或標記不確定？

Transcript correctness / auditability

如果 voice agent 要做任務，必須保留文字紀錄、信心分數、關鍵欄位確認、可回放 trace，而不是只追求聽起來順。

Failure mode

網路差、ASR 不確定、模型聽不懂、工具呼叫前，系統要不要確認？什麼情況可以自動執行？什麼情況必須要求使用者重說？

所以比較好的結論不是「WebRTC 錯了」或「OpenAI 錯了」，而是：WebRTC 解決的是 real-time media transport；voice agent 產品真正要解的是低延遲、正確性、可確認性與任務安全之間的取捨。