今天发现一个挺有意思的开源项目。
agent-desktop。
它最近更新到了 v1.0.2，项目现在托管在 Vercel Labs 的 GitHub 组织下面。
我去翻了一下项目文档。
发现它解决的是一个非常实际的问题。
我们一直希望 AI Agent 能帮忙操作电脑。
打开软件。
点击按钮。
填写表单。
读取界面。
执行任务。
但以前常见的方式，需要让模型不断截图、识别画面、计算位置，然后模拟鼠标点击。
这套流程虽然能用，但很容易出现定位错误。
而 agent-desktop 提供了另一条路线。
让 Agent 直接读取操作系统中的界面结构。
这个思路，我觉得非常值得研究。
01｜不靠截图，AI 怎么知道按钮在哪里？
先说它的核心技术。
Accessibility Tree。
中文叫无障碍访问树。
大家可以把它理解成操作系统提供的一份界面结构说明。
比如一个软件窗口里有：
文件菜单。
保存按钮。
文本输入框。
设置选项。
这些界面元素可能会通过系统接口暴露自己的名称、类型、状态和可执行操作。
agent-desktop 就利用这些信息，把软件界面转换成结构化 JSON。
然后给每个可以操作的元素分配引用编号。
Agent 想点击按钮，就可以使用对应的引用。
执行完操作，再读取一次界面。
确认按钮是否真的被点击，或者输入框里的内容有没有变化。
整个过程就是：
观察 → 定位 → 执行 → 验证。
你看，这个结构是不是非常熟悉？
这就是我们一直在研究的 Agent Loop。
02｜它到底能做什么？
我看了官方仓库。
目前提供 60 个命令名称，其中 56 个是可执行操作命令。
涵盖界面观察、点击、输入、滚动、键盘操作、窗口管理、剪贴板和状态检查。
而且支持三大桌面操作系统。
Windows。
macOS。
Linux。
项目使用 Rust 编写，同时提供 CLI 和 C 库接口。
这意味着开发者可以直接通过命令行调用，也可以把它集成进自己的 Agent 工具系统。
更有意思的是，默认情况下，部分操作可以通过无障碍接口在后台执行。
不需要每次都移动鼠标。
不过它并不能保证所有软件都支持这种方式。
比如复杂的游戏画面、纯图形画布、自定义渲染控件，可能无法提供完整的界面结构。
这种场景仍然需要截图、视觉模型或其他自动化工具。
03｜Windows 用户怎么体验？
这部分直接给大家一个简单的入门流程。
首先安装 Node.js。
然后打开 PowerShell。
执行：
npm install -g agent-desktop
安装完成后，检查版本：
agent-desktop version
再查看当前可以访问的应用：
agent-desktop list-apps
接下来可以打开 Windows 记事本。
让工具读取它的界面：
agent-desktop snapshot --app Notepad -i
如果当前系统能正确识别记事本，就会返回一份 JSON。
里面包含窗口信息、界面元素以及对应的引用编号。
下一步，可以根据实际返回的引用编号进行操作。
例如：
agent-desktop click '@实际快照ID:e8'
注意，这里的编号只是格式示意。
必须使用你自己刚刚获取的真实引用。
操作完成后，再运行一次 snapshot，检查界面有没有发生预期变化。
到这里，我们就完成了一个最简单的桌面操作循环。
当然，我这里介绍的是根据官方文档整理的操作流程，并没有把它包装成已经在我的电脑上完成的实测结果。
04｜真正有意思的是，和 Codex 配合
如果只是自己手动输入命令，那还不算真正的 Agent。
我们需要让模型根据任务自动选择工具。
比如我希望 Codex 帮忙整理一个本地软件中的信息。
它可以先调用 agent-desktop，读取窗口结构。
然后分析应该操作哪个元素。
执行点击或者输入。
最后重新读取界面，检查任务是否完成。
官方还提供了可以安装到 Agent Harness 的 Skill。
安装命令是：
npx skills add https://github.com/vercel-labs/agent-desktop --skill agent-desktop
也可以把下面这段规则加入项目的 AGENTS.md：
Use agent-desktop to inspect and operate
desktop applications.
Before the first operation, read:
agent-desktop skills get desktop
agent-desktop skills get platform
For every task:
1. Observe the current interface
2. Identify the target element
3. Execute the permitted action
4. Observe the interface again
5. Verify the expected result
Do not invent element references.
If a reference is stale, take a new snapshot.
Require human approval before
destructive or sensitive actions.
这就是我比较喜欢的工程化方式。
模型负责理解任务。
agent-desktop 提供操作工具。
Harness 负责权限、状态和失败恢复。
最后通过验证机制判断任务是否完成。
05｜和传统 Computer Use 有什么区别？
这里我觉得需要讲清楚。
基于截图的 Computer Use，主要通过视觉理解画面。
它能够处理很多没有标准界面结构的软件。
但需要处理图片、定位坐标和界面变化。
agent-desktop 则优先使用操作系统提供的结构化信息。
对于能够正确暴露无障碍元素的软件，操作目标通常更明确，也更容易进行状态检查。
但两者各有适用范围。
对于网页、办公软件、常规桌面工具，可以优先尝试结构化操作。
对于游戏画面、3D 编辑器视口、复杂图形软件，则可能需要结合视觉操作。
我觉得未来更实用的方式，是让 Agent 同时拥有两套工具。
先尝试结构化界面。
如果无法识别，再使用视觉工具。
这样可以在操作效率和覆盖范围之间取得更好的平衡。
06｜这个工具对 Agent 开发意味着什么？
我觉得 agent-desktop 最重要的价值，是把桌面操作能力做成了一个相对独立的工具层。
它没有强制绑定某个大语言模型。
也没有替开发者规定完整的 Agent 工作流。
你可以把它接入不同的 Coding Agent。
也可以用 Python 或其他语言编写自己的调度逻辑。
对于企业来说，还可以在外层加入更严格的权限管理。
比如只允许操作特定软件。
禁止读取密码管理器。
限制剪贴板内容。
敏感操作必须人工确认。
记录每次工具调用和执行结果。
这些事情听起来没有“一句话让 AI 操作电脑”那么吸引眼球。
但真正把 Agent 部署到生产环境，就必须考虑这些问题。
特别是最近 AI 编程插件供应链出现安全事件后，桌面工具的权限隔离更加重要。
最后
agent-desktop 这次更新，我觉得非常适合正在研究 Agent Engineering 的开发者关注。
它给了我们一个很清晰的思路。
桌面 Agent 的能力，可以拆成几个部分。
模型理解任务。
Harness 管理执行。
工具负责操作软件。
验证机制检查结果。
而 agent-desktop，正好补充了其中的桌面操作工具层。
现在我们距离真正可靠的通用桌面 Agent 还有不少工作。
但至少又多了一个能够自己部署、自己研究、自己集成的开源选择。
以后开发 Agent，可能越来越重要的不是让模型多聪明一点，而是让它拥有更可靠的工具。
Github：https://github.com/vercel-labs/agent-desktop/releases
