Agent 一接骨架屏页面就开始误判完成态：从 Readiness Signal 到 DOM Stabilization 的工程实战

浏览器 Agent 一进企业后台最容易踩的坑往往不是页面太慢而是页面看起来已经“加载好了”实际仍停留在骨架屏、占位卡片和半成品 DOM。⚠️ 人类会等列表真实出现再点Agent 如果只看到按钮可见、节点已挂载就可能提前触发搜索、提交或翻页直接把抖动放大成流程事故。骨架屏最危险的地方在于它提供了和真实页面极其相似的视觉信号。 对执行器来说标题、按钮和容器都已经存在可真正决定动作是否安全的数据和事件绑定往往还没落稳。观察与动作就在这里脱节。[外链图片转存中…(img-SLJ051ra-1777778322218)]图 1骨架屏最容易制造“已经可操作”的假象骨架屏为什么会把完成态判断带偏很多自动化框架默认把element visible、DOMContentLoaded或network idle当成可执行信号。 这在静态页里够用但现代后台依赖异步数据和 hydration。列表骨架还没替换成真实行按钮虽然能点回调却还没注册完成于是 Agent 会在“结构已到位、语义未就绪”的窗口里误出手。更棘手的是这类问题常常难以复盘。 回放截图里页面最后看起来完全正常日志里也能看到目标元素确实存在。真正缺失的是进入稳定态前的那几百毫秒DOM、数据和可交互状态并不同步。没有显式的 readiness contract模型就会反复把占位内容当成真实世界。图 2结构出现得早不代表页面已经进入安全操作区间一组 Readiness Signal 对比实验把问题看清这次回放了58条真实后台任务覆盖搜索、审批、工单跳转和报表筛选。 基线方案只检查目标节点可见方案二加入network idle方案三再补上骨架消失、关键数据行数达标和短暂 DOM 稳定窗口。提前点击的核心问题不是模型不会找按钮而是执行器没有区分“页面可见”和“页面可用”。✅方案任务成功率提前点击率平均重试次数误提交率仅检查元素可见61%19%3.611%元素可见 network idle73%10%2.47%多信号就绪判定91%2%1.21%真正有效的不是等更久而是等对信号。️ 一旦把骨架节点、关键字段回填和 DOM 短稳窗口纳入门槛许多“偶发”误操作就会立刻收敛说明问题根本不在推理而在执行前缺少页面语义校验。defis_page_ready(snapshot):return(notsnapshot.has_skeletonandsnapshot.data_row_countsnapshot.min_rowsandsnapshot.bound_actions_readyandsnapshot.dom_stable_ms300)defshould_execute(action,snapshot):returnis_page_ready(snapshot)andaction.targetinsnapshot.enabled_targets图 3真正要看的不是元素出现而是语义信号是否闭合工程上真正该补的是 DOM Stabilization 契约更稳的做法是把“可以动作”定义成系统契约而不是浏览器默认状态。️ 每次观察后执行器都要同时记录页面是否仍有骨架、关键数据是否回填、目标控件是否可交互以及最近一段时间 DOM 是否持续抖动。只有这些条件同时满足点击、输入和提交才允许放行。这样做的价值是把等待变成可审计的工程规则。另一层常被忽略的是回压与取消。⏱️ 页面长期停在骨架态时系统不能无上限重试“再看一眼”而要及时触发重载、降级路径或人工接管。笔者认为未来真正稳定的浏览器 Agent 都会把 readiness、重试预算和失败回退收敛成同一条状态机否则骨架屏会持续制造“元素在、结果错”的事故。⭐图 4页面稳定窗口、数据回填和动作放行必须一起判断未来 3 到 6 个月 页面自动化会更依赖语义就绪信号一句话总结骨架屏不会直接让 Agent 失明它破坏的是完成态判断。 把Readiness Signal和DOM Stabilization做成显式契约后系统才能分清“页面已出现”和“页面已可执行”这两个阶段。浏览器 Agent会在点击前确认骨架是否消失、数据是否回填、DOM 是否稳定吗