Pipecat、LiveKit Agents、TEN 与 Bolna：该买的是媒体通路，不是流水线

速览

四者都免费、都属广义上的宽松许可、都能接起一通电话。它们分歧的是：一个语音智能体本质上是什么。

那条没人写进对比表的轴

一个语音智能体是四样东西叠起来的：把音频在人与你的服务器之间搬运的东西、编排步骤的东西、桥接到电话网的东西，以及一组模型集成。所有对这几个框架的比较，都集中在第二样和第四样上——流水线 API 顺不顺手、接了多少家 STT 厂商——因为那是你写 demo 时会碰到的部分。

那也是切换成本最低的部分。模型插件一个约等于一天的工作量，而且反正一直在被重写。编排层是你自己的代码，你可以移植。媒体通路则不同：它决定了你的基础设施足迹、你的扩缩模型、你的延迟下限、你关于"音频流经何处"的合规说辞，以及自托管究竟是一个勾选项还是一个项目。选它，就是选一个三年后你仍然背着的依赖。

四个项目，四种答案

Pipecat —— 流水线，以及刻意不带传输

Pipecat 是 Daily 的 Python 框架，也是四者中 star 最多的，约 15.5k，采用 BSD-2-Clause。它把一个智能体建模成一条处理器流水线、让帧在其中流动，并且刻意不提供媒体通路：可选传输包括 Daily 的 WebRTC、LiveKit 的 WebRTC、一个 FastAPI WebSocket、一个内置的小型 WebRTC 传输、Vonage，以及本地音频。电话接入是四者中最广的——Twilio、Vonage、Telnyx、Plivo、Exotel 与 Genesys 的序列化器——这意味着同一条流水线只要换掉前门，就既能服务网页挂件，也能服务一个呼入号码。

这份中立既是它的全部卖点，也是它的全部风险。你得到四者中最大的集成面和更新最快的仓库（约 12,900 次提交），并且得由你自己来决定媒体那道题——如果你有主见，这是好处；如果你本来指望框架替你有主见，这就是成本。

LiveKit Agents —— 智能体是参与者，不是流水线

LiveKit Agents 采用 Apache-2.0，约 14.2k star，支持 Python 与 Node.js，并且把模型反了过来：你的智能体是一个可编程的参与者，与真人参与者一同加入一个 LiveKit 房间，跑在 LiveKit 开源的 WebRTC 媒体服务器之上。dispatch API 负责任务调度与智能体启动，工具集成原生支持 MCP。

房间这个抽象不是一种风格偏好。多方场景——一位来电者、一个智能体、一位旁听的主管、一个处理子任务的第二智能体——是原生的而不是外挂的，而热转接也就此不再是一项电话侧的小把戏。电话接入走的是原生 SIP 而非逐家厂商的序列化器：如果你自己落地中继，这是更干净的方案；如果不是，它就更有主见一些。这也是四者中唯一一个"把整条媒体通路自托管"属于受支持、有文档的配置，而不是一项自己折腾的活儿。

TEN Framework —— 一个恰好在做语音的图运行时

由 Agora 支持的 TEN，是四者中结构上最有野心的：约 11.1k star，把智能体描述为一张由节点构成的有向图——STT、LLM、工具、记忆、视觉——而扩展可以用 C/C++、Go、Python 或 JS/TS 来写，不限于 Python。它为那些硬实时的部分自带组件，包括一个 VAD 和一个专门面向全双工对话的轮次检测模型。

有两点要掂量。如果你确实有一个延迟敏感、不该待在 Python 里的组件，这个多语言运行时是真正的差异化；如果没有，它就是真正的额外负担。还有，它的许可证并不是纯 Apache-2.0：仓库声明为 Apache License 2.0 并附加限制，其中 packages 目录以纯 Apache-2.0 单独发布。这是一句该交给批准你依赖的那个人去看的话——在你基于它开建之前，而不是之后。

Bolna —— 电话优先，而且对此很坦白

