这篇文章想聊一个在 Agent 领域被反复提及、却很少被真正落地的理念：Human-in-the-Loop。

---

一、Agent 的自主性悖论

过去两年，Agent 技术的叙事主线几乎只有一个方向：更自主、更强大、更少人工干预。

AutoGPT 让 Agent 自己给自己下任务；Devin 号称能独立完成整个软件工程任务；各类 Multi-Agent 框架让多个 AI 互相协作、互相驱动。“人类只需要提一个目标，剩下的交给 AI”——这是整个行业在努力实现的愿景。

但在实际使用中，大多数人很快遇到了一个共同问题：

Agent 在做什么，我看不懂。Agent 做错了，我没法插手。Agent 跑完了，我只能接受结果。

这不是某一个产品的问题，而是整个"全自动 Agent"叙事的结构性缺陷。

自主性越强，黑盒越深。黑盒越深，用户越焦虑。

---

二、主流 Agent 系统的现状

以市面上主流的 Agent 框架和产品为例，它们在人机协作上的设计大致分为两个极端：

极端一：全自动模式

Agent 接受用户的一句话目标，自主规划、自主执行、自主决策，最终返回结果。

优点：流畅、高效，符合"AI 助手"的直觉期待。
缺点：

• 执行过程完全不透明，用户只能等待
• 中途出错无法干预，只能等跑完重新提问
• 执行偏差积累——前一步的错误会放大到后续每一步
• 用户对 Agent "信任"的建立无从验证

极端二：全手动确认模式

每一步执行前都弹窗请求用户确认：“我要执行 XX 操作，是否同意？”

优点：安全感强，用户完全掌控。
缺点：

• 严重打断执行节奏，体验极差
• 对于复杂任务（20+ 步），用户需要确认 20+ 次，远不如自己做
• 大量确认变成"默认点确认"，安全感成了假象

这两种极端都没有解决真正的问题：如何让人类在合适的时机以合适的粒度参与到 Agent 的执行过程中。

---

三、Human-in-the-Loop 的本质

Human-in-the-Loop（HITL） 并不是一个新概念。它起源于机器学习领域，指在模型训练或推理过程中，引入人类判断来提升质量和可靠性。

在 Agent 语境下，HITL 的含义更宽泛，也更有工程挑战：

在 Agent 自动执行的过程中，为人类保留可观测、可干预、可纠偏的能力——既不牺牲自动化效率，也不丧失人类控制权。

这不是"让人做更多事"，而是"让人在关键时刻做正确的事"。

HITL 的核心不在于频率，而在于时机和粒度：

• 时机：什么情况下需要人的介入？（信息不足时、任务关键节点、执行偏差时）
• 粒度：人的介入作用在哪一层？（整体目标层、单步决策层、参数层、结果层）

---

四、HITL 的三个维度

一个真正支持 Human-in-the-Loop 的 Agent 系统，至少需要在以下三个维度上做设计：

维度一：执行前的能力授权

Agent 能做什么，不应该完全由系统决定，用户应该有主动配置权。

比如：一个 Agent 系统集成了几十种工具能力（搜索、数据库读写、文件操作、邮件发送……）。如果每次对话都把所有能力都暴露给 AI，有两个问题：

1. AI 可能在不恰当的时机调用不恰当的工具（比如你只是在聊天，AI 却触发了数据库写操作）
2. 工具越多，AI 的选择空间越大，路由出错概率越高

真正的 HITL 设计应该让用户在对话开始前就能明确告诉系统：“这次我允许你使用哪些能力”。这是一种执行前的能力边界授权，而不是事后的结果审核。

维度二：执行中的信息补充

Agent 在执行复杂任务时，经常遇到"信息不足"的情况。

主流系统的处理方式通常是两种：

• A：AI 自行假设，用它认为合理的参数继续执行（风险：假设错误导致后续全错）
• B：AI 报错终止，让用户重新提问（风险：之前执行的步骤全部浪费）

真正的 HITL 应该是第三种：在执行中途暂停，向用户请求补充信息，获得信息后从断点继续，已完成的步骤不重跑。

这是"断点续传"而不是"重新提问"——两者体验和效率的差距是质的。

维度三：执行中的流程干预

这是 HITL 中最难做、也最有价值的维度。

当 Agent 正在执行一个多步骤计划时，用户应该能够：

• 看到每一步的状态和中间结果（可观测）
• 发现某一步结果不对时，直接跳过它而不中断整个任务（可剪枝）
• 发现某一步失败时，手动触发重试（可干预）

这要求系统的执行引擎是有状态的——每个步骤有独立的状态，用户对状态的修改能被执行引擎实时感知并响应。

大多数 Agent 框架没有这个能力，因为它们的执行是线性的、无状态的：要么全跑完，要么全重来。

---

五、主流框架在 HITL 上的差距

