2026 年 8 月 29 日
AI Agent 的确认提示，本身就是一道权限边界
事事都要确认，用户就不再细看；只确认目标，授权范围又会宽得危险。真正有用的边界，恰好落在那个会改变现实的具体操作上。
用户对 AI Agent 说：“删掉 Q3 沙盒。”Agent 打开设置，找到对应的工作区，来到删除按钮前。如果它每点一下都要确认一次，这个产品就没法用；如果它把最初那句话当成无限授权，那就太鲁莽；如果它最后只问一句“继续吗？”，用户还是不知道接下来会发生什么。真正难的产品决策，不是要不要保留人工把关，而是这道关从哪里开始、人到底在批准什么，以及这次批准什么时候失效。
所以，确认提示应当被视为权限模型的一部分，而不是 Agent 做好之后再补上的一道客气的摩擦。
两个糟糕的极端
第一种糟糕的设计，是每次状态变更都要确认。打开账单页面？确认。切到“按年付费”标签？确认。填写公司名称？确认。产品看上去很谨慎，但接二连三的确认，只会把用户训练成条件反射式地点同意。系统换来的只是走过场式的“同意”：点了很多次，却没怎么看。
相反的设计，只在一开始问一次：“我来清理一下工作区，可以开始吗？”听上去很高效，直到任务扩展成归档记录、移除成员，再发一封总结邮件。用户批准的是一个目标，而不是每一个后果。一句宽泛的自然语言指令，就这样变成了一个临时的管理员角色。
这两种失败，都源于把对话当成了授权层。对话擅长确立意图，却不擅长界定究竟授予了哪一项具体能力。
Microsoft 2026 年发布的 AI Agent 失败模式分类，从安全角度把这一点讲得很明白。它建议：采用确定性的人工审核；对有实际后果的子操作单独批准；审核描述要从底层工具调用中生成；并根据可逆性和影响范围划分批准等级。守住这条边界的，必须是应用本身，而不是模型。
如果改动 Agent 解释里的一句话，就能决定审核会不会出现，那这个审核就是由文字控制的。真正的权限边界，由应用即将执行的那个操作来控制。
按后果分类，而不是按按钮分类
团队通常会先列一张危险词清单：删除、发送、支付、取消。这有用，但按钮上的文字不是策略。“取消”可能只是关掉一个对话框，也可能是终止一份订阅；“移除”可能只是清空一个筛选条件，也可能是收回某个人的访问权限；“继续”则可能是购买流程里的最后一个按钮。
分类要看操作本身、操作对象，以及它所处的上下文状态。一套实用的策略，可以从五个问题开始：
1. 这个操作会不会产生外部影响，比如发出一条消息、一份邀请、一篇帖子，或者发布一项变更？
2. 它会不会动用资金，或者产生财务上的承诺？
3. 它会不会改变谁能访问数据，或者他们拥有哪些权限？
4. 它会不会删除数据、注销账户，或者变更订阅？
5. 如果做错了，同一个用户能不能迅速、彻底地撤销它？
这样划出的边界，比“所有写操作都要确认”有用得多。
拟执行的操作 · 默认行为 · 原因
读取页面、搜索、筛选或打开标签页 · 直接执行 · 不产生持久的外部影响
填写非敏感的草稿字段 · 执行，并让操作过程可见 · 提交之前可以撤回
修改带有明确撤销入口的本地偏好设置 · 通常直接执行 · 影响范围小，容易恢复
发送、发布、邀请、共享或变更访问权限 · 审核具体操作 · 会影响他人，或越过某条边界
购买、升级、取消、注销或删除 · 在执行前一刻审核 · 涉及资金，或难以撤销
输入登录凭据，或做出受监管的决定 · 必须由用户亲自操作，否则拒绝执行 · 并不是每个操作只要经过批准，就适合委托出去
这和 OpenAI 的 Agent 构建指南里的工具风险模型很接近：它建议从写入权限、可逆性、账户权限和财务影响几个维度给工具评级。关键的一步，是把这些属性写成代码和策略，而不是再加一条可以让模型“自由发挥”的指令。
在后果发生的那一刻再问
批准应当出现得尽可能晚，但一定要在外部影响发生之前。
比如“取消我的 Growth 订阅”。Agent 可以打开设置、进入账单页面、查看当前套餐，全程无需打断用户，因为这些步骤都不会让用户承担任何后果。真正有用的审核，出现在 Agent 已经找到那个实际的取消订阅按钮、并且知道它会影响哪一份订阅的时候。
这个时机让确认提示有了具体的事实可依：它可以直接说出操作和对象，而不是把最初的请求复述一遍。它也避免了让用户去批准一个 Agent 可能根本找不到的操作。
这里有一个清楚的区分：
– 澄清，发生在目标操作或操作对象不明确的时候。如果有两个成员都叫 Alex，“移除 Alex”就需要先问一句。
– 批准，发生在目标操作已经明确、应用准备执行一个有实际后果的步骤的时候。它应当是一个受限的决定：只能在“同意”和“拒绝”之间二选一。
把两者混在一起，对话就会让人抓狂。Agent 问“你确定吗？”，可它其实还不知道用户说的是哪条记录。又或者，它先拿到了批准，后来又碰到另一个确认按钮，就把先前的回答当成了执行这个新操作的许可。
更安全的顺序是：先明确意图，再确定对象，然后审核，最后执行。网站后面弹出的确认，是一个新的可执行操作，理应单独做决定。
确认提示必须描述真正要执行的操作
Agent 嘴上可以说“我只是整理一下工作区”，下一次工具调用却移除了一名成员。这种不一致是恶意为之、被注入了指令，还是单纯搞错了，都无关紧要。批准界面不能靠 Agent 的自我陈述，来描述它正在申请的权限。
审核文案应当从执行对象生成。把应用已经解析出的控件、对象、选定的值、目的地和相关范围都展示出来。“点击 Acme 的‘删除账户’”是有用的；“继续清理”则不是。
Microsoft 的那份分类，把这种薄弱的做法称为“描述洗白”（description laundering）：Agent 给出一段看似无害的摘要，底下却藏着一个后果更严重的操作。它给出的防御办法很直接：批准描述要从实际的工具调用或页面控件中生成，而不是来自模型自由发挥的文字。
即使没有人在攻击系统，这一点也很重要。模型会压缩信息，会省略限定词，会用一个“它”指错对象。执行层手里本来就有准确的参数，审核就应该直接用它们。
– 它之所以出现，是因为确定性的策略对可执行操作做了分类，而不是因为模型主动想问。
– 它用用户能核实的语言，说清操作、对象、目的地和范围。
– 它提供真正可用的拒绝选项，也不会把有后果的步骤藏在一批操作里。
– 它只授权一次尝试，而不是后面的整段对话。
授权应当只生效一次，并与状态绑定
最容易被忽视的问题，出现在用户点击“同意”之后：这一下，到底授权了什么？
假设审核卡片上写着“删除 Q3 沙盒”。卡片还开着，页面重新渲染了，底层元素现在指向的是生产环境的工作区。或者路由变了，或者表单的收件人变了。如果批准只是一个名叫 approved 的布尔值，Agent 就可能在一个用户从未见过的状态上执行操作。
正确的做法是，把批准绑定到待执行操作的指纹上。指纹可以包括元素标识、操作类型、目标标签、目的地、表单状态、所在容器、来源（origin）和路由。在执行前的最后一刻，应用会把当前操作和审核过的那个操作做比对。
只要有任何与安全相关的东西变了，执行就会中止。旧的批准照样作废，所以即使页面又变回原样，它也不能被重放。执行成功了，这次批准同样作废。一次审核，一次尝试，一个没有变过的对象。
这不是多余的繁文缛节。签名请求和一次性令牌遵循的也是同一个原则：权限应当范围窄、可追溯、时效短。Microsoft 针对应用层的指导指出，人工审核应当防止 Agent 自行授权有后果的操作，触发条件由代码强制执行，执行过程中也要能随时介入。与状态绑定的授权，正是让这条原则在动态界面里站得住的方式。
批准只是其中一层，不是整个安全体系
再好的确认提示，也撑不起整个安全模型。操作对象令人困惑，用户就可能批准一个错误的操作；提示词注入可能扭曲通往审核的整条路径；一个被攻破的页面可能呈现误导性的上下文。还有些任务，无论用户是否同意，都应当始终在 Agent 的权限之外。
OpenAI 的 ChatGPT agent 系统卡，把确认机制与模型训练、自动监控、受限能力，以及敏感场景下的主动监督放在一起介绍。这种分层结构，才是正确的思维模型。批准可以限制一次失误造成的损害，却证明不了之前的推理是可靠的。
系统的其余部分仍然需要：
– 对工具和数据的最小权限访问；
– 对禁止操作的对象和敏感输入做确定性拦截；
– 在多步任务进行中随时叫停的控件；
– 每次操作之后，重新读取一遍界面；
– 宣布成功之前，对用户要求的结果做最后一次核查；
– 能把用户请求、审核、执行和结果串起来的日志。
最后这次核查尤其重要。点了“同意”，意思是“你可以尝试这个具体的操作”，并不代表点击生效了、正确的状态发生了变化，或者任务已经完成。
我们为 Barkan 做的选择
在 Barkan 的代操作模式（Do Mode）下，日常的页面跳转和可撤销的界面操作可以直接进行，不必一路确认个没完。凡是被归为删除数据、变更账户或订阅、动用资金、对外沟通或变更访问权限的操作，组件都会在执行前于本地暂停。审核在执行路径中触发，而不是交给模型自行判断。
用户点了同意，这次审核就会与当前的操作对象和页面状态绑定，并在第一次尝试执行时即告作废。如果对象发生了变化，这次批准就不能再用。如果网站弹出了自己的最终确认，那个控件会被当作一个独立的操作单独审核。操作执行之后，Barkan 会重新读取一遍渲染出的界面，再用单独一轮最终核查确认结果，然后才报告完成。
这些选择，只在我们希望有摩擦的地方增加摩擦。目标不是最大程度的自主，也不是最大程度的谨慎，而是在一条用户看得懂的权限边界之内，做成尽可能多的有用的事。
衡量边界本身，而不只是通过率
单看批准率，是一个很差的成功指标。99% 的通过率，可能意味着 Agent 总是对的；也可能意味着确认提示太频繁、太含糊，用户早就不看了。
把这套机制当作一项安全控制来衡量：
– 审核覆盖率：有后果的操作，在执行前被拦下来审核的情况。
– 误打断率：无害操作却触发了审核的情况。
– 分类别的决定率：删除、资金、对外沟通、访问权限和账户变更各类操作的同意与拒绝情况。
– 过期授权拦截：因审核期间对象或状态发生变化而被阻止的尝试。
– 经验证的完成：已批准的操作中，事后确认达到了预期最终状态的那些。
– 叫停与纠正行为：用户在有后果的步骤之前打断或改变方向的任务。
然后，去看两头的具体案例：一头是逃过了审核的有后果操作，另一头是惹烦了用户的无害操作。策略的改进，靠的是让这两类都变少，而不是让每个任务都走向更多的批准。
确认提示，是 AI 产品把一次预测变成一项权限的时刻。要以对待权限授予的严谨来对待它：让 Agent 在可撤销的工作上快速推进，在那个具体的、有后果的操作前停下，展示真正将要执行的内容，并让每一次“同意”在一次尝试之后就失效。
Barkan 在你的产品里完成多步任务，并在那个具体的高影响操作执行之前停下来。
“大多数用户并不想再得到一个答案。他们要么想有人指路，要么想有人直接把事办好。这就是产品的全部。”
Gabriel Lancelot
Barkan 联合创始人
