3.5 语音交互支持
3.5 语音交互支持
本节摘要：从"打字"到"说话"是交互体验的升级。本节讲清语音交互的组成（语音转文字 → 智能体 → 文字转语音）、SDK 的语音支持方式、以及接入语音的工程考量（延迟、打断、多轮）。
阅读收获
阅读完本节，你应当能够：
- 说出语音交互的组成
- 理解 SDK 的语音支持
- 搭建语音对话链路
- 处理语音的工程细节
- 判断场景是否需要语音
一、问题与直觉
"你好，帮我查下明天航班"——语音是比文字更自然的交互方式。但语音不是"换了个输入"那么简单：它涉及**听（语音转文字）、想（智能体处理）、说（文字转语音）**三段管道。SDK 提供端到端的语音支持，让这三段成为标准链路。
为什么语音交互值得单开一节？因为它的工程难度和文字完全不在一个量级。文字交互的"单位"是消息，语音交互的"单位"是流——音频是持续到达的，用户可能说到一半停顿、可能随时打断、可能在嘈杂环境里说话。这些都会直接影响"听"的准确性，进而影响整个对话质量。
二、核心原理
2.1 语音交互的组成
三段式：ASR（听）→ 智能体（想）→ TTS（说）。其中智能体处理这一段，就是你前面学的全部内容——Agent、工具、会话、护栏，一个不少。语音只是换了"输入输出形态"。
2.2 语音的独特性
| 维度 | 文字交互 | 语音交互 |
|---|---|---|
| 输入 | 打字 | 说话 |
| 节奏 | 异步 | 实时 |
| 打断 | 不可 | 可打断 |
| 体验 | 正式 | 自然 |
| 上下文 | 文字可回看 | 听过即忘 |
"听过即忘"这条最容易被忽略：用户在语音对话里记不住长内容，所以语音智能体的回答要更短、更口语化——这不是风格偏好，是形态约束。
2.3 语音管道接入（概念）
# 概念：语音智能体 agent = Agent( name="voice_assistant", instructions="用简短口语回答，一次不超过两句。", ) # 概念：语音管道（ASR → Agent → TTS） pipeline = VoicePipeline(agent=agent) result = pipeline.run(audio_input) audio_output = result.audio # 播放给用户
真实接入时，语音管道会管理音频的缓冲、分段与流式返回。SDK 的语音能力基于实时语音接口，端到端延迟通常控制在"对话感"可接受的范围内。
三、工程实践要点
3.1 语音的工程考量
| 环节 | 考量 | 优化方向 |
|---|---|---|
| 延迟 | 实时性要求高 | 流式 ASR、边听边处理 |
| 打断 | 支持随时插话 | 检测用户新语音，中断当前回复 |
| 多轮 | 上下文衔接 | 沿用会话管理 |
| 噪声 | 识别准确率 | 降噪、近场麦克风 |
💡 关键直觉：语音交互的体验核心是"快"——延迟超过一两秒，对话感就没了。优化点集中在 ASR 与 TTS 的延迟，智能体本身的处理通常不是瓶颈。
3.2 常见卡点与对策
卡点一 打断处理：用户插话，智能体还在说 对策：检测到新语音立即中断 TTS，进入新一轮 ASR 卡点二 静音误判：停顿被当成说完了 对策：调长静音阈值，或用语义完整性判断 卡点三 专有名词识别错：航班号、订单号 对策：热词表注入 ASR，或让用户复述确认
3.3 场景判断
| 场景 | 适合语音 | 原因 |
|---|---|---|
| 免提场景（开车、做饭） | 适合 | 双手被占用 |
| 无障碍需求 | 适合 | 替代打字 |
| 复杂文档处理 | 文字更合适 | 需要回看细读 |
| 隐私敏感场合 | 谨慎 | 声音可被旁听 |
⚠️ 常见坑：把文字场景硬搬成语音。语音适合"短指令、快反馈"，不适合"长文本、细阅读"——按场景选形态，别为时髦而上。
⚠️ 常见坑：回答照搬文字版。文字版可以列五条要点，语音版念五条用户早忘了——语音回答要压缩成"一句话结论 + 一句可选追问"。
3.4 语音与智能体能力的结合
语音 + 工具：说"帮我订明天早上八点的闹钟" → 调日历工具 语音 + 会话：记住用户上次的偏好，少问重复问题 语音 + 护栏：敏感信息（身份证号）不要在语音里完整播报
语音只是交互入口，背后能用的还是全套智能体能力。设计时先想清楚"语音负责什么、工具负责什么"，再落实现有的组件。
要点串联
- 要点一：语音三段——ASR、智能体、TTS
- 要点二：SDK 提供端到端语音支持
- 要点三：体验核心是"快"，延迟决定对话感
- 要点四：支持打断是多轮语音的关键
- 要点五：适合短指令快反馈的场景
- 要点六：按场景选形态，回答要短、要口语化
高级特性全讲完，第 4 章进入工程——开发流程、调试、错误处理、性能、部署。