【2026 最新】Gemini 3.8 Live vs Extended Thinking：會插話、會等工具的語音 Agent 教學

你對語音 Agent 說「幫我查訂單」，它先回「我來看一下」，這時畫面收到 turnComplete: true。如果控制器立刻把狀態改成待命，使用者下一句可能撞上仍在執行的工具，甚至讓同一筆操作跑兩次。Gemini 3.8 Live 與 Extended Thinking 的難點，正是「一句話講完」和「整個任務做完」不再是同一件事。

這篇會帶你從音訊串流骨架開始，拆開標準 Live 與 Extended Thinking 的兩套狀態機，加入非阻塞工具、插話、超時與降級，再用 12 組任務建立自己的驗收表。先說清楚證據邊界：截至 2026 年 9 月 16 日，官方文件已公開協定與價格，但本輪環境沒有可用的 Gemini API 憑證，因此以下不會冒充端點實測，也不會預填延遲勝負；你會拿到的是可照著執行、能留下 Trace 的測試方法。

如果你還沒做過語音系統評測，先讀 Voice Agent Eval 的 12 段錄音法；想先補 Agent 的工具迴圈，可搭配 最小 AI Agent Harness 實作。

先說結論：可用的 Gemini 3.8 Live 不只是一條 WebSocket

先記住本文的核心式：

可用語音 Agent ＝ 會說話的模型＋不把 turnComplete 當結案的狀態機＋可取消、可對帳的工具。

標準 Gemini 3.8 Live 適合短對話、直接命令與快工具；Extended Thinking 適合多步推理或需要等待的外部工具。兩者不是「低階版／高階版」：選擇依據應是任務生命週期，而不是只看模型名稱。更重要的是，Extended Thinking 的 turnComplete 只代表一段語音結束；interactionStatus: IDLE 才表示模型端的整段互動結束。即使到了 IDLE，付款、訂位或資料庫寫入是否真的成功，仍要以你的工具結果與交易紀錄為準。

Gemini 3.8 Live vs Extended Thinking：協定差在哪？

Google 在 2026 年 9 月 15 日推出 gemini-3.8-live 與 gemini-3.8-live-extended-thinking。兩者的模型頁都列出 131,072 輸入 token 與 65,536 輸出 token，也都接受即時音訊、影像、影片與文字；但部署契約不同。標準 Live 模型頁列出 blocking 與 non-blocking function call；Extended Thinking 模型頁則要求工具為 NON_BLOCKING，不支援 function scheduling，thinking level 只能選 low、medium 或 high。

• 標準 Live：省略 thinking 設定，優先用在短問答、直接操作與需要快速回應的流程。
• Extended Thinking：背景推理可跨越多段語音與工具等待；不能把第一個 turnComplete 當成整個任務已完成。
• 共同點：非阻塞宣告只改變協定行為，不會自動把你的 Python／JavaScript 工具變成並行工作；worker、timeout、取消與去重仍由應用程式負責。

官方發布文說標準 Live 也能在工具背景執行時維持對話，但 Thinking 對照頁對標準版的描述較保守。這兩份說明存在落差，所以本文不把「工具執行時能否持續說話」當成型號保證；請用後面的固定測例，在你的帳號、SDK 與區域上驗收。產品 rollout 也不是所有介面與企業帳號同時完成，部署前應以 Google 發布公告及自己的 AI Studio 專案為準。

為什麼舊狀態機會壞？看一條 Extended Thinking Trace

假設使用者說：「查兩張發票，再告訴我哪張逾期。」一條合理的事件序列可能是：收到使用者音訊 → 模型說「我先查一下」→ turnComplete: true 且 interactionStatus: IN_PROGRESS → 發出兩個 tool call → 工具回傳 → 模型補上比較結果 → interactionStatus: IDLE。如果舊程式在第一個 turnComplete 就清空 busy 狀態，它會提早開放新的高風險操作，也會把後續工具回覆誤判成過期事件。

Live API schema把 interactionStatus 放在 serverContent 裡；因此 Python 是 message.server_content.interaction_status，JavaScript 是 message.serverContent?.interactionStatus。官方 Thinking 教學部分片段把它讀成 top-level 欄位，JavaScript 片段還對 SDK 已解析的訊息再做 JSON.parse；那兩段不要原樣複製。

步驟一：先跑通最小 audio-to-audio client

