每个智能体 (Agent) 架构图中都有一个标记为“上报给人类 (escalate to human)”的方框。它用一条整洁的箭头画出，既能让评审人员满意，又能让系统显得安全。然而，架构图从未展示过箭头另一端的人——他们是否存在、是否醒着，以及是否能在智能体耗尽耐心之前给出答复。
人机回环 (Human-in-the-loop) 被当作一种设计模式来推销。但在生产环境中，它的表现更像是一个人员配置问题。这种模式假设有人在随时待命；而人员配置的现实是，上报请求并不会在人类刚好有空时出现——它们有自己的“时间表”。比如凌晨 2 点，当夜间批处理任务触发护栏 (guardrail) 时出现的爆发式请求。或者是午餐时间，当一半评审员都不在座位上时产生的长尾延迟。又或者是细水长流般的请求量，在不知不觉中超出了那支在演示阶段看起来绰绰有余的双人团队——毕竟在演示阶段，智能体每天只处理 10 个请求，而不是 1 万个。
“我们有上报路径”与“上报得到响应”之间的鸿沟，正是智能体系统发生故障且评估 (eval) 无法捕捉的地方。评估衡量的是智能体是否正确地发起了上报，而从未衡量过是否真的有人在那里。
这种模式默默地假设了人的存在
人机回环 (HITL) 相关文献描述了三种清晰的模式：一个用于“是/否”决策的审批门禁 (approval gate)；一个当置信度低时将案例路由给人类的上报触发器 (escalation trigger)；以及一个人类与智能体共享状态的协作工作空间。这三种模式都是正确的，但它们都包含一个架构图未明说的关键性假设——即人类这一端是可以调用的“函数”，并且它会返回结果。
但它不是函数。它是一个容量有限、可用性波动且响应时间本身就是一个随机变量的“工作者池”。当你编写 await human_approval(case) 时，你并没有添加一个检查点，而是增加了一个对系统的依赖——一个你无法控制、没有预配资源、且可能从未衡量过的系统。
这就是为什么添加人机回环 (HITL) 会让人觉得成本低廉得具有误导性。编写触发代码只需一个下午的工作。但建立其背后的人力能力——值班轮换、SLA 协议、以及让评审员能在 30 秒而非 10 分钟内处理案例的工具——是一项持续的运营成本，而且通常没人将其列入项目预算。模式发布了，但人员配置没跟上。
上报本质上是队列，而队列遵循数学规律
一旦同时存在多个待处理的上报请求，你就拥有了一个队列。队列是软件领域少数拥有百年成熟理论支撑的事物之一。借用这些理论吧。
一个队列有三个决定性的参数：到达率 (λ)——智能体每小时生成多少个上报请求；服务时间——人类从收到通知到做出决定处理完一个请求所需的时间；以及可用服务器的数量——即实际在岗轮换的人员，而非组织架构图上的人头数。到达的工作量与团队能吸收的工作量之比就是流量强度。当这个比例略微超过 1 时，队列并不会只是变慢一点点，它会无限制地增长，直到系统崩溃。
如果你忽略以下三个特性，这个队列将会让你吃尽苦头：
- 到达是爆发性的，而非平稳的。 上报请求具有相关性。模型退化、上游数据变更或单一的异常输入类别都会同时触发大量案例。按平均到达率配置人员，必然会导致队列在每次爆发时溢出——而爆发时刻恰恰是最需要人工判断的时候。
- 服务时间具有肥尾效应 (fat tail)。 大多数上报处理起来很快。但有少数案例确实很难，评审员会卡在那里。这少数几个案例会阻塞后面的队列，就像线程池中的一个慢请求会阻塞整个池子一样。你的 p50 评审时间看起来很美好，但它毫无意义；p95 才是决定积压量的关键。
- 等待中的调用者会放弃。 呼叫中心的排队模型在几十年前就发现，如果不模拟“放弃（挂断电话）”，就无法模拟真实的队列。经典的 Erlang-A 模型之所以存在，正是因为不考虑放弃行为的数学模型会系统性地低估人员配置需求。你的上报队列也会发生“放弃”。问题在于，当调用者是智能体而非人类时，“放弃”意味着什么。
无人响应的上报比没有上报更糟糕
这正是让它比普通积压更危险的地方。当支持队列变长时，客户会等待并抱怨。但当“智能体”的上报队列变长时，智能体会有两种表现，而两者都很糟糕。
它会停滞。智能体被阻塞在 await human_approval 上，保持工作流处于开启状态。40 分钟前提出请求的用户正盯着进度条发呆。更糟的是，智能体可能正持有某些资源——数据库事务、预留的库存物品、部分构建的订单——这些资源现在都处于悬空状态。停滞的智能体并非暂停，而是一个正在积累风险的半成品操作。
或者，它会静默执行。由于某些原因，有人合理地添加了超时机制以防止系统死锁。超时触发后，智能体执行默认操作。如果默认操作选择不当——比如“超时即批准”，这在为了保持吞吐量的情况下非常常见——那么上报就起到了反作用。该案例之所以被标记，是因为它具有风险，而超时却将其转化为一个未经评审的风险操作。你建立了一个检查点，但在高负载下，它恰恰放行了那些它本该拦截的流量。
这是核心的不对称性。一个完全没有人机回环 (HITL) 的系统至少在自主性上是诚实的；你知道智能体是独立运行的，并据此进行设计。而一个会静默发生“故障放行” (fail open) 的 HITL 系统则是在对你撒谎。架构图显示已评审，审计日志显示已评审，但实际上根本没人看。最昂贵的事故往往源于这种鸿沟，因为上游的每个人都在信任一个从未发生过的评审。
为你实际构建的队列配备人员
如果升级（escalation）是一个队列，那么你就应该像运维团队一直管理队列那样去管理它——不是靠更精美的图表，而是靠容量、优先级和诚实的服务目标。
为 Agent 的升级设置 SLA，就像你为寻呼告警设置 SLA 一样。 “人类在 N 分钟内响应”是一个你可以据此配备人员、进行告警和报告的数值。如果没有它，“总会有人处理的”就成了政策，而这种政策除了演变成事故之外，没有任何失败模式。
将升级纳入真正的轮值（on-call）制度。 这是团队最抵触的一点，因为它将一个整洁的架构方框转化为一种持续的人力成本。但这种成本一直存在——你只是希望有人能非正式地消化掉它。在凌晨 2 点，他们不会。如果 Agent 可以全天候升级，那么轮值也必须全天候覆盖，或者 SLA 必须明确规定夜间升级要等到早上。两种做法都可以，但假装问题不存在是不行的。
进行分诊（triage）和批处理，让渡给人类看那些真正重要的决策。 一个淹没在低风险确认中的审核员会机械地点击批准——然后也会机械地批准那个真正关键的，因为它看起来和另外 40 个没什么两样。根据风险等级对队列进行排序，让 Agent 自动处理低风险部分。批量处理类似案例，让审核员做出一个明智的决策，而不是进行 40 次上下文切换。目标不是最大化人类的参与度，而是将稀缺的人力注意力花在能够改变结果的地方。10%–15% 的升级率是一个经常被引用的目标；正确的数字是你的轮值团队在 SLA 范围内实际能处理的任何数值。
衡量队列，而不仅仅是触发器。 监测到达率、响应时间、解决时间和放弃率。如果你只记录“Agent 是否正确升级”，你就会对真正发生的失败视而不见——即升级流程正确触发，却被投递到了一个空无一人的房间。
为“救兵永远不来”的情况做设计
你并不总能为队列配备充足的人员。预算是现实的，黑夜是漫长的，而流量激增往往会超出任何轮值的承受能力。因此，Agent 的行为必须建立在假设救兵可能永远不会到来的前提下。将其作为一等公民的（first-class）设计案例，而不是边缘情况来对待。
首先，让超时后的默认操作保持安全，而不是为了方便。对于大多数操作，超时后的安全默认是可逆的：不发送、不收费、不删除、不部署。暂缓不可逆的操作并让其过期。Agent 应该向用户返回明确的“我无法完成此操作——需要人工审核”，这是诚实的，而不是返回一个虚假的默认成功。一个承认自己被阻塞的 Agent 状态，远好于一个假装已获批准的 Agent。
其次，让等待过程本身是不具破坏性的。如果 Agent 在等待时必须保持工作流开启，它不应同时持有事务、锁或资源预留。持久化待处理状态，释放资源，并在人工响应时让工作流干净地恢复——或者在没人响应时干净地过期。一个待处理的升级应该只消耗存储空间，而不是带来风险。
此外，在截止日期到来之前，而不是刚好在截止日期时，设计分层降级方案。如果主审核员未能在 SLA 内响应，在执行默认操作之前，先路由给备选人员。一份数小时无人问津的贷款审核应该在触发任何自动决策之前，先转交给另一位审核员。默认操作是最后的手段，而且必须显而易见——要高调记录日志、在仪表盘上展示、并作为 SLA 违规进行报告，绝不能将其掩埋为日常事件。
诚实的说法是：升级路径是系统对自己许下的承诺。决定当承诺破裂时会发生什么，像设计正常路径一样细心地设计那条路径，并在启用它时发出响亮的告警——因为一个悄无声息触发的默认操作，与一个点头同意的人类并无二致。
核心要点
“人类在环”（Human-in-the-loop）并不是让 Agent 变得安全的方法。它只是将一个艰难的决定移交到队列中，并寄希望于队列能得到处理。它是否得到处理是一个人员配备问题——到达率与容量的博弈、服务时间与 SLA 的博弈、团队规模与必须吸收的突发流量的博弈——而人员配备问题无法通过架构图上的一个箭头来解决。
在你发布下一个“升级到人工”的方框之前，请回答三个架构图无法回答的问题。凌晨 2 点谁在另一端待命？Agent 在等待时正在做什么？以及，当确实没有人回答时，到底会发生什么？如果你不能回答这三个问题，你并没有增加安全网。你只是增加了一个依赖项，而且你还没有为这个依赖项预留资源。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
