一句话定义：Pipecat 是一个开源的 Python 框架，用来编排「实时语音智能体」—— 也就是你对着它说话，它能听、能想、能开口回答的那类应用。
一条看不见的流水线
语音对话听起来像一件很自然的事：我说话，它回答。但拆开看，它其实是一条很长的流水线：麦克风采集音频 → 判断用户有没有在说话（VAD, Voice Activity Detection）→ 语音转文字（STT, Speech-to-Text）→ 大模型生成回复（LLM）→ 文字转语音（TTS, Text-to-Speech）→ 音频推回给用户。每一环往往来自不同厂商，流式格式、延迟特性、错误处理方式全都不一样。
Pipecat 做的事，就是给这条流水线定一套统一的接口。它有几个核心抽象：
- Frame（帧）：管线里流动的最小数据单元。一段音频、一句识别出的文字、一个「用户开始说话」的控制信号，都是 Frame。
- FrameProcessor（处理器）：接收 Frame、处理、再往上游或下游推。STT、LLM、TTS 各封装成一个处理器，彼此只认 Frame，不认对方是哪家厂商。
- Pipeline（管线）：把这些处理器串成一条有向的数据流，音频进、语音出。
- Transport（传输）：负责和用户那一端的音视频通道对接，比如 WebRTC、WebSocket，或者接进电话网络。换一种传输方式，业务逻辑基本不用动。
打个比方：它像一个直播导播台。摄像机、麦克风、字幕机、播放器各接各的线，导播台负责调度——谁先谁后、哪路信号该被切掉、输出走哪个通道。你不用每次重新焊一遍线，只需要换插头。
打断：语音体验的关键环节
用户在 AI 说到一半时插一句「等一下，不是这个意思」，这是常态。系统必须立刻停止 TTS 播放、丢弃已经排队但还没播出的句子、把上下文切回「用户在说话」的状态。这件事叫打断处理（interruption / barge-in）。做不好，体验就像对着对讲机讲话；做好了，才像在打电话。Pipecat 把打断、轮次判断（turn detection）这类逻辑做进框架里，这是它区别于「自己拿几个 SDK 拼一拼」的地方。
和相邻概念的区别
| 主要编排对象 | 时间尺度 | 典型痛点 | |
|---|---|---|---|
| LangChain / LangGraph | 文本、工具调用、任务流程 | 秒级到分钟级 | 提示词与流程复杂度 |
| 直接调各家语音 SDK | 单个环节 | 毫秒级 | 拼接、格式转换、打断要自己写 |
| Pipecat | 实时音视频流 + AI 服务 | 毫秒级 | 延迟、打断、传输适配 |
对从业者和普通人的意义
对开发者，它省掉的是那些「没有技术含量但必须做对」的脏活：流式拼接、音频缓冲、打断清理、换厂商。对普通人，它决定的是你愿不愿意继续用某个语音助手——延迟超过一两秒、打断之后它还在自顾自念，人就走了。
Pipecat 最早由实时音视频公司 Daily 发起，后来被语音识别厂商 Deepgram 收购。它在语音 AI 基础设施里的位置，是「开放的中立编排层」：上层接各种应用场景，下层仍然兼容多家 STT、LLM、TTS 供应商，避免把应用锁死在单一厂商上；对 Deepgram 来说，则是从「卖识别 API」上移到「卖对话主干道」。具体支持哪些服务商、许可与商业条款，以官方页面为准。
如果你要做一个能打电话的客服、一个语音陪练、一个车载助手，先想清楚的不是用哪个大模型，而是这条流水线谁来调度。