过境笔记

主题

Human-in-the-loop：什么时候必须让人接手？ ​

今天先记住 ​

Human-in-the-loop（HITL）不是在 Agent 旁边放一个“人工客服”，而是在关键状态变化前暂停执行，让人做可记录的决定：批准、修改、拒绝，或直接补充信息。它解决的不是“模型不够聪明”，而是“某些动作一旦执行，责任和损失不能交给概率输出承担”。

它在大地图里的位置 ​

txt
用户目标
  -> 规则 / 边界
  -> 上下文 / 记忆
  -> 规划 / 决策
  -> 工具调用 / 外部系统
  -> 人工审查 / 中断恢复
  -> 执行 / 观察结果
  -> 最终输出

昨天讲工具权限与护栏，重点是系统自动拦哪些动作。今天的 HITL 再往前一步：当系统判断“这一步不能自动放行”，Agent 不应该硬猜，而应该把待执行动作、参数、理由和风险交给人。

它到底是什么 ​

HITL 是一种运行时控制点。Agent 准备调用工具时，系统先检查这次调用是否命中审查策略：比如要删除文件、执行 SQL、给外部联系人发消息、推送生产分支、提交付款。

命中后，执行暂停，当前会话状态被保存。人看到清楚的动作请求后，可以批准原动作，改参数后再执行，拒绝并给反馈，或回答 Agent 缺少的信息。重点是“暂停在动作发生前”，而不是动作做完后再让人背锅。

为什么 Agent 里会用到它 ​

真实 Agent 往往不是一次性问答，而是连续读、写、调用、提交。完全自动化会把小误判放大：模型误解“发布今天文档”，可能把无关文件一起提交；误解“清理旧记录”，可能把生产数据删掉。

HITL 把这些节点变成可审查的状态转换：从“准备 push main”到“已 push main”之间，必须有一条人类批准记录。这样出了问题时，你能查到它当时想做什么、参数是什么、谁批准或拒绝了。

怎么判断它有没有用 ​

  • 如果动作会对外发送、删除、付款、授权、发布或影响生产环境，就应该默认进入人工审查。
  • 如果人只是看最终答案，不能修改工具参数，那不叫有效 HITL，只是事后验收。
  • 如果每一步都要人点同意，系统会变慢且容易机械批准；应该只卡高风险节点。
  • 如果暂停后不能保存状态并从原位置恢复，HITL 会退化成“重新跑一次”，反而增加重复执行风险。

最近冒出来的词 ​

最近可以记一个工程词：HITL middleware。

LangChain 文档里把 Human-in-the-loop 做成 middleware：模型提出工具调用后，中间件按策略检查；如果需要人工介入，就发出 interrupt 暂停执行，并让人选择 approve、edit、reject 或 respond。它不是新概念，更像把“人工审批”从口头规则变成可组合的 Agent 运行时机制。

来源提示：LangChain Docs，Human-in-the-loop 页面，2026-07-27 抓取。

一个小例子 ​

txt
Input:
用户说：“生成并发布 2026-07-27 的 AI Agent Daily，只提交相关文件。”

Process:
1. Agent 写入 docs/ai-agent/2026-07-27.md。
2. 构建通过，准备 git add 和 git push。
3. 系统发现 push main 是高风险动作，暂停并展示：
   action=git_push
   branch=main
   staged_files=[docs/ai-agent/2026-07-27.md]
4. 人批准后才继续；如果 staged_files 混入 docs/english/*.md，人应拒绝并要求重新暂存。

Output:
批准状态：push 执行，页面发布。
拒绝状态：push 不发生，Agent 回到 git status 检查。

这个例子可以拿去判断真实系统：HITL 不只是“问一下要不要继续”，而是让人看到足够具体的动作和参数，能在执行前改变结果。

常见误区 ​

  1. 以为有人工确认就安全。确认页面如果只写“是否继续”，人其实没有判断材料。
  2. 以为 HITL 越多越好。低风险读操作不该频繁打断，否则用户会养成闭眼批准。
  3. 以为拒绝就是结束。好的拒绝会把原因返回给 Agent，让它换路径或补问。
  4. 以为 HITL 能替代日志。人工决定本身也要留痕，否则事后无法复盘。

今天自测 ​

  1. 哪三类动作最应该进入 HITL？
  2. 为什么“动作执行后再人工检查”不算真正的 HITL？
  3. 审批界面最少要展示哪些信息，人才有能力判断？