Gemini 3.8 Live：工具在跑時還能說話，真的更可靠嗎？（2026）

2026 年 9 月 15 日，Google DeepMind 產品經理 Alisa Fortin 與 DevX 技術人員 Thor Schaeff 在 Google Blog 發布〈Build real-time voice applications with Gemini 3.8 Live and 3.5 Transcribe〉，把 Gemini 3.8 Live 與 Extended Thinking 的賣點濃縮成一句話：工具在背景執行時，語音 Agent 不必只剩沉默。

這篇文章先還原 Google 真正發布了什麼，再用官方 API 文件與獨立榜單逐項對帳，最後回答一個更實際的問題：會在等待時繼續說話，是否就等於更可靠的 Agent？截至 2026 年 9 月 16 日 22:10 UTC，這次發布在 Hacker News 討論串累積 480 分、320 則留言；熱度是真的，但熱度不是產品驗收。

原文全貌：這不只是一篇 Gemini 3.8 Live 發布文

原文其實是一張 Gemini Audio 產品地圖。主角是新推出的 Gemini 3.8 Live 與 Extended Thinking；同文也回顧前一個月發布的 Gemini 3.5 Transcribe。Google 宣稱 Transcribe 支援 85 種以上語言，串流與非串流平均 WER 分別為 4.0% 與 2.6%，可偏置最多 1,000 個自訂詞彙，並能透過 Interactions API 處理最長一小時的檔案。這些是 Google 提供的整體平均與產品規格，原文沒有附上逐語言誤差、樣本組成或第三方重跑結果。

文章還把 Gemini 3.5 Live Translate、Gemini 3.1 Flash TTS 與 Lyria 3.5 放進同一套音訊產品敘事。客戶案例 Ambr AI 表示，換用 Extended Thinking 後模擬訓練變得更快、更有表情，單一整合可服務 70 種以上語言；但原文沒有給出前後測數值或獨立稽核。這個全貌很重要：Google 賣的不是一個「會說話的模型」，而是從辨識、即時互動、翻譯到生成的開發者音訊堆疊；本文接下來聚焦其中證據最具爭議的 3.8 Live 主張。

原文最後的訴求也很直接：到 Google AI Studio 試用，複製 Live API 範例，或把官方供 coding agent 使用的 Live API skill 交給開發代理。換句話說，這不只是研究發布，也是一次把整套音訊開發入口集中曝光的產品上市文。

Gemini 3.8 Live 的核心主張：把等待變成對話

Google 同時推出兩個穩定模型端點：標準版 gemini-3.8-live，以及 gemini-3.8-live-extended-thinking。兩者都能接收即時音訊、影像幀與文字，也都能發出 function call；真正拉開差異的，是 Extended Thinking 能以 low、medium、high 調整背景推理，並在工作尚未完成時先口頭確認或報告進度。

“Execute API and tool calls in the background while continuing to stream audio responses…”

中文：在背景執行 API 與工具呼叫，同時持續向使用者串流語音回覆。

Alisa Fortin、Thor Schaeff，Google Blog，2026 年 9 月 15 日

白話說，Extended Thinking 可以先說「我正在查」，再等待應用程式把工具結果送回來；Google 的比較文件對標準版描述得更保守。關鍵限制也藏在這裡：模型只提出函式請求，真正呼叫訂位、付款或資料庫 API 的仍是開發者的應用程式或可信後端。非同步 function calling 是通訊協定能力，不會自動帶來重試、權限控管或失敗復原。Google 的 最佳實務也提醒，目前模型在單一 function call 任務上的表現最好。

Extended Thinking 排行榜第一：82.6 點究竟代表什麼？

“ranking #1 on Artificial Analysis’ Speech-to-Speech leaderboard.”

中文：在 Artificial Analysis 的 Speech-to-Speech 榜單排名第一。

Alisa Fortin、Thor Schaeff，Google Blog，2026 年 9 月 15 日

這句話需要補上完整主詞：截至 2026 年 9 月 17 日，在 Artificial Analysis 即時榜單領先的是 Extended Thinking 的 High 設定，綜合指數為 82.6 點；標準版 Gemini 3.8 Live 是 76.0 點。這不是「82.6% 正確率」，也不是兩個版本一起拿第一。

依 Artificial Analysis 方法頁，目前 v2.0 指數把語音推理、工具任務、凍結版真人偏好分數與任務成功率各配 25% 權重。權重或方法版本換一套，排名就可能換一套。另一個好例子是 Extended Thinking（High）在 Big Bench Audio 得 97.7%，卻是該分項第四名：綜合第一從來不等於每一項都第一。

68.6% 很亮眼，但不能直接外推成真實客服的成功率。這是 Artificial Analysis 依 τ-Voice protocol 跑出的成績；τ-Voice 原始論文使用英文、合成語音與模擬使用者，工具呼叫近乎即時，也不評估語氣自然度、滿意度與部分完成。它雖加入電話頻寬、噪音與 frame-drop 模擬，評測仍是英文 TTS 使用者、可控環境與近乎即時的工具呼叫，不能直接代表非英語真人或真實慢工具。更細的一點是，Google 的評測說明把標準版成績標成 gemini-3.8-live-preview；因此不能逕稱發布圖上的所有標準版分數都由正式端點重跑。

