如果 AI 不需要看截图，也不需要移动鼠标，就能直接操作电脑上的软件，会怎么样？

最近我注意到一个开源工具，叫 agent-desktop，做的就是这件事：

让 AI 不靠截图识别，直接读取软件的界面信息，找到按钮、输入框，替你把操作做了。

理论上，它甚至能让多个 AI 同时操作不同窗口，互不干扰。

听起来已经有点像我们期待的“电脑助理”了。

于是，我在 Windows 上实际测了它，涉及记事本、计算器、微信、飞书、Word 等软件。

先说结论：

技术思路有点意思，但就这轮实测而言，它几乎没展现出值得普通用户去用的价值。

能操作的软件，基本用不着专门让 AI 来操作；真正需要 AI 像人一样去操作的软件，它又频频失灵。

01｜技术思路：不看截图，它怎么知道按钮在哪？

传统的 AI 电脑操作方案，大多靠视觉识别：

先截屏，让模型找到按钮，再算坐标，模拟鼠标点击。

agent-desktop 想绕过这个过程。

Windows 本身提供了一套叫 UI Automation（UIA） 的接口，原本主要服务屏幕阅读器这类辅助技术，可以让程序读取界面里的按钮、输入框、菜单等控件信息。

比如打开计算器。

传统视觉 AI 得在截图里找到数字“7”，再移动鼠标点过去；agent-desktop 直接从系统给的控件信息里找到这个按钮，调用它支持的操作。

一个靠像素猜界面，一个靠系统接口读界面。

这并不是什么全新的底层发明。

企业自动化软件早就在用类似的接口，agent-desktop 只是把它接进了大模型。

不过这条路线确实有值得研究的地方：

如果 AI 能直接操作控件，就能省掉反复截图、识图的步骤，也不必每次都去抢鼠标。

问题在于，这种操作有个非常重要的前提——

目标软件必须向操作系统暴露足够完整的控件信息。

而现实里的 Windows 软件，并没有那么配合。

02｜计算器能操作，但这有什么用？

先交代一下它能跑通的测试。

记事本里，AI 能正常写入和读取文字。

计算器里，它能读出按钮并完成运算，全程不碰鼠标。

我还同时开了两个计算器窗口，让两个 AI 进程各算各的，结果互不干扰。

这些功能确实跑通了。

但说实话，我不觉得这有什么值得惊艳的。

我需要 AI 操作电脑，难道是为了让它帮我按计算器、往记事本里写几个字吗？

更何况，文件处理、文档编辑这类任务，已经有不少基于命令行、API 或专用 Skill 的 AI 工具能直接完成。

比如 Claude Code 配上针对 Office 文档的工具，就能绕开一堆繁琐的图形界面操作。

既然能直接处理文件，何必让 AI 像人一样，一个按钮一个按钮地点？

所以这些简单软件的测试，最多证明一件事：

agent-desktop 的底层操作机制是可行的。

至于它能不能真正提高生产力，还得看我们每天在用的那些软件。

03｜实测：真正需要它的软件，它基本都搞不定

我更希望 AI 能帮我干什么？

在微信里查聊天记录、整理文件；在飞书里搜内容、处理内容；或者打开 Word，把文档改好，准确保存到指定位置。

这些才是桌面 AI 助理该解决的问题。

但实际测下来，情况相当糟糕。

微信：主界面直接失明

微信是这次测试里最典型的例子。

登录页面能正常读取，可一进主界面，agent-desktop 返回的控件数量就是：

0。

聊天列表、好友头像、搜索框明明都在屏幕上，但通过它的控件读取方式，什么也拿不到。

我换了套环境和工具版本，隔了几天重新测，结果依然是零。

这意味着，至少在我测的这个微信版本上，它连最基本的界面识别都完不成，更别说搜聊天记录、整理文件了。

飞书：能打开搜索，却无法输入

飞书稍微好一点。

导航栏能操作，搜索面板也能正常打开。

但真正要用的搜索框，读不到。

换句话说，它能帮你打开搜索，却没办法通过控件接口完成搜索。

Word：工具栏能读，正文读不到

Word 的表现也很有代表性。

菜单、工具栏、状态栏能读到大量控件，可真正要处理的文档正文，却没法正常读取。

AI 能找到 Word 的各种功能按钮，却读不到你写的内容。

那我还让它操作 Word 干什么？

04｜为什么会这样？

问题很大程度上出在桌面软件的界面生态上。

传统 Windows 软件用标准控件时，系统通常比较容易拿到它们的信息。

但现代桌面软件大量用自绘 UI、混合架构或跨平台框架。

这些技术不一定会让无障碍接口失效，但如果开发者没完整暴露内部控件，系统就可能只读到一个窗口外壳，甚至什么都读不到。

对人来说，界面明明完整地显示在屏幕上；但对依赖控件树的 AI 来说，里面可能什么都没有。

至于微信这次为什么返回零个控件，仅凭实测还确定不了底层原因。

但对用户来说，结果已经很明确：

它读不到，就没法靠这条路线完成后续操作。

05｜读不到怎么办？

那就只能退回截图和物理鼠标。

这条退路我也测了。

让 AI 用电脑版微信打开一篇公众号文章，结果它不断移鼠标、切窗口、抢焦点。

文章最后是打开了，但整个过程里，我几乎没法正常用电脑。

更尴尬的是，就算不用物理鼠标，它也未必做得到真正的后台操作。

我让它去操作后台的计算器，结果计算器窗口不断抢焦点，直接打断了我在编辑器里的输入。

折腾到最后，常用软件的自动化没解决，理想中的后台静默操作也没实现。

06｜技术路线值得关注，但现阶段不好用

经过这轮测试，我对 agent-desktop 的判断很简单：

技术思路有一定价值，但实际体验远远没到预期。

直接读系统控件、不依赖截图，确实是种值得探索的桌面自动化方式。

至少在部分标准控件软件里，这套机制已经证明能跑通。

然而它的局限也很明显。

它高度依赖目标软件对自动化接口的支持。在 Windows 这么复杂的软件生态里，一旦碰上没法完整暴露控件信息的应用，它的核心能力就可能直接失效。

而这些应用，恰恰包括我们日常最希望 AI 帮忙处理工作的软件。

macOS 上它可能表现得好一些吧。但我没测，不好说。

至少在这轮 Windows 测试里，我没找到为它专门搭一套桌面自动化方案的理由。

更何况，浏览器有专门的自动化工具，文件和 Office 文档也有对应的 API、CLI 或 Skill 方案。

能直接调用专业工具完成的任务，没必要硬让 AI 学着人一样去点图形界面。

所以，如果你是开发者，想研究 AI 怎么通过系统接口操作桌面软件，agent-desktop 是块有意思的技术积木，值得玩一玩。

但如果你只是普通用户，指望装完之后就能让 AI 替你整理微信、处理办公文件、管电脑上的各种任务——

我不推荐你现在为它投入太多时间。

它目前展现出来的，是特定条件下的技术可行性，离成熟的实用能力还远。

不过这件事也让我想到一个更值得讨论的问题：

未来 AI 真正接管电脑，障碍可能不只是模型能力不够强，还在于今天的软件并没有普遍准备好让 AI 直接操作。

如果操作系统和应用软件能提供更完整、更统一的自动化接口，AI 电脑助理或许才能真正摆脱反复截图、抢鼠标、点错按钮的尴尬。

但至少现在，agent-desktop 还远没解决这个问题。

技术有意思，工具不好用。

这是我对它最简洁的评价。