Pipecat

Pipecat 是一款开源 Python 框架，用于构建实时语音和多模态对话式 AI 代理。它由成立于 2016 年的 WebRTC 基础设施公司 Daily 创建，由联合创始人兼 CEO Kwindla Hultman Kramer 领导，并于 2024 年 5 月在 Hacker News 上开源了该项目。该框架解决了一个具体的工程问题：以足够低的延迟编排语音代理流水线中的语音转文本（STT）、语言模型（LLM）和文本转语音（TTS）步骤，使其听起来像自然的对话。它采用 BSD-2-Clause 许可证，免费使用，无需任何许可费用。

在 v1.1.0 版本（2026 年 4 月发布）中，Pipecat 支持超过 100 种集成，涵盖 19+ 种 STT 提供商（Deepgram、AssemblyAI、Whisper、Sarvam）、35+ 种 TTS 选项（ElevenLabs、Cartesia、OpenAI、Smallest TTS）、25+ 种 LLM 提供商（OpenAI、Anthropic、Mistral、xAI、Inworld Realtime），以及包括 Daily WebRTC、LiveKit、WebSocket、Twilio 和 WhatsApp 在内的传输协议。客户端 SDK 涵盖 JavaScript、React、React Native、iOS (Swift)、Android (Kotlin)、C++，甚至包括用于嵌入式设备的 ESP32。其生态系统包括用于结构化对话状态的 Pipecat Flows、用于多代理交接的 Pipecat Subagents，以及来自 Daily 的可选 Pipecat Cloud 托管服务，专为希望免去自建基础设施麻烦的团队提供。

Pipecat 在 2026 年 5 月的实际功能

Pipecat 的流水线模型是其标志性特征。像 Vapi 这样的托管平台在抽象层背后执行 STT/LLM/TTS 循环，而 Pipecat 则将每一步都变成了显式代码。开发者可以连接流式转录服务、配置端点检测灵敏度、处理部分结果、在转录和 LLM 步骤之间编写自定义逻辑，并精确控制语音的合成和播放方式。这是该框架的核心价值主张，也是其核心成本所在：完全的控制权伴随着完全的责任。

该框架于 2026 年 4 月达到稳定的 v1.0.0 版本，引入了基于 WebSocket 的 OpenAI Responses API 集成、异步函数调用支持以及 Inworld Realtime LLM 兼容性。该版本还附带了一份迁移指南，供从 0.0.x 预发布系列升级的团队使用。两周后发布了 v1.1.0，增加了 Mistral STT/TTS、DTMF（电话键盘）支持、多语言 Deepgram 模式以及 xAI 集成。到 2026 年 5 月，该项目在 GitHub 上获得了 11.7k 颗星，并在整个 2025-2026 年间保持着稳定的月度发布节奏。

Pipecat 在设计上是与传输协议无关的。相同的流水线代码可以在 Daily 的 WebRTC 基础设施、LiveKit 房间、原生 WebSocket 服务器、Twilio Media Streams 或本地音频捕获上运行。当传输协议改变时，流水线逻辑保持不变。这使得在本地进行原型设计、使用 WebSockets 进行测试，并在生产环境中通过 Daily WebRTC 或 Twilio 进行部署成为可能，而无需重写核心代理逻辑。

"语音到语音模型是未来。但今天你在生产环境中应该做的是：一个转录模型、一个文本模式的 LLM 和一个语音生成模型。" - Kwindla Hultman Kramer，Daily CEO 兼 Pipecat 创始人，Freeplay AI 采访，2026 年 4 月

Pipecat Flows 通过用于结构化对话的状态机模型扩展了核心框架：多步接入流程、基于意图的分支以及清晰的节点转换。Pipecat Subagents 处理多代理架构，其中路由代理分发给专门的代理（计费、技术支持、入职）并管理状态交接。这些功能是托管平台要么不提供，要么以对开发者不透明的方式实现的功能。

Pipecat 与 LiveKit Agents 和 Vapi 的定位对比

