Agent 需要人工确认的操作怎么设计？人在回路放在哪里？
面试怎么回答
我会按影响范围和可逆性给操作分级：只读和低风险自动执行；可逆的写操作自动执行但记录；删除、覆盖生产表、重跑影响下游的任务、对外发消息、产生费用这类不可逆操作必须人工确认；涉及敏感数据的导出要审批。确认逻辑放在工具执行层强制挂起，不靠模型自觉；复杂任务先确认计划，对外结果发布前确认。确认请求要写清楚影响范围、行数和能否回滚，超时默认不执行，避免对低风险操作频繁弹窗造成确认疲劳。等待时状态持久化，确认后继续。上线初期确认点多，根据审计数据逐步放权。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
Agent 能写 SQL、能重跑任务、能发邮件，但不是所有操作都应该让它自己决定。面试官问 Human-in-the-loop（人在回路），想看的是：你怎么判断哪些操作要人确认，确认流程怎么设计才不会变成形式主义。
哪些操作需要人确认
按「影响范围」和「可逆性」分级：
- 只读、低风险：查元数据、查指标、看日志，自动执行；
- 可逆的写操作：在临时表写数据、生成草稿报告，可以自动执行，但要记录；
- 不可逆或影响大的操作：删除数据、覆盖生产表、重跑影响下游的任务、对外发送消息、产生费用，必须人工确认；
- 涉及敏感数据：导出明细、跨部门共享数据，需要有权限的人审批。
确认点放在哪里
- 工具层强制：确认逻辑写在工具执行层，而不是靠提示词让模型「记得先问用户」。模型调用高风险工具时，系统先挂起，生成待确认请求；
- 计划确认：复杂任务在开始前把计划给人看，比每一步都确认更高效；
- 结果确认：报告、对外的回答在发布前给人审核。
让确认真正有用
- 信息要充分：确认请求里写清楚要做什么、影响哪些表和下游、预计影响多少行、能否回滚，而不是只问「是否继续？」；
- 差异可见：改数据前给出变更前后的对比或抽样；
- 超时有默认值：等待确认超时，默认不执行，而不是默认执行；
- 避免确认疲劳：低风险操作不要都弹确认，否则人会习惯性点「同意」；
- 记录审计：谁在什么时间确认了什么，便于追溯。
状态管理
等待确认时，Agent 的状态要持久化，确认后能从挂起的地方继续，而不是重新开始。这和审批流的设计很像。
逐步放权
上线初期确认点多一些，根据审计记录统计某类操作的确认通过率和出错率，稳定后逐步改成自动执行或抽检。