智能体面试准备（六十三）：智能体人在回路（HITL）与审批流工程——中断、审批、回滚与可审计闭环

智能体面试准备六十三智能体人在回路HITL与审批流工程——中断、审批、回滚与可审计闭环引言前面六十二讲了工具沙箱与执行安全把智能体能做什么关进了笼子前面五十五讲了工程化交付。但生产里还有一类更现实的问题有些动作不能让智能体自己拍板——发邮件、改数据库、批准报销、调用付费 API、对外发布。这些必须有人确认。这就是人在回路Human-in-the-loop, HITL。HITL 不是加个弹窗那么简单。它要的是在正确的节点停下来等人、把上下文讲清楚让人能决策、人决策后能从断点续跑、人拒绝后能安全回滚、全程可追溯可审计。本文讲一套工程上能落地的审批流设计含状态机、断点续跑、回滚、审计。结尾给速答。一、为什么 HITL 是生产智能体的刚需不需要 HITL 的: 需要 HITL 的: 只读查询(搜文档) 写操作(发邮件/改库) 低风险生成(草稿) 对外发布/付费调用 可回滚的试探 不可逆动作(转账/删除) 内部分析 涉及隐私/合规/他人核心判据动作是否不可逆、是否涉及他人、是否花钱、是否合规敏感。任一命中就进审批。这和六十二沙箱的默认拒绝 白名单是互补的沙箱管能不能执行审批流管要不要先问人。二、审批流的状态机把一次需要审批的工具调用建模成状态机是工程上最清晰的做法工具调用审批状态机 plan | v [pending] -- 自动白名单 -- [executed] --ok-- done | | 需审批 被拒/失败 | | v v [awaiting_human] [rolled_back] - done | 人批准 - [executed] 人拒绝 - [rolled_back] 人改参 - [pending](新参数)要点-pending是计划态尚未产生副作用。-awaiting_human是阻塞态智能体线程挂起不能继续往下走否则会出现人还没批它已经发了下一封邮件的事故。- 任何已产生副作用的状态都要能对应一个rollback动作。三、中断与续跑把执行拆成可恢复步骤智能体不能一次性跑完再问人。要把流程拆成步骤 检查点在检查点阻塞。工程上用一个持久化的执行上下文checkpoint保存当前到第几步、每步输入、已产生副作用列表。执行上下文(检查点)结构 { run_id, step_index, plan: [step0, step1(需审批), step2], side_effects: [ {step:0, kind:db_update, undo:UPDATE ... SET old} ], status: awaiting_human, human_decision: null }续跑人批准后在step_index处 resume加载上下文继续不丢历史、不重算已过的步骤。这呼应二十二长时任务断点续跑——审批流是断点续跑的一个特例。代码阻塞式审批桩import json, time def request_approval(ctx, step): ctx[status] awaiting_human ctx[pending_step] step save(ctx) # 持久化, 等待人 # 真实系统: 发消息给审批人(IM/工单), 然后阻塞或返回 decision block_until_human(ctx[run_id]) ctx[human_decision] decision if decision[action] approve: ctx[status] executing return True if decision[action] reject: rollback(ctx) # 回滚已产生副作用 ctx[status] done return False if decision[action] modify: step[args] decision[new_args] # 人改参数后重跑该步 return True四、回滚副作用必须可撤销不可逆动作转账、删除原则上不应进智能体自动链路必须做也要预扣 确认 限时。对可回滚动作每条副作用记 undo 脚本side_effect 记录 kind: db_update do: UPDATE account SET balancebalance-100 WHERE id1 undo: UPDATE account SET balancebalance100 WHERE id1 kind: email_send do: send(to, body) undo: 撤回(若服务商支持) 或 标记待确认未发 kind: file_write do: write(path, content) undo: write(path, backup) # 先备份原文件拒绝或超时时按side_effects倒序执行 undo。关键undo 本身可能失败要有补偿 告警 人工兜底不能假设回滚一定成功。五、审批人体验让人能决策人不会点批准如果看不懂要批什么。审批消息必须把决策所需信息给全【待审批】智能体想执行: 发送邮件 收件人: zhangcorp.com 主题: 关于 Q3 报销的确认 正文摘要: ...(前200字) 影响: 对外、不可逆程度低、预估成本0 [批准] [拒绝] [修改参数] [查看完整上下文]信息密度原则默认给做了什么、影响谁、能否撤销、完整上下文链接。否则人只能盲批HITL 退化成形式。六、可审计留痕是合规底线审计日志(每条审批) run_id, step, actor(智能体/人), action, decision_by, decision_at, before_hash, after_hash, side_effects, rollback_status审计要防篡改append-only 哈希链能回答谁在什么时候批准了什么、产生了什么后果。这在金融/医疗/政企场景是合规硬要求呼应六十安全合规。七、降级与超时审批人离线设超时策略——超时拒绝保守或转交备用审批人生产。默认超时拒绝 告警。高优路径把不可逆/高成本动作默认设为必须审批低风险动作走白名单自动过平衡效率与安全。批量审批同类低风险动作合并成一次审批允许接下来 10 分钟发送最多 5 封同类邮件降低人负担。八、和五十八多智能体编排的关系在 DAG/状态机编排里审批节点是一个特殊节点它把自动边变成人工边。编排引擎要支持human node作为一等公民——可挂起、可恢复、可超时、可回滚。否则 HITL 只能塞在单智能体里多智能体流程一碰到人工就断。面试速答问HITL 和沙箱六十二什么关系答沙箱管能不能执行默认拒绝白名单审批流管要不要先问人不可逆/花钱/合规敏感动作。一个管权限一个管决策。问审批流核心状态机答pending → awaiting_human →批准executed /拒绝rolled_back /改参回到 pending。阻塞态不能继续往下跑。问回滚为什么不能假设一定成功答undo 本身可能失败如邮件已读无法撤回。要补偿告警人工兜底并留审计。高频追问清单哪些动作必须进审批判据是什么智能体在 awaiting_human 时线程怎么处理能继续别的任务吗断点续跑的上下文要持久化哪些字段不可逆动作转账/删除怎么在智能体链路里安全处理回滚失败怎么办补偿事务怎么设计审批消息要包含哪些信息才不至于让人盲批审计日志为什么要用 append-only 哈希链审批人离线/超时策略怎么定批量审批怎么设计既安全又不烦人多智能体编排里 human node 如何作为一等公民支持挂起/恢复