成为一个进阶语音智能体开发者，你必须了解这些丨 RTE101 技术专场@RTE2025 回顾

除了本期论坛分享，你还可以阅读《对话式 AI 好奇者手册》，继续探索！

《对话式 AI 好奇者手册：给语音智能体开发者的第一课》

https://www.rtecommunity.dev/conversational-ai-for-the-curious/

在本届 RTE2025 大会上，来自产业界和学术界的多位专家深入探讨了一个 DEMO 到实际可落地的产品，必须掌握哪些实时互动与 AI 核心技术栈？

声网音视频算法工程师、TEN VAD 核心开发者林子毅、声网生成式 AI 产品负责人毛玉杰、声网音视频实验室负责人段涛、阶跃星辰开放平台技术产品经理、RTE 开发者社区布道师白宦成、RTE 开发者社区联合主理人、烟台小樱桃科技创始人杜金房 、声网研发 VP 陈若非 等技术专家、开发者和创业者，一同探索上下文工程和 Agentic AI 开发、分享了他们在各自领域的实践经验和独到见解。

RTE 开发者社区联合主理人、烟台小樱桃科技创始人杜金房和声网研发 VP 陈若非分别主持了活动主题分享和圆桌讨论环节。

林子毅：对话式 AI 中的语音技术——3A、VAD 和声纹

声网音视频算法工程师、TEN VAD 核心开发者林子毅指出，在一个对话式 AI 的整体管线中，语音技术是前置的「守门员」。用户在打电话、在办公室、在厨房，环境中的干扰、音量波动和回声就是「三大麻烦」，它们会直接导致 Voice Agent 误打断、功耗高、甚至无法正常交流。

林子毅详细介绍了如何解决这些问题：

AEC （声学回声消除）： 核心是通过时延估计、双点检测、线性回声消除和残余回声抑制四个部分，将麦克风收到的回声估算并剪掉，确保 Agent 不会听到自己说话；

ANS （自动降噪）： 采用传统信号输入（噪声估计 + 滤波器）和更先进的深度学习 AI 方法（运算量更大但效果更好）相结合，有效消除绝大多数噪声，改善信噪比；

AGC （自动增益控制）： 通过实时监测信号电平与预设电平进行比较，动态控制幅度，避免声音忽大忽小，确保音量清晰可识别；

VAD（语音活动检测）： 判断语音是否存在，并检测一段语音的开始（SOS）和结束（EOS）。

TEN VAD 则基于深度学习方法，实现了更好的性能和更低延迟。它最大的特点是 Agent Friendly：

极致轻量化：整个库最小只有 300KB，RTF 实时率只有 0.0086，推理速度极快；
高精准度：相比传统算法，TEN VAD 能够更准确地检测出两段独立句子中间的短暂停顿，这对于提升端到端响应延迟至关重要。

此外，声纹识别则用来解决注意力锁定和过滤背景干扰语音的问题，比如在机场场景，通过注册主讲人的声纹，可以过滤同事或嘈杂背景声，避免误打断。

TEN VAD: https://github.com/TEN-framework/ten-vad

「要是没有回声消除、降噪和 VAD 等前置语音技术，Voice Agent 根本不可能正常交流。」

林子毅

声网音视频算法工程师、TEN VAD 核心开发者

毛玉杰：WebSocket vs. WebRTC——对话式 AI 通讯技术之争

声网生成式 AI 产品负责人毛玉杰的分享，直言「WebSocket vs. WebRTC」这一话题易引行业误解，核心在于 WebSocket 与 WebRTC 并非直接可比的竞争技术。

他强调，当前对话式 AI 已成趋势（「风口已经让猪飞起」），技术选型应聚焦如何让「猪飞得又快又好」，即实现极致的实时性和低延迟，这是人与 AI 交互方式演进的底层逻辑。

回顾对话式 AI 里程碑，从 GPT-4o 实时交互能力的震撼亮相，到去年 10 月声网与 OpenAI 联合发布基于 WebSocket 的实时语音 API，以及国内首个 Realtime API 的推出，再到近期对话式 AI 引擎 2.0 的发布，都深刻体现了对实时性的不懈追求。

毛玉杰从产品视角出发，指出技术协议的选择最终关乎用户体验而非单纯的技术优劣。

他解释道，WebSocket 基于 TCP，适用于小数据量、状态同步等对实时性有一定要求但无需复杂媒体处理的场景，开发成本相对较低。

