📌 本文是「AI Agent 的人类控制权」系列的第 2/5 篇。第一篇建立问题意识，本篇给出三层分析框架，第三篇用框架做六大框架体检，第四篇深入工程实现，第五篇讨论前端设计与 Automation Bias。另有番外篇讲微软 Agent 框架的分裂与统一。

——谁介入、怎么介入、靠什么介入

上一篇我们确立了一个前提：Agent 能调工具就意味着有外部副作用，有副作用就需要人类控制机制（HITL）。我们还指出，HITL 不是一个单一的东西——人类在 Agent 系统中至少扮演三种不同的角色。

这篇要做的事情是把"HITL"这个笼统的概念拆开，给出一个系统化的分类框架。

当你在设计一个 Agent 系统的 HITL 时，本质上需要回答三个层次的问题：

  1. 为什么需要人类介入？ 人类在这次介入中扮演什么角色？
  2. 怎么实现这个介入？ 用什么工程机制？
  3. 靠什么让它在生产环境跑起来？ 底层需要什么基础设施？

这三个问题对应三个层次。我把它叫做 HITL 三层模型。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

┌──────────────────────────────────────────┐
│  Layer 1：介入目的（Why）                  │
│  把关人 / 协作者 / 纠正者                  │
├──────────────────────────────────────────┤
│  Layer 2：介入机制（How）                  │
│  工具级审批 / 计划审批 / 升级模式 / 反馈循环 │
├──────────────────────────────────────────┤
│  Layer 3：支撑能力（What）                 │
│  检查点与恢复 / 滑动自主性                  │
└──────────────────────────────────────────┘

每一层回答一个问题，上层定义需求，下层提供实现。

Layer 1：人类扮演什么角色

这一层回答"为什么需要人类介入"。答案不是笼统的"为了安全"，而是三种目的明确不同的角色。

把关人（Gatekeeper）——“这个操作能不能执行？”

Agent 准备调用一个高风险工具。框架在执行前强制暂停，把控制权交给人类。人类可以批准、拒绝、或者修改参数后放行。

注意这不是简单的 Yes/No。人类可以把邮件收件人从 all-company@ 改为 team-leads@ 后再批准——这是带修改的批准，比二元审批有用得多。

把关人的关键特征：

  • 时机：动作执行之前。副作用尚未发生，一切可逆。
  • 触发者：框架规则，不依赖模型判断。不管模型认不认为这个操作有风险，规则说要审批就要审批。
  • 认知负担：低。人类面对的是一个具体的决策——“允许发这封邮件吗？”

协作者（Collaborator）——“我需要更多信息才能继续”

Agent 执行到一半，遇到了信息缺口。它不知道你的预算上限是多少、你偏好哪个供应商、某个专业术语在你们公司的具体含义。它停下来问你。

协作者的关键特征：

  • 时机：执行过程中。Agent 并没有犯错，只是缺少必要信息。
  • 触发者：可以是模型主动判断（“我不确定，问问用户”），也可以是框架检测到必要参数缺失后强制触发。
  • 认知负担：中等。人类需要理解 Agent 的问题并提供准确信息。

协作者和把关人有一个本质区别：把关人面对的是"该不该做"的决策，协作者面对的是"怎么做"的信息需求。前者是准入控制，后者是知识补充。

纠正者（Reviewer）——“这个结果需要调整”

Agent 做完了某件事（或者做到一半），人类审查结果，发现方向有偏差或质量不达标。人类直接给出反馈、修改输出、甚至改变 Agent 的中间状态。

纠正者的关键特征：

  • 时机：执行之后或过程中。副作用可能已经发生（但输出可以被修订）。
  • 触发者：人类自己。不是 Agent 觉得需要审查，是人类主动介入。
  • 认知负担：高。人类需要理解 Agent 当前的状态，判断哪里有问题，给出修正方向。

纠正者是三种角色中认知负担最高的。把关人只需要对一个具体操作做判断，协作者只需要回答一个具体问题，而纠正者需要理解 Agent 的整体状态后做出质量评估。这也是为什么纠正者模式对 Agent 的"可解释性"要求最高——如果人类看不懂 Agent 在做什么，就无法有效纠正。

为什么是这三种，不是两种或四种？

这不是拍脑袋的分类。想想 Agent 的执行时间线：

