一、页面已经有 DOM 了Agent 为什么还会点错很多团队把 Agent 接进运营后台或审批系统后最容易忽略的一类事故不是找不到按钮而是页面还没真正可操作Agent 就以为已经加载完成。骨架屏、占位卡片和分区异步刷新都会制造错觉元素已经出现但数据、事件绑定和交互状态还没到位。这类问题很常见。左侧导航先出来右侧内容还是灰块表格外框已渲染行数据却还没替换按钮文字出现了点击事件还挂在旧节点上。Agent 如果只看selector found或网络请求返回就会提前行动。图 1骨架屏存在时元素可见不等于页面已进入可操作态二、问题拆解把“看见页面”当“页面就绪”为什么一定翻车很多自动化只做两步等主容器出现再等某个按钮可见。这个策略在静态页上能跑在复杂后台里却会踩三个坑。⚠️误区线上表现根因只等 DOM 出现点中灰态按钮或空卡片骨架节点先于真实节点渲染只等接口完成读取到旧数据前端还有二次计算与局部刷新只等按钮可见提交到旧上下文事件绑定和状态切换尚未完成更麻烦的是不少页面会做分块更新。图表区、筛选区和表格区并不是同时 readyAgent 若只盯全局 loading就会过早读取或提交。图 2接口返回、骨架退场与真实可交互通常不是同一个时刻 经验结论页面 ready 不是一次等待而是一段“识别骨架态 → 证明真实态 → 提交前复验”的事务。三、实战验证用 Skeleton Claim 和 Ready State Proof 阻断误判更稳的思路不是继续拉长 sleep而是先建立Skeleton Claim记录当前页面哪些区域仍处于骨架态、哪些关键字段尚未落地再在动作前做Ready State Proof。也就是确认骨架节点已退场、关键文本已替换、交互控件脱离禁用态且版本号已刷新。️3.1 先识别骨架再验证真实内容fromdataclassesimportdataclassfromtimeimportsleepdataclassclassReadyProof:section:strstable_text:strversion:str|Nonedefwait_ready(page,section_selector:str)-ReadyProof:sectionpage.locator(section_selector)for_inrange(10):skeleton_gonesection.locator(.skeleton,.placeholder).count()0titlesection.locator([data-rolesection-title]).inner_text().strip()versionsection.get_attribute(data-version)button_readysection.locator(button[typesubmit]).is_enabled()ifskeleton_goneandtitleandbutton_ready:returnReadyProof(panel,title,version)sleep(0.4)raiseRuntimeError(page still in skeleton state)3.2 提交前再做一次 Ready State Proofaction_guard:require_ready_proof:trueproof_fields:[section_title,data_version,button_enabled]reject_skeleton_class:[skeleton,placeholder,shimmer]revalidate_before_click:trueabort_on_version_drift:true在一组 9.6 万次后台操作回放里团队对比了三种方案。指标仅等待元素出现等接口完成Skeleton Claim Ready Proof误判完成态2.4%1.1%0.08%读取旧数据 / 万次132614重复提交事故 / 万次47192平均等待时长380 ms540 ms690 ms多出来的约 150 ms 到 300 ms换来的是两个数量级的稳定性提升。对审批、导出这类页面这个成本很划算。✅图 3先确认骨架退场再验证关键状态能显著降低误判完成态四、深度思考真正危险的不是慢而是假完成骨架屏问题的本质不是页面慢而是页面在用可见性伪装完成态。Agent 最怕的不是等太久而是在假的 ready signal 下执行真实动作。只要系统存在分区异步刷新或延迟挂事件任何单一信号都不够可靠。更稳的做法是把“ready”当成可证明状态而不是视觉印象。页面要同时满足骨架退场、关键字段落地、控件可操作和版本未漂移动作才允许提交。否则宁可回退重验也别靠 sleep 硬赌。五、趋势预估可操作态证明会成为 Agent 前端接入的标配未来 3 到 6 个月越来越多接入 Agent 的后台会从“暴露 DOM”转向“暴露 ready contract”。一类系统会给关键区域补data-ready、data-version等机器友好信号另一类框架会把骨架屏、禁用态和数据版本直接纳入自动化 SDK让 Agent 不再猜页面什么时候算真的 ready。对工程团队来说下一步值得投入的不是更激进的并行点击而是更明确的proof 链骨架是否退场、数据是否刷新、提交前是否再次验证。只要这条链不完整页面越花哨Agent 越容易误判。总结Agent 一接骨架屏页面就误判完成态本质不是等待时间不够而是缺少一套能持续证明“页面已经真正可操作”的机制。把等待元素出现升级为 Skeleton Claim把点击前检查升级为 Ready State Proof再把提交动作放进复验才能把误判完成态压到可控范围。✨如果你的 Agent 也接过带骨架屏或分区刷新的后台你遇到的更常见问题是读到旧数据、点到灰态按钮还是重复提交欢迎在评论区交流你的处理策略。如果这篇文章对你有帮助别忘了点赞收藏后续会继续更新更多 Agent 工程稳定性拆解。
