语音 Agent 是什么：与文本 Agent 的差异

语音交互 Agent 就是「能听会说」的 AI 助手：用户说话，它识别语音、理解意图、组织回答，再把答案合成语音播出来。表面上看只是给文本 Agent 加了个「耳朵」和「嘴巴」，工程上却完全是另一套体系。文本 Agent 的输入是干净完整的字符串；语音 Agent 的输入是一段带噪音、带停顿、可能有口音的音频流，输出还要考虑延迟、音色、打断等一堆文本场景不存在的问题。

语音链路可以拆成四个环节：拾音与预处理（VAD、降噪）、语音识别（ASR，把音频变文本）、对话理解与生成（LLM 部分，和文本 Agent 类似但输入是口语）、语音合成（TTS，把文本变语音）。这条链路的难点不在某一个环节，而在「衔接」：VAD 什么时候判定一句话说完了、ASR 出错怎么补救、LLM 回答太慢怎么让用户不等太久、TTS 怎么在生成第一句话时就开播。这篇按环节拆解，重点讲每个环节的选型思路和衔接工程。

语音 Agent 的体验上限由「最慢的环节」决定：用户感受到的延迟是 ASR、LLM、TTS 三段之和。
本文核心知识点
  • 拾音预处理VAD 判端点、降噪、断句是识别质量的地基。
  • ASR 选型实时/离线、热词、中文效果直接决定对话可用性。
  • 对话管理口语输入清洗、打断与静音超时是体验关键。
  • TTS 合成流式播放、音色与语速控制影响「像不像真人」。
语音交互 Agent 配图：左侧麦克风经声波波纹连接到戴耳机的机器人头部，右侧波形面板与仪表盘，蓝色渐变扁平风格
语音 Agent 的全链路：收音 → 识别 → 理解 → 合成 → 播报。

拾音与预处理：VAD、降噪与断句

一切从拾音开始。用户说话时，麦克风采集到的是 16kHz 或 8kHz 的音频流，里面混着环境噪音、设备回声，还有大量「没人说话」的静音段。第一个要做的处理是 VAD（语音活动检测）：判断哪段时间有人在说话，哪段时间是静音。VAD 的意义重大——它决定了「什么时候开始识别」和「什么时候判定这句话说完了」，识别质量差往往不是 ASR 的错，而是 VAD 把话说断了或把噪音当成了话。

第二个处理是降噪与回声消除。会议室、车内、街边这些场景背景音复杂，不做降噪 ASR 的错字率会明显上升；双向通话场景（比如电话）还要做回声消除，否则 Agent 自己的声音会被自己的麦克风又收进去，形成「自我对话」。第三个处理是断句：VAD 判定一句话结束后，把这段音频作为一次识别单元送出。断句太短会把完整句子切碎，太长会让用户等很久才得到回应，静音阈值（比如 600ms）需要按场景调优。

# 音频流处理（伪代码）
# 1. 持续接收麦克风音频帧
# 2. VAD：每帧判断是否人声；连续 N 帧无人声视为一句话结束
# 3. 说话期间：累加音频帧，同时做降噪与回声消除
# 4. 一句话结束后：把该段音频交给 ASR
# 5. 特殊处理：超长语音（如连续 30 秒）强制分段识别
def process_stream(frame):
    if vad.is_speech(frame):
        buffer.append(denoise(frame))
        silence = 0
    else:
        silence += frame.duration
        if silence > 0.6:            # 静音 600ms 视为断句
            emit(buffer)              # 送 ASR
            buffer.clear()

ASR 选型与接入：实时识别与热词优化

ASR 把音频变成文本，选型要考虑四个维度。一是实时性：电话客服、语音助手这类场景要求「边说边出字」（流式识别），延迟目标在几百毫秒内；离线转写场景（会议纪要）则可以用非流式模型，准确率更高。二是中文效果与口音：不同厂商对普通话、方言、专业术语的识别能力差异很大，要用自己场景的音频做实测，别只看宣传指标。三是定制能力：能不能加「热词」——把产品名、人名、专业词预先告诉识别引擎，显著降低专有名词的错字率。四是成本与并发：按分钟计费还是自建模型，要结合量级算账。