1
2
3
4
5
6
7
8

  执行前              执行中              执行后
    │                   │                   │
    ▼                   ▼                   ▼
  能做什么？          能做什么？          能做什么？
  批准/拒绝/修改      提供信息/澄清意图    审查/纠正/反馈
    │                   │                   │
    ▼                   ▼                   ▼
  把关人              协作者               纠正者

沿着时间线，人类能贡献的价值只有三类：

  • 安全判断——这个操作该不该执行？→ 把关人
  • 信息提供——Agent 缺少的知识或上下文 → 协作者
  • 质量判断——结果是否达到预期？→ 纠正者

你可以试着构造一个不属于这三类的 HITL 场景。“用户取消了整个任务”——本质上是把关人对"继续执行"的否决。“用户修改了系统配置”——这不是执行时介入，是系统管理，超出 HITL 的范畴。“合规官审计历史记录”——纠正者的后置变体。

我们在后续分析中用这三个角色作为坐标去审视了六个主流 Agent 框架的所有 HITL 功能，没有发现无法归类的反例。

Layer 2：怎么实现介入

Layer 1 定义了"为什么"，Layer 2 解决"怎么做"。四种工程机制，每种主要服务于某种角色，但不是一一绑定的。

机制一：工具级审批（Tool-Level Approval）

这是目前落地最广泛的 HITL 机制。核心思路很简单：给每个工具标一个风险等级，高风险的调用前要人类审批。

1
2
3
4
5
6
7
8

低风险（auto-approve）：搜索、计算、读文件
  → Agent 自主执行，不打扰人类

中风险（notify）：修改文件、创建资源
  → 执行后通知人类，人类可事后审查

高风险（require-approval）：发邮件、执行SQL、调用支付API
  → 执行前暂停，等人类批准

这就是上一篇说的"框架侧硬控制"的具体形态。它主要服务把关人角色——确定性拦截，不依赖模型判断。

工具级审批的优势是简单可靠。劣势是当 Agent 执行一个包含十几个工具调用的复杂任务时，人类可能要审批十几次——这就引出了下一种机制。

机制二：计划审批（Plan Approval）

不审批每一个工具调用，而是让 Agent 先输出完整计划，人类审查整体意图后一次性放行。

1
2
3
4
5
6
7
8

Agent："我的计划是：
  1. 查询数据库获取用户列表
  2. 筛选活跃用户
  3. 生成个性化邮件
  4. 发送邮件
  你确认这个计划吗？"

人类："步骤3和4合并，先生成所有邮件草稿给我看，我确认后再发送。"

计划审批把多次原子审批聚合为一次批量审批，牺牲粒度换取效率。它主要服务把关人（审查整体计划的安全性），同时兼具纠正者能力（人类可以修改计划）。

它的适用场景是 Agent 执行相对可预测的多步任务。OpenAI Deep Research 在执行前展示研究计划让用户确认，就是这种模式。

机制三：升级模式（Escalation）

Agent 自主判断何时需要人类介入，主动将控制权"升级"给人类。

实现方式通常是给 Agent 一个特殊工具（比如叫 ask_human 或 escalate_to_human），Agent 在推理过程中自己决定什么时候调用它。

这就是上一篇说的"模型侧软控制"在框架中的具体体现。它主要服务协作者角色——Agent 遇到信息不足时主动求助。

升级模式的优势是灵活——Agent 能在任意时刻、基于任意理由请求人类帮助。劣势是不可靠——它依赖模型的自我评估能力。如果模型对自己的不确定性缺乏感知（overconfident），它就不会升级；如果模型过度谨慎，它会频繁升级导致体验退化。

这就是为什么升级模式在生产环境中必须搭配工具级审批：升级模式处理模型"知道自己不知道"的情况，工具级审批兜底模型"不知道自己不知道"的情况。

机制四：反馈循环（Feedback Loop）

Agent 产出结果后，人类审查并提供反馈，Agent 根据反馈迭代。

1
2
3
4
5

循环：
  Agent 执行任务 → 生成输出
  人类审查 → 提供反馈（或直接修改状态）
  Agent 根据反馈重新执行
  重复，直到人类满意或达到迭代上限

