为 AI 代理建立分级审批规则

Agent 能不能删生产数据，不能等到事故复盘时才决定。原文给出的方案是一张「人在回路」审批矩阵：先按后果给动作分级，再规定哪些能自主执行、哪些必须审批，以及谁来负责、超时怎么办、如何留痕。

它值得程序员读的地方，是把「高风险操作找人确认」拆成了可执行规则。不过，这是一套治理建议，原文没有提供团队实测、事故下降比例或审批耗时数据。我们可以借用它的设计方法，不能直接认定它已经证明了效果。

先给动作分级，别只给工具开权限

原文的第一步不是找审批人，而是盘点 Agent 到底能做什么：读取记录、起草消息、修改配置、付款、删除数据。漏掉动作，后面的审批规则就会留下缺口。

这对接入工具的 Agent 很关键。同一个数据库工具，既可能查询测试数据，也可能删除生产记录。只按工具名称授权，区分不了两者的后果。

作者提出四个权限等级，作为风险负责人调整规则的起点：

等级	动作示例	默认控制
Tier 0，只读	查询知识库	自主执行并记录日志
Tier 1，可逆写入	起草工单、更新预发布记录	自主执行，抽样复核
Tier 2，影响业务	修改面向客户的设置	执行前获得一次审批
Tier 3，不可逆或受监管	删除生产数据、付款、授予访问权限	双人审批，超时也不能自动放行

分级还要看三个维度：影响范围、数据敏感度、财务敞口。对应的问题分别是：一次错误能波及多少用户、系统或记录？是否接触个人、财务或受监管数据？最坏但现实的结果会造成多大损失，包括清理成本和客户影响？

动作的等级取三个维度中的最高等级，而不是平均值。

这样做能避免一个花费很少、却涉及敏感数据的动作被评成低风险。不过，原文没有给出具体评分表，也没规定多少条记录算高风险。团队仍需结合自己的数据和业务补齐边界。

此外，只读只是动作形式。按作者后面的最高风险原则，读取敏感数据也可能需要更高等级，不能看到「查询」就直接归入 Tier 0。

自主执行的条件，必须能被程序检查

有了等级，还要把「允许自主执行」变成运行时条件。作者列出了四项检查：

1. 动作所属等级允许自主执行。
2. Agent 的置信度或验证分数达到约定下限。
3. 目标系统、账户或数据集位于批准名单中。
4. 本次执行的花费、操作量或记录数没有超过限制。

其中任何一项不满足，动作都要暂停并进入审批。每个阈值还要有负责人，调整时记录原因。

这里最有用的要求，是把检查放进 Agent 的执行路径。写在提示词或团队文档里，只能表达期望；真正调用工具前的检查，才能拦住越界操作。对 Node 编写的 Agent 服务，可以把它理解为工具调用前的一道统一关口：先检查动作和参数，再决定执行还是等待审批。

但置信度这一项需要打个问号。原文同时提到了 Agent 自身置信度与验证分数，却没有说明两者如何产生、如何校准，也没有证明某个分数能预测操作是否安全。模型认为自己有把握，不能替代目标名单和数量上限这些可核验条件。

作者还要求为例外设置升级规则。验证分数不足、两条策略冲突、目标不在批准名单中、反复重试却没有进展，都应转交人工。

没有出现在矩阵里的动作，先按 Tier 3 处理，直到人工完成分类。

这条规则堵住了「规则没写，所以可以执行」的缺口。但它也要求团队持续维护动作清单，否则大量普通请求都会被推到最高等级，审批很快就会积压。

审批能否有效，取决于责任、超时和记录

谁在线就找谁确认，解决不了责任归属。作者建议按风险类型指定角色：工程负责技术正确性，安全负责访问权限和暴露风险，业务负责人负责财务与客户影响。矩阵里写角色，不写固定姓名，便于应对休假和组织调整。

审批强度也要分层。有明确回滚方式的 Tier 2 变更，通常由领域负责人单人审批；涉及资金或权限的 Tier 3 动作，通常由领域负责人加安全负责人双人审批；新动作类型和策略例外，则交给跨职能风险小组评审。

每次请求还要规定响应窗口、备用审批人和超时处理。原文没有给具体分钟数，但明确要求：Tier 3 超时后继续阻塞，并升级请求。沉默不能算同意。

审批人收到的材料也决定了审批质量。请求应包含拟执行动作、Agent 给出的理由、使用的输入，以及触发复核的等级。让审批人临时翻记录、猜上下文，只会让审批变慢，或者变成机械点击。

执行之后，至少要留下动作及等级、审批人及决定、实际执行结果。作者进一步建议，把审批决定与对应动作日志放在一起，审批请求集中到一个入口，避免散落在 Slack、邮件和工单中。

矩阵也不是写完就结束。作者建议从每季度复核开始，检查审批率、覆盖原规则的原因和险些出事的情况。总能原样通过的动作，可以考虑降低等级；经常需要例外处理的动作，可能需要收紧阈值。每次复核都应形成具体调整。

我的判断

这套方法最有价值的地方，是把审批从聊天里的「确认一下」，推进到执行路径里的明确控制。相较于让模型自己判断风险，动作分级、目标名单和执行上限更容易检查，也更方便追查责任。

相较于所有操作都找人批准，它又给低风险工作保留了自主空间。代价是需要维护动作清单、角色、阈值和日志，还得有人及时处理请求。原文没有说明这套维护工作的成本，也没给出与其他方案的对照数据，因此仍属于经验性框架。

我也不会仅凭「每次都获批」就支持降级。原文把它列为候选条件，但审批率高也可能来自审批疲劳，或当前请求样本过于简单。是否扩大自主范围，还应结合执行结果和险情记录判断。

另外，可逆不代表影响小。面向客户的配置即使能回滚，也可能在回滚前造成损失；授予访问权限即使能撤销，也可能已经发生数据读取。作者按后果分级的思路是对的，具体分类必须由团队结合实际情况完成。

能拿来做什么

• 给现有 AI 编程或运维 Agent 列一份动作清单，把查询、起草、配置修改、权限变更和删除分别列出，再按影响范围、敏感度和损失分级。
• 在 Node 工具调用入口集中检查目标环境、批准名单和单次操作上限，让审批规则真正参与执行，并为每次阈值调整记录负责人和原因。
• 为生产配置修改、数据删除等请求准备统一审批材料，展示目标、参数、预期影响和可用的回滚方式，并明确备用审批人与超时处理。
• 定期把审批记录与执行结果一起复核，依据真实结果调整自主范围；遇到尚未分类的新动作，先暂停，再补齐矩阵。