LiveKit Agents：让任何 LLM 都能跑成实时语音 AI 的开源框架

发表于 分类于 ，
LiveKit 开源的实时多模态 Agent 框架，把 STT、LLM、TTS、WebRTC、SIP 电话、多 Agent 协作和测试框架打包成一个 Python SDK，帮你 30 行代码搭出一个能听能说的生产级语音 Agent。

LiveKit Agents：让任何 LLM 都能跑成实时语音 AI 的开源框架

你有没有遇到过这种场景：在公司客服系统上线一个 AI 语音助手，结果发现 OpenAI Realtime API 只支持自家模型？换到 Deepgram STT + Anthropic Claude + Cartesia TTS，延迟飙升到 5 秒以上？想加个” 用户没说完就打断” 的语义判断，自己写 VAD 模型调了半个月？最后生产环境还要解决并发分发、电话接入、PSTN 拨号……

如果你正在被这些细节折磨，今天 GitHub trending 上的 LiveKit Agents 值得你花 10 分钟了解一下：一个 Apache-2.0 开源的实时多模态 Agent 框架，把语音 AI 全栈打包装进了一个 Python 包。12.2k stars，今天还在以 432 stars/day 的速度增长。它解决的恰恰是上面提到的每个工程痛点。

项目背景：为什么需要” 语音 Agent 框架”

2024 年起，OpenAI Realtime API、xAI Voice、Moshi 等” 原生多模态” 模型把语音 AI 拉到了 Demo 惊艳、生产拉胯的尴尬境地。Demo 里你说一句它就能秒回，但生产里你马上会遇到三个问题：

  1. 供应商绑定。Realtime API 通常只跑自家或少数合作模型，一旦你想换 LLM 就要重写整套轮子。
  2. 延迟叠加。把 STT + LLM + TTS 串起来，” 流式 + 流式 + 流式” 听起来很美，实际断句、首字延迟、端点检测每一步都可能踩坑。
  3. 部署和测试。Demo 跑通不等于生产能跑：怎么水平扩展？怎么接电话？怎么做端到端评测？

LiveKit（一家做开源 WebRTC 基础设施的公司）过去几年一直在做实时音视频的传输层，2024 年开始把所有这些经验抽象出来，发布了 livekit-agents Python SDK：它不发明自己的模型，而是把任意 STT / LLM / TTS 组件像乐高一样拼成一个” 实时语音 AI Agent”，并且自带上线所需的所有脚手架 —— 并发分发、SIP 电话、多 Agent 接管、内置测试框架。

核心功能亮点

下面这几个是它在 GitHub README 里主推的能力，也是把它和” 又一个大模型 SDK” 区分开的关键：

1. 任意组合 STT/LLM/TTS，不绑定供应商

最大的特点是 pipeline 化。不强制你用某个模型，而是定义好统一的接口（STT / LLM / TTS），用哪个就 import 哪个。Realtime API（OpenAI、Google Gemini Live、阿里 Qwen-Omni）也能直接用作一整段大模型，跳过 STT/TTS。

1
2
3
4
from livekit.agents import inference
stt = inference.STT("deepgram/nova-3", language="multi")
llm = inference.LLM("google/gemma-4-31b-it")     # LiveKit Inference 托管的低延迟 Gemma
tts = inference.TTS("cartesia/sonic-3", voice="9626c31c-bec5-4cca-baa8-f8ba9e84c8bc")

想换 OpenAI 也只需要把 inference.LLM(...) 换成 openai.LLM(model="gpt-4.1-mini")。这种” 组件可插拔” 的结构对生产环境特别友好：你可以根据成本和合规需要随时替换底层。

2. 内置 Agent 任务调度器

AgentServer 不只是一个类，它是一个能水平扩展的多 Agent 调度器。你把服务进程跑在 N 台机器上，LiveKit Cloud（或自托管 server）会按房间、Worker 注册情况自动分发 job。这是它和” 裸写一个 FastAPI + WebSocket” 最大的区别 —— 你不需要自己撸一套分配系统。

@server.rtc_session() 装饰器 + JobContext 一行起步，没有样板代码。

3. 语义轮次检测（Semantic Turn Detection）

传统 VAD（Voice Activity Detection）只看能量阈值，用户说到一半” 嗯……” 就会被错断。LiveKit Agents 自带一个基于 Transformer 的语义判断模型，能识别” 用户只是停顿思考” vs “用户真的讲完了”—— 这是 2025 年后所有做语音 AI 的公司集体补齐的能力，但它直接帮你内置好了。

4. MCP 一行集成

工具调用支持 MCP（Model Context Protocol），只需要一行：

1
2
from livekit.agents import mcp
agent = Agent(instructions="...", tools=[mcp.MCPServer("http://localhost:3000")])

这意味着你可以把你已有的 MCP 工具（数据库查询、订单系统、CRM）直接当成 Agent 工具用，不需要为每个业务系统再写一层适配。

5. SIP 电话集成 & 通话测试

通过 LiveKit SIP，能让你的 Agent 接听和拨打真实电话。README 里直接给了 outbound caller 的示例代码（外呼销售、外呼提醒、客服回访）。这一点是 OpenAI Realtime API 到今天还做不漂亮的部分。

6. 内置测试框架

Voice Agent 最难的是测，因为结果不是布尔值。LiveKit Agents 提供了一个 pytest 风格的测试 DSL：

1
2
3
4
result = await sess.run(user_input="Hello, I need to place an order.")
result.expect_next_event().is_function_call(name="start_order")
await result.expect_next_event().is_message(role="assistant")
judge_with(llm, intent="assistant should be asking the user what they would like")

