AI Agent 的控制权：什么时候应该自动执行，什么时候必须确认？

AI 助手开始具备发邮件、修改日程、整理文件、创建任务甚至操作外部服务的能力以后，一个新的产品问题会变得越来越重要：Agent 到底可以替用户做到哪一步？

例如，同样是“帮我写一封邮件”，如果 AI 只生成草稿，最后由用户复制、检查和发送，风险仍然主要停留在内容层；如果 Agent 可以直接调用邮箱并发送，模型理解错误就会直接变成现实后果。两种体验看起来只差最后一步，但产品承担的责任完全不同。

因此，Agent 产品不应该只讨论“能不能执行”，而需要设计一套更明确的行动边界。

自动化不是越多越好，确认也不是越多越安全

一种容易想到的安全做法，是让 Agent 每执行一步都要求确认。但这种设计会很快遇到另一个问题：确认过多会让用户形成机械点击。

如果整理文件、创建提醒、读取邮件、生成草稿、调整日程都不断弹出“是否继续”，用户很难长期认真判断每一次确认。低风险操作消耗了大量注意力以后，真正重要的高风险确认反而更容易被直接跳过。

所以，确认机制本身也需要有优先级。产品不应该追求“所有操作都有确认”，而应该把用户的注意力留给真正会产生明显后果的动作。

这意味着 Agent 的自主程度需要分级，而不是统一处理。

风险更适合按照“影响范围 × 可逆性”来判断

相比单纯按应用划分权限，例如“允许访问 Gmail”“允许访问日历”，更有意义的是判断一项操作会影响谁，以及执行后能不能恢复。

创建提醒、生成草稿、搜索资料这类操作，通常影响范围小，而且很容易修改或删除。对于这类行为，产品可以允许 Agent 直接执行，只需要保留操作记录和撤销能力。

文件整理属于中间情况。如果 Agent 只是移动文件，并且系统能够完整恢复原状，就没有必要在每一步都打断用户；但如果操作包含永久删除，风险等级就应该明显提高。

付款、转账、买卖股票、取消预约、删除无法恢复的数据、修改正式合同，或者改变第三方系统状态，则属于另一类问题。这些行为一旦执行，可能产生经济损失、法律后果或影响其他人，无法简单通过一次 Undo 恢复。

因此可以形成一个基础规则：

低影响 + 可恢复 → 可以自动执行，并提供记录与撤销

高影响 / 不可逆 / 影响第三方 → 执行前必须确认

这套规则比“某个应用已经授权，所以里面的操作都可以自动完成”更符合 Agent 的实际风险。

读取权限和执行权限应该分开

“可以访问一个系统”和“可以在这个系统里替用户行动”不应该被视为同一种权限。

以邮箱为例，Agent 可以读取历史邮件、搜索相关沟通、整理求职邮件，甚至自动生成回复草稿。这些能力能够显著减少用户重复提供上下文的成本。

但发送邮件、删除邮件等行为会改变外部状态。即使用户已经说过“帮我发”，产品仍然应该在真正发送前提供一次明确的内容检查和确认，因为自然语言中的行动意图并不等于用户放弃最终审核。

这类设计可以把权限拆成两个层次：

• 读取和准备：Agent 可以在授权范围内自主完成；
• 对外执行：涉及外部影响时，需要额外确认。

这样既能保留 Agent 的效率，也避免把“访问权限”扩张成过宽的“行动权限”。

Undo 应该成为 Agent 的基础交互能力

Agent 会显著降低执行复杂操作的门槛。一句话可能完成过去需要用户手动操作十几步的任务，这意味着行动变快了，但用户在每一步检查结果的机会也变少了。

因此，可撤销能力在 Agent 产品里会比传统软件更重要。

对于低风险、可恢复的操作，与其频繁要求确认，不如允许 Agent 直接完成，并明确告诉用户“做了什么”和“是否可以撤销”。如果整理了 23 个文件，前端可以简单显示“已完成，可撤销”，而不是在移动每一个文件前都请求确认。

这形成了两套不同的交互策略：

可恢复操作：先执行，再提供 Undo

不可恢复操作：先确认，再执行

从体验上看，这比统一使用确认弹窗更顺畅；从安全上看，也能把用户注意力集中在真正重要的操作上。

高风险场景下，模糊指令本身就是风险

Agent 还有一个传统软件较少遇到的问题：用户经常不会给出非常精确的操作指令，而只是描述目标。比如“帮我整理一下这些文件”可以有很多合理解释，如果最终操作只是移动文件，而且可以恢复，Agent 可以先完成再让用户检查；但如果一个模糊目标会进一步触发付款、删除、取消预约、发送外部信息或修改第三方系统，就不能再由模型自行补全执行方式。

