无人值守的人工升级路径

每个智能体架构图都有相同的三个框。一个是“理想路径” (happy path)，即模型给出回答，用户满意离开。一个是“自动兜底” (automatic fallback)，即置信度低的回答触发重试、调用不同工具或返回预设的“让我查一下”。还有第三个框，通常画在最后且最小，标记为“升级到人工” (escalate to human)。在设计评审时，每个人都会对这个框点头表示认同。它看起来像是某种终结——一个让整个系统变得合理的安全阀。“别担心，如果智能体处理不了，人会接手。”

然后你上线了，却发现那个框是个谎言。不是技术上的谎言——代码能跑，工单能创建，对话会被标记。而是一个人员配置 (staffing) 上的谎言。那个标有“升级到人工”的箭头指向一个无人负责的队列，没有服务等级协议 (SLA)，也不在任何人的轮值表上。智能体完全按照指令行事，它把问题抛给了一个从未同意接收问题的组织。

这是智能体部署中最为常见的悄然失败的方式之一，而且它几乎从未在演示 (Demo) 中出现过。演示练习的是理想路径。压力测试练习的是吞吐量。没有人会对“升级”分支进行压力测试，因为升级不是一个分支——它是对另一个团队的承诺。而你没有投入资源的承诺，是无法兑现的。

升级是产品表面，而非 If 语句

当工程师写下 if confidence < threshold: escalate() 时，他们认为升级只是一行代码。它通过了编译，完成了路由，指标仪表盘上显示着一个绿色的“升级率：3.2%”方块，一切感觉大功告成。但那个 escalate() 调用其实是一个完整运营表面的入口，它存在于你的代码库之外：一个队列、守着队列的人、他们用来获取背景信息的工具、他们的清醒时间，以及对响应速度的预期。

相比之下，自动兜底确实只是一个 if 语句。当智能体尝试不同的提示词 (Prompt) 重试，或降级到更廉价的模型时，所有操作都留在你控制的系统内部。你可以对其进行测试、测量延迟并进行回滚。而人工升级路径默认不具备这些属性。它有着你无法控制的延迟，你未预留的容量，以及一种失败模式——客户等待、放弃或流失——这些永远不会出现在你的链路追踪 (Traces) 中，因为它们发生在交付边界的另一侧。

通过团队描述发布准备工作的方式就能看出端倪。“我们有转人工的兜底”被视为等同于“我们有重试逻辑”。它们完全不是一回事。一个是你可以端到端掌控的代码路径，另一个是对一个甚至可能不知道自己被依赖的团队的依赖。

无人值守的升级失败的四种方式

升级路径不会以某种戏剧性的方式失败。它们会以特定的、可识别的模式腐烂，且每个模式都有不同的根源。

• 无人负责的队列。 升级操作会在共享收件箱或通用的“支持”分类中创建一个工单，但没有任何个人对此负责。升级规则经常指向一个团队别名、一个 Slack 频道或一个已停用的路由目标——工单静静地躺在无人察看的地方，而 SLA 的时钟却在不停滴答。这是一种伪装成人员配置失败的配置失败：箭头指向了一个真实存在的地址，而那个地址恰好是个黑洞。

• 从未设定的 SLA。 即使有人盯着队列，通常也没有达成一致的周转时间。智能体可以在 200 毫秒内完成升级；但人工可能在 4 小时或 4 天后回复，而没有人规定哪种情况是可以接受的。没有目标，“缓慢”就与“故障”无异，而且你无法因为漏掉一个根本不存在的指标而呼叫 (Page) 任何人。

• 冷转接 (Cold transfer)。 人工在没有任何背景信息的情况下接手升级——没有对话历史，没有智能体已尝试方案的总结，也没有预期结果的说明。客户不得不从头开始重新解释一切，而这恰恰是智能体本该避免的体验。从技术上讲，交接成功了，但交互依然失败了，因为背景信息在边界处丢失了。

• 升级循环。 人工客服由于不确定或过载，将工单退回给自动化系统，系统再次升级，工单在边界两端来回跳动，而处理 SLA 却在无声无息中超限。循环通常源于触发第一次升级的同一种不确定性——双方都没有足够的信心来处理解决，于是工单变成了一个带着倒计时的烫手山芋。

