huaAgentStudyAgent

外观

zmh.life

H6 · 如何让人类参与、监督和干预 Agent 执行？ - Human-in-the-Loop ​

所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：03 · 如何让 Agent System 稳定、安全、可控地运行？ - Engineering & Governance
文档类型：人机协作控制、审批契约与运行时干预专题研究
版本：v1.1
更新日期：2026 年 10 月 29 日
核心问题：当 Agent System 可以长时间自主执行、调用外部工具并组织多个 Agent 协作时，如何在正确的时机将决策权交还人类，使人能够理解、审批、纠正、接管和终止任务，同时确保授权真实有效、执行状态一致、外部副作用可控？

专题导读 ​

本篇属 Engineering & Governance。Human-in-the-Loop（HITL）经常被简化为“执行前弹出一个确认按钮”。在实际 Agent System 中，人类可能在任务开始前设定目标和权限，在运行中补充信息、审核中间结果、授权敏感工具，在异常时接管或终止执行，在结束后对产物进行验收。一次人工操作还会跨越 UI、API、工作流调度、状态存储、权限策略和工具执行器；只要其中任一环节处理不当，就可能出现重复审批、过期授权、审批后参数被篡改、暂停后继续执行等问题。

本文以“技术研究报告 Studio”为贯穿案例：选题 Agent、调研 Agent、分析 Agent、审核 Agent 和发布 Agent 共同生成研究报告。用户需要批准选题、审阅证据、修改报告，并决定是否发布。研究重点不是按钮设计，而是人类决策如何成为系统可验证、可恢复、可审计的执行约束。

本文聚焦 H6 横向治理机制。L4 Agent Engine 负责单次 Run 的暂停和继续执行；L5 Orchestration & Collaboration 负责跨 Agent 的任务依赖和人工节点编排；L6 Application 提供交互界面与 API；H2 Security 负责身份与权限执行；H4 State Management 保证状态持久化和恢复；H5 Configuration 管理审批策略及版本；H12 Policy & Governance 定义组织级治理规则。H6 负责将上述能力组织为有效的人机控制闭环。

阅读目标： 能设计人工介入的触发策略、审批对象与状态机、运行时恢复协议、越权和竞态防护、人工接管流程，以及可执行的验证与验收方案。

一、概念、目标与适用边界 ​

1.1 Human-in-the-Loop 的严格定义 ​

在 Agent System 中，HITL 是指：系统在预定义或动态识别的决策点，将某项决策、信息补充、行为授权或执行控制交由具备相应权限的人类主体完成，并将该决定作为后续执行的可验证输入或约束。

该定义包含五个必要条件：触发条件明确；决策对象确定；决策主体具备权限；执行约束可以被技术机制强制落实；决定与结果可追踪。缺少任一条件，可能只有“人类看到了界面”，而没有形成有效的 HITL 控制。

HITL 与以下概念相关，但不应混为一谈：

概念人的参与方式典型用途
Human-in-the-Loop人必须在指定节点作出决定发布审批、敏感工具授权
Human-on-the-Loop人持续监督，可主动干预运行监控、异常接管
Human-out-of-the-Loop在既定边界内自主执行低风险重复任务
Human-in-Command人决定目标、授权范围与终止权组织级控制与问责

这不是绝对互斥的系统分类：同一个研究 Studio 可以在资料检索时自主运行，在发布前要求人工审批，在整个过程中允许用户取消任务。

1.2 四类目标 ​

控制（Control）： 人能够决定系统是否可以执行某项动作，以及何时停止。纠错（Correction）： 人能够修订目标、输入和中间结果，而不必丢失整个执行历史。问责（Accountability）： 能明确谁在何时依据何种信息批准了哪个具体动作。效率（Efficiency）： 只在风险、歧义或质量要求需要时介入，避免将所有低风险步骤都转交人类。

人工审批本身不保证安全或质量。人可能误判、疲劳、忽略上下文，也可能在权限不足的情况下尝试批准。HITL 的价值取决于审批信息的完整性、可理解性、权限约束与执行后核验，而不取决于确认按钮的数量。

1.3 适用边界 ​

适合人工介入的典型场景包括不可逆或高影响外部动作、敏感数据外发、重要资源支出、目标歧义、关键证据冲突、质量门禁失败、任务长时间停滞及合规要求。对于可逆、低风险、重复频繁且规则清晰的操作，可以采用自动化与事后抽样监督。

