把人工审批绑定到智能体的具体动作

给 AI Agent 加一个「批准」按钮，不等于真正管住了它。如果审批人看不到具体动作，或者批准后数据、权限已经变化，按钮留下的可能只是一条记录，挡不住错误执行。

作者的主张是：让 Agent 先完成准备工作，在即将产生难以撤销的业务承诺时交给人决策，并在执行前再次核对上下文。它值得程序员读的地方，在于把「有人点头」拆成了可以落实到流程里的控制条件。

审批应该卡在什么位置

原文用供应商付款举例：Agent 可以收集发票、匹配采购订单、核对金额、准备交易。这些步骤风险较低，大多可以撤回。真正付款则不同，资金离开账户，业务也产生了外部承诺。

如果一开始就让人批准「处理这张发票」，审批人尚未看到最终交易，很难判断自己究竟同意了什么。如果钱已经付出才要求确认，控制又来得太晚。

审批应该绑定一个具体、可检查的待执行动作。

因此，付款前展示给人的不能只有一句任务描述，还应包括：

• Agent 使用了哪些系统和记录。
• 这次操作为什么达到人工审批门槛。
• 如果延迟执行，哪些条件可能变化。
• 谁有权批准这次操作。

这些信息分别回答：依据是什么、为什么找我、能否等一等、谁有资格决定。审批人据此判断，批准才有实际含义。

人已经批准，为什么还要再检查

准备和执行之间可能隔着一段时间。期间，发票可能被修改，用户权限可能被撤销，政策可能调整，关联账户也可能出现新的告警。

此时，即使审批记录真实有效，执行依据也可能已经失效。人同意的是当时那个动作，不能默认覆盖之后发生的所有变化。

作者提出的控制可以分成两层。第一层先规定哪些动作必须经过人，例如资金转移、法律承诺、生产环境变更、对外沟通，以及可能影响声誉的操作。

这里的标准是影响大小，而不是 Agent 对结果有多自信。模型很确信，也不能代替业务授权。

第二层放在实际执行之前，再确认三件事：待执行动作是否仍与获批请求一致，执行者是否仍有权限，相关政策是否仍允许执行。任何一项发生变化，就退回重新审核。

一次批准，不应成为上下文变化后仍可执行的通行证。

作者还给出一个验收问题：系统能否向审核者展示 Agent 究竟要做什么、为什么允许做、从请求开始到现在发生了什么变化，以及是谁批准的？回答不了这些问题，多加一个审批按钮也补不上缺口。

我的判断

我认同作者对审批位置的划分。把人工注意力集中在后果重大的决策上，让 Agent 完成前面的准备，比每一步都要求确认更合理。它也比「模型置信度足够高就放行」更符合权限管理的逻辑：判断正确与有权执行，是两件事。

但原文是一套设计主张，没有团队实测、耗时对照或事故率数据。它能解释审批为什么可能失效，尚不能证明这种设计在具体组织里能减少多少等待。

落地难点也没有展开。怎样判断动作与批准内容仍然一致？哪些变化必须重审？最后检查通过后，到真正执行之间再次发生变化怎么办？原文没有给出实现方案。

还有一个前提需要各团队自己补齐：什么算「难以撤销」，不能只靠操作名称判断。同样是生产变更或对外沟通，影响范围也有差别。门槛过宽会让人疲于审批，过窄则会漏掉关键动作。这需要业务规则，不能只留给 Agent 临场判断。

能拿来做什么

• 为日常 AI 编程流程区分准备与执行。读取代码、整理变更、准备发布内容可以先完成；涉及生产环境变更时，再让人检查具体待执行内容。
• 如果用 Node 编排 Agent 工作流，把审批关联到具体动作及其依据，记录批准人和授权信息，避免只保存一句「同意处理」。
• 在执行入口增加最后核对。待执行内容、权限或政策与审批时不一致，就退回审核；同时检查现有界面能否清楚展示变化，帮助审批人作出判断。