Agent 等待确认时，不应该变成一排模糊弹窗
Agent 审批队列，是团队把 Axon Agent 运行中必须人工确认的动作，按原因、风险、owner 和处理时限组织起来的工作方式。没有队列纪律时，AI 数字员工很容易从自动化工具变成等待室：每周都有重复确认，每个弹窗都说“是否继续”，用户不知道它到底要发邮件、覆盖文件、引用新来源，还是只是生成一个内部草稿。
OWASP Top 10 for LLM Applications 提醒团队关注越权、提示注入和敏感动作；NIST AI Risk Management Framework 也强调治理和管理过程。Axon 的产品判断是：高风险动作需要确认，但确认必须带上下文。没有上下文的确认，只是把风险推给用户。
这篇文章和 Trust Mode 预检、Agent 异常处理与 Trust Mode 以及 Agent 负责人 是一组。预检定义边界，异常处理定义停手方式，Agent 审批队列负责让“等待确认”不变成低效堆积。
确认动作要能被判断
一个坏的确认请求通常长这样：Agent 需要继续，是否允许？ 这句话没有说明影响范围。用户只能猜：继续会不会外发？会不会覆盖？会不会改变客户承诺？会不会花钱调用 API？
好的审批不是让用户点得更多，而是让用户一眼看出为什么必须停下。
队列里每个待处理项至少应该带四个信息：
- 原因：为什么不能自动继续。
- 风险：外部发送、覆盖产物、资料不确定、付费调用，还是权限变化。
- owner：谁有资格判断。
- 过期：这个确认晚于什么时候就失去意义。
这些信息让审批成为工作，而不是弹窗。低风险草稿不应该排进队列；真正需要人判断的动作才应该留下。
一条审批记录应该短而具体
Agent: 每周客户反馈摘要
等待动作: 将报告发送给客户成功团队邮箱组
停下原因: external_send
依据: 报告已生成，来源文件为 2026-06-28 批次
风险: 邮件会进入外部协作空间，不能自动发送
owner: 客服运营负责人
建议: 审阅摘要和客户名称后再允许发送
过期: 2026-06-30 18:00
这条记录比“是否发送？”更能帮助 owner 判断。它也让 Agent 运行状态 更有解释力：不是运行卡住，而是停在一个明确的确认动作上。
队列里不该混在一起的三类事
- 低风险确认：例如生成内部草稿前询问标题偏好。通常不应该进入审批队列。
- 风险确认：外发、覆盖、发布、付费调用、访问新资料。这类需要 owner 判断。
- 来源缺失：这不是审批，而是
needs_source。它需要补资料，不需要用户点“同意”。
把三类事分开，队列才不会被噪音淹没。否则团队会养成坏习惯：看到确认就点通过，真正高风险动作反而失去保护。
审批也要有退出机制
很多队列的问题不是确认太少，而是确认没有过期。一个月前等待发送的报告，今天通过已经没有意义。一个价格表相关的审批，如果来源变了，也不应该继续沿用原判断。
实用规则很简单：
- 和外部发送有关的审批，应有明确截止时间。
- 和来源不确定有关的审批，来源更新后应重新生成。
- 和覆盖已有产物有关的审批，应展示被覆盖对象。
- 和付费或高成本生成有关的审批，应显示预算或次数边界。
这样做不会削弱自动化。相反，它让低风险步骤更快自动，让高风险步骤更少靠临时沟通。
FAQ
Q1：Agent 审批队列是不是每个 Agent 都需要？
不是。只生成内部草稿的一次性 Agent 可以很轻。会外发、覆盖、发布、定时运行或调用付费能力的 Agent 更需要队列纪律。
Q2：审批项应该由谁处理？
通常由 Agent owner 处理。涉及下游团队或外部对象时，相关业务 owner 也应该加入判断。
Q3：审批太多怎么办？
先检查是不是把低风险动作也放进队列。审批队列只应该承接真正需要人工责任的动作。
Q4：审批通过后是否需要记录？
需要。至少记录谁批准、批准了什么、依据什么资料、是否有过期时间。
Q5：审批失败算 Agent 失败吗？
不一定。高风险动作被拒绝可能是正常结果。重要的是状态清楚，产物和原因能追踪。
下一步
开始使用 Axon 运行带 Trust Mode 的 Agent 时，不要只设计“是否确认”的按钮。先设计 Agent 审批队列：确认原因、风险类别、owner、过期时间和处理结果。开始使用时，让自动化继续自动，让必须人工承担责任的动作真正可判断；了解更多时，复查哪些确认应该进入预检，哪些必须保留给 owner。