重要限制： 人类批准不应成为绕过系统硬性安全策略的万能通行证。例如，未经授权的数据访问、违反组织政策的外发操作、超出工具本身权限的动作，即使用户点击“同意”，也不应被执行。

二、参与者、职责与控制权限 ​

2.1 谁可以作出决定？ ​

至少区分四类主体：任务发起者（Requester）、业务审批者（Approver）、系统操作者（Operator）和安全/合规管理员（Security Reviewer）。同一人可能兼任多个角色，但角色不能天然互相替代。研究 Studio 中，用户可以批准选题，主编可以批准报告内容，拥有发布权限的负责人才能批准对外发布；运维人员可以暂停异常任务，却未必有权代表业务方批准发布。

系统需要同时判断主体身份、角色、资源归属、审批动作、当前任务状态、环境和风险级别。不能仅凭“用户已登录”判断其拥有所有审批权。

2.2 人类决策的七种动作 ​

动作含义后续处理
Approve同意指定操作验证授权后继续
Reject拒绝操作终止分支或返工
Request Changes要求修改生成有约束的返工任务
Clarify补充事实或意图更新输入后继续
Edit修改中间产物保存新版本并重新校验
Take Over人工接管撤销自动执行权限或暂停
Cancel取消任务停止后续调度并核验副作用

“驳回”和“要求修改”应分别建模：前者可能使任务进入终态，后者则应带有返工范围、验收标准和最大迭代次数。人工编辑也不应静默覆盖 Agent 原始产物；建议生成新版本并保留差异及责任归属。

2.3 职责分离与双人审批 ​

当单个错误可能造成重大影响时，可要求提交者与审批者不同、审批者与执行者不同，或要求双人复核。实现时需要明确：审批人数、角色组合、先后顺序、有效期、撤销规则、审批者离职/失权后的处理。双人审批不是两个按钮，而是由系统校验两个独立且有效的授权证明。

三、介入时机与风险驱动策略 ​

3.1 六个介入时点 ​

  1. 任务前（Pre-run）： 确认目标、约束、可用工具、预算及外发范围。
  2. 决策前（Pre-decision）： 对存在歧义或高影响的选择请求人工判断。
  3. 动作前（Pre-action）： 对特定工具调用及其参数执行授权检查。
  4. 执行中（In-flight）： 观察进展、修改优先级、暂停或接管。
  5. 产物前（Pre-release）： 审核报告、代码、邮件或发布物。
  6. 执行后（Post-action）： 复核实际结果、处理异常并形成反馈。

其中，动作前审批最接近强制控制点。执行后审核可用于质量改进，却无法代替不可逆动作的事前授权。

3.2 风险分级不应只看工具名称 ​

同一工具可能具有不同风险。例如 send_email 向本人发送测试邮件与向上千名外部收件人发送含敏感数据的邮件，风险显著不同。审批决策至少考虑：操作类型、资源范围、数据敏感度、外部可见性、可逆性、成本、执行环境、目标对象及当前权限。

建议采用硬性策略 + 风险评分 + 人工复核的分层机制。硬性拒绝规则优先于审批；可自动执行的低风险动作无需打断；中高风险动作进入审批；极高风险动作可要求双人审批或直接禁止。风险评分仅用于辅助决策，不能替代授权规则。

3.3 介入过度与审批疲劳 ​

如果每个检索、每次模型调用都要求人工确认，系统吞吐会下降，审批者也容易机械点击。可采用动作聚合、明确边界的批量授权、预算额度、可信工具白名单和事后抽样，但必须为授权范围设置对象、动作、次数、有效期与最大成本等约束。不能将一次“允许检索”扩展解释为“允许任意外发”。

四、核心数据模型与审批契约 ​

4.1 为什么审批必须绑定具体动作 ​

一个容易被忽视的竞态是：系统展示了工具调用 A 的参数，用户批准后，Agent 又生成了参数 B；如果执行器只检查“该 Run 已审批”，就可能执行未经批准的 B。正确做法是将授权绑定到规范化动作内容的摘要，并在执行前重新校验。

最小审批对象建议包含：

json
{
  "approval_id": "appr_018",
  "tenant_id": "tenant_demo",
  "task_id": "task_042",
  "run_id": "run_007",
  "step_id": "step_012",
  "action_id": "act_009",
  "action_type": "publish_report",
  "action_digest": "sha256:<canonical-action-hash>",
  "artifact_version": 7,
  "policy_version": "policy-2026-10",
  "required_role": "publisher",
  "status": "PENDING",
  "expires_at": "2026-10-30T10:00:00Z",
  "created_at": "2026-10-29T10:00:00Z"
}

