Human in the Loop 实践：AI 智能体的审批、抽检与转人工

Human in the Loop（人在回路）的关键，是在出错代价高、或难以撤销的 AI 操作前安排人工把关。人工审核可以放在 3 个位置：执行前审批、完成后抽检，以及异常升级时接手。先为每类操作选好审核位置，再根据证据，逐项减少不必要的例行审批。

什么是 Human in the Loop（人在回路）？

人工审核首先要划清权限：哪些操作可以不经人工同意，由系统自行执行？ 客服智能体可能在同一段对话里读取订单、起草回复、修改记录，再发起退款。这些操作需要的权限并不相同。

可以把它想成一座入口有人值守的花园。园丁不必检查每一个脚步，而是在损坏难以修复的地方把住入口，事后检查日常工作，遇到异常时再响应铃声。真正要想清楚的是：这道门应该设在哪里。

“人在回路”具体指什么？

Human-in-the-loop 通常缩写为 HITL，指人通过反馈、干预或决策，参与 AI 系统的运行。它的含义比一个审批按钮更广。放到企业的实际业务里，就应该对应一项明确职责：有人批准待执行的操作、检查已经完成的工作，或处理例外情况。参见 Stanford HAI 的定义。

这个概念也包括人工标注训练数据、纠正模型输出，以及引导模型学习。这些用法都成立，但今天由人批准一笔退款，并不会自动重新训练明天的模型。业务中的人工审核能积累证据；要改进模型或工作流，还需要另行设计并实施改进流程。参见 Google Cloud 的说明。

AI 智能体的人工审核应该放在哪里？

AI 智能体是利用模型选择执行步骤、调用工具的软件，例如查询订单或发送消息。对于会产生重大影响的工具调用，人工审核应紧挨着执行之前。在任务开始时批准智能体的计划，并不能确认它之后会选择哪个收件人、哪笔金额或哪条记录。

这些步骤之间如何协调，也要明确设计。AI 智能体编排介绍了如何围绕智能体的工作安排状态保存、责任归属和任务交接。

人工介入的三个位置

审批用于拦住某次具体操作，抽检用于发现已完成工作中的共性问题，异常升级用于处理超出智能体权限的事项。 同一个工作流可以同时采用这些机制。

执行前：人工审批

系统准备好一项内容明确的待执行操作，然后等待。审核人需要看到收件人或目标记录、拟做的变更、相关证据，以及触发审核的规则。批准后放行这项操作；拒绝后阻止执行。

退款、涉及敏感事项的客户回复、不可逆的删除，都适合在这一步把关。如果审核界面只问“是否允许使用客服工具？”，实际的业务决策就被藏起来了。写清“基于这一原因，将这笔订单的款项原路退回”，审核人才有实质内容可核查。

执行后：抽样审核

系统在已获授权的范围内执行操作，之后由人抽查部分结果。这适用于影响较小、偶发错误能够被发现且可以承受的操作，例如工单分类或内部摘要。

抽检无法阻止已经发生的错误。对于发给客户的消息，后续更正或许能补救沟通，却不能让客户忘掉已经读过的原文。决定是否自动执行时，也要把这部分无法消除的影响算进去。

用随机样本了解日常质量，再单独抽取异常案例做定向检查。如果只看投诉，就只能了解被报告的失败，无法判断全部已完成工作的质量。

异常升级时：转交人工

当智能体缺少证据、没有权限，或找不到适用规则时，就应把事项转交出去。例如，账户归属信息互相矛盾、订单数据缺失、需要破例处理，或客户明确要求转人工。

交接时应提供证据、已经尝试的操作、尚未解决的问题，以及当前状态。需要人工判断的操作先暂停。如果政策允许，其他已明确安全的工作，例如整理内部摘要，可以继续。

Human Over the Loop：谁来制定规则？

遇到 Human Over the Loop 这个说法时，可以把它理解为治理层：由人制定规则、调整权限，并有权停止系统。术语的用法并不统一，因此要写清具体职责，不能只靠一个标签。负责监督整体表现的管理者，不一定会逐笔审核业务操作。

同样，也要区分 in the loop 的人工审批与 on the loop 的运行监控。监控看板可以迅速暴露问题，但如果没有专门实现暂停机制，系统不会因此在下一次操作前自动停下来。

看出错代价，也看能否真正撤销

如果某项操作可能造成的损害，超过了你愿意在发现问题并完成补救之前承受的范围，就应要求人工审批。 只看模型置信度，回答不了这个问题。

评估一项操作时，可以逐项检查：