可以断言事件顺序，再用 LLM-as-judge 验证语义 —— 这是把 AI Agent 从” 跑通就好” 推进到”CI 永远绿” 的关键。

实战示例：30 行写一个能听能说的语音助手

下面这段代码来自 README 的入门示例，几乎是” 最短可用版本”：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
from livekit.agents import (
    Agent, AgentServer, AgentSession,
    JobContext, RunContext, cli, function_tool, inference,
)

@function_tool
async def lookup_weather(context: RunContext, location: str) -> str:
    """Used to look up weather information."""
    return f"weather in {location} is sunny, temperature 70 degrees"

server = AgentServer()

@server.rtc_session()
async def entrypoint(ctx: JobContext):
    session = AgentSession(vad=inference.VAD())

    stt = inference.STT("deepgram/nova-3", language="multi")
    llm = inference.LLM("google/gemma-4-31b-it")
    tts = inference.TTS("cartesia/sonic-3", voice="9626c31c-bec5-4cca-baa8-f8ba9e84c8bc")

    agent = Agent(
        instructions="You are a friendly voice assistant built by LiveKit.",
        tools=[lookup_weather],
    )

    await session.start(agent=agent, room=ctx.room)
    await session.generate_reply(instructions="greet the user and ask about their day")

if __name__ == "__main__":
    cli.run_app(server)

把这个跑起来需要：

  1. pip install "livekit-agents[openai,deepgram,cartesia]"
  2. 配置环境变量：LIVEKIT_URL、LIVEKIT_API_KEY、LIVEKIT_API_SECRET
  3. 注册一个 LiveKit Cloud 项目（或者 livekit server start 本地起一个）
  4. 用 LiveKit 自带的 Web 客户端连进同一个 Room，就能和你的 Agent 对话了。

可以看到它把 WebRTC 房间管理、模型编排、工具调用、首句引导全部藏在 SDK 里，业务开发者只需要写” 这个 Agent 应该会什么、提供哪些 function_tool”。

进阶：多 Agent 接管

README 里还有一个有意思的 pattern——handoff：

1
2
3
4
5
6
@function_tool
async def information_gathered(self, context, name: str, location: str):
    context.userdata.name = name
    context.userdata.location = location
    story_agent = StoryAgent(name, location)   # 切换到一个更专精的 Agent
    return story_agent, "Let's start the story!"

这种” 采集用户的名字和地点后切到故事 Agent” 的设计，本质上是把人设 / 职责切换变成了一层函数调用，比 CrewAI 那种多 Agent 编排要轻很多，适合电话客服那种” 开场先问身份、根据答案分流到不同专业 Agent” 的真实业务。

适用场景和限制

适合用它的场景：

  • 企业语音客服：需要接电话、转人工、查工单、和 CRM 对接。
  • 多模态 AI 助手：接入摄像头后能” 看见” 用户（README 里给了 Gemini Live Vision + iOS App 的端到端示例）。
  • 语音工作流自动化：和销售 / 排程系统对接，用自然语言完成” 帮我约下周二下午的客户”。
  • 快速做 PoC：上面那段 30 行代码就是” 听你说、答你话、能查天气”，足够做内部 demo。

目前的限制和坑：

  • 强依赖 LiveKit Cloud 或自部署 LiveKit Server。即便你的模型是自托管的，信令 / 媒体服务还是绕不开 LiveKit。如果你的 IT 政策严禁使用任何托管 SaaS，需要自己准备一套 LiveKit Server 集群。
  • Python only 是主仓库，Node.js 用的是另一个 agents-js 仓库，功能会落后一段时间。
  • Realtime 模型 vs Pipeline 模型的选择仍然要自己做：Realtime（OpenAI、Google Live）首字延迟最低但模型黑盒；Pipeline（STT+LLM+TTS）每一步可观测、可换供应商，但调试更繁琐。
  • 测试框架好用，但 judge 模型本身需要额外成本 ——CI 里跑 LLM-as-judge 不便宜，建议只在关键路径用。

和同类项目的差异

如果和同样在做” 语音 Agent 编排” 的几个项目对比：

  • Pipecat（Daily）：另一个很流行的 Python 语音 pipeline 框架，组件也很丰富，但调度、测试、SIP 这层基础设施比 LiveKit 弱，更适合做研究型 pipeline 原型而不是直接上线。
  • OpenAI Realtime API：用最简单，但模型绑死 OpenAI、延迟和定价都是它说了算，且接电话这种” 运营商级” 事情做不了。
  • Vapi / Retell / Bland 等 SaaS：开箱即用、托管化，但你的对话数据要过它们的服务器，定制空间也有限。LiveKit Agents 是” 给你源码、给你 SDK、给你自托管的路” 那种姿势。
  • Vocode / FastRTC：聚焦 dev 友好，但生产部署需要自己写一堆 WebRTC / 状态管理代码。

一句话总结：LiveKit Agents 的卖点不是” 我有一个特别聪明的模型”，而是” 我能让你用一个普通的 LLM 在生产环境里安全稳定地接电话、跑并发、被测试”。这正是 2026 年语音 AI 真正想落地的团队缺的东西。

总结

LiveKit Agents 不是又一个玩具级的” 语音对话 demo”，它补齐的是从 demo 到 production 之间那道最深的沟：任意模型组合、并发分发、电话接入、语义轮次、测试断言 —— 这些是真正能把”AI 语音客服” 卖给企业客户的工程能力。Apache-2.0 开源、自带 LiveKit Cloud 也能自托管、Python SDK 写得相当克制。如果你最近在为语音 AI Agent 选型，强烈建议拿它和你现有的方案对一下清单，看看它能帮你省下多少行 WebSocket 管理代码。