三條鏈路分流 · 決策矩陣 · 九步 Runbook · VNC 勾選表 · 日誌順序
v2026.4.26 在「Talk」家族裡補齊了一條面向瀏覽器宿主的路徑：把低延遲雙向語音通過 Google Live 系 transport 接入，而 Gateway 負責會話綁定、令牌與部分中繼語義——這和你熟悉的 Talk Mode + 本地 MLX（偏設備側推理）、Gemini TTS 插件（偏「念稿」輸出）以及 openclaw migrate（偏配置樹遷移）都不是同一張工單。本文給 能力邊界、何時選哪條鏈路的決策矩陣、從 doctor 到瀏覽器煙測的九步 Runbook、四條可貼進工單的結論句、18789 與中繼路徑在反代/TLS 下的核對表，以及在遠程 Mac 的 VNC 圖形會話裡必須點完的權限鏈；並鏈到 《Talk Mode MLX》、《Gemini TTS》、《4.26 migrate》、《Gateway 反代》 與 《瀏覽器 MCP》，便於你把語音鏈路與自動化鏈路分清臺帳。
先把名詞對齊，否則你會在工單裡看到「Talk 打開了但沒聲音」「Gateway 已經綠但瀏覽器拒絕麥克風」混在一起：瀏覽器實時 Talk強調的是宿主在 Chromium 內核側跑麥克風和腳本權限；Talk Mode + MLX強調的是本地合成與打斷策略，更適合離線或自有 GPU上的確定性延遲；Gemini TTS強調的是文本→音頻的消費側插件，不承擔瀏覽器/WebRTC握手本身。migrate 則是另一條軸線：目錄樹與 Claude Code/Desktop 併入，不負責 RTP 抖動。
瀏覽器 Talk + Google Live transport：把雲端雙向會話接到 Gateway 認證的上下文；你需要關心同源、HTTPS、混合內容與 Session，以及對中繼路徑上的 Upgrade/WebSocket是否與上遊站點一致。
Talk Mode MLX：麥克風與本地推理強相關，與「遠程機房只有 CPU」或「只讀鏡像層」會直接衝突；詳見另文對版本與麥克風延續授權的表格。
Gemini TTS：適合播報類輸出與工單摘要朗讀；若要打斷式會話，應以瀏覽器 Talk 或 MLX 會話策略為準。
Gateway：仍是編排與會話錨點——瀏覽器頁只能當作可信前端，不能把密鑰塞進 Local Storage；令牌側堅持 SecretRef 與短時租約。
VNC：承擔TCC（麥克風、自動化、屏幕錄製）裡 SSH 缺失的那一半點擊鏈；遠程租用鏡像若會話用戶≠ Gateway 守護進程用戶，音頻路由會在第一輪就被打斷。
先選鏈路，再談 Latency：把「能響」與「可對齊工單」分成兩次驗收。
下面表格用來給值周與外包同學「同屏語言」：哪一列先看，能顯著減少『把反代配反了還去調模型』的時間浪費。
| 現象 | 優先懷疑 | 其次再看 | 常見誤判 |
|---|---|---|---|
| 瀏覽器無麥克風彈窗或一直「未檢測到設備」 | 系統輸入設備策略、Chrome 站點權限、是否與 VNC 會話同一用戶 | USB/虛擬音效卡映射、租用鏡像裡是否裁剪了音頻棧 | 先去調雲端區域與 API 版本 |
| 握手成功但首包極高、很快斷流 | 反代空閒超時、WSS 透傳不完整、CDN 層剝了 Upgrade | 地域到 Google Live 接入點 RTT | 只加大模型配額 |
| Gateway 日誌有 session，瀏覽器端無路由 | 同源策略、CORS 預檢失敗、前端 base href 不一致 | 瀏覽器擴展攔請求、企業根證書替換 | 誤解為 OpenClaw core 崩潰 |
| 只對部分同事復現 | 分環境 API Key / 綁定到個人沙箱帳號 | 不同渠道 Webhook 覆蓋到不同 workspace | 直接歸因為網絡「偶發」 |
矩陣的「其次再看」一欄，常和《公網 Gateway》裡Nginx/Caddy 的 WebSocket 頭強相關：把那裡配成模板，不要在每個項目裡徒手改一次。與《瀏覽器 MCP》相比：MCP 管的是DevTools 與頁面自動化；本文管的是音視頻與長連——兩條線可以並行開啟，但要避免同一標籤頁堆滿腳本攔截器。
把變更壓到一次發布窗裡：每一步都產出可貼進工單的一句話，便於與 migrate 批次、Docker 主機、裸機 launchd 分支對照。
版本凍結與 diff：記錄 openclaw --version 與 Gateway 鏡像 tag；確認 4.26+ 變更裡含「browser talk / live transport」相關項，不要與 4.25 的冷註冊表 repair混在一起做盲升。
配置備份：狀態目錄與 ~/.openclaw（或團隊規範路徑）打包，標上機器角色：「僅 smoke」還是「承接外網回調」。
doctor：先清環境性假故障；對「埠已佔用」「證書與 Host 不匹配」一類問題在此階段顯性化。
Gateway 基線：本機環回可達 18789 控制臺與 health；反代域名與 TLS 證書 SAN 對齊，再測 WSS。
啟用 browser talk：在網關側打開「允許瀏覽器會話」「Google Live transport」能力，並把區域/配額類信息寫進變更單。
SecretRef：雲側憑證與路由型 API key 禁止落盤明文；對照 openclaw secrets plan/apply 節奏貼審計號。
瀏覽器煙測：用無痕窗口消除擴展幹擾；首輪只測麥克風權限 + 會話 id 回顯，第二輪再疊業務側 system prompt。
中繼一致性：確認從瀏覽器到 Gateway、再到上遊 Live 接入點，三條鏈路的 session / trace 能在同一搜索詞下對齊；出現「半開連接」立刻抓反代 idle 與 read timeout。
回滾演習：把「關掉 browser talk → 回落到文本或 TTS」寫成一條可執行開關，並在監控上設成功率與 P95 延遲閾值。
若你並行跑 Docker，請把宿主網絡與埠映射一併畫在圖裡：容器裡聽到的「本機」與 VNC 桌面上的「本機」不是同一語境，音頻設備尤甚。
給主管與跨團隊排期用：
硬數字 1：控制臺與探活優先看 18789（團隊若改埠須在反代與健康檢查同步改）。硬數字 2：首屏語音相關資源建議兩分鐘內完成可感知的「咔噠/振動」反饋，否則先當橋接失敗而不是調參。硬數字 3：無痕煙測至少兩輪（冷啟 + 熱啟），避免緩存把 CORS 問題藏住。
下列片段僅為結構與鍵位說明，請以你內網發行說明與實際 schema 為準；目的讓讀者知道「中繼到底中繼了什麼」。不要把示例裡的佔位符直接粘貼進生產。
gateway:
browserTalk:
enabled: true
realtimeTransport: google-live # Google Live transport 會話
relay:
bindLocal: "127.0.0.1"
advertisePublicHost: "agent.example.com"
cors:
allowedOrigins:
- "https://agent.example.com"
secretsRef:
googleLiveApiKey: "secretref:prod/google-live/key"CORS不是錦上添花：瀏覽器會話要以可信來源清單落地。mixed content會在第一輪就讓麥克風權限判定異常。relay.advertisePublicHost必須與實際 TLS 終端一致，否則 WebRTC ICE 會出現「能找到 Gateway，找不到瀏覽器回調」。更多反向代理片段請對照《Gateway 反代》文中的 Nginx/Caddy 最小片段。
租用鏡像最常見的坑不是 CPU，而是會話一致性：你用 SSH 起了 Gateway，卻在另一個用戶的 VNC 裡點麥克風——兩邊鑰匙串與 TCC永不交匯。推薦順序：
確認 Gateway、瀏覽器與麥克風權限同屬一個登錄會話；必要時把 Gateway 調整為launchd 用戶代理而非 root。
「隱私與安全性 → 麥克風」裡勾選 Chromium/Safari（取決於你的宿主）；再在瀏覽器站點權限裡放行麥克風。
若需要自動化控制瀏覽器以注入腳本測試流，勾選輔助功能並複查是否與瀏覽器 MCP文檔衝突。
錄屏排障時才開「屏幕錄製」；生產長期開錄屏會帶來合規噪音，只在復現窗口短暫打開。
這與 Talk MLX 文章的麥克風段落互補而非重複：MLX 關心本地推理與會話打斷；瀏覽器 Talk 關心WSS/TLS/CORS與中繼語義。
當一個工單同時出現「控制臺紅了」「瀏覽器靜默」「上遊 quota」三類跡象時，按下述順序取材：(1)瀏覽器開發者工具 Network → WS/WSS 幀是否周期性 ping/pong；(2)Gateway stderr / structured JSON 日誌中帶 session id 的行；(3)反代 access log 裡的 upstream_time；(4)再到配額面板與帳單明細。跳過前兩級就去懷疑模型配額，九成會把排障拖到下班後。
若你在跨國鏈路上啟用 Live transport，請同時記錄端到端 RTT與Gateway→上遊兩段 RTT：只對後者擴容常見無效。
08不建議搶佔同一麥克風路由；應以一條為主會話，並在配置中寫優先級與降級。
先查 WSS 與 Upgrade、Host、證書鏈，再核對是否 mixed content。
不能。瀏覽器與 TCC 點擊鏈必須在 VNC 會話裡完成。
通常先 migrate 固化目錄樹，再上瀏覽器 Talk；否則中繼指向的路徑可能與插件根漂移。
瀏覽器 Talk + Google Live transport 解決的是「會話像通話」——它對同源、TLS、中繼與麥克風鏈條特別苛刻；任一環節含糊都會被誤認為「模型變差」。當你把這些噪聲拆乾淨之後，剩餘的定位才真正落在策略與會話腳本上。
自有 Mac 當然可以調試這類鏈路，但你要同時扛硬體差異、系統更新打斷長連與機房側帶寬帳單。相較之下，租用一臺 Apple Silicon 遠程 Mac、在同一桌面會話裡完成 Gateway、瀏覽器與 TCC，更像一間可復盤的對照實驗室——團隊的變更單也更不容易長成玄學。
若要按本文九步在同一交互會話內驗收中繼與麥克風鏈，可從 VNCMac 租用雲端 Mac：主按鈕進入購買頁；產品與套餐說明見首頁；OpenClaw 系列長文在站內目錄交叉引用。