桌面自动化的新选项:Agent-desktop 让 LLM 跳过截图直接读无障碍树

一、问题:截图方案为什么一直别扭

6 月 13 日 HN 上有一个 Show HN 上了首页前 10(99 分 / 44 评论),作者 lahfir 发了一个 Rust 写的 CLI 叫 agent-desktop(github.com/lahfir/agent-desktop,841 stars,Apache-2.0,主仓建于 2026-02-19,最近一次提交 2026-06-13)。它做的事很朴素:让 LLM 直接读操作系统层面的无障碍树(accessibility tree),而不是截图后再让 vision 模型猜坐标。

这个问题我们其实忍了很久。过去几个月 Codex、Claude Code、Cua 这些 computer-use agent 走的都是同一条路径:

1. 截图
2. 让模型预测像素坐标 (x, y)
3. 点击 (x, y)
4. 再截图
5. 循环

这条路慢、贵、还脆。UI 稍微平移几个像素,整条链路就会断。模型即便点对了位置,也根本不知道那个元素是"按钮"还是"菜单项"。

二、解法:用 OS 自带的结构化接口

操作系统其实早就给我们准备好了结构化的 UI 信息,屏幕阅读器用这套 API 已经几十年了:

- macOS:  Accessibility API(AXUIElement)
- Windows: UI Automation(UIA)
- Linux:   AT-SPI(Assistive Technology Service Provider Interface)

Web 这边的剧本已经被验证过一次——Playwright 之所以把 Selenium 之类的截图式工具打得没脾气,核心原因就是它走 DOM、走 ARIA 属性,是结构化访问。Playwright 是 web 的"Playwright 时刻",agent-desktop 想做的是 native 桌面版的同一件事。

三、我具体跑了什么

agent-desktop 是个 cross-platform CLI(虽然实际可用面是另一回事,后面会说)。单一 Rust 二进制,约 15 MB,零运行时依赖,对外暴露 53 条命令,输出全部是 JSON,让 LLM 直接消费。一个典型的交互循环长这样:

# 1. 拿到当前 app 的可访问性快照(带 ref id 和 compact JSON 输出)
agent-desktop snapshot --app Slack -i --compact

# 2. 用 ref id 点元素(不是像素坐标)
agent-desktop click @e12

# 3. 在指定元素上输入文本
agent-desktop type @e5 "ship it"

返回的 JSON 里每个节点都带确定性 ref id(@e5、@e12 这种),不是坐标。这对 LLM 来说直接友好一个量级:prompt 里不再需要塞"屏幕中央偏左下 200px 的那个按钮"这种话,直接 @e12 就够。

作者在 Show HN 里演示了一个 Finder 自动化——打开、定位文件、批量重命名,反馈是"快得出乎意料"(HN 用户 zuzululu 复测了同样的步骤,体感一致)。相对截图方案,token 消耗能省掉截图本身和坐标预测两块,体感响应时间从秒级压到亚秒级。

四、和同类方案的横向对比

工具	数据来源	协议	输出	平台
agent-desktop	OS 无障碍树	CLI + JSON	确定性 ref id	macOS 完整;Windows/Linux 不全
Playwright (Web)	DOM + ARIA	CLI / lib	element ref	跨平台
PyAutoGUI	截图 + 像素	Python lib	坐标	跨平台
Cua (YC X25)	截图 + vision model	Docker VM	坐标	跨平台(但要起 VM)

Cua 是另一个同期热门(Launch HN,172 分 / 73 评论),思路完全不同——它跑一个轻量 VM 给 agent 用,牺牲资源换隔离。agent-desktop 不需要 VM,代价是它必须跑在你真实的桌面环境里。两者不是替代关系,一个是隔离舱,一个是驾驶员。

五、目前还搞不定的事(承认局限)

读了 13 条 HN 评论和 README,有几件事得说清楚:

• macOS 之外并不完整:多个用户(包括 esperent、someone654、jstanley)都指出 README 上写 cross-platform,但实际能用程度在 Windows / Linux 上仅限特定 GUI 框架(GTK / Qt 之类走标准无障碍协议的)。Electron 应用、自绘 UI、Dear ImGui / egui 这类直接画 framebuffer 的库——目前还不能稳定工作。这是这个项目最大的局限,我自己没在 Windows / Linux 上系统测过,只是从评论里汇总。
• 演示素材偏少:有用户直接问"能不能给个清晰的 demo 视频"——README 上的 GIF 偏暗,我自己看了两遍才理清流程。这点比纯文字介绍差一档。
• iOS 模拟器 / Android:暂不在范围。社区有人问能不能管 iOS simulator,作者没回应。如果你想管移动端,得另寻方案(比如 Maestro)。
• 和 MCP 协作的边界:MCP 已经是事实标准的 agent 工具协议,agent-desktop 走 CLI + JSON 的方式兼容 MCP 调用(它 topics 里就标了 mcp),但和 Anthropic / OpenAI 各自 MCP server 的成熟度比,它还是个新工具,长期维护性我还在调研。

六、适用场景

基于上面这些,我自己的判断是:

• 个人开发者 / 小团队自动化日常桌面任务——非常合适。15 MB 单文件、JSON 输出、零依赖,放进 agent loop 里基本是 drop-in。
• macOS 原生 app 重度使用 + Claude / GPT-4V 截图方案成本太高——直接换 agent-desktop,token 成本和延迟能压掉一个数量级。
• 跨平台生产环境需要管控——不适合,Linux / Windows 覆盖面不够,等作者把 AT-SPI / UIA 那一层做完再说。
• 必须跑在隔离环境——Cua 那条 VM 路线才是该选的,agent-desktop 这种直接吃本机无障碍 API 的工具,风险较高,别在生产系统上裸跑不可信 prompt。

参考链接

1. agent-desktop GitHub: https://github.com/lahfir/agent-desktop
2. HN 讨论(99 分 / 44 评论): https://news.ycombinator.com/item?id=47982708
3. Apple Accessibility API 文档: https://developer.apple.com/documentation/accessibility
4. Playwright(作为 web 端类比): https://playwright.dev/
5. Cua(同类对比,VM 路线): https://github.com/trycua/cua

(全文约 1700 字。我自己用截图方案的体感是"能跑但别扭"——换到无障碍树这一层之后,prompt 简单了一档,token 也省了不少,但跨平台那条线还远没到能放心上生产的程度。先把 macOS 路径跑稳,Linux/Windows 等社区补齐再说。)