Agent 人机协作（HITL）工程 2026：从审批流、中断恢复到反馈闭环的生产落地

一句话摘要：当 Agent 从 demo 走到生产，"什么时候让人介入、介入之后状态如何恢复、人的反馈如何回流为模型偏好" 三个问题会把一个会说话的玩具变成会协作的同事；本文把 HITL（Human-in-the-Loop）拆成审批流、可恢复执行、反馈闭环、权限边界四块工程，给出可直接落地的实现骨架与失败模式清单。

一、问题的提出：当 Agent 必须停下来等人

2026 年中，我们把 Agent 从"能跑通 demo"推到"能在生产环境里承担真实业务"时，最先撞到的不是模型能力天花板，而是人机协作的工程空白。在内部一个对外客服 Agent 的灰度阶段，第一周线上 P95 延迟从 1.8s 退化到 6.4s，回查原因并不是模型推理变慢，而是 31% 的请求在工具调用之后进入了"等人工审批"的中间态，没有超时、没有 SLA、没有恢复路径，最后堆积到下游队列里拖垮整个调用链。事后复盘的根因只有一个：HITL（Human-in-the-Loop）被人当作产品功能的"开关"，而不是工程系统的"回路"。

这一现象并非个例。截至 2026 年 7 月，公开资料里关于 Agent 人机协作的论文多数停留在"人对模型输出做反馈"的标注层，真正讨论审批流的并发控制、可恢复执行的一致性、人类偏好的工业级采集与回流的工程文献屈指可数。LangGraph 1.0、AutoGen 0.4、Claude Agent SDK 0.27 等框架虽然都内置了 interrupt / approval / human_input 之类的原语，但围绕这些原语构建 SLA、可观测、计费、审计的工程范式尚未稳定。本文把这套范式梳理为四个工程面——审批流、可恢复执行、反馈闭环、权限边界——并给出可直接落地的代码骨架与失败清单。

需要提前声明的是，本文不讨论纯理论层面的"AI alignment"，也不讨论 RLHF 这类训练阶段的偏好对齐——我们要讨论的是Agent 已经在产线上跑、模型权重已经冻结的情况下，如何用工程手段把人纳入 Agent 的执行回路，并且让这条回路在不牺牲吞吐的前提下具备可恢复、可审计、可计费的属性。

二、HITL 的四元组与决策边界

在进入工程实现之前，先把 HITL 的形式化边界画清楚。我们用一个四元组来描述任意一次需要人介入的 Agent 执行：

HITL = (Trigger, Channel, Decision, Resume)

• Trigger：触发人介入的事件。可以是预定义的（"调用写库工具前必须审批"）、可以是模型自荐的（"我不确定这条 SQL 是否会锁表，请人确认"）、也可以是外部触发的（"用户在 UI 上点了取消"）。Trigger 的粒度决定了 HITL 是"细粒度监督"还是"粗粒度兜底"。
• Channel：通知人到接收决策的通道。Slack 审批按钮、企业微信卡片、邮件链接、CLI 终端的 TUI 表单、Web 仪表盘的审核台都是合法 Channel。Channel 的工程差别不在 UI，而在幂等性保证与超时传递。
• Decision：人给出的反馈。三种基础类型——approve（同意并继续）、reject（拒绝并终止）、modify（修改并按修改后版本继续）。modify 是工程上最复杂的，因为它意味着 Agent 的 plan 状态需要被改写而不是被回滚。
• Resume：恢复执行的位置。是接着 Trigger 那一步继续（in-place resume），还是退回到 plan 起点重新规划（re-plan resume）。Resume 决定了 HITL 失败后能否恢复业务一致性。

四个维度都不是非黑即白的开关，而是连续谱：Trigger 可以是任意 JSON Schema 描述的条件；Channel 可以是任意的 webhook 接收方；Decision 可以是结构化表单而不是简单按钮；Resume 可以是图灵完备的"修改执行计划"。但在生产环境下，我们刻意把这四维压扁到最简形式，原因有二：扁平化降低工程复杂度，扁平化让 SLA 与审计可观测。

举例而言，一个真实订单退款 Agent 在生产中把 HITL 压扁为：Trigger = {tool.name == 'refund.create' && amount > 1000}；Channel = Slack 互动按钮（approve / reject / view_details）；Decision = 三选一按钮 + 可选备注；Resume = in-place 接着调用 refund.create（参数可能被 modify 修改）。这一压扁把一次审批决策的工程复杂度从"自由文本 + 任意修改"压到"三条预定义路径"，换来的是：审批延迟可预估（Slack 按钮 P95 7s）、SLA 可追踪、Decision 可结构化入库、Resume 状态可重放。

