设计一个实时语音 AI Agent

原文来源：https://outcomeschool.com/blog/design-a-real-time-voice-ai-agent

设计一个实时语音 AI Agent

实时语音 AI Agent 是这样一种系统：它聆听人说话、理解其内容、进行思考，在需要时采取行动，并以自然的人类语音做出回答——整个过程只需几分之一秒。在这篇博客中，我们将学习如何设计一个实时语音 AI Agent，也就是上述那套系统：聆听人说话、理解其内容、思考，在需要时采取行动，并以自然的人类语音回答，全程只需几分之一秒。

我们还会看到为什么语音比文本聊天机器人难得多，构建它的两条主要路径（Speech-to-Text、LLM、Text-to-Speech 组成的级联流水线，与端到端的 Speech-to-Speech 模型对比），agent 如何判断用户已经说完了，我们如何处理打断（barge-in），工具（tools）和记忆（memory）如何融入其中，如何把它扩展到成千上万通电话，在生产环境中会导致语音 agent 失效的边界情况，每种方案的优缺点，以及什么时候该用哪一种。我们将涵盖以下内容：

• 什么是语音 AI Agent？
• 为什么实时语音很难？
• 需求
• 粗略估算（back-of-the-envelope estimation）
• 高层架构
• 组件 1：音频传输
• 组件 2：语音活动检测（VAD）与轮次检测（Turn Detection）
• 组件 3：语音转文字（STT）
• 组件 4：大脑——带工具的 LLM
• 组件 5：文字转语音（TTS）
• 方案 1：级联流水线（STT → LLM → TTS）
• 方案 2：Speech-to-Speech 模型
• 方案 3：混合方案
• 级联流水线 vs Speech-to-Speech：对比
• 延迟预算：每一毫秒花在哪里
• 处理打断（Barge-in）
• 语音 Agent 中的工具调用
• 记忆与上下文
• 电话：接入真实电话通话
• 系统扩展
• 边界情况及处理方式
• 可观测性与评估
• 安全性、保密性与隐私
• 成本
• 如何在面试中呈现这个设计

我是 Amit Shekhar，Outcome School（https://outcomeschool.com/）的创始人，我曾教授和辅导过许多开发者，他们的努力使他们进入了高薪技术岗位，帮助许多科技公司解决了其独特的问题，并创造了许多被顶级公司使用的开源库。我热衷于通过开源、博客和视频分享知识。我在 Outcome School 教授 AI 与机器学习课程。

下面我们开始。

什么是语音 AI Agent？

语音 AI Agent 是一个软件程序，我们可以通过语音与它对话，它也会以语音回应我们，就像与人类打电话一样，只是电话另一头的是 AI。

我们来拆解这个术语。

语音 AI Agent = 语音 + AI + Agent

• 语音：输入和输出都是声音。我们说，它也说。不需要打字，不需要阅读。
• AI：理解和思考由 AI 模型完成，主要是一个大语言模型（LLM）。LLM 是在海量文本上训练出来的模型，因此它能理解语言并生成合理的回复。
• Agent（https://outcomeschool.com/blog/ai-agent）：它不只是聊天。它可以采取行动，比如查询你的订单、预约、取消订阅，或者把电话转接给人工客服。它通过调用**工具（tools）**来做到这一点，我们稍后会学到。

几个真实的语音 AI Agent 例子：

• 客服热线：你打电话说“我的订单在哪里？“，agent 查询后告诉你。
• 餐厅预订 agent：通过电话接受预订。
• 得来速（drive-thru）agent：接受你的点餐。
• App 中的语言导师：和你对话练习英语。
• 外呼 agent：给客户打电话提醒预约。

那么，这里的**“实时”（Real-Time）**是什么意思？在正常的人类对话中，当一个人说完后，对方大约会在 200 到 500 毫秒内回应。一毫秒是千分之一秒，所以 500 毫秒就是半秒。这个间隔对我们来说感觉很自然。如果回复超过一秒，就开始感觉慢了。如果超过两三秒，人们会说“喂？还在吗？“，整个体验就崩了。

所以，实时意味着 agent 必须足够快地回应，让对话感觉像在和真人交谈。我们的目标是：用户停止说话后，agent 大约在 800 毫秒内开始说话。这个单一数字将驱动我们绝大部分的设计决策。

为什么实时语音很难？

大家应该都了解文本聊天机器人。用户输入一条消息，按下回车，聊天机器人回复。构建语音 agent 看起来就像给那个聊天机器人加上麦克风和扬声器。但问题就在这里。

语音带来了很多文本时代从未出现过的新问题。

问题 1：没有人按回车。 在文本聊天机器人中，我们确切地知道用户何时说完了，因为他们会按回车。在语音中，没有回车键，用户只是停止说话。但一个停顿可能意味着“我说完了“，也可能意味着“我在想下一句该说什么“。agent 必须猜测。猜太早，会打断用户；猜太晚，会显得很慢。