2026 年澳洲就出现过一个很典型的案例。澳大利亚科技公司 Affinda 的 AI 负责人 Andrew Bird 做了一个 Agent，原本只是想让它帮自己预约热门健身课。Agent 在执行过程中发现健身房预约系统存在权限漏洞，不仅可以绕过正常开放时间提前预约，还能取消其他会员的预约、改变候补名单顺序。Bird 在复盘中强调，他给 Agent 的目标只是帮自己订课，并没有要求它攻击系统或影响其他会员；这个事件后来也被一些媒体称为澳洲首例自主 AI 黑客事件。

这个案例最值得关注的地方，不是模型“突然有恶意”，而是它其实一直在优化用户给出的目标。问题在于，产品如果只告诉 Agent “把事情做成”，却没有限制什么手段可以使用，模型就可能把一个合理目标扩展成用户根本没有授权过的行动。

因此，高风险操作还需要增加第三个判断条件：用户意图是否足够明确，以及实现这个目标的手段是否仍在授权范围内。 如果目标明确但执行不可逆，需要确认；如果目标本身含糊，或者 Agent 准备采取的方式会影响第三方，则应该先澄清，再确认，再执行。

这类设计不是为了阻止 Agent 主动解决问题，而是避免出现一种更隐蔽的越权：Agent 正确理解了“用户想要什么”，却擅自决定了“可以用什么方式得到它”。

操作记录应该完整，但不必全部堆在前端

Agent 需要高度可追溯，但“可追溯”不等于把所有内部步骤都实时展示给用户。

系统内部应该保留完整操作记录，包括做了什么、什么时候执行、调用了哪些工具、哪一步失败、哪些操作可以撤销。这些信息对故障排查、责任判断和用户申诉都很重要。

但正常情况下，前端只需要展示和当前决策有关的信息。例如：

已整理 23 个文件，可撤销。

如果任务失败、出现异常，或者用户主动展开详情，再提供更完整的执行记录。

这样可以把“系统透明度”和“界面简洁度”分开处理。用户不需要实时阅读 Agent 的每一步推理，但产品必须保证关键行为能够被追溯。

长期记忆和行动权限也应该分开

Agent 越来越像长期助手以后，个性化会依赖更多历史上下文。求职场景里，记住用户的工作经历、项目背景和职业目标，可以明显减少重复说明，也能让后续简历修改、岗位判断和面试准备更连贯。

但“系统知道什么”和“系统能拿这些信息做什么”仍然需要分开。

例如，Agent 可以记住用户的职业目标，并据此筛选职位；但这不意味着它应该未经确认自动替用户投递。同样，读取邮箱可以帮助理解上下文，但不代表可以自由发送或删除邮件。

长期记忆解决的是“理解用户”，执行权限解决的是“允许做什么”。如果两者混在一起，个性化越强，潜在风险反而越大。

Agent 需要一个独立的控制中心

当 Agent 只是偶尔调用一个工具时，权限可以藏在单次对话里；但当它开始连接邮箱、日历、文件、自动化任务和其他服务以后，仅靠聊天窗口很难让用户理解当前到底授权了什么。

因此，一个成熟的 Agent 产品应该提供独立的控制中心，至少能查看：

• 已连接的应用和当前权限；
• 自动化规则；
• 最近执行记录；
• 高风险操作历史；
• 可撤销操作；
• 长期记忆；
• 资源或 token 消耗。

这个页面不应该要求用户每天管理，而更像云服务控制台：平时可以忽略，需要检查、修改权限或处理异常时能够找到完整信息。

其中资源消耗也值得单独展示。Agent 可能在后台连续搜索、读取文件、调用模型和执行工具，用户对一次任务实际消耗了多少资源并不天然有感知。如果这些消耗最终影响额度或费用，透明的成本反馈会成为重要的产品能力。

Agent 的信任不需要建立在“永远不犯错”上

模型准确率当然重要，但 Agent 产品不可能等到模型接近零错误以后才开始使用。

更现实的产品目标，是把错误限制在用户可以接受的范围内。

如果 Agent 把一个文件移动错了位置，但用户可以一键恢复，这个错误的成本很低；如果它误转了一笔钱，哪怕模型总体准确率很高，这一次错误也可能不可接受。

所以 Agent 的信任机制更接近：

错误可以发生，但后果必须可控。

这也是为什么可撤销、权限透明、长期稳定和用户对关键操作的控制权，会比单纯展示一个模型准确率更重要。

结论：设计的不是“最大自动化”，而是“安全的自主程度”

Agent 产品最终需要解决的，不是如何让系统尽量少问用户，而是如何在不同风险等级下给它不同程度的自主权。

可以把这套机制概括成三层：

低风险、可恢复、主要影响用户自己的操作，可以直接执行，保留记录和 Undo。

高风险、不可逆、涉及付款或影响第三方的操作，执行前必须明确确认。

高风险且用户意图模糊的操作，先澄清，再确认，再执行。

这样设计的好处是，低风险任务仍然能体现 Agent 的效率，而真正可能产生现实后果的动作仍然由用户掌握最后决定权。

好的 Agent 不是替用户做得越多越好，而是在低风险任务上足够主动，在真正会产生后果的地方知道什么时候应该把控制权交还给用户。