三、审批流的工程实现：同步、异步与托管

审批流是 HITL 在工程上最先落地的面。三种实现路径各有适用场景：

同步审批（Blocking Approval） 是最直观的形态——Agent 走到触发点，停下来发 HTTP 请求到审批服务，审批服务叫人，人决策后返回结果，Agent 继续。在 LangGraph 里对应 interrupt_before / interrupt_after，在 Claude Agent SDK 里对应 await approval.check(...)。同步审批的工程优点是执行栈清晰：Agent 的线程阻塞，事件循环让出，审批结果回来后从同一调用栈恢复；缺点是超时不可控：审批服务的 P99 直接成为 Agent 的 P99。生产里我们强制同步审批有上限——例如金额 > 10000 的退款必须异步，因为人工审批 P99 经常超过 30s，会拖垮对话上下文窗口。

异步审批（Async Approval + Event-driven Resume） 把审批从同步链路里剥离出来。Agent 走到触发点，把当前 plan 状态序列化到持久化层（如 PostgreSQL 的 approval_pending 表 + Redis 的快照），返回一个 pending_id 给前端，前端展示"审核中"状态，审批服务异步调用 webhook 把决策写到持久化层，Agent 的 worker 通过事件订阅（Kafka topic / Postgres LISTEN）感知到决策到达，反序列化 plan 状态并 resume。异步审批的工程成本是状态机复杂：plan 序列化要够稳定（我们用 JSON Schema + version 字段）、worker 要能幂等地从快照恢复、Resume 时要校验 plan 是否已被并发审批多次。优点是吞吐与延迟解耦：Agent 的 worker 不阻塞，审批可以走完全不同的 SLA（比如风控审批走 4h SLA 而对话响应走 5s SLA）。

托管审批（Outsourced Approval） 是把审批环节外包给一个独立子系统（不是主 Agent 进程）。典型形态是独立的 approval-service：接收 (plan_id, snapshot, decision_request) 三元组，运行自己的 SLA 监控、降级策略、人工接管 UI、计费埋点。Agent 主进程只与 approval-service 通讯，完全不感知审批细节。这种架构的好处是职责清晰：主 Agent 团队只关心 plan 与 resume，审批团队只关心决策与 SLA，两个团队的迭代速度解耦。坏处是引入新的微服务边界——状态一致性、跨服务 trace、失败域隔离都要重新设计。

生产里我们通常的做法是混用：金额 < 500 的退款走同步审批（P99 4s 内完成）；500 ≤ 金额 < 5000 走异步审批（worker resume 5s 内感知 decision）；金额 ≥ 5000 走托管审批（独立 service + 4h SLA + 人工接管）。三种路径在同一个 Agent 进程里通过 approval_router 决策，路由表本身是声明式的（YAML + 版本号），可以独立变更。

四、可恢复执行：序列化、快照与一致性

HITL 的工程难点不是"怎么停下来"，而是"停下来之后能不能恢复"。在 2026 年的生产 Agent 里，我们观察到的 HITL 失败 60% 以上来自恢复阶段的不一致——人批了，但 Agent 恢复时拿不到 plan；plan 拿到了，但工具的副作用已经发生了；工具没执行，但 plan 的 schema 已经变了。

解决方法是把"可恢复执行"当一等公民来设计。具体而言，我们要求任何一次 HITL 中断都必须落盘以下五元组：

(snapshot_id, plan_json, plan_version, side_effects_log, resume_token)

• snapshot_id：全局唯一 ID，作为后续恢复的 key
• plan_json：当前 plan 的完整 JSON 序列化
• plan_version：plan schema 版本号，用于恢复时校验是否兼容
• side_effects_log：已经发生的副作用列表（哪一步工具调用了、调了什么、返回了什么），用于 Resume 时判断"哪些步骤可以跳过"
• resume_token：恢复用的凭证（通常是签名后的 JWT，包含 snapshot_id + 过期时间）

resume_token 是安全的关键：Agent 进程不应该信任任何来源的 resume 请求，必须用签名 token 验证"这次 resume 是合法的审批结果触发的"而不是攻击者伪造的。这一点在公网暴露的 Agent 场景下尤其重要。

