AX Tree：Agent 操作电脑时，真正需要的不是截图，而是界面语义

Agent 操作电脑不能只靠截图。AX Tree 把界面变成语义结构，让模型少猜像素、多读意图。

导语

让 Agent 操作电脑，最直观的方案是让它“看屏幕”。

截图发给视觉模型，模型判断哪里有按钮、哪里有输入框，再给出点击坐标。这条路足够通用，Canvas 应用、游戏、非标准界面都能覆盖。但它有一个很硬的代价：每一步都要处理大量像素，延迟高，token 贵，坐标还容易差几个像素。

桌面和浏览器里其实早就有另一条路。三十年前，无障碍技术为了让屏幕阅读器读懂图形界面，要求应用把 UI 的语义结构暴露出来：这里是按钮，名字叫“发送”；那里是输入框，当前值为空；这个菜单项被禁用；这个窗口里有一组可选文件。

这棵结构化的语义树，就是 Accessibility Tree，简称 AX Tree。

图：AX Tree 把视觉界面转成 Agent 可读取的语义清单

它原本服务于视障用户。今天，它正在成为 AI Agent 理解和操作数字界面的关键接口。

从像素到语义：AX Tree 解决的不是显示问题

图形界面对人类友好，对程序并不友好。屏幕上的按钮，对人来说一眼能看懂；对计算机来说，默认只是一片像素。

无障碍系统要解决的问题是：屏幕阅读器怎么知道一个按钮是按钮，它叫什么，现在能不能点击？

微软 1997 年推出 MSAA，Apple 在 macOS 中推出 VoiceOver 和 AXUIElement API，本质上都在做同一件事：把 UI 里的语义从像素里剥离出来，以结构化接口暴露给外部程序。

这套机制给 Agent 带来的价值很直接。模型不必先看图、猜控件、估坐标，而是可以直接读取一份机器可理解的界面清单。

每个节点通常会包含这些信息：

属性	含义	示例
role	元素类型	button、textfield、heading、menuitem
name	可读名称	发送、取消、搜索
value	当前值	输入框内容、滑块值
state	当前状态	enabled、selected、focused、disabled
frame	屏幕位置	x/y 坐标、宽高
hierarchy	层级关系	窗口、分组、列表、按钮之间的父子关系

AX Tree 不是视觉截图的替代品，而是另一种更接近“界面意图”的表示方式。

浏览器里，同一份 HTML 会变成三棵树

以 Web 页面为例，一份 HTML 进入浏览器后，不是直接被画到屏幕上。浏览器会先把它解析成 DOM Tree，再根据 DOM 渲染视觉界面，同时生成供无障碍系统读取的 AX Tree。

看一个简单 HTML：
` html

你好

`` ` ``

DOM Tree 会保留完整结构，包括只负责布局的 div：
` text
Document
└── html
└── body
└── div.container
└── div.layout-wrapper
├── h1 ("你好")
└── div.btn-area
└── button ("发送")
`

AX Tree 会过滤掉没有语义的布局节点，只留下对用户和辅助技术真正有意义的部分：
` text
WebArea
├── heading (level=1, name="你好")
└── button (name="发送", enabled=true)
`

这就是 AX Tree 的核心价值：它不是页面实现细节，而是经过语义过滤后的可操作界面。

对 Agent 来说，这比 DOM 更干净，也比截图更直接。DOM 里有大量样式容器、布局节点和前端实现细节；截图里只有像素。AX Tree 刚好站在中间，保留“用户能理解和操作什么”。

macOS 原生应用也能暴露同样的语义结构

Web 端有 DOM 和 ARIA，macOS 原生应用则通过 AXUIElement 暴露无障碍结构。只要应用遵循系统无障碍规范，外部程序就可以读取窗口、按钮、菜单、列表、输入框等信息。

