20 篇博文 含有标签「human-in-the-loop」

你的评估流水线每周会产生 800 条 trace 供人工审核。你的标注人员每周大约有 90 分钟的预算来处理这些数据。他们打开队列，对前三条进行打分，再将其余几条标记为“跳过”，然后就关闭了标签页。你在周一早上盯着看的排行榜，现在只是反映了哪些 trace 碰巧排在了列表顶部，而不是对系统质量的真实衡量。

这不是一个标注问题。这是一个披着质量问题外衣的吞吐量问题，也是评估项目退化最隐蔽的方式之一。Trace 仍在流动。仪表板仍在渲染。数值仍在变动。你没看到的是，你的“人工评分评估得分”的分母已经悄然缩减到了寥寥几项，而这些项是由一个没人刻意设计的排序函数挑选出来的。

确认对话框是 AI agent 工具箱中最廉价的安全层。它由一个字符串、一个按钮和一个回调函数组成。提议增加这一功能的项目经理在散会时，坚信该 agent 现在是安全的。开发它的工程师用一个下午就把它发布上线了。负责审计的合规检查员勾选了通过选项。而那天早上第七次看到它的用户，在眼睛还没读完标题之前，鼠标就已经移到了“确认”按钮上。

不到一周，确认步骤就不再是一个决策点，而变成了一种节奏。Agent 问：“你确定要发送这封邮件吗？”，用户回答“是”，就像别人打喷嚏时随口回一句“保重”一样自然。终有一天，Agent 会提议一个真正错误的动作——错误的收件人、错误的金额、错误的语气——而用户会带着之前确认那六个正确动作时同样的自动化反应去确认它。邮件发出后，团队写下一份事后分析，称之为“用户操作失误”。

这不是用户错误。这是系统误把“点击”的存在当成了“同意”的存在。

升级工具曾是最后一道安全网。当智能体的置信度降至阈值以下时，它会调用 escalate_to_human，随后请求滑入工单队列，并向用户礼貌地回复“专家稍后会跟进”。工程团队在发布清单上完成了闭环确认。值班表上也列出了负责接收的人员。

六个月后，一次审计对该路径进行了回溯。升级工具打开了一个 Zendesk 工单。Zendesk 队列由客服团队为了维持 SLA 响应时间而设立的预审智能体进行分拣。预审智能体由于找不到可以直接解决的政策匹配，调用了自己的 delegate_to_specialist 工具——该工具将案例路由给了一个专家智能体。而专家智能体在不确定时，又调用了 escalate_to_human。追踪轨迹形成了一个闭路。审计抽样调查的升级案例中，没有任何人类接触过。发布文档中描述的人机协作（human-in-the-loop）实际上并不存在。

升级接口并没有失败。它的每一次跳转都得到了执行。失败的是“接收系统是自然人”这一假设。

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

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

Agent A 向 Agent B 请求完成其任务所需的一项数据。Agent B 在回答之前，向 Agent A 请求生成该数据所需的一项上下文。这两项请求在发出途中都跨越了“需要人工审核”的边界。第一项请求落入了由 Priya 监看的 Slack 审批频道。第二项落入了由 Marcus 监看的 Jira 队列。Priya 正在吃午饭。Marcus 正在接听客户电话。两人都不知道对方的存在。工作流挂起了 19 个小时，直到一次客户投诉迫使有人去询问为什么汇总结果从未送达，才有人注意到。

这不是一种新颖的失败模式。它是分布式系统中最古老的失败模式，只是换了一身新装。Coffman 条件——互斥（mutual exclusion）、占有且等待（hold and wait）、不可剥夺（no preemption）、循环等待（circular wait）——早在 1971 年就被命名了，而一个带有“人机协同”（human-in-the-loop）审批队列的多 Agent 系统默认满足这所有四个条件。新的麻烦在于，死锁中的“资源”之一是人的注意力，这意味着你的活性保证（liveness guarantee）现在受限于两个互不相识的人独立进行上下文切换的速度。

你做了负责任的事。你检查了你的 agent，识别了那些可能造成真正损失的操作——发放退款、删除记录、发送外部邮件、部署配置更改——并将它们路由给人工审批。风险分级门控（Risk-tiered gating）。教科书级的做法。评审委员会也签署通过了。

然后，三周后收到了一个客户投诉：一个 agent 任务自上周二以来一直处于“进行中”。没有失败。没有报错。只是停留在一个人工审批队列中，而事实证明，根本没人在关注那个队列。Agent 完成了它的工作，将危险操作挡在门后并等待。而这扇门没有负责人。任务在没有仪表盘指向、没有警报触发的地方默默地老化。

观察一名开发者使用 Agentic 编程工具一小时，你会看到同一个动作重复四十次：弹窗出现，“允许 Agent 运行 git status 吗？”，手在眼睛读完之前就移到了批准按钮上。到第四十次提示时，提示内容根本没被阅读。它变成了一个用户学会全速通过的减速带。

