实时语音Agent的架构演进，正在从ASR、LLM、TTS等独立模型协作，延伸至原生Speech-to-Speech（S2S）语音建模。两种路线在语音信息表示、流式推理、交互控制和系统集成方面各有特点，但模型架构并不能单独决定最终的通话体验。对于企业级Voice Agent，如何降低响应延迟、准确判断用户表达结束、处理实时打断，并将对话结果转化为可靠的业务操作，同样是架构设计的核心问题。
合力亿捷围绕电话Agent构建的Smart-Voice实时语音交互技术体系，重点处理的正是这些模型能力之外的工程问题。理解级联式与端到端架构的差异，有助于进一步认识实时语音系统的关键设计机制，以及企业级Voice Agent在模型选型之外需要解决的技术挑战。
一、两种语音架构：从文本中间态到原生音频建模
1. 级联式ASR-LLM-TTS：模块化处理与显式文本控制
级联式架构将语音识别、语义推理和语音合成拆分为不同阶段，典型链路为：
音频输入 → ASR语音识别 → LLM理解与生成 → TTS语音合成 → 音频输出。
ASR负责将用户语音转换为文本，LLM结合对话上下文生成回答或调用业务工具，TTS再将文本转换为语音。各组件可以独立选型、替换和调优，企业也可以在不同环节加入专业词纠错、字段校验、知识检索及业务规则。
这种架构的关键优势在于具有明确的中间处理节点。语音转写结果可以被检查和修正，LLM生成的内容可以接受规则校验，外部工具的输入与返回结果也可以单独记录。对于需要准确识别设备型号、订单编号、客户信息并执行具体业务操作的语音客服，这种模块化设计有利于定位错误来源和控制执行过程。
级联架构并不意味着必须等待前一阶段完全结束后才启动下一阶段。通过流式ASR、增量文本处理、流式TTS和异步工具调用，不同阶段可以并行执行，缩短用户等待时间。实际性能取决于各环节的关键路径、调度方式和缓冲策略，而不是简单地将三个模型的完整推理耗时相加。
2. 端到端Speech-to-Speech：直接建模语音输入与输出
端到端Speech-to-Speech尝试直接从音频输入生成音频响应，减少对独立ASR转写和TTS合成链路的显式依赖。部分模型会使用神经音频编解码器，将声音表示为离散Audio Token，并在统一或联合建模过程中处理语言内容与语音生成。
2024年发布的Moshi研究是这一技术路线的代表。其模型并行建模用户与系统的音频流，并通过时间对齐的文本Token辅助语音生成，支持连续对话、插话及全双工交互。论文报告的模型实际延迟约为200毫秒，但这是特定模型和实验条件下的指标，并不代表完整电话Agent的端到端通话延迟。
原生音频建模的潜力在于，模型可以利用语速、韵律、语气及非语言声音等信息，而不必将所有输入都压缩为纯文本后再进行理解。这些特征可能影响用户意图判断和回复方式，尤其是在需要自然轮次交替、处理附和或理解语气变化的对话中。
不过，端到端不等于完全没有文本表示，也不意味着所有任务都可以绕过结构化处理。部分S2S模型仍会使用文本Token辅助生成；企业应用仍需处理关键字段提取、业务规则校验、工具调用和执行状态管理。
3. 两种架构的根本差异
级联架构强调模块边界和中间结果的可控性，原生S2S强调语音信息的连续建模与自然交互。前者需要处理阶段衔接、信息损失和累计等待，后者则需要解决复杂任务的可观测性、结构化数据提取与业务执行约束。
因此，技术演进不宜被简单理解为端到端架构必然替代级联架构。OpenAI的Voice Agents技术文档也将原生语音交互与级联语音工作流分别作为可选架构：前者适合连续语音交互，后者适合需要检查或转换中间文本、独立替换组件的场景。具体选择应取决于交互需求和系统约束，而不是仅看模型是否能够直接生成语音。
二、实时交互的关键技术：延迟、轮次与状态一致性
1. 低延迟优化：不仅要让模型更快，还要减少关键路径等待
实时语音Agent的响应时间由音频传输、表达结束判断、语音识别、模型推理、工具调用、语音合成和音频播放等环节共同决定。对于级联架构，流式处理可以让识别、推理和合成部分重叠；对于原生S2S，减少显式模态转换有助于缩短部分处理路径，但网络、推理、播放缓冲及外部业务接口仍可能形成延迟。
评价实时性能时，需要区分三个指标：首个有效语音反馈时间、有效答案开始播报时间、完整业务任务完成时间。 “好的，我帮您查询”可以让客户知道系统已经收到请求，但它并不代表业务查询已经完成。因此，缩短感知等待与缩短实际任务处理时间，需要分别优化。
另一种工程思路是提前启动响应准备。用户真实表达结束与ASR最终文本返回之间可能存在时间差，系统可以根据表达结束判断提前组织上下文、启动响应流程，再由完整识别结果继续驱动最终回答。对于“我来帮您查询”等任务范围明确的即时反馈，也可以使用专用轻量模型，避免每次都等待通用大模型完成推理。
合力亿捷Smart-Voice采用的预判垫词与专用小模型机制，正是围绕这一问题进行的工程优化：前者将响应准备前移，后者降低简单反馈的生成开销。两者共同优化响应启动时机和局部计算成本，而不是单纯追求某个大模型的推理速度。
2. 表达结束判断：VAD检测停顿，语义判断确认轮次
VAD（Voice Activity Detection）主要判断当前是否存在语音活动。它能够检测声音开始和停止，却不能仅凭静音判断用户是否已经表达完整。
例如，用户说“我的电话号码是180……7109……4779”，中间可能出现自然停顿。如果系统将每次停顿都视为一轮结束，就会频繁抢话；如果固定等待过长，又会增加不必要的沉默。
因此，实时语音系统需要区分声学活动检测与用户表达结束判断。前者回答“用户是否还在说话”，后者进一步判断“用户这一轮是否已经说完”。OpenAI的Realtime VAD文档提供了两种典型机制：基于静音区间的Server VAD，以及依据语义判断用户是否完成表达的Semantic VAD。
Smart-Voice也采用分层判断思路，在VAD之外增加专门的表达结束判断机制，为提前响应提供依据。这一设计同时影响响应速度与交互准确性：判断过早可能打断用户，判断过晚则会增加等待。两者需要结合实际对话节奏进行调优。
3. 语音识别增强：通用ASR之后仍需处理专业词
企业电话场景经常涉及产品名称、设备型号、行业术语和专有业务词。即使底层ASR支持热词配置，也可能因为发音相近而将专业词识别为更常见的词语。
Smart-Voice在ASR结果之后增加音素级热词增强机制：将识别文本拆分为音素，与企业配置的热词和纠错词进行发音相似度匹配，再根据匹配结果修正候选文本。与普通字符串替换不同，这一机制关注的是发音层面的接近程度，因此能够处理部分文字差异较大、但读音相似的识别错误。
这一机制说明，语音识别准确性并不完全取决于底层模型。输入音频质量、识别结果的后处理、专业词配置和业务上下文，都会影响最终可用性。对于涉及订单、设备或客户身份的任务，识别增强还应结合字段校验和必要的二次确认，避免将错误纠正结果直接用于业务操作。
4. 实时打断：从检测用户发声到判断用户意图
自然对话允许用户在机器人播报过程中插话，但并非每次发声都意味着需要停止。用户说“等等”“不对，我想改一下”通常需要打断当前回答；“嗯”“哦”等声音则可能只是正常的听众反馈。
仅依赖VAD事件会增加误打断风险；等待完整文本再判断，又可能错过及时响应的窗口。因此，实时系统需要结合声学事件、识别文本、语义判断和明确的关键词规则，综合决定是否中断当前播报。
Smart-Voice通过组合VAD事件、STT事件、文本语义模型与关键词策略，区分普通反馈和具有接管对话意图的插话。这里的技术重点不是简单地让机器人“能够被打断”，而是让系统判断何时应该停止、停止后如何重新理解用户，以及如何管理尚未完成的生成任务。
5. 上下文一致性：模型生成的内容不等于用户听到的内容
打断还会带来一个容易被忽视的状态问题。假设LLM生成了三句话，但机器人只播报完第一句，用户就打断了。如果三句话全部保留在下一轮历史中，模型可能会误以为用户已经听到了完整回答，并据此继续交流。
Smart-Voice针对这一问题，采用依据实际播放内容维护语音上下文的机制：如果三句话只播出第一句，下一轮上下文只保留已经实际播放的部分，未播出的内容不作为已告知用户的信息继续传递。
这一机制将模型生成状态与真实通话状态区分开来。对于实时语音Agent，会话历史不仅需要记录模型产生了什么，还需要准确反映哪些内容已经到达用户。否则，即使模型语义理解正确，也可能因为上下文与现实交互不一致而产生后续错误。
三、从语音交互到业务执行：企业级Voice Agent的架构边界
实时语音交互解决的是用户如何自然表达、系统如何及时回应的问题。企业级Voice Agent还需要理解业务意图、调用外部系统，并根据实际执行结果组织下一轮回复。
在这一层，语音模型可以通过工具调用连接CRM、订单、预约或工单等业务系统。无论使用级联式还是原生S2S，系统都需要明确工具输入与输出的数据结构、调用权限、异常处理和执行状态。对于预约变更、工单创建等操作，还需要避免重复提交，并区分尚未执行、执行中和已经完成的任务状态。
Google的Gemini Live API工具调用文档展示了原生实时语音会话接入外部函数和业务能力的实现方式。这也说明，端到端语音架构并不排斥业务工具；关键在于如何将连续对话与可控的执行流程连接起来。
在合力亿捷的电话Agent架构中，Smart-Voice负责实时语音交互的工程优化，Synerow客户联络Agent承担Agent构建、业务流程编排与工具调用等支撑。二者衔接后，语音交互可以继续进入意图识别、知识处理、业务查询与任务执行，而不止停留在语音问答层面。
对于这类系统，评价标准也应从单一模型指标延伸到完整业务链路，包括关键字段识别准确性、有效响应延迟、误抢话率、打断处理、上下文一致性、工具调用成功率和最终任务完成情况。通过对通话事件与业务执行日志进行关联分析，才能判断问题究竟发生在语音输入、模型推理、业务接口还是音频播放环节。
四、企业Voice Agent应该如何选择技术架构？
级联式ASR-LLM-TTS适合需要明确文本中间态、独立控制处理流程和灵活替换组件的场景。对于专业词较多、业务规则复杂、需要审计和定位错误的电话客服，模块化设计有利于逐环节优化识别、推理和执行过程；通过流式处理、提前响应和打断控制，也可以改善实时交互体验。
端到端Speech-to-Speech适合重点关注自然语音交互、连续对话和声学信息利用的应用。其原生音频建模能够减少对显式文本转换链路的依赖，但实际部署仍需验证业务字段提取、工具调用、状态管理、可观测性及总体延迟，不能仅凭语音自然度判断是否适合企业业务。
两种路线也不必被视为互斥选择。随着语音模型和Agent工程体系演进，企业可以根据不同任务的要求组合原生语音交互、显式文本处理与独立业务执行机制。但混合架构是否适用，仍需结合具体系统设计和测试结果判断，不能将其直接视为所有Voice Agent的必然形态。
实时语音Agent的核心技术问题，正在从单个模型能否听懂、能否开口，扩展到整条交互链路能否及时响应、正确处理打断，并将对话可靠地转化为业务执行。 端到端Speech-to-Speech拓展了原生语音建模的能力边界，而流式调度、专业词增强、轮次管理、上下文一致性和工具调用控制，仍然是企业级语音系统需要持续解决的工程问题。
从这一角度看，评价Voice Agent不能只比较ASR、LLM或TTS的单项能力，而应考察模型架构与实时交互机制能否共同支撑真实业务。架构选型的关键不是追逐某一种技术范式，而是围绕语音质量、响应效率、交互控制和业务可靠性建立可验证的系统设计。
参考资料
Défossez, A. et al. Moshi: a speech-text foundation model for real-time dialogue. arXiv:2410.00037.
OpenAI. Voice agents: architecture and implementation.
OpenAI. Voice activity detection.
Google AI for Developers. Tool use with Gemini Live API.