Gemini 3.1 Flash Live 主打即時語音 …
Gemini 3.1 Flash Live 把低延遲語音、影像與工具呼叫塞進 Google Live API。ComplexFuncBench Audio 拿下 90.8%，很適合做即時語音代理。
Google 的 Gemini 3.1 Flash Live 很有意思。它把語音、影像、工具呼叫放進同一條即時串流。Google 也丟出一個很硬的數字：ComplexFuncBench Audio 90.8%。
講白了，這是在挑戰傳統語音管線。以前是先轉文字，再推理，再合成語音。每一步都會卡一下。現在它想把這條路縮短成一個連續流程。
對台灣開發者來說，這種模型不是拿來看 demo 而已。它影響的是客服、車載助理、門市導購，還有各種要即時回話的軟體。只要延遲太高，使用者就會直接覺得很笨。
為什麼 Google 會改語音架構
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
傳統語音系統像接力賽。先做 VAD，再做 speech-to-text，再丟給 LLM，最後再做 text-to-speech。每一段都吃時間，也都可能出錯。
Gemini Live API 的思路不同。它走 stateful WebSocket。這代表同一個 session 可以一直維持下去，不用每次都重來。
更重要的是，它直接處理音訊。Google 說這樣能更好抓到語速、停頓、音高，還有背景雜訊。這點很實際。因為真實世界不是安靜錄音間，而是捷運、辦公室、店面，甚至是工地。
- 音訊輸入：16-bit PCM、16 kHz、little-endian
- 音訊輸出：raw PCM、24 kHz
- 影像輸入：約 1 fps 的 JPEG 或 PNG frame
- 上下文長度：128k tokens
這些規格很像工程師會在意的細節，但其實就是產品能不能上線的分水嶺。16 kHz 足夠做語音理解。24 kHz 輸出也能維持基本的播報品質。對很多即時應用來說，這組設定算務實。
它還支援 barge-in。使用者可以直接打斷模型。這功能看起來小，實際上很重要。人本來就會插話，模型如果不會停，整體體驗就會很假。
Live API 才是重點
真正讓這個模型能用的，是 Multimodal Live API。它維持雙向串流。音訊、字幕、影像、工具呼叫都能在同一個 session 裡流動。
這種設計很適合 agent。因為模型可以邊聽邊想，甚至邊講邊收新指令。你不用先把整段語音轉完，再丟給另一個服務做 TTS。少一層，就少一層延遲。
Google 也提到，伺服器事件可以把多個內容片段一起送出。這對前端同步很有幫助。做過即時字幕、音訊播放、工具回應同步的人都知道，對齊這些狀態真的很煩。
“The model doesn’t just use a transcript; it processes acoustic nuances directly.”
這句話很直白。Google 想說的是，模型不是只看轉好的文字。它直接吃聲學訊號。這對吵雜環境特別有用。
另外，Google 還公開了 gemini-skills repo。裡面有針對工具鏈與 API 行為的技能包。像 gemini-live-api-dev 這類內容，會幫助工程師少踩一些版本差異的坑。
數字比空話更有用
這次最能打的不是行銷詞，是 benchmark。90.8% 的 ComplexFuncBench Audio 很醒目。它測的是從語音輸入觸發多步驟 function calling 的能力。
這代表模型不只會聊天。它還要能做事。像查訂單、開工單、查庫存、叫 API，這些都屬於 voice agent 真正會碰到的工作。
Google 也提到 36.1% 的 Audio MultiChallenge，且是在 thinking enabled 的狀態下。這個測試比較接近吵雜、打斷、指令混雜的現場情境。分數不算誇張，但至少方向對。
- ComplexFuncBench Audio：90.8%
- Audio MultiChallenge：36.1%
- Context window：128k tokens
- thinkingLevel：minimal、low、medium、high
這裡可以看出 Google 的策略。它不是只追求快。它也保留了思考深度的選項。開發者可以調 thinkingLevel，在低延遲和高推理之間切換。
我覺得這很合理。客服機器人要快。現場維修助理可能要慢一點，但要更準。把兩種需求塞在同一個模型裡，對產品團隊比較省事。
Gemini Skills 為什麼實用
Gemini Skills 這個 repo 很容易被忽略，但它其實很實際。它把最新文件與上下文整理成可注入的技能，讓 coding assistant 少靠猜。
Google 在 repo 說明裡提到，加入相關 skill 後，code-generation accuracy 可到 87%，在 Gemini 3 Flash 上是這樣；在 Gemini 3 Pro 上則到 96%。這種提升，通常不是模型本體單獨做到的，而是資料上下文整理得夠好。
這對團隊很重要。很多 API 問題不是模型不會，而是文件過期。技能包可以把 WebSocket、blob、session 這些細節固定下來。少猜一次，就少改一次 bug。
- 沒有最新上下文時，agent 容易亂猜事件格式
- 有 skill pack 時，模型比較能跟上最新 API 規則
- 對 voice team 來說，這能少掉很多 demo 翻車
- 對內部 copilot 來說，這像一層活的知識庫
這種東西不花俏，但很值錢。因為真正拖慢專案的，常常不是模型不夠強，而是工程團隊一直在補文件落差。
如果你想看更多 agent 實作脈絡，可以參考我們對 production-ready AgentScope workflows 的整理。
和其他語音模型比起來怎樣
拿這次的 Gemini 2.5 Flash Native Audio 來比，Gemini 3.1 Flash Live 的重點不是單純變大，而是更適合即時互動。它強調原生音訊處理，也更明顯把工具呼叫放進 live flow。
和一般 transcript-first 架構比，差別更大。傳統作法常要先等整段語音結束。這對聊天型產品還行。可是一旦要插話、查資料、控制設備，就會慢半拍。
如果拿市面上的 voice agent 來看，很多產品還卡在「可以聽懂」而已。真正難的是「聽懂後立刻做事」。這也是為什麼 function calling 的 benchmark 會變成重點。
- 傳統管線：VAD → STT → LLM → TTS
- Gemini 3.1 Flash Live：原生音訊 + 即時串流
- 一般 voice bot：常卡在單向請求
- Live API：適合持續互動與中途插話
從產品角度看，這會影響兩類團隊。第一類是做客服與銷售。第二類是做現場工具。前者重視回應速度，後者重視工具串接與上下文維持。
如果你現在的架構還很依賴 transcript，那就該認真想一下。因為你的競品可能已經開始測 live multimodal 了。
這波其實反映產業方向
語音 AI 這幾年一直在補洞。早期大家都在拼辨識率。後來開始拼對話品質。現在輪到即時性。因為使用者已經不想等。
這也跟硬體環境有關。手機麥克風、筆電鏡頭、耳機、車載系統，全都在變得更常見。硬體到位後，軟體就得跟上。否則裝置再多，也只是多幾個收音孔。
對台灣市場來說，這類模型很可能先落在客服、零售、教育、製造維修。這幾個場景都有共同點：噪音多、流程碎、要即時回應。剛好都是 live API 擅長的地方。
你如果做 SaaS，現在就可以想兩件事。第一，你的產品需不需要 barge-in。第二，你的工具呼叫是不是可以在同一個 session 裡完成。這兩題的答案，會直接影響架構。
接下來怎麼看
Gemini 3.1 Flash Live 還在 preview。這代表它還不是可以隨便亂上 production 的東西。16 kHz PCM、24 kHz 輸出、WebSocket session、同步 function calling，這些限制都要先吃下來。
但方向已經很清楚。Google 想把語音 AI 從「會回答」推到「會即時互動」。如果你正在做客服、助理、或現場工具，我會建議先做一版小型測試。看延遲、看打斷、看工具呼叫成功率。
我的預測很直接。接下來 6 到 12 個月，會有更多團隊把 transcript-first 架構換掉。不是因為舊架構不能用，而是新的 live flow 更像真實對話。問題只剩一個：你的產品準備好接這種 session 了嗎？