先记住这个答案
可访问性树已经过滤掉大量纯表现层节点，保留带角色、名称、状态的可交互元素，语义密度高，token 成本低，且与辅助技术视点一致，便于 Agent 决策。相比之下，原始 DOM 包含大量无关脚本和样式节点，截图则缺乏结构化语义。因此，对于文本型 Agent，可访问性树是首选。
- 可访问性树过滤纯表现节点，token少
- 它保留角色名称状态，利于操作决策
- DOM可能更大且包含不可见或无关节点
机制：浏览器从 DOM 派生感知视图
浏览器根据 DOM 和 CSS 计算可访问性树：先为渲染内容计算 role、name、value、state 等属性，再裁掉不可见节点（如 display:none）以及无语义角色的纯布局元素（如多数 <div>、<span>）。因此树往往只有 DOM 节点数的几分之一。
Agent 拿到快照后，能直接看到可点击的按钮、链接、输入框及其文本，而不是从大量标签和属性中自我挖掘。这既降 token，又契合模型天然理解自然语言与界面控件语义的能力。相比截图，它包含精确的结构和状态，无需视觉理解。
场景：登录页面的令牌与决策成本
假设一个登录页面。原始 HTML 可能包含几十个 <div>、<svg>、<script> 和隐藏样式节点，约 3000 token 才能包裹。可访问性树快照只保留两个输入框、一个按钮、可能还有指向帮助的链接，不足 200 token。模型能快速决定如何填表和点击。
实际操作时，Agent 依据快照中的角色与名称定位元素（Playwright 的 ariaSnapshot 返回 YAML 结构；若需要 ref 形式的元素引用，可用 Playwright MCP 的快照能力），再调用 click 和 fill。若用 DOM，模型需自行过滤大量无关节点，容易受脚本内容或隐藏字段干扰，增加令牌消耗却降低准确率。
边界：可访问性树并非总完整
若页面用 Canvas 绘制交互区域，或自定义组件未正确映射 ARIA，可访问性树会看不到关键操作。若单纯依赖树，Agent 可能误判无需操作，此时需回退到 DOM 或截图，并结合视觉模型确认。
再者，可访问性树按辅助技术视角输出，会省略 aria-hidden 的内容，甚至对焦点顺序等做了抽象，但 DOM 中的结构层次与样式信息被过滤。对于确定元素坐标或调试布局，必须查 DOM 与样式。替代代价是增加指令与解析复杂度。
容易答错的地方
- 可访问性树一定比 DOM 准确
- 可访问性树依赖浏览器计算与 ARIA 映射。若组件实现有缺陷（如错误 role），树也会错。它不是真理，而是语义视图，需与 DOM 互补。
- 快照必须转成完整 JSON
- 快照展示为缩进列表即可，不必保留全部属性。追求完整会膨胀 token，丧失浓缩优势；只保留角色、名称、状态与引用是关键。
面试官还会怎么问？
可访问性树和 DOM 快照在什么情况下 token 数会接近？
当页面几乎全是语义化元素且无多余布局节点时，两者 token 数接近。但多数真实页面 DOM 含大量脚本与包装节点，树更精简。
若页面有 Shadow DOM，可访问性树能看到内部吗？
open/closed 只限制 JS 经 element.shadowRoot 访问，并不直接决定无障碍树内容：浏览器自身计算的无障碍树通常仍会展平并包含闭合 shadow 内的语义。但基于 DOM 遍历的快照工具（如 Playwright 的 ariaSnapshot）只能穿透 open root；闭合模式下需改用浏览器无障碍接口（如 CDP Accessibility）获取，注入脚本通常无法从外部穿透封闭边界。
多模态 Agent 用截图为主时，可访问性树扮演什么角色？
树可提供精确文本和状态，用于避免截图误读（如看清输入值或选中态），同时削减视觉 token 成本；二者结合可互补。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。