下面是一段用 Python 读取 Safari 按钮的示例：
` python
import atomacos

获取 Safari 的 AX Tree 根节点

app = atomacos.getAppRefByBundleId("com.apple.Safari")
window = app.AXWindows[0]

遍历窗口中所有可操作按钮

for btn in window.findAllR(AXRole="AXButton"):
print(f"按钮: {btn.AXTitle} 位置: {btn.AXPosition}")

输出示例：

按钮: 后退位置: (x=20, y=52)

按钮: 前进位置: (x=50, y=52)

按钮: 刷新位置: (x=80, y=52)

这类接口让程序可以“读懂”一个正在运行的应用，而不是只能截图。macOS 的键盘导航、辅助功能检查器、部分效率工具对前台应用状态的感知，都和这套机制有关。

开发者也可以直接打开 Accessibility Inspector，把鼠标悬停在任意 App 的界面元素上，查看它的 role、name、value、frame 和子节点。它原本是调试无障碍的工具，现在也成了理解 Agent 桌面感知的入口。

截图很通用，但它让 Agent 交了太多“像素税”

截图方案的优势是覆盖面广。Figma、游戏、Canvas 应用、没有正确标注无障碍信息的界面，都可以通过视觉模型处理。

但标准 UI 场景下，截图经常不是最优解。

一张 4K 截图经过编码后体积很大，送进模型会带来高 token 成本和高延迟。视觉模型还要先完成控件识别，再估算坐标。按钮很小、界面密集、弹窗层叠时，坐标误差会直接导致点击失败。

AX Tree 则是几 KB 到几十 KB 的结构化文本。模型可以搜索 name，判断 role，检查 state，再根据 frame 做定位。它不需要“看懂像素”，只需要读懂结构化界面描述。

方案	优势	代价
截图 + 视觉模型	通用性强，Canvas 和非标准 UI 也能处理	token 成本高、延迟高、坐标精度不稳定
AX Tree / ARIA	结构化、低成本、可推理、定位更稳	依赖应用正确暴露无障碍语义
混合方案	标准控件走语义，缺失部分用视觉补齐	系统设计更复杂，需要路由和融合

这也是为什么很多新系统开始走混合路线：先读 AX Tree，拿到标准控件；遇到 Canvas、空节点、缺失语义，再让视觉模型补位。

Agent 时代，AX Tree 有三种主要用法

AX Tree 在 Agent 系统里的价值，大致可以分成三类：上下文感知、Web 自动化、桌面操作。

图：结构图 2 展示本节关键关系

第一类是上下文感知。桌面助手可以持续读取前台应用和窗口内容，理解用户正在写什么、看什么、处理什么任务。它不必等每个应用开放 API，也不必要求用户手动粘贴内容。操作系统层面的无障碍接口，天然提供了一条跨应用读取语义的路径。

第二类是 Web 自动化。传统自动化常依赖 CSS 选择器或 XPath，比如 div.btn-primary > span.label。这种定位方式和页面实现结构强绑定，前端稍微改版就会失效。基于 ARIA 的定位方式则更接近语义：找到名为“发送”的按钮，或者找到 label 为“邮箱”的输入框。只要控件语义不变，DOM 结构调整不会立刻破坏自动化流程。

第三类是 Computer Use，也就是让 Agent 直接操作浏览器和桌面应用。这里正在形成三条路线：

路线	感知方式	适用场景
截图派	截图给视觉模型，模型判断坐标	Canvas、游戏、无语义界面
AX Tree 派	读取结构化 UI 树，让 LLM 基于语义推理	标准按钮、菜单、表单、列表
混合派	AX Tree 提供主干，视觉模型补缺失节点	复杂真实桌面任务

这条边界很重要。按钮、菜单、表单这类有稳定 role 和 name 的元素，AX Tree 往往更稳；Canvas 类应用，视觉方案更合适。真正成熟的 Agent 不应该默认一路截图，而应该知道什么时候读语义，什么时候看像素。

操作录制的关键，也不是视频，而是语义事件流

很多人想到“教 Agent 做一个流程”，会自然想到录屏。人演示一遍，模型看视频学会。这个想法直观，但并不经济，也不稳定。

视频和截图记录的是像素变化。要从里面恢复“用户点了哪个按钮、选中了哪个文件、页面状态是否真的变了”，模型还要做大量视觉理解。

更适合 Agent 的记录方式，是结构化事件流：每个关键动作都带上窗口上下文、目标元素的 AX 属性，以及操作前后的 AX Tree 或 diff。

一个缩略事件流可能长这样：
` json

