变成关键路径的审批队列

设计文档写着“人机回环”。发布演示稿写着“默认安全”。六个月后的事故回顾则写道，由于审批人在吃午饭，智能体（Agent）花了 90 分钟才给客户发送发票。这些文档都没有撒谎。它们只是在描述同一个组件在负载曲线不同位置的表现——而其中只有一份准确抓住了全貌。

当你在智能体与不可逆操作之间加入人工干预时，你并没有增加一个安全原语（safety primitive）。你实际上是增加了一个服务，它带有队列、吞吐量限制、质量负载曲线以及可用性概况。如果一个团队在发布智能体时没有命名那个服务，那么他们交付的产品的关键路径将取决于一段他们拒绝去运维的基础设施。

这种模式高度一致且可预测。有人记录过一个真实案例：由于要求对智能体的每一个输出进行人工审批，在 48 小时内积压了 1.4 万个待处理项，而负责审核的只有 3 个人，每小时大约处理 200 项。平均审批延迟达到了 6.5 小时。智能体并没有坏。它完全按照预期工作。只是审批人员池的大小是根据设计文档中的流量估算的，而不是实际的生产流量，这两者之间的差距在发布次日的早晨演变成了一个 P0 事故。

队列是一个服务，而不是一个勾选项

第一个错误是将“需要审批”视为工作流的一个属性，而不是系统中的一个依赖。属性是静态的。而依赖拥有 SLO、容量模型、轮值（on-call）和仪表盘。无论团队是否记录在案，审批环节都具备这些特性。

一个最低限度的诚实框架是：每一个审批步骤都是一个包含到达、服务时间和有限工作人员的队列。智能体是到达过程之一。客户升级请求（escalation）是另一个。常规重试是第三个。审批人员就是工作人员。排队论自 20 世纪 60 年代起就对此有了定义——团队只是没有使用这些术语，因为“人工”这个词让他们觉得数学模型发生了变化。

它并没有改变数学逻辑。它改变的是方差。人工服务时间具有重尾特征（heavy tails）——一次常规审批需要 30 秒，而一次令人困惑的审批则需要 20 分钟，且两者都由同一个审批人处理。重尾服务时间意味着在负载下，队列深度的增长速度比平均值所显示的要快。如果仪表盘显示的平均审批延迟是 4 分钟，它实际上隐藏了在队列繁忙时会让你陷入困境的长尾效应。

如果你在查看智能体延迟仪表盘时，没有同时查看队列深度仪表盘，那么对于控制到达率限流的人来说，这个队列就是不可见的。他们不会进行限流。深度会不断增加。直到客户投诉，人们才会第一次意识到问题的存在。

审批者的准确性并非恒定

第二个错误是将每次审批视为具有固定质量的独立事务。事实并非如此。同一个审批人在处理第 3 个和第 300 个决策时、在午饭前和午饭后、在正常周和发布高峰期，对于同类决策会给出不同的判断。

这非常重要，因为团队在发布时建立的安全案例假设审批者的准确率足够高，能够捕捉到智能体的错误。这一假设是在小样本、平静的日子里，且审批者知道自己正受监督的情况下测得的。在生产负载下，同样的审批者会在不相关的智能体任务之间进行上下文切换，混淆正在查看的方案，点错审批行，并因为某个重要决策埋没在 99 个无关紧要的决策中而将其遗漏。

在受监管的环境中，常见的升级 SLA 范围是：实时环节 15 分钟，批处理环节 4 小时，复杂审核 24 小时。在 15 分钟以下，审批者疲劳开始占据主导地位，审批质量随之下降。这并非一个感性的观察——而是一个决定了你究竟能发布什么样的智能体的结构性约束。如果你的业务模型需要亚分钟级的审批，那么你拥有的并不是一个“人机回环”系统。你只是拥有一个步骤繁琐的自动图章（rubber stamp）。

诚实的衡量方法是将审批准确性作为队列深度、队列时长、每小时处理项数和时间点的函数进行测量。绘制出这条曲线。准确率与智能体自身错误率相交的那一点，就是人工环节开始让情况变得更糟而非更好的转折点。没有绘制这条曲线的团队，只是在猜测自己处于这条线的哪一侧。

掩盖瓶颈的组织架构

第三个错误是结构性的。设计智能体的团队并不负责管理队列。负责队列的团队没有针对发布规模进行容量评估。产品经理关注迁移指标。SRE 负责可用性。采购部门负责人员编制。智能体的关键路径组件被拆分到了四个拥有不同考核指标的团队中，而它们之间的裂痕正是故障发生的地方。

你可以预见到接下来的剧本。智能体团队测量任务成功率并报告绿色的仪表盘。审批团队测量每班次处理的项数并报告绿色的仪表盘。而面向客户的延迟仪表盘则是红色的，因为客户在等待一个无人负责的队列中的审批。每个团队都在履行职责。唯独没有人负责的工作是“盯着那些裂痕”。

弥合这一差距的模式，正是每一个成熟的轮值机制最终都会采用的模式：有人需要对端到端延迟负责。不是负责智能体的延迟，也不是负责审批者的响应时间，而是负责客户感知的、从“我发起请求”到“我得到结果”之间的时间。这个人有权对智能体的到达率进行限流、传呼额外的审批者，或者向客户提供一个无需审批的小范围方案。如果没有人拥有这种权限，那么这个队列就是一座没有结构工程师的房子里的承重墙。