最快的起點是 Google 的 Python 麥克風範例。本文截稿時，它已改用標準 gemini-3.8-live 並處理麥克風與喇叭；但範例沒有本文需要的 Extended Thinking status、tool worker 與重連控制器，所以先把它當音訊管線。官方 README 要求 Python 3.11+、PortAudio、google-genai 與 pyaudio；以下第一行是 macOS 安裝法，其他系統請用自己的套件管理器，測試時戴耳機以減少範例未處理的回音：

brew install portaudio
python3 -m venv .venv
source .venv/bin/activate
python -m pip install google-genai pyaudio
export GEMINI_API_KEY="請放在本機環境變數，不要寫進前端或 Trace"

輸入音訊依官方 SDK quickstart 使用 raw PCM、16-bit little-endian、16 kHz、mono；輸出是 24 kHz PCM。不要把帶 WAV header 的檔案或瀏覽器 MediaRecorder 產生的 WebM blob 直接冒充 raw PCM。每個 server message 都寫入 JSON Lines，至少留下 trace_id、單調時鐘、事件種類、turnComplete、interactionStatus、tool call ID、取消 ID 與播放 buffer 狀態；敏感參數只存遮罩或雜湊。

{"t_ms":0,"event":"user_speech_end","trace_id":"T-001"}
{"t_ms":null,"event":"server_content","turn_complete":true,
 "interaction_status":"IN_PROGRESS"}
{"t_ms":null,"event":"tool_call","call_id":"C-17","name":"lookup_invoice"}
{"t_ms":null,"event":"tool_result","call_id":"C-17","ok":true}
{"t_ms":null,"event":"server_content","interaction_status":"IDLE"}

這是欄位格式示意，t_ms 必須由你在同一台機器上量測，不能拿 null 當成成績。瀏覽器端不要放長效 API key；依 ephemeral token 文件，由後端用長效憑證換短效 token，再交給前端建立即時連線。該文件目前寫 v1beta，但 SDK 原始碼仍可見 v1alpha 提示；請固定實際 SDK／endpoint 組合，驗證發 token、建連與重連後再部署。

步驟二：為 Gemini 3.8 Live 寫兩套 reducer

不要只用一個 isSpeaking。至少拆成 serverActivity、playbackState、micState 與 pendingTools；「伺服器仍在想」不等於「關掉麥克風」，「伺服器 IDLE」也不等於本機播放器已經播完。

function reduceLiveMessage(state, message, extended) {
  const sc = message.serverContent;

  if (sc?.interrupted) {
    state.playback.flushNow();       // 立即丟掉尚未播出的舊音訊
  }

  if (message.toolCall) {
    dispatchTrackedWorkers(message.toolCall.functionCalls);
  }

  if (extended) {
    if (sc?.interactionStatus === "IN_PROGRESS") state.server = "ACTIVE";
    if (sc?.interactionStatus === "IDLE")        state.server = "READY";
    // 狀態缺席時維持原值；不可把 turnComplete 當 READY
  } else if (sc?.turnComplete) {
    state.server = "READY";
  }
}

上面是狀態處理骨架，不是完整可上線 client；它省略音訊 backpressure、重連、schema 驗證與裝置清理。Python SDK 目前的 Live 實作會在一次互動完成時結束 session.receive() iterator，長連線程式要在外層重新進入 receive loop。raw WebSocket 文件又同時出現 v1alpha 與 v1beta 範例；請固定 SDK 版本與 endpoint，先用一問一答 smoke test 保存原始事件，再把結果納入回歸。

步驟三：讓工具真的非阻塞，而且可以等、停、對帳

Extended Thinking 的 function declaration 要標成 NON_BLOCKING，並且不要加入 generic tool guide 裡的 scheduling 設定；該模型頁明確列為不支援。收到 tool call 後，receiver 要立刻回去收下一個事件，真正耗時的工作交給有上限的 worker。每筆 pending tool 至少保存：

• call_id、工具名與經 schema 驗證的參數。
• deadline、取消 signal、連線 generation 與 idempotency_key。
• 工具結果、外部 side effect 狀態，以及回覆是否已送回模型。

onToolCall(call):
  validate(call)
  pending.add(call.id, deadline=now+8s, idempotency_key=makeKey(call))
  workers.start(call)                 // 不阻塞 receiver