这只是示意性数据契约，不是某个框架的官方 schema。实际系统应根据敏感度对审批对象采用数据库访问控制、签名或消息认证码，并避免在通知渠道暴露完整敏感参数。

4.2 决策记录与证据 ​

json
{
  "approval_id": "appr_018",
  "decision_id": "decision_003",
  "decision": "APPROVED",
  "actor_id": "user_021",
  "actor_role": "publisher",
  "reason": "报告已通过事实核验",
  "action_digest": "sha256:<canonical-action-hash>",
  "decided_at": "2026-10-29T10:05:00Z",
  "request_version": 3,
  "auth_context_id": "authctx_abc"
}

审计记录应能够回答：审批人看到了什么、批准了什么、当时具有何种权限、审批对应哪个产物版本、执行器最终执行了什么，以及执行结果如何。审批记录不等于外部执行成功证明；后者需要工具回执或业务系统状态核验。

4.3 授权的范围、有效期与撤销 ​

建议将授权约束建模为 (principal, action, resource, context, constraints, expiry)。一次审批原则上只覆盖一个确定动作，除非明确使用批量授权协议。若审批后工具参数、目标资源、产物版本、权限或策略发生实质变化，应使旧授权失效或重新审批。

撤销并不保证已提交到外部系统的动作能够撤回。因此要区分“尚未执行的授权撤销”和“已发生副作用的补救流程”。

五、审批状态机与一致性 ​

5.1 建议的状态集合 ​

text
CREATED
  → PENDING
  → APPROVED / REJECTED / EXPIRED / CANCELLED
APPROVED
  → CONSUMED / REVOKED / EXPIRED
CONSUMED
  → EXECUTING → SUCCEEDED / FAILED / UNKNOWN

这里将审批状态与动作执行状态分离。批准不等于消费授权，消费授权不等于外部执行成功。状态名可按系统实际契约调整，但必须保持语义明确。

5.2 核心状态不变量 ​

  • 只有具备相应权限的主体可以完成决策；身份与角色在提交时重新校验。
  • 同一个审批请求只能接受一次有效终局决策；重复提交返回既有结果或冲突。
  • 执行动作必须与审批的动作摘要、资源版本和策略条件一致。
  • 已过期、被撤销、被拒绝的授权不能被消费。
  • 同一授权不能被两个并发 Worker 同时消费；需要原子条件更新。
  • Run 被取消或冻结时，不能继续消费待执行授权。
  • 所有关键状态转移产生持久化事件与审计证据。

5.3 数据库事务边界 ​

审批提交一般应在同一数据库事务内完成：验证当前状态与版本、检查权限、写入决策、更新审批状态、写入待投递事件（Outbox）。事务提交后由工作流 Worker 接收事件并尝试恢复。不要先向队列发“已批准”，再异步写数据库，否则可能发生事件已投递但授权未落库的竞态。

5.4 幂等与重复提交 ​

用户可能双击按钮，浏览器可能重试，Webhook 可能重复投递。审批 API 应接受幂等键或以 approval_id + expected_version 进行条件更新。对同一审批请求的相同重复决策可返回原结果；对冲突决策返回明确的版本冲突，不应后写覆盖先写。

六、暂停、恢复、取消与人工接管 ​

6.1 “等待审批”是持久化状态，不是线程阻塞 ​

长时间运行的 Agent 不应通过在内存中阻塞线程等待用户点击来实现 HITL。正确做法是将 Run 保存为 WAITING_FOR_HUMAN，持久化 Checkpoint、审批请求和待恢复位置，释放计算资源。人类提交决策后，系统通过持久化事件唤醒工作流，再验证当前状态与授权后继续执行。

典型流程：

text
Agent proposes action
    ↓
Policy evaluates risk
    ↓
Approval request persisted + Run checkpointed
    ↓
Run → WAITING_FOR_HUMAN
    ↓
UI / notification displays immutable action summary
    ↓
Authorized human submits decision
    ↓
Decision validated + committed
    ↓
Workflow resumed with decision event
    ↓
Engine revalidates action and policy
    ↓
Tool executor consumes authorization and executes
    ↓
Result reconciled + audit emitted

6.2 取消的边界 ​

