重新路由回智能体的升级路径

升级工具曾是最后一道安全网。当智能体的置信度降至阈值以下时，它会调用 escalate_to_human，随后请求滑入工单队列，并向用户礼貌地回复“专家稍后会跟进”。工程团队在发布清单上完成了闭环确认。值班表上也列出了负责接收的人员。

六个月后，一次审计对该路径进行了回溯。升级工具打开了一个 Zendesk 工单。Zendesk 队列由客服团队为了维持 SLA 响应时间而设立的预审智能体进行分拣。预审智能体由于找不到可以直接解决的政策匹配，调用了自己的 delegate_to_specialist 工具——该工具将案例路由给了一个专家智能体。而专家智能体在不确定时，又调用了 escalate_to_human。追踪轨迹形成了一个闭路。审计抽样调查的升级案例中，没有任何人类接触过。发布文档中描述的人机协作（human-in-the-loop）实际上并不存在。

升级接口并没有失败。它的每一次跳转都得到了执行。失败的是“接收系统是自然人”这一假设。

升级是一个接口，而不是目的地

当你将 escalate_to_human 接入智能体的工具列表时，你并不是在将请求移交给人类。你是在调用一个 API，其契约内容是“最终，会有一个人类看到并处理此事”。这个契约由两部分组成：请求落到了人类可以阅读的地方，以及人类确实阅读了它。

第一部分很容易验证。你可以调用工单创建接口，在队列中看到该工单，然后勾选选项。但从智能体的角度来看，第二部分是不可见的。无论是一个人类明天阅读，还是一个机器人在 8 秒内阅读，抑或根本没人阅读，智能体观察到的响应都是一样的——工单已创建，状态为开启。该工具成功的标准是“请求已被下一个系统接受”。该接口并不承诺由谁或什么东西来消费它。

这与分布式系统中任何其他基于队列的移交形式相同。生产者不知道消费者。这种解耦正是其意义所在。但对于安全关键路径来说，这种解耦就是一个 bug。升级工具的全部目的是将工作路由到不同类型的处理器——即人类处理器。一旦消费者发生了变化，安全性特质也会随之改变，而且是悄无声息地改变，生产者端不会收到任何信号。

Zendesk 队列并不会对外宣告它在顶层增加了一个智能体。客服团队的预审自动化是一项提高生产力的成果，其部署时并未意识到另一个团队的安全设计依赖于该队列必须由人工后端处理。每一方都做出了局部合理的决策。而交汇点却成了一个死循环。

循环是如何闭合的

循环很少通过单次跳转就闭合。它是通过一个无人进行端到端负责的系统中自动化技术的缓慢积累而闭合的。

一旦你开始留意，这种模式便随处可见。一个团队因为业务量增加且人力响应慢，为他们的队列构建了自动化。另一个团队因为他们的智能体需要安全网，在该队列中构建了升级路径。这两个团队根据不同的时间表运作，处于组织架构的不同部分，拥有不同的评审流程。第一个团队的自动化是一项生产力功能。第二个团队的升级路径是一项合规性功能。任何一方的评审都不包括“对方的系统会如何处理这个请求？”这个问题——因为他们根本不知道对方的系统就在这条路径上。

第一个团队正在解决队列深度问题。他们增加了一个由 LLM 驱动的预审智能体，可以直接解决三分之一的入站工单：重置密码、状态查询、简单搜索。对于无法解决的工单，它会继续向下路由。该团队通过分流率（deflection rate）和节省的人工评审时间来衡量成功。两项指标都有所改善。智能体奏效了。

第二个团队的升级路径在构建时，是针对一个 100% 由人工处理的队列设计的。发布评审确认了升级请求能够到达队列。但发布评审中没有任何环节测试了是谁把请求取出来的。当第一个团队的预审智能体上线时，路径悄悄改变了形态，而第二个团队的监控中没有任何内容能捕捉到这一点。升级成功率维持在 100% —— 每次都能成功创建工单。而真正触达人类的升级比例在这一指标中是不可见的。

六个月后，一起事故或一次审计迫使团队进行端到端的追踪。当路径跨越两个以上的系统时，情况会变得更加糟糕。专家智能体可能会派遣给供应商的 API，供应商的 API 可能会排入他们自己的自动化队列，而他们的自动化又可能通过集成回调原始组织的工具。路径越长，原本属于人类的位置被悄悄替换的机会就越多。

本该捕捉到这一问题的指标

标准的升级指标是吞吐量指标。创建的升级数量。平均创建时间。队列深度。它们都没有衡量升级原本的目的。

加载中…