人机回环 (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 账户的面向客户的操作、不可撤销的数据删除——可能排在三百个琐碎的审批之后，仅仅因为它们恰好到达得更晚。

在实时操作系统文献中，优先级反转有一个专门的解决方案：优先级继承。在这种机制中，阻塞低优先级任务的进程会被临时提升优先级，以便其尽快完成并释放资源。HITL（人力介入）中的对应策略虽然更粗犷，但精神是一致的。你需要一种队列调度策略，能够窥探项目内容，并将高风险项推到前端，无论其到达顺序如何。

这意味着审批队列不能只是一个简单的列表。它需要是一个加权优先级队列，其评分至少应涵盖以下维度：

• 爆炸半径 —— 该操作的可逆性如何？如果不可逆，出错的代价是什么？
• 受影响数据或账户的敏感性 —— VIP 标记、合规类别、受监管领域。
• 时效性截止日期 —— 在价值衰减之前，该项任务需要多快做出决定？
• 置信度 —— 不是作为绕过审批的条件，而是作为一种信号，标示哪些项目值得审核员投入稀缺的注意力。

如果没有优先级评分，FIFO 的公平性就是一个陷阱：每个项目都被平等对待，这意味着最需要严格审查的项目，最终只得到了与那些本可以随意处理的项目相同的、仅三秒钟的快速浏览。审核员的注意力是一种有限资源。将其均匀地分配到整个队列中，等同于糟糕的资源配置。

分级升级与基于置信度的旁路机制

能够在规模化 HITL 中幸存下来的团队都有一个共同的结构模式：多个队列，而非一个。默认做法是让所有内容都进入单一的审批队列。而扩展模式则是增加一个路由层，根据项目的特征来决定进入哪个队列，或者是否根本不需要人力介入。

一个可行的分级结构如下：

• Tier 0（自动审批）：高置信度、低爆炸半径的操作完全绕过人工审核。此处的置信度阈值通常在 90% 以上，并根据历史审核员的一致性进行校准。该政策的效果取决于其在预留审计样本上测得的错误审批率。
• Tier 1（标准审核）：中等置信度或中等风险的操作，处理量大。针对吞吐量进行优化：采用批量处理界面、模板化的决策路径、键盘快捷键、短时效窗口。这是主要的流量层，工具链的重要性超过了审核员的资历。
• Tier 2（提级审核）：低置信度、高爆炸半径或触发特定政策的项目。具有更严格的 SLA、更资深的审核员，且必须记录决策理由。这一层级规模较小，且应保持精简。
• Tier 3（主管升级）：涉及合规、法律或新类别的项目，Tier 2 审核员无权处理。设计上是缓慢且罕见的。

关键举措是在 Tier 0 引入基于置信度的旁路（bypass）。你路由到 Tier 0 的每一个项目，都是在节省 Tier 1 的审核能力。如果在给定的爆炸半径下，Tier 0 的预留错误率是可以接受的（这是一个政策决策，而非技术决策），你就成功改变了到达率曲线。这是唯一可持续的扩展杠杆；除此之外的所有手段都只是在堆人力。

审核员轮换与审计样本

有两种运营实践能区分出哪些 HITL 系统是能够生存的，哪些会默默演变成“走过场”的橡皮图章。

第一种是审核员轮换。让同一个人负责同一类别的审批连续六周，他们就会产生模板化的反应。无论 Agent 的质量是否发生了变化，他们对该类别的批准率都会向上漂移。轮换可以重置认知框架，使审核员的决策重新成为真正独立的观察点——这是审批步骤能够提供有效信号的唯一方式。

第二种是审计样本：从自动审批的项目中抽取一部分作为预留样本，依然进行完整的人工审核，纯粹用于衡量旁路政策的真实误批率。没有这个，置信度阈值就只是个猜想。有了它，你就拥有了一个反馈循环，能告诉你旁路政策何时发生了漂移，以及何时需要重新调优。审计样本并非免费——它会削减自动审批带来的吞吐量增益——但它是运行基于置信度的旁路机制唯一合理的方式。

将这些结合在一起的模式是：将 HITL 系统视为需要自身可观测性和 SLO 的系统，而不是埋在 Agent 架构内部的实现细节。队列有指标，审核员有容量，政策有错误率。生产服务所具备的一切特征在这里同样适用，而“我们有人在审核”并不能回答生产服务必须回答的任何问题。

没人明说的架构决策

当团队发布带有流程审批的 Agent 时，他们隐式地在两种截然不同的系统之间做选择。一种将人类视为 Agent 必须通过的关卡——每一次操作，每一刻，非黑即白地批准或拒绝。另一种将人类视为对大多数自主系统的采样机制，仅在 Agent 自身不确定或触发政策时才介入。

第一种是大多数团队默认构建的，也是在规模化时会崩塌的。第二种构建起来更难——它需要一个有效的置信度信号、一个政策引擎、一个优先级队列和一个审计循环——但它是唯一能在 Agent 业务量超过单个审核员每日容量后依然持续扩展的模式。

从第一种架构转向第二种架构的决策通常会被推迟，直到队列已经“着火”。到那时，团队已经在处理超时的 SLA、愤怒的用户，以及因为各种错误原因趋近 100% 的批准率。更健康的做法是从第一天起就按第二种架构设计，设定保守的 Tier 0 阈值，并随着置信度数据的积累而收紧。你随时可以放宽政策，但你无法撤销一个季度以来所有“走过场”的决策。

对于任何部署带有辅助审批的 Agent 团队来说，首要原则是：引入人工审批的那一刻，你就引入了一个队列。开始对其进行仪表化监控，开始为其配置人员，开始将审核员的注意力视为真正的稀缺资源。架构图上的绿色对勾不是一个功能——它是一场赌博，赌你能一直付得起这笔账，而每当 Agent 运行时，账单就会随之而来。