onToolFinished(id, result):
  if !pending[id].claimCompletion(): reconcileSideEffect(id); return
  cancelDeadline(id)
  sendToolResponse(id, result)
  pending[id].markResponded()

onDeadline(id):
  if !pending[id].claimTimeout(): return // 原子地從 ACTIVE 轉為 TIMED_OUT
  cancelIfSupported(id)
  sendStructuredError(id, "TIMEOUT") // 不捏造成功

toolCallCancellation.ids 告訴 client 哪些 call 已被模型取消，但取消訊號不會自動撤銷已完成的刷卡、訂位或寫入。高風險工具必須使用冪等鍵與事後查詢，並把「模型已 IDLE」和「外部交易已確認」分成兩盞燈。想把這個 worker 擴成可觀測的 production loop，可接著讀 AI Agent Harness 是什麼。

步驟四：Barge-in、權限與敏感資訊要一起設計

收到 serverContent.interrupted: true 時，第一個動作是立即停止播放器並清空 queued audio，而不是等目前句子播完。使用者插話後建立新的 turn_epoch，晚到的舊音訊一律丟棄；工具則依 call_id 追蹤，不能只因使用者多說一句就丟掉仍有效的 non-blocking call，只有收到對應 cancellation ID、逾時或 session 已失效才封存。若工具可能已產生 side effect，則進入 reconcile 狀態，不要假裝回滾成功。

• 麥克風／相機：在送出前顯示當下開啟狀態與用途；相機採明確 opt-in，不把背景畫面默默加入 session。
• Trace：預設不存 raw audio、API key、姓名、地址、卡號與畫面截圖；若除錯必須保留，先遮罩、限制保存期限與存取者。
• 降級：Extended Thinking 超時、連線不穩或工具不適合長等待時，取消當前工作並開一個新的標準 Live session；不要在同一 interaction 內偷換模型，否則 Trace 無法解釋。

Live API 連線與 session 不是永久存在。session management 文件列出連線約 10 分鐘、未壓縮 audio-only session 約 15 分鐘，並提供 GoAway、session resumption 與 context compression。Resumption 可續接近期狀態，compression 會丟棄較舊內容；兩者都不是永久記憶，更不能取代交易資料庫。

用 12 組任務驗收 Gemini 3.8 Live，而不是只聽 Demo

固定硬體、網路、voice、工具資料與 12 段錄音，隨機化模型順序並重複多輪。前四題測短問答、直接命令、快速查詢與 3 秒查詢；第 5～8 題測平行查詢、依賴鏈、缺欄位追問與工具報錯；第 9～12 題測 timeout、說話中修正、工具中取消，以及長對話加強制斷線。繁中案例至少包含人名、金額日期、中英夾雜與背景噪音。

每輪分開記錄「使用者語音結束 → 第一段可播放音訊」、「第一句有實質內容」、「整個任務完成」、最長沉默、正確 tool／argument、最終答案、插話到舊音完全停止、重複 side effect、狀態機錯誤與重連成功率。模型若先說「讓我看看」，只能算第一段音訊，不能算實質答案。這套分層能避免把 filler speech 包裝成推理更快。更完整的錄音與評分表可直接沿用 Voice Agent Eval，模型升級後則用 Gemini 3.8 Flash effort workbook的固定案例觀念做回歸。

Gemini 3.8 Live 成本怎麼算？不要把每分鐘數字當總帳

截至 2026 年 9 月 16 日，Gemini Developer API 定價頁把兩個型號列在同一組：每百萬 token 的文字輸入 0.75 美元、音訊輸入 3 美元、圖片／影片輸入 1 美元、文字輸出（含 thinking）4.50 美元、音訊輸出 12 美元。頁面也顯示音訊輸入約 0.005 美元／分鐘、輸出約 0.018 美元／分鐘，但那不是一通電話的固定全包價。

Live session 會在後續回合重新處理保留的 context；thinking token、轉錄文字、視覺輸入、搜尋 grounding、重試與額外說出的進度都可能加價。因此比較式應是：

單一任務總成本 ＝ Σ（各模態實際用量 × 對應單價）＋外部工具成本；重試要算成新的用量。

