Agent 人工复核队列：把人放在高风险决策点，而不是所有步骤后面

“所有动作都让人确认”看起来最安全，实际会让用户把确认当成噪声，最后什么也不看地点击通过。更好的做法是把人工注意力放在真正高风险、低置信度或高影响的决策点，并给审核者足够证据在短时间内判断。人工复核是一个运营系统，不是 UI 上多一个按钮。

建立可解释的分流规则

先按动作影响分层。读取公开文档、生成草稿和格式转换通常可自动完成；发送外部消息、修改权限、导出大量数据、删除资源和触发付款需要更高门槛。再叠加不确定性：工具参数是否完整、检索证据是否冲突、模型是否使用了非预期工具、用户请求是否包含敏感数据。

分流规则应返回明确原因，而不是一个神秘风险分数。例如“该操作将向 350 个外部联系人发送邮件”“当前会话缺少导出权限”“检索到两个相互矛盾的合同版本”。审核者知道为什么被打断，用户也能补充缺失信息。

一个可审核任务至少展示：用户目标、Agent 计划、将调用的工具、关键参数、影响资源、权限依据、来源摘要、风险原因和可选操作。对写操作提供“批准”“拒绝”“要求澄清”“改为草稿”等不同路径，不要只有通过或取消。

证据包必须脱敏且可追溯。审核者应该能跳到原始业务记录，但不应看到无关租户的数据或完整密钥。每次决定记录审核人、时间、理由和最终执行结果，既支持事故复盘，也能反哺后续自动化策略。

把“即将影响客户的生产事故”和“可延后发送的日报”放进同一 FIFO 队列，会让高优先级任务错过时机。队列需要按风险、业务时效、用户等待时间和审核角色分流。超时策略也要明确：过期后自动取消、自动降级为草稿，还是升级给值班人员。

监控审核队列长度、等待时间、批准率、拒绝率、反复澄清率和审核后撤销率。批准率长期接近 100% 可能说明规则过严或审核流于形式；拒绝率突然升高则可能意味着模型、工具或上游数据发生变化。

审核结果应成为评测和策略改进的高价值数据。将批准、拒绝和修改后的正确参数脱敏后，归入失败分类和回放集。不要直接把审核者文本当成无条件训练数据，先确认它反映的是正确业务规则，而不是某位审核者的临时偏好。

随着系统稳定，可以把重复、低风险且高批准率的任务逐步自动化；把新工具和异常模式重新放入人工队列。这个循环让人类从每一步的执行者，变成策略边界和质量标准的维护者，才能同时获得效率和控制力。

人工队列的容量不是无限的。根据任务复杂度估算平均审核时长、可用审核人数和高峰到达率，为每个风险级别设置最大排队长度。超过阈值时，低风险任务可以降级为草稿或延迟执行，高风险任务则应提示用户预计等待时间并升级给值班角色。把所有任务堆在队列里，只会让真正需要判断的请求被淹没。

审核策略也要防止疲劳。连续处理同类批准任务会降低注意力，可以在界面中突出风险变化、随机插入质量抽样，并让高影响决策由不同角色复核。记录审核耗时和修改比例，若某类任务总需要手工改参数，说明问题应回到工具 schema、产品表单或 Agent 计划层修复，而不是长期消耗人工。

最后，为用户提供可理解的状态。告诉他们任务正在等待什么、何时会过期、是否可以自行补充信息或改为草稿。透明的队列状态能减少重复提交，也让人工审核成为可靠产品流程的一部分，而不是不可预测的黑箱。

审核权限应与业务权限分离。能够查看任务不代表能够批准付款、修改权限或导出客户数据；高风险类别需要明确的角色和双人复核规则。定期复查谁拥有审批权、哪些策略被绕过以及哪些任务反复超时，能防止人工队列本身成为新的越权入口。

在发布新审批策略前，用历史脱敏任务做回放，确认高风险任务没有漏进自动路径，低风险任务也不会无谓地堆积。把策略调整当作一次可验证的产品发布，才能避免审核队列随着规则增长而失控。

这也能让审核者对自动化边界保持一致预期。

每次策略变更后抽样检查被自动批准和被人工拦截的任务，确认分流理由、证据包和最终业务结果一致。这个小规模验收能在规则扩大影响前发现遗漏的风险类型。