国内大神开源:AI 能操控你电脑上所有软件,还不抢你的鼠标

01先把它能干什么说清楚

能开浏览器解决的，别用它。浏览器那条线已经很卷了，browser use 加各家插件随便挑。真正没人管的是浏览器之外的原生应用。

它操作的是你桌面上真实的窗口。应用得开着、有窗口、没最小化，它才看得见。所以准确说法不是"所有软件都能碰"，而是——你眼睛能看到的那扇窗口，它也能看到。

最关键的一点，也是最容易被误解的一点：多数人以为 AI 操作电脑是这么干的——截个屏，猜按钮在哪儿，再把鼠标移过去点一下。这么干必然抢你的鼠标，因为屏幕上只有一个指针。

它不是这么干的。它不猜坐标，直接读界面本身的结构。AI 拿到的是一份能精确寻址的元素清单，而不是一张图。

所以：它在后台把活干了，你的鼠标一直握在你自己手里。

不过——这句话有个前提，我实测之后才敢加这个限定：它成立的前提是你用 macOS。

02在 Windows 上实测之后，我得泼盆冷水

官方写的是 macOS、Linux、Windows 三端都支持，Linux 上还专门放了演示视频。听起来差不多。

但我在 Windows 上实跑下来，体感完全不是一回事：Windows 底层走的是 UI Automation，它会真的移动你的鼠标、把目标窗口拉到前台。也就是说，它干活的时候，你的鼠标被抢走了，你正在看的界面也被顶掉了。

这台机器干活的时候，你就别想干别的了。

所以我的建议很直接：这东西真正好用的地方在 macOS，Windows 上不建议折腾。除非它跑在你根本不碰的机器或者虚拟机里——那台机器的鼠标被抢，跟你没关系，代价就不成立了。

本文的其余实测全部在 macOS 上完成。

03实测：我把它塞进了小程序模拟器

我平时用微信开发者工具写小程序，有个环节很烦：想确认模拟器里页面渲染得对不对，得自己切窗口、截图、一项项对。

实测环境：微信开发者工具 Stable 2.02.2608060，模拟器机型 HUAWEI Mate 70 Pro，基础库 3.7.12。

先看它能看见什么。一句 get_app_state，整个页面回来了，479 行无障碍树：

我不用切窗口，不用截图，也不用复制粘贴。直接问它一句就行：

看一眼模拟器现在停在哪个页面，有几条告警，Console 有没有报错。

04然后我去试点，差点得出一个错误结论

我让它点页面上的"查看全部"和底部 tab，试了三种方式：

三种全没反应。页面纹丝不动，左下角始终是 pages/overview/index。

我当时差点写下"它点不动小程序页面"，而且真的差点就这么发出去了。

漏了第四种：sky_click。

这是项目里藏得最深的一个能力。click 一共有五种实现，auto 是默认的，另外还有 accessibility、app_post、sky_click、global。前几种对小程序模拟器全部无效——因为小程序页面跑在 Chromium 内核的 webview 里，bindtap 不响应无障碍的合成事件，后台投进去的事件它也不理。

sky_click 走的是 macOS 的 SkyLight 后台窗口通道，自带一次 Chromium primer click，专门治"Chromium 忽略后台事件"这个毛病。官方文档里那句话算是把钥匙递到手里了：

Use sky_click when Chromium ignores app_post.

换成 sky_click，加上坐标，点下去。页面从 pages/overview/index 跳到了 pages/concentrators/index，tab 高亮跟着变。我又点回"总览"，也回去了。往返两次，都成。

而且它没抢我的鼠标。官方写得很清楚：sky_click 不移动系统指针、不把目标窗口调到前台、不改变你当前应用的焦点状态。你该干什么干什么，它在后台把那次点击送到。

闭环这就通了：get_app_state 负责看，sky_click 负责点。你可以直接丢一句"帮我点进设备页，看看列表有几台集中器、状态对不对"，它自己点、自己看、自己给结论。

补一句，省得你走错路。如果你要的是几百条用例、跑在 CI 里的重型 E2E 回归，微信官方的 miniprogram-automator 才是正解——它走协议直接驱动页面，天生适合批量。open-computer-use 的价值是不用写脚本，随手验证、临时走查，让 AI 看着界面告诉你结论。

一个管批量，一个管随手。

05ERP 客户端：从最看好到打折

（这一节在 Windows 实测之后被我改写了。原来写的是"我最看好的场景"，现在得诚实地往下调。）

