人在回路设计：AI Agent该在哪些节点停下来问人？

一个现实问题：把 AI Agent 完全放手去跑，团队睡不着；但每个动作都要人点确认，效率还不如不用。真正的答案不是”全自动”或”全人工”，而是设计好”人在回路”（Human-in-the-Loop, HITL）的介入点。

一、四种 HITL 模式

1. 审批式（Approve-then-act）。 Agent 提出动作，人确认后才执行。适合高危操作：转账、删数据、发对外邮件、发布上线。

2. 复核式（Act-then-review）。 Agent 先执行，人在事后抽查或全量复核。适合低危但需要兜底的场景，如内容生成、分类打标。

3. 升级式（Escalate-on-uncertainty）。 只在 Agent 不确定或超出能力时转人工。这是性价比最高的模式，关键在于”不确定”的判定。

4. 协作式（Co-pilot）。 人和 Agent 交替工作，各展所长。适合复杂分析、代码开发这类需要来回迭代的场景。

二、该在哪些节点停下来

判断一个动作是否需要人工介入，看三个维度：

• 不可逆性：一旦执行能否撤销？不可逆则必须审批。
• 影响半径：影响到多少人、多少钱、多少数据？范围大则必须审批。
• 置信度：Agent 对这个决策有多确定？低则应当升级。

把三者画成矩阵，就能给每个动作分配模式：

维度	低影响	高影响
可逆	自动执行	事后复核
不可逆	事后复核	前置审批

三、“不确定”怎么判定

升级式 HITL 的成败，取决于能否可靠识别”我不确定”。可用的信号：

1. 自评置信度：让模型显式给出 0~1 的置信分（但要校准，模型常过度自信）。
2. 检索无命中：RAG 中相似度全部低于阈值，大概率是知识范围外。
3. 多次采样分歧：同一问题采样 5 次，答案分歧大则判定不确定。
4. 规则触发：命中敏感词、金额超阈值、涉及新客户等硬规则。
5. 工具报错：外部调用失败、格式解析失败。

把这些信号组合成”风险分”，超过阈值就走人工通道。

四、审批界面的三条实践

1. 给足上下文。 不要只让人看”是否批准”，要展示 Agent 的推理依据、将执行的具体内容、可能后果。否则人只会机械点”同意”，HITL 形同虚设。

2. 提供被编辑的选项。 最好的 HITL 不是二选一，而是允许人”改一改再放行”。Agent 提出草稿，人微调后执行，既保留效率又保安全。

3. 记录每一次干预。 谁在什么时候否决或修改了什么，全部留痕。这些数据反过来能用来改进 Agent 的置信度判定与提示词。

五、一个审批钩子示例

RISKY_TOOLS = {"transfer_money", "delete_records", "send_email"}

def execute(action, confidence):
    if action.tool in RISKY_TOOLS or confidence < 0.7:
        decision = request_human_approval(
            action=action,
            rationale=action.reasoning,
            risk=estimate_risk(action),
        )
        if not decision.approved:
            return abort(decision.comment)
        action = decision.edited_action or action
    return run(action)

六、三个常见失败模式

1. 审批疲劳。 什么都弹窗，人会无脑点”同意”。解决：只在高风险或低置信时打断，其余自动。

2. 无上下文审批。 只给个”批准/拒绝”，人无法判断。解决：把依据和后果一起呈现。

3. 单向升级、无回退。 人工处理完就结束，Agent 学不到东西。解决：把人工决策回灌为训练/规则。

结语

HITL 的精髓是把人的注意力花在刀刃上。不是让人替 Agent 干活，而是让人守住那些”错了就麻烦”的关键节点。设计得好，Agent 跑得快、人睡得着；设计得差，要么风险失控，要么效率归零。