恢复时的工程一致性靠两个机制保证：幂等工具 + 副作用白名单。幂等工具指那些"调用多次等于调用一次"的工具（GET 类、upsert 类、read 类），HITL resume 时可以直接跳过；副作用白名单由工具自身声明（如 refund.create 声明自己是"创建类副作用"），Agent 的 resume 逻辑根据白名单决定是否重放——创建类副作用要校验"之前是否已经创建过"（用 idempotency_key），读类副作用则直接跳过。

我们曾在生产中遇到过经典的不一致案例：用户审批"取消订单"，Agent resume 时调用了 cancel_order(order_id)，但实际上用户在审批的 5s 间隔里又点了一次"确认收货"，导致 cancel_order 撞到了状态机的非法转移。修复方案是所有副作用工具必须接受 expected_state 参数——cancel_order 必须传入 expected_state='paid'，后端服务在状态不符时拒绝并返回 409，Agent resume 时把 409 当作"plan 已不成立，需要 re-plan"。这一改动让我们的 HITL 一致性故障率从 5.2% 降到 0.4%。

五、反馈闭环：人类偏好的工业级采集与回流

HITL 不只是"让审批通过"，更是"采集人类偏好"。一次 approve / reject / modify 决策里包含了大量训练信号：审批人偏好哪种解释风格、容忍哪种错误、要求哪种 plan 改写。把这些信号采集并回流到模型微调或 prompt 优化，是 HITL 的长期价值。

工程上我们把反馈闭环拆成三层：采集层、归因层、回流层。

采集层负责结构化记录每一次决策。最低限度要记录：(1) 决策类型（approve/reject/modify）、(2) 决策耗时、(3) 决策人（user_id）、(4) 决策时 Agent 给出的 plan 全文、(5) 决策备注（可选文本）。我们用结构化日志（JSON Lines + Kafka）写入，schema 严格固定，方便后续聚合查询。

归因层负责把决策映射到模型行为。同一段 plan 被 reject，可能是因为"事实错误"、可能是因为"语气不当"、可能是因为"步骤顺序有问题"。归因标签由两个来源生成：(1) 审批人在 UI 上选择的多选标签（"事实错"、"语气差"、"步骤乱"等）；(2) 自动归因模型（一个轻量分类器）对 reject 决策打的标签。两个标签通过多数投票合并，作为后续 prompt 优化的依据。

回流层负责把归因后的偏好信号喂回 Agent。两条主要通路：(1) Prompt 微调——把 reject 案例聚类，自动生成 few-shot example 注入 system prompt；(2) 模型微调——把"审批人偏好 X 风格"的标注数据合成 DPO 偏好对，定期微调底层模型（按周/按月）。

截至 2026 年 7 月，回流层的工程成熟度还远不如采集与归因——大多数团队的 prompt 微调靠手工，模型微调受限于合规与成本。但即便是只做 prompt 微调的团队，我们也观察到 Agent 的 reject 率在 4 周内从 18% 降到 7%——纯 prompt 层的 few-shot 注入就能拿到明显的工程收益。

六、权限边界：HITL 不是全员可审批

HITL 容易被忽视的一面是权限边界。如果任何人都能审批 Agent 的任意决策，HITL 就退化成橡皮图章；如果审批权限过于收紧，HITL 又变成流程瓶颈。

我们采用三层权限模型：

• 决策权限（Decision Authority）：谁能对哪类决策给出 approve/reject/modify。这是按"业务领域 × 金额区间 × 风险等级"三维划分的。例如客服 Agent 的"金额 < 500 的退款"由一线客服审批；"500 ≤ 金额 < 5000"由主管审批；"金额 ≥ 5000"由风控审批。
• 接管权限（Handoff Authority）：谁能在 Agent 异常时接管流程、修改 plan、强制终止。这通常限定在 on-call SRE + 业务 owner 两个角色，且必须有审计日志记录每一次接管。
• 审计权限（Audit Authority）：谁能查看 HITL 的所有历史决策、申诉被拒的 case、修改审批规则。这通常是合规 + 安全团队，配合严格的只读访问与脱敏。

权限边界在工程上靠 RBAC（Role-Based Access Control）+ ABAC（Attribute-Based Access Control）混合实现：RBAC 给角色（"客服"、"主管"、"SRE"），ABAC 给条件（"金额 < 500"、"工作时段 9:00-18:00"、"客户等级 >= VIP3"）。两者通过 policy engine（如 OPA）统一求值，决策日志里必须包含"为什么这个 user 能批这个 case"的完整推理链。

