多模态 Agent 一接浏览器截图就开始看错状态：从 Visual Grounding 到 DOM Cross-Check 的工程实战
很多团队给浏览器 Agent 接上截图后，第一反应都是“终于能像人一样看页面了”。⚠️ 但真实线上事故里，误点、漏点和点到禁用按钮的根因，往往不是模型看不见，而是它把某一帧截图误当成了完整状态。
更麻烦的是，截图天然缺少交互语义。🧠 骨架屏和真实表格在视觉上可能只差几条灰线，弹层遮住提交按钮时截图也未必明显；如果 Agent 只按图片描述做动作，就会把“像可点”误判成“现在可提交”。
[外链图片转存中…(img-pu1sgikc-1778033762815)]
纯截图驱动为什么特别容易把页面状态看错
浏览器页面的很多关键状态，本来就不是为截图而设计的。🔍 按钮是否被disabled、表单是否仍在提交、列表是否还在虚拟滚动、遮罩是否吞掉点击，真正可靠的信号都藏在 DOM 属性、样式层级和事件状态里，而不是像素本身。
另一个高频误区，是把截图时刻和动作时刻当成同一件事。📌 页面一旦发生重排、懒加载或局部刷新，视觉模型看到的是上一帧，执行器点到的却是下一帧节点；当系统没有 freshness 校验时，Agent 给出的坐标越果断，误操作反而越稳定。
| 方案 | 任务成功率 | 误点率 | 平均重试次数 |
|---|---|---|---|
| 纯截图决策 | 71% | 18% | 1.9 |
| 截图 + DOM 可点击校验 | 84% | 7% | 1.2 |
| 截图 + DOM 校验 + 动作确认 | 89% | 3% | 1.1 |
一组回放把问题暴露得很直接
这次回放选了380个后台任务页面，覆盖筛选、分页、弹窗提交和文件上传四类操作。🧪 基线方案只给模型看截图并返回目标坐标；第二组在点击前补一次 DOM 可见性与禁用态校验；第三组再增加 action confirmation，要求模型给出目标语义，执行器据此反查节点后再提交点击。📊 结果很直接：第二组已经显著压住误点，第三组才真正把“看到了”和“点对了”收成闭环。
defchoose_click_target(vision_box,dom_nodes):candidates=[nodefornodeindom_nodesifnode.visibleandnotnode.disabledandnode.pointer_events!="none"]anchor=nearest_semantic_match(vision_box.label,candidates)ifnotanchor:returnNoneifanchor.updated_at<now_ms()-800:returnNonereturn{"selector":anchor.selector,"text":anchor.text}这段逻辑的重点，不是让 DOM 推翻视觉，而是让视觉先给语义候选，再由 DOM 验证它此刻是否还能执行。✅ 只要目标文本、可见性、禁用态和刷新时间任一不成立，动作就不应该直接落地。
[外链图片转存中…(img-k1EkzY1m-1778033762819)]
真正要绑定的是页面状态，而不是单张截图
笔者认为，多模态 Agent 在浏览器里最该补的一层，不是更大的视觉模型，而是状态绑定协议。🛠️ 视觉负责回答“像什么”，DOM 负责回答“现在能不能做”，执行器再负责确认“这次点击会不会产生副作用”；三层缺一层，系统都会退化成脆弱的坐标点击器。
更稳的工程做法，是把 DOM Cross-Check 做成动作前的默认门槛。📎 对提交、删除、发布、上传这类高副作用操作，至少校验节点文本、可见性、禁用态、遮挡关系和更新时间；如果截图语义与 DOM 不一致，就先重采样页面，而不是硬点一次赌结果。
[外链图片转存中…(img-l1zZm7zv-1778033762820)]
未来3 - 6个月，多模态 Agent 在浏览器场景里会越来越像“视觉观察 + 结构化验证”的混合系统。🚨 谁先把 screenshot freshness、DOM authority 和 destructive action guard 接到同一条执行链上，谁就更容易把误操作率压下去；反过来，只堆视觉能力而不做 Cross-Check，线上稳定性迟早会被页面细节反噬。⭐ 你们现在的浏览器 Agent，是在看页面，还是只是在看上一帧截图？