电话AI代理的耗时大头：不是LLM，是线路与打断

从零构建AI语音代理：真正耗费时间的是那些不起眼的环节

我们最近完成了第一个真正意义上的电话AI代理，并对工程时间的实际去向做了复盘。结果发现，时间并没有花在LLM上。

我们大概只花了15%的时间在对话行为本身的调优上。其余时间全部投入到了围绕它的各种枯燥事务中。

最大的时间消耗点包括：

1. 电话SIP配置、呼叫路由、处理各种奇怪的边缘情况。这部分耗时远超预期。
2. 话轮检测 + 打断响应。让代理在被打断时停止说话，听起来很简单，直到你需要让它在真实电话中可靠地工作。
3. 可观测性。我们的第一版基本上就是把对话记录和事件扔进日志。技术上讲我们有日志，但实际没人愿意翻原始JSON去排查一次通话为何出错。
4. 故障处理。超时、断线、工具调用过慢、语音转文字返回异常等。

这些东西在第一次演示中完全不会出现，然后突然就成了所有人的噩梦。

项目进行到一半时，我们考虑过托管语音代理平台，包括Vapi、Retell和Dasha。

回过头看，我认为一开始就使用托管运行时，把工程时间花在真正的业务逻辑上，会更好。

如果你构建过生产级语音代理，哪部分最终吞噬了你大部分时间？不是那种酷炫的演示效果，而是没有人画进架构图里的烦人环节。

—— 高票评论（帖子共7条讨论）——

[+1] u/BackgroundRiver8182：就是那些没人放进演示里的、不光彩的音频管道活儿。

[+1] u/epictime8：我们这里最隐蔽的时间黑洞是可复现调试。一次失败的通话是单次的——你不能刷新页面。我们最终构建了一个回放框架（音频+工具响应+时间线），这样一来，糟糕的会话就可以离线重跑。没有这个，每一次“它莫名其妙挂断了”都会变成对着时间戳盯一整天。

紧随其后的是：用于打断检测的静音与噪音区分。咖啡馆背景噪音和某人说“嗯哼”对朴素的语音活动检测器来说看起来差不多，而两者都会毁掉话轮切换。

[+1] u/ceyhunkarslan：模型很少是耗时的重点。

延迟、打断处理和奇怪的边缘情况会吞噬数周时间。

在生产环境中，哪种失败模式仍然让你措手不及？

[+1] u/presentofai：话轮结束检测（endpointing）对我们来说是一场BOSS战。判断一个人是真的说完了还是在停顿思考，这一环节破坏通话的次数远超模型本身。

[+1] u/cmtape：构建语音代理就像造一部电话。LLM是来电显示屏幕，人人都拿它拍演示视频；而SIP、语音活动检测和打断逻辑，才是真正的听筒、基带和天线，没人看见，直到电话在楼梯间掉线。大多数团队演示屏幕，然后花几个月焊听筒。