为什么选择 LiveKit
在实时语音 AI 场景里，很多团队起初只盯着音频传输能不能通，但真正落地时会发现更多坑：连接稳定性、会话管理、设备控制、Agent 协同以及扩展能力。LiveKit 的价值在于它不仅是传输层，更是一个面向实时 AI Agent 的平台能力层，统一了房间、参与者、媒体轨道和数据通道能力。
官方定位很明确：构建 voice / video / physical AI agents 的平台。
BK7258 工程架构解析
结合 projects/livekit/ 工程目录，核心模块分工如下：
- main/app_main.c：系统启动入口，负责拉起核心模块
- main/dialog_component/system_manager/system_manager.c：全局状态机（网络、激活、会话、录音、播放）
- main/dialog_component/dialog/dialog_module.c：麦克风采集 + 喇叭播放逻辑
- main/dialog_component/protocols/protocol.c：协议统一门面（WSS/MQTT/LiveKit）
- main/dialog_component/protocols/protocol_livekit.c：LiveKit 协议入口
- main/example.c：join_room() 实现，完成房间创建与连接
- components/livekit/core/engine.c：LiveKit 引擎状态机、信令与媒体通路
一句话理解：system_manager 管流程，dialog_module 管音频，livekit engine 管实时连接。
适配总体流程
实际落地通常遵循这条链路：
- 设备启动：初始化板级外设、音频驱动、任务和事件系统
- 网络就绪：配网成功后，状态机从 NET_* 进入可激活/可连云状态
- 协议层初始化：打开 CONFIG_PROTOCOL_USE_LIVEKIT 后，走 LiveKit 协议分支
- 进入房间：调用 join_room()，构建 room options，准备 server_url/token
- WebRTC 建链：完成 JOIN、addTrack、Offer/Answer、ICE trickle
- 音频上行/下行闭环：上行将 mic Opus 帧送入 LiveKit，下行订阅音频帧写入喇叭播放
- MCP 设备控制扩展（可选）：通过 tools/list 与 tools/call 把'语音问答'扩展到'语音控制设备'
关键配置项
配置阶段，这几个宏开关是关键：
CONFIG_LIVEKIT=yCONFIG_PROTOCOL_USE_LIVEKIT=yCONFIG_PROTOCOL_IOT_MCP=y（如果需要设备工具调用）
音频相关 Opus/AEC/VAD 配置需与云端策略匹配。实践建议先只保留 LiveKit 主链路，尽量减少并发变量（WSS/MQTT 先关），跑通连接与音频后再叠加 UI、摄像头、外设控制。
音频链路是成败核心
整个适配过程中，最关键的是把端侧音频回调和 LiveKit 媒体接口打通：
- 采集侧：音频驱动回调拿到 Opus 帧
- 发送侧：调用引擎发送接口推到 LiveKit 房间
- 接收侧：订阅远端音频帧
- 播放侧：写入 bk_aud_intf_write_spk_data() 到喇叭
最短闭环就是：Mic -> Opus -> LiveKit -> Agent/TTS -> LiveKit -> Speaker。只要这条链路稳定，后续能力都能围绕它扩展。
