语音Agent底座之争：LiveKit凭什么接住ChatGPT千万级通话

前不久一次行业饭局上，一位扎根呼叫中心十余年的老兵抛出一句让我印象深刻的感慨：「咱们现在这套架构，ASR挂一边、TTS挂一边，中间塞个LLM，跟搭积木似的。」他紧接着追问：「可ChatGPT那个语音模式，怎么就能做到随时打断、像真人一样自然接话？」这个问题戳中了行业痛点。翻阅OpenAI的技术资料后，我发现答案指向一个开源项目——LiveKit。它不仅是技术架构的演进，更可能是语音Agent时代的基础设施之争。

从SFU到语音Agent底座

LiveKit是用Go语言编写的开源WebRTC SFU，采用Apache 2.0协议，GitHub星标已过万，2021年成立至今融资至C轮。所谓SFU，是相对于传统MCU架构的演进——MCU像剪辑室，所有流进来混合好再发出去；SFU则像快递分拣中心，只转发不加工，按地址分发流。这种设计大幅降低了延迟和服务器成本，成为当前WebRTC主流方案。但LiveKit的真正价值不止于此：OpenAI已确认将ChatGPT高级语音模式架设其上，每年超过25亿通通话运行其上。这是对一个开源项目最硬核的技术背书——能承载ChatGPT数百万日活用户的实时语音交互，本身就是最好的性能证明。

LiveKit被OpenAI选中的核心原因，在于它从单纯的流转发进化为完整的语音Agent开发框架。它在传统SFU之上构建了轮次检测、打断处理、降噪、录制等关键能力。轮次检测解决的是「用户何时说完」这个看似简单却至关重要的判断——语音机器人最大的槽点「我还没说完它就抢答」，根子就在缺乏精准的端点检测模型。打断处理则实现全双工体验：用户随时插话，Agent立刻停下。2025年9月，LiveKit Agents 1.8.x版本引入DuplexModel类，专门适配「能同时说和听」的端到端语音大模型，首批接入OpenAI的GPT-Live模型。这意味着，当端到端语音大模型真正普及，LiveKit的接口位置已经预留好了。

全双工支持：端到端语音大模型的基础设施

对呼叫中心行业而言，LiveKit最关键的能力是SIP/Telephony组件——它能把AI Agent接入PSTN电话网络，支持呼入和呼出。浏览器里的语音Agent谁都能开发，但能把AI Agent接进真实电话通话的开源方案，凤毛麟角。LiveKit凭借活跃的社区和完善的文档，成为其中最成熟的选择。实际落地分为两步：首先通过Docker快速启动SFU服务，信令端口7880、媒体流端口7882/udp，开发模式免鉴权；其次使用Python或Node.js SDK构建Agent，所有组件采用插槽式设计——STT可选Deepgram/讯飞/火山，LLM可选OpenAI/国内大模型，TTS可选Cartesia/MiniMax，轮次检测模型也可按需配置。框架把轮次检测、打断、重连、录音等工程细节全部封装，开发者只需专注业务逻辑。

落地边界：它不是FreeSWITCH的替代品

尽管LiveKit展现出强大的语音Agent构建能力，但它并非万能解。传统呼叫中心的排队、坐席分配、技能组、话单统计、IVR树等核心功能，LiveKit一概没有——它是AI Agent的底座，而非人工客服的管理平台。当前更现实的架构是：FreeSWITCH及配套系统继续支撑人工服务，LiveKit专攻AI外呼/呼入一路，SIP协议实现两边互通。自建也存在隐性成本：TURN中继服务、TLS证书管理、UDP端口规划缺一不可，想省事可用LiveKit Cloud按量计费，但数据出境问题需纳入合规考量。国内落地还面临模型插槽以海外厂商为主的现实，需自行编写国产STT/TTS适配插件，网络质量直接影响通话体验。综合来看，LiveKit更像是为AI外呼新流量修筑的高速公路——传统呼叫中心不必推倒重来，但AI那条腿，很可能会站在这个底座上加速奔跑。

LiveKit的崛起揭示了一个趋势：语音Agent的核心竞争力正从「模型能力」向「工程底座」迁移。谁能更好地封装流媒体处理、轮次管理、打断响应、SIP接入这些工程挑战，谁就能成为下一个时代的FreeSWITCH。对于正在规划AI外呼系统的团队，与其纠结于「用新底座还是老架构」，不如先想清楚：自己的业务里，哪些环节值得用AI的「真对话体验」重新做一遍。