三条链路分流 · 决策矩阵 · 九步 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 系列长文在站内目录交叉引用。