而 WebRTC 则是一套完整的媒体协议栈，内嵌网络传输、带宽控制、编解码等模块，为实时音视频传输而生，虽然复杂，但能显著提升用户在公共互联网上的实时互动体验。实践中，两者常以混合架构存在，如 WebSocket 负责信令控制，WebRTC 处理媒体流，以实现优势互补。

他强调，若业务本身无音视频需求，不应盲目选择 WebRTC；同时，对于构建对话式 AI 或实时 RTC 能力的开发者，应充分利用声网等成熟厂商的工程积累，避免从零自研的巨大成本与风险。

「选择协议不只是选择传输方式，而是在定义用户体验的上限。」

毛玉杰

声网生成式 AI 产品负责人

段涛：从技术指标到用户体验——AI 交互性的全面评估

声网音视频实验室负责人段涛借鉴了声网在 RTE 领域多年的经验，提出一个核心观点：「模型不应该是评出来的，而是用出来的，用户说好才是好。」 段涛指出，尽管标准的语料测试显示大模型的准确率很高（错误率 3%-5%），但基于声网的线上抽样分析，实际线上的错误率可能超过 20%，其中会有 4-5 倍的差别，关键就是错误该如何看到。

他用一个常见的 AI 交互问题作为案例：用户在说话时停顿，AI 误以为用户说完并开始回复，造成「AI 在插我的话」的现象。这种问题让用户感到思路不连贯、易疲劳。线上复杂的影响因素（设备、网络、环境）与各种「海量 Corner Case」（背景人声、口头语、口吃、特殊口音等）是造成这一鸿沟的原因。段涛认为，当前的测评方法要么是面向单一模块（如 ASR 的准确率），要么是面向任务完成率（如能不能订到票），两者都无法对后续的优化提供清晰的指导。他将对话式 AI 体验相关的能力分为三个维度：理解、表达和交互，并提出了一个连接二者的桥梁——三维评估框架：

理解能力（AI 能不能听懂）：语义准确性、情绪语气识别、在不同机型/网络下的稳定性。其挑战是需要覆盖真实场景下的公式、数字、电话号码等特定业务需求的识别，以及背景人声的干扰；
表达能力（AI 说的是不是像人）：准确度（语义是否清晰）、自然度（音色、韵律）。其挑战是自然度难以脱离人工标注，需要通过多算法打分和人工校正相结合的方式进行评估；
交互能力（互动是否有效率）：AI 响应的成功率和延迟、用户打断 AI 的成功率和延迟、AI 误打断率。其挑战是解决「我希望模型开始说话的时候就说，不希望你说你就别说」的核心矛盾。比如用户说「对」只是表达习惯，AI 不应误以为是指令而停止。

这套框架的灵活之处在于可以根据不同的业务场景调整权重。例如，智能客服更看重理解能力和信息收集准确性，而对音色自然度不那么在意；智能玩具则更看重表达能力和表现力。他们正在致力于实现测试的自动化，通过一套分离的测试设备和控制设备，实现可控的对话角色扮演，并能加入背景噪声和人声模拟。

评估的终极目标是「用户导向测试」：使用符合用户真实使用情况的数据集、设备和网络条件进行测试，并通过任务达成率和主观问卷打分来反向验证和补充客观指标。

「对话式 AI 体验相关的能力分为三个维度：理解、表达和交互。」

段涛

声网音视频实验室负责人

白宦成：实时互动 Agent 构建过程中的工具和 MCP 实践

阶跃星辰开放平台技术产品经理、RTE 开发者社区布道师白宦成从实际业务出发，深入剖析了 Voice Agent 在从 Demo 到生产过程中遇到的最大难题：巨大的延迟爆炸和交互同步问题。

Voice Agent 必须要有 ToolCall 和 MCP，否则它不过是一个「有声音的 ChatBot」。Agent 的价值在于能够去做一些事情，比如智能控制或业务系统查询。

在语音 Agent 的世界里，没有 Loading 动画，只有用户直观感受到的「卡了」，这会直接影响整个用户体验。此外，ToolCall 的实现依赖于开发者提供的函数签名，如果签名设计「奇葩」，模型的泛化能力就可能扛不住，导致 ToolCall 结果错漏百出。白宦成指出，认真设计 ToolCall 签名至关重要，它直接影响模型的指令遵循效果。他还鼓励开发者积极联系模型厂商，将自己的 Tool 整合进去，参与模型训练以提升效果。

他强调，无论是传统的 ToolCall 还是 MCP，都是解决 Agent 外部数据连接的范式。MCP 能够统一大模型连接外部数据的方式，降低接入门槛，实现功能的快速叠加。

