不用截图也能操作桌面：Vercel agent-desktop 把“电脑使用权”交给了所有 Agent

让 AI Agent 操作你的电脑，最省事的办法一直是给它看屏幕截图：截一张图、猜一猜按钮在哪、算一算像素坐标点下去。这套办法能跑，但又贵又脆弱：一张截图就要吃掉上千个 token，窗口一动、分辨率一变，坐标就全错。2026 年 10 月 30 日，Vercel Labs 把一个不一样的答案推到了台前：agent-desktop 1.0.2，一个开源的命令行工具加 C 语言库，让任何 Agent 不用看图、直接读操作系统的无障碍树来操作桌面应用。

关键要先说清楚它的定位：agent-desktop 本身不是一个 Agent。它不内嵌大模型、没有图形界面、也不跑推理循环。它是一个“工具”，是 Agent 调用的一双手和一双眼睛。Agent 还是你原来用的那个，变的是它感知和操作桌面的方式：从“看图猜坐标”变成了“读结构、拿编号、按编号操作”。

它是怎么看见桌面的

每台主流操作系统都有一套为辅助功能准备的结构化接口：macOS 的 AX API、Windows 的 UI Automation、Linux 的 AT-SPI。屏幕阅读器就是靠这些接口“读”屏幕的。agent-desktop 走的正是同一条路：它把应用的界面读成一棵树，按钮、输入框、菜单、表格行都是树上的节点，每个节点带一个引用编号，Agent 拿到的是结构化的 JSON，而不是一张图片。

一次典型的循环是这样的：先执行 snapshot 命令，拿到当前窗口的快照；快照里每个可操作元素都有一个类似 @s8f3k2p9:e8 的引用，前半段是快照编号，后半段是元素编号；Agent 对这个引用执行点击、输入、展开、滚动；操作完再拍一次快照，确认界面是不是真的变成了预期的样子。观察、行动、再观察，循环的控制权始终留在 Agent 自己手里。

引用编号的设计里藏着几个防呆细节。引用必须连同它所属的快照一起用，单独一个 @e8 会被直接拒绝；界面变了之后，旧引用会返回 STALE_REF 或者 AMBIGUOUS_TARGET，Agent 就知道该重新拍快照，而不是凭着过期编号硬点。多个窗口长得差不多时，工具会把候选窗口编号列出来，让 Agent 先指定窗口再动手。这些规则看起来琐碎，实际是在解决像素方案最痛的一点：点错东西还没有自知之明。

为什么不用截图反而更便宜

截图方案的账很好算。Anthropic 的文档提到，一张截图大约消耗 1000 到 1800 个输入 token，再加上每次请求约 4500 个 token 的工具集开销。界面越复杂、步骤越多，这笔账滚得越快。agent-desktop 的卖点是：结构快照比图片便宜得多，尤其是在界面节点成千上万的“重型应用”里。项目方给出的自测数字是：用骨架快照只读三层深度、再对局部钻取，Slack、VS Code、Notion 这类应用的 token 消耗能比全量树形转储少 78% 到 96%，Apple Maps 的一次查看据称从 3811 个 token 降到了 273 个，一段 52 步的模拟任务从 198k 降到了 31k。

这些数字必须打上一个明确的标签：它们来自项目方自述，目前没有独立的第三方基准验证。写进正文不是为了背书，而是为了把“便宜多少”这个问题的现状说清楚：方向可信，数字待验。任何人在选型时拿自测数字当采购依据，都是在拿自己的预算替厂商做验证。更值得关注的是另一个不花钱的好处：无头执行。引用操作默认走无障碍 API，不移动你的鼠标、不抢走窗口焦点，Agent 在后台干活的时候，你可以继续用电脑。需要真实输入时，再用 --headed 显式切换到有头模式。这种“人不让位、Agent 照样干活”的体验，是截图方案很难给出来的。

装上就能用吗

安装本身只有一行：npm install -g agent-desktop，Bun、Yarn、pnpm 也行，包里自带了 x64 和 ARM64 的原生二进制。平台支持覆盖 macOS 13 及以上、Windows 10 1809 及以上或 Server 2019 及以上、Ubuntu 24.04 及以上，纯 CPU 就能跑，不需要 GPU。但权限这一步不能跳过：macOS 需要授予无障碍权限，工具自带 permissions --guide 引导；Windows 在终端同等权限级别下不需要额外授权；Linux 需要图形会话里的 at-spi2-core。Homebrew 和 Scoop 的官方包还在提交中，暂时不在默认仓库里，仓库也不再维护自定义的 tap 和 bucket。

