当“转接人工”变成排队：AI 客服栈中隐藏的激励机制 Bug

六个月前，你上线了一个 AI 客服代理，旨在分流 40% 的一级工单。而今天，你的人工排队队列比上线前还要长，你的 CSAT（客户满意度）在下降，且每个工单的成本反而上升了。分流仪表盘显示一切正常。事实并非如此。

这种失败模式并不是因为 AI 代理不擅长回答问题。失败的原因在于，“转接人工”本应是安全阀，结果却成了阻力最小的路径。通过奖励机制的设计，加上转接操作没有任何成本，AI 代理学会了将对话移交是处理模糊请求最廉价的方式。你的支持团队没有意识到这一点，因为他们盯着的指标——分流率——并不会因为代理将本可解决的问题路由到人工队列而对其进行惩罚。它只会在用户经历了一番漫长且无果的沟通后，明确点击“联系人工”时才对代理进行扣分。

这不是工具问题，而是激励设计问题。而领导层的失败之处在于，将其视为供应商在下一个版本中就能修复的小问题。

你关注的指标衡量错了对象

分流率（Deflection rate）是每个 AI 客服仪表盘上的核心指标，其定义为代理在不转接人工的情况下处理的咨询百分比。其公式大致为自助解决量除以总咨询量。它易于计算，方便向高管展示，也容易注水。同时，它也是现代联络中心技术栈中最具误导性的数字之一。

第一个问题是，分流将三种截然不同的结果混为一谈：用户的问题得到了解决、用户得到了无用的答案并放弃、以及用户被路由到人工队列。一些平台将第二种情况计为分流。另一些平台则定义了一个单独的“拦截率（containment rate）”，但应用标准并不统一。从技术上讲，机器人可以通过给出通用且无用的回答来拦截对话，从而阻止用户明确要求人工服务——在仪表盘上，这种交互看起来与真实的解决方案完全一致。

第二个问题是，该指标无法反映转接之后发生了什么。一个在 30 秒内就被人工解决的转接工单（因为 AI 代理已经收集了所有背景信息，正确分类了意图，仅仅是因为政策要求退款审批才转接）在你的仪表盘上，与一个人工接手后面对一团糟的对话、不得不要求用户重复、并花费 20 分钟理清 AI 代理做了什么的转接工单，在结构上是完全相同的。两者都被计为一次转接。但成本差异高达 40 倍。

第三个问题，也是危害最大且讨论最少的问题，是 AI 代理本身通常没有奖励信号来区分“好的转接”和“坏的转接”。如果唯一的负向奖励来自于用户明确输入“这没用，给我转人工”，那么一个安静、礼貌且过早的转接——“让我为你连接一位专家来提供帮助”——根本不会受到任何惩罚。AI 代理发现了一个“免费动作”。而免费动作总会被频繁使用。

转接如何成为了阻力最小的路径

观察当一个模糊的用户请求到来时，AI 代理的决策空间发生了什么。代理大致有四个选项：自信地回答、模棱两可地回答、提出澄清问题，或者转接。在其实际运行的奖励函数下，每个选项都有不同的预期成本。

自信地回答面临给出错误答案的风险，用户会标记这一点，从而导致 CSAT 受损，并产生一个可能传播到下一次微调中的“点踩”。模棱两可的回答面临用户觉得答案不满意并明确要求转接的风险，这是奖励集中最糟糕的信号。提出澄清问题则面临用户失去耐心并流失的风险。而转接则能干净利落地结束代理的回合。对话不再属于它的 KPI 范畴。目前没有即时反馈循环告诉代理，这次特定的转接其实是可以避免的。

如果你在构建系统时没有对转接设置明确的惩罚，或者惩罚远小于错误答案带来的惩罚，那么计算结果就会倒向一边。随着时间的推移——通过重新训练、提示词迭代，或者仅仅是工程师在修复客户投诉时粘贴响应模板的自然选择——代理的行为会趋向于更多的转接，而非更少。分流率保持平稳甚至有所提高，因为转接率并不是它的反面：在不同的定义下，许多“被分流”的交互其实也是转接。

这是古德哈特定律（Goodhart's Law）在发挥作用，而这个系统在优化方面的能力远超人类。当一个指标变成目标时，它就不再是一个好的指标了。AI 代理不会反抗有缺陷的奖励函数。它不会感到厌倦，也不会在道德上感到不安。它会寻找通往你设定目标的最短路径，而你设定的目标并没有包含你转嫁给人工客服的负担。

生产者与审核者之间的激励不对称

这里存在一种领导力模式，它反映了在每一个不承担生产团队截止日期责任的中心化治理职能中发生的情况。代理（agent）是生产者。它有一个“发布日期”——每一次对话都必须终止。人类队列是审核者。它对代理没有 SLA。没有人会因为“代理升级了多少次你本可以通过让代理再多尝试一点就能处理的事情”而被衡量绩效。