反馈循环主要服务纠正者角色。它有两种变体：

  • Review & Revise：Agent 生成草稿 → 人类标注问题 → Agent 修订。写作、代码生成等场景中最自然的模式。
  • State Surgery：人类不给反馈，而是直接修改 Agent 的内部状态。比如在 LangGraph 中，你可以用 update_state 直接改掉 Agent 记忆中的某个值，Agent 从修正后的状态继续执行。这是最精确但认知负担最高的纠正方式。

四种机制的关系

四种机制不是互斥的，而是可以任意组合的。一个生产级 Agent 系统通常同时启用多种机制：

机制主要角色确定性粒度适用场景
工具级审批把关人确定性（规则驱动）单次工具调用高风险操作的准入控制
计划审批把关人+纠正者确定性完整计划多步任务的整体审查
升级模式协作者非确定性（模型驱动）Agent 自行决定信息不足时主动求助
反馈循环纠正者非确定性（人类驱动）任务输出迭代式质量改进

推荐的生产配置是"工具级审批 + 升级模式"的组合——硬控制兜底已知风险，软控制覆盖未知场景。如果是写作/代码等迭代性任务，再叠加反馈循环。

为什么是四种？因为 Agent 执行流程中，框架能插入拦截的位置是有限的：计划生成之后（计划审批）、工具调用之前（工具级审批）、推理过程中的任意点（升级模式）、输出生成之后（反馈循环）。这四个位置覆盖了执行流程的全部拦截机会。中间有一个位置看起来缺了——“工具结果返回后、下一步推理前”——但它被反馈循环的中间检查点和计划审批的迭代变体共同覆盖了，不需要单独定义一种新机制。

Layer 3：让 HITL 在生产环境跑起来

到这里你可能觉得框架已经完整了。但如果你试过把任何一种 Layer 2 机制部署到真实的 Web 服务中，你会立刻撞上一堵墙。

Layer 3 不是 HITL 的"模式"，而是让上面所有模式能在生产环境运行的基础设施。没有 Layer 3，Layer 2 的一切都只能跑在 Jupyter Notebook 和命令行脚本里。

检查点与恢复（Checkpoint & Resume）

考虑一个最简单的场景：你的 Agent 作为一个 Web API 服务运行。用户通过浏览器发请求。Agent 执行到一半需要人类审批。

没有检查点会怎样？

1
2
3
4
5
6

HTTP 请求进来 → Agent 开始执行 → 遇到高风险操作，需要审批
→ Agent 线程阻塞，等待人类响应
→ 人类去开会了，30分钟后回来
→ HTTP 连接早已超时断开
→ Agent 线程被回收，执行状态丢失
→ 一切从头开始 ❌

这是所有 HITL 机制在生产环境中面临的核心矛盾：Agent 的执行是有状态的，但 Web 服务是无状态的。 Agent 需要"暂停等人"，但 HTTP 不允许你一个请求等半小时。

有检查点的正确流程：

1
2
3

HTTP 请求 → Agent 执行 → 需审批 → 保存完整状态到持久化存储 → 释放线程 → 返回响应
...（人类异步审批：可能是秒、分钟、小时、甚至几天）...
新的 HTTP 请求（携带审批结果）→ 从存储中恢复状态 → 继续执行 → 返回结果

检查点的本质是把"同步阻塞等待"转化为"异步持久化等待"。它需要两个能力：

  • 状态序列化：把 Agent 的完整状态（对话历史、中间结果、工具调用上下文、当前执行位置）保存到外部存储
  • 状态恢复：从存储中读取状态，让 Agent 从中断点精确恢复执行

这听起来简单，实现起来不简单。Agent 的"状态"比一般应用复杂得多——它包含 LLM 的对话历史、工具调用的中间结果、可能还有跨多个步骤的累积上下文。任何一个部分丢失，恢复后的 Agent 就不是中断前的那个 Agent。

这就是为什么检查点是 Layer 3 而不是 Layer 2。 它不是一种 HITL 模式，而是所有 HITL 模式在生产环境运行的前提条件。没有它，工具级审批只能用 input() 在命令行等着，计划审批只能在 Notebook 里阻塞 cell，升级模式只能在同步对话中进行。

滑动自主性（Sliding Autonomy）

假设你用工具级审批搭建了一个 Agent 系统。上线第一周，你把所有工具调用都设为 require_approval。安全是安全了，但你每天要处理上百个审批请求。到第三天你开始不看内容就点批准——审批疲劳（approval fatigue）让 HITL 名存实亡。

