2026 年 5 月,一个名为 agent-desktop 的开源项目登上了 Hacker News 首页,拿下了 99 分。一百多天之后,作者带着一份三个月后的更新回到 HN,标题相当大胆——I spent 3 months making desktop automation stop lying to AI agents。这条更新拿了 6 分,但讨论密度反而更高,因为它给出了一个具体答案:用操
2026 年 5 月,一个名为 agent-desktop 的开源项目登上了 Hacker News 首页,拿下了 99 分。一百多天之后,作者带着一份三个月后的更新回到 HN,标题相当大胆——I spent 3 months making desktop automation stop lying to AI agents。这条更新拿了 6 分,但讨论密度反而更高,因为它给出了一个具体答案:用操作系统原生的可访问性树替 AI Agent 看真实 UI,而不是靠截图猜像素。截至 2026 年 8 月,macOS 版已经 GA,Windows 与 Linux 接近发布。三个时间点的素材拼在一起,可以讲清楚一件事:为什么桌面自动化要让 LLM 看见 UI 的真实结构,这件事到底有多难,以及为什么它在 2026 年的可行性突然发生了变化。
桌面自动化在 2026 年的位置有点尴尬:浏览器自动化在 Playwright 那一代之后基本被解决了——拿到结构化的 DOM、ref、ARIA 标签,LLM 可以稳定地推理并操作。但桌面应用一直停留在截图加坐标的时代。Codex、Claude Code、CUA 以及这一波 Computer Use 工具里的大多数,工作方式大同小异:截一张图,让模型预测像素坐标,点 (x,y),再截一张图,循环。这个回路慢、烧 token、脆弱——UI 偏移几个像素就崩,而模型至始至终也不知道那个被点击的元素究竟是什么。
但操作系统本身已经把这些信息暴露出来了。macOS 的 Accessibility API、Windows 的 UI Automation、Linux 的 AT-SPI——屏幕阅读器用这些 API 已经用了十几年,Web 上 Playwright 之所以击败截图爬取,也是同一个原因:结构化访问就是比像素更好的抽象。把这套思路搬到桌面,就是 agent-desktop 的出发点。它是一个跨平台的 CLI,走可访问性树,提供 53 条命令、JSON 输出,让 LLM 在没有截图、没有视觉模型的情况下,也能检视并操作原生应用。一个二进制文件,大约 15 MB,没有运行时依赖。
一个典型的工作循环是这样的:agent-desktop snapshot --app Slack -i --compact 拿一份结构化快照,模型决定点哪个 ref,agent-desktop click @e12 执行,agent-desktop type @e5 ship it 输入文本,再触发快捷键。回到循环顶端,再快照一次。整个流程变成了四个动作——快照、决策、执行、再快照——而不是五步截图循环。
一、真正的问题是上下文窗口
把整个可访问性树塞进模型是最直觉的做法,但它直接撞上一面墙:真实应用的树非常大。Slack 一次完整的树转储,token 数可以轻松突破 50,000——这个规模让结构化访问在工程意义上变得不切实际。
agent-desktop 给出的答案是渐进式骨架遍历。第一遍只返回一棵浅树,深度通常到 3,更深的容器被截断,并附上 children_count。被命名的容器拿到一个 ref,模型可以请求只看那一支子树;动作执行之后,模型可以只重查那个区域,而不是重新快照整个应用。在 Slack、VS Code、Notion 这些 Electron 应用里,这种做法把 token 用量比完整树转储降低了大约 78% 到 96%。
实现细节里,有几个值得展开的设计选择。Rust 工作区通过 PlatformAdapter trait 把平台逻辑与核心逻辑严格分开;激活链优先走可访问性 API,鼠标合成只是 fallback,不是默认;元素 ref 像 @e1、@e2 一样确定地分配,并对 UI 偏移做乐观的重识别;错误是结构化的,带机器可读的错误码与重试建议;C ABI 通过 cdylib 暴露,所以可以从 Python、Swift、Go、Ruby、Node、C 直接 dlopen,而不是每次调用都 fork 一个 CLI。
二、三个月后:让 UI 不再骗 Agent
5 月份的 99 分帖子解决的是能用,8 月份的 6 分帖子解决的是可信。作者的原话是:Apps lie in both directions——Finder 在动作成功时返回错误,在动作无效时返回成功。如果只靠返回值判断,Agent 会做出完全错误的决策。
这一版的核心思路被作者自己拆成了五条具体设计:
骨架快照(skeleton snapshots)只快照父容器,给回 ref id,而不是把整棵可访问性树交给模型。
骨架下钻(skeleton drilling)在拿到浅树之后,Agent 可以决定钻入哪个具体区域。所有 --find、--click、--wait 之类的子命令,都在这个 ref 感知的区域内运行——这意味着找元素不需要在整棵树上搜索,Agent 拿到的是一个具体的提示,token 成本是原来的一小部分。
链式交互 fallback(chained interaction fallback)是这次更新里最反直觉的部分。一次点击不是一次 API 调用,而是一条有序的机制链:AXPress → AXOpen → 通过内部 cell activate → write selection → AXConfirm。每一步只在元素声明支持它时才会跑,成功与否不是看返回值,而是看应用状态是否真的变了——因为应用在两个方向都撒谎。先观察到的副作用胜出;响应里报告会尝试过的每一步,所以 Agent 能精确知道是哪条机制生效。
动作后反馈(after-action feedback)每一次动作都会报告它的处置状态——已交付并验证、已交付但未验证、未交付,以及任何弹出的界面(对话框、菜单、sheet)。Agent 在不重新扫描整个应用的前提下,就知道发生了什么。
严格的 ref 重识别(strict ref re-identification)ref 不是指针,而是身份证据——role、path、stable text、bounds hash。每次动作之前,它会针对实时 UI 重新解析。如果 UI 已经变了,你拿到的是 STALE_REF;如果现在有两个元素匹配,你拿到的是另一条具体的错误码。
这五条加起来,改变的不是工具的能力,而是工具的可观察性。Agent 不再被返回值欺骗,而是通过观察副作用、通过重新识别 ref、通过结构化错误码来推断真实状态。这正是从能用到可信的关键一步。
三、为什么这件事在 2026 年变得可行
把可访问性树用作 Agent 输入这件事并不新鲜——AppleScript 在 1990 年代就做过类似的事,Windows 的 UI Automation 也已经存在了十几年。真正的变化在于三个外部条件的同步成熟。
第一个条件是 OS 可访问性 API 的覆盖率。macOS 在过去几年里显著收紧了应用上架的 Accessibility 要求,Electron 应用(Slack、VS Code、Notion)也开始主动暴露密集的可访问性树——这正是 Agent 在桌面里遇到的最大障碍,也是这个项目骨架下钻设计要解决的真实问题。Windows 端的 UI Automation 与 Linux 端的 AT-SPI 同样覆盖了主流应用。
第二个条件是 LLM 自身的结构化推理能力。GPT-5.6、Claude Sonnet 5、Gemini Flash 这一代模型在读 JSON、ref 解析、错误码推理这几件事上,稳定性远好于两年前的模型——它们能可靠地处理给我 @e12 的元素、点它、观察状态这种工作循环,而不会因为一次失败就陷入死循环。
第三个条件是工具链的整合形态。agent-desktop 同时提供了 CLI、cdylib FFI、以及与 CDP 协议的互通——任何一个能调用外部进程的 Agent 框架都可以直接驱动它,而 Chromium 应用则通过 CDP 让 Playwright、Puppeteer、agent-browser 接管 Web 内容,把原生菜单、对话框、窗口留给可访问性路径。
把这三条放在一起,会发现一个相当具体的产业含义:桌面自动化的瓶颈不在模型,在结构。模型已经够好,框架已经够好,API 也在那里——真正缺的是一套让 Agent 看见 UI 真实形态的工具,以及一套让 Agent 看见自己动作真实结果的反馈机制。agent-desktop 这三个月补上的,正是后者的设计。
四、对企业级落地的几个判断
把这件事映射到企业内部常见的软件机器人场景,会得出几条具体的判断。
第一,截图加坐标这条路径,在企业内部通常不可持续。视觉模型对 UI 偏移、字体回退、分辨率差异极其敏感,任何一个版本的客户端升级都可能让整套机器人失效。可访问性树对 UI 偏移是结构上鲁棒的——只要元素的 role 与 label 没变,ref 就仍然有效。
第二,企业内部应用的可访问性树覆盖率参差不齐。原生 macOS 与 Windows 应用通常没有问题;Electron 应用近两年显著改善;但企业内部常见的 WinForms、Java Swing、Delphi 应用,可访问性树可能根本没有被维护。这条路径在落地时,需要先做一次目标应用的可访问性体检,而不是直接上 Agent。
第三,Agent 的可信度,最终由反馈链决定。返回值会撒谎,API 会超时,网络会丢包——这些都是工程现实。可信的设计不是避免失败,而是让每一次失败都暴露出来:结构化错误码、ref 重识别、副作用观察、动作后反馈。这套机制在企业内部的真正价值,不是 Agent 更聪明,而是运维能定位每一次异常。
第四,从浏览器自动化到桌面自动化的过渡,可能比很多人预期的要快。Playwright 在 Web 上的成功路径——结构化访问优于像素爬取——在桌面侧被同一批人重走一遍;Vercel Labs 的 agent-browser 已经在浏览器一侧验证了这条路,agent-desktop 把它搬到了桌面。Hacker News 上 99 分加 6 分的两条帖子,意味着这条路径在 2026 年已经从个人项目走到了工具链节点。
把视角拉远一点,会看到一个更一般的规律:任何 AI 看见世界的工程问题,解法很少是更好的视觉模型,而常常是换一个更适合被看见的接口。Web 上这个接口是 DOM,桌面上是可访问性树,API 调用是 OpenAPI 规范,数据库是 schema。模型的能力在持续变强,但真正决定落地速度的,是世界有多少把自己结构化地暴露出来。
三个月前的 agent-desktop 让这件事开始发生;三个月后的更新让这件事开始可信。剩下的,是企业内部应用愿不愿意也把自己结构化地暴露出来。