构建实时语音 AI 代理的真实挑战

梯形图转SCL | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

语音代理演示通常看起来出奇地简单：

microphone -> STT-> LLM -> TTS -> speaker

然后我们将其置于真实用户面前。

助手说"您的预约已确认在周二下午 3 点"，用户在中间打断：

"不，我需要周四"。

此时，系统可能仍有 LLM 令牌到达、文本排队等待合成、音频缓冲待播放以及 CRM 查询在后台运行。

问题不再是语音到文本或文本到语音。问题是当对话在工作仍在进行时发生变化，什么会变得过时。

这就是使 Pipecat 有趣的生产问题。

Pipecat 是一个用于实时语音和多模态代理的开源 Python 框架。但将其描述为一个集成 STT、LLM、TTS、WebRTC 和许多提供商的框架，会错过有用的部分。

它的真正价值在于为我们提供了这些服务之间尴尬部分的通用流式运行时： 帧、轮次边界、中断、工具执行、传输、状态和指标。

在撰写本文时，Pipecat 版本为 v1.7.0，需要 Python 3.11 或更高版本，采用 BSD-2-Clause 许可。

1、STT → LLM → TTS 只是最佳路径

对于基本的级联代理，Pipecat 真的可以如此紧凑：

pipeline = Pipeline([
    transport.input(),
    stt,
    user_aggregator,
    llm,
    tts,
    transport.output(),
    assistant_aggregator,
])

这很有用，因为每个组件都是可替换的。我们可以组合一个语音识别器、一个不同的模型提供商和一个不同的语音服务，而无需重写整个应用程序。

Pipecat 当前的服务目录涵盖 STT、LLM、TTS、语音到语音、电话、WebRTC、视频、内存和监控提供商。

但生产价值始于提供商 API 之下的一层。

Pipecat 将音频、文本、图像、消息和控制信号作为帧在管道中移动。帧处理器接收它们、对其采取行动并将其向前推送。

更重要的是，不同的帧类别具有不同的中断语义。当用户中断时，待处理数据和普通控制帧可以被丢弃；更高优先级的系统帧（如中断和生命周期信号）则不会。

这给了运行时一种表达方式：

此音频不再有效
此排队文本应消失
此控制事件仍必须到达
此新用户输入优先

这更接近语音的实际行为方式。

2、轮次是模型体验的一部分

用户暂停并不总是意味着用户已完成。

考虑：

"我们能把我的预约从周二改到……"

这里 400 毫秒的暂停可能是犹豫，而不是请求的结束。如果我们回答太早，代理会显得不耐烦。如果我们等待太久，它会显得缓慢。

Pipecat 将轮次的开始与轮次的结束分开。其当前默认值可以使用 VAD 或传入转录来注意到语音已开始，而默认停止策略使用 LocalSmartTurnAnalyzerV3 来估计对话轮次是否实际完成。智能轮次模型使用 ONNX 在本地运行。

这改变了思维模型：

      VAD
"有人在说话吗？"
       ↓
      STT
"他们在说什么？"
       ↓
   轮次模型
"他们真的完成了吗？"
       ↓
      LLM

Pipecat 在其正常轮次启动策略中默认启用中断。

当机器人在说话时开始新的用户轮次，框架可以停止机器人语音并清除待处理的音频和文本，以便新轮次可以接管。

这是 Pipecat 赢得其抽象的地方之一。我们不必在每个 STT、LLM、TTS 和传输集成之间发明临时取消信号。

3、工具调用也会过时

同样的问题超越了音频。

假设我们的预约代理开始一个五秒钟的 CRM 查询。两秒钟后用户说："实际上，忘了周二吧。周四上午。"

如果我们让旧查询完成并将其结果反馈到对话中，我们就创建了两个意图之间的竞争。

Pipecat 的函数注册支持中断感知取消和每个工具的超时：

llm.register_function(
    "lookup_appointment",
    lookup_appointment,
    cancel_on_interruption=True,
    timeout_secs=5.0,
)

使用 cancel_on_interruption=True，当对话继续时可以取消该函数。

Pipecat 还支持异步函数，当故意禁用取消时，这些函数会独立继续。

这是一个重要的生产模式：

插入应使过时的工作无效，而不仅仅是过时的语音。

对于事务性代理，我们仍然需要幂等性、授权、数据库级正确性和补偿逻辑，这些都在 Pipecat 之外。

框架可以协调取消，但它无法使设计不良的业务操作变得安全。

4、级联语音和语音到语音解决不同的问题

Pipecat 现在支持两种主要的语音架构。

级联路径仍然熟悉：

speech → STT → text LLM → TTS → speech

这让我们可以显式控制转录、模型选择、语音、工具调用和每个边界的指标。它还让我们可以替换一个弱组件，而无需更改堆栈的其余部分。

替代方案是原生实时语音模型：

audio → realtime multimodal model → audio

Pipecat 目前记录了包括 OpenAI Realtime、Gemini Live、AWS Nova Sonic、Grok Voice Agent、Inworld Realtime 和 Ultravox 在内的集成，但两者都不是自动更好的。

当我们需要提供商可选性、显式转录、识别和语音的独立调整或每个阶段的精确可观察性时，我们应该从级联管道开始。

当对话流畅性和更少的实时边界比组件级选择更重要，并且所选提供商为我们提供应用程序所需的工具、合规性、可观察性和语言行为时，我们应该考虑原生语音到语音。

Pipecat 在这里很有用，因为架构选择不会迫使我们放弃对话运行时的其余部分。