框架 / 产品	执行前授权	执行中补充	执行中节点干预	执行过程透明度
LangChain Agent	❌ 工具列表固定	❌ 无	❌ 无	⚠️ 仅日志
AutoGen	❌ 全工具暴露	⚠️ 有 human_input_mode 但粗粒度	❌ 无	⚠️ 终端输出
Dify	⚠️ 可配置工具	❌ 无	❌ 无	⚠️ 有限展示
Devin / 类 Devin 产品	❌ 全自动	❌ 无	❌ 无	⚠️ 日志可看
Cursor Agent	❌ 全自动	⚠️ 可对话但非断点续传	❌ 无	✅ 差异可见
理想 HITL 系统	✅ 用户白名单授权	✅ 断点续传	✅ 节点跳过/重试	✅ 全链路透明

可以看到，市面上的主流系统几乎没有在"执行中节点干预"这个维度上做出真正的设计。原因也很简单：这需要执行引擎本身是有状态的节点树，而不是线性链条。线性链条的 Agent 天然不支持中途修剪，因为每一步都依赖上一步的完整输出，跳过某步意味着后续全部失效。

---

六、为什么 HITL 在当前阶段尤其重要

有人会说：等 AI 能力足够强，就不需要 HITL 了。

这个逻辑在理论上成立，但忽略了几个现实：

1. 当前 LLM 的错误率不可忽略

即使是最强的模型，在复杂多步任务中的错误率仍然不低。多步执行中，每一步的错误会被后续步骤放大。一个 10 步任务，如果每步成功率 90%，整体成功率只有约 35%。HITL 是在能力不完美时提升系统可靠性的工程手段。

2. 用户信任需要被建立

信任 AI 不是天然的，而是通过"可观测 + 可验证 + 可纠偏"逐渐建立的。一个用户能看懂、能参与、能纠偏的 Agent，比一个黑盒 Agent 更容易被真正用起来——这不是情感问题，是产品问题。

3. 高风险场景不允许全自动

数据库写操作、文件删除、外部服务调用……这些操作一旦执行就难以撤销。即使 AI 能力再强，在高风险场景下保留人类决策权是工程责任，而不是对 AI 能力的不信任。

4. "全自主"是目标，不是现状

Hermes、Devin 等系统追求的"全自主 Agent"是长期目标。在到达那个目标之前的过渡期，HITL 是让 Agent 真正可用的关键桥梁。

---

七、HITL 与可观测性的关系

Human-in-the-Loop 不能脱离可观测性（Observability） 单独存在。

人类要干预，前提是人类能看懂发生了什么。如果 Agent 的执行过程是黑盒，HITL 就无从谈起——你不知道哪一步出了问题，怎么知道该跳过哪一步？

真正的 HITL 系统应该让用户能看到：

• 当前执行到哪一步（计划进度）
• 每一步用了什么工具、传了什么参数、得到了什么结果（步骤透明）
• AI 在每一步的推理依据（决策可追踪）
• 整体花了多少时间、消耗了多少成本（资源可见）

可观测性是 HITL 的前提，HITL 是可观测性的价值出口。两者相辅相成，缺一不可。

---

八、HITL 的设计原则

总结几个在实际系统中实践 HITL 的设计原则：

原则一：默认透明，而非默认隐藏
执行过程的所有信息默认对用户可见，而不是只暴露最终结果。用户可以选择"不看"，但系统不应该替用户决定"不展示"。

原则二：干预入口与执行流程解耦
用户的干预操作（跳过/重试/补充信息）应该通过状态变更作用于执行引擎，而不是直接修改执行逻辑。这样系统更稳定，干预入口更容易扩展。状态即行为——用户改变节点状态，引擎下一轮自然感知并响应。

原则三：断点续传优于重新执行
任何中断或干预操作，都应该尽量保留已完成步骤的上下文和产出，而不是从头重来。重新执行是最差的用户体验，也是最大的资源浪费。

原则四：授权粒度与使用场景匹配
不同场景需要不同粒度的能力授权。日常对话和高风险操作应该有不同的默认能力边界，而不是一刀切地全开或全关。

原则五：HITL 不是审批流
HITL 的目标是在关键时刻引入人类判断，而不是把每一步都变成审批。好的 HITL 设计是"静默执行为主，关键节点可介入"，而不是"默认请求确认"。

---

九、结语：自主性和控制权不是对立的

Agent 领域长期存在一个误解：给 AI 更多自主性，就意味着给人类更少控制权；要保留人类控制权，就必须牺牲自动化效率。

这个二元对立是假命题。

真正设计良好的 Human-in-the-Loop 系统，恰恰是在 AI 高度自动化执行的同时，为人类保留了有意义的控制入口——不是事无巨细的审批，而是在合适的时机以合适的方式参与决策。

用户不只是 Agent 的提问者，也是执行过程的共同决策者。

这才是 Agent 系统在当前阶段应该追求的形态：不是让人类消失在流程之外，而是让人类出现在真正需要的地方。

---

如果你对 Human-in-the-Loop Agent 的工程实践有兴趣，欢迎交流探讨。