小智的对话大脑：唤醒 → ASR → LLM → TTS 这条链路怎么串
本文讲解原理与流程、引用关键片段并注明出处，版权归原作者，遵循其开源协议；一切以上游仓库最新版本为准。
上一节联网你把小智的"神经"接通了——板子能连上服务端、把音频推上去、把结果收回来。管子铺好，这一节让水真正流起来：你喊一声"小智"到它开口答话，中间那条链路在小智里到底怎么一环扣一环串起来。
L4 那三节（唤醒词、ASR/TTS、大模型）已把每一环单独讲透，原理这里不重复。这一节只干一件事——把四环放回小智这台真实设备，看它们怎么协作、谁在本地谁在云端、以及小智为"不让你等得难受"做了哪些设计。 讲的是链路设计，不是把源码搬一遍。
这一节讲小智对话链路的设计思路，会引用它的关键设计选择，但不逐行贴源码。小智（78/xiaozhi-esp32）代码遵循 MIT 协议开放，版权归原作者 78 及社区贡献者。任何具体的协议字段、状态机命名、时序细节，一律以仓库最新版本为准——我讲的是"为什么这么设计"，不是"照抄这段代码"。
先把这条链路的地图摆出来
一句话说清小智一次对话发生了什么：你喊"小智"（唤醒）→ 它醒来录音、边录边上传（ASR）→ 服务端把文字喂给大模型生成回答（LLM）→ 回答合成成语音、边合成边流回来播放（TTS）。 四个环节一条线走到底。关键在于这条线从哪里断成"本地"和"云端"两截——小智的分工非常清晰，也是它设计上最值得学的一点：
┌───────── 板子本地（ESP32-S3）─────────┐ ┌──── 云端 / 服务端 ────┐
│ │ │ │
你喊"小智" → 唤醒词检测(WakeNet) → 醒来 → 麦克风录音 → 流式上传 → ASR → 文字 → LLM → 回复文字 → TTS → 音频流
│ │ │
你听到回答 ← 喇叭播放 ←──────────────── 流式下发 ←──┘ └──────────────────────────────────────────────┘
这条虚线的位置就是小智整套设计的骨架：唤醒留本地，三个重活（ASR、LLM、TTS）都甩到云端。为什么这么切，就是接下来要讲透的。
唤醒为什么必须留在本地
小智全天候待命，麦克风一直开着。若把每一帧声音都往服务器送、让云端判断"有没有人在叫我"，那等于这台设备在直播你屋里的一切声音——费流量、毁隐私、还得一直占着网络。所以小智把唤醒词检测放在板子本地跑（乐鑫官方离线方案 ESP-SR 里的 WakeNet，原理见唤醒词那节）。放到小智这台设备上，本地唤醒承担三个别处替不了的职责：
- 省电常驻：唤醒模型极小，只回答"刚才那声像不像'小智'"这一个是非题，能塞进 ESP32-S3 长时间待命，不必为待命一直烧网络与云端算力。
- 隐私闸门：不喊它，声音就不出门。这道闸门在本地，从物理上决定"你没叫它时它不上传"，比任何隐私承诺都实在。
- 决定"什么时候开始听"：只有唤醒判定为"是"，小智才接通上云的链路、开始录音上传。唤醒是整条链的总开关。
这也是为什么小智适配 ESP32-S3 这类带 AI 指令加速的芯片——本地跑带降噪的唤醒对算力内存有门槛，选错板子这道闸门就立不稳。
ASR、LLM、TTS 为什么都甩给云端
醒来之后，剩下三环——听懂你说什么（ASR）、想出怎么回答（LLM）、把回答念出来（TTS）——小智全放到云端。原理ASR/TTS 那节讲过，落到小智更直白：ESP32-S3 只有几百 KB 量级的 RAM，装不下也跑不动像样的 ASR/LLM/TTS 模型。 强塞一个裁剪版进去识别不准、回答弱智、合成像机器人念字，体验差到没法用；而云端能上大模型、新模型，识别准、回答有料、合成自然。这笔账没什么可犹豫的：轻的（唤醒）留本地，重的（ASR/LLM/TTS）上云。
小智在设备这头因此变得很"薄"——主要干两件事：把录好的音频流式推上去，把合成好的音频流式收下来播，真正的智能都在服务端。这个"薄设备 + 云大脑"的分法正是下一节自建后端能成立的前提：设备只收发音频、不绑死哪家 ASR/LLM/TTS，你才能把"大脑"整个搬回自己的服务器、三样都换掉。
代价小智也一并背着：依赖网络（断网就哑）、有网络延迟、语音要离开设备。前两条正是最后"时延优化"要对付的，第三条是你做产品时必须对用户讲清的隐私底线。
这条链路怎么在设备里串起来：一次对话的时序
光知道"谁在本地谁在云端"还不够，得看它们在时间上怎么接力。一次完整对话拆成小智设备侧的动作序列：
- 待命：唤醒模型在本地一小段一小段地听麦克风，别的声音一概不理。
- 唤醒触发：某段声音"像'小智'"超阈值，触发唤醒。状态从"待命"切到"聆听"，通常给个反馈（亮灯、表情、提示音）让你知道它醒了。
- 录音 + 流式上传：设备开始录音，边录边通过上一节建好的连接把音频片段往服务端送，而非等你说完整句再打包。这步还靠 VAD（语音活动检测）判断你这句话说完了没——一判定"说完了"就结束录音。
- 等云端接力：服务端 ASR 转文字 → 喂给 LLM 生成回答 → 交给 TTS 合成，三步在云端串着跑，设备这头等音频回来。
- 流式播放：TTS 合成的音频边合成边流回设备，设备收一段播一段。你听到开头那几个字时，云端可能还在合成后半句。
- 回到待命：一轮结束，设备切回待命，等下次唤醒。
关键在于——它不是"做完一步再做下一步"的接力赛，而是尽量让多个环节同时在动的流水线。 第 3 步你还在说、云端 ASR 已在识别前半句，第 5 步你已在听回答、云端可能还在合成。小智靠这套"边做边传"，把等待感从"明显卡顿"压到"接近自然对话的停顿"。
时延从哪来，小智怎么把它压下去
一次"喊它 → 听到回答"，端到端常见落在一两秒到几秒之间（大模型那节拆过这笔账）：时间花在网络往返、ASR 转写、LLM 推理、TTS 合成四处。做语音对话这个量级能接受——人和人聊天也有停顿——但小智仍在几个点上刻意抠时延：
- 流式贯穿全程：压时延最大的一招。上传边录边传、下发边合成边播，不让总计算量变少，但让你更早听到第一个字。所以小智每一环都优先走流式。
- 唤醒本地、秒级响应：唤醒不上云，省掉"判断你有没有叫它"这趟网络往返，你喊完到它醒几乎没有网络延迟。
- VAD 精准切句：VAD 判准"你说完了没"，直接决定云端多早能开始干活——切得准整条链起跑就早。
- 长连接省握手：上一节建的持久连接（而非每次对话重新握手），省掉反复建连的开销。
非流式是"你说完 → 等 ASR 转完 → 等 LLM 想完 → 等 TTS 合成完 → 才开始播"，四段首尾相接排队，端到端可能拖到好几秒；流式把这四段改成流水线，多段同时在动，你话音刚落回答的第一个字可能就来了。同样的总计算量，体感是两回事——这就是小智把"流式"当成硬约束而非可选优化的原因。
一个常被忽略的设计：状态机
把上面六步串起来，小智设备侧其实在管一个状态机——待命、聆听、思考、说话之间来回切换。这不是工程洁癖，它决定了几件很实际的事：
- 状态反馈与打断：不同状态配不同灯效/表情/提示音，你才知道它在听、在想、还是在答；你话说到一半或它正念回答时要不要允许被打断，也靠状态机管。没有清晰反馈你会不知道该什么时候开口。
- 异常怎么兜底：网络断了、云端超时、ASR 没识别出内容——每种异常落在哪个状态、怎么退回待命，都得状态机来兜。
真正让小智用起来顺的，是这套把四环组织起来、管好状态流转与异常兜底的设计——能跑通链路的人很多，能把状态和异常管干净的才叫会做产品。
小结 · 下一步
这一节把唤醒→ASR→LLM→TTS 四环放回小智这台真实设备，看清它的链路设计：
- 端云分工的骨架：唤醒留本地（省电、隐私闸门、总开关），ASR/LLM/TTS 上云（算力和效果决定），设备因此变"薄"，主要负责流式收发音频。
- 流水线而非接力赛：靠流式贯穿全程、多环节同时在动，把等待感压到接近自然对话。
- 时延怎么抠：流式上传下发 + 唤醒本地 + VAD 精准切句 + 长连接省握手。
- 状态机才是黏合剂：把四环组织起来、管好状态反馈与异常兜底，才是设备"用起来顺"的真正原因。
设备侧的链路你看透了。但你可能已在想：这条链路的"大脑"（ASR/LLM/TTS 三样云服务）还握在别人手里，能不能拿回来？ 能。下一步去自建后端那节，用小智配套的服务端项目把 ASR、LLM、TTS 都收到自己的服务器，可插拔可替换，数据和模型都由你掌控。想回看某一环原理，翻 L4 唤醒词、ASR/TTS、大模型；想重看网络怎么铺的，回上一节联网。