人在回路，英文常写作 human-in-the-loop，缩写 HITL，在企业 AI Agent 平台里指的是一种把人的判断嵌入任务执行链路的机制。Agent 读取信息、生成方案后，遇到预设的高风险动作或不确定情形会暂停，把待执行的动作、依据和影响交给有权限的人确认、修改或拒绝，得到结果后再继续。它约束的是一类具体动作的授权，确认框只是界面表现之一。
用一个报销场景可以看清这条回路。Agent 收到一笔 1.2 万元的报销申请，核对发票、预算科目和供应商信息后，发现金额超过部门阈值，于是暂停付款，把发票、预算余额、制度条款、收款账户和风险提示一起推给财务负责人。负责人确认无误后批准，Agent 才执行付款并把审批记录写回任务。负责人如果发现发票抬头不对，可以直接修改参数或退回补充材料，任务不会带着错误继续往下跑。
人在回路是什么？
把一条回路拆开，至少包含四个动作。Agent 在某个节点停下；平台把当时的任务状态、待执行动作和判断依据保存下来；有权限的人做出批准、拒绝、修改或升级的决定；平台根据这个决定恢复执行、回滚或终止任务。四个动作里缺一个，人在回路就容易变成一句口号。一条可用的回路，至少要有暂停、保存现场、人工决策、恢复或终止四个动作。
它和普通的弹窗确认有区别。弹窗只解决“点一下同意”，不解决谁来批、批的是什么、批完能不能恢复、出了问题能不能查。企业级平台要把审批做成任务状态机里的一段，记录任务当前走到哪一步、下一步能做什么，并且能持久化、能分派、能超时处理、能留痕。Oracle 的 Human Task 文档就把人工任务描述为：工作流停在人工节点，授权用户查看执行细节和 AI 输出后批准或拒绝，工作流再继续。审批属于流程状态的一部分，不会只作为结果旁边的一行提示。
它和人工客服也有区别。人工客服通常是在 Agent 答不上来之后接管对话，人在回路是在动作生效之前设置控制点。前者处理服务体验，后者处理授权和责任。
行业里还会提到人在环上，英文写作 human-on-the-loop。人在环上允许 Agent 先自主运行，人通过看板、告警和抽样监控，必要时介入、覆盖或叫停。人在回路则要求人在指定动作生效前成为链路的一环。两者可以同时存在：低风险动作让人在环上监控，高风险动作让人在回路里签字。
为什么企业 Agent 需要人在回路
生成式 AI 的第一阶段，风险主要是“说错了”。Agent 进入业务系统后，风险变成“做错了”。它可能修改客户记录、发送对外邮件、批量触达用户、删除数据、提交付款、变更权限，甚至调用第三方工具。动作一旦发生，撤回成本往往比生成一段错误文字高得多。Agent 的风险从“说错了”扩展到“做错了”，审批要落在工具调用之前。
提示词可以写规则，但没有强制执行力。长上下文、多轮任务、工具返回内容和外部网页都可能稀释最初的指令，提示词注入也可能诱导 Agent 绕过限制。把审批要求写进提示词，适合做第一层提醒；控制要落在工具调用之前，由平台校验权限、动作类型和审批状态。Cloudflare 的 HITL 文档把审批放在工具调用、持久化工作流和连接器调用等不同层，说明这类控制需要在系统层实现，不能只靠模型自觉。这类风险可以对照 Agent 越权治理清单逐项排查。
如果 Agent 进入金融、医疗、政务等高风险场景，人工监督还可能成为合规要求。欧盟《人工智能法案》第14条要求高风险 AI 系统在设计上支持自然人有效监督，监督措施要与风险、自主程度和使用场景相匹配。被指派的监督人员要能理解系统的能力和局限，能监视运行，能在具体情况下不采用、推翻或逆转输出，并能中断系统。这里说的是“有效监督”，只在流程末尾放一个同意按钮，很难满足这个标准。
从管理角度看，人在回路还解决责任归属。谁批准了这笔付款，谁确认了这条对外文案，谁允许了这次权限变更，记录要能对应到具体的人、具体的时间点和当时看到的数据。没有这层记录，出了问题只能追溯到“系统”，组织很难接手。
平台里的回路怎么运行
企业级平台通常把人在回路拆成六个动作。
- 触发。平台按动作类型、金额、数据敏感度、外部影响、模型置信度和例外情况判断是否需要人。
- 暂停并保存现场。平台把任务状态、待执行动作、参数、数据快照、来源和影响写入一条待审批记录。这里要用持久化状态，不能用挂起的 HTTP 请求等人，否则用户离开页面、网关超时或任务重试都可能让同一个动作被提交两次。
- 分派。平台按角色、权限、金额阈值和组织架构找到审批人。付款、删除、权限变更等敏感动作可以要求双人复核，避免一个人既发起又放行。
- 呈现。审批人看到动作、参数、依据、影响范围和可选方案。只给一个“是否同意”，人很难判断，最后只能凭感觉点。
- 决策。审批人可以批准、拒绝、修改参数、要求补充信息或升级给更高权限的人。修改后的参数要重新校验，不能沿用旧快照直接执行。
- 恢复或回滚。批准后从断点继续；拒绝后终止任务，必要时走补偿或回滚；全过程写入审计日志。
图：人在回路的关键阶段，审计记录贯穿全过程。
不同业务适合不同的审批形态，代价也不一样。
| 形态 | 适用场景 | 主要代价 |
|---|---|---|
| 同步确认 | 秒级可决策，发起人就是审批人 | 等待期间任务不能推进，占用会话 |
| 异步审批 | 审批人是另一个角色，可能几小时后处理 | 需要状态持久化、通知、超时和升级机制 |
| 事后复核 | 不可阻断的低延迟链路 | 动作已经发生，依赖补偿能力 |
Oracle 的 Human Task 采用异步思路：工作流暂停，生成通知，授权用户查看执行细节和 AI 输出后批准或拒绝，工作流再恢复。Cloudflare 的文档强调待审批状态要能跨请求完成和休眠保留，同时处理超时、审计、连接中断和拒绝后的降级。这些工程细节决定了回路能不能在生产环境里跑住。企业级智能体平台的人在回路能力，差异主要体现在这些工程细节上。
哪些动作该进审批
人在回路的关键判断是动作级授权。同一个 Agent 可以自动做只读查询，也可以在被允许的范围内打标签、写备注，但涉及资金、对外发送、删除和权限变更时，要停下来等人。给整个 Agent 设一个统一的自主等级，往往会得到两种坏结果：管得太死，Agent 省不了多少时间；放得太开，风险留到事故后才发现。人在回路按动作设置，不按 Agent 整体设置。
| 动作类型 | 默认策略 | 判断依据 |
|---|---|---|
| 只读查询、检索、生成草稿 | 自动执行 | 不改变外部状态，出错可以撤回 |
| 低价值、可逆写入，例如打标签、更新备注 | 自动执行或抽样复核 | 影响有限，抽样能发现系统性问题 |
| 对外发送、批量触达、修改生产数据 | 事前审批或双人复核 | 影响客户、数据或生产环境，撤回成本高 |
| 付款、退款、删除、权限变更 | 必须事前审批 | 涉及资金、隐私和安全，后果不可逆或难逆 |
| 低置信度、异常、策略例外 | 转人工 | 模型没有足够依据，继续执行风险高 |
这张表只提供默认判断，不同行业和企业的阈值要自己定。金融、医疗、政务可以把门槛设得更严，内部知识检索和报表生成可以放得更宽。判断时看四个问题：动作能不能撤回，是否涉及资金或他人权益，是否改变外部系统状态，是否触碰敏感数据。命中越多，越应该进审批。
全审批会带来审批疲劳。一个人每天批几十条相似的请求，很快会形成“看到就点同意”的习惯，审批记录有了，控制效果却没多少。更可行的做法是分层：高风险动作逐笔审批，低风险动作抽样复核，重复出现的同类请求可以批量呈现，但批量批准要保留抽样和异常标记。
审批节点怎么设计
人在回路属于 Agent 安全与治理的一部分，要和权限、工具调用控制、日志审计一起设计。审批节点可以按五个问题展开。审批节点要回答五个问题：什么时候停、人看到什么、谁来批、等不到人怎么办、事后怎么复盘。
1. 什么时候停
触发条件要写成可执行的规则，不能只写“高风险动作须审批”。规则可以按工具、动作、金额、数据范围、对外影响、置信度和时间窗口组合。比如付款金额超过 5000 元、对外发送超过 1000 人、删除生产数据、变更管理员权限，分别触发不同审批。规则要能版本化，改了什么、什么时候生效、影响了哪些任务，都要能查。
2. 人看到什么
审批界面要回答五个问题：Agent 要做什么，用什么参数做，依据是什么，影响谁，有没有替代方案。数据快照要不可变，审批人点同意时执行的必须是当时看到的那份数据。如果恢复时重新读库，审批人批的是 A，系统执行的是 B，回路就失效了。
3. 谁来批
审批人要具备相应权限和业务知识。金额、风险等级和岗位要匹配，关键动作可以要求双人复核或职责分离。审批权限还要能收回，人员调岗、离职或项目结束后，旧权限不能继续生效。
4. 等不到人怎么办
超时要有明确默认动作。付款、删除、权限变更这类高风险动作，超时默认拒绝或升级；低风险动作可以设置提醒后自动通过，但要写清条件和上限。最怕的是超时分支没有定义，任务抛异常，动作却已经执行了一半。
5. 怎么复盘
把审批数据当成运营数据看。审批通过率、修改率、拒绝率、平均等待时长、超时率、复审后发现问题的比例，都能说明阈值是否合理。如果某个节点的通过率长期接近 100%，可能说明审批太松或审批人没有认真看；如果等待时间过长，说明分派或权限设计有问题。定期抽样复核，比只看审批数量更有用。
选平台时看什么
选企业 AI Agent 平台时，人在回路不能只看演示里有没有“同意”按钮。可以用五个问题做验收。能在工具调用前暂停并从断点恢复，是比界面上的同意按钮更硬的指标。
- 能不能在工具调用前暂停，并从断点恢复？暂停的是任务，还是只弹了一个提示？
- 待审批状态是否持久化，审批人看到的数据快照是否不可变？
- 平台是否提供统一的 Agent 管理，能按角色、金额、动作类型和数据范围配置审批策略？是否支持双人复核和职责分离？
- 是否记录完整审计链，能关联到具体任务、模型、工具、参数和审批人？
- 是否支持细粒度权限和私有化部署，满足企业的数据主权与合规要求？
以 ThinkingAI 为例，企业级 AI Agent 平台 Agentic Engine 把权限控制、执行审计和运行观测放在平台治理层，支持私有化部署。选型时仍要拿自己的高风险动作清单做一次实测，确认这些能力能落到具体审批节点。
常见问题
人在回路和人工审核有什么区别？
人在回路把人的决定嵌入任务执行链路，审批结果会直接影响任务继续、修改还是终止。人工审核可以是事后的批量检查，和具体任务的执行状态不一定绑定。实际项目里两者常常一起用，事前审批管高风险动作，事后审核管抽样和质量改进。
人在回路会拖慢 Agent 吗？
会占用等待时间，但只针对被规则拦下的动作。读操作、草稿生成和低风险写入可以自动通过，高风险动作走异步审批，等待期间 Agent 可以处理其他任务。把所有动作都设成人工确认，速度一定会下降，审批质量也会下降。
所有 Agent 都需要人在回路吗？
不需要。只读查询、内部检索、草稿生成等低风险任务可以自动执行。涉及资金、对外发送、删除、权限变更、敏感数据或监管要求的任务，更适合设置人工节点。判断依据是动作风险，与 Agent 的数量或名字无关。
人在回路能保证 Agent 不出错吗？
不能保证。它降低的是高风险动作直接生效的概率，效果取决于触发规则、审批人看到的信息、审批人的判断和回滚能力。规则设计得粗、上下文给得少、审批人疲劳，都会让回路失效。它需要和权限控制、工具沙箱、日志审计、异常监控一起工作。
监管是否强制要求人在回路？
要看行业、司法辖区和系统风险等级。欧盟《人工智能法案》第14条对高风险 AI 系统提出人工监督要求，要求监督措施与风险、自主程度和使用场景匹配。它没有要求所有 AI Agent 的每一个动作都经过人工确认。金融、医疗、政务等行业还有各自的监管规则，落地前要让法务和合规团队一起确认。
参考资料
- 欧盟《人工智能法案》第14条，Human Oversight，https://artificialintelligenceact.eu/article/14/
- Oracle，MicroTx Workflows User's Guide，Human Task，https://docs.oracle.com/en/database/oracle/transaction-manager-for-microservices/26.1/aiwfg/human-task.html
- Cloudflare，Agents 文档，Human-in-the-loop patterns，https://developers.cloudflare.com/agents/concepts/agentic-patterns/human-in-the-loop/
- 阿里云开发者社区，《人机协同新范式：人在回路的 Human-in-the-loop 设计》，https://developer.aliyun.com/article/1762485