取消请求通常先进入 CANCELLING，再由调度器停止新步骤、向可取消工具发送取消信号，并核对已经提交的外部操作。对于正在执行的外部 API，客户端停止等待并不等于外部动作已停止；最终应区分 CANCELLED_NO_EFFECT、CANCELLED_PARTIAL_EFFECT 或 UNKNOWN 等业务可解释结果，必要时触发人工补救。

6.3 人工接管协议 ​

人工接管至少包括：暂停自动调度、冻结或收回相关执行租约、保存当前状态、向接管人展示上下文和未确认副作用、明确人工操作权限、记录修改与决定、设定是否允许 Agent 重新接管。若使用分布式 Worker，接管时需要考虑 Lease 与 Fencing Token，防止旧 Worker 在人工接管后继续写入。

6.4 恢复时重新检查什么？ ​

恢复时不能只检查“存在 APPROVED”。还要重新确认审批未过期、决策主体权限未被撤销、动作摘要未变化、Run 未取消、资源版本仍匹配、硬性策略未升级为禁止，以及工具的实际执行状态。尤其对于长时间等待的任务，模型配置、工具 schema、知识库内容和发布策略都可能已经变化。

七、界面与交互设计：让审批者理解后果 ​

7.1 最小审批信息集 ​

审批界面至少说明：任务目标、拟执行动作、影响对象、关键参数、使用的数据及其敏感度、可能的外部后果、不可逆性、风险原因、成本估计、证据链接、可选操作与截止时间。对报告发布，应显示报告版本、发布渠道、可见范围、主要修改差异及事实核验状态。

审批者不应需要阅读全部模型思考过程才能判断。更可靠的是呈现可验证的行动摘要、证据和预期影响。模型生成的解释可以辅助理解，但不应被当作独立的安全证明。

7.2 交互模式 ​

  • Inline Approval： 在聊天或任务流中直接批准，适用于低复杂度动作。
  • Review Workspace： 展示证据、差异、版本与风险，适用于报告、代码、发布物。
  • Batch Review： 批量处理同类低风险请求，但每项仍需独立记录授权范围。
  • Escalation Queue： 按角色、优先级和超时规则路由待审批事项。
  • Live Intervention： 人工实时暂停、接管和修改任务。

重要操作应避免模糊按钮，例如“继续”可能意味着继续生成、继续执行工具或继续发布。建议使用“批准发布第 7 版报告”等具体动作文案，并在服务端验证其实际含义。

7.3 审批通知不是授权本身 ​

邮件、IM、移动端推送可以通知审批请求，但通知中的链接和按钮不能仅凭可猜测的 ID 完成授权。应要求有效会话、资源级权限校验，必要时执行二次验证。审批内容在通知和最终执行之间必须保持一致，避免展示 A、执行 B。

八、多 Agent 协作中的人工控制 ​

8.1 人工节点在任务图中的位置 ​

在多 Agent DAG 中，人工审批可以是具有输入、输出和终态的节点。例如：选题生成 → 自动审核 → 人工确认选题 → 深度调研。人工节点未完成时，依赖该节点的下游任务不能启动；但不依赖该节点的其他分支可以继续，前提是没有跨分支的全局冻结要求。

8.2 委托链与权限传播 ​

Supervisor Agent 将任务委托给 Worker Agent，不意味着 Worker 自动继承 Supervisor 的全部外部操作权限。审批应绑定最终实际执行的动作、资源与执行主体。对外发布权限由可信授权系统授予，而不是由 Agent 消息“我已获得批准”来证明。

8.3 返工循环与终止条件 ​

人工提出修改意见后，系统应保存反馈版本、返工范围、验收标准、负责人和最大迭代次数。若连续多轮返工仍无法达标，应进入升级处理或终止，避免无限消耗预算。不同 Agent 对同一报告版本提出冲突修改时，需要明确最终裁决者和版本合并策略。

8.4 共享状态中的审批版本 ​

假设审核人批准报告 artifact_version=7，分析 Agent 随后写入第 8 版。原审批不能默认覆盖第 8 版。发布服务应校验 approved_artifact_version == current_publish_version；若不匹配，要求重新审批或经过明确的差异审批协议。

九、与安全、策略和治理的关系 ​

9.1 人工审批不是权限绕过 ​

H2 Security 提供身份认证、资源授权和可信执行边界；H12 Policy & Governance 决定哪些动作必须审批、哪些绝对禁止；H6 负责在具体任务中收集和执行人工决定。三者关系可表述为：Policy 决定规则，Security 强制边界，HITL 获取人类决策并将其转化为受控执行条件。

9.2 Prompt Injection 与伪造批准 ​