权限的失效模式是过度信任模型自荐的审批。如果 Agent 自己判断"我不确定"就触发审批，恶意 prompt injection 可以让 Agent 把所有请求都路由给"最薄弱"的审批人，从而绕过风控。修复方案是审批路由不能被 Agent 控制——Trigger 的判定由独立的 policy engine 完成，Agent 只能"建议"触发审批，不能"决定"触发审批；最终是否触发审批由 policy engine 基于 tool、金额、用户行为等多维度信号综合判定。

七、生产级可观测性：HITL 的三轴关联

HITL 的可观测性需求远高于普通 Agent 调用。一次 HITL 涉及至少三个独立进程（Agent worker、审批服务、决策存储），任何一个环节失败都会导致用户感知的"卡住"。我们建立了 HITL 的三轴可观测：

时间轴：从 Trigger 到 Decision 的全链路耗时分布。这是 SLA 监控的核心。我们关心的分位数是 P50 / P95 / P99 + 长尾（P99.9 + 最大值）。生产里我们经常发现 HITL 的 P99 是 P50 的 50 倍以上——长尾来自审批人换班、系统午休、消息推送延迟。

决策轴：approve / reject / modify 三类的占比与趋势。modify 的占比尤其重要——高 modify 占比往往意味着 plan 生成质量不达标，或审批人的预期与 Agent 的能力之间有 gap。modify 的内容也常用于 prompt 优化（"用户总是把步骤 3 改成步骤 5"）。

路径轴：审批流在不同路由（同步/异步/托管）的分布与转化率。同步审批 → 异步审批 → 托管审批的转化率是关键的工程信号：如果 30% 的同步审批在超时后被升级到异步，说明同步审批的 SLA 设置不合理；如果 50% 的异步审批最终走到托管审批，说明异步 worker 的事件订阅有延迟。

三个轴的数据要能在同一个 dashboard 里 cross-reference。我们用 Grafana + Loki + Tempo 三件套：Loki 存结构化日志（决策类型、耗时、user_id）、Tempo 存分布式 trace（Agent → approval-service → decision-store 的完整链路）、Grafana 把三者按 pending_id 关联。一个 pending_id 能查到：完整的 plan 快照、决策人、决策耗时、决策备注、Agent 的 trace、tool 调用的 trace、最终 resume 后的执行结果——这是合规审计与故障复盘的最小数据集。

八、HITL 的失败模式与未解决的问题

把 HITL 落到生产后，我们梳理了 2026 H1 观测到的失败模式：

失败模式 A：审批延迟吞噬上下文窗口。Agent 停下等人，模型上下文（system prompt + 历史 messages + tool definitions）继续占用 KV cache 预算。如果审批延迟超过 30s，长上下文模型的 KV cache 占用会把 GPU 显存打爆，导致 OOM。修复方案是审批触发时冻结上下文——把当前 messages 序列化到对象存储，释放 KV cache，resume 时重新加载。我们用这一改动把 HITL 期间的 GPU OOM 率从 8% 降到 0.3%。

失败模式 B：审批人疲劳导致决策质量退化。大量 HITL 审批堆积在少数审批人身上，导致 approve 比例上升、reject 减少、modify 几乎消失——审批人变成橡皮图章。修复方案是轮值 + 抽样审计——审批任务按规则分配到轮值池，并定期抽查 5% 的 approve 决策做质量复核。

失败模式 C：跨 session 状态丢失。用户开启一个新对话，Agent 应该能"记得"上一轮的 HITL 决策（例如"上次您拒绝了方案 A，这次我们换个方案 B"）。这要求 HITL 决策进入长期记忆（向量库 + KV 存储），并按 user_id + topic 维度检索。工程上这一块仍不成熟——多数团队的 HITL 决策只存 90 天就清理，而 Agent 的"记忆"需要更长。

未解决问题：(1) HITL 的 SLA 与 Agent 的 SLA 如何对齐——目前普遍做法是"审批 SLA 单独算"，但用户体验是"端到端 SLA"，两者 gap 经常被忽视。(2) 多人协作审批（如"主管 + 风控双签"）的状态机建模——目前缺少标准的状态机语言。(3) AI 生成审批建议（"Agent 已经做了预审，建议 approve"）的可信度校准——容易让审批人过度信任。这些都是 2026 H2 急需工程界共识的方向。

