小呼叫中心该用哪套开源语音 Agent：LiveKit、Pipecat、Vocode 和决定成败的成本算术

十坐席的呼叫中心花两周比功能表，选了 star 最多的那套，试点时才发现真问题是 SIP 桥、端点检测老抢话，以及一个从 2024 年起就没提交过代码的仓库。

💡 你将学到

十坐席的呼叫中心花两周比功能表，选了 star 最多的那套，试点时才发现真问题是 SIP 桥、端点检测老抢话，以及一个从 2024 年起就没提交过代码的仓库。

📜 目录

• 三套栈的现状
• 第一关：电话怎么进来
• 第二关：打断，演示最容易死在这里
• 第三关：延迟预算
• 第四关：成本算术
• 第五关：能不能看出这通电话为什么失败
• 两周试点该量什么
• 那到底选哪个

十二个坐席的呼叫中心真正要问的不是哪个框架 API 好看，而是：它能不能礼貌地被打断，第 41 通电话失败时我能不能看出原因，凌晨两点电话桥挂了谁来修。现在讨论最多的三套开源栈，对这三个问题给出的答案不一样。

下面的数字都是 2026-10-24 从 GitHub API 和 PyPI 取的。厂商没公开的，就写没公开，不编。

三套栈的现状

LiveKit Agents：14,907 star，Apache-2.0，最后提交 2026-10-23，814 个未关 issue，PyPI 版本 1.8.8。电话能力来自它自己的 SIP 栈（livekit/sip，486 star，SIP 转 WebRTC 的桥），另有 job 调度用的 dispatch 接口，以及一个基于 transformer 的语义轮次检测，用来判断对方说完了没有。

Pipecat：16,751 star，BSD-2-Clause，同样 2026-10-23 有提交，432 个未关 issue，PyPI 版本 1.13.0。传输层支持 Daily WebRTC、FastAPI websocket、LiveKit、SmallWebRTC、Vonage、WhatsApp 和本地音频；序列化层覆盖 Twilio、Plivo、Telnyx、Exotel、Genesys、Vonage。

Vocode：3,806 star，MIT，只有两个未关 issue，最后提交是 2024-11-15。对生产选型来说这个日期就是全部结论：二十三个月没有提交，意味着底层语音和电话 SDK 变了之后没人修。star 数只代表关注度，不代表能用。

第一关：电话怎么进来

这一关最多人做反。号码已经在 SIP 中继或者换不掉的话，你需要一条从中继进到音频循环的桥。LiveKit 在自家产品里解决：SIP 通话作为房间里的一个参与者进来，Agent 加入房间即可。Pipecat 走序列化：把运营商本来就有的 Twilio、Telnyx 这类通话变成 websocket 流接进管道。没有谁绝对更好，LiveKit 路线默认你愿意自建或付费托管，Pipecat 路线默认运营商媒体流靠谱，大厂基本成立，转售商看运气。

第二关：打断，演示最容易死在这里

用户会不停抢话。三件事要一起工作：不被背景噪音触发的语音检测，判断「说完了」而不是「停顿了」的端点检测，以及能把 TTS 流当场掐断的打断路径。最毁试点的参数是静音阈值：太短，想半秒的人都会被抢话；太长，每一轮都像卫星电话。先按半秒起，然后看头二十段录音里真人被切断的比例。LiveKit 的语义轮次检测就是为了把这个取舍变软，代价是一点延迟。

第三关：延迟预算

体感延迟分四段花：端点等待、语音识别出终稿、模型出第一个 token、语音合成出第一帧音频。加起来和「用户开始喂喂喂」的间隔比。实操上一秒以内像对话，超过两秒必然出现连续喂喂，第一印象就没了。优化之前先把四个时间戳打出来：停止说话、转写完成、首 token、首帧音频。没有这四个戳，所有延迟争论都是观点，而最常见的盲目修法（全部改流式）换来一点点收益和一大笔账单。

第四关：成本算术

四块钱：电话分钟、语音识别、语音合成、模型 token。框架本身三套都免费，所以栈的选择只通过两件事影响成本：换供应商是否方便，语音层能不能自建。自建语音是量的游戏，按月通话分钟算的盈亏平衡点大致是：GPU 每小时成本乘 730，再除以 API 每分钟的价钱。GPU 每小时 0.50、API 每分钟 0.02 时，大约 18,250 分钟一个月。表里给的是同一套算术的几组组合，按自己的数字找行，别争论谁家便宜。

两个前提要说清：表里是总通话时长，不是并发数，一张卡能同时跑若干路，真实容量比表里高；自建还要加一份值班成本，这笔钱不会出现在表里，但一定会出现在第一次故障里。一个月六千分钟的十坐席店铺离平衡点很远，老老实实用 API。

第五关：能不能看出这通电话为什么失败

每通失败的电话都有形状，录音本身很少能解释。需要的是一份带时间戳的转写、Agent 调了哪些工具和参数、第三关的四个延迟戳、以及转人工的原因。两套活跃框架都能接 tracing，但都要你自己决定 trace 里放什么，这件事要在试点前定，出了问题再补等于凭记忆复现故障。试点真正要看的指标是自助解决率：在接进机器人的电话里，有多少没转人工就解决了。转人工不是失败，绕了九十秒才转才是。把转人工原因做成分类，第三第四个高频原因通常就是下一轮迭代的业务理由。

两周试点该量什么

五十通真实来电，走备用号码，录音要有告知和同意；端到端延迟的 p50 和 p95；头二十段录音人工数打断错误；自助解决率按来电原因分开算，不要平均成一个数；每通成本用你自己的账单算，别用厂商计算器。两周够看出端点检测错不错，不够宣布胜利；跳过试点的团队通常在真实流量里、在有客户的情况下，才发现声学问题。

那到底选哪个

要自建媒体设施、希望 SIP 是一等公民，选 LiveKit 更稳：开发活跃、有专门的 SIP 桥、自建累了还能走托管。号码已经在 Twilio、Telnyx、Plivo、Vonage 上、想把 Agent 做成可以换供应商的管道，Pipecat 的序列化覆盖是最短路径，传输层也允许你先用 websocket 上线、以后再转 WebRTC。Vocode 的会话状态抽象值得读，但作为要活两年的系统的依赖不值得，这不是批评设计，是陈述提交日期。还有一点对比文章很少提：两套活跃栈变得都很快，写这篇文章时两边都在最近一天内发过版，未关 issue 都是几百个。锁版本、升级前读变更说明、把语音供应商挡在自己的接口后面，这样一次破坏性改动只花一个下午，而不是重写。

如果通话转写要留在自己机器上，见 自建转写那篇对比；如果 Agent 背后的模型跑在自己的服务器上，见 Linux 上跑本地大模型那篇。