> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 实时语音智能体技术栈 - URL: https://www.hubwiz.com/blog/the-tech-stack-for-real-time-voice-agents/ - Published: 2026-08-30T10:11:40.000Z - Updated: 2026-10-13T15:17:39.000Z - Description: 组织正在竞相为其客户带来自然、实时的语音AI。需求涵盖两个主要方面：现代化传统联络中心中笨重的IVR菜单，或将语音优先界面直接嵌入到打字不理想的Web应用、移动应用和智能设备中。 - Author: admin - Tags: INDUSTRY, #Import 2026-10-14 14:41 组织正在竞相为其客户带来自然、实时的语音AI。需求涵盖两个主要方面：现代化传统联络中心中笨重的IVR菜单，或将语音优先界面直接嵌入到打字不理想的Web应用、移动应用和智能设备中。 目标始终相同：一个倾听、推理、行动和说话而没有延迟或尴尬停顿的对话助手。实现这一目标需要完整的端到端架构，结合基础模型（如OpenAI realtime、Amazon Nova Sonic）、编排框架（如Strands Agents）和可扩展的托管目标（如Bedrock AgentCore或托管容器环境）。 本文将逐层分解语音代理技术栈，以便您可以为平台选择正确的工具。 ## 0、语音代理堆栈 语音工程刚刚经历了其"LAMP堆栈"时刻。该领域已经成熟，模式已经固化，开发人员终于开始使用标准化的多层架构进行构建。告诉某人\*\*"我正在AgentCore上使用WebRTC运行Nova Sonic + Strands BidiAgent"\*\*现在可以像十年前"MEAN堆栈"对Web开发人员那样快速解释您的完整系统架构。 无论您是要淘汰传统联络中心IVR还是要将语音界面直接放入移动应用和智能设备，目标都是一样的：零延迟、自然的对话，真正完成工作。 以下是语音代理堆栈： ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-Y0XSOFlKupWOWoqMlYfTrQ.jpeg.png) 这篇博客文章将引导您了解每一层：选择是什么，它们如何比较，以及选项权衡。 ## 1、模型：倾听、思考和说话 模型层是语音架构中最大的分叉点。它设置了延迟下限，决定了您需要编写多少客户端粘合代码，并塑造了用户体验的整体感觉。 您有两个主要范式，以及一个提升音频流方式的操作模式。 ### 1.1 级联管道（ASR > LLM > TTS） 这是经典的"菊花链"方法：单独的服务按顺序链接在一起。 流程如下：**麦克风 > VAD > ASR > LLM > TTS > 扬声器**。 ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-PeVOIiuc_Oz8o_o6m_4ADw.jpeg.png) 除了运行这三个核心模型（AST、LLM、TTS）之外，您的编排层还必须自己处理语音活动检测（VAD）、采样率转换和打断逻辑。 **生态系统：** - \*云巨头：\*AWS（[Transcribe](https://aws.amazon.com/transcribe/?ref=hubwiz.com) \+ [Bedrock](https://aws.amazon.com/bedrock/?ref=hubwiz.com) LLM + [Polly](https://aws.amazon.com/polly/?ref=hubwiz.com)）、Azure（[Speech](https://aws.amazon.com/pm/transcribe?ref=hubwiz.com) \+ Text Chat）、Google Cloud（[Speech-to-Text](https://cloud.google.com/speech-to-text?ref=hubwiz.com) \+ [Vertex AI](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/speech/text-to-speech?ref=hubwiz.com)）。 - *小众速度恶魔：*[Deepgram](https://deepgram.com/?ref=hubwiz.com) 或 [AssemblyAI](https://www.assemblyai.com/?ref=hubwiz.com) 用于ASR；[ElevenLabs](https://elevenlabs.io/conversational-ai?ref=hubwiz.com) 或 [Cartesia](https://www.cartesia.ai/?ref=hubwiz.com) 用于高保真TTS。 \*\*权衡：\*\*您获得终极灵活性。您可以换掉任何部分，插入高度专业化的文本LLM，或使用自定义语音克隆。缺点是什么？累加延迟（通常为1.2到2秒往返）以及大量管道代码以在三个不同API之间保持状态同步。 ***双向流（语音到语音）*** 与其链接模型，不如单个神经网络在一个连续会话中处理语音输入、推理和语音输出。音频进来，音频出来。不会将事物分解为单独的ASR或TTS步骤。 ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-VmcUFd5nEfXndUe-61J9pA.jpeg.png) **前沿参与者：** - [Amazon Nova Sonic](https://nova.amazon.com/sonic?ref=hubwiz.com)：专为低延迟对话代理、异步工具执行和处理嘈杂的真实音频而构建。 - [OpenAI Realtime API](https://developers.openai.com/api/docs/guides/realtime?ref=hubwiz.com)：支持GPT-4o实时系列，具有异步函数调用和无缝上下文保留功能。 - [Google Gemini Live](https://gemini.google/overview/gemini-live/?ref=hubwiz.com)：多模态流，处理实时音频（和视频），具有原生情感、音高动态和智能轮流发言。 \*\*权衡：\*\*速度和平滑度。由于语音识别、音调调制和轮流管理都在模型传递中发生，响应时间降至约300ms–600ms。设置要简单得多，因为模型原生处理自己的VAD和中断。主要问题是什么？您被锁定在供应商的原生语音目录和连接模型中。 ***扩展：全双工*** 虽然S2S描述了**模型正在做什么**，但全双工描述了**如何**通过WebSockets或WebRTC等持久连接流式传输它。将全双工视为构建在S2S之上的操作超能力： - \*\*真正的同步I/O：\*\*用户可以在模型说话时说话，而不会锁定通道。音频同时双向流动。 - \*\*即时打断：\*\*用户在句子中间中断的瞬间，服务器触发截断事件（如input\_audio\_buffer.speech\_started信号）。客户端立即丢弃其本地播放队列，模型丢弃未播放的令牌，使中断感觉完全自然而不是笨拙。 **范式比较** ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-zvAtJWC1Yx7zwkEQFGMgaQ.png) ## 2、框架：编排语音会话 正如Web应用需要Express或Django来处理HTTP生命周期一样，语音代理需要框架来处理音频流生命周期：轮流发言、中断、编解码器转换、语音期间的工具分发和会话状态。这一层是语音等效于[LangChain](https://www.langchain.com/?ref=hubwiz.com)、[CrewAI](https://crewai.com/?ref=hubwiz.com)或[Strands Agents](https://strandsagents.com/?ref=hubwiz.com)用于文本/多模态代理，但针对实时音频约束进行了调整。 **Strands Agents** 是一个模型驱动的SDK，旨在跨多个提供商构建生产就绪的AI代理。作为原始S2S模型SDK的直观高级包装器，其[BidiAgent](https://strandsagents.com/docs/user-guide/concepts/bidirectional-streaming/agent/?ref=hubwiz.com)抽象了底层WebSockets、事件循环复杂性和工具订阅接线。开发人员可以使用单一、统一的事件接口构建丰富的语音代理业务逻辑和多代理集成。`BidiAgent`支持具有实时音频流、无缝句子中间中断和并发处理功能的长时间运行对话——在三大S2S模型提供商（Amazon Nova 2 Sonic、OpenAI Realtime和Gemini Multimodal Live）之间提供一致的开发人员体验。 [LiveKit Agents](https://docs.livekit.io/agents/?ref=hubwiz.com) 是一个基于房间的实时媒体框架，具有提供商无关的插件，支持双向流和级联管道，具有用于语音到语音模式的原生Nova 2 Sonic集成。对于级联，您可以在不重写编排的情况下交换STT、LLM和TTS提供商。它包括内置WebRTC传输、多方支持以及集成的VAD和轮流检测。 [Pipecat](https://github.com/pipecat-ai/pipecat?ref=hubwiz.com) 是一个面向管道的框架，具有可组合的帧处理器，也支持双向流和级联管道，具有原生Nova 2 Sonic集成，可与传统STT/LLM/TTS链一起使用。它提供了对音频缓冲和计时的细粒度控制、具有背压的事件驱动架构以及每个阶段的可插拔处理器。 许多团队在与专有联络中心基础设施或特定媒体管道集成时也会构建自定义编排。 ## 3、集成：代理能做什么 使语音代理"具有代理性"而非纯粹对话的是其采取行动的能力。集成层通过工具、知识检索和其他代理将代理连接到业务系统，使其能够查找帐户、验证身份、安排约会、处理付款或在对话中升级给人工。 ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-gXeokBwM8HJaJPYd6Cy7yQ.jpeg.png) **工具和服务端点**后端工具依赖于无服务器计算或标准微服务，通过通用API网关通过RESTful或gRPC端点公开。这些代表可调用函数，模型在对话期间调用这些函数来处理数据库查询、CRM更新、付款处理、约会安排或任何自定义业务操作。 **RAG和向量数据存储**为了提供流畅的语音交互，RAG必须以超低延迟运行，以避免中断对话流。代理不是在流循环中嵌入复杂的摄取逻辑，而是通过快速RESTful API或MCP查询外部向量数据库（如Pinecone、Qdrant或pgvector）。对于查询产品FAQ、策略文档或知识库文章等典型用例，代理在对话中提取语义意图，从向量索引中获取匹配的块，并将其注入模型的上下文窗口，从而提供即时、准确的口头回答，而不会延迟音频流。 **工具发现和协议标准化**工具集成利用开放标准（如[模型上下文协议（MCP）](https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro?ref=hubwiz.com)）将后端服务呈现为可发现的、自描述的工具目录。通过将RESTful或HTTP端点注册到MCP服务器，代理在会话初始化期间使用标准基于令牌或API密钥的身份验证自动发现可用工具。这使得工具可跨不同代理重用，并将工具编写与代理编排干净地解耦。 \*\*子代理（代理到代理委派）\*\*子代理架构支持代理到代理（A2A）调用，使主代理能够将专门的任务委派给具有专用权限、隔离运行时环境或特定领域模型的下游子代理。例如，认证代理可以在安全边界内验证用户身份，支付代理可以在严格的PCI兼容范围内运行，领域专家代理可以处理复杂的利基数据集。 **技能和可组合模块**技能充当可重用的模块化包，将系统提示、工具模式和执行逻辑捆绑到单个可组合单元中。例如，"呼叫转移"技能将所需的API工具定义、对话提示指令和升级逻辑打包到任何代理都可以采用而无需重新实现的单个模块中。 **架构灵活性**所有这些功能都可以使用托管云服务实现，也可以通过自托管的开源组件构建。托管路径减少了运营开销，而自托管微服务提供完全的基础设施控制。大多数生产架构利用针对其安全和扩展需求量身定制的混合方法。 ## 4、渠道：用户如何到达代理 渠道层决定了音频如何在用户和代理之间流动。语音代理使用四种常见协议，每种协议映射到不同类型的语音代理架构和解决方案。 ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-5TUd4-VE22JDgHz0SZu0XQ.jpeg.png) #### WebSocket和WebRTC（Web、移动、物联网） 数字原生渠道。这是通过互联网将客户端直接连接到语音代理的两种主要协议，它们服务于不同的目的。 **WebSocket**提供持久的双向TCP连接，用于在客户端和代理运行时之间流式传输音频。客户端负责捕获音频（麦克风访问、编码）和播放接收到的音频。WebSocket易于实现，可在防火墙和代理后面工作，并让您完全控制音频管道。当您正在构建自定义客户端体验并希望自行管理音频捕获、编码和播放时，它非常适合。 **WebRTC**是一种实时通信协议，最初设计用于点对点语音和视频通话。它通过UDP运行以获得更低的延迟，包括内置回声消除、噪声抑制、自动增益控制和自适应比特率。WebRTC在浏览器或移动SDK中原生处理整个音频捕获和播放生命周期，因此客户端集成对于语音用例更简单。当您想要开箱即用的生产级音频处理时，它是更好的选择，特别是在声学条件变化的浏览器和移动环境中。 主要区别： ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-XSXkoNfaEW4gJmGKyqo2yA.png) #### PSTN和SIP（电话/联络中心智能） 电话渠道将语音代理连接到电话网络。PSTN为任何希望呼叫者到达AI代理的企业提供直接电话号码连接，而SIP支持与企业联络中心平台集成。 **PSTN**是最终用户拨打电话的方式。CPaaS提供商在电话网络和您的代理之间架起桥梁。[Twilio](https://www.twilio.com/docs/voice/media-streams?ref=hubwiz.com)提供媒体流和会话中继。[Vonage](https://developer.vonage.com/en/voice/voice-api/concepts/websockets?ref=hubwiz.com)提供WebSocket音频流。[Bandwidth](https://www.bandwidth.com/?ref=hubwiz.com)和[Telnyx](https://telnyx.com/?ref=hubwiz.com)提供具有WebSocket交付功能的直接PSTN。提供商处理号码配置、PSTN互连和编解码器协商。您的代理通过WebSocket接收音频。这是"拨打电话，与AI代理交谈"的最快路径，非常适合希望AI代理接听电话的中小企业（餐厅预订、牙科诊所预约、汽车维修店安排服务），以及不需要企业联络中心平台集成的开发、原型设计和生产部署。 **SIP**是企业联络中心平台路由呼叫的方式。直接中继集成将您的代理连接到[Genesys Cloud CX](https://www.genesys.com/genesys-cloud?ref=hubwiz.com)、[Five9](https://www.five9.com/?ref=hubwiz.com)、[NICE CXone](https://www.nice.com/products/cx/cxone?ref=hubwiz.com)或[Cisco Webex Contact Center](https://www.webex.com/contact-center.html?ref=hubwiz.com)等平台。SIP需要信令（UDP/TCP 5060）、RTP媒体处理（UDP端口范围）和编解码器转换（G.711 mulaw 8kHz到PCM 16kHz）。这是企业CCI部署的生产路径，其中语音代理位于现有联络中心工作流中或替代人工代理。 #### 不同渠道用于不同解决方案 ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-XSXkoNfaEW4gJmGKyqo2yA.png) 您选择的渠道反映了您正在构建的语音代理类型。数字产品使用WebSocket或WebRTC。基于电话的自助服务通过CPaaS提供商使用PSTN。企业CCI使用SIP连接到现有联络中心平台。 ## 5、托管：运行位置 语音代理具有标准HTTP设置难以处理的独特基础设施要求：持久WebSocket连接、双向流、低延迟和连续会话生命周期管理。 无论您是部署托管云服务、编排**容器**还是管理裸机，以下是托管选项在不同环境中的细分。 #### **托管语音代理运行时** Amazon Bedrock AgentCore BidiRuntime（或等效的托管代理运行时）等服务为您提供最低的运营负担。 - **工作原理：原生支持持久WebSockets和WebRTC，无需依赖连接升级技巧。您提供容器化应用程序代码**或Python包入口点，运行时根据活动流连接自动扩展。 - \*\*最适合：\*\*希望直接从本地开发跳转到生产而无需配置网络代理、负载均衡器或自定义扩展钩子的团队。 **托管容器（AWS ECS/Fargate、Azure Container Apps、GCP Cloud Run）** 在托管的无服务器或弹性容器平台上运行**Docker容器**，平衡控制与低基础设施管理。 - **工作原理：您将语音代理、上下文桥或代理打包到轻量级容器**中。负载均衡器（如AWS ALB、Azure Application Gateway或GCP HTTPS负载均衡）处理TLS终止和WebSocket连接路由。 - \*\*最适合：\*\*标准WebSocket/WebRTC语音代理、HTTP回退路由以及位于CPaaS提供商（Twilio、Vonage）和您的代理逻辑之间的电话代理适配器。 **Kubernetes编排（AWS EKS、Azure AKS、GCP GKE、本地OpenShift /原生K8s）** 对于需要底层网络的工作负载，Kubernetes提供了对**容器**如何与客户端设备和电话网络通信的完全控制。 - **工作原理：Kubernetes处理可以直接绑定到主机网络接口（hostNetwork：true）或使用具有原始UDP支持的网络负载均衡器（NLB）的自定义容器Pod**。 - **最适合：直接SIP/RTP媒体流、自定义音频编解码器（G.711、Opus），或需要跨公共云和本地数据中心相同容器配置**的多云环境。 **虚拟机和本地裸机（AWS EC2、Azure VM、GCP Compute Engine、私有云）** 部署**自管理容器**（通过Docker Compose、Podman）或VM/裸机服务器上的原始进程可提供完全的架构自由。 - \*\*工作原理：\*\*自动扩展组或自定义编排器根据活动连接数而不是仅标准CPU/RAM使用情况来扩展实例。您完全控制底层操作系统、内核级网络调优和本地硬件访问。 - \*\*最适合：\*\*本地企业电话集成、阻止云部署的严格合规性要求，或自定义底层C++/Rust音频处理管道。 ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-5Xo38PlvsnEPQo5g2XdKAg.png) ## 6、示例语音代理堆栈 就像Web开发人员用一行描述他们的堆栈一样，语音代理构建者也可以这样做： ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-2sbFjmOa4oGZ4JKyIorAWw.png) --- 原文链接：[Building Real-Time Voice AI Agents: Choosing Models, Frameworks, Protocols, and Hosting](https://medium.com/@zhangblue/building-real-time-voice-agents-choosing-models-frameworks-protocols-and-hosting-5dc0a28f98e2?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处 > **这是「多模态生成」专题的一部分。**完整地图见：[多模态生成完全指南](https://www.hubwiz.com/blog/generative-media-stack/)