来自网页、PDF、检索结果或其他 Agent 的文本可能声称“用户已同意发布”“无需审批”。这些内容属于低信任数据，不得改变审批状态。只有通过可信审批 API、已认证的人类主体和服务端授权检查产生的决策事件，才可被执行器接受。不要让模型从自然语言对话中自行推断已获得高风险工具授权。

9.3 敏感审批信息与审计隐私 ​

审批记录可能包含个人信息、商业机密和访问凭据。建议最小化保存敏感正文，使用摘要与受控证据引用，按角色控制访问，并设置保留期限。审计证据需要具备完整性与可追溯性，但不意味着永久保存所有模型输入和用户数据；具体保留策略由 H9 Data Governance 负责。

十、参考架构与接口契约 ​

10.1 控制面与执行面 ​

text
┌────────────────── Application / L6 ──────────────────┐
│ Review UI · Inbox · Notification · Approval API     │
└──────────────────────────┬───────────────────────────┘
                           │ authenticated decision
┌──────────────────────────▼───────────────────────────┐
│ HITL Control Plane / H6                              │
│ Approval Service · Policy Decision · Role Check      │
│ Decision Store · Audit · Escalation · Timeout        │
└──────────────────────────┬───────────────────────────┘
                           │ durable event / outbox
┌──────────────────────────▼───────────────────────────┐
│ Runtime / L4 + Orchestration / L5                     │
│ Run Checkpoint · WAITING_FOR_HUMAN · Resume Worker   │
└──────────────────────────┬───────────────────────────┘
                           │ revalidate and consume
┌──────────────────────────▼───────────────────────────┐
│ Trusted Tool Executor / H2                           │
│ Action Digest · Permission · Idempotency · Receipt   │
└──────────────────────────────────────────────────────┘

这是一种逻辑分层，不要求部署成五个独立微服务。小规模系统可以将审批服务、状态机和执行器放在同一应用中，但仍应保持职责与数据契约独立。

10.2 建议 API ​

http
POST /v1/tasks/{task_id}/approvals
GET  /v1/approvals?status=PENDING
GET  /v1/approvals/{approval_id}
POST /v1/approvals/{approval_id}/decisions
POST /v1/runs/{run_id}/pause
POST /v1/runs/{run_id}/resume
POST /v1/runs/{run_id}/cancel
POST /v1/runs/{run_id}/takeover

接口是参考设计，并非通用标准。decisions 请求应包含 decision、expected_version、idempotency_key 和必要的意见字段；服务端从认证上下文解析操作者，不信任客户端自行传入的 actor_role。对审批创建接口，应限制为受信任的工作流服务或内部系统调用，避免任意客户端伪造审批请求。

10.3 决策提交伪代码 ​

python
# 设计伪代码：未针对具体数据库或权限框架执行验证。
def submit_decision(approval_id, decision, expected_version, auth_context):
    with database.transaction() as tx:
        approval = tx.lock_approval(approval_id)
        assert approval.version == expected_version
        assert approval.status == "PENDING"
        assert now() < approval.expires_at
        authorization.require(auth_context, approval.required_role,
                              approval.tenant_id, approval.action_type)
        policy.require_decision_allowed(approval, decision, auth_context)
        tx.insert_decision(approval, decision, auth_context.subject)
        tx.transition_approval(approval, decision)
        tx.insert_outbox("approval.decided", approval.id)
    return {"approval_id": approval_id, "decision": decision}

真实实现还需要处理重复请求、异常映射、数据库隔离级别、权限变更竞态、审计写入失败和事件投递重试。尤其要注意，审批提交时的授权校验与动作真正执行前的授权校验都不可省略。

十一、工程框架与实现选择 ​

11.1 LangGraph Interrupt ​

LangGraph 的 interrupt 机制支持在图执行中暂停并通过持久化 Checkpointer 保存可恢复状态，随后使用恢复输入继续执行。其工程重点在于：恢复语义、线程标识、节点重放、持久化后端和副作用隔离。由于恢复可能重新执行部分节点代码，不能把不可幂等的外部动作随意放在中断前后而不做保护。具体 API 与行为应以所用版本的官方文档为准。[R1]

11.2 Temporal Workflow ​

Temporal 提供持久化工作流执行模型，可使用 Signal/Update 等机制接收外部决策，再让 Workflow 按确定性规则推进。人工等待可以是持久化工作流状态，而非占用工作线程。工程上仍需自行实现审批权限、动作摘要、策略检查和业务审计；Temporal 的持久化执行能力不自动等于业务审批合规。[R2]