接着，他给出了解决延迟爆炸问题的四大「干货」绝招，目标是将任何带有工具调用的对话轮次延迟阈值尽可能控制在 800 毫秒以内：

流式工具调用 + 填充词：不要等到工具执行完毕才开始回复。模型在第二或第三帧识别到需要调用某个 Tool 时，就可以直接开流式输出，同时插入填充词（如「请稍等」，或带有感知度的语句）。
并行执行 ToolCall：设计业务流程时，尽可能让模型并行执行相互不关联的 Tool（如天气和机票查询），以缩短整体时延。

3.预测性执行（小模型意图抽检）：在 ASR 结果进入主模型之前，先用一个非常小的模型进行意图判断。小模型预测到 ToolCall 后，可以先在旁路执行耗时的 Tool，等主模型推理完毕，直接返回 Tool 结果。

基础设施优化：减少 TTS/WebSocket 等各环节的证书检验、网络传输等累计损耗，尽量简化调用链路。

「Voice Agent 必须要有 ToolCall 和 MCP，否则它不过是一个『有声音的 ChatBot』。」

** 白宦成 **

阶跃星辰开放平台技术产品经理、RTE 开发者社区布道师

杜金房：AI+SIP——对话式智能体技术实践

RTE 开发者社区联合主理人、烟台小樱桃创始人杜金房，从通信技术的演进史切入，生动地回顾了从烽火台、电报到实时通信（RTC）的发展历程。他指出，尽管以 ChatGPT 为代表的大模型技术带来了革命性突破，但许多对话式 AI 的核心组件——如 ASR（语音识别）、TTS（语音合成）——早已是成熟技术。

他以早期电话营销机器人「Lenny」为例，强调了工程化思维的重要性：在没有复杂 AI 的情况下，通过巧妙的录音循环设计，同样能实现有效的对话交互，这启发我们应务实地看待技术应用。

杜金房详细阐述了其核心产品 XSwitch 的定位与实践。他认为，SIP 作为一个历经数十年考验的通信协议，尽管存在不少实践中的「坑」，但其无处不在的应用（如运营商网络、客服中心、门禁对讲）使其成为连接 AI 与现实世界通话的最佳桥梁。

XSwitch 正是这样一个基于开源构建的、可无限扩展的 SIP 交换平台，其核心价值在于「连接一切」。 它将传统的 SIP 网络与现代的 AI 技术栈无缝对接，能够灵活集成讯飞、豆包、Whisper 等多家 ASR/TTS 服务与大模型，从而快速构建智能呼入或呼出机器人。

为了应对不同客户的需求，XSwitch 提供了云服务（XSwitch Cloud）与本地化部署的硬件盒子（XSwitch Box）两种方案。后者专为那些电话线路不多、不便上云的小客户设计，实现了「即插即用」的便捷部署。

杜金房分享了一个生动的案例：其开发的 AI Agent 在致电美国客服时，能耐心等待半小时的背景音乐，直到接通人工坐席。这不仅展示了技术的实用性，也体现了他的理念——新技术并非总是颠覆，更多时候是作为一种强大的补充，去连接和增强成熟的呼叫中心系统，最终与更多合作伙伴共同构建一个融合的通信生态。

「技术好是好，但并不一定是颠覆，而是补充你欠缺的东西。」

杜金房

RTE 开发者社区联合主理人、烟台小樱桃科技创始人

圆桌讨论：从 Demo 落地到一个 RTE AI Builder 的自我修养

本次圆桌讨论主题为「从 Demo 落地到一个 RTE AI Builder 的自我修养」，其聚焦于 Voice Agent 从原型到商业化落地的关键环节、技术难点和未来趋势。声网研发 VP 陈若非担任主持人，参与讨论的嘉宾有声网生成式 AI 产品负责人毛玉杰、阶跃星辰开放平台技术产品经理白宦成，RTE 开发者社区联合主理人杜金房。

从跑通 Demo 到真正落地商用的分界线是什么？什么叫做 Production Ready？

杜金房和白宦成强调快速迭代。杜金房指出，跑通 Demo 和上线之间没有严格界限，但真正的鸿沟在于环境的适配。演示通常在安静的办公室进行，而一旦上线到真实环境并扩大规模，问题就会暴露。

白宦成建议，初创公司不应过于苛求，只要能让 5-10 个真实用户在生产环境跑一周，解决绝大多数问题，就达到了初步的上线基准。他认为，追求「扩大到很大规模才发现」的问题是「幸福的烦恼」，前期不应因此错失时间节点。