工具一共 60 个命令名，其中 56 个可用，剩下 4 个按键按住类命令要等守护进程支持释放操作才开放。命令按观察、按引用操作、键盘鼠标、应用窗口、通知、剪贴板、等待、会话、系统分了组，Agent 可以通过 agent-desktop skills get desktop 和 skills get platform 把本机对应的用法文档直接读进上下文。除了命令行，每个版本还附带 libagent_desktop_ffi 这个 C 库，Python、Swift、Go、Ruby、Node 都可以在进程内调用同一套能力，不必每次起一个 CLI 进程。对 Electron 应用，launch --cdp 还能打开 DevTools 端口，接上同门的 agent-browser。

它解决不了的四件事

第一，没有无障碍树的界面，它够不着。大量自绘界面、游戏画面、老旧应用根本不暴露结构信息，工具再聪明也读不到。第二，无障碍树的质量参差不齐。有的应用节点命名规范、层级清晰，有的则是一堆没有名字的容器，Agent 读到的结构可能是残缺的，操作成功率会跟着打折。第三，权限本身就是攻击面。授予无障碍权限，等于允许这个工具代替你点击、输入、读取剪贴板和通知。一旦 Agent 被提示注入带偏，或者工具链里混进恶意组件，后果比截图方案更直接——因为它操作的是真实界面上的真实按钮。所以项目 README 里专门提醒：快照、剪贴板读取、截图、命令输出和调试产物都可能包含私人桌面内容，不要把它们贴进公开日志和上传内容里；可选的 JEV 辅助模块还会把屏幕描述发给配置好的模型厂商，那是独立于原生 CLI 的另一条数据流，用之前要单独评估。第四，它不负责判断。工具只保证“按编号操作”这一步可靠，至于该点哪个、点完对不对、要不要继续，全是 Agent 的责任。把判断力外包给工具，是对这个项目最常见的误读。

和同类方案放在一起看

市面上的电脑使用方案大致分三路。第一路是模型厂商的 API 工具集，比如 Claude 的 computer use 和 OpenAI 的 computer use，优势是开箱即用、模型和工具一体调优，代价是按量付费、依赖厂商、且以截图和像素为核心。第二路是完整 Agent 框架，比如微软开源的 UFO²，同样走 UI Automation 路线，但它本身就是一个 Agent，有自己的推理和管理层。第三路就是 agent-desktop 这样的中立工具层：不带模型、不做决策、只把桌面变成结构化接口，任何 Agent 都能接。三种路线没有高下，只有取舍：想要最快跑起来，选厂商 API；想要一个能自己改的完整 Agent，选框架；想要把桌面操作能力嵌进自己已有的 Agent 体系，或者想在不同模型之间切换而不重写操作层，工具层更合适。Vercel Labs 的算盘也很清楚：Apache-2.0 开源、跨三平台、模型无关，赌的是“桌面操作”会变成 Agent 基础设施里的一层，而不是某家模型的独占功能。这个赌注能不能成，要看社区会不会真的在它上面长出生态，而不是只停留在发布当周的星标数上。仓库本身创建于 2026 年 2 月，10 月 30 日的 1.0.2 是公开推广的节点，而不是从零写出来的新项目，这一点值得说清楚：它的成熟度来自近一年的迭代，不是发布会上的演示。

给 vibe 开发者的三条建议

第一，先拿它给自己的应用做无障碍体检。你的应用在无障碍树里长什么样，决定了 Agent 能不能顺利操作它，也决定了残障用户能不能顺利使用它。跑一遍 snapshot，看看按钮有没有名字、层级有没有逻辑、关键操作能不能被引用命中，这既是 Agent 兼容性测试，也是无障碍质量测试，一举两得。第二，别在主力机上裸奔试新工具。先在备用机或虚拟机里授予权限，先跑只读的 snapshot 和 find，确认行为符合预期，再逐步放开点击和输入；涉及真实账号、真实支付、真实数据的界面，一开始就排除在自动化范围之外。第三，把 token 账算在自己的基准上。厂商的 78% 到 96% 是自测数字，你的应用界面结构不同，结果就会不同。拿你自己的高频任务跑一遍截图方案和结构方案，对比 token、步骤成功率和失败恢复成本，再决定要不要迁移。工具选型最忌讳的就是抄别人的基准当自己的结论。

一句话总结：agent-desktop 没有发明“让 AI 操作电脑”这件事，它只是换了一种更便宜、更稳定、更不打扰人的实现方式：不猜像素，读结构；不抢鼠标，后台干活；不绑模型，谁都能接。这层基础设施值不值得押注，答案不在发布稿里，而在你自己的应用和任务上跑出来的数字里。

实操：用一组命令走通第一个任务

