LiveKit

LiveKit 是一个开源的实时通信基础设施平台和 AI 代理框架，由 Russ d'Sa 和 David Zhao 于 2021 年创立。它为 OpenAI 的 ChatGPT 语音模式（Voice Mode）提供底层语音基础设施支持，并已被 Tesla、Salesforce Agentforce、xAI 以及紧急服务运营商投入生产环境使用。2026 年 1 月，LiveKit 在 Index Ventures 的领投下以 10 亿美元的估值筹集了 1 亿美元，巩固了其作为大规模企业级语音 AI 部署首选基础设施层的地位。

该平台提供两款相互关联的产品：一款基于 Go 语言、采用 Apache 2.0 许可的 Selective Forwarding Unit (SFU) 媒体服务器（在 GitHub 上拥有 18.5K 颗星）；以及 LiveKit Agents，一个用于构建实时语音 AI 代理的 Python 和 Node.js 框架（截至 2026 年 4 月版本为 1.5.7，拥有 10.3K 颗星和 3.1K 个分支）。Agents 支持完整的 STT-LLM-TTS 管道，并原生集成了 OpenAI GPT-4o 和 Realtime API、Deepgram 语音转文本、Cartesia TTS、带视觉功能的 Google Gemini Live 以及 Silero 语音活动检测。语义轮次检测、模型上下文协议 (MCP) 工具支持、SIP 电话以及内置的代理可观测性平台进一步完善了其生产级功能集。

LiveKit 在 2026 年 5 月的实际功能

LiveKit 的服务器采用 SFU 架构处理实时音视频路由：发布者向服务器发送一个编码后的媒体流，服务器在不重新编码的情况下将其转发给订阅者，从而保持较低的上行带宽和极低的延迟。该服务器支持水平扩展，使用 Redis 在节点之间进行点对点路由，并且可以在单个 VPS 或具有相同配置的数百个节点上运行。代理层位于此传输层之上，将 AI 模型连接到 WebRTC 流。

LiveKit Agents 框架定义了一个标准管道，用于处理语音活动检测、转录、LLM 推理和文本转语音播放。2025 年引入的语义轮次检测使用 transformer 分类器来判断用户何时完成发言，而不是仅仅依赖静音时长。这显著减少了在嘈杂环境中或用户在句子中间停顿时发生的错误中断。由 d'Sa 撰写并于 2024 年 10 月 3 日发布的 OpenAI 合作伙伴关系公告，推出了内置 OpenAI Realtime API 支持的多模态代理 API（Multimodal Agent API），提供约 300ms 的双向音频延迟以及播放期间的自动转录同步。开发者首次能够使用与 ChatGPT 内部完全相同的语音基础设施来构建应用程序。

除了语音之外，该平台还支持物理 AI 用例。Tesla 的部署涵盖了销售、道路救援、保险和支持等场景，在这些场景中，车辆或设施需要与云端托管的代理进行双向音频流传输。SFU 负责底层媒体路由；Agents 框架则负责对话逻辑。

"LiveKit 的灵活性和性能对于提供可靠、低延迟的语音体验至关重要。" - Thomas Cornelius，Product Hunt，2025 年 5 月

LiveKit 与 Pipecat 和 Daily 的定位对比

Pipecat 是架构上最接近的竞争对手。Pipecat 由 Daily 团队构建并使用 Python 开源，采用基于帧的管道模型：音频帧流经有序的阶段，从传输到 STT，再到 LLM、TTS 并返回。这种抽象对于习惯管道思维并希望灵活插拔 AI 服务的开发者来说非常直观。Pipecat 原则上与传输无关，技术上可以连接到 LiveKit 房间或其他 WebRTC 后端，但其原生搭配是 Daily 的托管基础设施。其代价是代码冗长：Pipecat 需要更多的手动连接、代码中更多的凭证配置以及更多关于管道排序的决策。对于优先考虑 WebRTC 的团队，LiveKit Agents 提供了更简洁的 API 和更少的样板代码，而 Pipecat 的帧模型则更适合希望对服务间音频流进行细粒度控制的开发者。

Daily 是 Pipecat 背后的公司，运营着自己的托管闭源 WebRTC 基础设施，拥有超过 75 个全球接入点，中位数首跳延迟为 13ms。Daily 的差异化优势在于预构建的功能面：开箱即用的 UI 组件、分组会议室、转录、录音和聊天。希望快速发布视频产品而无需管理媒体基础设施的团队通常会选择 Daily。LiveKit 的差异化优势在于所有权：Apache 2.0 服务器可以在任何硬件上自托管、自由修改并进行全面审计。Daily 没有相应的自托管版本。对于将语音作为核心产品而非附加功能的团队，特别是对于有 HIPAA 或数据驻留要求等合规性需求的团队来说，LiveKit 的自托管选项是 Daily 无法匹敌的决定性优势。

Vapi 和 Retell AI 在此格局中的定位：两者都是完全托管的语音代理平台，抽象掉了整个基础设施层。它们的上手速度更快，不需要服务器管理，但将媒体路由、模型路由和数据管道的控制权交给了第三方 SaaS。当利润率、合规性、延迟 SLA 或深度集成比首次通话时间更重要时，LiveKit 是首选。

"WebRTC 流媒体技术难度很高，而 LiveKit 提供了一个非常适合开发者的托管解决方案。" - Awais Shafique，Product Hunt，2025 年 5 月

代理开发循环的实际情况

