使用 Amazon Bedrock 和 Pipecat 构建低延迟智能语音 Agent
在生成式 AI 与语音交互技术快速发展的当下,如何高效构建低延迟、个性化、自然对话体验的智能语音 Agent,已逐渐成为业界关注的焦点之一。
智能语音 Agent 的应用领域广泛,包括智能设备语音交互(如具身机器人、智能音箱)、个人助理、自动化客服(如餐厅预订、销售、保险、预约安排)、营销、语言教学(如英语口语学习)、健康医疗以及多模态内容创作等。
本篇博客将首先介绍构建智能语音 Agent 的核心组件和延迟优化建议,接着将利用 Pipecat 开源框架和 Amazon Bedrock 服务,打造一个支持用户打断、多轮上下文管理的实时交互智能语音 Agent
一、智能语音 Agent 核心组件
智能语音 Agent 结合了基础模型的文本/语音识别、理解和推理能力,旨在提供实时、自然、连续的语音交互体验。一般来说,构建智能语音 Agent 通常需要包含以下核心组件:
VAD( Voice Activity Detection ) :检测音频中是否存在人类语音
EOU(End of Turn/Utterance ) :检测说话者是否已经完成了他们的发言
STT (Speech To Text) :也称为自动语音识别(ASR),将给定音频转录为文本
LLM 和 LLM Agent:大语言模型,如 Amazon Nova/Nova Sonic,DeepSeek,Anthropic Claude 系列模型
TTS( Text To Speech) :也称为语音合成,从文本生成自然且清晰的语音
通过将上述组件组合成一条 Pipeline,即可构建出智能语音 Agent。随着生成式 AI 技术的进步,业界发展出了端到端语音模型(即 Speech to Speech 语音模型),该模型可实现语音输入到语音输出的全链路处理,例如 Amazon Nova Sonic 就是一款由 Amazon 研发的 Speech to Speech 语音模型。端到端语音模型内置了 VAD、EOU、STT、LLM、TTS 等集成功能,能够实现更低的延迟。这类模型使得构建语音 Agent 更为轻松便捷。
Amazon Nova Sonic 是一款语音理解和生成模型,可提供自然的类人语音对话式人工智能,并且实现了低延迟和行业领先的性价比。该模型提供流畅的对话处理、自适应语音响应、内容审核、API 调用和基于 RAG 的知识库集成,同时提供高度自适应且引人入胜的用户体验。
这两种方案各有优缺点:Pipeline 方案可以对各个部分进行精细控制,但其缺点在于语音到文本的来回转换可能导致部分声音信息丢失,并且延迟相对较大。端到端语音模型方案延迟更低,实现更为简单,并且能够更好地感知声音信息,例如非语言线索(如笑声、犹豫)、语调、重音、风格、情绪等,但对语音如何流入和流出 Agent 的控制相对较少。
需要注意的是,在当前阶段,SOTA LLM(前沿大语言模型)相比于 Speech to Speech 语音模型,在成本、推理能力、指令遵循和函数调用等方面仍占据优势。但不可否认,Speech to Speech 模型是语音 Agent 的未来。
📢限时插播:无需管理基础设施,利用亚马逊技术与生态,快速集成与部署生成式 AI 模型能力。
✨ 精心设计,旨在引导您深入探索 Amazon Bedrock 的模型选择与调用、模型自动化评估以及安全围栏(Guardrail)等重要功能。
⏩快快点击进入《多模一站通 —— Amazon Bedrock 上的基础模型初体验》实验构建无限, 探索启程!
二、传输协议对比
要构建自然流畅的智能语音 Agent,传输协议的选择至关重要,它们直接影响着语音流的传输效率和实时性。常见的传输协议有 WebSocket,WebRTC 等,它们有各自的特点,详细对比如下。
通过对比可以看出,WebSocket 兼容性更好,WebRTC 对音视频的传输做了很多优化,传输效率更高。一般来说,对于构建原型和轻量级项目,可以选择 Websocket,对于中大型生产项目,WebRTC 是更优的选择。但 WebRTC 协议复杂,部署也很复杂,需要实现信令服务器、STUN 服务器(公网 IP 和端口发现),TURN 服务器(P2P 连接失败时作为媒体中继服务器,实现诸如 NAT 穿透)。因此构建一个成熟稳定的 WebRTC 方案,难度比较大。目前市面上有Livekit开源框架,同时也有 Amazon KVS、Daily、Livekit Cloud 等商业 WebRTC 服务可供选择。
使用 WebRTC 有两种主要方式:一是通过云端的 WebRTC 服务器中转,商业 WebRTC 服务多采用此模式;二是直接在客户端和语音 Agent 端之间建立连接。云端服务器模式可以实现直连模式无法提供的诸多特性,例如多方会话、多方录音等。而直连模式则非常适合语音 AI Agent 的客户端-服务器场景,它减少了服务器中转环节,并且无需维护任何特定于 WebRTC 的基础设施。
Tips:
自建 WebRTC 服务可以使用公开 STUN 服务器:https://gist.github.com/mondain/b0ec1cf5f60ae726202e。可以根据语音 Agent 的部署位置选择合适的 STUN 服务器。
WebRTC 服务使用 UDP 协议进行连接,在亚马逊云部署时需要在安全组开放对应的 UDP 端口。
三、智能语音 Agent 延迟优化建议
延迟是影响人与语音 Agent 之间对话体验的关键因素。人类期望在正常对话中获得快速响应,长时间的停顿会显得不自然(人机对话的典型响应时间通常为 500 毫秒)。因此,延迟优化对于智能语音 Agent 来说至关重要。
根据作者基于 Amazon Bedrock 构建智能语音 Agent 的实践经验,建议综合考虑以下方式优化延迟技术。
语音 Agent 部署尽量靠近用户,减少网络传输延迟。
使用传输效率更高、延迟更低的传输协议,如 WebRTC。
LLM 延迟优化:LLM 的延迟在整个语音 Agent 的延迟中占据主要部分,因此对 LLM 进行延迟优化显得尤为关键。在满足要求的前提下,可以采用以下手段进行优化。
优先选择端到端语音模型,这种模式一般比 STT-LLM-TTS 的 Pipeline 模式延迟更低。
选择参数量更小/推理速度更快的模型(例如 Nova Lite,Claude 3.5 Haiku 等)。
使用 Bedrock 上支持延迟优化的模型(例如 Nova Pro,Claude 3.5 Haiku 等)
开启 Prompt caching
Pre-LLM TTS 填充,在用户对话前预先输出内容(如自我介绍),给用户体感上的快。
执行长时间函数调用之前,输出提示信息,例如“处理中,请稍后…”,从而减少客户的等待时间。
通过 LLM 提示词引导,缩短回复内容。
典型的 Pipeline 模式和端到端语音模型延迟对比如下(请注意,不同方案和组件的延迟差异较大,以下数据仅供参考)。在设计智能语音 Agent 时,将语音端到端延迟控制在 800 至 1000 毫秒是一个不错的目标。
四、使用 Pipecat 框架构建智能语音 Agent
构建一个智能语音 Agent 并非易事。除了实现上文所述的核心组件,还需要考虑如何存储会话上下文、接入外部知识库或对接后端系统等功能。使用Pipecat 开源框架可以显著简化智能语音 Agent 的开发过程。
4.1 Pipecat 框架介绍
Pipecat 是一个开源的 Python 框架,专为构建实时语音和多模态对话 Agent 而设计。它能够轻松协调音频/视频流、AI 服务、多种传输方式以及对话流程,从而让开发者更专注于打造独具特色的 Agent。
Pipecat 主要特性包括:
低延迟实时交互
支持 Agentic Workflow,可集成各类工具(tools)
支持 WebRTC、WebSocket 等传输协议
灵活的模型和服务选择,如 Amazon Bedrock,Polly,Transcribe 及其它主流的模型。
支持用户打断
多模态
4.2 方案介绍
接下来,我们将借助一个示例项目,探讨如何基于 Pipecat 框架,并结合 Amazon Bedrock、Amazon Polly 和 Amazon Transcribe 等服务来构建智能语音 Agent。Amazon Bedrock是用于构建生成式 AI 应用程序和 Agent 的托管服务,支持多种自研和第三方大模型,例如 Amazon Nova、Nova Sonic、DeepSeek、Anthropic Claude 系列模型。Amazon Polly是一项完全托管的服务,可按需生成语音,将任意文本转换为音频流(即 TTS),并支持数十种语言。Amazon Transcribe 是一项完全托管的自动语音识别(ASR)服务,自动将语音转换为文本。
该示例项目演示了如下功能:
支持 Pipeline 模式和端到端语音模式(使用 Amazon Nova Sonic 模型)。
使用 WebRTC 作为传输协议。
通过 Tools 集成知识库,该知识库包含了 2025 年亚马逊云科技中国峰会的相关内容。
提供 Web 前端,用于与 Agent 进行语音交互。
完整的示例代码见 Github 代码仓库: https://github.com/freewine/sample-voice-agent-with-Amazon-Bedrock-and-Pipecat
使用 Pipecat 构建智能语音 Agent 的逻辑架构如图所示。
4.3 Agent 核心代码
使用 Pipecat 构建语音 Agent 的关键在于工作流的搭建。以下是 Pipeline 模式的示例代码,从中可以看出,通过 STT、LLM 和 TTS 等服务构建了一条完整的 Pipeline。为便于阅读和理解,我们已对代码进行简化,完整代码请访问 Github 仓库。
如果使用 Speech to Speech 模型,可以省去 TTS 和 STT,实现端到端语音输入输出。示例代码如下。
4.4 系统提示词最佳实践
语音 Agent 与文字 Agent 的系统提示词在核心原则上是相通的,但语音 Agent 具有其特殊性,需要额外考虑多方面因素,例如口语化的适应、非语言信息的处理、错误纠正和澄清等。以下是作者在构建语音 Agent 时总结的几点经验:
由于 STT/ASR 模型在实时流中可用的上下文信息有限,语音转录时很可能出现错误。好在当前的 LLM 已足够智能,在进行推理时可以访问完整的对话上下文。因此,我们可以通过系统提示词告知 LLM,输入为用户语音的转录文本,指示其进行相应推理以纠正转录错误。建议在系统提示词添加如下的内容:When you receive a transcribed user request, silently correct for likely transcription errors. Focus on the intended meaning, not the literal text. If a word sounds like another word in the given context, infer and correct.
鉴于 LLM 的推理结果将用于 TTS 进行语音合成,因此可在系统提示词中要求其避免输出难以发音的内容:Your output will be converted to audio so don’t include special characters in your answers.
保持 Agent 语音输出的简洁性,打造更好的对话体验,建议在系统提示词里添加如下约束:Keep your responses brief, generally two or three sentences for chatty scenarios.
参考文件
Amazon Nova Sonic: https://aws.amazon.com/ai/generative-ai/nova/speech/
Amazon bedrock:https://aws.amazon.com/bedrock/
*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营,具体信息以中国区域官网为准。
本篇作者
本期最新实验《多模一站通 —— Amazon Bedrock 上的基础模型初体验》
✨ 精心设计,旨在引导您深入探索 Amazon Bedrock 的模型选择与调用、模型自动化评估以及安全围栏(Guardrail)等重要功能。无需管理基础设施,利用亚马逊技术与生态,快速集成与部署生成式 AI 模型能力。
⏩️[点击进入实验] 即刻开启 AI 开发之旅
构建无限, 探索启程!







评论