纸上谈兵容易，真正上手时建议按这个最小闭环走一遍。先用 list-apps 看看工具能不能列出你的目标应用，确认权限已经生效；再对目标应用拍一张只含可交互元素的快照，读一读返回的 JSON，确认按钮和输入框的名字对不对得上你的预期；然后挑一个无害的操作，比如点开一个菜单、展开一个分组，执行完立刻再拍一次快照，验证界面确实变了；最后才尝试带输入的操作，比如往搜索框里打字，并且同样用快照验证结果。这个“拍一张、动一下、再拍一张”的节奏，就是工具设计者希望 Agent 遵守的循环：每一次行动都要有验证，验证失败就重新拍快照、而不是重试过期引用。错误处理也有一条铁律：只有当错误信息里的处置标注为可安全重试时才重试，否则就停下来、重新观察。很多自动化脚本的灾难都来自同一类写法：失败了就原地再点一次，结果界面早已不是原来那个界面，第二次点击落到了完全不同的按钮上。把这条纪律写进你的 Agent 提示词或者技能文档里，比多写十个重试分支都管用。还有一个容易忽略的点：先在测试数据上跑。不要第一次就让 Agent 操作真实收件箱、真实账单、真实客户数据，测试账号和沙盒环境存在的意义，就是让你在出事时只损失测试数据。

什么时候别用它

工具再好也有不适用的场景，提前划清边界能省下很多返工。第一，如果目标应用本身提供了 API 或者命令行接口，优先走接口，不要开着界面自动化去绕远路。界面自动化永远是备选方案，不是首选方案，接口更稳定、更快、更容易测试。第二，如果任务本身就是视觉判断，比如检查设计稿还原度、核对图片渲染效果、玩需要看画面的游戏，结构快照帮不上忙，这时候截图和视觉模型才是对的工具。第三，如果应用的无障碍支持很差，快照里全是无名容器，强行用引用操作只会得到一堆猜谜式的失败，不如先推动应用本身补齐无障碍信息，或者换一条自动化路线。第四，如果任务涉及敏感操作，比如转账、删除数据、修改权限，不要把决策权完全交给自动化，至少留一个人工确认环节。工具的价值在于把“操作”这一步做可靠，而不是把“判断”这一步也承包过去。分清这两步，是用好所有 Agent 工具的前提，也是这篇文章最想留给读者的一句话。

时间线：10 月 30 日到底发布了什么

这里需要把时间线掰开说清楚，避免把一次公开推广误读成从零到一的诞生。仓库本身创建于 2026 年 2 月，此后经历了近一年的迭代；1.0.0 在 10 月下旬到达 npm；10 月 30 日，Vercel Labs 的成员在公开渠道集中介绍了这个项目，GitHub 上的最新版本随之来到 1.0.2；10 月 31 日，多家技术媒体跟进报道。也就是说，10 月 30 日这个日期，标记的是“正式推向更广泛开发者群体”的节点，而不是第一行代码写成的日子。这对评估成熟度很重要：一个打磨了大半年的项目，和一个为发布会赶工的演示，值得给出的信任额度是不一样的。反过来也提醒读者，版本号和星标数都只是参考，真正验证的办法是自己去看：打开 GitHub Releases 页面，确认 1.0.2 的发布时间和更新内容；读一遍 README 里的平台支持表，确认你的操作系统和架构在列；跑一次 version 命令，确认装上的就是你以为的那个版本。做完这三步，再决定要不要把它放进自己的工具链。

最后回到最初的问题：Agent 操作电脑，到底应该看图还是读结构？这篇文章的立场是，结构优先、截图补位。能读结构的时候读结构，因为它更便宜、更稳定、更不打扰人；必须看画面的时候再截图，因为有些判断只有眼睛能做。agent-desktop 的价值，就是把“读结构”这条路铺成了一条任何 Agent 都能走的通用道路。路已经铺好了，走不走、怎么走，取决于你的应用、你的任务和你的风险承受能力。

顺带收益：为 Agent 优化，等于为所有人优化

还有一个收益很容易被忽略：当你为了让 Agent 顺利操作而去修应用的无障碍树时，真正受益的不只是 Agent。按钮有了准确的名字，屏幕阅读器用户就能顺利使用；层级有了清晰的逻辑，键盘导航用户就能少按很多次 Tab；关键操作有了稳定的标识，自动化测试也能跟着变稳。很多团队把无障碍当成上线前的合规负担，能拖就拖，而 Agent 时代给了它一个新的正当理由：你的应用越“可读”，就越能被越来越多的 Agent 顺畅操作。在这个意义上，agent-desktop 这类工具的出现，可能会无意中推动一大批应用补上早就该补的无障碍课。这堂课的受益者，首先是真实的人，其次才是 Agent，这个顺序值得在每一次技术选型里被记住。

如果你今天就要动手，建议从最小的只读任务开始：先让 Agent 在测试机上读一读你的应用，看看它读到的结构和你以为的结构是不是同一回事。这个简单的对照，往往比任何发布稿都更能告诉你，你的应用离“Agent 可用”还有多远。