网页操作自动化领域一直有个技术路线的分歧，究竟应该依赖 DOM 解析来定位页面元素，还是让模型直接从视觉输入理解界面？前者精确但脆弱，后者泛化性好但定位精度一直上不去。我们在 Mano-P 项目里走的是纯视觉路线，在 WebRetriever Protocol I 基准测试中拿到 41.7 NavEval，超过了 Gemini 2.5 Pro Computer Use 的 40.9 和 Claude 4.5 Computer Use 的 31.3。这篇文章拆解一下这个成绩背后的技术设计。
https://github.com/Mininglamp-AI/Mano-P
纯视觉驱动的网页元素定位，为什么难
传统的网页自动化方案（Selenium、Playwright 这一类）通过 DOM 树直接获取元素的坐标、属性和层级关系，定位精度很高。但这条路的问题在于，它跟网页的具体实现强耦合，换一个网站，DOM 结构、class 命名、嵌套层级可能完全不同，之前写的定位逻辑大概率要重写。
纯视觉驱动的思路是让模型只看屏幕截图，从像素信息里理解哪些区域是可交互的、当前应该操作哪个元素。这条路的泛化性天然好很多，一个表单在不同网站上长得差不多，视觉模型见过足够多的表单之后就能在新网站上正确操作。困难在于精度，屏幕截图里两个相邻按钮可能只差十几个像素，模型需要在这个粒度上做出准确判断。
GSPruning 视觉 Token 剪枝
Mano-P 在这个问题上的一个关键技术是 GSPruning（视觉 Token 剪枝方法）。VLM 处理屏幕截图的时候，图像会被切分成大量的视觉 token，但网页截图里的信息密度分布极不均匀，大面积的白色背景、装饰性图片、重复的导航栏占据了大部分像素，真正需要交互的按钮、输入框、下拉菜单只占很小的面积。
GSPruning 的做法是两步走的。第一步通过锚点机制保留全局空间结构，确保模型不会因为剪枝而丢失对页面整体布局的感知，页面顶部的导航栏在哪里、主体内容区从哪里开始、侧边栏的位置，这些空间关系必须保留。第二步用语义异常值识别找到关键 UI 元素对应的 token，这些 token 在特征空间里跟周围的背景 token 有明显差异，算法通过这种差异把它们挑出来优先保留。
两步组合的结果是模型在处理网页截图时能获得 2-3 倍的吞吐提升，同时精度损失极小。这对实际部署很重要，因为网页操作任务通常涉及多步交互，每一步都需要重新处理一张截图，推理速度直接决定了整体任务的完成时间。
三阶段渐进训练与 Mano-Action 框架
WebRetriever 41.7 的成绩背后是 Mano-Action 双向自强化学习框架。这个框架的核心设计是 Text↔Action 循环一致性学习，模型不仅要从文本指令生成操作序列，还要能从操作序列反推出对应的文本描述，两个方向互相约束，防止模型在某个方向上偷懒。
训练流程分三个阶段。第一阶段是 SFT（监督微调），用标注好的网页操作数据让模型学会基本的界面理解和操作生成能力。第二阶段是离线强化学习，把之前 SFT 模型跑出来的轨迹（包括成功的和失败的）拿来做奖励建模，让模型学会区分好的操作策略和差的操作策略。第三阶段是在线强化学习，模型在真实网页环境里实时操作，每一步操作的结果都会即时反馈给奖励模型，形成闭环训练。
三个阶段的递进关系比较严格。我们在早期实验里发现，如果 SFT 阶段的数据质量不够高，后面两个强化学习阶段的收益会大幅缩水------模型没有建立起基本的界面理解能力，强化学习信号就没法有效引导策略优化。
think-act-verify 循环推理机制
模型在执行网页操作时用的是 think-act-verify 循环。具体来说，模型收到一张截图和任务描述之后，先做 think------分析当前页面状态，判断下一步应该做什么操作；然后 act------生成具体的操作指令（点击坐标、输入文本等）；最后 verify------操作执行后再截一张图，对比操作前后的页面状态变化，确认操作是否达到了预期效果。
verify 环节对多步操作任务特别关键。网页表单经常有联动逻辑，比如选完省份之后城市下拉框会异步刷新，如果模型不检查上一步的结果就直接做下一步，很容易在城市下拉框还没更新完的时候就去点击，导致后续所有操作偏离预期。think-act-verify 循环保证了每一步操作的结果都经过验证，虽然增加了推理步数，但大幅减少了因状态追踪失败导致的级联错误。
https://github.com/Mininglamp-AI/Mano-P
4B 本地模型的推理性能
Mano-P 面向实际用户发布的是 4B 参数量的本地模型（Mano-CUA-4B-Thinking-1.1），可以在 Apple M 系列芯片上运行。根据 README 的 Performance Evaluation 数据，在 Apple M5 Pro 64GB RAM 上，W8A16 配置下 prefill 耗时 2.839s，decode 速度 80.1 tok/s；切换到 W8A8 量化后 prefill 缩短到 2.519s，decode 保持在 79.5 tok/s。测试 Context 长度是 4516 tokens。
Cider SDK（我们单独开源的推理加速工具，GitHub 上 323 Star）提供了 MLX 原生缺失的 W8A8 和 W4A8 激活量化支持。在 M5 Pro 上，Cider 的 W8A8 方案比 MLX 原生 W4A16 快 1.4x 到 2.2x prefill 速度。这个 SDK 不限于 Mano-P 使用，任何 MLX 模型都可以接入。
在真机 macOS GUI 测试（100 个任务，MacBook Pro M5 16GB）中，各配置的通过率如下。Mano-CUA Cloud 版本 83.0%，平均 10.3 步，每步 9.3s；Mano-CUA-Thinking-4B 本地版本 56.0%，平均 11.5 步，每步 7.9s；作为对比，Qwen3-VL-Plus 云端大模型是 39.0%，平均 11.2 步，每步 10.2s。4B 本地模型在通过率上比云端通用 VL 模型高出 17 个百分点，而且每步推理还更快。
需要说明的是，OSWorld 排行榜上 Mano-CUA 1.1 的 58.2% 成绩使用的是 72B 评测用模型，这个模型没有开源，仅用于 benchmark 评测。实际用户可用的是 4B 本地模型。
混合精度量化的工程细节
把 4B 模型塞进消费级硬件还需要解决量化精度损失的问题。Mano-P 用的是混合精度量化策略，配合 GSPruning 的视觉 token 剪枝，在保持操作精度的同时压缩模型的内存占用和计算量。
Cider SDK 里有一篇详细的教程（how_to_write_efficient_int_gemm_m5），讲了在 M5 芯片上怎么写高效的整数矩阵乘法，如果想深入了解 Apple Silicon 上的量化推理优化，可以去 Cider 仓库（ https://github.com/Mininglamp-AI/Cider ）看看。
整体部署要求是 Apple M4 芯片 + 32GB RAM，Mac mini 或 MacBook 都行，也支持通过 USB 4.0 算力棒外接部署。本地模式下截图和任务描述完全不离开设备，完整客户端代码在 Apache 2.0 协议下开源，可自行审计。
https://github.com/Mininglamp-AI/Mano-P
安装 CLI 工具用 `brew tap Mininglamp-AI/tap && brew install mano-cua`，首次本地运行前跑 `mano-cua check && mano-cua install-sdk && mano-cua install-model` 完成模型下载。技术问题可以在 GitHub Issues 提。