speech-to-speech 项目发布首个大版本 v1.0.0，整合为 serve、talk、local 三个命令，新增 Qwen3-ASR 识别、OpenAI 兼容 STT/TTS 端点、有状态 OpenAI Realtime 转写与实验性 vLLM Realtime 转写，并改进文本/音频/工具调用的有序输出、打断与 会话清理。浏览器演示基于 OpenAI Agents SDK，覆盖 WebSocket 与 WebRTC 两种传输的集成测试，Apple Silicon 默认改用 4-bit Qwen3-4B LLM 与 6-bit Qwen3-TTS。
推荐理由：开源全栈语音对话管线的 1.0 里程碑，命令行与后端生态明显收敛，适合做语音 Agent 自建参考。
Zoom 发布开源 Web 远程医疗入门套件，基于 Zoom Video SDK 构建，覆盖医生与患者注册、预约、设备预览、视频问诊、聊天、屏幕共享、云录制、实时转写和 PDF 文件共享等核心流程。套件采用 Next.js 16、React 19 和 TypeScript，代码托管于 GitHub。官方声明该示例尚未按 HIPAA 合规设计或验证，未经独立安全与合规审查不得用于受保护健康信息。
LiveKit 推出非生产部署，让语音 Agent 以不同名称与生产环境并行运行，共用同一容器镜像、项目和密钥，创建只需一条命令。非生产部署空闲时休眠且不计费，但重新部署会立即中断活跃会话，且不支持回滚；需 livekit-agents 1.6 或 @livekit/agents 1.7.1 以上 SDK 才能接收呼叫。
LiveKit 发布 Connectors，把 Twilio Programmable Voice 和 WhatsApp Business Calling 的通话作为普通参会者接入 LiveKit 房间，无需配置 SIP 中继或网关。WhatsApp 通话端到端走 WebRTC（ICE、DTLS-SRTP、Opus），Twilio 通话经 Media Streams WebSocket 以 G.711 原始形式发布，仅为需要的订阅者转成 Opus。Connectors 已在 LiveKit Cloud 正式可用，计费与 SIP 相同，每分钟 0.004 美元（Ship）和 0.003 美元（Scale）。
推荐理由：LiveKit 把 Twilio 与 WhatsApp 通话直接接入房间，读者可据此判断现有 SIP 方案是否要改。
Inworld 于 8 月 31 日将 Realtime TTS-2 转为正式可用（GA），面向实时对话设计：模型接收完整对话音频，感知用户的语气、节奏与情绪状态，并支持用自然语言像提示 LLM 一样下达 voice direction；同一音色身份可跨 100+ 种语言保持。前代 Realtime TTS 1.5 曾在 Artificial Analysis Speech Arena 排名第一。
推荐理由：实时 TTS 从静态朗读转向双向对话的关键产品节点，100+ 语言音色一致性对全球化语音 Agent 影响直接。
mediasoup-client 3.23.0 移除 transport.produce() 的 headerExtensionOptions，改为 Device 层 forcedRtpExtensions 按扩展 URI 强制开/关；该能力目前仅最新 Chrome 支持 WebRTC RTP Extension Control API，并修复了 Canary 149 中 abs-capture-time 引发的 codec collision 报错。
推荐理由：浏览器 RTP 扩展控制能力落地到主流 SFU 客户端库，影响采集时间同步等特性接入方式。
LiveKit 发文梳理语音智能体对 yes、no、ok 等短语音应答失败的原因，指出回合结束需要 final_transcript 和 end_of_speech 两个事件同时满足，中间转写不会关闭回合。文章列举 STT 未生成最终转写、端点检测过于激进或过于宽松、噪声抑制误删短语音、SIP 通话质量差以及 backchannel 被误判为打断等成因，并给出对应做法，包括启用 transcription_timeout 做优雅恢复、turn_detection="stt" 时将 endpointing.min_delay 设为 0、按场景选择 voice isolation 或 background noise suppression、优先使用 G.722 等支持 HD voice 的编解码器，以及用自适应打断处理识别 backchannel。
推荐理由：LiveKit 官方梳理短语音回合检测失败的常见成因，并给出可逐项排查的配置与恢复手段。
LiveKit 将 Agent 会话分钟与录制、WebRTC 连接和 SIP 连接改为按秒计费，最低按 10 秒计费，适用于所有套餐与账户（含企业合同），无需技术改动。该调整已对现有客户生效，8 月用量将体现在 9 月账单中。LiveKit 称按分钟计费会限制外呼等短时场景的扩展，按秒计费可消除这种定价错配。
LiveKit 的 SFU 架构让机器人系统从点对点连接扩展为多参与者 Room，摄像头、模型、操作员和下游服务各作为一个参与者加入，无需重新设计传输架构。在跨网络的人机协同录制场景中，机器人观测可同时分发给策略、操作员和录制端，策略动作与人工干预各自独立回传，避免额外网络跳数。VLM 可作为任务级编排者，各技能策略以独立参与者订阅所需观测，奖励模型则按控制频率评估执行状态并驱动策略升级。
针对 ESP32、ESP32-S3 等低资源设备做语音通话，建议从 16 kHz、16 bit、单声道、20 ms 帧长起步，优先保证接通率与稳定性，再评估提升音质。声网 RTSA SDK 仅支持单声道、20 ms 发送间隔，包体积增量小于 400 KB，收发 320×240 H.264 时内存占用小于 2 MB，采集与编解码需设备端自行实现。
声网发布游戏语音质量评估方法，把语音可用拆成加入频道、发布订阅、音频播放等环节，建议接通率按进入队伍后 5 秒内成功加入频道并接收至少一名队友音频来统计，持续低于 98% 视为链路存在系统性问题。排查上先查频道、订阅和音频路由状态再查网络，用 audioLossRate、frozenRate、networkTransportDelay、jitterBufferDelay、e2eDelay 和 mosValue 区分网络卡顿与客户端卡顿，并给出首版质量看板的八项核心指标。
推荐理由：声网把游戏语音质量拆成接通率、卡顿率、延迟和弱网恢复四类指标，并给出可复用的排查顺序与看板指标。
LiveKit 宣布其 Inference 中所有 LLM、STT、TTS 模型默认启用零数据保留（ZDR），适用于所有套餐，无需开关或升级配置。ZDR 要求不保留、不记录日志、不训练、不聚合，LiveKit 通过合同、账户或工作区配置及逐请求参数强制第三方提供商遵守，不达标者不予接入。Agent 可观测性数据保留 30 天，Egress 录制存入用户自有云存储，语音克隆样本在最后使用 12 个月后删除。
LiveKit 在 LiveKit Agents 中发布 expressive mode，用一个开关让语音智能体根据对话上下文调整语气。该模式在 LLM 提示中注入各家 TTS 的标记方言，由框架统一转换，并会把多句合并成更大块再送入 TTS，以稳定情绪和音高且不显著增加延迟。目前支持 Fish Audio、Inworld、Cartesia 和 SpaceXAI 的 LiveKit Inference 模型，前端可通过 lk.expression 属性获取情绪信号。
推荐理由：LiveKit 官方说明 expressive mode 如何把 LLM 输出转成各家 TTS 的情绪标记，并给出开启方式与前端联动做法。
声网发布游戏语音质量监控方法，把语音可用链路拆成开启语音、获取频道信息、加入频道、发布订阅、音频播放五个时间点，建议接通率以最后必要环节为准，持续低于 98% 通常说明存在系统性问题。文章结合 Unity RTC 回调给出排查顺序：听不到先查频道、OnRemoteAudioStateChanged 订阅状态和音频路由，再查网络；卡顿用 OnRemoteAudioStats 的 audioLossRate、frozenRate、jitterBufferDelay、e2eDelay 和 mosValue 区分网络与客户端问题，并建议质量看板先保留接通率、可听首帧时间、卡顿率、端到端延迟 P95 等八项指标。
推荐理由：声网结合自家 Unity RTC 回调，把游戏语音从玩家反馈到指标看板的排查链路拆成可落地步骤。
以东南亚移动热点（丢包 8%-15%）客户案例切入：丢包超 5% 时 MOS 从 4.2 降到 3.0 以下、端到端超 400ms 对话节奏被破坏、抖动超 30ms 音频变调；工程上采用 ULPFEC 不均等保护（I 帧与音频 30%-50% 冗余、P 帧 10%-20%，20% 丢包下恢复率约 70%）、动态 Jitter Buffer 在 80-200ms 间伸缩，并观察到 BBR 在移动网络带宽突降时收敛比 GCC 快约 1.5 倍。
推荐理由：有案例、有阈值、有参数取舍的弱网优化实战记录，FEC 分级与缓冲策略可直接借用。
LiveKit 官方文章聚焦 agent 加入延迟，即后端请求 agent 到 agent 就绪进入房间的时间，并指出用户侧表现为持续响铃、静音、头像黑屏、客户端超时或提前离开。文章列出常见原因：LiveKit Cloud 上 Build 计划会缩容到零导致冷启动，自托管需维护预热进程池并调整 num_idle_processes，入口点阻塞代码和过大的容器镜像也会拖慢加入，虚拟形象会额外增加一个参会者并处于关键路径上。排查时可记录显式 dispatch 前与 await ctx.connect() 返回后的时间戳，并通过 job metadata 传递 ID 关联两条日志。
推荐理由：LiveKit 官方拆解 agent 加入房间延迟的成因与排查路径，自托管团队可据此定位冷启动和扩容问题。
智能硬件语音交互的体验瓶颈往往不在 LLM，而在麦克风采集、回声消除、RTC 实时传输、流式 ASR、TTS 播放与打断控制等基础环节。文章拆解了从采集、前处理、实时传输到 ASR、LLM、TTS、播放与打断的完整链路，指出 RTC 是弱网下保持语音连续的关键通道，并建议量产前按真实场景验证麦克风、弱网重连、儿童语音与云端成本。
Tsahi 以客户案例论证 WebRTC 与 SIP 的媒体质量上限相当（都走 RTP/SRTP），质量问题常被误判为协议问题；他主张在改架构前先用 getStats() 做客户端侧全量采集，因为服务端指标“只能看到一半故事”，有观测后定位问题可从数天缩短到数分钟，并明确反对在数据不足时切换 SFU、盲目上 AV1 或追逐 MoQ。
推荐理由：对“换栈解决问题”倾向的纠偏，强调客户端可观测性优先于架构决策。
声网对话式 AI 引擎为旅游平台 AI 语音助手提供实时交互底座，端到端响应延迟可低至 650 ms，打断响应 340 ms，选择性注意力锁定可屏蔽 95% 的环境人声和噪声干扰。该引擎在 80% 丢包率下仍可维持语音对话，断网 3 至 5 秒时也能继续处理连接恢复后的交互，酒店政策、订单状态等业务数据仍由平台自有系统提供。
声网把 Voice Agent 的端到端延迟拆成 RTC 延迟、算法前处理延迟、ASR 延迟、LLM 延迟和 TTS 延迟，启用数字人时再加渲染延迟，并给出各段典型范围，如 RTC 150-300 ms、ASR 末字延迟 400-700 ms、LLM 首字节 250-1000 ms、TTS 首字节 100-350 ms。文章建议按轮次记录 session_id、turn_id、asr_final_ts、llm_first_token_ts、tts_first_audio_ts、interrupt_detect_ts 等字段，并分别观测 ASR 的 TTLW 与 WER、LLM 的 TTFB 与 TTFS、TTS 首帧音频、VAD 的起止检测延迟和打断成功率。选型阶段可用声网 AI 模型评测平台对比 ASR、LLM、TTS 组合的 P50、P90、P99 延迟与成本，上线后再用会话级 trace 定位瓶颈。
推荐理由：把 Voice Agent 的端到端延迟拆成 RTC、ASR、LLM、TTS、VAD 各段，并给出可采集的会话字段与仪表盘结构，适合直接对照搭建观测体系。
LiveKit 发布指南，说明 LiveKit Agents 每个任务运行在独立子进程中，由 supervisor 通过事件循环上的 ping/pong 健康检查监控，循环阻塞会导致响应延迟、进程被杀并在约 15 秒内被新实例替换。内置事件循环监控在 Python livekit-agents 1.8.1+ 和 Node.js @livekit/agents 1.9.1+ 默认开启，对 100ms 及以上的停顿告警并给出阻塞代码行，排查可用 py-spy、asyncio debug 模式和 Node.js 事件循环延迟测量。
推荐理由：LiveKit 官方梳理了阻塞事件循环的日志特征与排查手段，可对照自家 Agent 的告警和 trace 定位问题。
LiveKit 正式发布 Unity SDK v2.0.0，将其从开发者预览转为正式版本，并称该 SDK 已与现有 LiveKit SDK 达到功能对齐。开发者可在 Unity 游戏中接入实时语音、视频和 AI，用于语音聊天、音视频直播、VR 远程操控机器人以及语音 AI 驱动的 NPC。2.0.0 带来移动端和桌面端的原生平台音频、基于 DataTracks 的高频数据消息和可配置 token 源的简化鉴权；官方支持 Unity 2022.3 及以上版本，覆盖 macOS、Windows、Linux、iOS 和 Android。
推荐理由：LiveKit Unity SDK 结束开发者预览并达到与其他 SDK 的功能对齐，可据此判断现有 Unity 项目是否迁移。
LiveKit 以酒店前台参考 Agent 为例，讲解如何让语音 Agent 不脱离脚本：先用结构化提示词设定身份与护栏，再用确定性代码强制校验规则，如用 Python 做卡号长度与 Luhn 检查、用 max_tool_steps 限制工具调用链。文章强调提示词防护对蓄意攻击很弱，真正的规则必须在代码层执行。
Agora 实验室用 iPhone 13 加人工发声设备、可控网络模拟丢包、双轨录音逐帧取时、每项 n=30 的方法测试三代 ChatGPT 语音模式：GPT-Live-1 正常网络中位响应 1099ms（P90 1203ms、SD 104ms），Advanced Voice Mode 为 1304ms（P90 2318ms、SD 489ms），Standard 级联模式 5197ms；10% 上行丢包下 GPT-Live 仅增 314ms，同级丢包的 P90 仍优于零丢包的上一代；插话停止延迟中位数 1399ms 比上一代慢 498ms，但背景人声误触发从 22 次降到 1 次。
推荐理由：方法论透明、样本量与局限都交代清楚的端到端延迟实测，弱网下的对比尤其有信息量。
Cartesia 发布语音转文本模型 Ink-2，面向实时语音代理，称其在 Artificial Analysis 流式榜单上以最低词错误率排名第一，并内置语义端点检测。官方数据显示其 Time-to-Final-Transcript 为 0.1s，在 14 种英语口音的 AppTek 基准上 WER 为 8%，内部生产环境基准 WER 为 6.5%，轮次检测 F1 为 93%。Ink-2 已在 play.cartesia.ai 上线，可通过 API 使用，并接入 LiveKit、Vapi 和 Pipecat，多语言支持尚在开发中。
推荐理由：官方给出 Ink-2 在准确率、轮次检测和延迟三项指标上的对比数据，可据此判断语音代理的选型取舍。
Tavus 宣布 PAL 可像邀请同事一样加入 Google Meet：开摄像头、跟随对话并实时应答，可做会议记录、随行销售通话或主持站会；官方称 Zoom 与 Microsoft Teams 支持为下一步。
推荐理由：AI 视频智能体深度嵌入主流视频会议平台，是行业级产品动作。
腾讯云游戏用自研 Tencent-RTC 做抗抖动与网络自适应：发送端缓存视频帧、接收端按网络动态调缓冲深度，并用预测算法生成中间帧补偿丢包；传输上基于 UDP 并叠加 FEC 与 ARQ，按数据类型（游戏指令、视频帧、音频）设差异化优先级；量化表现为稳定网络下端到端 50-70ms，盛趣游戏案例做到 1080P/60 帧下延迟小于 40ms，全球部署 2000+ 边缘节点。
推荐理由：云游戏这一延迟最敏感场景的厂商实测数据与机制说明，40ms/1080P60 的案例有参考价值。
Cartesia 提出按真实用例而非实验室基准选择语音 AI 模型，指出演示中 600–800ms 的往返延迟在真实电话网络上会升至 2–4 秒、P95 达 5 秒。评估 ASR 应看完整转写时间 TTCT 而非首 token 延迟，端到端低于 200ms 对话才自然，超过 1 秒用户会重复发言；轮次检测的精确率与召回率决定打断和响应表现。
Cartesia 发布语音 AI 术语入门指南，梳理构建对话式语音 AI 所需的 20 个关键术语，涵盖 STT、VAD、TTS 等核心语音处理链路概念。文章指出，打断处理、轮次检测和语音隔离等能力决定语音代理的对话体验，其 Ink-2 STT 模型已将轮次检测内置，无需单独集成 VAD 模型。
声网开源的实时多模态对话 AI 框架 TEN Framework 把 STT、LLM、TTS、VAD、Turn Detection 等环节抽象为可插拔 Extension，用 Graph 定义数据流并并发调度，换模型只需改配置。其 Turn Detection 基于 Qwen2.5-7B 做语义级打断判断，支持中英文，传输层支持 RTC、WebSocket、SIP。按 Demo 流程配置 Agora、Deepgram、ElevenLabs、OpenAI 的 Key 后，约 20 分钟可跑通。
出海语聊房选 RTC SDK 不能拿国内测试结果做参考，应优先确认目标市场有无本地节点、弱网丢包恢复表现如何。可用 tc netem 注入 5%、10%、15% 丢包自测卡顿与断流恢复，并核查厂商节点城市列表。声网 SD-RTN 覆盖全球 200+ 国家地区，采用私有 UDP 协议，Yalla、Kumu 等大房间场景为其生产案例。
把弱网定义为高丢包（10%-30%）、高延迟高抖动、低带宽三维度同时恶化；音频侧 FEC 在 20% 丢包下几乎无感、PLC 在 60%-80% 丢包仍可懂、可降至 Opus 6kbps 在 30kbps 网络上保语音不断；视频侧自适应码率加 SVC 平滑降级、关键帧优先保护、帧率优先于分辨率；并引即构数据：音频抗 80% 丢包、视频抗 70%、抖动容忍 1000ms、带宽可压至 30kbps。
推荐理由：按音频/视频/传输/业务四层给出弱网策略清单，附厂商实测基线数据。
把弱网分为带宽抖动、高丢包、高延迟、持续拥塞四类，对应三件武器——自适应编码动态调码率与量化参数、弹性帧率从 60/120fps 平滑降到 30fps、关键帧与参考帧选择性重传；核心是用智能码控统一决策“降码率 vs 降帧率 vs 加重传”，避免编码器与重传模块策略打架导致总带宽失控。
推荐理由：讲清了多机制并发时的策略冲突与统一指挥思路，对自建弱网策略编排有启发。
文章面向产品团队讲解 AI SDK 的能力谱系，从文本、语音延伸到具备全栈数字人的会话式视频集成。
用 Ookla 2025 数据定位战场：印尼移动均速 45.01Mbps（低于东南亚均值 91.79）、外岛 3G 常态，丢包超 10%、抖动超 100ms 时音频流明显劣化；给出四件套的适用边界——FEC 适合 10%-30% 丢包且 RTT>150ms（代价 10%-30% 带宽）、NACK 要求 RTT<150ms 且丢包<10%、Opus 从 32-64kbps 降级到 8-12kbps、动态 Jitter Buffer 工作范围 60-200ms，并强调本地节点对 RTT 的实质影响与 tc netem 测试方法。
推荐理由：少见的按目标市场网络实测数据反推弱网策略的实战文，参数边界清晰可落地。
LiveKit 基于自身实时基础设施发布面向机器人的遥操作、数据采集与远程推理生产级方案（LiveKit Portal），延续其在多参与者机器人场景的布局。
推荐理由：实时音视频进入物理 AI/机器人遥操作场景的代表性产品方案。
W3C Media Working Group 于 2026-06-08 同日发布 AV1、AVC/H.264、HEVC/H.265、Linear PCM、Vorbis、A-law PCM 六份 WebCodecs 注册规范（随后 9 月又补齐 Opus 与 MP3），逐一定义各编解码器的 codec 字符串、EncodedVideoChunk/AudioDecoderConfig 描述字节及 VideoEncoderConfig 扩展；这使浏览器低层编解码 API 在视频侧主要格式的互操作语义全部落到正式工作组出版物。
推荐理由：WebCodecs 是浏览器端自研转码/推流管线的基础 API，AV1 与 HEVC 注册定稿让 Web 侧编码策略有了可依赖的规范锚点。
LiveKit 官方推出 C++ SDK 1.0，为 C++ 应用提供实时音频、视频与数据通道能力，官方定位面向机器人、低延迟 AI 推理和高性能媒体管线场景。
推荐理由：补齐 LiveKit C++ 生态的关键产品更新，直接影响机器人与端侧实时音视频开发。
文章对比两条技术路径：语聊房走 RTC/UDP 通道（端到端 100–400ms，靠 FEC/ARQ 抗抖动），直播间走 RTMP 推流 + HLS/FLV 拉流（10–30 秒，低延迟 FLV 约 1–3 秒），并以 Yalla（纯 RTC、单房 2000 人）与荔枝（CDN 直播 + 偶尔连麦）说明选型差异，指出混合架构需维护两套延迟体系、排查成本高。
Tsahi Levent-Levi 分析 Video API 四种商业模式（按分钟、按 MAU、按 GB、自建）：主流按分钟计费约 $0.004/视频分钟，一个成功的 POC 可能在 9 个月内从数千美元涨到 $80,000+/月；他建议先定商业模式再比厂商价格，并给出何时转向自建 SFU 的判断框架。
推荐理由：实时音视频规模化的成本模型少有人系统写清，这篇文章给出了可对标的数字。