问题 2：时间预算极小。 文本聊天机器人花两三秒回复，没有人抱怨。语音 agent 只有不到一秒的时间。而在这一秒内，我们要把语音转成文本、用 LLM 思考、把文本转回语音，还要把音频通过网络发送出去。每一步都在消耗预算。

问题 3：用户会打断。 人类经常打断彼此。如果 agent 正在念一段长答案，用户说“等等，我指的是另一个订单“，agent 必须立刻停下来说话并倾听。文本聊天机器人永远不会有这个问题。

问题 4：音频很脏。 文本是干净的。音频里有背景噪音、电视机在响、小孩在哭、电话线路不好、口音、语速过快、含糊不清、两个人同时说话。这些每一样都可能让系统犯错。

问题 5：语音没有标点，也没有拼写。 当有人说“我的订单号是 A B 一 二 三“时，系统必须判断它到底是“AB123“还是“A B 1 2 3“，还是“Abe one two three“。人名、数字、邮箱和代码在语音中非常难处理。

问题 6：输出必须听起来像人。 agent 不仅要说对内容，还要有正确的节奏、停顿和语调。一个机器人声音把“forty-five dollars point five zero“（45.50 美元）读出来，而不是“forty-five dollars and fifty cents“（45 美元 50 美分），听起来就是错的。

问题 7：一切都是连续流。 在文本中，一条消息就是一次请求。在语音中，音频在整个通话过程中不断流入和流出。我们必须把它当作流来处理，而不是当作一次请求和响应。

所以，语音 AI Agent 不是“带麦克风的聊天机器人“。它是一个有着严格时间预算的实时流式系统。

既然我们知道了它为什么难，接下来就来定义我们要构建的到底是什么。

需求

在系统设计面试中，我们必须从澄清需求开始。我们来梳理一下。

功能需求

• 用户说话，agent 聆听、理解，并用语音回应。
• agent 支持多轮对话，也就是说它能记住同一次通话中之前说过的内容。
• agent 可以使用工具采取行动，比如查询订单、预约时段，或发送确认消息。
• agent 说话时用户可以打断，agent 必须立刻停下并倾听。
• agent 既能通过普通电话使用，也能在移动 App 或网页浏览器中使用。
• agent 在需要时可以把通话转接给人工。
• agent 支持多种语言（这可以作为延伸目标）。

非功能需求

• 延迟：用户停止说话后，agent 必须在 800 毫秒内开始说话，绝不能超过 1.5 秒。
• 可用性：系统必须在 99.9% 以上的时间保持在线。掉线是非常糟糕的体验。
• 可扩展性：系统必须能同时处理数千通电话。
• 可靠性：agent 绝不能半句话没说完就停住，也不能无故沉默。
• 成本：每分钟通话成本必须低到在商业上说得通。
• 隐私与安全：语音是个人数据。录音和转写必须受到保护。
• 可观测性：我们必须能看到每通电话中每一步发生了什么，以便调试和改进。

最重要的指标

对于语音 agent，最重要的指标是语音到语音延迟（Voice-to-Voice Latency）。

语音到语音延迟是从用户停止说话的那一刻，到用户听到 agent 回复的第一个声音的那一刻之间的时间。

我们会反复回到这个数字。我们所设计的一切，都是为了在保证回答正确的同时把这个数字压低。

粗略估算

我们来做一些简单的数学运算，以了解规模。假设我们为一家每天有 100 万通电话、平均每通 5 分钟的公司做设计。

并发通话数： 每天 100 万通电话，平均每秒约 12 通。每通电话持续 5 分钟，也就是 300 秒。所以，在任意时刻大约有 12 × 300 = 3,600 通电话正在进行。通话并非均匀分布在一天之中，所以在高峰期，我们可以假设是这个数字的 3 倍，大约 10,000 路并发通话。

音频带宽： 声音以数字的形式被采集。电话通话通常每秒采集 8,000 次（我们称之为 8 kHz 采样率）。对 AI 模型来说，良好的语音质量是每秒 16,000 次（16 kHz）。每个数字占用 2 字节。所以，16 kHz 音频 = 16,000 × 2 字节 = 32,000 字节/秒，原始形态下即 256 千比特每秒（kbps）。这种原始形式称为 PCM（脉冲编码调制，Pulse Code Modulation）。

我们不会在网络上直接传输原始音频，而是用编解码器（codec）（一种能压缩音频的程序）进行压缩。一种常见的编解码器 Opus 可以在良好音质下将其降到约 32 kbps。电话网络使用一种叫 G.711 的编解码器，速率为 64 kbps。

对于 10,000 路并发通话，且音频双向传输：10,000 × 2 × 64 kbps = 1.28 Gbps（千兆比特每秒）。这对现代服务器来说很容易处理。

录音存储： 100 万通电话 × 5 分钟 = 每天 500 万通话分钟。一分钟 32 kbps 的 Opus 音频大约是 240 KB。所以，如果我们录制每一通电话，每天就是 500 万 × 240 KB = 1.2 TB。转写文本相比之下很小，一通 5 分钟的通话大约是 5 到 10 KB 的文本。

算力： 这才是真正的瓶颈。每一路并发通话都需要：