11.3 OpenAI Agents SDK ​

OpenAI Agents SDK 文档提供 HITL 相关的执行中断、审批与恢复模式，可用于工具审批流程。实际采用时需核实所用 SDK 版本的接口、运行状态持久化方式、工具批准范围和恢复机制，不能把 SDK 的批准对象直接视为完整组织级授权系统。[R3]

11.4 自建 HITL 控制面 ​

对于多租户、强审计、双人审批、细粒度权限、跨框架 Agent 和长期运行任务，自建统一审批服务通常更有利于形成一致契约。可采用关系数据库保存审批与决策、Outbox 保证事件交付、工作流引擎负责等待与恢复、策略引擎负责授权规则。代价是需要自行承担协议维护、权限正确性和分布式一致性测试。

方案强项需要补足
LangGraph Interrupt图节点暂停与恢复组织级审批与审计
Temporal持久化等待与工作流恢复业务授权与审批 UI
Agents SDK HITLAgent 工具审批集成跨系统审批控制面
自建审批服务统一权限、审计和策略开发维护与可靠性

十二、贯穿案例：技术研究报告 Studio ​

12.1 业务流程 ​

text
用户提交研究需求
   ↓
选题 Agent 生成候选题目
   ↓
审核 Agent 自动检查选题质量
   ↓
[人工确认选题]
   ├─ 批准 → 深度调研
   ├─ 修改 → 选题 Agent 返工
   └─ 拒绝 → 结束任务
   ↓
调研 Agent + 分析 Agent 协作
   ↓
证据冲突或外部高风险访问？
   ├─ 是 → [人工澄清 / 审批]
   └─ 否 → 继续
   ↓
审核 Agent 检查事实与引用
   ↓
[人工审核报告版本]
   ├─ 通过 → 待发布
   └─ 修改 → 返回相应 Agent
   ↓
[具备发布权限者批准发布]
   ↓
发布服务核验审批与产物版本
   ↓
执行发布并记录外部回执

12.2 三类审批请求的不同契约 ​

选题确认： 审批对象为 topic_proposal_version，决策允许批准、要求修改或拒绝。它主要是业务方向确认，不应自动赋予后续数据外发权限。

证据冲突澄清： 审批对象为冲突证据集与待解决问题。人类补充信息应保留来源类型和可信度，不能被系统静默标记为“已独立核验事实”。

报告发布： 审批对象为确定的 artifact_version、目标发布渠道、可见范围和摘要。执行前重新验证报告版本、发布权限、敏感数据策略和目标渠道；若发布服务返回超时，应查询发布状态而非盲目重试。

12.3 失败案例：审批后报告被改写 ​

  1. 审核人批准第 7 版报告。
  2. 分析 Agent 在审批等待期间写入第 8 版。
  3. 发布 Worker 收到“已批准”事件。
  4. 如果只检查 approval.status=APPROVED，第 8 版可能被错误发布。
  5. 正确处理：发布前比较 approved_artifact_version 与待发布版本；不一致则阻止发布并要求重新审批或差异审批。

这说明 HITL 必须与 H4 状态版本、H5 配置版本、H2 权限校验及 L6 产物交付协同设计。

十三、故障场景与恢复策略 ​

故障场景主要风险建议处理
审批超时Run 永久等待到期、升级或安全终止
重复点击重复决策幂等键与版本校验
两人同时审批决策冲突原子条件更新
审批人失权无效授权决策和执行时重验
产物版本变化批准对象漂移摘要与版本绑定
Worker 崩溃丢失恢复事件Outbox 与持久化状态
审批后策略升级旧授权越权执行前重新校验
工具超时副作用未知查询回执与状态核对
人工接管竞态旧 Worker 继续写入Lease 与 Fencing
通知链接泄露非授权审批身份认证与资源授权

13.1 超时策略 ​

审批超时默认不应自动批准高风险动作。可选择拒绝、继续等待、升级至上级审批者或安全终止；每种策略都应在创建审批时明确并记录。对于必须在期限内执行的任务，需要区分“业务超时”与“审批请求过期”，避免超时后重新投递旧授权。

13.2 外部动作的 UNKNOWN 状态 ​

若发布 API 返回超时，系统无法仅凭客户端错误判断是否已发布。应保存外部请求幂等键、查询发布渠道状态，并在无法确定时进入人工核验。不要让“人工已批准”成为重复发送的理由。

