Vapi 语音 Agent 五大生产失败模式

大多数人在一个下午内就能让 Vapi 语音 Agent 对话起来。快速入门文档写得好，文档齐全，打一个演示电话听起来也足够令人印象深刻，足以让项目获得绿灯。

然后它就遇到了真实通话。

我构建生产级语音 Agent，同时也花大量时间修复那些由别人构建、但最终崩溃掉的 Agent。模式很一致：Agent 的行为完全符合设计，但设计本身从未考虑过它会如何失败。构建过程中没有做错任何事。只是有些问题没有被决定，而生产环境替他们做了决定。

所以，如果你打算雇人来构建一个 Vapi语音 Agent，以下是决定它能否存活下去的五个决策点。在构建开始之前就问清楚。答案在设计阶段毫无成本，放到后面代价就大了。

1. 转移边界上发生了什么

我接到的最常见的生产故障：Agent 外拨，正确导航了 IVR 菜单，转接给真人——然后沉默了。你能听到 Agent，但 Agent 听不到人类。拉取电话运营商自己的录音，音频是完全清晰的。

几乎所有人第一反应都是调优 prompt。Prompt 没问题。

真正发生的事情是：在通话桥接到真人的那一刻，音频传输会重新连接，入站音频开始以片段形式到达，转录器无法组装这些片段。这是一个传输层面的故障发生在交接时刻，不是智能问题。再多的 prompt 工程也触及不到它。

确认问题的方法是：在你控制的测试台上重建相同的转接流程，通过两种不同的传输路径运行。不管哪个出了问题，都告诉你修复应该落在哪里。

问你的构建者：在交接时音频会话会发生什么，我们如何在上线前而不是上线后测试它？

2. 语音邮件在结构上类似于对话

我曾被请去看一个 Agent，它把"合格线索"中的很大一部分推送到客户的 CRM 中作为回拨。那是答录机。

客户对此的描述很直接：Agent 把语音邮件问候误标记为回拨，销售团队回拨的那些人实际上从未与它对话过。

这比一个无用的 Agent 更糟糕。每个误报都消耗了一个人的拨号。设计来减轻销售团队负担的系统，反而在为他们制造工作。

直觉反应是收紧分类 prompt。但这是在和症状斗争，因为机制是结构性的：答录机产生的转录文本看起来就像一段对话。问候、停顿、说话。读取该转录文本的分类器没有强信号来区分"一个人说了你好"和"一段录音说了你好"。你让它去区分两件在唯一可用的数据中确实相似的东西。

修复方法不是更聪明的一次通过，而是二次通过：获取转录文本加上第一个 Agent 给出的处置结果，再问一个独立的模型那个处置是否正确。事后裁决，而非更好的预测。

问你的构建者：系统如何验证自己的处置结果，谁来阅读转录文本？

后半部分比听起来更重要。在那个项目上，构建方没有人真正在阅读转录文本。每个错误都是由客户发现并上报的。这是一个穿着模型故障外衣的流程故障，而客户在不知不觉中成了 QA 层——他们知道这一点，而且对此很不满。

3. 你的验证器会字面理解，它会扔掉好线索

这就是我刚才描述的修复方法中的陷阱。

加入验证环节后，它会开始丢弃真正的线索。不是因为它太严格——而是因为它太字面。被要求判断"这是合格线索吗？"的 LLM 默认会要求一个明确的肯定。任何复杂的条款都会被读作"不是明确的 yes"。

一个明显暴露这个问题的通话：一位潜在客户回答了所有问题，，顺便提到她那周不在，被丢掉了。一个清晰、可工作的线索，就这样被扔掉了。

"是的，但我正在度假"是一条完全可以工作的线索。对于一个字面理解的裁决者来说，这是"否"。

