很多团队把浏览器 Agent 接到富前端后台后最难排查的并不是元素定位而是页面明明已经刷新Agent 却还在读旧数据。⚠️ 面板里看到的列表、筛选结果甚至审批状态都可能来自 Service Worker 的旧缓存而不是刚刚返回的接口结果。问题一旦落在自动化链路里后果往往不是“显示有点旧”而是误点、误审和错误提交整批扩散。人类在页面出现异常时通常会本能地刷新、切账号、看时间戳。 Agent 如果只把 DOM 当真相就会把缓存命中后的旧内容继续写入后续动作直到外部世界和内部观察彻底脱节。真正需要治理的不是“缓存要不要开”而是缓存版本、页面世界版本和后台同步任务有没有被隔离。图 1页面能打开不代表 Agent 看到的是最新世界状态Service Worker 为什么会把 Agent 带进旧世界Service Worker 最大的价值是把网络波动、静态资源和部分接口结果挡在页面外层。 对真人用户来说这通常意味着更快的首屏和更强的离线能力对 Agent 来说却多了一层看不见的状态转译。只要缓存键没有显式带版本或stale-while-revalidate被滥用页面上“刚刷新过”的内容仍然可能来自旧响应。更麻烦的是 Background Sync。 某些系统会先把写操作放进本地队列再由 Service Worker 异步回放到服务端。Agent 在点击完成后看到的成功提示未必代表服务端已经接单而同步任务一旦和读缓存共用命名空间就会让“本地已成功”和“远端未落地”同时存在。结果就是观察层读到旧值动作层却以为写入已经完成。⏱️图 2真正的难点不在刷新动作而在缓存、网络和同步队列不是同一个时钟一组回放数据把“页面刷新成功”和“数据已更新”分开看这次回放了36条后台任务覆盖列表审批、工单处理和批量导出三类场景。 基线方案只看 DOM 是否变化方案二增加接口完成等待方案三再补上cache version、world version校验和 Background Sync 隔离。结果很直接只盯页面刷新远远不够。✅方案任务正确率旧数据误读率平均等待耗时仅 DOM 观察63%19.4%3.1 sDOM 网络空闲78%10.2%4.6 sCache Version Sync Isolation93%1.8%5.2 s真正有效的改动是让 Agent 能证明自己看到的是“当前世界版本”。️ 每次关键读操作前系统都校验接口etag、业务版本号或最近更新时间每次关键写操作后再确认 Background Sync 队列是否清空避免把尚未落远端的本地成功态当成事实。这样哪怕 Service Worker 仍在工作旧缓存也不会再直接驱动高风险动作。asyncfunctionreadFreshState(page,expectedVersion){constworldVersionawaitpage.evaluate(()window.__DATA_VERSION__)constsyncPendingawaitpage.evaluate(async(){constregsawaitnavigator.serviceWorker.readyreturnregs.active?window.__SYNC_PENDING__true:false})if(syncPending)returnwait_syncif(worldVersion!expectedVersion)returnrevalidatereturncontinue}图 3给缓存和同步链路加版本边界后任务正确率明显提升工程上真正该补的是缓存版本和同步隔离契约更稳的做法是把 Service Worker 页面当成“存在第二观察层”的系统来设计。️ 第一层补cache version让静态资源、接口结果和业务数据都有显式版本键第二层补world version校验确保 Agent 在点击前知道自己看到的是哪一版事实第三层把 Background Sync 队列从读缓存命名空间里拆开写入未落地时禁止继续做依赖最新状态的动作。笔者认为未来 3 到 6 个月浏览器 Agent 的稳定性竞争不会只看模型会不会点页面而会看它能不能证明“看到的是新世界而不是缓存出来的旧世界”。⭐ 谁先把 Cache Version、同步隔离和结果再验证做成标准件谁的自动化链路就更接近生产级。你们现在的 Agent在 Service Worker 页面上能分清自己看到的是最新结果还是离线缓存吗