• 后果： 是否可能泄露隐私信息、转移资金、作出承诺，或影响账户访问权限？
• 恢复： 能否完整、快速地恢复原状，而且不需要让客户帮忙收拾错误？
• 影响范围： 影响的是内部草稿、一位客户，还是整批记录？
• 证据： 身份、源数据和政策是否足够明确，能够支撑决策？
• 发现时机： 在同类操作不断累积之前，能否及时发现异常？

数据库字段可以改回去，不代表它触发的下游事件也能撤销。收货地址或许很容易恢复，但一旦订单开始履约，情况就变了。要判断完整的业务后果，不能只看数据库是否有撤销操作。

操作范围明确、证据可靠、剩余风险可以接受时，可以采用抽检。操作影响重大，或补救能力不足时，应在执行前审批。缺少必要事实或规则时，要升级处理。如果某项操作本来就被禁止，应直接拦截；审批队列不能成为绕过政策的通道。

AI 护栏是针对输入、输出和工具调用的自动检查，可以为这套机制提供支持。在人花时间审核之前，它们就能拒绝格式错误的请求，或拦截未经授权的目标。人工判断应集中处理通过这些检查后，仍然合理存在的模糊之处。

客服智能体案例：哪些操作需要人工审核？

按操作类型拆分客服智能体的权限。 下表是一家企业刚把智能体引入订单客服时，可以参考的假设性初始规则。这是设计示例，既不是厂商默认配置，也不是实测结果。

假设客户表示一直没有收到订单，并要求退款。智能体可以查询订单和承运商状态，再整理处理建议。如果配送证据与客户陈述冲突，就应把决策转交人工，而不是自行编造解决方案。

如果证据表明这笔退款符合政策，智能体就准备好确切的订单、金额、款项去向和退款原因，提交审批。执行组件在调用支付系统之前，先检查审批结果和当前退款状态，再记录支付系统返回的交易回执。只有这之后，智能体才能声称退款成功。

退款审批与回复审批，是两项独立权限。 批准资金操作，不代表同时允许在随附邮件里编造送达承诺。同样，批准一条安抚客户的消息，也不代表允许智能体在下一次工具调用中悄悄发起退款。

对外发送销售邮件，也应采用同样的区分：文案生成可以自动进行，但向新的收件人名单发送邮件需要审核。修改数据时，应审核旧值与拟修改值之间的实际差异，不能只看一句“已清理记录”的摘要。

让审核队列真正运转起来

审核人需要完整的决策材料、明确的处理时限，以及说“不”的权限。 在聊天频道里放一个审批按钮，只解决了通知这一步。

决策材料应展示确切的操作、受影响的客户或记录、拟提交的参数、原始证据、匹配的政策，以及尚未确认的事实。对于修改操作，应把旧值和拟改值并排展示。附上底层证据的链接，让审核人无需重建整段对话，就能验证智能体的解释。

指定主要审核人和后备负责人，将紧急升级与日常审批分开处理。审核超时后，应继续暂停或取消待执行操作，并通知后备负责人。无人回应，不能被视为同意。

审核能力有硬上限。假设一个队列每小时收到 24 个请求 × 每个请求审核 3 分钟 = 每小时需要 72 分钟的审核时间。一名审核人每小时只有 60 分钟，还没扣除其他工作。即使每个决策都正确，队列也会越积越长。在承诺响应时间之前，要先减少不必要的审批、收窄智能体的操作范围，或增加审核人手。

每次批准都应绑定到审核过的具体内容及参数。如果收件人、退款金额、记录版本或消息内容发生变化，原审批应失效，并重新提交审核。执行前，还要复查等待期间可能变化的事实，例如是否已有其他操作人员为该订单办理退款。

同一项审核决定即使被重复接收，也必须安全。应使用稳定的操作标识，让决定仅被消费一次，并防止对外部系统重复写入。所谓幂等操作，是指重复执行与只执行一次产生相同的效果。如果退款请求超时，应先核对其状态，再决定是否重新发起支付。

常用工具如何暂停 AI 智能体，等待人工决定？

工具提供的暂停机制各不相同，业务决策规则仍要由企业自己制定。 下文描述已于 2026 年 10 月 21 日对照各厂商当时在线的文档核实，介绍的是文档所述行为，并非产品实测。

OpenAI Agents SDK：审批待执行的工具调用

OpenAI Agents SDK 是在应用代码中构建智能体的库。它通过 Python 中的 needs_approval=True，或 JavaScript 中的 needsApproval: true，支持工具审批。需要审批的调用会返回中断信息和可恢复状态。应用批准或拒绝待处理项后，再恢复同一次运行；如果决策需要等待，也可以将状态序列化保存。参见 OpenAI 的审批文档。