{"id":2,"kind":"window.changed","timestamp":"2026-06-21T00:00:01Z",
"app":{"name":"Sample Chat"},
"window":{"title":"Sample Chat"},
"ax":{"mode":"fullTree","text":"Sample chat main window\n AXButton title=Send file\n AXTextField title=Message input\n AXButton title=Send"}}

{"id":3,"kind":"mouse.click","timestamp":"2026-06-21T00:00:02Z",
"app":{"name":"Sample Chat"},
"window":{"title":"Sample Chat"},
"mouse":{"button":"left",
"target":{"role":"AXButton","title":"Send file"}}}

{"id":4,"kind":"selection.changed","timestamp":"2026-06-21T00:00:03Z",
"app":{"name":"Open"},
"window":{"title":"Open"},
"selection":{"target":{"role":"AXList"},
"selectedItems":[
{"role":"AXRow","title":"project-report.pdf"},

{"id":5,"kind":"window.changed","timestamp":"2026-06-21T00:00:05Z",
"app":{"name":"Sample Chat"},
"window":{"title":"Sample Chat"},
"ax":{"mode":"diffFromPrevious","text":"+ AXGroup title=sent attachments\n+ AXRow title=project-report.pdf\n+ AXRow title=budget.xlsx"}}
`

这类数据记录的不是“在坐标 (342, 891) 点了一下”，而是“在 Sample Chat 窗口里点击了 role=AXButton、title=Send file 的元素”。文件选择器里选中了什么，也不是靠截图猜，而是 selection.changed 明确记录了 selectedItems。操作后附件是否出现在界面里，可以通过 diffFromPrevious 看到新增节点。

图：结构图 3 展示本节关键关系

这就是语义事件流比视频更适合 Agent 的地方。它保留的是动作背后的证据，而不是动作发生时屏幕长什么样。

在回放或复用流程时，Agent 也不必机械寻找同一个坐标。只要当前界面语义仍然一致，它就可以重新定位同一个按钮、同一个列表、同一个输入框。窗口位置变了、布局微调了、分辨率不同了，流程也不一定立刻失效。

AX Tree 的质量，会变成 Agent 可用性的上限

过去很多团队做 ARIA、无障碍标签，主要是为了合规和视障用户体验。Agent 时代，这件事会多一个工程含义：你暴露给无障碍系统的语义质量，直接影响 AI 能不能操作你的产品。

如果一个应用大量使用 Canvas 渲染，或者控件没有 role、name、state，Agent 通过 AX Tree 看到的就是一片空白。它只能退回截图方案，开始猜像素坐标。

反过来，一个无障碍结构良好的应用，会让 Agent 更容易完成任务：

· 按钮有稳定 name。
· 输入框有清晰 label。
· 菜单和列表有正确 role。
· 弹窗、选中态、禁用态能被 state 表达。
· 动态内容变化能及时反映到无障碍树中。

这意味着，好的无障碍设计正在变成好的 Agent 兼容性。它不只是“让人能用”，也让机器能更可靠地理解和执行。

结语：三十年前的语义层，成了 Agent 的入口

AX Tree 最初不是为 AI 设计的。它是为了让屏幕阅读器、键盘导航和辅助技术理解图形界面。

但正因为它不是为某个 Agent 产品临时造出来的，它反而有很强的基础设施属性：跨应用、跨系统、结构化、低成本，并且和真实 UI 语义绑定。

未来的 Computer Use 很可能不会在“纯截图”和“纯 AX Tree”之间二选一。更现实的路线是：标准 UI 走 AX Tree 和 ARIA，缺失语义的区域再交给视觉模型补齐；实时任务读取当前 AX Tree，重复流程则沉淀成语义事件流，让 Agent 不必每次从零摸索。

让 Agent 操作电脑，真正难的不是让它看见屏幕，而是让它理解屏幕上哪些东西可读、可点、可编辑、可验证。

这件事，AX Tree 已经默默做了三十年。

AI小老六