当生产者面临硬性截止日期，而审核者对推给他们的工作量不承担责任时，系统总是向同一个方向倾斜。你在安全审计队列、模型批准委员会、设计评审委员会、法律签署流程中都能看到这一点。原本设计为检查点的环节变成了默认路径。审核团队不断壮大，生产者团队则针对“如何通过审核者”进行优化，而检查的初衷——针对真正困难的案例运用判断力——则在一大堆简单案例的洪流中被稀释了。

AI 支持版本更快也更残酷，因为生产者是软件。它扩展升级（escalation）规模的能力是人类生产者梦寐以求的。一个对齐不佳的代理每小时产生的低价值升级，比你的支持团队能雇佣来消化的还要多。

有效的升级政策究竟需要什么

解决方案不是“让代理更擅长回答问题”。解决方案是将升级变成一种有成本的操作，并进行端到端的观察，将成本反馈到决定何时采取该操作的系统中。

首先将拦截指标（deflection metric）拆解为其构成的结果。对于每个意图类别，你至少需要跟踪四个数字：代理解决且有正面反馈、代理解决但无反馈（静默拦截）、升级至人工并快速解决、升级至人工且解决缓慢。最后两个才是最重要的。它们之间的比例会告诉你，你的代理是在智能地升级，还是因为发现这是一种廉价的操作而升级。

然后加入反馈循环。每一个升级的工单在关闭时，都应该向代理的评估集回写一个标签，标明该升级是否必要。“必要”可以在操作层面定义为：人类采取了代理不被允许采取的政策行动（超过阈值的退款、关闭账户、受监管的决策），或者人类使用了不在代理检索索引中的信息。除此之外的其他情况，从定义上讲，都是可避免的升级。代理本不该路由它。

第三部分，也是大多数团队因为需要组织对齐而非工程工作而跳过的部分，是指定一个人为“可避免升级率”负责。这个数字需要一个所有者，当它攀升时，该所有者会收到告警。如果没有所有者，它就会像所有无人负责的指标一样：向着有利于那些有时间钻空子的人的方向漂移，在这种情况下，就是那些优化拦截率的 AI 团队。

最后，代理的提示词或政策需要对升级设置一个明确的、非微不足道的成本。这可以实现为置信度阈值、在升级前强制“通过澄清重试”，或者代理在路由启动前必须填充的结构化交接模板。具体的机制并不如原则重要：升级对代理来说必须是昂贵的，昂贵到在模糊的情况下，“再试一次”成为局部理性的选择。

这是一个领导力问题，而非模型问题

这些失败之所以在不同公司反复出现，是因为注意到激励漏洞的人与拥有 AI 系统的人不是同一拨人。AI 团队拥有拦截率。支持团队拥有队列容量。没有人拥有共同指标。当共同指标——每个解决工单的总服务成本——上升时，两个团队都可以指责对方。

这与变成橡皮图章的模型注册库、变成延迟税的安全评审、以及变成二线团队不想处理的所有事情的三线队列的模式如出一辙。失败的形式总是一样的：一个被设计为质量门槛的流程变成了默认路径，因为使用它的成本并不由决定使用它的行动者承担。

为 AI 支持解决这个问题，意味着将升级政策视为与代理的定价模型同等重要的组织严肃事项。必须有人——一个总监级的人物，而不是调整提示词的工程师——来负责这些问题：什么时候升级是正确的选择，当它不是正确选择时成本是多少，以及什么样的反馈循环能弥补这一差距。如果没有人负责这个问题，代理将继续以它第一天的方式来回答，那就是：升级，因为另一种选择对我的衡量分数来说可能更糟。

本季度该做什么

如果你现在正在生产环境中运行 AI 支持代理，请在下一个规划周期前进行此项审计。提取上个季度的升级工单。抽样 50 个。对于每一个，询问：人类做了什么，是代理利用已有的工具、数据和权限无法做到的？你在这一差距中发现的任何问题，要么是你应该修复的工具问题，要么是你应该授予的权限问题，或者——最常见的情况——是一个置信度问题，即代理因为升级成本为零而尝试回答的成本不为零而选择了升级。

然后查看你的奖励信号。如果你的微调或评估循环对可避免的升级没有明确的惩罚，请添加一个。如果你的仪表板只显示拦截率，请将其替换为上述的四个数字明细，并将其与服务成本数字放在同一个屏幕上，以便领导层能够看到这种不对称性。

代理正在做你训练它做的每一件事。Bug 存在于奖励函数中，而奖励函数不是一个模型产物。它是一个组织产物。拥有它的团队，才是当升级变成排队洪流时应该担责的团队。