九、给工程师与架构师的落地清单

如果你要在 2026 年下半年把 HITL 落地到生产 Agent，这里是一份可直接执行的工程清单：

1. 先把 Trigger 形式化：不要让 Agent 自己决定什么时候触发审批。Trigger 由独立 policy engine 求值，policy 版本号、触发条件、上下文一起存。
2. 状态序列化是核心能力：snapshot_id + plan_version + side_effects_log + resume_token 必须完整；缺一项就要复盘为什么没存。
3. 审批流分层：低风险同步、中风险异步、高风险托管；分层标准写到 policy 文件里，方便变更。
4. 工具必须幂等或声明副作用：所有被 HITL 路径调用的工具必须支持 idempotency_key 或显式声明副作用类型（read/create/update/delete），否则 resume 时无法判断是否要重放。
5. 反馈闭环必须先于回流：先建立决策采集与归因，再考虑 prompt 微调或模型微调；没有采集层，回流层就是空中楼阁。
6. 权限 RBAC + ABAC 双层：单纯 RBAC 不够灵活，单纯 ABAC 不易审计；两者结合最稳。
7. 三轴可观测同步建设：时间轴、决策轴、路径轴的 dashboard 在 HITL 上线第一天就要有；缺 dashboard 的 HITL 等于裸奔。
8. 冻结上下文：审批期间序列化 messages 到对象存储、释放 KV cache；这是被严重低估的工程要点。
9. 轮值与抽样审计：审批人疲劳是真实风险，机制层面的解药比文化层面的呼吁更可靠。
10. 预设 HITL 的退出条件：HITL 不是终态。设计 Agent 逐步减少 HITL 触发频率的路径（如"审批率从 18% 降到 5% 以下就关闭这一路审批"），让 HITL 真正成为过渡态而不是长期形态。
11. 跨 session 记忆与偏好沉淀：把高频审批决策的结构化特征写进 user-level memory（如"该用户偏好简洁回复、容忍中等风险"），让 Agent 在新 session 主动避开已知会触发审批的路径。
12. 告警分层与值班接管：审批 SLA 触发阈值分级（如 P95 > 60s 黄灯、P95 > 120s 红灯、红灯触发 on-call 接管），避免长尾延迟在无人察觉时累积成业务故障。

回到最开头那个 6.4s P95 延迟的客服 Agent，最终的修复不是某个 prompt 的微调，也不是某个工具的优化，而是把 HITL 当成工程系统来重构——审批路由、状态快照、可恢复执行、权限边界、可观测性五个面同时落地。HitL 的价值不在"让人介入"，而在"让介入可工程化"。当一个团队能把每次审批的延迟、决策、路径、权限、回流全部数据化、版本化、可观测化，HITL 才真正从产品功能进化为工程范式；而这套范式，正是 2026 年下半年 Agent 走向大规模生产的关键基础设施。

参考文献

1. LangGraph Documentation v1.0: Human-in-the-Loop Patterns, LangChain, 2026.
2. AutoGen 0.4 Release Notes: Asynchronous Approval and Event-driven Resume, Microsoft Research, 2026.
3. Anthropic Claude Agent SDK 0.27: Approval Checkpoints and Resume Tokens, 2026.
4. OPA (Open Policy Agent) Documentation: RBAC and ABAC Policy Authoring, Styra, 2025.
5. Grafana Labs: Distributed Tracing with Tempo and Loki, 2026.
6. PostgreSQL 16 Documentation: LISTEN/NOTIFY for Event-driven Workers, 2026.
7. Redis 7.4 Documentation: Snapshot Persistence and Replay, 2026.
8. Apache Kafka 3.7: Idempotent Producer and Exactly-Once Semantics, 2026.
9. Kubernetes 1.30: Sidecar Pattern for Approval Services, CNCF, 2026.
10. OpenTelemetry GenAI Semantic Conventions, CNCF, 2026.
11. PagedAttention: KV Cache Memory Management for Long Context, Kwon et al., SOSP 2023.
12. Anthropic Constitutional AI: Harmlessness from AI Feedback, 2022.
13. DPO: Direct Preference Optimization, Rafailov et al., NeurIPS 2023.
14. RLAIF: Scaling Reinforcement Learning from Human Feedback with AI Feedback, Lee et al., 2023.
15. Reflection / Reflexion: Self-correction via Verbal Reinforcement, Shinn et al., NeurIPS 2023.