企业 Agent 什么时候必须让人工接管：Human-in-the-Loop 的设计边界

一手素材：

1. Microsoft Learn - *Human Evaluation for Microsoft Foundry Agents*（https://learn.microsoft.com/en-us/azure/foundry/observability/how-to/human-evaluation ）

2. LangChain - *Interrupts - LangGraph*（https://docs.langchain.com/oss/python/langgraph/interrupts ）

本文把 Microsoft Azure 和 LangChain 两份一手文档里"人工介入"这条主线拉出来讲透——目标读者是企业 AI 平台架构师、Agent 研发工程师、合规负责人、以及正在设计 Human-in-the-Loop 机制的团队。

---

一句话结论

Agent 不是"完全自主系统"，而是"人类监督下的自动化系统"——关键决策必须有人工介入，Agent 才能真正承担企业级任务。 Microsoft Azure 和 LangChain 在两份文档里反复强调同一个核心原则："High-risk decisions should never be fully autonomous." 高风险决策必须有人工确认，Agent 的真正价值是"让人类从低价值重复工作中解放出来，专注于高价值判断工作"，而不是"替代人类做所有决策"。

如果你正在设计 Agent 的 Human-in-the-Loop 机制，先记住三个判断标准：

• Agent 是否有明确的"暂停等待人工"机制？——没有就不是真正的 HITL。
• 是否明确定义了"哪些决策需要人工确认"？——不明确就无法实施。
• 人工介入的等待超时和兜底方案是否明确？——不明确就会卡死业务。

三个中只要命中一个没做到，就该重新设计 HITL 机制。

---

一、为什么 Agent 不能完全自主

过去两年，企业 Agent 项目的"自主程度"经历了几个阶段的认知变化：

阶段 1：完全自主论（早期狂热）

• "Agent 应该完全自主决策，不需要人参与"
• 现实：Agent 在生产环境频繁出错，企业损失巨大

阶段 2：完全不信任论（过度悲观）

• "Agent 太危险了，所有决策都要人工确认"
• 现实：人工工作量没减少，Agent 价值无法体现

阶段 3：分级介入论（成熟认知）

• "高风险决策人工确认，低风险决策 Agent 自主"
• 现实：效率和安全平衡，企业真正受益

Microsoft Azure 在 *Human Evaluation for Microsoft Foundry Agents* 里直接说："Human-in-the-loop is not about limiting agent capability. It's about enabling agents to take on high-stakes tasks safely."——人工介入不是限制 Agent 能力，是让 Agent 能安全承担高风险任务。

LangChain 在 *Interrupts* 文档里给出了具体的实现机制：Agent 在关键决策点调用 interrupt() 函数暂停，等待人工决策后再恢复执行。这种"中断-恢复"机制是 HITL 的核心技术。

把这两份文档合起来，HITL 的核心不是"限制 Agent"，而是"扩展 Agent 的能力边界"——没有 HITL，Agent 只能做低风险任务；有 HITL，Agent 能做高风险任务。

---

二、HITL 的 4 种介入模式

把 HITL 的介入方式分类，主要有 4 种模式。每种模式适用不同场景。

模式 1：决策前确认（Pre-decision Approval）

机制：Agent 在做出决策前，先把决策方案提交给人类审查，人类批准后才执行。

典型场景：

• 涉及金额的退款（金额 > 阈值）
• 涉及合规的操作（修改客户数据、删除记录）
• 涉及客户承诺的回复（"我们会在 24 小时内解决您的问题"）

实现方式：

Agent 决策 → 生成决策方案 → 提交人类审查 → 人类批准 → 执行
              ↓
          人类拒绝 → 重新决策

优点：最严格的安全保证。

缺点：增加延迟（人类审批需要时间）。

模式 2：决策后审核（Post-decision Review）

机制：Agent 先执行决策，人类在事后审核。如果发现问题，可以回滚。

典型场景：

• 自动生成的报告（事后审核）
• 自动发送的营销邮件（事后审核）
• 自动调整的推荐算法（事后审核）

实现方式：

Agent 决策 → 执行决策 → 记录决策 → 人类事后审核 → 必要时回滚

优点：不增加延迟。

缺点：错误已经发生，回滚成本高。

模式 3：异常时介入（Exception-based Escalation）

机制：Agent 正常运行，遇到异常情况时升级给人类处理。

典型场景：

• Agent 检测到异常交易（升级给安全团队）
• Agent 处理不了的客户咨询（升级给人工客服）
• Agent 出现错误（升级给运维团队）

实现方式：

Agent 正常运行 → 检测异常 → 升级给人类 → 人类处理 → 继续或终止

优点：高效（正常情况不打扰人类）。

缺点：异常检测的准确性决定效果。

模式 4：持续监督（Continuous Oversight）

机制：人类持续监督 Agent 的运行，能随时介入。

典型场景：

• 关键业务的 Agent（实时监控）
• 高风险环境的 Agent（自动驾驶、医疗）
• 内部审计（合规检查）

实现方式：

Agent 运行 ←→ 监督面板 ←→ 人类监督员
                ↓
         异常时立即介入

优点：最高的安全保证。

缺点：成本高、需要专门监督人员。

---

三、HITL 的 5 个核心设计原则

把 HITL 设计经验总结，Microsoft Azure 和 LangChain 都强调以下 5 个原则。

原则 1：明确触发条件

HITL 必须有清晰的触发条件，不能让 Agent "自由决定是否升级"。

反例：Agent 在 prompt 里被告诉"不确定时升级给人类"——结果 Agent 频繁升级（每次都不确定）。