5、结构化对话需要状态，而不是一个巨大的提示

预约电话不仅仅是开放对话。它有业务阶段：

识别来电者
      ↓
查找预约
      ↓
收集新日期
      ↓
确认可用性
      ↓
提交更改
      ↓
确认或转接

我们可以将每个指令和每个工具放入一个大的系统提示中，但这使得 LLM 负责隐式维护整个工作流。

Pipecat Flows 是一个可选层，适用于对话确实具有显式状态的情况。

流是节点的图；每个节点可以将模型专注于一个任务，只使用该阶段所需的工具。

官方示例包括餐厅预订、患者入院、保险报价、LLM 切换和向人工进行热转接。

这对受监管或事务性对话很有用，但我们不应该自动使用 Flows。如果我们的代理主要是开放式伴侣或助手，强制每个对话通过严格的图可能会增加不必要的状态管理工作。

在业务流程有结构的地方使用结构。

6、传输是语音体验的一部分

快速模型无法拯救糟糕的媒体传输。

Pipecat 支持 WebRTC 和 WebSocket 选项，但其文档清楚地说明了生产区别：对于面向客户端的实时语音，WebRTC 是首选路径。

WebRTC 在处理抖动、丢包、时间戳、重新连接、回声消除和噪声处理等媒体问题方面比原始 TCP WebSocket 好得多。

WebSocket 对于服务器到服务器的通信、电话集成、受控网络和原型设计仍然有用。

这很重要，因为语音延迟不仅仅是模型延迟。

它是：

网络
+ 轮次检测
+ STT
+ LLM 首个令牌
+ 文本聚合
+ TTS 首个音频
+ 播放缓冲

Pipecat 的文档说许多配置可以在大约 500 到 800 毫秒内完成完整的交互往返，其快速入门将典型往返描述为不到一秒。

我们应该将其视为项目文档目标，而不是通用基准。实际数字取决于提供商、地理位置、上下文大小、音频路径、网络条件和轮次设置。

好消息是 Pipecat 在我们需要的地方提供了指标：服务 TTFB、处理持续时间、从第一个 LLM 令牌到完整 TTS 句子的延迟、LLM 令牌使用量、TTS 字符使用量和轮次完成计时。

这使得"机器人感觉慢"变得可诊断。

7、Pipecat 何时赢得其复杂性

当我们同时需要以下几项时，Pipecat 最强大：

• 多个可互换的 STT、LLM、TTS 或实时提供商；
• 自然中断和轮次管理行为；
• 生命周期必须跟随对话的工具；
• 一个运行时模型背后的 Web、移动、电话或多模态传输；
• 结构化业务流程加开放式推理；
• 阶段级延迟和使用可观察性。

在那种环境中，自己构建相同的协调层很快就会变成框架工作。

但存在真正的成本。

Pipecat 引入了自己的帧、处理器、生命周期、聚合器、轮次策略和调试模型。

单提供商原型使用提供商的原生实时 SDK 可能更简单。如果我们不需要提供商可移植性、自定义管道阶段或跨提供商可观察性，直接的 OpenAI Realtime 或 Gemini Live 应用程序可能需要更少的代码。

也没有框架抽象可以消除提供商现实：

• STT 质量仍因口音和噪音而异。
• TTS 质量和延迟仍因语音和地区而异。
• 实时模型行为仍因提供商而异。
• 电话仍引入自己的媒体和运营商约束。

Pipecat 不会取代代理周围的控制。工具授权、凭据范围、同意、PII 处理、保留策略、业务规则和人工批准仍然属于我们的应用程序和平台架构。

8、如何有效使用 Pipecat

最有效的采用路径不是启用 Pipecat 暴露的每个集成。

而是尽早使实时边界可见：

从保持测量的最简单架构开始：

级联 STT → LLM → TTS 管道通常是最简单的基线，因为每个延迟组件都是可观察的。

如果它改善了我们实际通话中的对话，我们可以稍后转向原生语音到语音。

在优化提示之前启用轮次处理和指标：

出色的提示无法补偿糟糕的轮次结束检测或 700 毫秒的传输停顿。

首先测量这些。

将每个工具视为可中断或故意不可中断的：

查询通常可以取消。支付或已提交的写入可能需要不同的事务模型。

选择应该是明确的。

当业务流程需要状态时引入 Flows：

不要仅仅因为框架可以就将开放对话变成图。

在真实网络和真实口音上测试：

提供商交换在代码中看起来很容易，但识别质量、轮次计时、语音延迟和网络弹性是用户可见的属性。

我们的生产选择应该来自这些跟踪，而不是提供商矩阵。

9、我们应该使用的决策

我们不应该因为 Pipecat 支持很长的供应商列表而采用它。

我们应该在对话本身已成为分布式实时系统时采用它，我们需要一个地方来推理什么正在进行、什么可以中断、哪个轮次是当前的、哪个工具结果仍然有效、媒体如何到达用户以及延迟在哪里累积。

进展很简单：

    原型
STT → LLM → TTS
        ↓
    真实用户
轮次 + 插入 + 网络
        ↓
    真实业务操作
工具 + 取消 + 状态
        ↓
    生产
传输 + 指标 + 策略 + 恢复

这就是 Pipecat 帮助组织的。

该框架不会使语音 AI 变得容易。它使困难的部分显式且可组合。

对于实时语音代理，这就是重要的区别。

原文链接：Pipecat: What It Really Takes to Build a Real-Time Voice AI Agent

汇智网翻译整理，转载请标明出处