LiveKit Agents的深度技术架构，你剖析过吗？
- 内容介绍
- 文章标签
- 相关推荐
LiveKit Agents的深度技术架构，你剖析过吗？这简直是一场噩梦
说实话， 当我第一次看到“LiveKit Agents”这个项目的时候，我的内心是拒绝的。真的。你剖析过吗？如果你没有，那你真是太幸运了。这不仅仅是一个技术框架，这简直是对程序员发际线的一次集体宣战。 泰酷辣！ 我们今天要聊的， 不是那些官方文档上写得漂漂亮亮的“Hello World”，而是真正的、血淋淋的、充满噪音的深度技术架构剖析。准备好了吗？没有？那更好。
不靠谱。 它提供了一个强大的 Worker 模型来管理进程、 连接和作业分配，一边提供通过插件架构集成各种 AI 服务的能力。听起来很完美，对吧？就像广告里说的那样。但是当你真正试图去理解这个“强大”的 Worker 模型时你会发现事情并没有那么简单。这玩意儿到底是怎么把那些乱七八糟的 AI 服务粘合在一起的？
关键音频路径采用零拷贝和微缓冲技术降低延迟。零拷贝！微缓冲！这些词听起来就像是某种高科技，专门用来忽悠投资人的。但不得不承认，它确实在降低延迟。监督树模式确保进程异常自动恢复，支持共享推理资源提升效率，为实时AI应用提供稳定可靠的基础架构。稳定？可靠？在 Python 的世界里？这简直是个笑话，但 LiveKit 竟然做到了，太治愈了。。
摘要：这不仅仅是一份文档， 这是我的血泪史
本文档以资深系统架构师的视角， LiveKit Agents 框架的设计哲学与实现细节。不同于... 不同于那些只会复制粘贴的博客文章，我真的是在熬夜看源码。我的眼睛都快瞎了。 躺赢。 不同于常规的功能说明， 本文将聚焦于并发模型选择、自定义 IPC 协议设计、低延迟音频流处理关键路径以及进程级故障隔离机制。听起来很高大上？其实全是坑。
LiveKit Agents 框架是一个基于 Python 的系统， 旨在构建、部署和管理与 LiveKit WebRTC 基础设施交互的实时对话式 AI Agent。简单说就是提供基于 LiveKit 房间的智能对话能力。但是这种“简单”背后隐藏着巨大的复杂性。你想想， Python 这种语言，天生就不是为高并发实时音视频而生的，LiveKit 居然用它来做这个，这本身就是一种极客精神的体现，或者说是一种自虐。
核心框架团队：那些在幕后默默受苦的人
我们得先看看是谁在造这辆车。核心框架团队 - 负责 livekit-agents/ 目录下的核心功能开发， 包括语音代理会话管理、LLM 集成、STT/TTS 接口等核心模块。这帮人简直是天才，也是疯子。然后是语音技术团队 - 负责 STT/TTS 相关插件， 包括 Deepgram、ElevenLabs、Cartesia 等，如 livekit-plugins-deepgram/、livekit-plugins-elevenlabs/，到位。。
插件，又是插件。现在的软件架构如果不搞点插件化，好像就显不出水平似的。但是 这种插件架构确实解决了大问题，让你可以随意更换那些昂贵的 AI 服务提供商，就像换衣服一样简单，操作一波。。
原来小丑是我。 说到这里我不禁想问，市面上这么多 STT 服务，我们到底该选谁？这简直比选对象还难。为了让大家少走弯路，我熬夜整理了一个表格，虽然可能明天就过时了但至少现在看着挺专业的。
| 服务名称 | 类型 | 延迟表现 | 性价比 | 吐槽点 |
|---|---|---|---|---|
| Deepgram | STT | 极快 | 高 | 有时候会把沉默识别成“嗯...” |
| ElevenLabs | TTS | 中等 | 贵 | 声音太像真人了 吓人 |
| OpenAI Whisper | STT | 慢 | 一般 | 除了准确一无是处 |
| Cartesia | TTS | 快 | 未知 | 名字太难记了 |
实时AI集成：与 OpenAI 的爱恨情仇
瞎扯。 3、实时AI集成:与 OpenAI 的实时 API 深度集成，支持低延迟的 AI 响应和处理.大大简化了多模态 AI应用的开发，高级语音功能也用了相同的技术栈. 看到这句话，你是不是觉得很激动？我也是。但是当你真正去对接 OpenAI 的实时 API 时你会发现那是一个无底洞。连接超时、协议不匹配、莫名其妙的断开连接。LiveKit Agents 项目中 OpenAI 实时语音识别连接异常问题分析，这简直成了我的日常娱乐活动。每次看到那个红色的 Error 报错，我的心跳都会漏半拍。
技术更新内容 最新版本 v0.12.0 中，LiveKit Agents 项目正式合并了对 OpenAI 语音模型的支持。此次更新主要包含两大功能模块：新增对 GPT-4o Mini Transcribe 和 GPT-4o Transcribe 模型的支持。哇，GPT-4o，听起来好厉害。但是你的钱包准备好了吗？每次调用这些模型，我都能听到金币掉落的声音。而且， LiveKit Agents 项目中 OpenAI 工具调用错误分析与解决方案，这又是一个让人头秃的话题。工具调用， 本来是为了让 AI 更聪明，后来啊经常是让 AI 变成了智障，拿着工具不知道怎么用，或者干脆把工具给弄坏了，搞一下...。
架构设计：Supervisor-Worker 模式的双面人生
LiveKit Agents 的核心设计目标是在不稳定的 AI 模型与高实时性的 WebRTC 通信之间建立一道防火墙。为此，框架采用了 "Supervisor-Worker" 的多进程架构模式。这个设计真的很聪明，真的。如果不采用这种模式， Python 的 GIL早就把你的 CPU 吃干了或者一个 AI 模型的崩溃就带着整个房间一起陪葬，我们都曾是...。
高层架构图... 我画不出来主要原因是我的画图工具崩溃了。但是我可以想象。一个 Supervisor 像个保姆一样，盯着一群 Worker 干活。Worker 们负责处理那些脏活累活——连接 AI、 C位出道。 处理音频流。一旦 Worker 挂了Supervisor 就会无情地把它重启，就像什么都没发生过一样。冷酷，但是有效。
框架并没有简单使用 Python 标准库的 `multiprocessing`，而是设计了一套基于 Unix Domain Sockets / Pipe 的高性能自定义二进制协议。为什么要这么做？主要原因是标准库太慢了！太慢了！在毫秒必争的实时音视频领域，标准库的开销简直就是犯法。自定义协议，虽然难写，虽然容易出错，但是快啊！为了那几毫秒的延迟，架构师们也是拼了。
每个 JobProcess 内部运行一个独立的 `asyncio` 事件循环。父进程通过 `loop.run_in_executor` 和 `duplex_unix` 模块将阻塞的 Socket I/O 桥接到 `asyncio` 协程中，实现了跨进程的“全异步链路”。全异步！听起来很性感，对吧？但是写异步代码的痛苦，谁写谁知道。回调地狱， Promise 链，或者 Python 的 await/await/await... 一不小心就把代码写成了一盘意大利面。
低延迟音频流处理：为了那该死的 200ms
在实时 AI 对话中，端到端延迟是核心指标。LiveKit Agents 在架构上对此做了极致优化。极致！你知道为了降低 10ms 的延迟，他们做了什么吗？他们把缓冲区砍到了微乎其微。微缓冲技术。这意味着任何一点网络抖动，或者 CPU 占用稍微高一点，音频就会卡顿。就像走钢丝一样，刺激，推倒重来。。
SupervisedProc 类实现了一个类似于 Erlang OTP 的监督者模式：虽然默认模式是每个 Job 独占资源， 但在 inference_ 中，我们看到了 Shared Inference 的设计蓝图。 结果你猜怎么着？ 共享推理资源。这听起来很环保，很节约。但是多租户之间的资源隔离怎么做？如果我的 AI 对话正在关键时刻， 隔壁老王的 AI 突然发疯占用了所有 GPU 资源，我是不是也得跟着卡？这真是个让人担忧的问题。
说到资源， 我突然想起 AWS Nova 作为亚马逊云科技推出的新一代加速计算实例，凭借其创新的硬件架构和虚拟化技术，贵点就贵点吧。
插件生态：百花齐放还是群魔乱舞？
核心库:通过 pip install livekit-agents 安装， 提供基础的 Agent 运行环境. 安装特定插件，比方说用于 STT 的 livekit-plugins-deepgram: agents Build real-time multimodal AI applications. 这里的插件系统做得还算灵活。 境界没到。 你想用 Deepgram 做语音识别？装个插件。你想用 ElevenLabs 做语音合成？装个插件。你想用 Cartesia？也装个插件。只要钱到位，插件随便配。
但是插件多了也有烦恼。版本兼容性问题简直是噩梦。LiveKit Agents 核心库升级了后来啊插件没跟上，直接报错。或者插件升级了核心库不支持了。这种撕逼的事情在开源界每天都在发生。LiveKit Agents 项目中 Gemini Realtime 模型的对话轮次检测问题解析， LiveKit Agents 项目中 Gemini 2.0 Flash 实时语音转录准确性... 这些问题背后往往都是版本不兼容或者 API 变更惹的祸。
请大家务必... 为了让大家更直观地感受一下这些插件的“威力”，我又做了一个表格。别问我为什么这么勤快，我只是想让大家少踩坑。
| 插件名称 | 功能 | 依赖环境 | 推荐指数 | 备注 |
|---|---|---|---|---|
| livekit-plugins-deepgram | 语音识别 | Python 3.8+ | ★★★★★ | 不解释， 强推 |
| livekit-plugins-elevenlabs | 语音合成 | 需要 API Key | ★★★★☆ | 效果太好，慎用 |
| livekit-plugins-openai | 大模型集成 | OpenAI 账号 | ★★★★★ | 贵，但是好用 |
| livekit-plugins-playht | 语音合成 | 网络通畅 | ★★★☆☆ | 有时候会抽风 |
LiveKit VoicePipelineAgent 初始化超时问题分析与解决方案
这又是一个经典问题。LiveKit VoicePipelineAgent 初始化超时。你满怀信心地启动了服务，后来啊... 超时。超时！为什么？网络不好？API Key 没填对？还是 LiveKit 的代码有 Bug？从架构角度看，这些变化体现了 LiveKit 团队对实时通信系统特性的深刻理解。 我深信... 深刻理解个鬼啊！每次遇到超时我都想把键盘砸了。后来发现，很多时候是主要原因是初始化的时候加载了太多的模型，或者网络连接建立得太慢。解决方案？加超时时间？或者祈祷网络变好？这真是个玄学问题。
项目官网:docs.livekit.io/agents. LiveKit Agents 与 OpenAI 的实时 API 深度集成， 提供超低延迟的 WebRTC 传输，确保流畅的用户体验. LiveKit Agents 的技术原理. 说到底，还是那一套。WebRTC 传输， 从一个旁观者的角度看... SFU 架构。LiveKit 是一个开源的实时音视频通信平台， 采用选择性转发单元架构，能够高效地支持多用户实时互动. SFU，这个架构确实比 MCU 要省流量，特别是在多对多的场景下。但是这也意味着服务器端的压力会比较大。如果你的服务器配置不行，那就别怪视频卡成 PPT。
痛并快乐着
归根结底。 读完本文， 你将清晰掌握 LiveKit 的核心技术演进方向，以及如何利用这些即将到来的功能构建下一代实时互动应用. 真的吗？如果你真的读完了这篇乱七八糟的文章，并且没有被我气死，那你真的是真爱粉了。LiveKit Agents 不仅仅是一个简单的 SDK 包装， 它是一个为长连接、多模态、高并发场景量身定制的工程化容器。它在 Python 的灵活性和生产环境的稳定性之间找到了极佳的平衡点。虽然这个平衡点有时候摇摇欲坠， 虽然有时候你会被各种 Bug 折磨得死去活来但是当你的 AI Agent 第一次流畅地跟用户对话，没有卡顿，没有延迟，那一刻，你会觉得，一切都值了。真的。
文章浏览阅读 301 次。本文介绍了如何在 LiveKit 中利用 Elevenlabs 的 TTS 功能， 涉及 livekit-agents 库的初始化和环境变量配置，特别是 ELEVEN_API_KEY 的设置。这些细节，虽然琐碎，但是缺一不可。就像盖房子， 我们都曾是... 少一颗钉子都不行。所以别嫌我啰嗦，别嫌这篇文章写得烂。技术本来就是这么一回事，充满了噪音、充满了不确定性，但也充满了惊喜。LiveKit Agents，你值得拥有。好了不说了我要去改 Bug 了LiveKit VoicePipelineAgent 又超时了...
LiveKit Agents的深度技术架构，你剖析过吗？这简直是一场噩梦
说实话， 当我第一次看到“LiveKit Agents”这个项目的时候，我的内心是拒绝的。真的。你剖析过吗？如果你没有，那你真是太幸运了。这不仅仅是一个技术框架，这简直是对程序员发际线的一次集体宣战。 泰酷辣！ 我们今天要聊的， 不是那些官方文档上写得漂漂亮亮的“Hello World”，而是真正的、血淋淋的、充满噪音的深度技术架构剖析。准备好了吗？没有？那更好。
不靠谱。 它提供了一个强大的 Worker 模型来管理进程、 连接和作业分配，一边提供通过插件架构集成各种 AI 服务的能力。听起来很完美，对吧？就像广告里说的那样。但是当你真正试图去理解这个“强大”的 Worker 模型时你会发现事情并没有那么简单。这玩意儿到底是怎么把那些乱七八糟的 AI 服务粘合在一起的？
关键音频路径采用零拷贝和微缓冲技术降低延迟。零拷贝！微缓冲！这些词听起来就像是某种高科技，专门用来忽悠投资人的。但不得不承认，它确实在降低延迟。监督树模式确保进程异常自动恢复，支持共享推理资源提升效率，为实时AI应用提供稳定可靠的基础架构。稳定？可靠？在 Python 的世界里？这简直是个笑话，但 LiveKit 竟然做到了，太治愈了。。
摘要：这不仅仅是一份文档， 这是我的血泪史
本文档以资深系统架构师的视角， LiveKit Agents 框架的设计哲学与实现细节。不同于... 不同于那些只会复制粘贴的博客文章，我真的是在熬夜看源码。我的眼睛都快瞎了。 躺赢。 不同于常规的功能说明， 本文将聚焦于并发模型选择、自定义 IPC 协议设计、低延迟音频流处理关键路径以及进程级故障隔离机制。听起来很高大上？其实全是坑。
LiveKit Agents 框架是一个基于 Python 的系统， 旨在构建、部署和管理与 LiveKit WebRTC 基础设施交互的实时对话式 AI Agent。简单说就是提供基于 LiveKit 房间的智能对话能力。但是这种“简单”背后隐藏着巨大的复杂性。你想想， Python 这种语言，天生就不是为高并发实时音视频而生的，LiveKit 居然用它来做这个，这本身就是一种极客精神的体现，或者说是一种自虐。
核心框架团队：那些在幕后默默受苦的人
我们得先看看是谁在造这辆车。核心框架团队 - 负责 livekit-agents/ 目录下的核心功能开发， 包括语音代理会话管理、LLM 集成、STT/TTS 接口等核心模块。这帮人简直是天才，也是疯子。然后是语音技术团队 - 负责 STT/TTS 相关插件， 包括 Deepgram、ElevenLabs、Cartesia 等，如 livekit-plugins-deepgram/、livekit-plugins-elevenlabs/，到位。。
插件，又是插件。现在的软件架构如果不搞点插件化，好像就显不出水平似的。但是 这种插件架构确实解决了大问题，让你可以随意更换那些昂贵的 AI 服务提供商，就像换衣服一样简单，操作一波。。
原来小丑是我。 说到这里我不禁想问，市面上这么多 STT 服务，我们到底该选谁？这简直比选对象还难。为了让大家少走弯路，我熬夜整理了一个表格，虽然可能明天就过时了但至少现在看着挺专业的。
| 服务名称 | 类型 | 延迟表现 | 性价比 | 吐槽点 |
|---|---|---|---|---|
| Deepgram | STT | 极快 | 高 | 有时候会把沉默识别成“嗯...” |
| ElevenLabs | TTS | 中等 | 贵 | 声音太像真人了 吓人 |
| OpenAI Whisper | STT | 慢 | 一般 | 除了准确一无是处 |
| Cartesia | TTS | 快 | 未知 | 名字太难记了 |
实时AI集成：与 OpenAI 的爱恨情仇
瞎扯。 3、实时AI集成:与 OpenAI 的实时 API 深度集成，支持低延迟的 AI 响应和处理.大大简化了多模态 AI应用的开发，高级语音功能也用了相同的技术栈. 看到这句话，你是不是觉得很激动？我也是。但是当你真正去对接 OpenAI 的实时 API 时你会发现那是一个无底洞。连接超时、协议不匹配、莫名其妙的断开连接。LiveKit Agents 项目中 OpenAI 实时语音识别连接异常问题分析，这简直成了我的日常娱乐活动。每次看到那个红色的 Error 报错，我的心跳都会漏半拍。
技术更新内容 最新版本 v0.12.0 中，LiveKit Agents 项目正式合并了对 OpenAI 语音模型的支持。此次更新主要包含两大功能模块：新增对 GPT-4o Mini Transcribe 和 GPT-4o Transcribe 模型的支持。哇，GPT-4o，听起来好厉害。但是你的钱包准备好了吗？每次调用这些模型，我都能听到金币掉落的声音。而且， LiveKit Agents 项目中 OpenAI 工具调用错误分析与解决方案，这又是一个让人头秃的话题。工具调用， 本来是为了让 AI 更聪明，后来啊经常是让 AI 变成了智障，拿着工具不知道怎么用，或者干脆把工具给弄坏了，搞一下...。
架构设计：Supervisor-Worker 模式的双面人生
LiveKit Agents 的核心设计目标是在不稳定的 AI 模型与高实时性的 WebRTC 通信之间建立一道防火墙。为此，框架采用了 "Supervisor-Worker" 的多进程架构模式。这个设计真的很聪明，真的。如果不采用这种模式， Python 的 GIL早就把你的 CPU 吃干了或者一个 AI 模型的崩溃就带着整个房间一起陪葬，我们都曾是...。
高层架构图... 我画不出来主要原因是我的画图工具崩溃了。但是我可以想象。一个 Supervisor 像个保姆一样，盯着一群 Worker 干活。Worker 们负责处理那些脏活累活——连接 AI、 C位出道。 处理音频流。一旦 Worker 挂了Supervisor 就会无情地把它重启，就像什么都没发生过一样。冷酷，但是有效。
框架并没有简单使用 Python 标准库的 `multiprocessing`，而是设计了一套基于 Unix Domain Sockets / Pipe 的高性能自定义二进制协议。为什么要这么做？主要原因是标准库太慢了！太慢了！在毫秒必争的实时音视频领域，标准库的开销简直就是犯法。自定义协议，虽然难写，虽然容易出错，但是快啊！为了那几毫秒的延迟，架构师们也是拼了。
每个 JobProcess 内部运行一个独立的 `asyncio` 事件循环。父进程通过 `loop.run_in_executor` 和 `duplex_unix` 模块将阻塞的 Socket I/O 桥接到 `asyncio` 协程中，实现了跨进程的“全异步链路”。全异步！听起来很性感，对吧？但是写异步代码的痛苦，谁写谁知道。回调地狱， Promise 链，或者 Python 的 await/await/await... 一不小心就把代码写成了一盘意大利面。
低延迟音频流处理：为了那该死的 200ms
在实时 AI 对话中，端到端延迟是核心指标。LiveKit Agents 在架构上对此做了极致优化。极致！你知道为了降低 10ms 的延迟，他们做了什么吗？他们把缓冲区砍到了微乎其微。微缓冲技术。这意味着任何一点网络抖动，或者 CPU 占用稍微高一点，音频就会卡顿。就像走钢丝一样，刺激，推倒重来。。
SupervisedProc 类实现了一个类似于 Erlang OTP 的监督者模式：虽然默认模式是每个 Job 独占资源， 但在 inference_ 中，我们看到了 Shared Inference 的设计蓝图。 结果你猜怎么着？ 共享推理资源。这听起来很环保，很节约。但是多租户之间的资源隔离怎么做？如果我的 AI 对话正在关键时刻， 隔壁老王的 AI 突然发疯占用了所有 GPU 资源，我是不是也得跟着卡？这真是个让人担忧的问题。
说到资源， 我突然想起 AWS Nova 作为亚马逊云科技推出的新一代加速计算实例，凭借其创新的硬件架构和虚拟化技术，贵点就贵点吧。
插件生态：百花齐放还是群魔乱舞？
核心库:通过 pip install livekit-agents 安装， 提供基础的 Agent 运行环境. 安装特定插件，比方说用于 STT 的 livekit-plugins-deepgram: agents Build real-time multimodal AI applications. 这里的插件系统做得还算灵活。 境界没到。 你想用 Deepgram 做语音识别？装个插件。你想用 ElevenLabs 做语音合成？装个插件。你想用 Cartesia？也装个插件。只要钱到位，插件随便配。
但是插件多了也有烦恼。版本兼容性问题简直是噩梦。LiveKit Agents 核心库升级了后来啊插件没跟上，直接报错。或者插件升级了核心库不支持了。这种撕逼的事情在开源界每天都在发生。LiveKit Agents 项目中 Gemini Realtime 模型的对话轮次检测问题解析， LiveKit Agents 项目中 Gemini 2.0 Flash 实时语音转录准确性... 这些问题背后往往都是版本不兼容或者 API 变更惹的祸。
请大家务必... 为了让大家更直观地感受一下这些插件的“威力”，我又做了一个表格。别问我为什么这么勤快，我只是想让大家少踩坑。
| 插件名称 | 功能 | 依赖环境 | 推荐指数 | 备注 |
|---|---|---|---|---|
| livekit-plugins-deepgram | 语音识别 | Python 3.8+ | ★★★★★ | 不解释， 强推 |
| livekit-plugins-elevenlabs | 语音合成 | 需要 API Key | ★★★★☆ | 效果太好，慎用 |
| livekit-plugins-openai | 大模型集成 | OpenAI 账号 | ★★★★★ | 贵，但是好用 |
| livekit-plugins-playht | 语音合成 | 网络通畅 | ★★★☆☆ | 有时候会抽风 |
LiveKit VoicePipelineAgent 初始化超时问题分析与解决方案
这又是一个经典问题。LiveKit VoicePipelineAgent 初始化超时。你满怀信心地启动了服务，后来啊... 超时。超时！为什么？网络不好？API Key 没填对？还是 LiveKit 的代码有 Bug？从架构角度看，这些变化体现了 LiveKit 团队对实时通信系统特性的深刻理解。 我深信... 深刻理解个鬼啊！每次遇到超时我都想把键盘砸了。后来发现，很多时候是主要原因是初始化的时候加载了太多的模型，或者网络连接建立得太慢。解决方案？加超时时间？或者祈祷网络变好？这真是个玄学问题。
项目官网:docs.livekit.io/agents. LiveKit Agents 与 OpenAI 的实时 API 深度集成， 提供超低延迟的 WebRTC 传输，确保流畅的用户体验. LiveKit Agents 的技术原理. 说到底，还是那一套。WebRTC 传输， 从一个旁观者的角度看... SFU 架构。LiveKit 是一个开源的实时音视频通信平台， 采用选择性转发单元架构，能够高效地支持多用户实时互动. SFU，这个架构确实比 MCU 要省流量，特别是在多对多的场景下。但是这也意味着服务器端的压力会比较大。如果你的服务器配置不行，那就别怪视频卡成 PPT。
痛并快乐着
归根结底。 读完本文， 你将清晰掌握 LiveKit 的核心技术演进方向，以及如何利用这些即将到来的功能构建下一代实时互动应用. 真的吗？如果你真的读完了这篇乱七八糟的文章，并且没有被我气死，那你真的是真爱粉了。LiveKit Agents 不仅仅是一个简单的 SDK 包装， 它是一个为长连接、多模态、高并发场景量身定制的工程化容器。它在 Python 的灵活性和生产环境的稳定性之间找到了极佳的平衡点。虽然这个平衡点有时候摇摇欲坠， 虽然有时候你会被各种 Bug 折磨得死去活来但是当你的 AI Agent 第一次流畅地跟用户对话，没有卡顿，没有延迟，那一刻，你会觉得，一切都值了。真的。
文章浏览阅读 301 次。本文介绍了如何在 LiveKit 中利用 Elevenlabs 的 TTS 功能， 涉及 livekit-agents 库的初始化和环境变量配置，特别是 ELEVEN_API_KEY 的设置。这些细节，虽然琐碎，但是缺一不可。就像盖房子， 我们都曾是... 少一颗钉子都不行。所以别嫌我啰嗦，别嫌这篇文章写得烂。技术本来就是这么一回事，充满了噪音、充满了不确定性，但也充满了惊喜。LiveKit Agents，你值得拥有。好了不说了我要去改 Bug 了LiveKit VoicePipelineAgent 又超时了...