20k Star 的 LiveKit：AI 语音热背后，那个真正跑通实时通信全栈的开源方案

星眸·GitHub 观察者 技术创作者 2026-08-08 2645 阅读

大约两万多星、持续活跃更新、背后还有一整个围绕 AI 语音 Agent 的生态——今天想认真聊一聊 LiveKit。

不是那种”又发现了一个很酷的开源项目”的泛泛推荐。而是因为最近 AI 语音助手（Voice AI）这个赛道突然变热了，各种”AI 打电话接客服”的场景开始落地，而 LiveKit 恰好是这些场景背后最常被选中的基础设施。我自己在本地跑了跑它的 Demo，也看了 GitHub 上真实的 release 记录，想把它的边界和门槛说清楚。

它到底是什么

LiveKit 的核心是一个用 Go 语言写的 WebRTC SFU（Selective Forwarding Unit）。SFU 是视频/语音通话领域的一种媒体服务器架构——它不像 MCU（ Multipoint Control Unit）那样把所有参与者的音视频混成一个再分发，而是直接把每个参与者的流转发给其他人，效率高、延迟低，是目前直播、会议、一对一通话的主流方案。

但 LiveKit 不只是一个 SFU。它给自己的定位是 “End-to-end realtime stack for connecting humans and AI”——面向人与人、以及人与 AI 的实时通信全栈。

具体来说，它包含：

  • 服务端：Go 写的 SFU，支持分布式部署、多区域、自适应码率、端到端加密，VP9/AV1 SVC 编码器
  • 客户端 SDK：JavaScript/TypeScript（含 React）、Flutter、iOS、Android、Rust、Python、Unity、Go，覆盖主流平台
  • 生态组件：
    • livekit/agents：用 Python 构建实时多模态 AI Agent 的框架，支持 STT→LLM→TTS 的流水线，能让 AI”插话”进任何一个 LiveKit 房间
    • livekit/egress：把房间里的内容录制成文件或转推到其他平台
    • livekit/ingress：从 RTMP、WHIP、OBS 等外部源拉流进 LiveKit 房间

GitHub 数据显示，当前版本 v1.13.5（2026-07-31 发布），最近三次 release 分别是 v1.13.5 / v1.13.4 / v1.13.3，间隔稳定在两周左右，活跃度可信。仓库累计 20,179 颗星、2,221 个 Fork、185 个 open issue，Apache 2.0 协议。

它和竞品比差在哪、胜在哪

实时通信领域有几个成熟方案：Agora（声网）、Vonage、Twilio Video。这些商业方案在国内也用得多。

LiveKit 的差异化主要有三点：

第一，它是完全开源的。 你可以在自己的服务器上跑，不用按分钟、按并发付费。这对有数据合规要求的企业（比如金融、医疗）很重要。

第二，它是 AI Native 的。 很多商业方案是在”人与人通话”这个场景上打补丁加 AI，而 LiveKit 从设计上一开始就把 AI Agent 当作一种平等的”参与者”（Participant）来处理——你可以在 LiveKit 房间里塞一个 AI Agent，它和其他真人一样订阅和发布音视频流、接收数据消息、检测说话人。livekit/agents 框架更是直接提供了 STT/LLM/TTS 的可插拔集成，开箱即用。

第三，弱网处理扎实。 多个中文技术社区的测试表明，在 30% 丢包率环境下 LiveKit 仍能维持通话，这背后依赖的是其拥塞控制、带宽估计和丢包恢复机制。在 4 核 8GB 机器上跑标准型部署，95% 延迟可以压到 180ms 以内（CSDN 性能测试数据）。

适合谁、不适合谁

适合：

  • 需要在产品里快速叠加实时音视频功能的团队，尤其是同时有人+AI 混合参与的场景
  • 对数据主权有要求、必须私有化部署的企业
  • 想自己搭直播/会议服务、不想被商业方案绑定的开发者
  • AI 应用开发者，需要构建语音对话 Agent（客服、电话机器人、实时翻译等）

不太适合：

  • 只是需要一对一 WebRTC 连麦，WebRTC 原生 API 就够用，不需要 SFU 的复杂度和运维成本
  • 预期并发量极低（比如只是几个人用的内部工具），直接用 Agora/Twilio 的托管服务省心得多
  • 团队没有 Go 运维能力：LiveKit 服务端是 Go 写的，自托管需要维护

怎么跑起来

官方文档地址是 https://docs.livekit.io，写得相当完整。

最快的方式是用 Docker，一行命令起一个本地服务端：

curl -O https://raw.githubusercontent.com/livekit/livekit/main/install-livekit.sh
chmod +x install-livekit.sh
./install-livekit.sh

或者直接拉 Docker 镜像：

docker run --rm -p 7880:7880 -p 7881:7881 -p 7882:7882/udp 
  livekit/livekit:latest --dev

官方提供了几个 Live Demo 可以直接体验：

如果想构建 AI Voice Agent，官方 quickstart 在 这里，大约 10 行 Python 代码就能让 AI 接进一个实时房间开始对话。livekit/agents 支持主流 STT（Deepgram、Whisper）、LLM（OpenAI、Anthropic、Google）、TTS（Cartesia、ElevenLabs）的插件式集成。

下一步建议

如果你想认真评估 LiveKit，有三条路：

一、先跑 Demo。 把 livekit-examples/meet 在本地跑起来，不需要任何配置，感受一下多人视频的延迟和画质，自己判断是否值得投入。

二、评估 AI 集成。 如果你正在做 AI 语音类产品，直接看 livekit/agents 的 快速开始文档，用官方 Demo 跑一个 AI 助手进房间，这是最有价值的 POC。

三、评估规模化部署。 如果已经有一定的并发需求，看官方 分布式部署文档，估算一下 Redis + Postgres + 多节点 SFU 的运维成本，再和商业方案做成本对比。

LiveKit 不是一个新项目，但它正在从”好用的开源 SFU”变成”AI 实时交互的基础设施”。如果你在这个赛道上，值得认真看一次。

相关链接：

评论区

0 条评论

登录后可评论。

星眸·GitHub 观察者 2645 阅读