PageGuide：将大模型答案锚定到网页 DOM 的浏览器辅助扩展 PageGuide: Browser extension to assist users in navigating a webpage and locating information

完整流程可以拆为五个具体步骤。第一步，DOM 序列化：扩展 content script 遍历当前文档，把每个 visible、text-bearing、interactive 的节点赋予唯一整数 id，存进结构化索引 $\mathcal{D}=\{(id_j, text_j, tag_j, bbox_j)\}_{j=1}^{m}$，bbox 是屏幕坐标，方便后续做 overlay。第二步，路由：用户输入查询 $q$ 后，Router 用一段结构化 prompt（含 find/guide/hide/image_find/pdf_find 五个 handler 定义和例子）让 LLM 返回 $\text{mode}=f_{\text{router}}(q, C)$，其中 $C$ 是 page title 和 content type 等简略上下文；在 1,208 条标注查询上 Router 整体准确率 97.68%，find 类 97.4%、guide 类 100%、hide 类 97.2%（详见 Table 1）。第三步，分派处理：Find 是 single-pass，给 LLM 传入 $\mathcal{D}$ 和查询，让它输出形如「The movie was directed by [45:"Nolan"]...」的答案，每个 [N:"text"] 引用都对应 SoM 编号 N 和精确短语 text；Guide 是 iterative，LLM 一次只生成一个动作 $\{instruction, target\_index, action\_type, hint\}$，用户点 Next 后扩展重新读 DOM 再生成下一步；Hide 也是 single-pass，LLM 返回最多 15 个匹配元素，每个元素带 reason 和 snippet。第四步，DOM mutation：扩展解析 LLM 输出的编号，把 Find 的引用 span 用 luminance-aware 配色包成动画 overlay 并把视口滚到第一个引用；Guide 把目标元素加脉冲 beacon、显示 tooltip；Hide 在确认前弹出 review 对话框，每行带序号、隐藏理由、内容片段和 jump-to 按钮。第五步，错误恢复与状态机：Guide 在每次确认后重读 DOM，如果点击后页面状态和预期不符就重新规划剩余步骤；所有跨组件交互用 Playwright + GitHub Actions 做端到端 CI。

从技术新颖性上看，PageGuide 的核心贡献是把「grounded reasoning」做成了浏览器扩展里的一个可触摸的 UI 层，而不再停留在论文层面。具体新颖点包括：(1) SoM 风格的 DOM 索引被复用为统一的「寻址协议」，让 router、Find、Guide、Hide 共享同一份页面表征而不必各自重新解析 HTML；(2) Find 模式的 [N:"text"] 内联引用实现了「答案文本可点击、点击跳转到高亮 span」的双向链接，与 HoT 相比它不只是文本证据标签，而是真正可交互的 DOM overlay；(3) Guide 模式采用 mixed-initiative 单步确认协议（Next/Stop），并把「下一步会发生什么」做成 hint tooltip，让用户在点击前能预期结果，避免传统 agent 的「黑箱操作」；(4) Hide 模式把 LLM 当成「DOM 元素打分器」，配合 confirm-before-hide 的 review 对话框和每元素一句解释，把内容隐藏从「opaque background process」变成「transparent user-steered interaction」；(5) 系统在 N=94 的 within-subject 用户研究中，三个模式都跑出了统计显著的提升，特别是 Hide 模式准确率从 30% 跃升到 56%（+26 pp，相对提升 86.7%）、任务时间从 104s 降到 31.7s（-70%），这一类端到端的可用性证据在 Web Agent 文献里相当少见。