语音 AI 框架类别目前有三种截然不同的架构方法，Pipecat 与 LiveKit Agents 一起稳稳地占据了开源自建赛道，它在理念上与两者都有所不同，而在基础模型上则与 Vapi 等托管平台区分开来。

Pipecat vs. LiveKit Agents：两者都是需要开发者基础设施的开源框架。关键的机制差异在于它们与传输层的关系。LiveKit Agents 是事件驱动的，并与 LiveKit 的 WebRTC SFU（选择性转发单元）架构紧密耦合：代理作为参与者加入 WebRTC 房间，订阅音频轨道并对事件做出反应。这种耦合赋予了 LiveKit Agents 其独有的能力：视频支持。因为 LiveKit 的 SFU 在房间参与者之间路由视频流，带有虚拟形象（HeyGen、Tavus）的视频代理可以在原生的 LiveKit 房间模型中工作。Pipecat 与传输无关的流水线模型原生并不提供这一点。然而，对于仅限电话或原生 WebSocket 部署，LiveKit 的房间模型会成为一种限制，因为房间抽象增加了开销。Pipecat 使用相同的流水线逻辑处理这些情况。开发者的反馈普遍认为，LiveKit 能更快地让项目跑起来；而 Pipecat 提供了更多的每步控制权，代价是在轮流发言和 VAD（语音活动检测）上需要更多的调优工作。

Pipecat vs. Vapi：这种比较实际上是“自建”与“购买”的对比。Vapi 是一个闭源的托管平台，开发者通过 API 参数（系统提示词、语音提供商、工具定义）配置语音代理，Vapi 的基础设施处理其余部分。实现首次通话的时间大约为两小时。代价是控制权：使用 Vapi，开发者无法在转录到达 LLM 之前拦截或修改它，无法调整 VAD 端点检测灵敏度，也无法在对话中途插入自定义逻辑而不触及托管模型的限制。Vapi 的全包成本为每分钟 $0.05-$0.13。自托管的 Pipecat 只需支付 AI 提供商的 API 费用，当每月超过约 50,000 分钟时，与 Vapi 相比，成本节省估计可达 80%。如果每月低于 10,000 分钟，运行 Pipecat 的工程开销通常会超过每分钟节省的成本。

"GPT-5、最新的 Claude、Gemini 3，它们都达到了我认为非常困难的基准测试的极限。但问题是：它们对于语音代理来说都太慢了。" - Kwindla Hultman Kramer，语音 AI 现状采访，Coval.ai，2026 年

对于将 Pipecat 与 Retell AI 或 Bland AI 进行比较的团队来说，同样的“自建与购买”计算法则也适用：这些托管平台为标准用例提供了更快的上市时间，而 Pipecat 则在定制深度、数据隐私和规模经济方面胜出。

流水线的实际情况

生产环境中的一个最小化 Pipecat 代理涉及几个活动组件：运行流水线的 Python 进程、传输连接（WebRTC 或 WebSocket）、流式传输音频块并返回部分转录的 STT 提供商、检测用户何时完成发言的 VAD（语音活动检测）层、LLM 推理调用、流式传回合成音频的 TTS 提供商，以及如果用户再次开始说话则中断机器人当前语音的播放逻辑（打断机制）。

在生产环境中确保每一步都正确无误需要进行调优。该框架的文档专门包含了一份 STT 延迟调优指南，因为这是一个常见的绊脚石。GitHub 的 issue 记录了用户语音结束和机器人响应开始之间存在 2-5 秒的间隙（issue #1694），一个半双工门控错误，即机器人在完成发言后音频输出门保持关闭（阻止下一次 TTS 播放，直到新的用户语音重置状态），以及没有明显触发原因的句中音频暂停（issue #2941）。当第二个参与者加入基于 LiveKit 的会话时，有报告称出现了严重的延迟和响应排队（issue #3218）。一位大规模部署 Pipecat 的开发者发布的一份生产指南记录了 26 个不同的生产问题，涵盖内存泄漏、VAD 误触发和流水线冻结。

