企业官网建设流程全解析

上一篇文章里，我们讨论了 Tool Node。

一个重要结论是：

Agent 不只是会说话，它还可以调用工具去执行动作。

但问题也随之而来：

不是所有动作都应该自动执行。

有些操作太敏感，有些判断太重要，有些风险太高，必须让人介入。

这就是 Human-in-the-loop。

这篇文章就讨论：

什么时候需要人工介入？为什么这对 LangGraph 很重要？

什么是 Human-in-the-loop？

Human-in-the-loop，简单说就是：

让人进入自动化流程，在关键节点做确认、修改、审核或补充。

在 Agent 场景里，它通常表现为：

流程执行到某一步 ↓ 系统暂停 ↓ 等待人工确认 ↓ 人工给出决定 ↓ 流程继续

这不是流程失败，而是受控暂停。

为什么 Agent 需要人工介入？

因为模型并不总是可靠。

即使模型很强，真实业务里仍然有很多情况不适合全自动。

比如：

发邮件 删除数据 修改订单 执行退款 发起审批 更新配置 调用高风险接口

这些动作一旦做错，代价可能很高。

所以不能简单让模型自己决定全部。

Human-in-the-loop 的意义，就是给系统加一个安全阀。

哪些场景适合人工介入？

常见场景包括：

1. 高风险操作

比如：

删除记录 退款 发通知 修改权限 写入数据库 执行审批

这些操作通常需要人工确认。

2. 低置信度判断

如果模型对某个判断不够确定，可以交给人。

比如：

当前结果是否足够？ 是否应该继续检索？ 是否应该切换策略？

3. 关键业务决策

比如合同审核、财务审批、客服升级处理。

这些流程往往不能完全自动化。

4. 需要补充信息

模型缺少信息时，可以暂停流程，向用户提问。

比如：

请补充订单号 请确认退款原因 请确认目标收件人

人工介入不是流程中断，而是流程控制

很多人会把人工介入理解成“卡住了”。

其实不是。

更准确地说，它是图里的一个暂停点。

流程在这里保存状态，等待人工输入，然后恢复。

这和普通聊天窗口不一样。

普通聊天窗口只会追加消息。

Human-in-the-loop 是有结构的暂停和恢复。

在 LangGraph 里为什么特别合适？

因为 LangGraph 本来就是有状态流程。

它支持：

记录当前 State 在关键节点暂停 等待外部输入 根据输入恢复流程

这让人工介入不再是临时补丁，而是流程的一部分。

比如一个理赔 Agent：

接收申请 ↓ 初步审核 ↓ 判断风险等级 ├─ 低风险：自动处理 ├─ 中风险：人工复核 └─ 高风险：直接升级

这种流程非常适合图结构。

人工介入需要保存什么？

要能恢复流程，就必须保存好状态。

比如：

当前走到哪一步 已经执行了哪些节点 人工要审批的内容是什么 用户输入了什么 接下来该去哪里

如果状态没保存，人工确认后就没法恢复。

这也是为什么 Human-in-the-loop 往往和 Checkpoint 一起出现。

因为暂停和恢复必须依赖持久化状态。

人工介入界面要尽量清楚

如果系统要求人做判断，就应该把需要判断的内容说清楚。

比如：

当前拟执行操作 操作影响范围 模型为什么建议这样做 可选动作 历史上下文

这样人工才知道自己在审什么。

不要只给一句模糊提示：

请确认是否继续

这种信息不够，没法做决策。

人工介入也要有边界

不是所有节点都能随意暂停。

应该明确哪些情况必须人工介入，哪些情况自动处理。

比如：

查询类动作自动执行 写入类动作需要确认 删除类动作需要双重确认 跨权限动作不允许执行

这让系统既有自动化效率，又保留人工控制力。

常见误区

第一个误区，是把 Human-in-the-loop 当成兜底乱用。

不是所有问题都靠人工解决。

第二个误区，是没有明确的暂停点。

人工介入必须出现在图里，而不是随手插一段代码。

第三个误区，是没有保存状态。

没有状态，就无法恢复流程。

第四个误区，是人工输入不结构化。

如果输入内容杂乱，恢复流程也会混乱。

第五个误区，是把人工介入当成失败。

它其实是受控决策的一部分。

总结

Human-in-the-loop 是 Agent 工程化里非常重要的一层。

它的价值不是减慢系统，而是在关键时刻给系统加上人类判断。

在 LangGraph 中，它尤其自然，因为图结构本来就支持暂停、恢复和分支控制。

当动作高风险、判断低置信度、流程需要补充信息时，人工介入就很有必要。

这样系统才不会一味自动化，而是真正变成可控的 Agent Workflow。

下一篇文章，可以继续进入更复杂的生产化主题：

Checkpoint 和恢复能力。