Gemini 3.8 Live 的價格：每分鐘報價不是總成本

Google 在 Standard（非 Batch）計費欄列出的音訊等值價格，是每分鐘輸入 0.005 美元、輸出 0.018 美元，底層對應每百萬 input tokens 3 美元、output tokens 12 美元。這兩個數字可以拿來做第一輪估算，卻不是固定吃到飽的通話費：官方價格頁以 token 計費，歷史上下文可能在後續輪次重新處理，轉錄會增加文字輸出，思考 token 也會計費。

圖上的 0.84 美元與 3.50 美元，回答的是「同一組測試題跑下來要多少模型費用」，不是把官方每分鐘輸入價格乘以 60。它納入該工作負載的音訊輸入、輸出與思考，卻不含你的電話供應商、資料庫、搜尋、監控與工具呼叫成本。兩個 3.8 模型的 proactive audio 都固定開啟，安靜聆聽仍會累積輸入。要估算產品毛利，應記錄完整 session 的 billed tokens，而不是只看首頁報價。

發布證據還留下三個缺口

1. Stable 模型與 Preview API 同時存在

兩個模型專頁都標示 Stable，但 Live API capabilities 頁首仍標 Preview。這不是字面矛盾：模型 ID 可以穩定，承載連線與事件的整合面仍可能演進；但它提醒採購者，不應把一個 Stable 標籤外推成整條產品鏈都已定型。

2. 支援 97 種語言，不等於 97 種語言都被同等驗證

官方能力頁列出的是 97 種支援語言，不是發布摘要所寫的「97+」。公開主力 benchmark 則以英文與合成語音為主，沒有證明跨語言品質一致。視覺能力也是應用程式擷取並送出 JPEG／PNG 幀，文件上限為每秒 1 幀；「可看鏡頭或螢幕」不能理解成模型自行取得裝置權限。

3. 對話仍在進行，不等於任務已完成

Extended Thinking 的官方範例會先播放進度語音，當下可能出現 turnComplete:true，但狀態仍是 IN_PROGRESS，稍後才有工具請求與最終結果。Live API 參考也說，若插話發生時外部工具已造成副作用，client 最多只能嘗試復原。發布文證明「等待可以不再沉默」，沒有證明等待、取消與交易風險一起消失。

Google 的 模型卡另外列出幻覺、偶發延遲與 timeout 等已知限制。這些不會抹去新能力，但會改變「可以展示」到「可以承接重要工作」之間需要多少工程。

AlphaLab 的判讀：突破在互動協定，不在可靠性已被解決

它沒有消滅等待，而是重新安排等待

語音介面最令人不安的，不只是慢，而是不知道系統有沒有聽懂、是否還活著。先確認意圖、在長任務中交代進度，能把不可見的延遲變成可理解的狀態。這是一個真正的產品進步；但若 filler 說得很流暢，最後仍訂錯票，使用者只是更舒服地等到錯誤結果。

語音 Agent 品質是一組向量，不是一個榜單名次

延遲、任務成功、插話處理、自然度、重複可靠度、成本與可逆性彼此拉扯。Extended Thinking 在這組合成工具任務中的分數大幅較高，標準版則較便宜；截至 9 月 17 日，標準版在即時真人偏好榜的 Elo 也較高。真正的問題不是「哪個模型最強」，而是你的失敗成本落在哪個維度。

同一篇發布文，混合了不同成熟度的證據

3.8 模型端點、Preview API 介面、Google 自報的 Transcribe 平均值、Artificial Analysis 的獨立即時榜單，以及 Ambr 的客戶證言被放進同一篇故事裡，閱讀時很容易得到「每一項都已同等驗證」的印象。更公平的讀法，是把可重現規格、特定 benchmark、客戶自述與未來產品敘事分層，而不是把它們相加成一個總體可信度。

我同意 Google 對互動體驗的方向判斷：背景推理與進度語音，確實把 voice agent 從一問一答推向持續協作。我存疑的是讀者若把綜合榜首、每分鐘報價與 Stable 標籤自行串成「已適合所有正式工作流」的結論；本文引用的發布材料與公開評測，尚未證明多語真人環境下的品質一致，也沒有測到真實慢工具與不可逆動作的 production 可靠性。

行動建議：用證據矩陣讀發布，而不是追一個冠軍

1. 先標出證據類型。規格、供應商評測、第三方榜單、客戶證言與產品願景，可信度和可外推範圍都不同。
2. 固定比較設定。記下模型 ID、thinking level、榜單日期、試跑次數與成本口徑；「Gemini 3.8 第一」若少了這些條件，就沒有可重現的意義。
3. 把品質拆成多個維度。至少分開看任務成功、真人偏好、第一聲延遲、最終完成時間、可逆性與全包成本，不要讓綜合分數替你決定權重。
4. 用自己的語言與工作流重跑。97 種語言支援只是測試起點；涉及付款、寄信或敏感資料時，也要審查確認機制、API 條款與資料治理。

若你準備動手，AlphaLab 的Gemini 3.8 Live 實作教學專門處理事件狀態機與中斷恢復，Voice Agent Eval 驗收法則把插話、數字與 task success 變成可重跑測試。這篇敘事回答的是「發布證據夠不夠」；那兩篇接手「系統怎麼做、怎麼驗」，三者的讀者任務不同。