一个标准的 LiveKit Agents 项目从一个 Python 工作进程开始，该进程连接到自托管或 LiveKit Cloud 上的 LiveKit 服务器实例。工作进程监听传入的房间或调度，为每个会话生成一个代理实例。代理逻辑被定义为一个类，包含 on_enter、on_message 和 on_exit 的生命周期钩子。模型集成通过插件包添加：pip install "livekit-agents[openai,silero,deepgram,cartesia,turn-detector]~=1.4" 涵盖了最常见的生产技术栈。

对于电话用例，LiveKit 的 SIP 协议栈通过配置层处理入站和出站 PSTN 呼叫，无需额外代码即可将电话呼叫连接到相同的代理管道。2025 年底引入的代理可观测性平台提供了每个会话的时间线视图、轮次检测事件和模型调用日志，使得在不构建自定义日志基础设施的情况下进行生产调试变得易于管理。

测试是该框架中一项值得注意的投入：内置的测试工具包括单元级函数模拟、场景模拟以及基于裁判的验证系统，该系统使用 LLM 来评估代理的响应是否符合测试用例的意图。这比 Pipecat 中可用的基本 CI 钩子或大多数团队对 Vapi 托管代理进行的手动测试要复杂得多。

LiveKit 是为谁构建的

LiveKit 是为希望拥有技术栈控制权的后端工程师提供的基础设施。适合使用 LiveKit 的团队应具备：熟悉阅读 WebRTC 文档的 Python 或 Node.js 开发者，能够运行 Go 二进制文件或 Docker 容器的 DevOps 环境（用于自托管），以及将语音作为核心功能而非可选附加组件的产品。

具体适用场景包括：呼叫量大到足以证明优化每分钟成本比支付托管平台加价更划算的客户支持自动化；需要 HIPAA 合规性和数据驻留且不能委托给第三方 SaaS 的医疗保健和法律应用；需要以最少中间跳数进行双向媒体流传输的机器人和物理 AI 产品；以及需要通过 MCP 将语音与工具使用管道结合的开发者工具和编码助手。像 ElevenLabs 和 Whisper 的用户经常一起出现在 LiveKit 部署技术栈中，通过代理管道馈送其 TTS 或 STT 输出。

Spotify、Meta、Microsoft、Character AI、Speak 和 Fanatics 在 LiveKit 的公开资料中被列为客户，涵盖了从音乐聆听会话到社交网络功能再到粉丝互动平台等各种用例。

2026 年 1 月的 C 轮融资还揭示了一个新兴的物理 AI 细分市场：Tesla 在销售、支持、保险和道路救援的语音交互中使用了 LiveKit。这种部署模式（车辆或设备将实时音频流式传输到云端托管的代理）有别于典型的浏览器到云端呼叫，代表了大多数托管平台根本无法解决的类别。LiveKit 的 SFU 架构在不重新编码的情况下路由媒体，使往返延迟保持在足够低的水平，以满足车辆端部署的需求，在这些场景中，额外几百毫秒的延迟就会让体验大打折扣。

LiveKit 不是什么

LiveKit 不提供无代码或低代码界面。没有拖拽式的代理构建器，没有电话号码配置 UI，也没有类似 Vapi 或 Retell 产品的呼叫分析仪表板。每一次集成都需要编写代码。

它不是用于批量音频处理的解决方案。整个平台都是围绕实时流媒体构建的；如果工作流不涉及实时会话中的双方，那么 LiveKit 就没有用武之地。

如果您的产品依赖于预构建的视频通话 UI 组件、屏幕共享控件或通话中聊天功能，它不能作为 Daily 的直接替代品。LiveKit 提供媒体基础设施；界面层是开发者的责任。这种区别在实践中很重要：构建类似 Zoom 产品的团队会发现 Daily 的发布速度更快，因为 Daily 捆绑了 UI 原语。而在自己的 Web 应用之上构建语音优先的客户支持产品的团队会发现 LiveKit 更合适，因为他们不需要 Daily 捆绑的界面组件，也不想为此付费。

LiveKit 也不适合主要关注小呼叫量运行成本的团队。在小规模下，像 Vapi 这样的托管平台每分钟的开销可以忽略不计，而且不管理 WebRTC 基础设施所节省的工程时间远远超过了成本差异。自托管选项使 LiveKit 真正免费运行，但“免费”的基础设施仍然需要工程师来维护。只有当团队有足够的呼叫量，使得每分钟的 SaaS 加价成为值得优化的项目时（通常在每月 50,000 分钟以上，这大致对应于 LiveKit 自己的 Scale 层级阈值），经济效益才会明显倾向于 LiveKit。

如果是为了快速制作原型，请跳过 LiveKit。如果目标是在一个周末内测试语音代理概念，Vapi 或 Retell 将在不到一小时内生成一个可用的电话号码和呼叫流程。LiveKit 的设置（即使使用云托管选项）也假定用户熟悉 WebRTC 概念、Python 异步编程和分布式系统调试。然而，克服了这一学习曲线的开发者经常指出，他们获得了足够的底层理解，使得 LiveKit 难以被放弃：正如一位 HackerNews 评论者所说，一旦你足够了解 LiveKit，你对 WebRTC 内部机制的了解就会“多到不健康的地步”，这让你下次更有可能自己动手构建。这一观察听起来像是批评，但也证明了 LiveKit 成功地向认真使用它的工程师传授了底层基础设施知识。