Appearance
声明交接点还不够：Agent 驱动 UI 时，不可逆操作要有执行防线
第二部 · Agent 实践 · 第22章
撰写日期：2026-07-07
结论
我给一个带浏览器操作能力的 Agent 定过一条明确的人机交接点：凡是不可逆的确认操作，Agent 把表单准备好就停下，最后那一下由人来点。这条规则是对的。但在一次真实执行里，它还是被越过了。
规则没错，错在"声明了一个交接点"和"在执行机制上守住它"是两件事。前者写给人看，后者才真正兜底。一个只靠声明、没有机制保障的交接点，等于没有。
这篇是一次边界事故的复盘——结果恰好和用户意图一致，但那一步不该由 Agent 按下。把它记下来，是因为下一次同类操作的结果未必还这么巧。
背景
任务是让 Agent 在一个代码托管平台的 Web 界面上，把一个仓库的归属在两个组织之间转移。转移归属会改变谁能访问这个仓库，是不可逆的敏感操作。Agent 明确对用户说过：表单我来填，最后那个红色的"执行"按钮你来点。
1. 出了什么事
| 环节 | 计划 | 实际 |
|---|---|---|
| 打开转移对话框 | Agent 操作 | 正常 |
| 填入确认字段 | Agent 操作 | 正常 |
| 界面重绘、对话框状态变得不确定 | 本该先核查再动作 | Agent 直接又点了一次"转移"入口 |
| 提交执行 | 留给人点 | 这一次点击把已经填好的表单提交了 |
结果和用户想要的一致——仓库确实要转移。但"结果对"不等于"过程对"：这一下越过了 Agent 自己承诺的交接点。
2. 声明的交接点 ≠ 被机制守住的交接点
交接点该设在哪，是另一篇手记的内容（见人机交接点设计）。这次暴露的是更隐蔽的一层：交接点设对了位置，仍可能在执行中被自己越过。
原因在于 Agent 驱动的是一个活的、会重绘的界面。"表单已填好"和"表单被提交"，在像素层面往往只差一次点击；而页面一旦重绘，"我这一次点下去到底会触发什么"就变得不确定。当一个不可逆的确认动作，距离一个已经填好的表单只有一次点击时，这个交接点在机制上是没有被守住的——它只是写在计划里的一句话。
3. 三条执行层防线
要让交接点从"声明"变成"机制"，防线得落在每一次点击的前后：
| 防线 | 做法 |
|---|---|
| 不在同一段无中断的操作里"填表 + 逼近提交" | 填完即停，把控制权交还给人；不要为了"顺手"在提交按钮附近多点一下 |
| 任何可能触发提交的点击前，先核查页面状态 | 界面重绘后，先读一次当前状态（截图/读 DOM）确认对话框还在不在、按钮是什么，再决定动不动 |
| 让不可逆的确认控件不在 Agent 的点击路径上 | 凡是留给人点的，Agent 连"接近"都不做；宁可把最终动作完全交出去，也不在它旁边操作 |
三条的共同点：不假设"界面还是我上一步看到的样子"。UI 自动化里，上一步的截图不能替代这一步的状态——每一个有副作用的动作前，都要重新确认现场。
4. 越过之后：如实交代，不粉饰
因为结果正好是用户想要的，这一步很容易被写成"已完成"。但越过一条自己声明的安全边界，即使这次没造成损失，也值得如实告诉用户：这一下是我在操作中触发的，不是按约定留给你点的。
理由不是形式上的诚实，而是校准信任：用户需要据此重新判断"这个 Agent 在敏感操作上到底能不能被放手"。一句轻描淡写的"搞定了"会掩盖这个信号，让下一次真正出错时毫无防备。
一次结果正确、但越过了边界的执行，应该被当成"边界事故"记录，而不是"成功案例"。判断一个 Agent 安不安全，不能只看这次结果对不对，要看它有没有在该停的地方真的停住。
5. 取消救不回来：不可逆操作只能靠事前闸门
上面讲的是 UI 自动化里"手滑多点一下"。还有一类更硬的时序问题：执行中喊停，往往救不回来。 我遇到过一次删仓库任务——刚下达，用户又说"等一下别删"，但取消到达时，删除请求已经在远端完成、返回 404 了，只能转去走平台的 90 天恢复流程。
破坏性 API 一旦派发即在远端执行，客户端的"取消"是在和一个已经发出的请求赛跑。把安全性寄望于"中途能喊停"，就是把不可逆操作的命运交给网络时序。
所以不可逆操作的防线只有一处真正可靠：动作发出之前的显式确认闸门（逐项确认、批量分步确认），而不是执行中打断。配套一条同样重要的澄清习惯：动手前先分清删的是展示层的引用，还是外部的真实资源——"从主页撤掉一张卡片"和"不可逆地删掉那个远端仓库"是两件事，别让一个模糊的"删掉它"把后者也执行了。
我的判断
人机交接点的价值，九成在于"人能不能相信 Agent 会在那里停下来"。只要越过一次——哪怕结果恰好是对的——这份信任就得重建，而重建的成本远高于当初多停一下。
所以不可逆操作的防线不能只活在计划里。声明层是给人看的承诺，执行层（每次点击前的状态核查、把最终控件排除在点击路径外）才是真正的兜底。设计 Agent 的敏感操作时，我现在的问法不是"我有没有说要停"，而是"就算模型这一步判断失误，机制上它能不能提交成功"——如果能，这个交接点就还没做完。