大家好，我是袋鼠帝。
上次给大家分享了一个CUA的开源项目，能让AI Agent直接操控电脑界面，相当于把任何App都变成Agent的Skill。反响还不错。
开源Turix，你可以把任何App当Agent Skill用！比如微信...
但评论区有两个比较多的反馈：
太耗token了。
截图上去，安全吗？
说实话，这两个问题，我自己用下来也发现了，GUI操作确实耗token。
模型要持续截屏、理解界面、定位元素、执行操作，每一步都在烧token。
特别是在全自动编程流程里，有数据表明，GUI测试消耗的token甚至占到整体的一半以上，是最大的单项开销。
而且每一帧截图都要上传到云端模型去处理，企业级场景下确实有隐私顾虑。
前两天我偶然挖到一个开源模型叫 Mano-P
它天生就是为GUI操作设计的，而且是端侧模型：可以在你自己的Mac上本地运行，截图和任务数据不出设备。
有72B版本，最小也有4B参数版本，本地一台Mac就能跑。
不花token，不上云，私密性拉满，听起来挺完美的。
但其实还有一个很现实的问题：本地跑模型，虽然不耗token了，但效率怎么样？速度怎么样？会不会跑起来就把电脑卡住了？
这也是本地跑模型一直以来最头疼的问题之一。
不过，我最近挖到的另一个开源框架 Cider，恰好解决了这事（下面会简单介绍）。
万事俱备，就差效果了。
所以我想亲手试试：4B端侧小模型 + 本地推理加速，跑GUI操作，到底行不行？
先说 Mano-P 是什么
是一个开源的端侧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。
纯视觉 DOM操作
画面在的地方，代码不一定在 代码在的地方，画面不一定有
再说 Cider：我挖到的另一个开源框架
前面说了 Mano-P 解决了token和隐私问题。
但本地跑模型，速度和效率是绕不开的坎。
Cider 是一个基于 Apple MLX 生态的推理加速框架，解决的就是这个问题：
让模型在Mac上跑得更快、更省内存。
因为它真正调用了Apple GPU的INT8计算能力。
Apple的M系列芯片其实原生支持INT8计算，但MLX（Apple自己的AI框架）一直没把这个能力完全用上，只做了权重量化，没做激活量化。
Cider推理加速
传统推理FP16 VS 加速推理INT8
速度提升 1.4-1.9倍
Cider补齐了这块，它是首个在Apple GPU上实现硬件加速INT8 TensorOps的框架。
实测下来，W8A8模式比MLX原生的W4A16快4.4到7倍。
而且Cider不只是给某一个模型用的，Qwen、Llama、Mistral这些主流开源模型都能接入使用。
安装其实越来越简单了
安装零门槛了
我用Codex帮我自动装的，全程几乎没动手😂
Mano-P和Cider都是让Codex帮忙安装的
官方推荐的硬件：Apple M4芯片 + 32GB内存的Mac mini或MacBook
对了它还有一个skill，也让codex帮忙安装一下
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（营销短视频生成平台）
之前做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，私密性也更好。
整个过程除了慢一点，稳是真的稳。
第二张图文字完整提取
视觉理解这块完全由 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操作这件事上，它不一定比大模型差。
如果你有 M4 Mac，推荐自己跑跑看。
如果你也尝试了一些有意思的 Case，欢迎评论区聊聊~
能看到这里的都是凤毛麟角的存在！
如果觉得不错，随手点个赞、在看、转发三连吧~
如果想第一时间收到推送，也可以给我个星标⭐
谢谢你耐心看完我的文章~
