人机回环 (HITL) 是一个队列，而队列具有动态特性

团队向 AI 工作流添加人工审批的方式，与他们在代码库中添加 if (isDangerous) requireHumanApproval() 的方式如出一辙：将其视为一个二进制开关，在设计时检查一次，然后便将其遗忘。架构图上的指标是“人工监督”旁边的一个绿色对勾。而真正重要的指标——人工花费了多长时间、他们是否阅读了任何内容、在点击批准时该条目是否仍然相关——却很少有对应的仪表板。

将人工审批者视为二进制开关，你就等于在不知不觉中构建了一个队列。而队列具有动态特性：积压量的增长速度超过了你的员工配置速度、陈旧性使昨天的决定变得毫无意义、疲劳让审查变成了“走过场”（rubber-stamping），以及优先级倒置让真正重要的那一个决策被排在三百个无关紧要的决策之后。架构图中看不到这些，但它们都会出现在事故回顾（incident retro）中。

一个有用的重构视角是：HITL（人机回环）不是一种安全检查，它是一项服务。它具有到达率（arrival rate）、服务率（service rate）、延迟分布，以及当到达量超过服务能力时的失败模式。适用于支付处理器或后台作业队列的一切原则同样适用于此，但有一个不同之处——执行工作的是人，他们的吞吐量退化方式与 CPU 不同。

利特尔法则（Little's Law）同样适用于审批者

利特尔法则指出，一个稳定队列中的平均项目数等于平均到达率乘以每个项目在队列中停留的平均时间。应用于审批工作流：待审批积压量等于 AI 代理（agent）生成需要审批的动作的速率，乘以从提交到决策的平均间隔时间。

这并不是一个比喻，而是算术。如果一个代理系统每天生成 1,200 个符合审批条件的动作，且平均决策时间为 4 小时，那么在任何给定时刻，稳态下的积压量就是 200 个进行中的项目。将到达率提高 3 倍——这是任何成功的代理部署的必然轨迹——要么积压量爆炸，要么决策时间崩塌。没有第三种选择。

团队遇到这种情况时，往往认为答案是“增加更多审核人员”。有时确实如此，但更多时候，到达率已经超出了任何合理审核人数所能吸收的范围，此时的修复方案在于到达端：加强上游验证器、制定更严格的“哪些内容需要人工查看”的政策、设置置信度门槛让 90% 明显安全的内容完全绕过队列。直觉反应是扩招人员；而成本更低的修复方案几乎总是减少到达量。

团队缺乏的监控仪表盘不是“人工是否批准了”，而是队列的生命体征：到达率、服务率、当前积压深度、排队时间分布（而不仅仅是平均值）。一旦到达率在一段持续的时间窗内超过了服务率，队列就不再稳定，每一个下游指标都是故障已经在发生的滞后指标。

“橡皮图章”式的相变

当一个人每小时审查 10 个项目时，他们确实可以阅读它们。当他们审查 200 个时，他们做不到。这两种模式之间的过渡并不是渐进的——它更像是一种“相变（phase change）”，因为在量级曲线的某个点上，审核者会停止对每个项目进行认知评估，转而开始对表面特征进行模式匹配。

其可衡量的特征非常明显：每个项目的平均审查时间大幅下降，而批准率却保持不变或上升。在一个校准良好的系统中，批准率应该与队列构成相关——如果策略管道运行正常，疑难案件应该产生更多的拒绝和更多的升级。当批准率与队列构成脱钩并趋近 100% 时，人类就不再是在进行筛选，而是在提供“背书”（credentialing）。

自动化偏见（Automation bias）让情况变得更糟。关于 AI 辅助决策的实证研究发现，人类同意错误的 AI 建议的基准率约为 7%，而且这个基准率在时间压力下表现得异常稳健——处于截止日期压力下的审核者并不会思考得更深入，他们只会直接点击批准。再加上审查 AI 输出在认知上与从零开始做决策完全不同：锚点已经设定，框架已经画好，“批准”是阻力最小的路径。

团队通常发现得太晚，因为糟糕的指标看起来很漂亮。吞吐量上升了，SLA 合规率上升了。ML 团队将高批准率作为其模型表现良好的证据。没有人注意到，人类在六周前就已经不再作为“人”在工作，而审批步骤已变得具有仪式感。

陈旧性：沉默的失败模式

在代理需要审批的两小时后才返回的批准，通常比完全没有批准更糟糕。世界已经向前迈进。代理正在响应的工单已被重新分配。发送退款请求的客户已经发起了拒付。代理即将更新的数据已被另一个进程更新。人工点击批准时，所针对的只是一个已经不复存在的意图快照。

这是队列理论没有直接命名但每个真实系统都会表现出的失败模式：服务率很重要，但被服务项目的时间相关性曲线也同样重要。在许多 HITL 工作流中，决策的价值随延迟而急剧下降。超过某个阈值后——对于交互式代理动作通常是 10 分钟，对于批处理工作流通常是 1 小时——决策的信息内容已经变得陈旧，以至于盲目批准几乎等同于盲目拒绝。两者都是噪音。

值得关注的信号是“人工同意”与“人工及时同意以产生影响”之间的差距。这是两个不同的问题，将它们混为一谈会让审批队列变成风险放大器。更糟糕的是：陈旧性与队列深度相关，而队列深度又与“走过场”阶段相关。积压任务中最深的部分，恰恰是审核人员最疲劳、决策最无关紧要、项目最有可能在未读情况下被批准的地方。

一个有用的架构改进是为每个项目设置一个新鲜度截止期限（freshness deadline），并在项目过期时以不同方式处理决策。一些团队会自动拒绝陈旧项目，其理论是陈旧的拒绝比陈旧的批准更安全。另一些团队则将它们完全从人工队列中移除，并将其路由回代理，附带一个“错过审批窗口”的策略信号，让代理决定是重试还是放弃。这两者都优于默默地清理一堆已经过期的决策积压。

审批队列中的优先级反转

朴素的审批队列是先进先出（FIFO）的。这在几乎所有情况下都是错误的，原因源自分布式系统中的一个特定概念：FIFO 队列会产生优先级反转。你的高风险项——超过政策阈值的付款、来自 VIP 账户的面向客户的操作、不可撤销的数据删除——可能排在三百个琐碎的审批之后，仅仅因为它们恰好到达得更晚。

加载中…