SOTA Sync
返回 FEED
AGENT2026-05-07

语音 Agent 架构全景图：从级联到端到端的完整指南

语音 Agent 第一次上线的体验，像极了 2003 年打卫星电话：停顿长、节奏怪、偶尔抢话。那一刻我意识到——文字工程和语音工程是两码事。

语音引入了完全不同的延迟轮廓、不同的失败模式集合、不同的时间约束。语音 Agent 不是"LLM + 扬声器"，它是一个管道，管的每个阶段都在和同一个敌人作战：时间。

三阶段管道：STT → LLM → TTS

最常见的语音 Agent 架构由三个顺序阶段构成：

Speech-to-Text（STT）：将麦克风原始音频转成 LLM 可处理的文本。主流选择：OpenAI Whisper（开源、准确但有延迟）、Deepgram（低延迟流式转录）、AssemblyAI（高准确率）。关键指标不是词错误率，而是转录时间——产生转录结果需要多久。一个准确率 98% 但耗时 800ms 的方案，往往不如准确率 95% 但耗时 150ms 的方案。

LLM：大脑。接收转录文本、应用上下文和记忆、生成回复。同样的模型用法，但提示词结构完全不同——语音对话更短、更口语化，模型绝对不能输出 Markdown、编号列表或长段落。每句回复都要能自然地说出口。

Text-to-Speech（TTS）：将 LLM 文本回复转回音频。从老式机械音到现代神经 TTS：ElevenLabs、Cartesia（极低延迟）、OpenAI TTS、PlayHT。生产环境最重要的指标是到首个音频块的时间——用户多久能听到第一句话。

三个阶段串起来容易，但要无缝衔接才是真正的挑战。

级联 vs 端到端：两条技术路线

级联架构（Cascade）就是我们刚才描述的：STT → LLM → TTS。完全控制每个阶段、完整可观测性、组件可独立替换。代价是延迟（每阶段都加时间）、上下文丢失（LLM 听不到语气和犹豫，只听到转录文字）、情感表面较平。

端到端语音模型直接绕过转录：音频进、音频出。代表：OpenAI Realtime API（基于 GPT-4o）、Kyutai 的 Moshi、Sesame 的 CSM。没有 STT 步骤也没有独立 TTS，延迟骤降。Moshi 报告响应延迟在 200-300ms 区间，接近人类对话。韵律和情感也更好，因为模型直接听和输出音频，不经过文本压缩。

代价是放弃了级联系统的大部分工程化能力：无法检查模型"听到"了什么、无法下季度换一个更好的 STT、工具调用和结构化输出较弱（因为必须编码进音频模态）、目前每分钟对话成本远高于级联方案。

2026 年的现实：客服、电话、已有系统的语音前端，级联仍是正确答案。但对于自然对话比精确工具调用更重要的场景（陪伴、语言 tutor、无手操作助手），端到端正在变得真正有竞争力。

延迟预算：每毫秒都是工程问题

要让语音对话感觉自然，用户说完一句话到听到回复第一个字，总延迟需要控制在约 500-800ms。超过 1.5 秒就感觉坏了。

| 阶段                    | 典型延迟      |
|------------------------|-------------|
| 音频捕获 + VAD 结束检测   | 100–300ms  |
| STT 转录               | 150–400ms  |
| LLM 首 token 时间（TTFT）| 300–800ms  |
| TTS 首个音频块          | 100–300ms  |
| 网络开销                | 50–150ms   |
| **总计**                | **700ms–1.95s** |

悲观看已经感觉像信号不好的电话了。语音 Agent 本质是延迟工程问题，不是 AI 问题。

流式 pipeline：真正的 unblock

naive 方案是顺序执行：等用户说完 → 等完整转录 → 发给 LLM → 等完整回复 → 发给 TTS。延迟叠加。

流式方案的核心是让各阶段重叠：LLM 刚开始生成 token 就开始 TTS，不等完整回复。LLM token 一个接一个出来，TTS 实时消费这些 token 并开始合成音频，通常缓冲 5-15 个 token 后才开始生成第一块音频，避免断断续续。

结果是：用户听到回复第一个字时，LLM 还在生成第二句。这就是 ElevenLabs Conversational AI、Retell AI 等生产级语音系统实现亚 600ms 端到端延迟的架构原因。

全双工与 barge-in：最难的部分

半双工是按讲模式：一方说，另一方听，然后交换。简单但感觉像互相留语音信箱。

全双工是真正的人类对话模式：双方可以同时说话、打断对方、随口说"嗯嗯"、实时反应。实现难度不在一个量级，需要同时监听和生成音频——这意味着解决 barge-in 问题。

Barge-in：用户开始说话时 Agent 还在说。设计良好的全双工系统检测到用户开始说话（通过 VAD），立即停止自身音频输出、取消待处理的 TTS 块、开始处理新输入。

技术挑战三重奏：

  1. VAD 模型需要区分用户声音和 Agent 通过扬声器播放的自己的声音，否则 Agent 会听到自己然后以为被打断
  2. VAD 触发后需要在毫秒级切断音频，不是 300ms 后
  3. 需要判断 barge-in 期间捕获的部分音频是真正输入还是噪音

