人在回路

它是什么

人在回路是在 AI 工作流的特定判断、审批或异常节点引入人员，让人获得必要信息并决定继续、修改、拒绝还是升级。

它不是要求人重做全部工作，也不等于界面上随便放一个确认按钮。关键在于人员能否在动作生效之前进行有意义的控制——能看见判断所需的依据、有权限说不、并且知道自己在为哪个后果负责。少了这三条，那个环节叫作「有个按钮」，不叫人在回路。

为什么需要它

AI 系统会遇到低置信度、规则冲突和高影响动作这三类情况。完全自动化可能把一次误判直接变成一笔退款、一次删除、一封对外发送；而所有步骤都要人工确认，又等于没有自动化。

人在回路解决的是分配问题：把人员放在风险最高或信息最不足的节点上，其余环节放手。同时它解决责任问题——谁在什么条件下批准了什么，可以被记录、被追溯。前者是效率，后者是治理，两者都是它存在的理由。

它如何工作

机制是暂停—审批—恢复：系统先定义触发条件（金额阈值、不可逆动作、敏感对象、连续失败等）；当模型发起受控的工具调用时，运行暂停并保存状态；审批界面展示动作、参数、依据、风险和可选决定；有权限的人批准、拒绝、修改或升级；系统记录决定，再从原状态恢复执行。

OpenAI Agents SDK 文档展示的就是这条「中断 → 审批/拒绝 → 恢复」的实现路径；而 NIST AI RMF 则把「定义人机角色」和「记录监督流程」列为风险管理的预期结果——一个给的是技术机制，一个给的是治理要求，两边是配套的。

三个工程细节决定了它是不是真管用：

• 状态必须能保存和恢复，否则「暂停」等于中止，人批完还得从头再跑一遍。
• 审批界面必须自带判断依据。 如果审批人要离开页面去查金额或供应商状态，这个环节很快就会退化成形式。
• 超时要有明确语义。 默认「无人处理保持未执行」；绝不能把「没人管」默认为批准——这是这类设计里最危险的一条默认值。

必须澄清的误会

人在回路 ≠ 人工监督（人工监督）。 两者层级不同：人在回路是流程层的控制点——「这个动作前必须有人批」；人工监督是组织层的安排——「谁对结果负责、怎么追溯、怎么审计」。把前者当成后者，会出现一种典型失效：每一步都有人点了「同意」，但没人对整体结果负责，出事时查不到是谁的判断。

人在回路 ≠ 护栏。 护栏是自动执行的规则边界（超限就拦、命中黑名单就拒），人在回路是人工决策点（由人拍板）。它们配合使用：护栏先挡掉明显越界，剩下的灰色地带交给人。反过来用就会出问题——用人工审批去承担本该由规则拦住的事，等于把人变成一道昂贵的、会疲劳的过滤器。

人在回路 ≠ Agent 沙箱。 沙箱管的是「即使获批之后，它还能碰到什么范围」；人在回路管的是「这一步要不要放行」。一个管范围，一个管放行，缺任何一个都不完整：只有审批没有沙箱，一次误批就可能越权访问；只有沙箱没有审批，越界动作会在范围内畅通无阻。

真实例子

一个采购助手可以自动汇总报价、生成订单草稿。但当订单金额超过阈值、或供应商不在白名单时，它必须暂停。

审批人此时看到的是：供应商名称、金额、预算科目、报价出处、以及模型建议。他可以批准、退回修改，或转给法务。如果超时无人处理，订单保持未执行并通知负责人。

这个例子里有三个设计动作值得照搬：触发条件是具体可实现的（金额 + 白名单，不是「重要订单」这种形容词）；展示的字段是为判断服务的（预算科目与报价出处，缺了就得出去查）；超时语义是明确的（保持未执行，而不是默认放行）。

什么时候适合与不适合

适合：高风险、不可逆、受监管或明显异常的动作。判断标准不是「重不重要」，而是做错了能不能撤回——不能撤回的，就该有人。

不适合：低影响且容易撤销的常规步骤。这些适合自动执行或事后抽样复核——每一步都设人工确认，等于把自动化退化成一个人工队列，而且会带来新的失效：审批疲劳（不看就点同意）、上下文不足（信息不够，只能凭感觉批）、以及人员自身偏差。

所以设置人工点位时，还有三条必须一起到位：审批人要有权限（能真的说不）、要有足够上下文（不用离开页面去查）、要有明确责任（他知道这是他的判断）。同时系统要监测三个指标：拒绝率、响应时间、绕过行为——这三个数字能告诉你这个环节是真在起作用，还是已经变成形式。

亲自试一下

选一个 AI 工作流，列出所有会改变外部状态的动作（发送、写入、删除、支付、对外提交），按影响与可撤销性分成低、中、高三档。

然后只针对高风险那一档，写出五件事：触发条件、审批角色、必须展示的五项信息、四种可能的决定（批准/拒绝/修改/升级）、以及超时怎么处理。

最后请实际的审批人拿一条模拟请求判一次。

全程约 30 分钟。观察点是「他有没有离开页面去查关键事实」——如果查了，说明你给的审批上下文不完整，这个环节上线后一定会退化。他提出的第一个疑问，通常就是你没列进展示字段的那一项。

接下来学什么

人在回路是第 4 站 给手脚 · 怎么让它做事 的控制边界；本站回答的是「怎么从给答案变成把事办完」。

顺着这一站往下：上游是 AI Agent（它为什么会走到需要人介入的地方）、工具调用 与 Agent 规划（它靠什么动手、怎么定步骤）。同一站内，Agent 沙箱 管住「它能碰到什么范围」——和本文的「放行」是一对。

组织层的那一半在第 8 站 给安全 · 什么时候必须有人管：那里有 人工监督、AI 护栏 与 人工升级处理。

来源与修订

「敏感工具调用的暂停、批准或拒绝，以及从原状态恢复」这套技术机制，参考 OpenAI Human-in-the-loop 文档（Agents SDK）；「定义人机角色、记录监督流程、明确责任」这组治理要求，参考 NIST AI Risk Management Framework Core；而人员偏差、不同人机配置的适用边界，参考同一框架的 Human-AI Interaction 附录（均访问于 2026-09-19）。三份来源覆盖了「机制」「治理」「人因」三层，避免只谈实现不谈责任。

两处必须点明的边界：其一，本文不固化任何阈值——金额上限、白名单这类参数是业务决策，词条只给判断方法；其二，具体的审批 API 与法定义务随系统版本、行业与司法辖区而变，NIST AI RMF 本身也在修订中，涉及合规时应以你所在辖区的现行要求为准。

修订日期 2026-09-19：本条由生成模板改为决策页——新增「必须澄清的误会」一节（对人工监督、对护栏、对沙箱），把「暂停—审批—恢复」与「超时不得默认批准」写成机制，去掉生成期的引用标记，补 boundaries 与 minAction。