网络研讨会回顾：让文本聊天机器人拥有自然人声
- 发布时间
- 最近更新
收听收听本文
聊天智能体已成为企业软件技术栈的标配。大多数公司已有一个，或正在构建一个。但较少有人想清楚：当用户更想直接说话时，该怎么办。
语音带来的改变不止是便利性。用户会通过语气表达挫败、紧急和困惑，而这些信息在文本中会完全丢失。输入“我的订单还没到”的客户，与带着明显焦虑说出这句话的客户，传递的是不同信号——而只能阅读文本记录的智能体，只掌握了一半信息。
如今大多数团队的问题已不是是否要加入语音，而是如何在不重建现有功能的前提下实现它。
在 线上研讨会：为文本聊天机器人加入自然人声中，Paul Asjes（开发者体验）、Bhargavi Bhatt（客户体验）和 Fergal Burnett（产品营销，ElevenAPI）介绍了为现有智能体添加语音时面临的技术现实，以及实际可用的集成方案。
为什么用语音构建比看起来更难
核心挑战之一是轮次管理。人类能通过语调、节奏和上下文判断对方是否说完，但语音活动检测（标准方法）只能检测静音。
结果往往是系统把每一次停顿都当成开口说话的信号：频繁打断、在用户话说到一半时截断，并把自然的犹豫当作完整句子来回应。
技术上能用，对话上却一团糟。
上下文是问题的另一半。每轮都将对话历史传给 LLM 虽有必要，但还不够。同样的话会因说话方式不同而含义不同——如释重负地说“我没事”和带着挫败感说“我没事”，文本记录相同，互动却不同。忽略这一维度的语音系统，无论单个模型多强，听起来总会略显不自然。
还有工程维护成本。自行管理语音编排的团队，需要持续维护轮次管理逻辑、打断处理和延迟分析，这不是一次性开发。
如何为现有智能体添加语音
最简洁的方法是采用双 WebSocket 架构。
- 一条连接在客户端与 ElevenLabs API 之间运行，另一条在服务器与 ElevenLabs API 之间运行
- 用户对着麦克风说话，音频发送至 ElevenLabs API，在那里转写后再发送到服务器
- 服务器将从 ElevenLabs API 获取的完整对话历史提供给 LLM，流式响应再返回进行语音合成
- 这可在 LLM 完成生成前开始，从而保持较低的首字节延迟
关键集成点是 onTranscript 方法，它会在每轮结束时触发，并将完整对话历史传给 LLM。
会话开始时使用 contextualUpdate 可将用户切换到语音前在文本对话中的内容一并带入，让同一个智能体跨两种模式工作且不丢失上下文。
构建时有几点值得注意：
- 在语音场景中，LLM 的选择比聊天场景更重要。 深度推理模型即使回答质量更高，也会产生停顿，在音频中听起来像不自然的犹豫。对于实时语音，更快的模型在感知质量上几乎总是更胜一筹。
- 音频应使用 WebRTC，而非 WebSocket。 WebRTC 内置回声和噪声消除，在移动设备或嘈杂环境中尤为重要。使用 WebSocket 传输音频则意味着需要自行处理这些问题。
- 不要让用户选择语言。 这会打断对话流程。更好的模式是从最初几秒语音中检测并锁定语言，同时支持自然切换，无需用户进行任何操作。
- 将轮次管理模型与 LLM 分开。 让 LLM 判断用户是否说完，会为每一轮增加延迟和成本。专用的轮次管理模型处理得更快、更准确，值得在架构中作为独立组件对待。
需要自行管理多少基础设施
正确答案取决于现有条件。如果已有可用的聊天智能体，在其上添加语音层（保留 LLM、编排和业务逻辑）通常是最快、风险最低的路径。
无需重建任何东西，只是在已有功能上添加音频接口。
如果需求扩展到电话系统、部署渠道管理、内置测试和分析，将更多技术栈交给语音智能体平台会更合理。这两种方式并不冲突——团队可以先从轻量级语音层开始，随着使用场景成熟，再逐步加入平台功能。
演示：为现有聊天机器人添加语音
本演示展示一名用户正与基于文本的旅行规划聊天机器人对话，为日本之行咨询街区和美食推荐。
演示内容：
- 在不修改底层智能体的情况下，为聊天机器人扩展了语音层。
- 用户在对话中途从输入文字切换为说话，智能体在两种模式间保留了完整上下文。
- 用户说荷兰语，智能体自动检测到语言切换。
- 智能体被打断后，用户要求它在句中切回英语；它做到了——还在未被提示的情况下，用略带荷兰口音的英语完成了回答。
- 在整个对话中，打断检测让用户能自然地插话，无需等智能体说完。
重要原因：
演示展示的并非专门构建的 语音智能体。而是一个原本就能工作的文本智能体，上面加了一层语音层。上下文处理、语言检测和打断行为都来自语音层，底层文本智能体没有变化。
观看完整活动
在 这里观看完整研讨会。
.webp&w=3840&q=80)