接入时最容易踩的坑是「一次性把整段音频丢给 ASR」。流式场景必须用流式接口，边传边拿中间结果；同时要建立「纠错机制」：ASR 输出的文本错误是常态，不能直接当最终输入，常见做法是让 LLM 在理解时对明显错误做容忍与推断（比如「微信支负宝」应理解为「微信、支付宝」），或结合领域知识做规则纠错。热词的注入要在 ASR 配置里做，而不是指望事后用文本替换兜底——事后替换经常漏。

# ASR 流式接入（伪代码）
# 1. 建立流式识别会话，配置语言与热词表
# 2. 持续把音频帧发送给识别引擎
# 3. 识别引擎返回中间结果（partial）与最终结果（final）
# 4. 一句话结束（final）时，取最终文本进入下一步
# 5. 对 final 文本做领域纠错后再交给 LLM

对话管理：口语输入清洗与意图理解

语音场景喂给 LLM 的输入，和文本场景完全不同。口语里全是「那个」「就是」「嗯」「帮我查一下那个…」这样的填充词、重复和语法碎片；ASR 还可能在句子里插入「重复刚才的话」这种识别错误。直接把这些原文丢给 LLM，会浪费上下文、还容易让模型困惑。所以对话管理第一步是「口语清洗」：去填充词、纠正常见错字、把碎片化的句子补全，同时保留对意图有用的信息。

第二步是「意图与槽位」管理。语音对话的特点是用户说话随意：「明早八点提醒我」和「明天早上八点，别忘了提醒我一下」是同一个意图，槽位（时间=明早八点、动作=提醒）要能抽出来。可以用 LLM 做意图识别 + 槽位抽取，配 few-shot 示例兜底。第三步是「打断与插话」处理：用户可能在 Agent 播报途中再次开口（「等一下，我是说……」「不是这个，换一个」），系统要能检测到打断（一边 TTS 播报一边监听 VAD），暂停播报、重新进入识别。没有打断处理的语音 Agent，体验会非常「笨」。

# 语音对话状态（简化状态机）
# 1. IDLE：等待用户说话 → VAD 检测到人声 → 进入 LISTEN
# 2. LISTEN：收集音频 → 断句 → ASR → 口语清洗 → LLM 理解
# 3. THINK：LLM 生成回答（同时可播报“请稍等”缓冲音）
# 4. SPEAK：TTS 流式播报；此期间持续监听，检测到打断 → 回 LISTEN
# 5. 任一状态静音超时（如 10 秒）→ 兜底话术后回 IDLE

TTS 与语音合成：音色、语速与流式播放

TTS 决定用户听到的「声音长什么样」。选型看三点：音色自然度（有没有机器感）、中文发音（多音字、专有名词读法）、定制能力（能不能克隆品牌音色、调节语速语气）。现在的神经 TTS 自然度已经很高，但多音字和数字读法仍是老大难：「一行代码」的「行」读 háng 还是 xíng，「2026」读年份还是数字，都要靠发音字典和规则修正。重要的专有名词可以维护一份「读音表」，在合成前做文本规范化。

体验层面有三个要点。一是流式播放：不要等整段文本合成完再播，要「合成一句播一句」，让用户尽早听到声音，感知延迟能降低一大截。二是语速与停顿：长回答要控制语速、在适当位置停顿，必要时拆成短句播报，避免一口气念完 200 字的压力感。三是语气变化：同一句话用不同语气说，用户感受完全不同，客服场景要温和，助手场景要干脆。这些可以用 SSML 之类的标记语言控制，也可以在 LLM 生成回答时就约束「这句话要短、口语化、适合朗读」。

# 流式播报（伪代码）
# 1. LLM 生成回答文本（可要求分句输出，每句一个自然段）
# 2. 逐句合成：第一句 TTS 完成后立即开始播放
# 3. 播放第一句的同时，后台合成第二句，以此类推
# 4. 播报前做文本规范化：数字读法、专有名词读音、标点转停顿
# 5. 播报被打断时，停止合成与播放，丢弃未播内容