十四、可观测性、指标与运营 ​

14.1 关键事件 ​

建议记录 approval.requested、approval.viewed、approval.decided、approval.expired、approval.revoked、run.paused、run.resumed、run.taken_over、action.authorization_consumed 和 action.reconciled。事件至少携带租户、任务、Run、审批、动作、版本、时间及相关 Trace ID，但敏感字段应按数据分类策略处理。

14.2 指标 ​

指标说明注意事项
Approval Latency请求到有效决策的时间按风险与角色分组
Pending Queue Age待审批队列等待时长观察尾部延迟
Expiration Rate超时审批占比结合业务类型分析
Rework Rate审批后返工占比不能单独衡量质量
Override Rate人工修改自动决策占比需要区分纠错与偏好
Unsafe Execution Count未经有效授权的动作数应以零为目标
Resume Failure Rate审批后恢复失败占比关联状态和版本
Approval Fatigue Proxy高频、快速、批量批准比例仅作风险线索

审批速度越快不一定越好；对于高风险动作，过快批准可能反映信息展示不足或审批疲劳。质量指标需要结合 H3 Evaluation 的人工校准和真实任务结果。

十五、测试设计与验收标准 ​

15.1 确定性状态测试 ​

  • 单次有效审批： PENDING → APPROVED；再次提交相同决策应幂等。
  • 冲突决策： 两个并发请求分别批准与拒绝，最多一个成功。
  • 过期授权： 超时后不能被消费。
  • 版本漂移： 报告版本变化时，旧审批不能发布新版本。
  • 权限撤销： 审批后失去权限，执行前应阻止动作。
  • Run 取消： 取消后即使收到延迟审批事件，也不能继续执行。
  • 事件重复： Outbox 重复投递不能导致重复副作用。
  • Worker 崩溃： 审批已提交但恢复前崩溃，重启后仍可继续。
  • 人工接管： 旧 Worker 在接管后不能覆盖人工修改。
  • 注入攻击： 检索文档声称“已批准”不得改变审批状态。

15.2 最小参考实验：版本绑定与一次性消费 ​

以下 Python 标准库示例演示单进程内的审批版本绑定与一次性消费语义，不具备持久化、并发事务或真实授权能力。它不能直接用于生产系统。配套文件 H6-Agent-System-Human-in-the-Loop-v1.1-demo.py，Python 3 标准库（含 3.9）。运行：python3 H6-Agent-System-Human-in-the-Loop-v1.1-demo.py。

python
from __future__ import annotations

from dataclasses import dataclass

@dataclass
class Approval:
    artifact_version: int
    action_digest: str
    status: str = "PENDING"

    def decide(self, decision: str) -> None:
        if self.status != "PENDING":
            raise ValueError("decision already finalized")
        if decision not in {"APPROVED", "REJECTED"}:
            raise ValueError("invalid decision")
        self.status = decision

    def consume(self, artifact_version: int, action_digest: str) -> None:
        if self.status != "APPROVED":
            raise ValueError("not approved")
        if artifact_version != self.artifact_version:
            raise ValueError("artifact version changed")
        if action_digest != self.action_digest:
            raise ValueError("action changed")
        self.status = "CONSUMED"

a = Approval(artifact_version=7, action_digest="hash-A")
a.decide("APPROVED")
try:
    a.consume(8, "hash-A")
    raise AssertionError("version drift must be rejected")
except ValueError:
    pass
assert a.status == "APPROVED"
a.consume(7, "hash-A")
assert a.status == "CONSUMED"
try:
    a.consume(7, "hash-A")
    raise AssertionError("reuse must be rejected")
except ValueError:
    pass
print("local hitl checks passed")

本地执行通过：输出 local hitl checks passed。

真实生产验收必须补充数据库原子更新、跨进程并发、消息重复投递、权限服务失效、审批人身份变更、分布式 Worker 接管和外部工具副作用核验。

15.3 工程验收门槛 ​

最低可用： 具备审批请求、身份授权、持久化等待、明确决策、动作版本绑定、恢复与审计。可运营： 具备超时升级、审批队列、通知、取消、异常处理、关键指标和自动化回归测试。高保障： 具备职责分离、双人审批、策略版本、并发一致性、跨系统追溯、故障注入及定期权限审计。

十六、常见反模式 ​

反模式一：把“模型说用户已同意”当作授权。 解决方法是仅接受可信审批通道生成的结构化决策事件。