同一套玩法搬到 ERP 上，本来价值比小程序大得多。ERP 大概算 To B 交付里最难对接的那一类东西——它常常不是"没有接口"，是"接口不归你开"。

拿 SAP 说，它官方就有 GUI Scripting，但前提是一串你决定不了的事：服务端要把 sapgui/user_scripting 参数打开，要给你分配 S_SCR 授权，客户端得在选项里启用 scripting，还得关掉那两个会弹窗的提醒——不然 RPA 一接上来操作就被打断。

这些开关大多在别人管的服务器上。技术问题，最后变成一张走不动的审批单。

走无障碍层的好处本来在这儿：它不指望对方给你开 scripting 接口。但 Windows 那次实测把这条路堵了大半——ERP 客户端绝大多数跑在 Windows，而 Windows 上的实现会抢鼠标。在这个场景里，它退化成了一个需要人盯着的 RPA，那个"不抢鼠标"的优势没有了。

所以结论我往下调：如果你的客户环境是 Mac，这套玩法值得一试；如果是 Windows，现阶段我不建议拿它去做 ERP 交付，除非目标是部署在一台没人用的机器上。

另外那句提醒还是放在这儿：ERP 里装的是业务和财务数据。只读、查询这类放手让它干；涉及写入的，让它先把要做的事说给你听，你点头再执行。

06装上它，你可以一句话都不动手

这个项目最省事的地方是：真不用你自己装。装的过程不需要你敲任何命令。

打开 WorkBuddy 或 opencode，别管什么配置格式，直接说人话。我一般这么讲：

帮我安装 open-computer-use，这是一个 Computer Use 的 MCP 工具，项目在 github.com/iFurySt/open-codex-computer-use。装完后把它自带的 Skill 也装上，然后跑一遍验证，告诉我能不能列出我当前运行的应用。

接下来它会自己去读项目的安装说明，装本体，找到对应的配置文件写进去，再跑一遍 list_apps 证明能用。中间只有几步需要你点"允许"。

我这边最后的结果是配置落在 ~/.workbuddy/mcp.json，跑一句 open-computer-use call list_apps，当前运行的应用列表就回来了。

一句建议：装完再加一句"把配置文件里新增的那段贴给我看看"。它有时候图省事写裸命令，某些环境里会起不来——MCP 服务是宿主进程拉起来的，不一定继承你登录 shell 的 PATH。让它写绝对路径更稳，看一眼就知道有没有踩坑。

macOS 用户最后还有一步：可能需要授权"辅助功能"和"屏幕录制"（系统要求 14.0 以上），Windows 和 Linux 不用走。这两个权限是系统级的，建议先拿不重要的应用试手；不确定有没有给到位，可以让它跑一遍环境自检，会把授权状态直接列出来。

WorkBuddy 用户注意：改完配置不会自动生效，要去连接器管理页点一下"信任"。

07MCP 给工具，Skill 教用法

这两件事容易混，其实各管一摊：MCP 给 Agent 工具，Skill 教 Agent 怎么用这些工具。两个都装才完整。

配置文件和 Skill 装到哪儿了，你也用不着自己去找——问它一句"你把 Skill 装在哪个目录了"就行。里面有份完整的操作规范，旁边还带一本排查手册。

官方有句提醒值得抄下来：Skill 是以 Agent 的完整权限运行的，装之前最好先看一眼内容。

接上之后，Agent 手上会多出 9 个工具：list_apps、get_app_state、click、type_text、press_key、set_value、scroll、drag、perform_secondary_action。

日常基本只用前三个：列应用、读界面、点。

写在最后

以前这些窗口只能靠人去点，现在 Agent 能自己伸进去。那些"这活儿没法自动化，只能让人盯一遍"的流程，可以重新拿出来算一笔账了——这笔账在 macOS 上算得过来，在 Windows 上暂时还不行。

"不抢鼠标"这四个字听着不起眼，但它决定这东西能不能进你的日常工作。一个动不动就要独占你电脑的 AI，你一天也用不了几次——你得盯着它，中间什么都干不了。能在后台干活、你该干嘛干嘛的，才留得下来。

这也是为什么我对那三次失败那么较真。最后那一下点成功了，而且全程没碰我的鼠标。

项目地址：github.com/iFurySt/open-codex-computer-use npm 包名：open-computer-use（短命令 ocu）

也说说你那边：你手上有没有哪个软件，是死活没有 API、AI 根本帮不上忙的？这种"顽固"软件才是它真正的主战场。你说得出来，我就去实测给你看。