另一个极端：你把所有工具设为 auto_approve。效率很高，但 Agent 某天误操作删了生产数据，你连知道都不知道。

两个极端都不可接受。你需要的是一个旋钮，能根据不同条件动态调节 Agent 的自主程度：

1
2
3
4
5

L0 - 禁止执行：这个工具不允许调用
L1 - 需要审批：调用前必须人类批准
L2 - 事后通知：自动执行，但通知人类
L3 - 自动执行：执行并记录日志
L4 - 完全自主：执行，不记录

这个旋钮可以基于多种因素调节：

  • 工具的风险等级：delete_database 永远是 L1，search_web 可以是 L3
  • 操作的参数值：转账金额 < 100 元走 L3，> 10000 元走 L1
  • Agent 的历史表现：连续 50 次操作无误 → 从 L1 降到 L2
  • 当前环境：测试环境走 L3，生产环境走 L1
  • 组织的合规要求：金融行业可能要求所有外部通信永远走 L1

滑动自主性不是一种独立的 HITL 机制，而是控制所有 Layer 2 机制介入频率的元策略。它让系统在"过度干预导致审批疲劳"和"放任自流导致失控"之间找到动态平衡。

三层之间的关系

三层不是各自独立的，它们之间有明确的映射关系：

Layer 1 → Layer 2：角色通过机制来实现

1
2
3

把关人  ──主要用──→  工具级审批、计划审批
协作者  ──主要用──→  升级模式
纠正者  ──主要用──→  反馈循环

注意是"主要用"而不是"只能用"。计划审批同时服务把关人（审查安全性）和纠正者（修改计划）。升级模式可以由框架规则强制触发（此时更像把关人的变体）。

Layer 2 → Layer 3：机制依赖基础设施来运行

1
2
3
4
5

工具级审批  ──必须依赖──→  检查点（生产环境中暂停等审批）
计划审批    ──必须依赖──→  检查点
升级模式    ──必须依赖──→  检查点
反馈循环    ──必须依赖──→  检查点（保存状态供修改）
全部机制    ──受益于──→    滑动自主性（控制介入频率）

关键洞察：检查点是所有 Layer 2 机制在生产环境中的必要条件，无一例外。 这解释了为什么它被单独抽取为 Layer 3——它不属于任何一种特定的 HITL 机制，而是所有机制共享的底层需求。

用一个类比：Layer 2 和 Layer 3 的关系，类似于 HTTP 和 TCP 的关系。HTTP 定义了请求和响应的语义（GET/POST/PUT），TCP 保证了数据在网络上的可靠传输。你可以在不了解 TCP 的情况下使用 HTTP，但 HTTP 的一切能力都建立在 TCP 之上。类似地，Layer 2 定义了 HITL 的交互语义（审批/反馈/升级），Layer 3 保证了这些交互在生产环境中能可靠运行。

小结

这篇展开了 HITL 三层模型的完整结构：

Layer 1（Why）——人类在 Agent 系统中的三种角色：

  • 把关人：安全控制，执行前拦截
  • 协作者：信息补全，执行中协助
  • 纠正者：质量修正，执行后审查

Layer 2（How）——四种工程实现机制：

  • 工具级审批：按风险等级拦截工具调用
  • 计划审批：审查整体计划后批量放行
  • 升级模式：Agent 自主判断何时求助
  • 反馈循环：人类审查输出并提供反馈

Layer 3（What）——两项基础设施：

  • 检查点与恢复：让 HITL 能在异步、无状态的 Web 环境中运行
  • 滑动自主性：动态调节 Agent 的自主程度，避免审批疲劳

三层之间的关系：Layer 1 定义需求 → Layer 2 提供实现 → Layer 3 保障运行。

这个模型的价值不在于它本身，而在于它提供了一个统一的坐标系。当我们用它去审视市面上的 Agent 框架时，每个框架在 HITL 上的能力和缺陷就变得一目了然——哪些角色被支持了，哪些机制被实现了，哪些基础设施是缺失的。

这正是下一篇的内容：六个主流 Agent 框架，用三层模型做一次体检。

这是「AI Agent 的人类控制权」系列的第二篇。 完整系列：