语音Agent需要三条退出路径而非一条

大多数语音 Agent 演示都在优化happy path。来电者要求预约，Agent 完成预约，全场鼓掌。我把这些系统落地到了医院、兽医诊所、汽车修理厂和房产经纪公司，而happy path 恰恰不是决定生死的地方。真正导致失败的，是那些从脚本边缘滑落的电话。

一个能处理 90% 来电但遗漏另外 10% 的 Agent，并不是 90% 的成功。那 10% 被遗漏的，才是真正重要的电话：紧急情况、愤怒的客户、即将成交的单子。业务方会用整体系统来评判它，这样做是对的。

作为软件工程师，你早已知道这种模式。它就是错误处理。我们都知道错误路径才是真正的产品表面，但所有人还是把它留到最后才写。语音 Agent 的惩罚来得更快，因为失败是实时发生的，而且有人正在电话那头听着。

"转接人工" 被当作一个单一功能，一个配置里的布尔值。但在生产环境中，它是三条不同的代码路径，混为一谈正是让 Agent 感觉像坏掉的原因。

出口一：转接实时通话

来电者保持在线，某个人接起电话。就在情况紧急的时候，就在来电者已经经历了一轮误解之后，或者就在让这个人回电就会造成真金白银损失的时候。这也是最容易失败的出口，因为它依赖一个特定的人此刻正好有空。

出口二：采集结构化信息并升级

Agent 正确采集了详细信息，干净利落地结束了通话，并向团队实际在监控的地方发送警报。这个出口远比客户预期的更常用，特别是在非工作时间，但它是最容易被跳过的一个。

出口三：拒绝并引导

Agent 完全拒绝处理该话题，坦白说明，并指向正确的渠道。对于医疗机构，那是临床建议。对于房产经纪，那是任何涉及价格谈判或公平住房的内容。Agent 这里不需要一个优雅的答案。它需要一个坚定的答案。

一旦有了三个出口，你就不再试图构建一个永远知道答案的 Agent——那是一个注定失败的游戏——而是开始构建一个永远知道电话该转去哪里的 Agent。小得多的问题，而且真的可以解决。

我在写脚本之前先写出口条件

我向客户问的第一个问题从来不是 Agent 应该说什么。而是：哪些电话，如果这东西处理得很差，会让你明天就关掉它？答案简短而具体，它们就是升级规范：

兽医诊所说，任何描述动物倒地、流血或中毒的来电者。不做分诊，不问问题，直接转人工。

汽车修理厂说，任何在路边抛锚的人。无论他们打电话来是为了什么都已经不重要了，因为一个站在高速公路旁边的人是完全不同类型的来电者。

医疗诊所说，任何看起来像症状或建议的内容。不管置信度如何，都不是 Agent 的活儿。

房产经纪说，任何提到竞争对手报价的来电者。快速转人工是这通电话的全部价值所在。

这些作为一等公民的出口被放进流程里，在我写预约路径之前，不写一行代码。和在写函数体之前先写异常抛出点是一样的思路。它也改变了客户告诉你的内容。"处理我们的来电" 不是规范。"不要让一个路边抛锚的司机经历完整的预约脚本" 是，而且可以测试。

真正能捕获升级的触发器组合

升级触发来自四个来源。只实现一个的 Agent 会漏接电话。

内容触发器。来电者说了列表上的词。紧急词汇、法律词汇、取消词汇、竞品名称。容易定义，所以大多数实现停在了这里。

显式请求。来电者要求转人工。无可协商，我在流程的每个节点都接上这条线。一个在对方要求转人工后还一直把人往脚本里引的 Agent，是让来电者最快对一个商家产生厌恶的方法。如果他们要求两次，转接早就应该发生了。

修复循环触发器。Agent 两次没能理解同一件事，或者来电者重复了自己说的话，或者通话时间已经远超这类电话应有的长度。没有任何关键词命中。对话就是进行得很糟糕，Agent 应该仅从结构上就能检测到。这是所有人都忘记的那个触发器，但它捕获的来电最多。

情感触发器。来电者明显表现出沮丧。有用，值得保留，但要保守。假阳性意味着人工接到了一通严格来说不需要转接的电话，但比起另一个选项，这很便宜。

交接必须携带的内容

一个把困惑的人类丢进没有任何上下文的人工通话的转接，比直接丢线好不了多少。接电话的人一开始就要求来电者重复一切，这恰恰是商家花钱要避免的情况。

所以每次交接都携带一个载荷：来电者是谁及其回拨号码、用 Agent 自己的话描述他们为什么打电话、已经确认了什么信息、以及触发升级的原因。如果接收团队使用 CRM，那就在电话响之前把这条记录作为备注挂在联系人上。Agent 保持轻量，它背后的系统保持智能。

回拨号码最重要。尽早获取，确认它，并把获取这个字段当作 Agent 真正有耐心去做的事。如果转接失败，那个号码是商家和丢失线索之间唯一的东西。

这也是热转接与冷转接的决策点。冷转接适用于高容量路由场景，目标方已经知道来电的用途，比如有人只是想联系配件柜台。如果让来电者重复他们的故事会损害关系，那就先简要通知接收方，再热转接。

没人接电话，这是正常情况

这是被放在最后构建、却最先坏掉的部分。转接是一个请求，不是保证。它是对一个人类发起网络请求，可能会超时。线路忙，现在是晚上七点，有人在休假。如果计划是"转接人工"而没人应答，来电者要么收到沉默，要么听到语音信箱的提示音，系统在最应该保护的这通电话上失败了。

我构建的是一个带有终止条件的阶梯：

尝试主要目的地，用短响铃窗口，不是长的。一个听着嘟嘟响的来电者在消耗他们进门时带的耐心。

如果有备选目标就尝试。值班电话、第二个地点、非工作时间的老板手机。

如果没人接，Agent 重新上线，诚实告知。不是再说一次"请稍等"，而是更像一个人会说的：大家都在接待客户，这里是有人会回电的时间。

采集回拨详情，确认时间范围，干净地结束通话。

向团队实际在监控的地方发送升级通知。Agent 负责对话，n8n 负责提醒、短信、工单和跟进。

第三步是客户push back最多的，也是救他们最多的。一个承认没有人可用并承诺回电的 Agent 保住了线索。一个一直尝试转接的 Agent 丢失了它。

响铃时间和查询时间都是来电者在等待中消耗的，所以你的延迟预算也适用于交接。张嘴要在沉默之前，不是在之后。

为什么我把它当作安全问题来处理

我对升级的大部分思考不是来自语音 AI。来自多年构建那些自信的错误答案是最糟糕输出的系统。在临床眼动追踪工作中，头戴设备可以为每个 session 产生一个数字，但诚实的系统是能够说捕捉效果不够好并将判断交回给临床医生的那个。在公共安全 XR 中，显示着过期数据却信心满满的叠加层，比承认失去追踪的那个更危险。

语音 Agent 是同类系统。它有时会出错，问题是永远不是如何完全防止它。而是系统在自身能力边缘做什么。一个构建良好的交接是表明 Agent 是由真正运行过它的人构建的最强信号。

构建三个出口：实时转接、采集消息并升级、拒绝并引导。

先写出口条件，从"哪些电话会让你关掉它"开始。

在内容上触发，在任何节点的显式请求上触发，在修复循环上触发，保守地在情感上触发。

携带上下文进行交接，尽早获取回拨号码。

为没人接听做计划，用诚实的承诺结束那条路径，而不是等待。

更详细的版本，以及更多逐客户的升级规范，在我网站上。