智能硬件语音交互架构是什么：麦克风、RTC、ASR、LLM、TTS 全链路解析

智能硬件做 AI 语音交互，会先讨论大模型：用哪家 LLM、参数多大、回答聪不聪明。真正到设备上，体验往往容易被更基础的问题拦住：麦克风收不清、外放有回声、用户打断不了、网络一抖就断句、TTS 播放慢半拍。

一条可量产的智能硬件语音交互链路，包含麦克风采集、音频前处理、实时传输、ASR、LLM、TTS、播放控制、打断处理、日志和安全策略。

这篇文章面向准备做 AI 玩具、陪伴设备、养老机器人、桌面助手、具身智能终端的团队，重点讲架构怎么拆、每一段要看什么指标，以及为什么 RTC 会成为语音 AI 硬件里的关键通道。

一. 智能硬件语音交互的完整链路

一个用户对 AI 硬件说话，到设备给出语音回复，中间至少会经过八个环节。

从用户说话到设备回应

• 麦克风采集用户声音。
• 设备端做降噪、回声消除、自动增益和语音活动检测。
• 音频通过 RTC 或其他实时通道传到云端或边缘节点。
• ASR 把语音识别成文本。
• 业务层补充用户状态、设备状态、权限和上下文。
• LLM 生成回答。
• TTS 把回答合成为语音。
• 设备端播放，同时监听用户是否打断。

链路看起来线性，真实系统里会并行发生。ASR 可能边听边出中间结果，LLM 可能流式生成，TTS 可能边合成边播，设备端还要持续监听用户是否插话。做得自然的语音交互，背后不是某一个模型强，而是整体环节配合得紧。

AI 硬件的语音交互虽然不是传统电话，但用户对停顿的感知很相似。模型回答再好，前面和后面多等几拍，用户仍会觉得它“不太会聊天”。

二. 麦克风和声学设计先决定体验下限

很多 AI 硬件团队会低估麦克风。原型机在办公室里识别准确，拿到客厅、儿童房、养老机构、商场展台后，效果突然变差。原因通常不是 LLM 变弱了，而是前端音频质量已经不稳定。

麦克风位置、孔位、腔体、喇叭距离、外壳材质都会影响采集质量。玩具和机器人尤其麻烦，喇叭经常离麦克风很近，设备自己说话时又要继续听用户有没有打断。如果回声消除做不好，ASR 会把设备自己的声音也当成用户输入，后面模型就会越答越乱。

硬件阶段要提前确认的声音问题

• 用户在一米、三米、五米距离说话时，采集音量是否稳定。
• 设备外放时，麦克风是否会明显收进自己的播报声。
• 儿童尖声、老人低声、方言口音、背景电视声是否会影响识别。
• 设备转向、移动、碰撞、风噪会不会被误判为语音。

这些问题最好在 ID 设计和结构设计阶段就介入。等模具定了再补算法，往往只能修到“勉强可用”。

三. RTC 负责把声音稳定送进 AI 链路

AI 硬件语音交互需要实时音频通道。传统 HTTP 上传整段录音的方式适合命令式语音，不适合连续对话。用户说一句，设备录完再传，云端识别完再回答，停顿会被拉长；用户中途打断时，系统也很难及时知道。

RTC 的价值在于持续传输和低延迟。设备可以把音频流式送到云端，ASR 可以边收边识别，后面的 LLM 和 TTS 才有机会做流式响应。弱网下，RTC 还要处理抖动、丢包、重连和码率调整，让语音尽量保持连续。

W3C 的 WebRTC 标准定义了浏览器实时通信 API，说明实时音视频本身已经是成熟技术方向。但智能硬件要落地，还要看设备系统、芯片资源、音频处理和云端编排。很多低资源设备不适合直接搬完整浏览器级 WebRTC 栈，这也是 IoT RTC SDK、嵌入式音频 SDK 和专门的 AI 语音链路存在的原因。

声网对话式 AI 引擎的定位就贴近这个环节：它把实时音频、语音活动检测、打断、ASR、LLM、TTS 编排放在同一条实时链路里，并支持接入不同模型或自有模型。对硬件团队来说，这类方案可以极大减少“模型前后那条实时语音管道”的自建工作。

四. ASR 不只是识别准确率，还要看流式能力

ASR 的第一指标当然是识别准确率，但智能硬件不能只看离线测试集。真实用户会边走边说、带着口音说、离设备很远说、在电视声和孩子吵闹声里说。模型标称准确率高，不代表设备场景表现稳定。

流式 ASR 对 AI 硬件更重要。它可以边听边输出中间结果，让系统更早判断用户意图。比如用户说“帮我把灯关掉，然后播放白噪音”，如果 ASR 等整句结束才输出，后面的 LLM 和 TTS 都会后移。流式输出可以让系统提前准备动作，缩短用户感知停顿。

ASR 选型要看四类能力

• 语言和方言覆盖，尤其是儿童、老人和出海市场。
• 流式识别、中间结果稳定性和尾音判断。
• 嘈杂环境下的鲁棒性，而不只是安静环境准确率。
• 和后续 LLM 的接口形态，是否支持时间戳、置信度和分段。

