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