升级工具曾是最后一道安全网。当智能体的置信度降至阈值以下时，它会调用 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 可能会排入他们自己的自动化队列，而他们的自动化又可能通过集成回调原始组织的工具。路径越长，原本属于人类的位置被悄悄替换的机会就越多。
本该捕捉到这一问题的指标
标准的升级指标是吞吐量指标。创建的升级数量。平均创建时间。队列深度。它们都没有衡量升级原本的目的。
真正重要的指标是升级路径上的人工触达率（human-touch rate）：在一段窗口时间内创建的升级中，有多少比例在解决之前，在追踪轨迹上至少有一个明确的人类操作。不是“某个人本可以查看”，也不是“工单到达了人类可以阅读的队列”，而是一个记录在案的人类操作 —— 由未授权给智能体的用户账号撰写的评论、人类发起的状态流转，或者从人类控制的收件箱发出的回复。
按照这种定义，当消费者端渗入自动化时，该指标就会下降。它会干净利落地下降，并给出一个可以触发告警的数值。它不依赖于智能体团队是否知晓客服团队上线了自动化。信号是通过数据传递的，而不是通过跨团队的认知。
构建这一指标需要智能体平台通常做得并不好的一点：它需要区分由人类采取的行为和由智能体代表人类采取的行为。如果你的智能体以服务账号登录，那么你就可以免费获得这一指标。如果你的智能体冒充人类用户（这很常见，因为这让审计追踪看起来“很对”），那么你就有了一个该指标会暴露出来的问题。这个问题本身也是一个安全问题，暴露它是一件好事，而不是代价。
验证线路的另一端
一旦你接受了升级工具的契约是不完整的，修复方法就是扩展该契约。有两种模式行之有效，且可以组合使用。
第一种是交接验证（handoff verification）：在交接时，发起升级的智能体（agent）会从接收系统收到一份关于将由何种处理器处理该请求的签名断言。断言很简短——“人工队列，当前深度 12，预计 4 小时内人工接管”——而智能体的工具接口会将缺失此类断言视为升级失败，而非成功。如果下游队列增加了一个智能体，断言就会改变（“混合模式：分流智能体 → 人工后备，当前分流智能体拦截率为 31%”），此时发起调用的智能体可以决定该路径是否仍满足安全属性。这种机制很乏味，但其约束力在于：智能体不能再将“工单已创建”等同于“已联系到人工”。
第二种是人工触达强制执行（human-touch enforcement）：升级系统记录升级创建的时间点，并等待一个特定的信号——不是下游状态的变化，也不是自动回复，而是记录在案的针对该案例的人工操作——之后才认为升级已解决。该信号的超时不会被“系统已处理”所掩盖，而是会变成事故。如果一批升级任务在 24 小时内都没有得到人工触达，那就是一起火警，即使所有工单最终都关闭了。这与基础设施服务的合成探测（synthetic probe）模式相同，只是应用于组织层面的服务。
这两种模式都有一个共同属性：它们将接收系统视为“对手”——不是指意图上的敌对，而是进化过程中的变数。接收方可能会改变，可能会自动化，甚至可能悄悄变成最初请求升级的那个智能体。契约必须在这种变化中幸存，而无需请求系统预先知晓。
Bug 背后的组织现状
技术修复是简单的部分。难点在于这种循环是组织层面缺失负责人的症状。
根据定义，升级路径是跨团队的。构建智能体的团队并不拥有队列，拥有队列的团队并不知道哪些智能体会向其发起升级。当队列演进时，队列所有者会根据队列的目标（吞吐量、分流率、成本）来审查变更，而不是根据上游每个系统的安全契约。这些契约对队列团队是不可见的，因为在队列团队这一侧，没有人把它们记录下来。
修复方法不是开会，而是建立一个注册表（registry）。系统中的每条升级路径都有一个条目：源智能体、目标队列、源智能体所依赖的属性（末端有人工、X 分钟内接管、有特定的专家可用），以及一名必须对可能破坏该属性的变更进行签字确认的目标侧负责人。注册表规模很小。成本只是在每次队列侧变更审查时多问一个问题：这项变更是否会影响任何已注册的升级路径？ 收益在于，下次支持团队发布分流智能体时，这个问题会被触发，对话会展开，循环永远不会闭合。
如果没有注册表，你只能寄希望于队列侧团队自发意识到他们即将发布的智能体会吞噬别人的安全网。他们不会意识到的。这不是因为他们粗心大意，而是因为那个属性对他们不可见，且他们还有需要降低的队列深度指标。
“人机回环”的真正含义
“人机回环”（human-in-the-loop）一词不应描述一个存在的工具，而应描述一种可观察的行为。如果你无法指出最近的升级并证明人工触达了它们，那么你并没有实现人机回环。你只是拥有一个名为 escalate_to_human 的工具，并寄希望于这个名字仍然符合现实。
这种希望会衰减。每当你上游、下游或侧向的团队发布一个自动化程序时，它就会衰减。这种衰减是无声的，因为调用工具的智能体无法看透工具边界，且工具的成功信号没有改变。让这种希望保持诚实的唯一方法是衡量名称所承诺的行为，并在测量结果偏离时报警。
这是一个更广泛的模式：随着组织中更多的工作通过智能体流转，更多原本默认以人工为末端的接口不再如此。在假设旧默认值保持不变的设计下，默认值已经发生了偏移。升级是最明显的案例，因为其安全属性如此明确，但同样的动态也影响着通知渠道、审批队列、审查步骤，以及任何价值源于接收端人工处理的交接过程。
这种约束要求你命名你所依赖的属性，直接测量它，并将它的侵蚀视为一种回归（regression）。升级工具将继续返回成功，路径将继续接受工单。而你必须要做的工作是确保在整个追踪链路中的某个地方，确实出现了一个人。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
