一、页面已经有 DOM 了，Agent 为什么还会点错

很多团队把 Agent 接进运营后台或审批系统后，最容易忽略的一类事故，不是找不到按钮，而是页面还没真正可操作，Agent 就以为已经加载完成。骨架屏、占位卡片和分区异步刷新都会制造错觉：元素已经出现，但数据、事件绑定和交互状态还没到位。😵

这类问题很常见。左侧导航先出来，右侧内容还是灰块；表格外框已渲染，行数据却还没替换；按钮文字出现了，点击事件还挂在旧节点上。Agent 如果只看 selector found 或网络请求返回，就会提前行动。🔍

二、问题拆解：把“看见页面”当“页面就绪”为什么一定翻车

很多自动化只做两步：等主容器出现，再等某个按钮可见。这个策略在静态页上能跑，在复杂后台里却会踩三个坑。⚠️

更麻烦的是，不少页面会做分块更新。图表区、筛选区和表格区并不是同时 ready；Agent 若只盯全局 loading，就会过早读取或提交。🧭

💡 经验结论：页面 ready 不是一次等待，而是一段“识别骨架态 → 证明真实态 → 提交前复验”的事务。

三、实战验证：用 Skeleton Claim 和 Ready State Proof 阻断误判

更稳的思路不是继续拉长 sleep，而是先建立 Skeleton Claim：记录当前页面哪些区域仍处于骨架态、哪些关键字段尚未落地，再在动作前做 Ready State Proof。也就是确认骨架节点已退场、关键文本已替换、交互控件脱离禁用态，且版本号已刷新。🛠️

3.1 先识别骨架，再验证真实内容

from dataclasses import dataclass
from time import sleep

@dataclass
class ReadyProof:
    section: str
    stable_text: str
    version: str | None


def wait_ready(page, section_selector: str) -> ReadyProof:
    section = page.locator(section_selector)
    for _ in range(10):
        skeleton_gone = section.locator(".skeleton,.placeholder").count() == 0
        title = section.locator("[data-role='section-title']").inner_text().strip()
        version = section.get_attribute("data-version")
        button_ready = section.locator("button[type='submit']").is_enabled()
        if skeleton_gone and title and button_ready:
            return ReadyProof("panel", title, version)
        sleep(0.4)
    raise RuntimeError("page still in skeleton state")

3.2 提交前再做一次 Ready State Proof

action_guard:
  require_ready_proof: true
  proof_fields: [section_title, data_version, button_enabled]
  reject_skeleton_class: [skeleton, placeholder, shimmer]
  revalidate_before_click: true
  abort_on_version_drift: true

在一组 9.6 万次后台操作回放里，团队对比了三种方案。📊

多出来的约 150 ms 到 300 ms，换来的是两个数量级的稳定性提升。对审批、导出这类页面，这个成本很划算。✅

四、深度思考：真正危险的不是慢，而是假完成

骨架屏问题的本质，不是页面慢，而是页面在用可见性伪装完成态。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 工程稳定性拆解。🤝