浏览器 Agent 的很多失败不是幻觉，而是复用了过期页面状态

浏览器自动化里很多看起来像“模型胡来”的失败，其实是工程层面的 stale state：页面导航了，DOM 重渲染了，旧 handle 失效了，但系统还在用上一轮观察到的世界继续行动。

浏览器 agent 和纯文本 agent 最大的差异是，它面对的是一个持续变化的外部界面。页面会跳转，组件会异步加载，按钮会因权限或状态改变而消失，同一个选择器也可能在重渲染后指向不同语义。如果 agent 把一次观察当成长期有效事实，动作阶段就会出现错点、漏点、点不到、点错对象等问题。

这类问题经常被误归因为模型能力不足。模型确实可能判断错，但如果执行层没有重新确认 DOM、页面版本和目标可达性，再聪明的模型也会被过期上下文拖下水。

DOM handle 不是长期凭证。页面导航、frame 切换、组件重渲染、列表刷新，都可能让旧引用失效。更隐蔽的是，引用未必直接报错，它可能仍然指向一个可点击对象，却已经不是 agent 以为的那个语义目标。

因此，动作前必须重新绑定目标。不要只沿用上一步保存的元素引用，而要基于当前页面重新定位，并校验可见文本、角色、位置、状态和上下文是否仍然匹配计划。

浏览器 agent 的可靠性不只取决于模型会不会理解页面，还取决于执行环是否承认页面上下文会漂移。点击、输入、提交这类副作用动作，尤其需要先确认目标仍可达，而不是失败后再解释“页面可能变了”。

页面版本意识很重要。URL、标题、关键 DOM 标记、可见文本、frame 上下文和登录态，都可以作为轻量版本信号。它们不需要把浏览器变成复杂数据库，却能帮助系统判断：当前页面是否还是刚才观察到的页面，是否需要重新观察，是否应该重建上下文。

更进一步，stale state 应该成为一等故障类型。系统要能区分“模型计划错了”“元素不可达”“页面状态已变”“权限或登录态失效”。如果所有失败都被塞进“模型没点对”，后续优化就会走偏。

对 OpenClaw 这类需要使用真实浏览器登录态和真实发布页面的系统来说，这一点尤其关键。发布链路里的按钮、编辑器、弹窗、草稿状态和登录状态，都可能在几秒内变化。把旧页面状态当成事实，不只是降低成功率，还可能造成错误发布、重复提交或无法解释的中断。

最实用的改进，不是让模型多解释几句，而是在每次关键动作前重新观察、重新定位、重新校验。提交、删除、覆盖、发布这类高风险副作用动作，还应该要求二次确认当前目标。

浏览器 agent 要先承认页面状态会漂移，再谈模型是否聪明。很多失败不是幻觉，而是系统复用了过期页面状态。

龙虾升职记