什么是 人在回路（Human-in-the-Loop）？
人在回路（Human-in-the-Loop）是一种控制模式：AI 系统在明确决策点暂停，由经过认证和授权的人在继续执行前复核、批准、拒绝、编辑、升级或终止拟议工作。
快速了解
| 规范文档 | 官方规范 |
|---|
工作原理
人在回路（Human-in-the-Loop，HITL）不是在 Prompt 中要求模型征求许可，也不是笼统宣称事后有人可以看日志。它是 Proposal 与 Consequence 之间受强制执行的控制路径。Runtime 或下游服务决定何时必须 Review，模型不能自行豁免。Human-on-the-Loop 监控、事后 Audit 与 Dataset Labeling 也是有价值的人工控制，但不等于执行前门禁。
Interrupt、Approval 与 Authorization 必须分开。Interrupt 持久化 Run 并暴露 Pending Item；Approval 记录某个人针对一个具体 Proposal 的决定；Authorization 校验 Actor、Approver、Tenant、Resource、Operation 与当前 Policy 是否允许执行。Approval 是授权证据之一，不替代授权；下游服务仍需强制 Ownership 与 Least Privilege。
Durable Approval Envelope 应绑定 approval_id、run_id、call_id、Actor、已认证 Approver、Reviewer Role、Tenant、Resource、精确 Tool / Schema Version、Argument Digest、Policy Version、Decision、Rationale 或 Edit、Issue Time、Expiry 与 Single-use State。UI 应展示准确 Target、关键参数 Diff、预期外部 Effect、Evidence、Uncertainty、Reversibility 与 Alternative，同时隐藏 Secret 和隐式思维链。笼统的“批准这个 Agent”按钮范围过大。
Review Response 包括 Approve、Reject、Edit、Request Clarification、Escalate 与 Cancel。编辑参数会生成新 Proposal 和 Digest，必须重新通过 Schema、Policy 和必要审批。Reject 应进入 Terminal State 或显式路由，不能让模型无限改写同一请求。过期、重复、越权、不匹配或已消费的 Decision 应 Fail Closed。
长期 Review 需要 Durable Checkpoint 和独立于单个进程或浏览器 Session 的 Pending-approval Store。恢复同一个兼容 Run，并在执行前根据当前 Resource State、Policy Revision、Tool Schema、Approver Authority 与 Expiry 重新校验 Proposal。框架 Replay 可能重新执行 Interrupt 前的代码，因此此前不得发生副作用，或副作用必须幂等。审批后派发超时属于 Effect Journal 问题，不能再次请求审批后盲目执行。
Gate 应按 Action-level Risk 选择，而不是按 Agent 标签或未经校准的模型置信度选择。考虑 Impact、Reversibility、Data Sensitivity、Delegated Authority、Uncertainty、Novelty 与 Policy。低风险 Read 可以使用确定性控制；高后果 Write 常需要审批或 Separation of Duties。人工复核不能修复 Excessive Permission、Unsafe Tool、Prompt Injection 或缺少下游授权，因此还要组合 Narrow Capability、Isolation、Budget、Validation 与 Complete Mediation。
不要只统计 Approval Rate。测试 Bypass Attempt、Cross-tenant Reviewer、Changed Argument、Stale Policy / Schema、Expiry、Replay、Concurrent Decision、Cancellation、Reviewer Unavailability，以及执行前后 Crash。跟踪 Gate Coverage、False Allow / False Block、Disagreement、Edit / Escalation Rate、Queue Age、P50 / P95 Decision Latency、Abandoned Item、Override Outcome、Incident 与 Reviewer Load。可以用确定性 Policy 减少低价值重复提示，但不能仅因复核人通常点击批准就自动化高风险类别。
主要特点
- 在明确后果发生前强制暂停，不依赖模型主动配合
- 复核人身份经过认证，并分离 Interrupt、Approval 与 Authorization
- 决定绑定 Actor、Resource、Argument、Schema、Policy、Expiry 与单次消费状态
- Pending State 可跨进程丢失持久化，并恢复同一个兼容 Run
- 支持批准、拒绝、编辑、澄清、升级、取消与紧急停止路径
- 度量覆盖率、决策质量、延迟、疲劳、绕过与事故
常见用途
- 审批退款、付款、账户变更、部署、合并、删除或外部消息
- 合同或发票抽取字段进入权威系统前由人工纠正
- 把新颖、模糊、高影响或策略敏感案例升级给领域专家
- 暂停长期 Agent Run，并在异步复核后恢复
- 对高权限操作分离请求者权限与独立复核人
- 沉淀已复核评测样本，但不默认把批准当成训练标签
示例
Loading code...常见问题
Human-in-the-Loop 等于让模型询问确认吗？
不等于。Prompt 可能被忽略或操纵。真正的门禁由可信 Runtime 或下游代码强制执行，在收到有效 Decision 前阻止敏感操作。
人工审批可以替代授权吗？
不能。Approval 记录复核决定；执行时仍须校验 Actor、Approver Authority、Tenant、Resource Ownership、当前 Policy、准确参数与最小权限凭证。
复核人编辑 Tool Call 后应如何处理？
编辑会生成新 Proposal 与 Argument Digest。重新校验 Schema 与业务规则，重新执行 Policy；若变化后的操作仍需审批，则必须获得新 Approval，不能复用旧决定。
延迟审批应如何恢复？
持久化 Run 与 Pending Approval Envelope，认证复核人，再恢复同一个兼容 Run。执行前重新检查 Expiry、Single-use State、Policy / Schema Version、Resource State 与 Approver Authority。
如何评测 Human-in-the-Loop 系统？
测试绕过、过期或重放审批、参数变化、越权复核人、超时、并发决定、崩溃与取消；度量覆盖率、误放行、误阻断、延迟、编辑、升级、放弃、疲劳与事故。