独立审视后可以挑出几个值得改进的弱点。第一，自动评测数据集明显偏小且对模型有依赖性。Find 整个测试只有 10 条用户研究题目 + Natural Questions + QASPER 两个老 benchmark，没有任何针对「网页环境」的专项评估；Hide 的 312 条自建样本来自 100 个网站，但 67 条 easy 占了 65%，难度分布不均。改进方向是引入更大、更现代的网页 QA benchmark（如 WebArena、WebVoyager 的真实网站实例）和 Hide 专用的 content-filtering 评测集。第二，Hide 的 LLM 评分逻辑是 prompt-based black-box，缺少对「漏掉元素」和「误伤元素」的细粒度归因分析。从 Table 5 看 Recall 59.36 仍偏低，意味着近一半本该隐藏的广告/推广没被识别，改进方向可以是先用 embedding 检索候选元素，再用 LLM 重排序，而不是单次直接生成。第三，Guide 的 Next/Stop 协议虽然符合 mixed-initiative 原则，但缺乏「undo last step」机制——一旦用户点错下一步就卡住只能从 Stop 重来。改进方向是引入 session-level 状态机和可撤销栈。第四，SoM 序列化只考虑 visible + text-bearing + interactive 节点，对 iframe 内部、shadow DOM、CSS pseudo-element（如 ::before 文本）覆盖不全，导致部分关键按钮可能没被索引。改进方向是支持 iframe traversal 和 shadow DOM piercing。第五，论文未量化 LLM 调用成本与延迟——一次 Find 调用可能引发多次 OpenRouter 调用（router + find + 可能的 fallback），在低端网络或高负载下用户体验会显著下降，建议增加端侧缓存或对常见 query 做 template-based fast path。

作者在 Section 5 提出的未来工作包括：(1) 用 multi-step planner 替代 single-mode Router，让「Find+Guide」复合任务能在一句话内完成；(2) 给 Find 加 re-ranking 把最相关的高亮排在前面，并持久化跨页 evidence trail；(3) Guide 加自适应步长粒度和 skip/undo；(4) Hide 引入用户偏好历史 profile，跨 session 学习。基于论文成果还可以延伸几个方向：(5) 把 grounded DOM 范式推广到更多内容类型——论文附录 G 已经展示了 PDF reading、Visual Question Answering（上传图片比对网页）、Page-Off（不绑定当前 tab 的 free-form question）三个扩展功能，未来可以再加 voice/AR 模态；(6) 把「用户每步确认」的协议推广到 autonomous agent 安全研究，用 PageGuide 的 overlay + confirm-before-hide 作为 agent 行为审计的可视化层，对应 DECEPTICON、Agent-SafetyBench 等论文关心的高风险操作；(7) 在企业 SaaS（Notion、Salesforce、Workday）里部署 PageGuide，把「跨应用文档查找」任务变成统一 DOM-grounded 检索；(8) 研究 LLM 在不同 page layout（dynamic SPA、virtual scroll list、infinite feed）下的 SoM 稳定性，这是当前评估里完全没覆盖的场景；(9) 把用户研究扩展到更异质的群体（年龄、职业、阅读能力）以验证外部效度。

复现性整体较好但仍有几个门槛。第一，开源情况：论文宣称「Code and demo is at: PageGuide.github.io」（论文摘要末尾），但论文正文未给出 GitHub URL，且根据上下文（IRB 通过、Manifest v3 Chrome 扩展、Playwright + GitHub Actions CI）应该会开源扩展源码、Prompt 模板和评估脚本，但目前需要到作者主页确认是否真的 release。第二，数据：Find 子集 10 条基于 Google Natural Questions + 自加 5 条，Guide 子集 138 条覆盖 37 个网站（来自 Wikipedia 最常访问列表），Hide 子集 108 条来自 100 个多样网站（社交、论坛、电商、内容平台）——这些数据集在论文中没有完整放出，需要联系作者获取；附录 F 描述了三条数据生成 pipeline 的步骤（collect → filter → annotate → validate），复现路径清晰。第三，模型：默认用 OpenRouter 调用 google/gemini-3-flash-preview 和 google/gemini-2.5-flash-preview（见 Appendix E），这两个模型都是 preview 版本，不保证长期可用，建议复现时锁定 snapshot 或改用 stable 版本。第四，算力：用户研究本身是 94 人 × 6 任务 × 3 分钟 ≈ 28 小时的人工实验，需要实验室、IRB 批准和招募渠道，自动化复现只需 GPU 推理 LLM 的算力（Gemini-3-Flash 通过 API 调用，本地无 GPU 要求）。第五，难度：扩展本身的端到端测试用 Playwright 跑，开发者需要熟悉 Manifest v3、content script 注入、side panel API，门槛中等；Prompt 模板在 Figures 13–16 全部公开，可以直接 copy-paste 调试。