在客服应用中，应把审批关卡放在退款工具或发送工具上，并围绕待执行操作设计审核界面。文档中的简短示例会在代码里批准返回的中断项；直接照搬这个无条件批准的循环，并不会形成真正的人工审核。应用必须先取得人的决定。

LangGraph：中断执行，再从保存状态恢复

LangGraph 是用于有状态智能体工作流的库，通过 interrupt() 暂停执行，等待外部输入。需要配置可持久化的检查点保存组件（checkpointer），用来保存执行状态，并使用稳定的 thread_id。恢复时，在同一个线程上调用 Command(resume=...)。参见 LangGraph 的中断文档。

文档明确指出了一个上线时必须注意的细节：恢复执行时，被中断的节点会从头开始运行。中断之前的代码可能再次执行。会改变外部状态的操作，应放在审核之后，并保证可安全重复执行；文档也建议将这类副作用操作拆到独立节点中。中断可以无限期等待，因此还要在外层补上业务所需的审核时限和升级处理逻辑。

n8n：为指定工具接入人工审核

n8n 是可视化工作流自动化平台，可以为连接到 AI Agent 节点的指定工具接入人工审核。文档描述的流程会先暂停，展示拟调用的工具及参数；批准后，按 AI 指定的输入执行，拒绝则取消操作。参见 n8n 的人工审核指南。

打开智能体的 **Tools（工具）**连接口，在 **Human review（人工审核）**下选择一个渠道，再把需要审核的工具连接到这一步。指南列出的渠道包括 n8n Chat 和 Slack，也介绍了如何用 $tool.name 和 $tool.parameters 组织审核消息。

审核消息要让人看清自己究竟在批准什么。指南介绍的是批准和拒绝，不应据此假定它还提供了可编辑的退款表单。如果审核人要求修改，应把提案退回修订，再重新审批。

Anthropic Claude Code：用权限控制工具访问

Anthropic 的编程智能体 Claude Code 在文档中列出了工具权限模式。标为 Manual（手动）的 default 模式会弹出权限确认提示，但已获允许的操作及规则适用例外。acceptEdits 自动允许在获准的工作目录中编辑文件，以及执行某些文件系统命令。plan 用于探索，不修改源文件。参见 Claude Code 的权限文档。

auto 模式会用后台分类器审核 shell 命令、网络请求等操作。这仍是自动化审核决定。bypassPermissions 会跳过权限提示，但文档列明、任何模式都不会自动批准的操作除外。这两种模式，都不能证明每项操作经过了人工审核。

这些设置控制的是 Claude Code 的运行时权限。客服服务仍然需要自己制定退款、收件人和数据访问规则。更聚焦的 Claude dangerously skip permissions 指南解释了该模式在实际运行中的边界。

日志应该记录什么？

保留足够的结构化证据，能够还原谁授权了哪项操作，以及之后发生了什么。 单靠对话记录很难做到这一点，尤其是在任务暂停或转交之后。

将以下字段记录为独立事件，再通过事项标识和操作标识关联起来：

• 操作提案： 操作类型、目标、准确参数、内容版本或摘要值、旧值，以及支撑该操作的原始资料引用。摘要值相当于已审核内容的指纹。
• 决策路径： 政策版本、命中的规则、审批或抽检要求、升级原因，以及相关校验结果。
• 人工决定： 已验证身份的审核人、其对这项操作的授权范围、批准或拒绝的结果、要求的修改、原因、时间戳及有效期。
• 执行情况： 获批操作的标识、工作流与模型配置版本、本次执行尝试的标识、工具结果、外部回执和最终状态。要区分失败、成功和结果未知。
• 质量审核： 该事项如何被选入样本、观察到的错误类型、严重程度、纠正措施，以及权限规则是否发生变化。
• 队列运行情况： 请求到达时间、指定负责人、等待时长、实际审核耗时、是否逾期，以及交接结果。

限制敏感证据的访问权限，对机密信息做脱敏，并制定保留期限。能链接到受保护的源记录时，就不要把每位客户的数据复制进每一份日志。记录简明的决策理由和证据即可；审计一次审批，不需要模型隐藏的推理过程。

把责任归属、禁止事项和升级处理职责写进 AI 可接受使用政策。日志只能记录政策是否被遵守，不能替代一份从未制定过的政策。

按操作类型，逐步减少人工介入

只有经过验证、范围明确的能力，才适合放开自动执行；新操作和影响重大的操作仍应保留审核。 一个笼统的“智能体准确率”，把不同性质的风险混在一起，不足以支撑权限调整。