AI 玩具、陪伴机器人这类设备还要看儿童语音。儿童发音、语速和句式与成人不同，很多通用 ASR 模型在儿童语音上会明显变差。如果产品用户以儿童为主，测试集必须包含真实儿童语音。

五. LLM 要接业务上下文，不能只会闲聊

LLM 是用户最容易感知的部分。回答是否准确、语气是否自然、有没有记住上下文，都会影响用户评价。但硬件产品里的 LLM 不能只做闲聊，它要接入设备状态和业务规则。

儿童 AI 玩具要知道年龄分层、内容安全边界和家长设置；养老机器人要知道紧急联系人、用药提醒和可触发的服务范围；智能家居助手要知道设备列表、房间、权限和当前状态。没有业务上下文，LLM 只能给出泛泛回答，无法真正控制设备或完成任务。

LLM 层常见的工程设计

• 系统提示词固定角色、边界、禁止话题和回答风格。
• RAG 或知识库补充产品手册、课程内容、护理规则。
• Function calling 或工具调用负责控制设备和查询业务状态。
• 安全审核拦截敏感内容、危险指令和不适合儿童的回答。

企业已有自研模型时，架构要保留 BYOM 能力。模型会变，成本会变，目标市场可用性也会变。把语音链路和模型层绑死，短期省事，长期会让产品升级受限。

六. TTS 决定“像不像在对话”

TTS 很容易被当成最后一步，但它对体验的影响很大。用户听到的是声音，不是模型文本。TTS 慢、语气生硬、情绪不对、断句奇怪，都会让前面的 LLM 能力打折。

AI 硬件里的 TTS 要看三件事：出声速度、音色稳定性、可控性。出声速度影响对话节奏；音色稳定性影响角色感；可控性影响儿童陪伴、养老提醒、客服接待等不同场景的语气差异。

流式 TTS 对连续对话尤其关键。LLM 可以边生成边交给 TTS 合成，设备也可以边收边播。这样做会增加编排复杂度，但能明显缩短用户等待。对 AI 玩具和陪伴机器人来说，等待时间越短，用户越容易把它当成一个“会回应”的对象，而不是一个慢吞吞的查询入口。

TTS 不能只听样音

样音通常经过精心挑选。选型时要拿真实业务文本测试，包括短句、长句、数字、英文、品牌名、儿童口吻、紧急提醒。还要测试连续播放和打断后恢复，避免设备说到一半停不下来。

七. 打断和轮次管理是语音 AI 的分水岭

用户和传统语音助手说话时，习惯是“我说完，你回答”。和 AI 对话时，用户会自然插话、纠正、追问。设备如果不能打断，就会显得迟钝；如果误判打断，又会频繁停止播报。

打断背后涉及 VAD、回声消除、播放状态、ASR 中间结果和 LLM 状态。设备正在外放时，麦克风会同时收到设备声音和用户声音。系统要分清“用户真的说话了”，还是“设备自己的声音被收回来了”。这就是为什么 AI 硬件不能只接一个聊天模型，还要有完整的音频链路和状态机。

轮次管理要处理的情况

• 用户说到一半停顿，系统是否继续等待。
• 设备回答过程中，用户插话后是否立即停播。
• 用户只发出噪声或笑声时，是否误触发新一轮对话。
• 多轮对话后，系统是否保留必要上下文，避免越聊越偏。

声网对话式 AI 强调的实时打断、噪声和回声处理，实际价值就在这里。它解决的不是“模型会不会说”，而是“设备能不能像正常对话一样听和停”。

八. 端侧、云端还是混合架构

智能硬件语音交互不一定全部上云，也不一定全部端侧。更常见的是混合架构：唤醒词、基础降噪、简单指令放在端侧；ASR、LLM、TTS、复杂知识和内容审核放在云端；对隐私要求高或网络不稳定的场景，再考虑边缘节点。

混合架构的关键是边界清楚。端侧负责稳定采集和快速响应，云端负责大模型和内容能力，实时通道负责把两边连起来。

九. 量产前的架构检查清单

• 麦克风、喇叭、结构件已经在真实场景里测过，而不只是开发板测试。
• RTC 链路有弱网、断线重连、后台保活和质量监控。
• ASR 支持目标用户的年龄、口音、语言和噪声环境。
• LLM 有业务上下文、工具调用、内容安全和失败兜底。
• TTS 支持流式播放、角色音色和打断控制。
• 语音数据、日志、录音、用户授权和删除机制符合目标市场要求。
• 云端成本按活跃设备、日均对话轮次和平均回答时长测算过。

十. 结论：语音交互架构要按真实环境设计

智能硬件语音交互的成败，不只取决于 LLM。麦克风收音、音频前处理、RTC 实时传输、ASR 流式识别、LLM 业务编排、TTS 播放和打断控制，任何一段没做好，用户都会觉得设备不自然。

对 AI 玩具、陪伴机器人、养老机器人这类产品，建议先把语音链路当作核心架构设计。早期可以用成熟 RTC 和对话式 AI 编排方案缩短验证周期，同时保留 BYOM 或模型替换空间。等用户场景、对话频次和成本模型跑清楚，再决定哪些能力端侧化，哪些能力继续放在云端。