这就是为什么这个问题真的很危险。误报是响亮的——有人在一天内拨打了一个空号并投诉。漏报是沉默的。线索数略低与数据批次略差无法区分。没有任何东西会浮出水面。这种失败被发现的唯一方式是一通被命名的电话，由一个注意到反复出现模式的人类标记出来。

问你的构建者：我们如何抽样检查系统丢弃的线索？

如果这个问题没有答案，系统就有一个盲点，恰好在它造成伤害的地方，而且没有任何机制会报告它。

4. 栈中每个速率限制在扩展之前都是不可见的

一个客户将 Agent 集群扩大了三倍，得到的产出却和之前差不多。引起他们注意的是账单：三倍的 Agent，成本却几乎没动。

信号是平坦的成本。额外的 Agent 几乎没带来额外花费。

成本是实际完成工作的代理指标。增加容量，看着账单保持平稳，你就知道没有额外的工作发生——这将整个调查从"质量"重新定位到"吞吐量"这一步。停止调试 prompt。

原因有很多层，没有一个在语音平台上：

模型提供商的 key 是冷的。Agent 一直是针对一个热的、高等级的 key 构建的。客户自己的 key 被换成了全新的，新的 key 处于最低速率限制层级——它只随已用时间和累计消费攀升。你无法花钱升级。更糟的是，在项目启动时交付的 key 从未被接入，所以在其本可以预热的那段时间里完全没有积累任何预热。

记录存储有每分钟写入上限。在少量 Agent 和短触发间隔下，没有冲突。扩大 Agent 规模后，触发器落在同一分钟内，写入报错，通话记录静默地未能记录。缓解措施——带抖动的更长间隔——限制了整个集群来修复它。

在低 Agent 数量下，栈中每个速率限制都不可见。扩展不会逐渐揭示它们。它同时击中多个，在没有人监视的各层中，而你最可能去责怪的那个平台通常不是问题所在。

问你的构建者：每一层的每分钟上限是多少——模型提供商、电话、编排器，以及末端的记录存储？

最后那个是最无聊的组件，没人盘点，但它是我最常发现拖累整个系统的东西。

5. 是否任何东西可以在没有人先看到的情况下发出

最后一个决策听起来像是开销，但其实不是。

我见过的最强构建把每个出站操作——每通电话、每条消息——默认放在干跑门控后面。在人类明确释放之前，没有任何东西能触达真实的人。这一点在上线后依然成立，不只是测试期间。

语音 Agent 朝一个特定方向失败：它们行动。坏了的仪表盘给你展示一个错误的号码。坏了的语音 Agent 给某人打电话。如果它错了，它会以规模化、在外面、对着你的客户的方式犯错，而你到发现时已经晚了。

问你的构建者：这个系统可以在没有人工批准的情况下发出什么，这个门控能永久开启吗？

在写 prompt 之前我实际检查什么

上面每一条都是一个设计决策，不是 bug。每一个决策都会被做出，不管是否有人刻意去做。

所以在我写一行 prompt 之前，我想知道：音频会话在交接时做什么，处置结果如何在事后验证，我们如何抽样系统丢弃的东西，栈中每个每分钟上限在哪里，以及什么可以在没有人类介入的情况下发出。

这些都不是 Vapi 特有的东西。这是演示出色的 Agent 和三个月后仍在运行的 Agent 之间的区别。

---

我是 Ussama Assad。我构建生产级语音 Agent，也修复它们——延迟、掉话、工具调用失败、转移时的传输错误、Agent 丢失对话状态。我无法保证预约率；那取决于你的报价、你的名单和你的市场。我能告诉你的是你的系统到底在做什么、为什么，当它出问题的时候我为构建负责。

如果你正在规划一个语音 Agent，想在构建之前对设计获得第二意见，这是一个值得进行的对话。

我是 Ussama Assad——我构建和调试生产级外联 AI：语音 Agent、冷邮件系统、线索生成管道。我在这里写的每一样东西都是我追踪到根因并修复的真实故障。https://ussama.dev