当 AI 浏览器代理在复杂网页上执行任务时，一个令人沮丧的现实是：单个亚马逊产品页面可能产生高达 15 万 Token 的原始 HTML，而这些内容中真正有价值的语义信息可能不足 1 万 Token。这种严重的 Token 膨胀不仅推高了运营成本，更导致了上下文污染和模型幻觉问题。工程团队需要跳出简单的「抓取 HTML」思路，转而构建基于 DOM Delta 压缩与增量更新的智能架构，才能真正实现可扩展的浏览器自动化方案。
问题根源：DOM 规模与模型上下文的矛盾
现代 Web 应用的复杂性已经超出了传统浏览器自动化工具的设计假设。一个典型的电商产品页面包含了大量的 CSS-in-JS 垃圾代码、水合作用标记、追踪像素以及为了满足框架要求而存在的嵌套 div 结构。当工程团队直接将这段庞大的 HTML 文档塞进 Claude 或 GPT-4 的上下文窗口时，问题接踵而至：单次导航步骤的成本可能达到 0.5 至 0.75 美元，一个包含 20 个步骤的工作流在完成任何实际任务之前就已经烧掉了 15 美元。更严重的是，模型会「遗忘」用户的核心指令，因为它们被淹没在数千行无关的标记代码中。标准 Playwright MCP 集成的崩溃正是源于此 —— 它将整个页面源码作为工具输出返回，直到上下文窗口溢出导致一切失败。
针对这一问题，业界领先的团队已经发展出一套认知架构，将浏览器自动化的复杂度从「如何让模型理解整个页面」降低到「如何让模型只理解必要的部分」。这种架构的核心洞察是：停止使用 DOM 进行推理，转而使用可访问性树。浏览器生成可访问性树（Accessibility Tree）是为了支持屏幕阅读器，它会激进地修剪那些纯粹用于展示的元素，只暴露语义信息：角色（Role）、名称（Name）、描述（Description）和状态（State）。实测数据显示，这种技术可以一次性提供 10 倍至 15 倍的上下文缩减，原本 15 万 Token 的亚马逊页面可以压缩到约 1 万 Token 的语义地图。
核心机制：DOM Delta 压缩的工程实现
DOM Delta 压缩的核心思想是只发送 DOM 状态之间的变化（增量），而非每次都传输完整的快照。这与版本控制中的 diff 原理类似，但在 Web 代理场景下需要考虑更多的工程约束。增量压缩面临的首要挑战是计算开销 —— 每次页面变更时都需要精确计算两个 DOM 版本之间的差异，这需要额外的处理时间和计算资源。其次是参数调优的复杂性 —— 不同的页面结构需要不同的压缩策略，一刀切的配置往往效果不佳。
工程实现中，DOM Delta 压缩通常包含三个核心步骤。第一步是状态捕获，通过 Chrome DevTools Protocol 或 Playwright 的 DOM 快照功能获取当前页面的序列化状态。第二步是差异计算，使用树形 diff 算法（如 Myers 算法或其变体）识别新增、删除或修改的节点。第三步是增量序列化，只将变化的部分编码为紧凑的指令序列发送到模型端。这种方法的理论收益是会话期间的 Token 使用量可以保持固定，无论任务持续多长时间，因为历史信息被持续压缩而非无限累积。
结合 D2Snap 等下采样技术，增量压缩的效果可以得到显著提升。D2Snap 算法定义了三种节点特定的压缩程序，分别针对元素、文本和属性进行差异化处理。对于元素，算法通过合并容器元素（如 section 和 div）来简化 DOM 树结构，参数 k 控制合并比例。对于文本，算法基于 TextRank 算法对句子进行重要性排序，并丢弃排名最低的文本片段，参数 l 控制丢弃比例。对于属性，算法根据预训练模型评估每个属性的 UI 特征得分，低于阈值的属性将被丢弃，参数 m 控制这一阈值。实验数据表明，经过优化的 D2Snap 配置可以实现 27% 至 73% 的大小缩减，使复杂页面能够轻松适配 128K 的上下文窗口。
增量同步：流式更新与状态管理
在实际的 AI 浏览器代理中，增量更新需要与流式同步机制紧密配合才能发挥最大效用。流式同步的核心优势在于无需等待完整页面加载完成即可开始处理可用的 DOM 信息，这大幅降低了首次 token 到达的延迟。然而，流式场景下的增量压缩面临额外的挑战：如何在部分 DOM 信息的情况下准确计算差异？如何处理网络抖动导致的消息乱序？如何确保增量指令的幂等性以支持重试机制？
工程实践中的解决方案通常采用「快照锚点 + 增量流」的混合模式。系统首先建立一个完整的 DOM 快照作为参考锚点，后续的所有增量更新都相对于这个锚点计算。每个增量指令携带唯一的序列号和基准版本号，接收方可以根据这些信息进行乱序重组和缺失检测。当检测到增量丢失时，系统可以请求重发特定版本区间或回退到完整快照。为了进一步降低增量大小，工程团队还可以引入「微快照」机制 —— 每隔 N 个增量步骤自动生成一个轻量级的完整快照，用于控制误差累积和简化状态恢复。
流式同步的另一个关键考量是模型端的指令解析效率。增量指令的语义复杂度直接影响模型的推理延迟。过于细粒度的增量（如「将第 347 个 div 的 class 属性从 foo 改为 bar」）虽然节省了传输带宽，但增加了模型的理解负担。过于粗粒度的增量（如「页面主体区域发生了一些变化」）则失去了压缩的意义。实践中，工程师通常会在增量指令中嵌入结构化的变更描述，包含变更类型、影响范围和语义类型三要素，使模型能够快速定位关键变化而无需逐行解析整个 diff。
可落地参数与监控清单
对于计划实施 DOM Delta 压缩的工程团队，以下参数配置和监控指标可以作为起步参考。在压缩参数方面，可访问性树提取应作为默认起点，预期实现 10 倍至 15 倍的 Token 缩减。对于列表密集型页面（如搜索结果、商品网格），建议引入 SimHash 折叠策略：将具有相同结构的兄弟元素折叠为「首个元素 + 摘要」的形式，并通过搜索工具按需展开特定项目。这种方法可以实现与列表大小无关的 O (1) Token 成本。对于视觉推理需求较高的场景（如「点击图片下方的红色按钮」），建议部署 Set-of-Mark 方案：在截图前通过脚本为交互元素注入数字标签，模型输出标签编号后由编排层映射回实际的 DOM 元素。
在监控指标方面，核心观测点包括：每次交互的输入 Token 数量（目标值：9,000 以下）、上下文压缩率（目标值：原始 DOM 的 10% 以下）、增量同步延迟（P50 应低于 200 毫秒）、任务完成率（相比无压缩基线提升 3 至 5 倍）以及单次任务成本（目标值：0.005 美元以下）。建议建立仪表盘实时追踪这些指标，并在出现异常时触发告警。成本监控尤为重要 —— 当单次任务的 Token 消耗超过预算阈值时，系统应自动降级到更激进的压缩模式或请求人工确认。
分层实施路径可参考如下规划：第一周至第二周聚焦基础建设，将原始 DOM 提取替换为可访问性树，测量上下文缩减比例并建立基线指标；第三周至第四周推进算法优化，对列表密集型页面实现 SimHash 折叠，为需要视觉上下文的任务添加 Set-of-Mark 能力，并构建成本监控仪表盘；第五周至第六周完成规模化改造，部署 Manager-Worker 模式处理跨页面复杂工作流，集成 Human-in-the-Loop 检查点应对高风险操作，并引入反检测机制应对高级防护系统。预期 ROI 包括：每步 Token 成本降低 10 至 15 倍，任务完成率提升 3 至 5 倍，多数导航步骤延迟降至亚秒级。
总结
DOM Delta 压缩与增量更新代表了 AI 浏览器代理工程化的一个重要方向。通过可访问性树提取、差分压缩算法和下采样技术的组合使用，工程团队可以将原本动辄十几万 Token 的页面压缩到几千 Token 的可管理范围，同时保持甚至提升任务完成率。这种方法的核心价值不在于某个单点优化，而在于构建了一套从状态捕获、差异计算到流式同步的完整架构。随着 AI 代理在 Web 自动化场景的应用日益广泛，掌握这些压缩与增量技术将成为团队竞争力的关键差异点。
资料来源：D2Snap 官方论文与实现（arXiv:2508.04412）、Webfuse DOM 下采样技术解析。