500毫秒，這是人類對話中"自然感"的生死線。超過它，你會感覺對面是個機器人；低于它，用戶幾乎察覺不到延遲。谷歌Gemini 2.5 Flash Live API把語音交互壓進了這個區(qū)間，但一位開發(fā)者花了500多場真實對話才發(fā)現(xiàn)——真正的殺手不是推理速度，是回聲。

GoNoGo.team的創(chuàng)始人最初以為最難的是多智能體編排、40多個函數(shù)調(diào)用工具。結(jié)果上線后，AI面試代理頻繁打斷自己說話，像個人在空曠房間里聽到回音后愣住。問題的根源：瀏覽器自帶的回聲消除（Acoustic Echo Cancellation，AEC）在新型語音架構(gòu)里完全失效。

為什么傳統(tǒng)方案會"失明"

傳統(tǒng)語音AI走"語音→文字→語音"的拼接路線，延遲通常在1-3秒。Gemini Flash Live API是原生語音到語音（speech-to-speech），音頻進、音頻出，沒有中間文本層。這意味著客戶端處理的是原始PCM數(shù)據(jù)：16kHz麥克風(fēng)輸入，24kHz代理語音輸出，Base64編碼后走WebSocket傳輸。

瀏覽器端的AEC有個底層假設(shè)——"遠端音頻"必須通過``元素或Web Audio API播放，這樣瀏覽器才能追蹤參考信號。但GoNoGo的實現(xiàn)是手動解碼WebSocket傳來的24kHz PCM塊，用AudioContext緩沖區(qū)調(diào)度播放。瀏覽器看不到這個音頻流，自然無法消除它。

后果很荒誕：AI開口說話，筆記本揚聲器出聲，麥克風(fēng)收進去，AI以為用戶在打斷自己。最優(yōu)情況是它重復(fù)半句話；最差情況——作者說" constantly happened"——對話徹底崩掉。

500場對話磨出的野路子方案

開發(fā)者試過讓AI忽略自己的聲音，但語音活動檢測（Voice Activity Detection，VAD）閾值調(diào)再高也攔不住物理層面的聲波耦合。最終方案是在客戶端建立"自引用消除"：把即將播放的音頻幀緩存為參考信號，與麥克風(fēng)輸入做實時對齊抵消。

這相當于在瀏覽器里重寫半個AEC。對齊精度要控制在樣本級別——24kHz意味著每幀約21微秒的偏差都會漏出殘差。作者用512樣本塊（約32毫秒）處理，RMS能量檢測閾值設(shè)在0.05，低于此值直接丟棄。

更麻煩的是采樣率不匹配。輸入16kHz，輸出24kHz，重采樣本身引入延遲。GoNoGo的做法是統(tǒng)一在客戶端升到48kHz處理，再降回各自目標，把額外開銷壓到10毫秒以內(nèi)。

被忽視的工程暗角

這個案例暴露了一個行業(yè)盲區(qū)：當語音AI從"文本中介"轉(zhuǎn)向"端到端音頻"，大量瀏覽器層面的音頻基礎(chǔ)設(shè)施需要重建。AEC、噪聲抑制、自動增益控制（AGC）這些曾經(jīng)開箱即用的功能，在WebSocket+手動解碼的架構(gòu)里全部需要自研。

作者提到一個細節(jié)：測試時發(fā)現(xiàn)某些筆記本的揚聲器-麥克風(fēng)物理隔離太差，即使軟件層面完美消除，機械振動仍會漏音。最終被迫在檢測到AI說話時，動態(tài)壓低麥克風(fēng)增益——用信噪比換穩(wěn)定性，這是硬件層面的妥協(xié)。

500毫秒延遲的目標達成了，但代價是團隊把一半精力花在"讓AI聽不到自己"這種基礎(chǔ)問題上。語音AI的競賽正在從模型能力轉(zhuǎn)向工程整合——誰能把端到端延遲、回聲消除、網(wǎng)絡(luò)抖動緩沖這些臟活累活打包好，誰才能讓用戶覺得"對面像個真人"。

GoNoGo現(xiàn)在每天處理數(shù)百場創(chuàng)始人面試，回聲問題基本解決。但作者留下一個未回答的疑問：當多模態(tài)模型開始同時處理語音、視覺、實時環(huán)境音，現(xiàn)有的音頻處理棧還有多少能復(fù)用？下一代開發(fā)者會不會在同樣的坑里再栽一次？