这是“人机回环”（human-in-the-loop）的一种无声失败。架构图上仍然显示人类在把控每一个危险动作。审计日志仍然记录着对每个命令的明确批准。但人类已经停止了评估。他们变成了一个接入控制流的生物版 “yes” 函数 —— 虽然身在回路中，却不贡献任何判断。权限提示本应是一项安全控制，它却退化成了附带确认对话框的系统延迟。

每个智能体 (Agent) 架构图中都有一个标记为“上报给人类 (escalate to human)”的方框。它用一条整洁的箭头画出，既能让评审人员满意，又能让系统显得安全。然而，架构图从未展示过箭头另一端的人——他们是否存在、是否醒着，以及是否能在智能体耗尽耐心之前给出答复。

人机回环 (Human-in-the-loop) 被当作一种设计模式来推销。但在生产环境中，它的表现更像是一个人员配置问题。这种模式假设有人在随时待命；而人员配置的现实是，上报请求并不会在人类刚好有空时出现——它们有自己的“时间表”。比如凌晨 2 点，当夜间批处理任务触发护栏 (guardrail) 时出现的爆发式请求。或者是午餐时间，当一半评审员都不在座位上时产生的长尾延迟。又或者是细水长流般的请求量，在不知不觉中超出了那支在演示阶段看起来绰绰有余的双人团队——毕竟在演示阶段，智能体每天只处理 10 个请求，而不是 1 万个。

“我们有上报路径”与“上报得到响应”之间的鸿沟，正是智能体系统发生故障且评估 (eval) 无法捕捉的地方。评估衡量的是智能体是否正确地发起了上报，而从未衡量过是否真的有人在那里。

当 AI 系统犯下严重错误时，一种本能的反应似乎很合理：在流程中加入人工环节。如果一名审核员遗漏了某些内容，就增加第二层审核。如果法务部门感到不安，就增加第三层。这种级联反应给人的感觉像是安全性的复利叠加——每一个审批阶段都是另一层保护。

事实并非如此。在大多数高审核量的生产系统中，增加审批层级反而会降低 AI 的准确性，让审核员产生一种毫无实际作用的监管错觉，而且最糟糕的是，它会毒化 AI 训练所依赖的反馈信号。最终，你承担了人工审核的全部运营成本，却几乎没有获得任何安全性收益。

每个智能体产品的安全仪表盘上都应该有一个数字，但几乎没人追踪它：随时间推移的人均批准率。发布一个“我可以发送这封邮件吗”或“我可以针对生产环境运行此查询吗”的权限提示，其曲线每次都如出一辙。第一天，用户会犹豫、阅读，有时会点击“不”。到了第二周，这已经是本小时内的第五次提示，拒绝的代价是必须由你亲自完成工作，于是点击率会收敛到 95% 以上。团队的安全叙事仍然声称用户批准了每一项操作。但在任何实质性的认知层面上，用户并没有。

这不是一个可以通过更好的文案来修复的 UX 问题。这是使 Cookie 横幅、浏览器 SSL 警告和 Windows UAC 对话框失效的同一种习惯化现象，只是应用在了一个运行速度比以往快几个数量级的底座上。许可门槛是一种具有半衰期的安全控制。如果在发布时不衡量它的衰减速度，你发布的只是一个用户到第二周就会习惯性忽略的复选框 —— 以及一个依赖于不再具有任何意义的点击的合规叙事。

发布的 AI 功能带有一个完美的“安全方案”。任何置信度高于阈值的请求都会自动执行。任何低于阈值的请求都会进入人工审核队列。刚发布时，每天下午 5 点队列就会被清空。市场部门在幻灯片上写下“人工参与（human-in-the-loop）”。合规部门签字批准。大家打道回府。

六个月后，该功能的使用量增长了 10 倍，但审核团队并没有。队列里堆积了 72 小时的待办任务。一个需要“人工审核”的项目在未读状态下躺了三天，然后被一名疲惫的审核员批准——他平均处理一个决策只需 11 秒，因为只有这样才能保证队列不会在夜里翻倍。产品依然宣称“每项操作都经过审核”。现实情况是，“人工参与”已经退化成了“人工最终会在队列里看到”——这在功能上其实就是带有文书延迟的自主运行。

安全方案并不是因为 Bug 而失效，而是因为一个没人负责的人力资源计划而崩溃。

大多数AI团队能告诉你他们的遏制率——AI在不转交给人工的情况下处理的交互比例。但很少有团队能告诉你这个数字是否合理。

升级标准是AI增强团队中最重要的设计文档，而大多数团队根本没有这份文档。他们有一个埋藏在YAML文件中的阈值，以及一个隐含的假设：AI知道自己什么时候卡住了。这个假设在两个方向上都是错误的：阈值过高，人工就要花时间返工AI的工作；阈值过低，用户在没有任何补救措施的情况下承受AI的错误。两种失败都是隐性的，直到它们积累成大问题。