真正弥合差距的模式

在那些已经历过这种冲击并幸存下来的团队中，反复出现了一些设计动作。它们都不算奇特，但都要求将队列视为一等公民系统。

根据风险对请求进行分层，并进行相应路由。 Coinbase 报告称，在 2024–2025 年期间，通过将大约 60% 的常规查询路由到仅限智能体（agent-only）的路径，将特定账户的工作路由到一级（Tier 1）审核池，并将高价值交易路由到专门团队，在人员编制不变的情况下处理了三倍的支持量。同样的逻辑也适用于内部智能体：一个能够自动批准 500 美元以下申请、将 5000 美元档位路由给财务审核员、并上报任何异常情况的报销智能体，拥有的不只是一个队列。它拥有三个具有不同 SLO 的队列，并且系统能够独立地承受每个队列的负载。

在审核员界面进行批量处理和分选。 能够将十个低风险审批作为一次决策进行批量处理，然后标记出第十一个异常值的审核员，与必须逐行点击的审核员相比，其处理量完全不同。批量处理原语并没有放宽门槛——它改变了负载下的单次决策时间曲线。第十一个异常值仍然能得到充分关注，而前十个则不再是疲劳的来源。

使 SLO 面向用户，而非面向审核员。 “审核员在 15 分钟内响应”并不是客户签署的合同。客户签署的合同是“我在 15 分钟内得到结果”。仅测量审核员的响应时间而忽略端到端延迟，会让队列在团队拥有的仪表盘上看起来很健康，而客户感知到的延迟却在无人关注的仪表盘上悄然漂移。翻转测量标准：真正重要的数字是从用户意图产生到用户看到结果的时间。

在智能体本身内置优雅降级。 当队列超出负荷时，智能体应该能够为用户提供一个不需要审批的更小范围的服务，或者明确地推迟请求并提供诚实的预计到达时间（ETA），而不是让它停留在加载动画中。后备方案（fallback）不是权宜之计，而是一种卸载（load-shedding）策略。没有它，智能体在负载下的唯一行为就是“沉默地等待”，用户会将其解读为“系统损坏”。

智能体层的队列感知规划。 如果智能体知道队列正处于高负载状态，它可以推迟低优先级的审批工作，为高优先级路径保留审核员容量，并重新编排自己的任务列表。这要求队列的状态对智能体是可见的——这意味着队列必须是一个一等公民的可观测组件（first-class observable component），而不是 API 调用背后的黑盒。

你试图向自己隐藏的单位经济效益

成本框架通常是大多数团队的模型在接触生产环境时崩溃的地方。智能体典型的单位经济效益计算包括：每次调用的模型成本、工具延迟、托管费用。审核员的时间很少出现。即使出现，它也是按纯小时工资计算的，而不是包含了管理、入职培训、流失以及高级审核员因初级审核员成为瓶颈而处理常规项目的机会成本在内的综合成本（loaded cost）。

更诚实的核算应该从智能体所取代的人力时间的综合价值开始——到 2025 年底，美国平民的平均薪酬约为每小时 49 美元，专业服务领域则明显更高。一个每月能节省 60 小时人工、每小时成本 100 美元的供应商跟进智能体，创造了 6000 美元的价值。平台成本是 1200 美元。如果审批审核需要 9 小时的审核时间，净节省约为 3900 美元。如果审核时间攀升至 35 小时，数学逻辑就会发生反转，工作流将变成净负值。

令团队感到惊讶的数字是，单位经济效益对审核时间是多么敏感。设有审批门槛的智能体并不是按推理成本定价的，而是按审核员的小时数定价的。如果团队在迁移提案中没有体现这一数学逻辑，那么他们就是给领导层签下了一张账单，其中最大的支出项目是随着采用率而增长的人员编制——这恰恰与大家被承诺的曲线背道而驰。

第二个令人不安的数字是 AI 智能体项目的失败率。 Gartner 2025 年的调查显示，40% 的项目面临到 2027 年被废弃的风险，主要原因是成本和商业价值不明确。幸存下来的团队将是那些诚实地评估了人工门槛成本并构建了路由以保持其精简的团队。而废弃项目的团队则会太晚才发现，他们购买了一项边际成本为审核员小时数的业务。

审核员容量即基础设施容量

架构上的认知既简单又令人不适：将人工审核员视为无限吞吐量，与将推理端点（inference endpoint）视为无限吞吐量是同样的错误。两者都会产生看起来像智能体故障的停机，而实际的失败源于一个没人编写的容量模型。

解决方案不是移除人工，而是像运营任何其他受容量限制的服务一样运营由人工把关的组件：配备到达率控制、深度和账龄遥测、负载卸载路径，并指定一个得分指标包含端到端延迟的负责人，以及一个与预测负载挂钩的人员配备模型，就像值班轮换（on-call rotation）与预测事故挂钩一样。

审批队列是一个引入了人工环节的调度问题。一旦你这样称呼它，你需要的工具箱就是你在技术栈中处理其他调度问题时已有的工具——背压（backpressure）、优先级排序、批量处理、优雅降级，以及在对用户最重要的边界处测量的 SLO。那些弄明白这一点的团队运行的不是魔法，他们运行的是队列。那些还没弄明白的团队也在运行队列，只不过他们将其称为安全原语，而这种区别正体现在事后复盘（postmortems）中。