上次分享了一个CUA的开源项目，让AI Agent可以直接操控电脑界面，相当于把任何App都变成Agent的Skill。效果还不错。
开源Turix，你可以把任何App当Agent Skill用！比如微信...
不过评论区有两个比较多的反馈：太耗token了，以及截图上传后会不会有安全问题。坦白说，这两个问题在实践中确实存在。GUI操作本身就是一个极其“烧token”的场景——模型要持续截屏、理解界面、定位元素、执行操作，每一步都在消耗资源。尤其在自动编程的完整流程里，有数据显示，GUI测试消耗的token甚至能占到整体的一半以上，是最大的单项开销。
而且每一帧截图都要上传到云端模型去处理，企业级场景下，隐私问题也让人担忧。
前两天偶然挖到一个开源模型——Mano-P。它原生就是为GUI操作设计的，而且是端侧模型：可以在你自己的Mac上本地运行，截图和任务数据不出设备。
Mano-P有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、游戏、或者非浏览器的桌面应用，直接失效。
纯视觉与DOM操作的区别：画面在的地方，代码不一定在；代码在的地方，画面不一定有。
再说 Cider：另一个开源框架
前面提到Mano-P解决了token和隐私问题，但本地跑模型，速度和效率是绕不开的坎。
Cider是一个基于Apple MLX生态的推理加速框架，核心解决的是：让模型在Mac上跑得更快、更省内存。它真正调用了Apple GPU的INT8计算能力。
Apple的M系列芯片原生支持INT8计算，但MLX（Apple自己的AI框架）一直没把这个能力完全用上，只做了权重量化，没做激活量化。Cider补齐了这块，是首个在Apple GPU上实现硬件加速INT8 TensorOps的框架。实测下来，W8A8模式比MLX原生的W4A16快4.4到7倍。
而且Cider不仅服务于某一个模型，Qwen、Llama、Mistral等主流开源模型都能接入使用。
安装其实越来越简单了
实际操作上，安装过程已经相当简化，甚至可以用Codex这类工具自动完成。官方推荐的硬件是Apple M4芯片 + 32GB内存的Mac mini或MacBook。
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，私密性也更好。
整个过程除了慢一点，稳是真的稳。慢的原因主要是三点：Codex本身的思考耗时；本地配置一般，没达到官方推荐的M5芯片+32GB内存；Codex和Mano-P之间的信息同步还不够丝滑，这部分也占了一定耗时。
3、玩游戏
再来个有趣的尝试——让大模型玩扫雷。小时候没玩明白过，只知道乱点。之前试过用Playwright去操作4399上的扫雷，完全做不到。因为4399的游戏界面是Canvas渲染的，Playwright操作的是DOM树，在Canvas面前直接失效，根本看不到游戏里的格子和数字。
但Mano-P是纯视觉路线，理论上可以操作。于是让它打开4399→搜索扫雷→进入游戏→开始玩。
结果挺有意思：它一步一步打开了4399，搜索到扫雷，顺利进入了游戏界面，确实能点击到扫雷的方块。但坦白说，它并不太理解扫雷的游戏逻辑，玩得比较随机，没有根据数字去推理哪些格子安全。
不过，Playwright做不到的事，4B小模型通过纯视觉还是能做。
最后
Mano-P 4B虽然游戏玩得菜，但页面操作这块，还是挺靠谱的：页面元素定位、按钮点击、表单填写、跨步骤任务执行，这些都能做得不错。
更合适的定位是：自动化执行给定的GUI任务，而不是全程独立思考怎么做。搭配一个聪明的大模型（比如接入Codex配合GPT-5.5）一起用，效果最好。
回到开头的那两个痛点：token成本和数据安全。Mano-P + Cider的组合，确实在一定程度上解决了这两个问题。本地GUI操作不花或少花token，数据不出设备——这不是安全协议上写着“我们承诺不看你的截图数据”，而是物理上数据就没出过你的电脑。
端侧AI的方向也越来越清晰：端侧模型不需要具备通用性，而是在某一个具体场景深耕、打穿。更私密、更省钱、更可控——在GUI操作这件事上，它不一定比大模型差。
如果你有M4 Mac，推荐自己跑跑看。