同樣費率下，Extended Thinking 可能因為多想、多說或更久的 context 而較貴，也可能因為少重試而較省；沒跑同一批任務之前不能下結論。兩個 3.8 型號都固定啟用 proactive audio，官方 best practices 也提醒：模型在聆聽時會產生音訊輸入費用。用 Live API best practices建議的短音訊 chunks、context compression 與 usage metadata，逐輪記帳；不用收音時就停止送流。實際 project quota 會依 tier 與帳號變動，部署日到 AI Studio 查看，不要把別人的數字寫死。

怎麼選：標準 Live、Extended Thinking，還是先降級？

• 選標準 Live：短問答、一次工具、直接控制，以及「先有可靠低複雜度 baseline」最重要。
• 選 Extended Thinking：要跨多步推理、同時等多個工具，或使用者需要在等待期間繼續互動。
• 先不要上 Extended：工具沒有冪等、取消與 timeout，或 UI 只有一個布林 busy 狀態。
• 設 fallback：達到你的 interaction deadline 後，明確告知使用者、取消可取消的工作，核對 side effect，再建立新的標準 Live session；保留原 trace ID 的 parent 關係。

這篇的目標是「把語音 Agent 做出來並驗收」，不是替兩個模型排總名次。若你只是想理解 Agent 的基本零件，可先讀 Agent Harness 白話篇；若準備系統化練習，則可查看 AlphaLab 線上課程。

常見坑：五個看似成功、其實還沒完成的訊號

1. 看到 turnComplete 就解除 busy：Extended Thinking 要等明確的 IDLE。
2. 看到 IDLE 就顯示付款成功：仍要核對工具結果與外部交易紀錄。
3. 宣告 NON_BLOCKING 就同步跑工具：應用程式若在 receiver 裡直接 await 慢函式，整條事件流照樣卡住。
4. 插話只停 UI 動畫：必須清空實際音訊 buffer，並丟棄舊 epoch 的 late chunks。
5. 只看首音：把進度話術和實質答案分開量，否則最快的模型可能只是最早說「請稍等」。

FAQ：Gemini 3.8 Live 語音 Agent 常見問題

1. Extended Thinking 一定比標準 Live 慢嗎？

不能直接這樣說。首音、第一句實質答案與任務完成時間是三個不同指標；請用同一批任務分開量，官方發布數字也不能取代你的網路與工具條件。

2. turnComplete: true 還能拿來做什麼？

它仍可表示一段模型 utterance 已結束，適合收斂字幕或播放段落；在 Extended Thinking 裡不要用它結束整個 interaction。

3. IDLE 是否等於工具一定成功？

不是。IDLE 是模型端整體處理狀態；工具可能失敗、超時，或外部 side effect 已完成但回覆遺失，仍須查工具與交易紀錄。

4. 可以把 API key 放在瀏覽器嗎？

不要放長效 key。由可信後端換取短效 ephemeral token，限制開始與連線時效；同時對 token endpoint 做驗證、限流與稽核。

5. Barge-in 會自動取消訂單或付款嗎？

不會。它能停止模型輸出與觸發 tool cancellation，但已送到外部系統的操作需要冪等鍵、取消 API 或事後對帳。

6. thinking level 要直接設 high 嗎？

先從 low 建 baseline，再用相同 12 題比較 medium、high 的任務成功、延遲與 token；沒有品質增益就不必支付額外等待與輸出。

7. 為什麼要分 server、mic、playback、tool 四種狀態？

因為它們可同時不同步：模型在想、麥克風仍開、播放器已清空、工具還在跑。壓成一個 busy 布林值會失去取消與除錯所需資訊。

8. 什麼時候應降級到標準 Live？

當任務其實只有一步、延遲預算很窄，或 Extended interaction 超過你設定的 deadline。降級前先取消、對帳並告知使用者，再開新 session。

給新手的 6 個重點

1. 把「一句話完畢」與「整個任務完畢」拆成兩個事件。
2. Extended Thinking 以 interactionStatus 為主，狀態缺席時不要自行推定 IDLE。
3. 工具 receiver 與 worker 分離，每筆 call 都有 deadline、取消與冪等鍵。
4. 插話的驗收終點是舊音訊真的停止，不是收到一個事件。
5. 首音、實質答案、任務完成與 side effect 各自量測。
6. 價格、quota、區域與 SDK schema 都在快速變動；固定版本並保存 Trace。

更多語音、Agent 與模型評測文章可在 AlphaLab AI 專區找到；若要比較 ASR → LLM → TTS 的另一種組裝方式，也可讀 Nari Qwen3-TTS／ASR Voice Agent 教學。