当前 SOTA 使用 Silero VAD——轻量级神经 VAD 模型，本地运行，延迟极低（约 10ms/32ms 音频块），配合回声消除（从麦克风输入中过滤掉 Agent 自己播放的音频）。

轮次检测：人类不按顺序说话

人类对话不用严格交替。我们用"嗯嗯"、"对"来回应，在对方还没完全说完时就开始说话，用音调节奏暗示"我说完了"。当前语音 Agent 处理这些很笨拙。

naive 方案是基于能量的结束检测：等 N 毫秒静音就判定用户说完了。问题是：深思熟虑的发言中 500ms 静音很正常，不代表用户说完了。

更好的方案：静音检测 + 韵律分析（音调下降模式是否和句子完成一致？）+ 语义分析（目前转录是否形成完整意思？）。有些系统用小型快速 LLM 来预测用户话语是否可能已完成，效果出奇好。

生产级代码什么样

以 Pipecat 框架为例，约 40 行代码就能搭起一个支持 VAD、回声消除、barge-in、全双工音频的流式语音 Agent：

from pipecat.frames.frames import LLMMessagesFrame
from pipecat.pipeline.pipeline import Pipeline
from pipecat.pipeline.runner import PipelineRunner
from pipecat.pipeline.task import PipelineTask
from pipecat.services.deepgram import DeepgramSTTService
from pipecat.services.openai import OpenAILLMService
from pipecat.services.cartesia import CartesiaTTSService
from pipecat.transports.services.daily import DailyTransport
from pipecat.vad.silero import SileroVADAnalyzer

async def main():
    transport = DailyTransport(
        room_url, token, "Voice Bot",
        DailyParams(
            audio_in_enabled=True,
            audio_out_enabled=True,
            vad_enabled=True,
            vad_analyzer=SileroVADAnalyzer(),
            transcription_enabled=False,
        ),
    )

    stt = DeepgramSTTService(api_key=DEEPGRAM_KEY)
    llm = OpenAILLMService(api_key=OPENAI_KEY, model="gpt-4o-mini")
    tts = CartesiaTTSService(api_key=CARTESIA_KEY, voice_id=VOICE_ID)

    messages = [{
        "role": "system",
        "content": "You are a voice assistant. Keep replies short and natural."
    }]

    pipeline = Pipeline([
        transport.input(),
        stt,
        LLMMessagesFrame(messages),
        llm,
        tts,
        transport.output(),
    ])

    task = PipelineTask(pipeline)
    await PipelineRunner().run(task)

框架隐藏了巨大复杂度，应用代码保持精简。LiveKit、Daily、Pipecat 已经完成了 orchestration 的重活。

组件选型参考

场景STTLLMTTS
最低延迟Deepgram Nova-2蒸馏 7-8B 模型Cartesia Sonic / ElevenLabs Flash
最高准确率Whisper large-v3 / AssemblyAIGPT-4o / Claude SonnetElevenLabs Turbo
电话部署Deepgram小模型ElevenLabs / AWS Polly
全自托管/隐私优先Whisper.cpp（本地）Llama-3 via OllamaCoqui/VITS / Piper

语音特有的 prompt 工程

回复是为语音设计的，不是为文本：

  • 不用 Markdown 格式——TTS 会原样读出来，听起来很怪
  • 短句、自然节奏——长复合句口语难跟上
  • 避免列表，用"首先……然后……最后……"代替
  • 缩写和口语化更自然
  • 等待计算时加填充词（"让我想一下"）

真正的难题：4 个工程挑战

噪音环境：咖啡馆开着电视、孩子在旁边——STT 准确率骤降。Krisp/RNNoise 对稳定噪音（空调、风扇）有效，但非稳定噪音（其他人声、背景音乐）很难。解法：低置信度时让用户重复，但这是 workaround，不是 solution。

多说话人：家庭客服电话场景，三个人混在一起说话，STT 产出"弗兰肯斯坦转录"，LLM 回应一个没人问的问题。说话人分离（Speaker Diarization）是答案，Pyannote-audio 是主流开源方案，但每个轮次加 200-400ms 延迟，大多数团队选择不解决。

长对话上下文：30 分钟支持电话轻松产生 6000-10000 tokens 对话历史。需要记忆架构来总结旧轮次、提取持久事实、按需加载相关上下文——而且这一切都要在 500ms 延迟预算内完成。

口音差异：在美式英语基准上词错误率 5% 的模型，在印度英语上可能是 15%、尼日利亚英语 20%、重口音非母语者 30%。如果产品是全球性的，需要在实际用户口音上测试，不是用供应商引用的基准。

语音 Agent 领域发展很快，LiveKit、Daily、Pipecat 让基础设施比 18 个月前容易得多。架构模式正在收敛，真正的挑战在细节：让延迟真正感觉像"在场"，让记忆真正感觉像"连续"，让轮次交替真正感觉像"对话"。

继续阅读