请注意，这其中只有一种——冷转接——是真正关于交接内容的。其他三种都关于组织：所有权、协议和问责。你无法通过写出更好的总结提示词来修复它们。它们是穿着工程外壳的人员配置和流程问题。

为什么拦截率指标掩盖了腐烂

这种失败模式之所以能长时间不被察觉，有一个结构性原因：每个人都在优化的指标正在主动掩饰它。“拦截率 (Deflection rate)”——即智能体在没有人工干预的情况下处理的对话比例——几乎是每一个智能体业务案例的核心数据。而一个无人值守的升级路径反而会提高你的拦截率，因为一个在无人负责的队列中放弃等待的客户，永远不会被计入人工处理的联系。他们的放弃被解读成了成功。

拦截率衡量的是 AI 做了什么，而不是客户达成了什么。真正重要的问题是，问题是否在没有后续联系或流失事件的情况下得到了解决。建立在破碎升级路径上的高拦截率是这个领域最危险的错觉之一：仪表盘之所以是绿色的，恰恰是因为升级在静静地失败。那些最需要人工帮助的客户，正是你的指标最无法察觉的人。

如果你想让升级路径变得可见，你必须对交付的另一侧进行监测，而不仅仅是这一侧。追踪“人工响应时间”、“升级解决率”以及“升级后的再次联系率”。这些数据存在于支持系统中，而不是你的智能体追踪系统中，这正是工程团队容易忽略它们的原因。

在上线前为路径配备人员

将升级机制视为产品的一个功能界面，意味着你需要像配置任何有容量限制的依赖项一样去配置它——在它进入关键路径之前，而不是在它出问题之后。

从业务量计算开始，因为这通常会被忽略。如果你的智能体每天处理 10,000 次对话，并有 5% 转为人工，那就是每天 500 个工单。负责处理这 500 个工单的团队是否有足够的人手？通常答案是没人做过乘法，而“人工兜底”被默认视为已经存在的免费资源。转人工的业务量必须对接收方是可持续的，这个数字是上线前必须确定的输入，而不是上线后的意外发现。

然后为该路径提供与其他操作界面相同的基本要素：

• 绑定到角色而非个人的明确负责人。 将升级路由到“值班支持工程师”，而不是 Priya，这样当 Priya 度假或离职时，所有权依然存在。基于角色的所有权是解决“无人认领队列”故障最可靠的方法。

• 带有报警计时的明确响应 SLA。 确定可接受的人工响应时间，然后进行监测，以便在即将超时时提高优先级并提醒负责人。严重程度设定时限，时间强制执行。没有计时器，SLA 只是一个愿望。

• 结构化的上下文负载。 交接应携带对话历史、智能体尝试过的操作总结、客户身份和等级以及预期的结果。这是唯一的工程侧修复，它能将“冷转接”变成“暖转接”。

• 基于技能的路由，而不是大杂烩。 将所有升级丢进一个队列会保证漫长的等待和困惑的响应者。按问题类型和客户等级进行路由，使工单落到真正能解决它的人手中，这也能降低循环率（loop rate）。

• 经过测试的触发集，避免过度升级。 升级应该基于真实的信号触发——置信度不足、不可逆或高风险操作、检测到挫败感、接近 SLA——而不是每一个轻微的不确定性。一个过于频繁转人工的智能体会淹没人力队列，让你的人员配置计算失效。

现代智能体框架让技术性中断变得简单：你可以在工具调用处暂停运行，持久化保存其状态，等待人工决策，然后从中断处精确恢复。这种机制是现成的且值得使用。但它解决的是暂停的技术问题，而不是另一端是谁的社会学问题。框架会很乐意中断你的智能体并永远等待。是否有人出现是你的问题，而不是框架的问题。

在设计评审中要问的问题

下次你在设计评审中，有人指向“转接人工”框时，问一个问题：谁负责值守那个框，他们的响应 SLA 是多少，他们是否同意处理这个业务量？ 如果全场鸦雀无声，说明你没有设计好升级路径。你只是设计了一个让问题消失的地方。

自动兜底属于工程范畴。升级路径是与其他团队签署的运营协议，它在上线前——而不是在第一个客户等了三天，却发现根本没分配人手之后——需要一个负责人、一个数字和一个签名。智能体擅长察觉自己力不能及。如果它们伸出的手没人接住，这种直觉就毫无价值。