权限提示是一个 UX Bug：当“人在回路”沦为“人工橡皮图章”

观察一名开发者使用 Agentic 编程工具一小时，你会看到同一个动作重复四十次：弹窗出现，“允许 Agent 运行 git status 吗？”，手在眼睛读完之前就移到了批准按钮上。到第四十次提示时，提示内容根本没被阅读。它变成了一个用户学会全速通过的减速带。

这是“人机回环”（human-in-the-loop）的一种无声失败。架构图上仍然显示人类在把控每一个危险动作。审计日志仍然记录着对每个命令的明确批准。但人类已经停止了评估。他们变成了一个接入控制流的生物版 “yes” 函数 —— 虽然身在回路中，却不贡献任何判断。权限提示本应是一项安全控制，它却退化成了附带确认对话框的系统延迟。

这一点之所以重要，是因为没有人刻意如此。没有产品经理写过 “用户应当盲目批准”。它是 Agent 的行为方式与人类在重复负荷下的注意力机制相互作用而产生的。由于它是悄然发生的，往往只有在事故发生后才会被发现 —— 此时，事后复盘（post-mortem）会写下 “用户批准了该操作”，并将其视为分析的终点，而非起点。

审批疲劳不是纪律问题

当你注意到用户不经阅读就点击批准时，第一直觉是责怪用户。训练他们更加小心。在 “你确定吗？” 之上再加一个 “你真的确定吗？”。这种直觉是错误的，而且这种错误在 AI 领域之外早有定论。

安全运营团队在 “警报疲劳”（alert fatigue）的名义下已经忍受了二十年。数据很惨淡：一个典型的安全运营中心每天处理约 960 个警报，大型企业则会看到数千个。大约 90% 的中心报告称自己被积压工作和误报所淹没。2025 年 SANS 检测调查发现，误报和警报疲劳正逐年显著恶化。其结果并不是分析师懒惰，而是人类的警觉性是一种可耗尽的资源，而一连串大多良性的信号会按可预测的进度耗尽它。

航空业称这种现象为 “自动化懈怠”（automation complacency） —— NASA 的报告系统将其定义为 “基于对系统状态令人满意的无理假设，而可能导致不警觉的自我满足感”。对使用 AI 诊断工具的维修技师的研究发现，在使用六个月后，他们接受 AI 输出而不进行独立验证的比例超过了安全操作阈值。这些是从事安全关键工作的受过训练的专业人士。他们不是粗心大意，他们是人类，而当你喂给人类重复的、低风险的确认请求时，人类的注意力正是会这样表现。

因此，橡皮图章式的盲目审批不是一个需要通过培训消除的用户缺陷。它是系统要求审批过于频繁的预期输出。如果你的设计依赖于人类在数百个几乎相同的提示中保持敏锐，那么你的设计就依赖于人类并不具备的属性。修复必须是结构性的。

提示数量才是 Bug 所在

这是一个令人不安的重新审视：Agent 发出的审批提示数量并不是一个可以随意调高的安全拨盘。每增加一个提示并不等同于增加一份边际安全性。超过一个相当低的阈值后，每增加一个提示实际上都会降低安全性，因为它加速了用户坠入反射性批准的速度 —— 这种退化适用于每一个提示，包括那个真正重要的提示。

把它想象成一项预算。一个用户在每个 session 中拥有有限数量的、真实的、专注的批准次数 —— 可能是十次，也许二十次，之后模式匹配就会接管大脑。Agent 每发出一份提示，都在消耗这项预算。如果 Agent 只是请求读取文件、列出目录、检查 git 状态和运行测试 —— 这些都是安全且可逆的操作 —— 它就白白烧掉了预算。当破坏性的 rm -rf 或生产数据库迁移到来时，用户已经处于自动驾驶状态了。

这意味着设计纪律不是 “对危险动作进行提示” —— 几乎所有人已经做到了这一点。设计纪律应该是不要对其他任何事情进行提示。安全、可逆、只读的操作根本不应该产生对话框。做得好的 Agentic 编程工具会在不询问的情况下读取项目文件、列出目录并运行明显无害的命令，而将中断留给那一小部分真正值得人类介入的操作：在工作目录外写入、触碰密钥、部署到生产环境、运行破坏性的 shell 命令。目标是让提示变得足够稀少，以至于稀少本身就是一种信号 —— 当对话框出现时，你作为用户的前验判断应该是 “这很不寻常，我应该仔细看看”。

风险分级，以及为什么信任应当衰减

一旦你接受了提示（Prompts）是稀缺资源这一观点，你就需要一种原则性的方法来决定哪些操作值得触发一次提示。一个有用的框架是根据两个维度对 Agent 的每个操作进行分类：外部影响和可逆性。

