当升级请求无人响应时：人机回环是一个人员配置问题

每个智能体 (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 分钟前提出请求的用户正盯着进度条发呆。更糟的是，智能体可能正持有某些资源——数据库事务、预留的库存物品、部分构建的订单——这些资源现在都处于悬空状态。停滞的智能体并非暂停，而是一个正在积累风险的半成品操作。

加载中…