1. 1

   先只让智能体提出方案

   让智能体起草操作方案，由人作出决定。标注错误类型：收件人错误、陈述缺乏依据、金额不正确、证据缺失，或不必要的升级。用这些案例构建有代表性的评测集，并设置适当的访问控制。

2. 2

   在限定范围内，审批后执行

   只允许在批准后执行。确认拒绝确实能阻止操作、参数变化会使审批失效、重复决定不会造成重复写入。扩大访问权限前，先演练超时和外部操作结果不确定的情况。

3. 3

   把合适的操作改为抽检

   选定一个具体类别，例如基于已核实数据发送的常规订单状态回复。在查看结果之前，就确定验收门槛、抽样方法、审核负责人和停止条件。必须升级处理的触发规则仍要保持有效。

4. 4

   条件变化时恢复审核

   模型、提示词、政策、工具或数据源发生变化时，应重新评估受影响的权限。出现严重事件，或抽检结果恶化时，应在调查期间恢复相关审批关卡。

按操作类别跟踪造成实际损害的错误、审核人的纠正、遗漏的升级，以及恢复所需的工作量。把纯粹的措辞润色与真正避免了损害的修改区分开来。同时记录已审核的操作数量和全部符合抽检条件的操作总量。样本错误率应以实际审核的操作数为分母，随机样本与定向样本要分开统计；少量经审核的成功案例，不能证明整个系统可靠。

只看批准率并不够：审核人可能因为工作质量好而批准，也可能因为材料没有提供有效信息，或队列压力太大而放行。应定期检查审核决定本身。人的参与提供了发现错误的机会，却不保证一定能发现。

哪些说法被夸大了？

在弄清审核人能看到什么、能阻止什么之前，“有人在回路里”只是一句不完整的说法。 退款已经发生后才收到通知的人，做的是监督，不是执行前审批。

“先让所有操作都走审批，等信任建立后再放开”，也不完整。缺少明确标准，流程就容易让人疲劳，最后只是因为等不及而扩大权限。信任应来自针对具体操作的证据，以及可靠的恢复能力。

此外，人工反馈本身不会自动改进系统。必须有人把纠正意见转化为更好的源数据、更清晰的规则、修订后的提示词，或经过评测的模型变更。指定人工审核机制的负责人时，也要把这部分工作算进去。

下个工作日就能开始做什么？

运营负责人应盘点智能体能执行的操作，为每一类安排审核位置。 可以从前面的客服表格入手，确定真正有权审批的人，并确认在承诺提供服务的时段内，始终有人负责审核队列。

开发者应在执行环节强制落实规则。 保存待执行操作，把批准决定绑定到对应版本，并验证拒绝、过期、重复决定和参数变化时，系统行为是否正确。模型不能拥有给自己批准的能力。

创始人和采购方应要求演示：操作被拒绝后会怎样，审核无人处理直到超时又会怎样。 这些场景能看出系统是否具备实际的运行控制，还是仅仅会发送审批通知。

如果智能体已经能在没有明确边界的情况下发送消息、转移资金或修改客户数据，就应马上采取行动。如果政策或审核人手尚未落实，先不要继续扩大自主权限。一个无法对外执行操作、只负责内部起草的助手，可能只需要常规编辑审核，而不必新建审批系统。

关于人工审核的常见问题

AI 中的 Human in the Loop 是什么？

指人通过审核、反馈或决策，参与 AI 系统的运行。对于承担业务工作的智能体，需要明确人是在执行前审批、事后抽检，还是处理异常。

“人在回路”具体意味着什么？

意味着把人的判断明确纳入流程。有效的实现应说明谁来审核、负责什么决策、能看到哪些证据，以及系统等待期间会做什么。

Human in the Loop 就是智能体 AI 吗？

它可以用于智能体 AI，但两者不是同一个概念。智能体负责选择步骤、调用工具；Human in the Loop 描述人在哪些环节影响或授权这些工作。

怎样让 AI 工作流始终保留人的参与？

在影响重大的工具调用前设置审批关卡，为升级路径安排人员，并按事先规定的抽样方式审核符合条件的已完成工作。记录决策及结果，再依据各类操作的证据调整权限。

为什么 AI 会陷入循环？

在智能体工作流中，反复重试、重复选择工具，或未完成的交接，都可能让任务无法推进。应设置停止条件，并指定升级处理负责人。这类故障循环，与本文讨论的有意设计的人工审核回路不同。

想了解把 AI 接入业务工作流的实用方法，欢迎订阅邮件简报。