很多团队把浏览器 Agent 接到商品流或监控列表后，第一批线上事故并不是“不会滚动”，而是它滚得很勤，却依旧漏内容。⚠️ 页面每次只暴露一个视口，模型若把“当前看到的列表”直接当成“完整世界”，结果就会一边下滚一边丢证据。
人类刷列表时，会顺手记住“上次看到哪一条”和哪些卡片只是骨架屏。🧠 Agent 若只依赖当下 DOM 快照，就容易重复读旧卡片、跳过新卡片。🔍
为什么无限滚动页会让抓取结果越滚越乱
第一层根因，是视口驱动观察天然不完整。📌 很多执行器默认“当前 DOM 即当前列表”，但无限滚动页只会懒加载局部节点；上方节点被回收、下方节点尚未挂载时，模型看到的只是被截断的时间片。
第二层根因，是列表项缺少稳定身份。🧩 当 Agent 只按第n行或屏幕位置记忆项目，页面一插入推荐卡或置顶项，后续索引就会错位。
一组回放实验说明问题不在模型，而在状态契约
这次回放了58条真实任务，覆盖商品列表遍历和异常告警确认。🧪 基线方案只在每次滚动后读取当前可见卡片文本；改进方案在每轮扫描后记录viewport checkpoint，并用业务主键或链接生成stable item key。📊
| 方案 | 任务完成率 | 漏抓率 | 重复抓取率 | 人工接管率 |
|---|---|---|---|---|
| 仅依赖可见视口 | 61% | 19% | 14% | 18% |
| Checkpoint + Stable Key | 89% | 4% | 3% | 6% |
真正拉开差距的，不是让模型多描述几遍页面，而是让系统能回答两个问题：上一轮扫描停在什么位置，当前卡片是不是新对象。✅ 只要这两个问题答不清，流程就不该继续滚动。
defsnapshot_item(node):return{"stable_key":node.get("data-id")ornode.get("href"),"title":node.get("title"),}defshould_collect(item,seen_keys):key=item["stable_key"]returnbool(key)andkeynotinseen_keys这段契约并不复杂，却能把“看到一次就算处理过”和“真正确认唯一对象”分开。🛠️ 一旦stable_key缺失，系统宁可回退补充观察，也不要继续把屏幕坐标当主键。
工程上真正该补的是 Viewport Checkpoint
stable item key解决对象归属，viewport checkpoint解决进度归属。🚨 更稳的做法，是在每一轮滚动后记录最后一个已确认项目的主键、顶部锚点文本和页面是否仍在加载。这样即使下一轮 DOM 被回收，也能知道该从哪里续扫。
笔者认为，无限滚动页最常见的误区，是把滚动当成视觉动作，而不是状态迁移。📍 只要系统没有显式记录检查点、加载完成信号和去重集合，再强的模型也只能在半屏信息里猜测。把滚动升级成“提交一次可恢复检查点”，可靠性才会真正上来。📈
未来 3 到 6 个月 长列表 Agent 会越来越依赖列表级证据链
接下来更值得投入的方向，不是继续堆更长上下文去“看全列表”，而是把检查点、稳定主键和加载完成信号做成统一状态层。📦 当系统能证明“这条数据已处理过、这段列表已扫完、这次滚动还没稳定”，无限滚动页才会从随机试错变成可审计流程。
一句话总结：无限滚动真正危险的不是页面长，而是列表对象和扫描进度都没有稳定身份。⭐ 把Viewport Checkpoint和Stable Item Key补上后，Agent 才不会一边滚动一边漏结果。🤖 你们现在的长列表自动化，记录的是屏幕位置，还是业务主键？
