但评论区有两个比较多的反馈：
太耗 token 了。
截图上云，安全吗？
说实话，这两个问题，我自己用下来也发现了，GUI 操作确实耗 token：
模型要持续截屏、理解界面、定位元素、执行操作，每一步都在烧token。
特别是在全自动编程流程里，有数据表明，GUI 测试消耗的 token 甚至占到整体的一半以上，是最大的单项开销。
而且每一帧截图都要上传到云端模型去处理，企业级场景下确实有隐私顾虑。
前两天我偶然挖到了一个开源模型，叫 Mano-P
https://github.com/MININGLAMP-AI/MANO-P
它天生就是为 GUI 操作设计的，而且是端侧模型：可以在你自己的 Mac 上本地运行，截图和任务数据不出设备。
有72B版本，最小也有 4B 参数版本，本地一台 Mac 就能跑。
不花 token，不上云，私密性拉满，听起来挺完美的。
但其实还有一个很现实的问题：本地跑模型，虽然不耗 token 了，但效率怎么样？速度怎么样？会不会跑起来就把电脑卡住了？
这也是本地跑模型一直以来最头疼的问题之一。
不过，我最近挖到的另一个开源框架 Cider，恰好解决了这事（下面会简单介绍）。
ok万事俱备，就差效果了。
所以我想亲手试试：4B端侧小模型 + 本地推理加速，跑 GUI 操作，到底行不行？
是一个开源的端侧 GUI-VLA（视觉-语言-动作）Agent 模型。
简单来说，它能够像人一样看屏幕，并操作电脑。
开源不久（应该才半个月不到）在GitHub 有1.3k Star了。
目前开源了两个尺寸：Mano-P 1.0-72B 和 Mano-P 1.0-4B。
72B 大模型在 OSWorld Benchmark 的专项排行里排第一，成功率 58.2%，超过第二名 13 个百分点，但 72B 需要通过高配设备来跑。
4B 是专门为端侧设计的轻量版，可以直接跑在 Mac mini / MacBook 上，量化后峰值内存才 4.3GB。
我的电脑配置有限，所以这次部署的是 4B。但在 CUA 任务上的准确率也已经跟云端大模型相当了，训练数据的底子很扎实：20,000+ 条浏览器操作轨迹、40,000+ 条桌面操作轨迹，覆盖 300 万+ 动作。
它的核心能力是纯视觉驱动，不依赖 CDP 协议，不解析 HTML，直接"看"屏幕截图来理解界面、定位元素、执行点击和输入。
这意味着它不局限于浏览器，桌面软件、3D 应用、专业工具、甚至游戏界面，理论上都能操作。
这一点非常关键。之前用 Playwright 这类工具做浏览器自动化，本质上是在操作 DOM 树。碰到 Canvas 渲染的页面、Flash 游戏、或者非浏览器的桌面应用，直接GG。
前面说了，Mano-P 解决了 token 和隐私问题。但本地跑模型，速度和效率是绕不开的坎。
Cider 是一个基于 Apple MLX 生态的推理加速框架，解决的就是这个问题：
让模型在 Mac 上跑得更快、更省内存。
因为它真正调用了 Apple GPU 的 INT8 计算能力。
Apple 的 M 系列芯片其实原生支持 INT8 计算，但 MLX（Apple 自己的 AI 框架）一直没把这个能力完全用上，只做了权重量化，没做激活量化。
Cider 补齐了这块，它是第一个在 Apple GPU 上实现硬件加速 INT8 TensorOps 的框架。
实测下来，W8A8 模式比 MLX 原生的 W4A16 快 1.4 到 1.9 倍。
而且 Cider 不只是给某一个模型用的，Qwen、Llama、Mistral 这些主流开源模型都能接入使用。
我用 Codex 帮我自动装的，全程几乎没动手 😂
Mano-P和Cider都是让Codex帮忙安装的
官方推荐的硬件：Apple M4 芯片 + 32GB 内存的 Mac mini 或 MacBook
对了它还有一个skill，也让codex帮忙安装一下
https://clawhub.ai/hanningwang/mano-cua
4B 模型跑起来还是轻松的，完全不卡。
好，环境搭好了。也通过skill把Mano-P接入Codex了（也可以接入别的Agent，比如Claude Code等...）。
接下来看看 Mano-P 的效果到底如何。
1、自动浏览小红书并互动
先来试一个稍微复杂的经典任务。
小红书的 UI 是挺复杂的：信息流、弹窗、多种交互方式混在一起。
我让 Mano-P 去搜 AI 话题->浏览前三个帖子->点赞->并评论。
这个任务我只是抱着试一试的态度，结果 Mano-P 竟然圆满完成了，有点意外。
让我惊喜的是一个细节是，第一个帖子打开的时候是已经点赞的状态，它一进来就习惯性地点了点赞按钮，实际上是把点赞取消了。但它很快意识到不对，立马又把点赞重新点了回来。
这说明它不是在机械执行，而是能根据界面的视觉反馈来判断操作是否正确，并自动纠偏。这个能力对于 GUI Agent 来说非常关键。
这种自动互动的能力其实还有个很实际的用途：比如你想做 X（Twitter）的冷启动，去各个大 V 下面点赞、评论、转发来增加曝光，这种重复性高的任务，拿GUI Agent来跑就很合适。
2、用 tiktok-gen 做 E2E 测试
然后我尝试了一个开发者场景。
我自己有一个开源项目 tiktok-gen（营销短视频生成平台）
https://github.com/kangarooking/tiktok-gen
之前做 GUI 测试都是自己手动点，登录、上传、生成、验证，一套流程走下来挺费劲的。
这次我想试试让 Codex + Mano-P 配合来跑。
Codex 负责调度和监督，Mano-P 负责 GUI 操作打开项目前端->测试注册、登录->资产中心上传图片和音频素材->文案素材生成->最后产出一份测试报告。
整个过程里，Codex 像个监工，Mano-P 是主要干活的。
4B 小模型的 GUI 操作能力确实不错，但偶尔会跑偏或者卡住，这时候 Codex 作为监督者就能及时纠偏，把任务拉回正轨。
我甚至觉得这个组合比单独用 Codex 的 CUA 效果更好。我之前试过 Codex 自己做 GUI 操作，速度倒是快一些，但也会跑偏。而且没有另一个 AI 帮它纠偏，出了问题只能自己死磕。
之前就遇到过，让Codex自己去qq音乐搜周杰伦的歌，结果它在哪里输入周杰伦的拼音，死活找不到。。
还有一个更大的优点：整个过程不需要用到 Codex 的视觉能力。
视觉理解这块完全由 Mano-P 在本地完成，Codex 只负责安排任务和纠偏。这意味着截图不会上传到云端，能省不少 token，私密性也更好。
整个过程除了慢一点，稳是真的稳。
慢的原因我总结了一下，主要是三个：一是 Codex 本身的思考耗时；二是我本地配置一般，没达到 Mano-P 官方推荐的 M5 芯片 + 32GB 内存；三是 Codex 和 Mano-P 之间的信息同步还不够丝滑，这块也占了一部分耗时。
也希望开源作者能继续优化这一点。
以下是Codex的原话，Codex是没有参与GUI的查看和执行的
3、玩游戏 🎮
再来个有趣的。我也一直想试试，让大模型玩扫雷，反正我小时候是没玩明白过，只知道乱点🤣
我之前试过用 Playwright（最好用的浏览器自动化 MCP 工具之一）去操作 4399 上的扫雷，完全做不到。
原因很简单：4399 的游戏界面是 Canvas 渲染的，Playwright 操作的是 DOM 树，在 Canvas 面前直接失效，它根本"看不到"游戏里的格子和数字。
但 Mano-P 是纯视觉路线，肯定是能操作的
所以我让它打开 4399->搜索扫雷->进入游戏->开始玩。
结果挺有意思的：它一步一步打开了 4399，搜索到扫雷，顺利进入了游戏界面。游戏确实能玩上，能点击到扫雷的方块。
但说实话，它并不太理解扫雷的游戏逻辑，玩得比较随机，没有根据数字去推理哪些格子安全 🤣
不过 Playwright 做不到的事，4B 小模型通过纯视觉还是能做。
我想说，Mano-P 4B虽然游戏玩得菜🤣，但页面操作这块，还是挺专业的🤔
页面元素定位、按钮点击、表单填写、跨步骤任务执行，这些它都能做得不错。
Mano-P 4B更适合的定位是：自动化执行给定的 GUI 任务，而不是全程独立思考怎么做。
搭配一个聪明的大模型（比如接入 Codex 配合 GPT-5.5）一起用，效果最好。
回到开头的那两个痛点：token 成本和数据安全。
Mano-P + Cider 的组合，确实一定程度上解决了这两个问题。本地 GUI 操作不花或少花 token，数据不出设备，这不是安全协议上写的"我们承诺不看你的截图数据"，而是物理上数据就没出过你的电脑。
然后端侧 AI 的方向也越来越清晰了：端侧模型不需要具备通用性，而是在某一个具体场景深耕、打穿。
更私密、更省钱、更可控，以及在 GUI 操作这件事上，它不一定比大模型差。
