一、先想清楚核心原则

人工确认的本质：高风险、高不确定性、高成本的动作交给人；低风险、确定性、可回滚的动作交给 Agent 自动执行。 不要把 “人工确认” 做成兜底万能补丁，而是一套可配置的触发策略，和业务风险等级绑定。

二、需要触发人工确认的 6 大类场景

1. 高资金、高权限、不可逆操作（最高优先级）

这类操作一旦执行，很难撤销，是线上事故高发区。 典型例子：扣款、转账、删除数据库表、修改核心配置、给用户下发权限、批量删数据。

面试话术：只要操作具备不可逆、资金损失、权限变更属性，强制走人工确认，不允许 Agent 自主执行。哪怕 Agent 信心 100%，也要拦截。

2. 模型判断置信度不足、存在歧义、信息缺失

Agent 拿到的信息模糊、资料冲突，没办法稳定输出正确方案。 比如 RAG 返回两份矛盾文档、用户需求描述模糊、缺少关键参数，模型自己拿不准答案。 这个时候不是硬着头皮继续调用工具，而是主动向人提问，补充信息、确认方案方向，避免沿着错误路径越跑越偏。

3. 超出预设能力边界、陌生任务

任务不在 Agent 的能力清单、允许工具列表里。 比如 Agent 只允许查工单，但是用户要求修改服务器防火墙；Agent 只负责查资料，用户要求编写上线变更脚本。 超出能力域，直接请求人工介入，而不是尝试调用未知工具、强行瞎处理。

4. 变更类、会影响存量业务的操作

批量修改、配置变更、数据迁移、版本发布这类操作，会影响大量用户，哪怕单次金额不大，也需要人工复核。 比如批量修改上百个用户标签、批量推送通知，执行前展示预览清单，等待人确认。

5. 安全风险场景：敏感内容、高危指令

识别到提示注入、越狱指令、试图绕过安全沙箱、读取隐私数据。 比如 Agent 收到指令尝试读取密钥、导出用户隐私手机号，立刻暂停，上报人工审核，拒绝自动执行。

6. 用户明确要求 “每一步都确认”

用户侧配置了强校验模式，用户主动开启人工审批，无论什么操作，都需要确认之后再执行。

三、可以不用人工确认，自动执行的场景

1. 只读查询：查文档、查公开信息、查询订单状态，不会修改任何数据；
2. 低风险、可回滚的轻量操作：创建临时文件、生成报表、发送普通消息；
3. 重复、标准化、经过大量验证的固定流程：比如固定模板的周报生成；
4. 风险在阈值以内，并且有自动兜底回滚机制。

四、工程落地怎么设计这套规则（面试加分项）

1. 风险分级：给每个工具、每个动作打标签：高危 / 中危 / 低危，高危强制人工；
2. 置信度阈值：模型输出置信度低于阈值，自动触发人工；
3. 白名单 + 黑名单：白名单内低风险操作自动放行，黑名单操作强制拦截；
4. 预览机制：触发人工时，必须把将要执行的内容、影响范围展示给人，而不是只问一句 “是否确认”；
5. 超时策略：人工确认不能无限等待，超时之后可以设置拒绝执行、或者降级通知；
6. 日志审计：所有人工确认记录、Agent 原始方案、人的选择，全部落日志，方便复盘。

五、面试高频追问

Q：如果全部操作都加人工确认，有什么问题？ A：会丧失 Agent 自动化的价值，吞吐量暴跌、响应变慢，人力成本爆炸，只适合极小流量、极高安全要求场景，不能通用。

Q：能不能让 Agent 自己判断要不要找人？ A：可以辅助判断，但高危动作不能完全交给模型自主决策，模型本身会幻觉，必须硬编码规则兜底。

小结

Human-in-the-Loop 的核心不是 “有人在回路里”，而是精准控制什么时候人进入回路。不可逆、高成本、信息不确定、越界、高危操作，请求人工；只读、低风险、可回滚、标准化任务，交给 Agent 自动跑。