三明治架构：企业级语音智能体的最佳落地方案

语音智能体为什么难做？

随着大模型能力的成熟，语音智能体（Voice Agent）成为企业级 AI 应用的热门方向。但真正做过这类项目的开发者都知道，语音智能体的落地远比想象中复杂——它不仅要求模型能"听"能"说"，更需要具备完整的智能体能力：循环迭代、用户意图识别、工具调用（skill 调用）、上下文管理等。

这里所说的「循环迭代」是指 Agent 在处理复杂任务时，不是一次性给出答案，而是通过多轮"思考-行动-观察"的循环（类似 ReAct 框架）逐步逼近目标。「工具调用」（Tool Use / Function Calling）是指模型能够识别何时需要调用外部 API 或服务来获取信息或执行操作，例如查询数据库、调用日历服务、发起支付等。「上下文管理」则涉及在多轮对话中维护会话状态、记住用户之前说过的内容、以及在长对话中进行信息压缩和检索。这些能力的组合使得语音智能体区别于简单的语音助手——后者只做单轮问答，而前者能完成多步骤的复杂任务。

从工程实现的角度来看，市面上所有涉及语音的智能体，其底层架构大致可以分为三种主流形态。理解这三种架构的差异，是设计一个可用语音智能体的前提。

三种主流语音智能体架构

第一种是三明治架构（STT + Agent + TTS）。 顾名思义，它把负责推理与决策的大语言模型（Agent）"夹"在语音转文本（STT）和文本转语音（TTS）两层之间，像三明治一样。这是本文重点讨论的方案。

第二种是原生实时的 Speech-to-Speech 架构。 它要求使用一个可以实时进行语音交互的多模态大模型，输入和输出都是语音，无需中间的文本转换。原生 Speech-to-Speech 模型的核心思想是将语音信号通过音频编码器（如 audio tokenizer）转化为离散的语音 token，与文本 token 一起纳入统一的序列建模框架中，模型直接输出语音 token 再由解码器还原为音频波形。代表性工作包括 OpenAI 的 GPT-4o（实时语音模式）、Google 的 Gemini 2.0 Flash（原生音频输出）等。这种架构的优势在于模型能够直接学习语音中的韵律、情感、停顿等副语言信息，且省去了中间文本转换步骤带来的信息损失和延迟。但训练这类模型需要海量的语音-语音对齐数据，且模型规模通常极大，推理成本高昂。理论上这是延迟最低、体验最好的方案。

第三种是混合架构。 它结合了三明治架构与原生实时架构的特点，试图在两者之间取得平衡。混合架构的设计思路是：在简单、高频的交互场景（如确认、简短回答）使用原生 Speech-to-Speech 路径以获得最低延迟；在需要复杂推理、工具调用的场景则切换到三明治架构以保证智能体能力。这种路由策略需要一个前置的意图分类器来判断当前对话轮次的复杂度，并动态选择处理路径。此外，混合架构还可能采用「投机执行」策略：在等待强推理模型返回结果的同时，先用轻量模型生成一个快速的占位回复（如"让我查一下"），以降低用户感知延迟。

实时性：语音智能体的生死线

为什么原生 Speech-to-Speech 架构听起来最优，却难以落地？核心问题在于延迟性与实时性。

一个真正意义上的语音智能体，其延迟应该控制在 0.2 秒以内——这是人类几乎感受不到卡顿的阈值。这一阈值源自人机交互领域的经典研究。Jakob Nielsen 在其可用性启发式原则中指出，100 毫秒以内的响应让用户感觉系统是即时的，200 毫秒以内用户不会感知到明显延迟，而超过 1 秒则需要给出加载反馈。在语音对话场景中，人类自然对话的话轮转换间隔（Turn-taking gap）平均约为 200-300 毫秒，因此语音智能体要达到自然对话体验，端到端延迟（从用户说完到系统开始回复出声）需控制在这一范围内。超过 500 毫秒，用户会明显感到"卡顿"；超过 1 秒则对话体验严重退化。

但要达到这一点，你必须找到一个真正实时（real-time）的多模态语音大模型。

这里有一个常见的认知误区。很多人会说："某某模型不是多模态的吗？它能处理语音啊。"但需要区分的是，我们要求的多模态大模型，不仅输入支持语音、图片、文字、视频，输出也必须支持语音。 对语音智能体而言，输出为语音是硬性要求。

以目前市面上的一些视觉多模态模型为例，它们的输入确实支持多模态，但输出并不支持语音。如果强行使用这类模型，就意味着模型先输出文本，再把文本转成语音，这个额外的转换环节会显著增加延迟，实时性无从谈起。

遗憾的是，目前真正成熟、稳定的实时多模态语音大模型屈指可数。这正是原生实时架构落地的最大障碍。

智能体能力：另一个绕不开的评估指标