反模式二：只批准工具名称，不绑定参数和资源。 解决方法是审批规范化动作摘要及目标对象，执行前重新校验。

反模式三：等待审批时占用进程内线程。 解决方法是持久化 WAITING 状态并通过事件恢复。

反模式四：批准后立即执行，不检查状态变化。 解决方法是使用版本约束、权限复核、策略复核与一次性授权消费。

反模式五：将所有操作都交给人工。 解决方法是按风险分级，优化审批信息和自动化边界。

反模式六：审批与执行使用同一个状态字段。 解决方法是分离审批、授权消费和外部动作结果状态。

反模式七：将人工接管理解为暂停界面动画。 解决方法是停止实际调度、处理 Worker 租约并冻结相关写入权限。

反模式八：将审批日志等同于可审计性。 解决方法是关联身份、动作摘要、版本、政策依据、执行回执与最终产物。

研究结论 ​

  1. HITL 是可强制执行的人机控制协议，而不是 UI 功能。 完整机制必须同时覆盖触发、授权、决策、状态转移、恢复与审计。
  2. 审批应绑定具体动作和资源版本。 未绑定参数、目标和产物版本的笼统批准，容易形成审批后执行对象漂移的安全漏洞。
  3. 等待人工决策必须可持久化。 长任务应在审批点保存 Checkpoint、释放资源，并通过持久化事件恢复。
  4. 人类决定不应覆盖系统硬性安全策略。 人工授权、权限验证与策略执行是互补关系。
  5. 审批成功不等于动作成功。 需要分离决策状态、授权消费状态与外部副作用结果，尤其处理超时和 UNKNOWN 状态。
  6. 多 Agent 协作需要版本化的人类裁决。 人工审核应绑定具体任务分支、产物版本和委托边界，防止旧批准被用于新结果。
  7. HITL 需要在安全性和效率之间进行工程优化。 低风险动作适合自动执行，高风险动作需要充分证据、明确责任和强制审批。
  8. 可靠的 HITL 依赖跨专题协作。 H2 保障权限，H4 保存状态，H5 管理版本，L4/L5 执行与编排，L6 展示交互，H1/H3/H12 提供观测、评估和治理规则。

附录 A：参考文献与原始资料 ​

以下资料优先采用官方文档和标准原文。外部框架的 API、接口参数和兼容性可能随版本变化；实施时应再次核验目标版本。本文中的审批 schema、状态机和架构为综合工程设计建议，不代表这些来源共同定义了某个统一 HITL 标准。

附录 B：研究证据、验证声明与适用边界 ​

B.1 证据分级 ​

官方资料支持的机制： LangGraph 提供中断与持久化恢复能力；Temporal 支持持久化工作流与外部消息交互；OpenAI Agents SDK 提供 HITL 工具审批模式；PostgreSQL 支持事务与并发隔离。这些机制的具体行为仍依赖产品版本与部署方式。[R1][R2][R3][R7][R10]

综合工程推导： 动作摘要绑定、审批与执行分离、双重授权校验、Outbox、版本化产物审批、人工接管与 Fencing、审批疲劳指标等属于本文根据通用安全与分布式系统原理提出的设计建议，并非某一来源直接规定的统一标准。

案例性假设： 研究报告 Studio 的角色、审批层级、风险分类和流程均为教学与架构设计示例；真实系统需要依据业务法规、组织权限与风险容忍度调整。

B.2 验证声明 ​

本文包含参考 API、JSON 数据契约、状态机和 Python 单进程示例。这些内容不等于已完成生产环境验证。 Python 示例只验证最小状态逻辑，不覆盖认证、持久化、并发、分布式恢复、外部副作用或框架集成。正式上线前需按照第十五节完成单元、集成、并发、故障注入与安全测试，并保存真实执行证据。

B.3 适用范围 ​

适用于研究报告 Agent、企业流程 Agent、编程 Agent、自动化运营 Agent、跨工具协作 Agent 等需要人工监督的系统。涉及医疗、金融、法律、公共安全或其他高影响场景时，本文不能替代专业监管要求、组织治理程序和具体行业的合规审查。

B.4 与后续专题的衔接 ​

下一篇 「H7 · 如何保障 Agent System 的可靠性与故障恢复？ - Reliability」 将进一步研究失败分类、超时与重试、幂等、副作用协调、故障注入、灾难恢复及服务等级目标。H6 关注“人类如何介入并有效控制”，H7 关注“系统如何在失败和不确定条件下保持正确运行并恢复”。