一个没有外部影响的只读操作——检查代码、查询状态——不需要关卡。一个具有外部影响但可逆的操作——将草稿发送到暂存频道、更新非关键记录、创建分支——可以在有时被称为“人在回路旁”（human-on-the-loop）的模式下运行：Agent 执行操作，人类观察输出流，如果发现异常则在事后进行干预。只有那些不可逆或高风险的操作——转账、以公司名义发送外部邮件、修改生产环境——才应该拦截并等待人类明确表示“同意”。

在实践中，有三个特性使这一机制生效。首先，它应该由策略层强制执行，而不是由 Agent 自己的代码执行。散布在 Agent 逻辑中的规则会脱离覆盖范围且难以审计；一个中央策略引擎可以统一应用相同的分级标准，并为你提供一个集中的检查点。其次，提示应该显示后果，而非命令。“允许 psql -f migrate.sql 吗？”是在要求用户在大脑中执行 SQL。“这将从生产环境的 users 表中删除 3 列”则是疲惫的人类真正可以评估的信息。差异（Diff）、爆炸半径、金额——这些才是一个知情审批（Informed approval）的内容。

第三点，也是最反直觉的一点：信任应当按操作类别衰减，而不是累积成一个通用的许可。一个正确运行了 200 个测试命令的 Agent，已经赢得了无需询问即可运行测试的权利，但它并没有赢得任何关于部署的权利。当它尝试一类新操作时，审批关卡应当重新出现，因为胜任能力的证据是特定于类别的，你的安全模型也应当如此。如果一个系统允许在某个领域的良好表现静默地解锁另一个领域，那么它就是在训练用户期待提示消失——这只是通往“橡皮图章”式盲目审批的一条更慢的路径。

在“橡皮图章”产生危害前对其进行监测

这种失效模式在事故发生前是不可见的，这意味着你必须主动去寻找它。好消息是，“橡皮图章”式审批具有明显的行为特征，且测量成本很低。

最能说明问题的指标是审批延迟（Approval latency）——即提示出现到用户解决它之间的时间。绘制这个分布图。一个健康的分布在“多秒级”范围内具有权重，因为阅读和评估需要几秒钟。一堆亚秒级的处理结果并不代表用户操作快，而是代表用户在对话框完成渲染之前就已经做出了决定。亚秒级的批准从定义上来说就不是知情的批准。你可以对低于（例如）800 毫秒的批准比例进行告警，并将该比例的上升视为监督失效的先行指标。

将此与按操作类型细分的批准率结合起来。一个对所有内容都 100% 批准的用户并没有在行使判断力；一个健康的审查者总会拒绝或编辑某些东西。如果每个类别的批准率都固定在 100%，那么这个回路就只是个摆设。还要观察会话内的趋势——如果审批延迟从第一个提示到第四十个提示稳步下降，你就是在实时观察疲劳的累积，这提醒你该会话触发了过多的提示。

这些指标本身并不能告诉你 Agent 做了错事。它们告诉你的是，如果 Agent 做了错事，人类将无法捕捉到它。这正是你希望在事故发生前、而非事故发生后得到的警告。

“人在回路中”首先是 UX 问题，其次才是安全问题

这一领域最深刻的错误是将审批关卡视为 UX 团队负责渲染的一个安全功能。事实恰恰相反。安全属性——“人类对该操作进行了有意义的评估”——只有在界面产生了一种使评估成为可能的心智状态时才存在。如果用户感到疲劳，如果提示显示的是命令而非后果，如果对话框是第四十个完全相同的对话框，那么无论审计日志怎么记录，安全属性根本就不成立。

这就是为什么“用户批准了它”并不是一个结论。人类无法进行有意义评估的批准不是监督，而是审计日志的“不在场证明”——一个为了事后追责而存在的记录，而不是一个防止事故发生的控制措施。当一份事故复盘止步于“用户已批准”时，它就误把“点击的存在”当成了“判断的存在”。

这其中还涉及安全问题，而不只是可靠性问题。如果攻击者能影响 Agent 的输出——通过 README 中的提示词注入（Prompt injection）、有毒的 Issue 或被劫持的工具响应——他们并不需要攻破你的审批关卡。他们只需要将一个恶意操作埋没在流式的日常操作中，让审批疲劳完成剩下的工作。第四十个提示是攻击者最好的朋友。一个保持提示稀缺且后果易读的设计不仅是更好的 UX，它更是隔离受污染 Agent 与保持阅读习惯的人类之间的屏障。

所以，实际的结论是：停止将提示的数量作为衡量产品严谨程度的标准。要把它们看作是你正在消耗的预算。对操作进行分级，只让不可逆的操作中断流程。显示后果，而非命令。让信任按操作类别衰减。监测审批延迟，以便发现“橡皮图章”的形成。当你在写下一份事故复盘时，不要使用“用户已批准”这句话——而要问界面是否曾让知情后的审批成为可能。如果界面没有做到这一点，那么 Bug 就不在回路中，而是在提示里。