LiveKit Agents 推出答录机检测(AMD):外呼自动区分人声、语音信箱与 IVR
LiveKit 为外呼语音 Agent 增加答录机检测能力(AMD),自动识别接听方是人、语音信箱还是 IVR 菜单并路由到对应行为,支持自动问候、留言与按键导航。
推荐理由:外呼语音 Agent 落地的关键工程细节,直接影响电话场景接通质量。
LiveKit 为外呼语音 Agent 增加答录机检测能力(AMD),自动识别接听方是人、语音信箱还是 IVR 菜单并路由到对应行为,支持自动问候、留言与按键导航。
推荐理由:外呼语音 Agent 落地的关键工程细节,直接影响电话场景接通质量。
Cactus 开源从 Gemini 蒸馏的 26M 参数函数调用模型 Needle,消费级设备上预填充 6000 tok/s、解码 1200 tok/s;核心观察是工具调用本质是检索与组装而非推理,因此采用纯注意力加门控结构、完全去掉 FFN。
推荐理由:端侧函数调用模型的代表性工作,结构取舍结论对端侧 AI 有普适启发。
双耳渲染通过HRTF模拟声音到双耳的传播过程,用普通耳机实现前后上下三维定位,区别于仅有左右维度的立体声和依赖多音箱的环绕声。其实现分双耳录音与双耳合成两类,后者灵活可实时调整声源,但受限于HRTF个性化、头部追踪缺失及多声源卷积的算力开销。
发送端同时编码 1080p/720p/360p 三路流(约 2Mbps/1Mbps/300Kbps),SFU 按订阅关系只转发合适的一路;文章覆盖 SDP 的 ssrc-group:SIM 与 RID 协商、setParameters 编码参数配置、切换时的 PLI/FIR 关键帧请求优化,以及与 SVC 在带宽消耗和兼容性上的对比。
推荐理由:完整覆盖 Simulcast 从协商、实现到 SFU 转发的工程细节,并给出移动端编码负担的权衡。
区分容量探测(主动加压测可用带宽上限)与被动估计(借 ICE 阶段 STUN/TURN 消息推断),强调探测目标应与实际通话服务器同节点、控制在 1-3 秒内、可后台预探测并设 30 秒级缓存有效期;并给出根据探测结果调整编码参数、提前提示用户、通话中被动监测加主动探测的闭环做法,以及 NAT 超时、移动网络切换对探测准确性的影响。
推荐理由:弱网自适应的感知基础,方法、参数与坑位都讲得比较完整。
针对“一会话一端口”与有状态 ICE/DTLS 会话在 Kubernetes 下的扩容冲突,OpenAI 将数据包路由与协议终止分离:Relay 只做无状态 UDP 转发并借 ICE ufrag 编码路由信息实现首包确定性投递,Transceiver 用 Go+Pion 运行完整 WebRTC 端点;该架构已全量上线,支撑 9 亿周活用户的实时媒体流量,客户端无感知。
推荐理由:罕见的基础设施级披露,展示超大规模实时语音服务的 WebRTC 架构取舍与开源栈的生产验证。
以 10 人会议量化三种架构的带宽与计算分布:P2P 每人需维护 9 条连接(约 18Mbps 上行),SFU 把客户端上行降到 1 路但服务端产生约 100Mbps 转发量,MCU 客户端压力最小但编解码计算成本最高;并给出 Simulcast/SVC、分层 SFU、CDN+RTC 混合等增强方案与适用场景。
推荐理由:用具体数字讲清三种媒体服务器架构的成本结构与选型逻辑,是 RTC 架构选型的完整参考。
把首帧时间拆为信令连接、ICE 协商、设备初始化、编码传输、解码渲染五段分别埋点统计;优化手段包括信令就近部署与预连接、Trickle ICE 边收集边检查、进入大厅即预初始化摄像头、首帧降码率与优先传输、以及进度提示与头像占位;并分场景给出策略——1v1 追求绝对速度、多人会议分批加载防设备过载、直播权衡首帧与缓冲。
推荐理由:首帧优化的完整方法论,分段统计与分场景策略可直接用于体验优化。
LiveKit Inference 正式支持声音克隆:克隆一次后可跨多个 TTS 供应商使用,并在生产环境中提供自动 fallback,为语音 Agent 定制音色。
推荐理由:语音 Agent 音色定制与供应商解耦的实用能力更新。
按场景给出指标优先级:强交互场景延迟是第一杀手(端到端超 400ms 对话节奏被破坏),内容消费场景卡顿最致命,音频质量敏感场景丢包率需严控;并说明三者连锁反应——丢包超 10% 时卡顿率通常同步上升,以及声网在教育、社交、会议场景的分层保障策略(大班课教师端 400ms 内、学生端 CDN 3-5 秒)。
推荐理由:把延迟、丢包、卡顿三个指标放进场景比较优先级,对质量监控体系设计有直接参考价值。
按 ITU-T P.800 给出 MOS 五级划分(4.0 以上适合商用、3.5 以下急需改进),介绍 PESQ、POLQA、VISQOL、VMAF 等客观算法与 E-model(G.107)估算公式;文中称其水晶球平台用改进 E-model 加机器学习预测 MOS、准确率 90% 以上,并引用“MOS 每降 0.5 分用户流失率上升 20%-30%”的结论。
Chrome 148 将视频与音频元素的延迟加载纳入默认功能集,此外还包含 CSS 名称限定容器查询、Prompt API、WebRTC 数据通道始终协商等更新。
推荐理由:媒体元素 lazy loading 进入稳定版,影响视频站点的加载策略与带宽优化。
LiveKit 对照级联管线(STT-LLM-TTS)与实时端到端(S2S)模型在延迟、工具调用、话轮检测、语音自然度、可控性与调试、成本、合规与电话场景上的差异:实时模型在情绪与韵律感知、串行开销上有结构优势,但工具调用准确率与可定制性较弱;管线在每层可观测、可替换、可在文本层脱敏 PII、可做区域数据驻留上更可控,但需要靠流式重叠(部分转写进 LLM、token 边到边进 TTS)才能压到接近实时模型。文章另给出两种混合方案:realtime 模型配独立 STT,以及半级联(realtime 只出文本、由独立 TTS 出声)。并指出电话网络为 8kHz G.711 音频,而实时模型多按 16–48kHz WebRTC 音频训练,呼叫中心场景管线通常更可靠。
推荐理由:语音 Agent 架构选型的系统性对照,覆盖延迟、工具调用与合规等实际决策维度。
LiveKit 给出观察者模式(observer pattern)的完整实现:通过 AgentSession 的 conversation_item_added 事件旁路监听转录,用更强、可更慢的独立 LLM 异步做策略分类,再以 update_chat_ctx 把护栏指令作为系统消息注入主 Agent 上下文,主 Agent 在下一轮生效,全程不阻塞对话;必要时观察者可直接结束通话或接管控制。示例中主会话使用 gpt-4.1-mini、观察者使用 gpt-4.1,并以网约车乘客被司机要求线下现金支付的违规场景演示分类与响应分离。文章还列出三项工程细节:同一违规类型每会话最多注入一次、并发保护确保同时只跑一次评估且不丢用户轮次、以及 JSON 解析失败的兜底。
推荐理由:把安全策略与对话模型解耦的可复用工程模式,直接缓解复杂护栏挤占对话能力的问题。
LiveKit 推出 Agent Console 实时调试界面,可在一个面板中查看语音 Agent 的时延、工具调用、SIP 参与者、打断、RPC 与转写文本等状态。
推荐理由:语音 Agent 可观测性工具的迭代,开发调试体验的重要补充。
YouTube Live 更新四项能力:横屏直播也可收礼物并扩展至加拿大、韩国等更多市场,Super Chat/礼物触发个人无广告窗口,互动高峰自动暂停广告,并支持横竖屏同时开播且共用一个聊天室——官方披露 2025 年美国 30% 以上直播观看时长来自联网电视。
推荐理由:YouTube 直播形态与变现机制的重要调整,CTV 占比数据对行业有参考意义。
LiveKit 系统梳理语音 AI 方案中各环节的潜在时延来源,并说明应优先处理哪些部分,是官方给出的时延优化方法论。
推荐理由:语音 Agent 时延优化的官方框架性指南,工程参考价值高。
针对家庭摄像头、割草机等天然弱网部署场景,声网以 SD-RTN 为骨架做四层对抗:秒级网络感知与动态路由、秒级降码率加渐进恢复、FEC+NACK 双保险(称音频可抗 80% 丢包、视频 40%)、以及首帧关键帧优化;对外指标包括 80% 丢包下音视频流畅、设备 5 秒连通率 99.5%、出海首次激活成功率 >99.9%,SD-RTN 全球延时中位数 <76ms。
推荐理由:厂商披露的极端弱网量化指标与全链路对抗逻辑,对 IPC/IoT 类产品选型有直接参考。
LiveKit 开源 livekit-wakeword,支持一条命令从零训练自定义唤醒词模型,官方称误报较 openWakeWord 低 100 倍,并提供 ONNX 与 Home Assistant 兼容。
推荐理由:端侧唤醒词开源工具的实用更新,对语音 Agent 前端链路有价值。
data tracks 把任意二进制帧接入 LiveKit 的 track 基础设施,面向遥操作、传感器与遥测场景:SFU 按订阅选择性转发,走无序丢失容忍的 WebRTC data channel,采用 12 字节自定义 RTP 风格包头以吃满 MTU,房间内并发轨道理论上限 65,535;已支持 JS、Rust、Python、C++、Unity SDK。
推荐理由:把 RTC 的选择性转发能力扩展到非音视频数据,对机器人与遥操作类实时应用是实用的能力更新。
LiveKit 介绍 subagent delegation(又称 talker-reasoner、快脑慢脑)模式:每个会话轮次由延迟优化的主 Agent(示例用 google/gemma-4-31b-it)处理,需要多步推理或慢工具的任务交给后台推理模型(示例用 google/gemini-3.1-pro),两者仅通过一个异步工具连接——主 Agent 调用后首次进度更新即释放对话,可继续应答或追问,子 Agent 结果在空闲时以追加回复返回,且会话历史不进入子 Agent 以保持轮次成本低。文章同时给出不适用情形:答案需先核实(价格、医疗建议)、单个快模型已够用、主 Agent 无事可做只能念填充话术、以及通话普遍短于 30 秒。
推荐理由:面向长耗时推理的语音 Agent 编排模式,给出了可落地的分工与适用边界。
声网把首帧定义为“视频第一帧在本地渲染显示”的结果指标,从关键帧触发、建链协商、路径选择、终端渲染四处下手:建议引擎提前创建初始化、enableVideo 前设好编码配置,参考最佳实践后 Windows/macOS Chrome 首帧最低可降到 300ms 以内;方案整体给出 99.9% 连通成功率、SD-RTN 覆盖 200+ 国家、全球延时中位数 <76ms、80% 丢包下仍流畅。
推荐理由:有明确数字的首帧优化案例,且强调弱网与跨国条件下的首帧成立概率。
Gemini 3.1 Flash Live 通过 Gemini Live API 在 Google AI Studio 开放预览,官方宣称较 2.5 Flash Native Audio 在延迟、可靠性与自然度上有台阶式提升:嘈杂环境下工具触发更稳、复杂系统指令遵循更强、可识别音高语速等声学细节,实时多模态对话支持 90+ 语言。
推荐理由:Gemini 实时语音模型代际更新,是语音 Agent 平台侧最重要的供给变化之一。
WebKit 在 Safari 26.4 加入 WebTransport,面向低延迟场景(多人游戏、实时协作、视频会议);macOS 上 getUserMedia 可同时采集多路麦克风并动态把已有采集迁移到合适处理单元、同时管理回声消除,便于做播客工具与多路录音;此外增强字幕外观自定义(字号、颜色、背景等)。
推荐理由:WebTransport 落地与多麦克风采集是实时音视频在 Safari 上的能力补齐。
AOMedia 发布 SVT-AV1 v4.1.0,重构 MD、EncDec 与熵编码内核,并提升静态图像编码效率。该版本调整了 M3 及以下预设的色度 Wiener Filter 级别,优化静态图像屏幕内容编码,同时修复了单进程多实例编码器挂起等问题。
文章指出把原始音频推过 WebSocket 会继承 TCP 的队头阻塞——单包丢失即让接收端停滞数百毫秒,后续音频积压后突发播放,破坏对话节奏;而 WebRTC 为实时媒体设计,在丢包恢复、抖动缓冲与拥塞控制上开箱即有,作者将其定位为“demo 能跑、生产会垮”的架构差异。
推荐理由:从协议特性出发解释语音 Agent 传输层选型,对自建实时链路的团队有直接参考意义。
Chrome 引入浏览器发起的自动画中画:对未注册媒体会话操作处理程序的网站,切标签页时也可自动弹出视频 PiP;触发条件严格限定,包括媒体两秒内有声、未使用摄像头/麦克风、用户媒体互动指数超阈值等。
推荐理由:浏览器播放器行为的重要变化,视频/音乐类 Web 应用需关注触发条件与隐私设定。
FFmpeg 8.1 "Hoare" 小版本发布,新增 xHE-AAC Mps212(实验性)、经 libmpeghdec 的 MPEG-H 解码、EXIF 元数据解析和 LCEVC 元数据解析转发,并加入基于 Vulkan 计算的 ProRes 编解码与 DPX 解码、D3D12 H.264/AV1 编码及 scale_d3d12 等滤镜、Rockchip H.264/HEVC 硬件编码。该版本还包含大量内部改动与缺陷修复,Vulkan 计算编解码器和部分滤镜不再依赖运行时 GLSL 编译,swscale 重写的前期工作正在推进。
推荐理由:FFmpeg 8.1 汇总了解码器、Vulkan 与 D3D12 硬件编解码及新滤镜等变化,可据此判断升级与硬件加速路径。
Tavus 发布 Raven-1 多模态感知系统,将音频、视觉与时间动态统一处理并实时对齐,通过语调、表情、迟疑和语境判断用户真实意图,而非仅依赖文字转写。此前其 Raven-0 已让 AI 具备解读视觉语境的能力。该系统针对传统对话 AI 将语音转为文本后丢失语调、节奏、非语言声音和情绪变化等信息的问题,主张情绪是连续且分层的,无法归入固定类别。
Pipecat 团队发布面向实时语音智能体的 STT 基准,在 1000 条真实人类语音样本上测试 10 家 STT 服务,同时衡量转写延迟(TTFS)与语义准确率。中位延迟上 Deepgram Nova 3(247ms,1.62% WER)、Soniox(249ms,1.29% WER)、Speechmatics(495ms,1.07% WER)位于帕累托前沿。基准用 Claude 做语义 WER 评估,只统计会导致 LLM 理解不同的错误,并强调 P95 延迟与 finalization 支持比中位数更影响对话体验;代码已在 GitHub 开源,Pipecat 0.0.102 起可设置 ttfs_p99_latency 参数。
推荐理由:Pipecat 团队用 1000 条真实语音对比 10 家 STT 服务的延迟与语义准确率,并给出可自行复现的基准工具。
Daily.co 在 NVIDIA DGX Spark 上完成了开源 Smart Turn 语音轮次检测模型的训练,耗时约 61 分钟,与 NVIDIA L4 的 79 分钟和 RTX 5060 Ti 的 53 分钟大致相当。借助 128GB 统一内存,训练批次大小可设为 2000,但需改用 Arm 版依赖并启用 torchcodec 的 aarch64 nightly 构建。
OpenMOSS 的对话式 TTS 项目 MOSS-TTSD 打上 v0.7 标签,release 说明仅注明这是 v1.0 迁移前的存档版本(Archive v0.7 before v1.0 migration),未列出具体功能变更或指标。
YouTube 宣布自动配音面向所有创作者开放并扩展至 27 种语言:2025 年 12 月日均超 600 万观众观看 10 分钟以上自动配音内容;Expressive Speech 在英法德等 8 种语言上线以保留情绪表达,同时新增观众偏好语言设置与音乐/静音视频智能过滤,唇形同步处于试点阶段。
推荐理由:全球最大视频平台的 AI 配音规模化数据与功能边界,是配音行业与 AI 增强的风向标。
Daily 发布语音智能体基准 aiwf_medium_context,测试文本模式 LLM 与语音到语音模型在约 30 轮长对话中的工具调用、指令遵循和知识引用,源码已在 GitHub 开源。结果显示已有三个模型在该基准上各项指标达到 100%,但都太慢,无法满足语音智能体所需的 1500ms 以内语音到语音响应(约对应文本模型 700ms TTFT);生产中最常用的仍是 GPT-4.1 和 Gemini 2.5 Flash,AWS Nova 2 Pro 在性能与延迟上与之持平。语音到语音模型中 Ultravox 0.7 表现突出,GPT Realtime 通过率为 86.7%,低于 GPT-4.1 的 94.9%。
推荐理由:Daily 公开语音智能体基准的源码与结果,可看到长多轮对话下模型能力与延迟之间的取舍。
LiveKit 于 1 月 22 日宣布由 Index Ventures 领投的 1 亿美元 C 轮融资,Salesforce Ventures、Hanabi Capital 及老股东 Altimeter、Redpoint 跟投,估值 10 亿美元;其 Agents 框架月下载超 100 万次,网络每年承载数十亿次语音 Agent 通话,并已与全球电话运营商直连 PSTN;资金将用于扩展面向语音 AI 的算力、存储与网络服务。
推荐理由:实时音视频基础设施公司在语音 Agent 浪潮中的标志性融资,印证 RTC 云服务的价值重估。
SRT 基于 UDP 引入序列号与时间戳,用选择性自动重传替代 TCP 的顺序阻塞重传以避免队头阻塞,并可在配置的延迟窗口内换抗丢包能力;协议层内置 AES-128/256 端到端加密、传输层统一时间基准做音视频同步、仅出站连接简化防火墙穿透,还持续监测丢包/RTT/带宽/抖动以自适应调整;定位为专业直播与远程制作的低延迟传输方案。
Vidstack 作者回顾从 Vime 到 Vidstack 的 6 年:累计 90 亿次 CDN 请求、700 万次 NPM 下载、6200 个 GitHub Star 与 200 多个版本。核心结论是浏览器媒体元素的事件与状态不一致(事件可能不触发或连续触发),因此 Video.js v10 放弃插件式架构,改为编译期组件与可预测的状态流。
推荐理由:主流开源播放器 v10 重构的一手复盘,指向浏览器媒体事件模型的固有坑。
把抗弱网能力分为四层:发送前加固(抗错编码、I 帧最高保护等级的不平等保护、FEC 冗余)、传输中动态适配(实时探测带宽/丢包/延迟/抖动并调码率、按延迟预算决定是否重传)、接收端补救(运动补偿错误隐藏、FEC 解码恢复)、系统级协同(Wi-Fi 与蜂窝多路径传输、按接收者网络选发低码率高保护流)。
声网推出对话式 AI 引擎,主打 2 行代码、15 分钟快速构建 AI 客服智能体,集成 ASR、NLP、LLM 与 TTS 全链路。其端到端响应延迟控制在 650 毫秒以内,打断响应为 340 毫秒,并可抑制高达 95% 的环境人声与背景噪声。接入需开通服务、集成 v4.5.1 及以上实时互动 SDK,并配置 LLM 与 TTS 供应商信息。
从协议本质对比两种方案:RTMP 基于 TCP,网络抖动时反复重传导致数秒至十几秒延迟;声网基于 UDP 私有协议加全球 200 多个节点调度,平均延迟 200-800ms、抗丢包率称可达 70%-80%;文中给出维度对比表(延迟、抗丢包、连麦体验、全球覆盖、成本)与大型发布会、电商带货、出海三类场景的选型建议。