05 - 语音助手¶

项目背景与目标¶

某智能硬件厂商的车载与家居产品线希望升级语音助手。现有基于关键词槽位填充的方案只能执行固定指令（如「打开空调」），无法理解上下文与复杂意图，用户常需重复唤醒、表达僵硬。企业希望构建基于大模型的语音交互助手，实现「听懂-思考-回应」全链路：语音识别（STT）将用户语音转文字，Agent 完成意图理解与多轮决策，文本转语音（TTS）自然播报，支持打断、情绪感知与多模态上下文，端到端延迟 < 1.5 秒，覆盖车载、家居、App 三端。

核心目标： 1. 端到端语音交互延迟 < 1.5 秒（含 STT + Agent + TTS） 2. 支持多轮上下文与中途打断 3. 情绪感知，回应语气适配 4. 离线/在线双模式，弱网降级可用

预期价值：提升交互自然度、降低唤醒流失、增强产品差异化、支撑复杂场景控制。

需求分析¶

用户角色与场景 - 车载用户：导航、媒体控制、车辆状态查询、电话，双手被占用 - 家居用户：控制家电、查询日程、播放内容，可能远场语音 - App 用户：语音搜索、语音输入

功能需求列表 - 语音活动检测（VAD）与唤醒词 - 流式 STT，边说边转写 - Agent 意图理解、上下文记忆、工具调用（车控/家控/导航） - 流式 TTS，自然韵律与情绪适配 - 中途打断（barge-in）处理 - 降噪与远场拾音 - 离线指令降级（无网时基础控制）

非功能需求 - 性能：端到端 < 1.5 秒，STT < 300ms，TTS 首包 < 200ms - 隐私：语音数据端侧处理优先，云端传输加密 - 可用性：弱网降级，离线可用核心指令 - 健壮性：噪声、口音、儿童语音

约束条件：车载算力有限（边缘 NPU）；部分场景需断网可用。

技术选型说明¶

层次	技术选择	选型理由
STT	SenseVoice / Paraformer	流式、多语种、噪声鲁棒
Agent	自研轻量编排 + 端云协同	边缘处理简单意图，云端处理复杂
LLM	Qwen2.5-7B 边缘 + 72B 云端	端侧低延迟，云端强能力
TTS	CosyVoice（流式）	自然韵律、情感可控、首包快
VAD	Silero VAD	轻量、低延迟
部署	端侧 NPU + 云端 GPU	端云协同

架构设计¶

flowchart LR
    MIC[麦克风阵列] --> VAD[语音活动检测]
    VAD --> STT[流式 STT]
    STT --> AGENT[Agent 编排]
    AGENT --> INT[意图判定]
    INT -->|简单| EDGE[端侧 7B + 车控工具]
    INT -->|复杂| CLOUD[云端 72B + 云工具]
    EDGE --> TTS[流式 TTS]
    CLOUD --> TTS
    TTS --> SPK[扬声器]
    AGENT --> BAR[打断检测]
    BAR -->|打断| STOP[停止 TTS 播放]
    AGENT --> CTX[上下文管理]

端云协同是关键：简单意图（开关空调、导航回家）端侧 7B 直出 + 本地车控工具调用，延迟 < 800ms；复杂意图（「找附近评分高又有停车场的川菜」）上云，云端 72B + 云端检索工具，延迟略高但能力强。流式贯穿全链路以压低首字延迟。

关键模块实现思路¶

模块1：流式 STT 与 VAD¶

思路：Silero VAD 实时检测语音段，检测到静音尾部即触发「端点检测」提交给 STT；STT 流式输出 partial 结果供 Agent 预判意图，final 结果触发执行。
关键点：端点检测延迟与误切断需平衡，车载环境噪声大需调阈值；partial 结果可用于提前准备工具调用。

模块2：Agent 端云路由¶

思路：维护意图路由表，简单意图（车控、家居、本地媒体）走端侧 7B + 本地工具；复杂意图（搜索、多步推理、长文本生成）走云端。路由决策在端侧完成，避免每次上云。

示意：

def route_intent(text):
    intent = edge_classifier(text)
    if intent in LOCAL_INTENTS and len(text) < 30:
        return run_edge(text)
    else:
        return run_cloud(text)  # 流式回传

模块3：流式 TTS 与情绪适配¶

思路：CosyVoice 流式合成，首包 < 200ms；根据 Agent 输出的情绪标签（平静/愉悦/歉意/紧急）调整韵律参数；标点与停顿按语义切句，边生成边播放。
关键点：TTS 必须流式，等生成完再合成会突破延迟预算。

模块4：中途打断（barge-in）¶

思路：TTS 播放期间持续运行 VAD，检测到用户说话立即停止 TTS、丢弃后续生成、重置对话状态为新用户输入；保留必要上下文（如正在播报的内容主题）。
关键点：回声消除（AEC）必不可少，否则 TTS 自己的声音会被识别为打断。

核心流程详解¶

流程1：车载导航复杂查询¶

用户「找附近评分高又有停车场的川菜」
端侧判定为复杂意图 → 上云
云端 72B 调用 POI 搜索工具（评分 + 停车场筛选）
流式生成「为您找到 3 家...」边生成边 TTS
用户中途打断「第二家怎么走」→ 停止播报，发起导航

流程2：家居离线控制¶

断网状态用户「把客厅灯调暗一点」
端侧 7B 理解意图，调用本地家居网关工具
调暗灯光，TTS 简短确认「好的」
全程不依赖云端

部署与优化建议¶

部署架构：端侧模型量化（INT4）部署于 NPU；云端 vLLM 流式服务；STT/TTS 端侧为主、云端为辅。
性能优化：全链路流式（STT partial → Agent 准备 → TTS 流式）重叠执行；端侧模型蒸馏到 7B 以下。
成本控制：简单意图端侧处理零云端成本；云端按需调用。

常见问题与解决方案¶

噪声/口音识别差 → STT 模型针对车载场景微调；AEC + 降噪前处理。
唤醒误触 → 二次确认机制（短指令直接执行，模糊意图反问）。
云端弱网延迟 → 端侧先给通用回应，云端结果到达后补充。

扩展方向¶

多模态融合：结合摄像头识别驾驶员疲劳，主动语音提醒。
个性化声纹：识别不同家庭成员，个性化响应。
主动交互：基于日程与路况主动发起语音建议。