即便你勉强找到了一个支持语音输入输出的全模态大模型，还会遇到第二个矛盾——它的智能体能力往往很弱。

评估模型智能体能力的关键指标

判断一个模型是否"够格"作为智能体的核心推理引擎，主要看两个基准测试指标：

• 智能体能力（Agent）得分：反映模型在意图识别、工具调用、多步推理上的准确性；
• 编码能力（Coding）得分：反映模型的逻辑与代码生成能力。

评估模型智能体能力的主流基准测试包括：BFCL（Berkeley Function Calling Leaderboard）评估模型的函数调用准确性，包括简单调用、多函数选择、参数填充等维度；AgentBench 测试模型在真实环境中执行多步任务的能力，涵盖操作系统、数据库、Web 浏览等场景；SWE-Bench 则测试模型解决真实 GitHub Issue 的能力，体现端到端的代码理解与修改水平。编码能力（Coding）方面，HumanEval、MBPP、LiveCodeBench 等是常用评测集。这两类能力高度相关——工具调用本质上是结构化代码生成，而复杂推理任务也常需要模型具备编程式的逻辑思维。

近期国产模型在这两项指标上表现亮眼。多款国产模型在主流测试平台上的得分已非常接近国际顶尖水平，作为智能体核心推理模型已具备相当的竞争力。

全模态模型的智能体短板

问题在于，那些真正支持语音输入输出的全模态大模型，虽然"能听能说"，但它们在智能体基准测试数据集上的得分远远低于主流推理模型。

这就形成了一个尴尬的矛盾：

• 推理能力强的模型 → 智能体能力强，但语音输入输出支持差；
• 语音全模态模型 → 语音支持好，但智能体能力弱。

两个要求同时满足，在当前几乎没有完美的方案。

三明治架构：一种务实的工程折中方案

面对上述矛盾，三明治架构提供了一条务实的工程路径。它的核心思路是：把最强的能力用在最关键的地方，其余部分用成熟组件补齐。

三明治架构拆解

三明治架构的核心逻辑是：

1. 中间层（Agent + 推理模型）：使用智能体基准得分最高的模型作为核心。这一层负责意图识别、工具调用、上下文管理等真正体现"智能"的部分。
2. 前置层（STT - 语音转文本）：在推理模型前面接入一个语音转文本模型，解决语音输入问题。
3. 后置层（TTS - 文本转语音）：在推理模型后面接入一个文本转语音模型，解决语音输出问题。

STT 技术经过近年来的快速发展，已经达到了相当高的准确率。以 OpenAI 的 Whisper 为代表的开源模型，在多语言场景下的词错误率（WER）已降至 5% 以下。商用方案如 Google Speech-to-Text、Azure Speech 等更是针对企业场景做了大量优化，支持领域自适应和热词定制。TTS 领域同样取得了突破性进展，基于神经网络的 TTS 模型（如 VITS、Bark、ChatTTS、Fish Speech 等）已能生成接近真人的自然语音，支持情感控制、语速调节和多说话人切换。更关键的是，流式 TTS 技术的成熟使得模型可以边生成文本边合成语音——即推理模型每输出一个句子片段，TTS 就立刻开始合成，大幅降低了用户感知的端到端延迟。

通过 STT 和 TTS 把强推理模型"夹"在中间，就既保证了智能体的核心能力，又补齐了语音输入输出。这就是三明治架构名称的由来。

三明治架构的优势与代价

三明治架构的最大优势是灵活性与能力上限：你可以自由选择当下最强的推理模型，不受语音能力的束缚；STT 和 TTS 也可以各自选用最优组件。当某一层有更好的模型出现时，可以独立替换升级，不影响其他层。这种模块化设计也便于团队分工——语音工程师负责 STT/TTS 的优化，AI 工程师负责 Agent 逻辑的迭代。

代价在于延迟。相比原生 Speech-to-Speech，多了两次转换环节，理论延迟会更高。具体来说，STT 环节通常增加 100-300 毫秒（取决于是否使用流式识别），TTS 环节增加 100-200 毫秒（使用流式合成可显著压缩），加上推理模型本身的首 token 延迟（TTFT），总体端到端延迟通常在 500 毫秒到 1.5 秒之间。但在缺乏成熟实时全模态模型的现实下，用可控的延迟换取强大的智能体能力，对绝大多数企业场景而言是更合理的取舍。

架构选型是一场权衡

语音智能体的架构选型，本质上是在实时性与智能体能力之间做权衡。原生实时架构体验最佳，但受限于模型生态尚不成熟；三明治架构在能力上限和工程可行性上取得了平衡，是当前企业级落地的主流选择。

对于希望快速构建可用语音智能体的团队来说，先用三明治架构跑通业务闭环，再随着实时多模态模型的成熟逐步向原生架构演进，是最稳妥的路径。技术架构没有绝对的优劣，只有是否匹配当下的资源与需求。

核心要点