毛玉杰则提出了更高的要求：价值转化。他认为，Production Ready 的本质分界线是产品是否真正帮助客户解决了业务问题。对于对话式 AI Voice Agent 来说，要看它是否帮助客户提高了转化率、解决了实际的业务痛点。一旦价值得到了验证，后续的产品迭代才是跨过了真正的鸿沟，实现了 从「功能交付」到「价值转化」 的飞跃。

Voice Agent 开发中哪些技术点最值得关注，又有哪些难点容易被低估？

毛玉杰指出，最容易被低估的是交互体验的细节和拟人化。开发者倾向于关注模型（ASR、LLM、TTS 的串联与延迟），但忽略了人与人对话的本质。他以生物学处理语音信号为例，指出大脑皮层对语音信号的流转和理解非常复杂。影射到 AI，当前的 Voice Agent 在处理注意力锁定、延时削减以及各种网络情况下的交互细节方面，仍有很多未被注意到的地方。例如，对话中常见的「嗯」「点头」等非语言信号，AI 应该如何响应，这都是目前尚未解决的复杂难题。

白宦成提醒开发者要警惕技术栈的债务。他认为，虽然各类脚手架能快速搭建 Voice Agent 验证需求，但开发者不能止步于「能用」。大家一定要花精力研究框架底层的实现原理，不能对语音技术一无所知，否则一旦进入 Production 环节需要调优，就要花大量时间和精力来「还债」。他建议开发者要一边构建，一边研究工具的原理。

杜金房强调了参数调整的灵活性。他指出，许多 ASR 内置的 VAD 做得并不好，虽然通用级别的 Convo AI 跑起来很容易，但一旦客户提出五花八门的需求，产品就需要提供高级的参数调整能力。例如，让客户可以自由选择使用内置的 VAD、TEN VAD 还是不用 VAD。只有提供这种调整的「手段」，开发者才能根据自己的场景进行定制，确保产品的持续竞争力。

面对琳琅满目的开发框架，开发者应该如何选择？

白宦成建议分阶段选择：

从零到一（DEMO 阶段）：选择像 TEN Framework 这样分工清晰、易于上手的框架，实现快速构建；
市场验证和付费阶段（Production Ready）：回归到 「大道至简」的原则 ，选择那些封装没有那么深、有足够调优空间的框架。他强调，最差的选择是自己从头写一个并用到生产上，因为自己写的产品无法享受开源社区的红利（如 PR 参考、bug 修复），但开发者需要保留自己改造的机会和可能性。

毛玉杰提出了 「多试用」和「业务驱动」 的视角。他鼓励大家动手去试、去做评测，因为人类的喜好和产品的需求各有侧重，试了才知道哪个最符合需求。他强调，要从实际的业务场景出发，拆解出最核心的体验点，例如做情绪价值的产品可能更在意音色拟人化，做任务完成的产品可能更在意知识库构建和集成，然后根据这些核心点来选择技术框架。

杜金房认同多试用，但也建议不用试得很深，只需找到 TOP 3 进行试用即可，以避免被无限的资源消耗（如 TB 级大模型）所困扰。

AI 和 Voice Agent 的快速发展给 RTE 开发者带来了哪些机遇和挑战？未来两年的发展展望是什么？

在最后的开放式问题中，嘉宾们聚焦于技术心态、协议理解和人机交互的未来：

杜金房关注协议的演进。他告诫开发者不要盲目跟风，虽然要了解前沿技术，但做产品和应用时不要冲动。他指出，三段式架构可以覆盖大部分场景，开发者需要知己知彼，了解竞争对手的长处，但要以己之长攻彼之短，保持对各种通信协议的理解宽度。

白宦成聚焦于模型与评测体系。他鼓励开发者积极试用各家模型，即使是觉得不好的模型也要试，因为各家模型训练方法、数据和 Alignment 存在差异，会导致推理结果在真实场景中表现不同。他建议开发者构建自己的产品评测体系，不断试用、迭代和替换模型，以积极应对学术界和工业界带来的巨大变化。

毛玉杰则回到了他最着迷的人机交互体验。他认为，未来一到两年，围绕人机交互体验层面一定会迎来突破。目前的交互还处于早期，光是语音交互就已经很复杂。他认为，真正的突破点将是 AI 如何处理和响应肢体动作、眼神交流等非语言信息，将所有感官信息汇聚到一起，达到「一个眼神知道你在做什么」的具身智能体验，这将是未来人机互动体验的核心飞跃。

主持人陈若非总结，当前的 Voice Agent 领域仍处于早期，充满变化，RTE 开发者需要不断跟进并拥抱这些变化，期待明年会有更多新的技术和应用涌现。