LiveKit

它是什么

LiveKit 是这套"轻量 + 低延迟 + 好管理"方案里真正负责低延迟的那一层：一个用 Go 写的、基于 Pion WebRTC 的可分布式 WebRTC SFU（选择性转发单元）。人、设备、AI Agent 都能以参与者身份进入同一个房间。

它的位置很容易搞混，所以先划清：

Element Call 的群组通话、Stoat 的语音频道，底层都是 LiveKit。 你不是在选一个聊天软件，而是在给聊天软件装一台"低延迟语音引擎"。

为什么 SFU 比 mesh 强（这决定了你的规模上限）

• Mesh（Chitchatter / MiroTalk P2P）：每人和其他所有人各建一路连接，上行 = N-1 路。4 人还行，8 人开始卡，20 人直接崩。
• SFU（LiveKit）：每人只上传 1 路，由服务器按需转发给其他人。配合 simulcast（同时推多档清晰度）和选择性订阅，弱网用户只收到自己扛得住的那档。

顺带一个常被问的点：LiveKit 用的是 Pion——纯 Go 实现的 WebRTC。你不需要碰 C++ 的 libwebrtc，整个项目就是一个 Go 二进制。

上手：5 分钟跑起来

# 安装（单二进制）
curl -sSL https://get.livekit.io | bash      # macOS: brew install livekit

# 开发模式启动（内置一组占位密钥）
livekit-server --dev
# API Key: devkey   API Secret: secret

# 用 CLI 直接造一个测试房间 + 推流
lk token create --api-key devkey --api-secret secret \
    --join --room my-first-room --identity user1 --valid-for 24h
lk room join --url ws://localhost:7880 --api-key devkey --api-secret secret \
    --identity bot-user1 --publish-demo my-first-room

把生成的 token 填进 https://example.livekit.io 就能连上你自己的服务器看到画面。授权模型是 JWT：token 里编码身份和房间权限（能不能发、能不能订、有效期），这也是它比"裸 SFU"更适合做产品的原因。

生产部署：单二进制 / Docker / Kubernetes，支持多区域分布式、UDP/TCP/TURN 兜底。

那些"企业级才算有"的能力

README 列的功能里，对自建通讯最有价值的几项：

• Moderation API（踢人/静音等服务端管控）——管理能力不用自己造
• 端到端加密（E2EE）——SFU 只看密文，适合高敏感场景
• Webhook 事件——房间/参与者进出可触发业务逻辑
• SIP 电话接入——把 PSTN 电话拉进会议室
• Data tracks / 数据通道——低延迟遥测、协同白板
• SVC 编解码（VP9/AV1）——比 simulcast 更省带宽的现代方案
• LiveKit Agents：Python/Node 的实时语音 AI 框架，STT/LLM/TTS/轮次检测/打断处理都含在内，Agent 以"参与者"身份进同一个房间

生产客户是 Salesforce、Nvidia、Oracle、SAP、Deutsche Telekom、Spotify、Tinder、Coursera 等（README 自述每年承载数十亿次通话）。

必须知道的坑

1. 它是基础设施，不是成品软件。LiveKit 给你的是房间、token、轨道、SDK——没有"开箱即用的会议 UI"。要么自己写前端，要么用现成集成（Element Call、Stoat、或者官方示例 livekit-examples/meet）。
2. UDP 端口和带宽是硬门槛。自建要放通 RTC 端口并准备足够的上行带宽；服务器放哪儿直接决定延迟。用 Caddy/Nginx 反代是解决不了 RTC 的（Stoat 的文档也专门解释过这点），要么直通端口，要么配好 TURN。
3. Apache-2.0 很友好，但 Cloud 是商业化的。代码完全开源可商用；LiveKit Cloud 提供托管、Agent 托管、模型推理等增值服务。自建和 Cloud 用同一套 SDK，迁移路径通畅。
4. 需要自己做鉴权与业务。token 必须由你的后端签发（别把 API Secret 放前端），房间权限、用户体系、录制审核这些都得自己接。
5. AI Agent 生态是重点方向，文档更新速度快，但版本迭代也快——锁版本、读 changelog 是必要的。
6. 录制/转码要额外组件（Egress / Ingress 服务），不是 server 自带。

二开与集成建议

1. 组合方案（推荐给自建通讯）：
   • 要 IM + 生态桥接 → Tuwunel + Element Web + LiveKit(Element Call)
   • 要 Discord 式频道管理 → Stoat 全家桶（语音已是 LiveKit）
   • 只要语音房间、自己写界面 → 直接 LiveKit + 自研前端
2. 别自己写 SFU，写业务就好：用官方 SDK（Web / iOS / Android / Flutter / Rust / Python / Go…）+ lk CLI，把精力放在房间生命周期和权限模型上。
3. 从 livekit-examples/meet 起步：想快速有产品，fork 官方 Meet 示例改造，比自己从 RTCPeerConnection 开始省几周。
4. 监控看四个数：房间数、并发参与者、出口带宽、丢包率。SFU 的成本基本就是带宽，容量规划看这四个指标。
5. 要 AI 助手就直接上 Agents：让语音 Agent 作为参与者进房间，比自己拼 STT→LLM→TTS 省太多，且和真人共享同一套房间与权限体系。

一句话总结

LiveKit 是"低延迟"这件事的答案本身：Go + Pion 的 SFU，Apache-2.0、单二进制、20k+ star、企业级生产验证，Element Call 和 Stoat 的语音都跑在它上面；它不解决"管理方便"，但正因为它是被大量成熟客户端复用的底座，你选 Element 或 Stoat 时那条低延迟语音链路已经是现成的——自建通讯真正该下功夫的地方是"消息与权限"，音频传输早就没必要自己造了。