浏览器 Agent 正在重写 UI 的“提交”逻辑

传统网页中，点击是人与界面之间最普通的交互。用户点击按钮，系统执行对应动作。设计师当然会区分普通操作和危险操作，但无论删除、发送、打开菜单还是选择一个选项，动作的发起者始终是用户本人。人在点击之前，通常已经知道自己准备做什么。

浏览器 Agent 打破了这个关系。

当 AI 获得 Computer Use 能力之后，它可以替用户打开网站、填写表单、选择选项、发送邮件甚至完成购买。用户给出的可能只是一句任务目标，几十次具体点击则由 Agent 自行规划和执行。

从鼠标行为看，它们都是点击；从用户承担的结果看，它们完全不是同一种事情。

10 月 2 日，Make Your Agent 发布的一篇 Computer Use 安全实践文章提出了一种很有启发性的划分方式：不要再把浏览器操作笼统地看成 click，而是按照产生的后果分成 observe、stage 和 commit 三类。

Observe 只读取状态，例如打开页面、查看订单；Stage 会改变当前界面，却尚未真正产生外部结果，例如填写表单、准备草稿、选择付款方式；Commit 才是最终改变真实世界状态的动作，例如发送、购买、删除、发布、转账或者接受协议。

这三者之间最大的差异，不在视觉表现，而在后果是否已经成立。一个 Agent 可以替用户填写完整封邮件，在点击“发送”之前，它仍然只是一个可以修改的草稿；可以把商品、地址和支付方式全部准备好，在最后一步之前也没有真正产生交易。

这样的划分给 UI 设计留下了一个非常清晰的边界：Agent 可以自主准备，但真正改变外部状态之前，界面需要让用户重新获得判断权。这里的“确认”也不能继续沿用一句简单的“是否继续”。

文章提出，在 Commit 发生之前，系统应该把 Agent 当前准备执行的动作重新整理成一个明确的 proposal：它准备对谁做什么，关键参数是什么，可能产生什么结果，这个结果能否撤销，以及这份授权在什么时候失效。系统还需要重新检查用户当前的权限，以及目标状态是否已经发生变化。

这和传统确认框存在一个本质区别。传统确认框往往只是重复用户刚刚完成的动作：“确定删除吗？”因为删除本来就是用户亲自发起的。

Agent 场景中，用户可能已经几分钟没有直接操作界面。他只知道自己交给系统一个目标，却未必知道 Agent 此刻为什么走到了这一步。所以确认界面的任务不只是阻止误触，还必须重新建立意图、动作与后果之间的关系。

例如，与其显示“是否允许继续”，界面更需要告诉用户，Agent 准备向哪个公司账户支付多少钱，依据的是哪张订单，这笔付款能否撤销。

此时设计需要区分的，不再是“主按钮和危险按钮应该用什么颜色”，而是整个任务过程中，哪些状态属于准备，哪一个节点开始产生真实后果。

这种思想甚至会影响 Agent 的进度设计。

今天很多 Agent 界面把任务显示成一串连续步骤，好像完成第 6 步和完成第 7 步只是进度上的差异。但如果第 6 步只是填写转账信息，第 7 步会真正转出资金，这两个节点显然不应该拥有相同的视觉权重和交互逻辑。

动作之后还有另一个容易被忽略的问题：Agent 未必总能确认操作究竟有没有成功。

文章因此提出了 verified、failed 和 unknown 三种结果状态。浏览器在提交订单后突然超时，并不能立即被标记成“失败”，因为订单可能已经提交，只是 Agent 没能看到成功页面。此时如果自动重试，反而可能造成重复付款。系统需要先重新读取目标状态，再决定接下来如何恢复。

对于 UI 设计师，这一点可能比 observe、stage、commit 本身更重要。

传统软件习惯把任务状态设计成成功与失败；Agent 开始代表用户跨系统执行真实操作之后，“不知道是否成功”会成为一种必须被认真设计的产品状态。

当然，observe、stage、commit 目前只是这篇实践文章提出的一套工程与产品框架，并不是经过大规模用户实验验证的通用标准。不同产品也未必需要直接采用这三个名称。它只是为我们提供了一种更适合 Agent 的设计视角。

过去我们按照控件和操作设计界面：这是点击，这是输入，这是提交。

当操作开始由 AI 完成之后，设计师需要向前再走一步，按照后果重新组织这些动作：哪些只是观察，哪些仍处于准备状态，哪一步真正改变了外部世界，以及改变之后我们是否能够确认它已经发生。

浏览器 Agent 让“点击”第一次变成了一个过于粗糙的交互单位。未来 Agent UI 需要让用户看见的，可能不是它刚刚点了哪里，还有现实世界究竟有没有因为这次点击发生变化。