• 一个流式 Speech-to-Text 会话
• 一个正在生成 token 的 LLM 会话
• 一个流式 Text-to-Speech 会话

这三者都运行在 GPU（https://outcomeschool.com/blog/how-does-a-gpu-work-for-deep-learning） 上，也就是运行 AI 模型的专用处理器。所以，对于 10,000 路并发通话，我们需要一支庞大的 GPU 集群，我们的成本主要就是 GPU 成本。这就是为什么我们要尽可能地关心使用小而快的模型。

现在我们对规模有了直观的感受。接下来进入架构。

高层架构

学习这部分最好的方式是通过一个例子。假设用户拨打我们的客服电话并说：“我的订单 45678 在哪里？“以下步骤必须依次发生：

• 第 1 步：用户的语音被采集，并以小块音频的形式流式传输到我们的服务器。
• 第 2 步：系统检测到用户正在说话，之后再检测到用户已经停止说话。
• 第 3 步：音频被转换为文本：“Where is my order 45678?”
• 第 4 步：LLM 读到这段文本，判断需要查询订单，于是调用 get_order_status 工具，拿到结果，并写出回复：“您的订单 45678 已于昨天发货，明天将会送达。”
• 第 5 步：回复文本被转换为语音。
• 第 6 步：语音音频被流式传输回用户。

高层架构如下所示：

用户（电话 / 移动 App / 浏览器）
    |
    | 双向音频流
    | （电话用 SIP/RTP，App 和浏览器用 WebRTC）
    v
+-----------------------------------+
| Media Gateway（媒体网关，边缘）   |
| 处理通话建立、编解码器、          |
| 回声消除、抖动缓冲（jitter buffer）|
+-----------------------------------+
    |
    | 干净的音频块（每块 20 毫秒）
    v
+-----------------------------------+
| Voice Agent Orchestrator          |
| （每通电话一个会话）              |
|                                   |
|   语音活动检测（VAD）             |
|   轮次检测（Turn Detection）      |
|   流式 Speech-to-Text --> |--> STT 服务（GPU） |
|   流式 LLM + 工具      --> |--> LLM 服务（GPU） |
|   流式 Text-to-Speech  --> |--> TTS 服务（GPU） |
|   打断处理                        |
+-----------------------------------+
    |                               |
    v                               v
+----------------+          +---------------------------+
| 工具 / API     |          | 存储                      |
|（订单数据库、  |          |（录音、转写、              |
| 预订系统、     |          | 日志、指标）              |
| CRM 等）       |          +---------------------------+
+----------------+

实时语音 AI Agent 的高层架构

我们来理解每一部分。

Media Gateway（媒体网关）：这是入口。它与电话网络或 App 通信，接受通话，并把音频转换成我们的系统能理解的干净、标准的格式。它还会做音频清洗，比如回声消除和噪声抑制。别担心，我们后面会详细学习这些。

Voice Agent Orchestrator（语音 Agent 编排器，https://outcomeschool.com/blog/ai-orchestration）：这是系统的心脏。每一通通话都会创建一个编排器会话（session）（会话就是一次通话的“活体记录“，包含其状态和打开的连接）。它接收音频块，判断用户何时说完，把音频发送给 Speech-to-Text，把文本发送给 LLM，把 LLM 的回复发送给 Text-to-Speech，再把音频流式传回。它还负责处理打断。把它想象成乐团的指挥——它自己不演奏任何乐器，但让所有人都在正确的时刻演奏。

STT、LLM、TTS 服务：这是三个 AI 模型。它们运行在 GPU 上，被多路通话共享。

工具 / API：真正的业务系统，比如订单数据库、预订系统或 CRM（客户记录系统）。API 只是一个程序向另一个程序请求某样东西的方式。

存储：录音、转写、日志和指标，用于调试、合规和改进。

客户端与编排器之间的消息

客户端（App 或媒体网关）和编排器通过一组小而精的消息进行通信。我们来看一下，因为它们会反复出现：

• 从客户端到编排器：audio_chunk（用户音频的 20 毫秒），以及 playback_progress（agent 音频中实际已经播放了多少）。
• 从编排器到客户端：agent_audio_chunk（agent 声音的 20 毫秒）、transcript_interim 和 transcript_final（用于在 App 中实时显示文字）、agent_speech_started 和 agent_speech_ended，以及 clear_audio_buffer（丢弃所有尚未播放的内容，用于打断场景）。

请记住这些，尤其是 playback_progress 和 clear_audio_buffer。正是这两条消息让打断处理成为可能，我们稍后会看到。

现在，让我们逐一深入每个组件。

组件 1：音频传输

在跳入 AI 模型之前，我们必须先了解声音是如何从用户的嘴传到我们的服务器的。

声音如何变成数据

麦克风每秒测量数千次空气压力，并且每次都给出一个数字。这些数字被称为采样（samples）。我们每秒采集多少个采样，就是采样率（sample rate）。

• 电话通话：每秒 8,000 个采样（8 kHz）。这就是电话里的人声听起来有点闷的原因。

• 语音 AI …