Bolna 是个异类：约 760 star，MIT 许可，而这个 star 差距会让人读错它。它是一个围着呼出与呼入电话搭起来的 Python 框架——已集成 Twilio 与 Plivo，Exotel 与 Vonage 标注为即将支持——对印度语言与运营商支持很强，背后约有 2,900 次提交。它并不想成为一个通用实时媒体框架；它想让一场电话营销真正跑起来。

对于一支产品就是外呼、且市场恰在大项目视为次要的地区的团队来说，这份专注比更大的插件目录更值钱。对其他人来说，在一个模型层一年要动两次的品类里，更小的贡献者基数是实打实的风险。

它们竞争的那个子系统，正是被删掉的那个

接下来是让这四家都尴尬的部分。过去两年它们投入最重的地方是轮次检测：判断人类什么时候说完了、智能体可以接话了。TEN 把一个轮次检测模型当作头牌组件来发布。LiveKit 与 Pipecat 也都提供了语义端点检测。这是这个品类里最难的问题，也是质量差距最看得见的那个。

而它也正是一个全双工模型让其失去意义的那个问题。自 2026 年 9 月 10 日起进入 API 的 OpenAI GPT-Live-1，会边说边听并自行决定何时开口——没有轮次结束事件供框架去计算，也没有阈值供它去调。这场比较里的每一个框架都会保留一个全双工适配器；问题在于：当适配器成为通用路径之后，它们的差异化还剩下什么。

留下来的，恰恰是本文主张的那张清单：谁拥有媒体通路、你能触达多少家运营商、会话的可观测性如何，以及当模型层再次变动时项目发版有多快。留不下来的，是流水线的优雅。如果你今天是按"哪个 API 在周末原型里用着最舒服"来选，那你优化的是半衰期最短的那部分。

在这里，许可证与维护是选型轴，不是脚注

四者中有三者的许可证，你的法务不看也会批：Pipecat 的 BSD-2-Clause、LiveKit Agents 的 Apache-2.0、Bolna 的 MIT。TEN 的"Apache-2.0 并附加限制"是那个需要真读一遍的。诚实的说法不是它就此出局——而是：现在弄清楚要花五分钟，以后弄清楚要花一次迁移。

维护速度值得同等权重。有用的信号不是 star；这里的前三名彼此相差约三成以内，而 Pipecat 的领先有一部分反映的是该组织如何拆分仓库。真正的信号，是面对一个移动着的模型层时的提交节奏。过去十二个月里落地了两个具备全双工能力的语音模型和一批新的 STT 与 TTS 厂商，而一个框架的价值，几乎全在于它是否已经把它们吸收进来了。

什么时候选谁

把默认建议直说：如果你还没有一条自己的媒体通路，选 LiveKit Agents，因为你最难回头去改的那个决定，正是它替你做了、而且做得很好的那个。如果你已经有一条——一个 Daily 账号、一片 Twilio 资产、一套现成的 WebRTC 部署——选 Pipecat，因为它拒绝对传输持有主见，恰恰就是你想要的。当那个多语言运行时确实回答了你真有的一个问题时，去拿 TEN；当本土市场的电话接入本身就是产品、而不是管道时，去拿 Bolna。

无论选谁，要你自己去建的那一块都是同一块，也正是四者都很薄的那一块：评测。框架能让你拿到一通接通的电话。这几个仓库里，没有任何东西会告诉你这通电话打得好不好。

延伸阅读

本站相关：

• 实时架构 —— 生产语音栈收敛到的那个参考形态。
• 电话与 PSTN 接入 —— 来电者在电话上时，什么会变。
• 轮次切换与打断 —— 本文所说正在被商品化的那个子系统。
• 全双工语音 —— 轮次边界为什么正在消失。
• 评估语音智能体 —— 四者都没有提供的那一块。
• 智能体框架 —— 一般性地该如何判断这一类依赖。

项目来源：

• pipecat-ai/pipecat —— 传输、电话序列化器、BSD-2-Clause。
• livekit/agents —— 可编程参与者、dispatch API、Apache-2.0。
• TEN-framework/ten-framework —— 图运行时、TEN VAD 与轮次检测、许可条款。
• bolna-ai/bolna —— 电话优先的对话式智能体，MIT。