Pipecat Cloud 是 Daily 的可选托管层，它卸载了基础设施部分：配置代理容器、扩展并发以及处理 SIP/PSTN 电话。定价基于使用量，从 0.5 vCPU 容器的 $0.01/分钟到 1.5 vCPU 容器的 $0.03/分钟不等，没有月度最低消费限制。1:1 语音会话包含免费的 Daily WebRTC 传输。Pipecat Cloud 的定位是为那些希望拥有 Pipecat 对流水线逻辑的控制权，但不想为并发语音会话管理 Kubernetes 或 Docker 自动扩展的团队提供一条捷径。它于 2025 年推出，被 Daily 描述为“首个开源语音 AI 云”。

关于搭配建议，2025-2026 年社区对于构建纯语音代理的技术团队的共识是：Pipecat 或 LiveKit Agents 加上用于 STT 的 Deepgram Nova-3，以及用于 TTS 的 Cartesia Sonic-3 或 ElevenLabs Flash v2.5。完整语音循环的延迟目标是中位数低于 800 毫秒；Kwindla 在 Pipecat 2024 年发布会上使用 Deepgram + Groq + Deepgram Aura 演示的 500 毫秒基准，仍然是经过良好调优的提供商选择所能达到的参考点。

Pipecat 是为谁构建的

Pipecat 是为那些需要交付自定义语音代理，并愿意承担使其达到生产就绪状态所需的基础设施和调优工作的工程师编写的。最理想的受众是拥有至少一名精通 Python 的工程师的团队，其用例能够证明工程投资的合理性（自定义对话逻辑、合规性要求、每月超过约 5 万分钟的规模经济，或三者的结合），并且偏好在 AI 服务提供商之间保持供应商中立。

客户支持和呼叫中心自动化是主要的生产类别。自托管的 Pipecat 代理可以通过 Twilio 或 SIP 接入现有的电话基础设施，通过函数调用连接到 CRM，并以托管平台在规模上无法匹敌的成本结构处理数千个并发呼入电话。Pipecat Subagents 使得构建路由逻辑变得切实可行，可以在专门的代理之间移交呼叫者而不会丢失对话上下文。

语音辅导、语言学习和教育是第二大类别。Flows 系统处理结构化的课程进度。多模态扩展（用于视觉的 Moondream，用于视频虚拟形象的 HeyGen/Tavus）可用于提供超越纯音频交流的更丰富的互动辅导体验。

嵌入式和物联网语音代理代表了一个小众但真实的用例。Pipecat 提供了 C++ 客户端 SDK 和明确的 ESP32 支持，涵盖了为硬件设备构建语音界面的开发者。这是 Vapi 和 Retell AI 都没有覆盖的能力空白。

Pipecat 不是什么

Pipecat 不是一个无代码工具。没有可视化构建器，没有提示即部署的界面，也没有供非工程师配置代理的管理仪表板。每个代理都需要为流水线编写 Python 代码并管理部署基础设施，无论是自托管还是通过 Pipecat Cloud。

它不是一个 JavaScript 优先的框架。代理服务器运行 Python 3.11+，服务器端没有官方的 TypeScript 运行时。只有 TypeScript 后端的团队必须将 Pipecat 作为单独的 Python 服务运行。客户端 SDK（JavaScript、React、iOS、Android）处理浏览器和移动端，但流水线本身存在于 Python 中。

它不适合小批量项目，在这些项目中，上市速度比成本或控制权更重要。如果一个团队需要在 48 小时内交付一个基础的语音机器人，或者每月运行时间低于 10,000 分钟，Vapi 托管平台和 2 小时实现首次通话的组合将胜过 Pipecat 所需的数周基础设施设置。该框架的优势在规模和定制深度上会产生复利效应；低于这些阈值，托管替代方案是更实际的选择。

它在传统意义上还不是一个稳定的 API。v1.0.0 于 2026 年 4 月发布，包含与 0.0.x 系列有意为之的破坏性更改以及必需的迁移指南。在生产环境中运行 1.0 之前版本 Pipecat 的团队必须升级其流水线代码，以遵循新的基于 WebSocket 的架构。该项目发展迅速，这既是它的吸引力所在，也是它的维护成本所在。