正解：明确定义"必须升级"的条件清单：

• 涉及金额 > 1000 元 → 必须升级
• 涉及合规红线操作 → 必须升级
• 涉及删除数据 → 必须升级
• 涉及客户承诺 → 必须升级
• Agent 置信度 < 0.7 → 必须升级

原则 2：明确等待超时

HITL 必须有超时机制，不能让业务卡在"等待人类决策"。

反例：Agent 提交升级后，人类不响应，业务卡死。

正解：明确超时策略：

• 30 分钟未响应 → 自动决策（按预设规则）
• 1 小时未响应 → 升级给主管
• 2 小时未响应 → 任务终止 + 告警

原则 3：明确兜底方案

HITL 必须有兜底方案，不能"升级后什么都不做"。

反例：Agent 升级给人类，人类不响应，Agent 不知道怎么办。

正解：明确兜底逻辑：

• 默认拒绝（保守策略）
• 默认按规则处理（规则优先策略）
• 默认保留状态等人类（保守策略）

原则 4：明确的介入界面

HITL 必须有友好的介入界面，不能让人类在命令行里 review。

反例：人类收到一个 JSON，需要人工解析才能理解 Agent 在做什么。

正解：人类收到清晰的提示：

• Agent 在做什么任务
• 当前的决策方案是什么
• 决策的理由是什么
• 选项（批准 / 拒绝 / 转其他）

原则 5：完整的审计日志

HITL 必须有审计日志，决策过程必须可追溯。

记录内容：

• 何时升级
• 升级的原因
• 人类何时响应
• 人类的决策
• 决策的影响

审计日志是合规和事后分析的基石。

---

四、LangGraph Interrupt 的 4 个核心 API

LangGraph 提供了完整的 HITL 实现机制，核心是 interrupt() 函数及其配套 API。

API 1：interrupt() - 暂停执行

from langgraph.types import interrupt

def agent_node(state):
    # Agent 做出决策
    decision = "approve_refund"

    # 关键决策前暂停
    if decision_involves_high_risk(decision):
        interrupt({
            "decision": decision,
            "context": state["context"],
            "options": ["approve", "reject", "modify"]
        })

    # 人类决策后继续
    return state

interrupt() 让 Agent 在关键决策点暂停，等待人类决策。

API 2：恢复执行（Resume）

人类决策后，通过特定机制让 Agent 恢复执行：

# 人类决策通过 UI 提交
# LangGraph 自动从 interrupt 点恢复
result = agent.invoke(resume_command, state)

API 3：状态保留

LangGraph 自动保存 Agent 的完整状态，包括：

• 当前任务进度
• 已完成的步骤
• 中间结果
• Token 消耗

人类决策后，Agent 从中断点无缝恢复，不需要从头开始。

API 4：多轮介入

LangGraph 支持在任务执行过程中多次介入：

Agent 开始 → 决策 1（自动） → 决策 2（需要人工） → 决策 3（自动） → 决策 4（需要人工） → 结束

每次人工介入都保留完整上下文。

---

五、企业落地 HITL 的 5 步路径

Step 1：明确 HITL 策略

明确每个 Agent 的 HITL 策略：

• 哪些决策需要人工确认？
• 哪些决策 Agent 可以自主做？
• 人工介入的等待超时是多久？
• 超时后的兜底方案是什么？

Step 2：选择介入模式

按业务场景选择：

• 高风险决策 → 决策前确认
• 中风险决策 → 异常时介入
• 低风险决策 → 决策后审核

Step 3：实现介入界面

为人类监督员提供友好的介入界面：

• 待审批列表
• 决策详情
• 决策理由
• 一键批准/拒绝

Step 4：建立监控和审计

监控 HITL 的运行情况：

• 介入频率
• 介入响应时间
• 介入决策分布（批准/拒绝比例）
• 介入对延迟的影响

Step 5：持续优化

基于监控数据持续优化：

• 介入频率过高 → 调整触发条件
• 介入响应时间过长 → 优化人类工作流
• 介入决策分布异常 → 检查 Agent 决策质量

---

六、5 条给企业的具体建议

1. 第一步：明确 HITL 策略，不要让 Agent 自由决定是否升级。 触发条件必须明确。

2. 第二步：选择合适的介入模式。 不同风险等级用不同模式。

3. 第三步：用 LangGraph 等框架实现 HITL，不要自己造轮子。 框架已经实现了完整的 Interrupt / Resume 机制。

4. 第四步：建立友好的介入界面，让人类快速做决策。 界面友好度决定 HITL 效率。

5. 第五步：建立监控和审计，持续优化 HITL。 没有监控就没有优化。

---

写在最后

HITL 不是限制 Agent，是扩展 Agent 的能力边界。

Microsoft Azure 的核心建议："HITL enables agents to take on high-stakes tasks safely."——HITL 让 Agent 能安全承担高风险任务。

LangChain 的核心建议："Interrupts are not failures. They are deliberate pauses for human judgment."——中断不是失败，是为了人类判断的刻意暂停。

把这两条原则记在心里，你的 Agent HITL 设计会比 80% 的同类项目更安全、更高效、更能承担关键业务。

---

*本文基于 Microsoft Learn *Human Evaluation for Microsoft Foundry Agents* 与 LangChain *Interrupts - LangGraph* 两份一手文档整理，并结合企业 AI 平台团队在 HITL 设计中的真实经验。所有事实性表述都可追溯到原始素材；具体案例为通用化描述，不指向特定企业。*