打断延迟压到毫秒级：用 Gemini Live API 搭建实时语音代理

核心洞察

实时语音代理和普通语音助手之间最大的鸿沟，就是“能不能打断”。这个教程把打断这件事拆到了毫秒级，给出了一个很实用的技巧：别等服务器告诉你被插话了，先在本地把音频掐掉。如果你正在做语音交互产品，第三步值得反复看。

大多数人和 AI 助手说话已经成了日常。想听某首歌，直接用嘴说就行，不用掏手机打字，也不用去按音箱上的按钮。

但这种体验和实时语音代理之间差了一大截。差别就在对话的自然程度。

举个例子：
我：“嘿 Mira，放点 dream pop 呗？”
实时语音：“好嘞，这就来。”
我：（打断）“这首跳过。”
实时语音：“帮你跳了。”

这就是实时语音代理。它在听，实时回应，你可以在它说到一半时打断，跟打电话一样。大部分 AI 语音系统做不到这一点。下面讲讲怎么用 Gemini Live API提供实时音频、视频交互的 Gemini API，支持双向流式通信。 搭一个出来。

核心结论

1. 实时语音代理与普通语音助手的核心区别在于是否支持“打断”（barge-in），Gemini Live API 通过音频到音频的双向通信实现这一能力，而传统 TTS 方案只能单向输出。

2. 实现即时打断的关键技巧是：在浏览器端麦克风检测到用户说话的瞬间，立即静音并清空本地播放缓冲区，而不是等待服务端中断信号穿过网络返回，以此消除数百毫秒的延迟。

3. Gemini Live 内置语音活动检测（VAD），当模型在输出音频时检测到用户说话，会自动停止生成并发出中断信号；客户端需在用户安静时也持续传输音频，以维持稳定基线。

4. 语音交互中工具调用存在硬约束——工具执行慢会导致代理沉默；解决方案是采用异步“触发即确认”模式，立即返回成功回执让模型继续说话，耗时操作在后台异步执行。

5. 搭建实时语音代理需要三个组件协同：浏览器客户端（采集与播放音频）、Gemini Live API（音频原生模型）、Python 后端（通过 WebSocket全双工通信协议，允许服务器主动推送数据，常用于实时应用。 维持与 Gemini 的长连接并中继音频）。

文本转语音 vs. Gemini Live（单向 vs. 双向）

动手之前，先理一下背景。现在大多数 AI 助手用的是文本转语音（TTS）。TTS 的逻辑很简单：你给它文字，它返回一段音频。它能说话，但没法像人一样“听到你”。

Gemini Live 用的是音频到音频，两个方向同时通信。它把你的声音当作原始音频来听，也以原始音频回话。因为它是音频原生的，模型能感知语气、停顿、能量和语调变化。它甚至会在还在组织答案的时候就开始说话，而不是等整段文字生成完再开口。

架构与核心循环

用 Gemini Live API 搭建，需要连接三个部分：

1. 浏览器客户端：采集麦克风音频并播放响应。
2. Gemini Live API：音频原生模型，处理实时音频、检测语音、生成声音。
3. Python 后端：一个轻量中继，维持与 Gemini 的长连接，通过 google-genai SDKGoogle 提供的用于与 Gemini API 交互的软件开发工具包。 传递音频。

浏览器和后端之间走 WebSocket。普通网页请求问一次就关了。WebSocket 会一直开着。这条持久连接让音频可以双向同时持续流动。

第一步：打开双向 WebSocket 连接

标准 HTTP 请求问一次就关闭。实时语音通话需要一条始终打开的通道，音频同时双向传输：把你的麦克风音频流给 Gemini，同时接收 Gemini 的语音流回来。

第二步：实现四步核心循环

连接打开之后，你的后端要同时跑两个循环，不是先后跑。一个把麦克风音频推给 Gemini，另一个拉取语音片段并播放。谁都不等谁。这种并发才是对话感觉“实时”的原因，也是打断能成立的前提。

四个持续运行的操作：

第三步：用 barge-in 技巧降低延迟

打断是整个搭建过程中最难的部分，也是决定代理“像活的”还是“像电话树”的关键。问题在于，模型只能在你的声音穿过网络、被处理完、信号返回之后，才知道自己被插话了。到那时候，代理已经在你说话时继续讲了好几百毫秒，幻觉就破了。

要让代理的响应感觉像自然互动，模型需要知道你什么时候开始说话、什么时候停下。这叫语音活动检测（VAD），Gemini Live 内置了这个能力。

当内置 VAD 在模型输出音频时听到你说话，模型会停止生成并发出中断信号。因为 VAD 在服务端自动处理，你的客户端需要在你安静时也持续传输音频，这样模型有一个稳定的基线，能精确捕捉到你开口的那一毫秒。

同样的 VAD 也是 barge-in 的基础，它让代理在有人开始插话的瞬间停下来。

不过，等信号穿过网络回来会有延迟。要让打断感觉真正即时，你需要在浏览器端，麦克风听到你说话的那一毫秒，就静音并清空本地播放缓冲区。别等服务端的中断信号穿过网络回来。先掐掉本地音频，让模型自己去追。

第四步：加工具，给代理能力

光靠语音模型，它只能产出文字。它没法播放列表、跳过曲目或暂停音乐。要给代理这些能力，需要挂载工具。

工具就是你代码里的一个函数，有名字、描述和参数。比如：

• play_playlist(genre)
• skip_track()
• pause_music()

当模型判断需要执行某个动作时，它会输出一个工具调用，包含从你语音里提取的参数。你的后端代码执行这个函数，再把结果报回去。

但语音交互有一个硬约束： 工具慢 = 代理沉默。

工具运行期间，模型会暂停语音生成，等结果返回。如果一个工具要花三秒去请求外部 API，你的代理就不说话了，场面会很尴尬。

要让对话保持流畅，实现异步“触发即确认”模式：

• 当 play_playlist 这样的工具被触发时，把耗时的播放动作异步派发出去。
• 立刻返回一个即时确认码或回执（比如 {"status": "success"}）给模型。
• 模型收到即时成功回执，继续无缝说话（比如“帮你跳了”），与此同时音乐在后台真正开始播放。

深入代码，自己试试

用原生 Gemini Live API 搭建实时语音代理，能获得低延迟、音频原生的能力，这是标准 TTS 串联管线做不到的，也能帮你做出交互自然的语音代理。

去看完整代码，自己跑一下 demo。Mira 这个深夜电台 DJ 语音代理的完整实现，在这个 GitHub 仓库里。

常见问题（FAQ）

Gemini Live API 和传统 TTS 在语音交互上有什么本质区别？

传统 TTS 是单向文本转语音，只能说话不能听。Gemini Live 是音频到音频双向通信，能实时听你说话，感知语气和停顿，还能在你打断时立刻停止，实现自然对话。

如何用 barge-in 技巧让语音代理的打断响应更即时？

别等服务端中断信号。在浏览器端，麦克风听到你说话的那一毫秒，就静音并清空本地播放缓冲区。先掐掉本地音频，让模型自己去追，这样打断感觉才真正即时。

工具执行慢导致代理沉默怎么办？

实现异步“触发即确认”模式：工具触发时，把耗时动作异步派发，立刻返回成功回执给模型，模型继续无缝说话，同时后台执行工具，避免对话停顿。