人点头点不过来了：Agent 权限审批要用分类器而不是弹窗
一个改动值得当成工程信号来读：某编码类 Agent 工具把”每一步都要人批准”改成默认自动模式——由自动检查拦截高风险操作，用户仍然可以切回手动；此前的演进路径里，判定用的分类器从本地改到服务端推理，审查范围从显式的高危命令扩展到只读类与受限执行范围内的命令，未配置权限模式时默认走自动。媒体的转述里还带出一组受控测试的结论，两个方向都反直觉。
先说这组结论，因为它们决定了架构该怎么画。在厂商与媒体披露的受控测试里，一路由人工逐步审批时，识别出危险命令的比例明显低于另一路由自动分类器拦截的比例；同一个人连续处理到数十次弹窗之后，通过率显著上升。两组现象合起来指向一句话：人不是可靠的闸门，人是会被耗尽的闸门。运行隔离与提示注入防护是另一层的事，站内已有一篇专门谈过，这篇不谈，只谈”该问谁、什么时候必须问人、问人的那几次怎么让它有效”。
一、逐步审批失效的机制，比”点太多”更具体
弹窗数量与任务步数成正比，人的注意力与步数不成正比，这是第一层。真正让审批失去意义的是后面三个衍生现象：
不看参数就点确认。命令文本长、参数多、路径深，人在第三次之后就开始只扫开头几个词。审批界面上”影响对象”和”参数”这两块信息，如果不在同一视野内，人基本不会去读参数。
把批量批准当效率优化。”这次任务里后续同类动作都不再问”这类便利开关，本质是把一次判定复用成 N 次判定，而同类动作的影响对象每次都不同。
把”没有报警”当成”安全”。自动检查给出的沉默放行，在人眼里会被理解成系统认可，而实际含义只是”置信度不足以触发拦截”。沉默背后是两种完全不同的结论——判定为安全、判定不了——这两者在界面上必须分开，否则审批者对系统的信任会建立在一个错误前提上。
所以正确的改法不是”少弹窗”，而是把审批者从人换成一套分层判定，人只留在少数必须留的位置上。
二、把”要不要问人”拆成五个可判定的维度
一个动作该走哪条路，取决于五个彼此独立的性质。把它们拆开，才有分层的可能；混成”风险高不高”一个分数，判定就只能靠人。
不可逆性：这个动作执行后，能不能靠系统自己变回去。删数据、覆盖线上配置、对外打款、发出后无法撤回的消息、清理历史版本，都是不可逆。这一维只看后果的可撤销性，不看动作看起来是否寻常。
外发性：数据有没有离开边界。读出一份含个人信息的表，是外发链条的第一步；把上下文内容写进外部请求体、把文件上传、把日志发到第三方服务，都是外发。这一维和”读”与”写”无关，只和方向有关。
越界性：动作作用的对象，是否在本次请求声明的范围之内。用户让它改一个目录里的文件，它去改了另一个服务的配置，即使动作本身温和也是越界。这一维需要一个显式作用域定义，没有作用域就无法判定。
放大性：一次动作是否导致批量后果。对单行生效的更新与一条没有 WHERE 条件限定的更新，代码上只差一处，后果规模完全不同。这一维要看预估影响面，而不是看意图。
隐蔽性：出了问题，结果能不能被察觉。改权限位、改定时任务的执行账号、改缓存过期策略这类动作，异常要等很久才显形，因此不能靠”事后有人会发现”来兜底。
每一维都需要系统输入而不是模型自述：动作语义类别、目标对象标识、展开后的完整参数、所属环境与凭据作用域。这就是为什么判定必须发生在执行前的最后一刻，而不是发生在计划生成阶段。
三、五种判定各自的正确落点
| 判定维度 | 主落点 | 兜底动作 | 留痕要求 |
|---|---|---|---|
| 不可逆性 | 硬编码拒绝规则，由用户或企业自定义，优先级最高 | 不在拒绝表内的不可逆动作，转人工确认并给出可撤销性说明 | 命中的规则标识、规则版本、动作参数快照 |
| 外发性 | 服务端分类器判定，命中即必须人确认 | 默认拒绝未知外发目标；外发内容做敏感字段预检 | 目标标识、被判定为敏感的内容类别 |
| 越界性 | 作用域配置层判定（配置里声明可写范围，不在范围内直接拒） | 请求扩大作用域时转人工，并要求人工改写范围 | 声明作用域与实际目标对象的差值 |
| 放大性 | 需要人确认，且界面必须先给出预估影响面 | 影响面无法预估时按最大可能值处理 | 预估依据、审批人选择 |
| 隐蔽性 | 先降级为只读执行或影响预览，再决定是否放行 | 变更后进入自动核对队列，与变更前基线比对 | 预览结论与实际执行结果的差异 |
五个维度都不成立的低风险动作，直接放行，不进任何队列——这一条要写进设计，否则系统会退化成”所有动作都要有人看一眼”，那和弹窗没有区别。
表里”只读降级”这一项需要限定含义：它指把写操作先换成一次只读的影响预览，比如列出将要修改的对象、生成变更集而不合入。它不涉及运行隔离机制本身，那是另一层。
四、分类器放在服务端：换来口径统一，付出三笔账
收益很清楚。判定口径全环境一致，更新即时生效，不会出现客户端配置漂移——本地规则一旦被各自修改、版本参差，同一个动作在两台机器上得到不同结论，审计就无法解释，而这类漂移在有多套开发环境的公司里几乎必然发生。
代价有三笔，都要在设计里还掉。
离线不可用。链路断了或者服务不可达时，系统必须有明确的降级策略。正确写法是：本地只保留硬拒绝规则，其余一律转人工，绝不允许静默放行。把”判定服务不可用”实现成”跳过判定”，等于给分层机制开了一个后门。
链路延迟。判定发生在执行之前，就必然进入关键路径。要给判定设延迟预算，并且超时的处置是降级为询问而不是降级为放行。这条纪律看起来只有一句话，但它决定了系统在判定服务不可达、超时时的行为是保守还是鲁莽。
审计要留判定依据快照。每一次放行或拦截，都要记下判定发生时的分类器与规则版本、输入摘要、命中的判据、最终决定。没有这一层，事后无法回答”为什么那一次没问我”，而对一个自动放行系统来说，这类问题一定会被问到。
还有一条常被误解的边界：硬拒绝规则必须由用户或企业自定义，且优先级高于自动判定。分类器只被授权”多问一句”，永远不能覆盖一条显式拒绝。少了这条约束，”自动模式”的实质就是未经同意的扩权。另外，规则要按动作语义与最终展开参数来写，不要按命令字符串写——别名、编码、变量拼接、把命令塞进解释器都能绕过字符串匹配，只在执行前对完整参数求值才有意义。
五、审批被替代之后，信任靠什么重建
把人的确认撤掉，等于撤掉了团队唯一的安全感来源。补回来靠下面这几层结构。
可回看的动作流水。每一步记录意图、参数、影响的对象、可撤销性标记和判定来源（硬规则、分类器还是人工）。这份流水的第一用途不是审计，是让审批人能回看自己那几次判断的后果，从而校准下一次判断。
可撤销性设计，把不可逆变可逆。删除走软删除并保留恢复窗口；写入先进暂存区而不直接落到目标；对外发送先落草稿并留出延迟窗口；关键变更走变更集先审后合；对共享数据的改动用影子写入，新旧两份并行一段时间再切。这一层做到位，前面那张表里”不可逆性”一行的拦截压力会自动下降一大截——因为可回滚的动作不需要人来看。
事后纠偏。一键回滚与批量补偿要有，且回滚动作本身要走同一套判定并被记录，否则回滚会变成绕过权限的通道。
身份与凭据的衔接。Agent 用谁的身份执行，这个映射要能被回答，因为它决定审计责任归属；长期凭据的作用域按项目、库、目录收窄；执行时优先临时凭据、单目标、最小权限；密钥绝不进上下文——一旦进了上下文，它就成为外发性判定的一个攻击目标，而这类目标会被写进模型输出的可能性永远不为零。
灰度节奏按同一套结构推：先只读再写；按目录、库、项目逐级放开自动放行；在发布窗口、结算时段、批处理执行期这些高风险时段，冻结自动放行改回必须人工确认。判定的严格程度应该跟着环境状态走，而不是跟着配置一次性设死。
六、洹拓视角：把”不可自动放行的动作清单”当成交付物
我们在交付 Agent 类项目时，会要求这份清单和功能清单一同签字。理由是：功能清单说明系统能做什么，权限清单说明系统在什么情况下必须停下来问人，后者决定这个系统敢不敢接生产环境的凭据。清单要能落到具体动作语义上，”删除数据”不算一条，”对客户主表执行不带条件限定的删除”才算一条。
一份可以直接照着核对的落地检查表：
- 是否存在用户或企业可自定义的硬拒绝规则，且优先级高于任何自动判定。
- 判定服务不可用时，系统的默认行为是转人工还是放行。
- 审批界面是否同屏给出影响对象与完整参数，是否给出预估影响面。
- 人工确认的触发条件是按五个维度定义的，还是按命令字符串黑名单定义的。
- 动作流水是否记录判定来源、分类器与规则版本、参数快照。
- 不可逆动作是否已尽量改造成可回滚形态（软删除、暂存区、变更集、影子写入）。
- Agent 使用的凭据是否为短时、单目标、最小作用域，密钥是否确认未进入上下文。
- 高风险时段是否能冻结自动放行，灰度是否按目录、库、项目分级推进。
分层机制的价值不在”少弹几次窗”，而在于把人的注意力留给真正需要判断的那少数动作，剩下的用结构、留痕和可回滚兜住。剩下的弹窗越少，每一次弹窗的可信度才越高——审批的有效性从来不是由次数决定的，是由人点开它时还愿不愿意读参数决定的。