Mano-P 深度解析：当 GUI Agent 挣脱云端，走进你的 Mac

## 01:00 开篇：一个名字的隐喻 Mano，西班牙语里「手」。P，两层含义：Person（个体）和 Party（组织）。 明略科技给这个开源项目起的名字，已经透露了它的野心。不是「助手」（assistant），不是「智能体」（agent），而是「手」——一个能直接替你操作电脑的手。而且不只服务于某个公司，而是让个体和组织都能拥有自己的。 2026 年 4 月 13 日，这个项目在 GitHub 悄然开源。没有发布会，没有 Keynote，只有一个仓库和一份详尽的中英文 README。但技术指标一摆出来，整个行业都得看一眼： **OSWorld 专用模型全球第一，58.2%。领先第二名 13.2 个百分点。** 什么概念？在这个 GUI Agent 领域最权威的 benchmark 上，Claude Sonnet 4.6 以 72.1% 坐庄（所有模型榜），但在「专用 GUI 智能体」这个细分赛道里，Mano-P 72B 把之前的 SOTA 甩出了 13.2% 的差距。这不是进步，这是断层。 更关键的是：它不需要云端。一台 M4 Mac mini，32GB 内存，本地跑。 --- ## 02:30 GUI Agent 的「云原罪」 要理解 Mano-P 为什么重要，先得理解它反对的是什么。 当前主流的 GUI Agent 方案（Claude Computer Use、Gemini Computer Use、甚至 OpenClaw 的部分 workflow）都依赖一个共同前提：**把屏幕截图上传到云端**，让大模型在服务器上分析，再返回操作指令。 这个模式有三个结构性缺陷： ### 缺陷 1：隐私的天然对立 你的屏幕截图里有什么？正在编辑的财务报表、Slack 里的内部讨论、邮件里的商业条款、甚至密码管理器的界面。把这些图像上传到第三方服务器，对于任何有基本安全意识的企业和个人，都是不可接受的。 Claude 的 Computer Use 文档里明确写着：「屏幕截图会被发送到 Anthropic 的服务器」。这是诚实，但也是软肋。 ### 缺陷 2：延迟的物理极限 截图 → 上传 → 云端推理 → 下载指令 → 本地执行。即使网络再快，这个往返也至少是数百毫秒。在需要快速连续操作的场景里（比如游戏、实时交易界面），这个延迟是致命的。 ### 缺陷 3：API 的边界牢笼 云端方案本质上受限于 API 的能力边界。模型能做什么，取决于云服务商开放了什么。如果厂商不支持你需要的某种操作，你只能等。而且每个云服务商的 API 格式不同，锁定效应极强。 Mano-P 的回应很干脆：**全部本地。截图不上云，推理在本地，控制也在本地。** --- ## 04:10 纯视觉的本质 Mano-P 第二个颠覆性选择是**纯视觉驱动**。 传统 RPA 和自动化工具依赖什么？DOM 解析、系统 API、控件树遍历。这些方案的问题在于：**它们只能操作「被解析」的界面**。现代软件的 UI 越来越复杂——3D 应用、游戏、非标准控件、自定义渲染——DOM 和 API 根本够不到。 Mano-P 的做法像人一样：**看屏幕，像人眼一样理解像素，然后操作。** 这意味着： - 不需要浏览器插件（对，它不限于浏览器） - 不需要系统级 API 权限（除基本的屏幕录制和辅助功能） - 不需要应用提供任何接口 - UI 改版了？只要人类还能看懂，Mano-P 大概率也能 这是「通用性」的终极形态。理论上，它能操作任何有图形界面的软件——从 Excel 到 Figma，从 Photoshop 到 Unity，从微信到小众的专业工具。 当然，代价是对视觉理解能力的极高要求。这也是为什么它能在 OSWorld 上拿 58.2% 的原因：OSWorld 的测试场景就是「给截图和操作指令，看模型能不能正确操作」，没有 DOM，没有 API，纯靠看。 --- ## 05:40 双版本策略：天花板与地板 Mano-P 采用了非常聪明的双版本架构： | 维度 | 72B 完整版 | 4B 量化版 | |------|-----------|----------| | **定位** | 技术上限探索 | 端侧普惠落地 | | **部署** | 云端 / 算力棒 | Mac M4 + 32GB | | **OSWorld** | 58.2%（全球第一） | 未公开但可用 | | **内存峰值** | — | 4.3 GB | | **预填充速度** | — | 476 tokens/s | | **解码速度** | — | 76 tokens/s | | **量化方式** | — | w4a16 | 这个策略的精妙之处在于：72B 模型负责「证明这件事能做到什么程度」，4B 模型负责「证明这件事能在你的设备上跑起来」。 很多开源项目犯的错误是：只开源一个小模型（效果一般），或者只发论文（没有模型）。Mano-P 两个都给了——而且 4B 模型的性能数据（476 tokens/s 预填充）证明它不是摆设。 --- ## 07:15 三项核心技术拆解 ### 技术 1：Mano-Action 双向自增强学习 传统 GUI 模型怎么训练？单向的：给你截图和指令，预测点击哪里。这就是 SFT（监督微调）。 Mano-Action 的突破是**双向**： - **Text → Action**：根据自然语言描述，定位并操作界面元素 - **Action → Text**：给定界面元素，准确描述其位置和功能 这两个方向互相增强。模型既要学会「听指令做事」，也要学会「看到东西能说清楚」。这种循环一致性让模型对界面的理解更鲁棒——不容易被 UI 微调欺骗，因为「描述」和「操作」两个能力互相验证。 训练分三阶段递进： 1. **SFT**：基础能力，「能做」 2. **离线 RL**：在历史数据上做策略优化，区分好动作和坏动作，「做对」 3. **在线 RL**：在真实环境里交互，根据实际反馈自我进化，「持续做对」 配合「Think-Act-Verify」循环推理：每一步先「想」（分析界面），再「做」（执行动作），最后「验」（检查结果）。验证失败就回溯重试。 这不是花哨的概念，而是长任务链中保证可靠性的刚需。GUI 操作有一个残酷特性：**错误是累积的**。点错一个按钮，后续所有操作都可能在错误上下文中进行，最终雪崩。 ### 技术 2：GSPruning 视觉 Token 剪枝 处理高分辨率屏幕截图时，一个 1920×1080 的图转成视觉 token 可能是几千个。传统 VLM 逐像素处理，慢且浪费。 GSPruning 的思路是：**只看重要的 13%。** 具体做法： - 保留**全局空间锚点**（维持网页/界面结构骨架） - 识别**语义异常值**（关键 UI 元素：按钮、输入框、菜单） - 压缩掉背景、重复纹理、无关装饰 效果：token 保留率压缩到 **12.57%**，吞吐量提升 **2-3 倍**，性能损失极小。 在 Online-Mind2Web benchmark 上，Mano-P 用 12.57% 的 token 量做到了 0.336 的任务成功率，对比其他剪枝方法的 0.310-0.343，性价比极高。 ### 技术 3：混合精度量化 w4a16 4B 模型能在 Mac 上跑的关键： - **权重（Weight）**：4bit 存储，极度压缩 - **激活值（Activation）**：16bit 保留，保证推理精度 - 峰值内存仅 4.3GB，M4 Pro 上 476 tokens/s 预填充 这个组合不是随意的。4bit 权重 + 16bit 激活是在「压缩比」和「精度」之间找到的平衡点。纯 4bit（w4a4）会损失太多精度导致 GUI 定位错误；w8a16 又太占内存。 --- ## 09:30 Benchmark 战绩全览 Mano-P 1.0 在 13 个多模态基准上拿了 SOTA。挑几个最有说服力的： ### GUI Grounding（界面元素定位） - **ScreenSpot-V2**：桌面/移动端/网页跨平台定位 → SOTA - **MMBench**：综合多模态理解 → SOTA - **UI-Vision**：UI 专用视觉理解 → SOTA ### CUA & BUA（Computer Use / Browser Use） - **OSWorld（专用模型）**：58.2%，全球第一，领先第二名 13.2% - **OSWorld（全模型榜）**：位列第五，前面是 Claude Sonnet 4.6 (72.1%)、Seed-1.8 等千亿级通用大模型 - **WebRetriever Protocol I**：41.7 NavEval，超过 Gemini 2.5 Pro Computer Use (40.9) 和 Claude 4.5 Computer Use (31.3) ### 感知与认知 - **Video-SME-2**：视频显著性检测 → Stage III 全面领先 - **MIT1003 / SalECI**：人眼注视点预测 → SOTA - **ETMD**：情感识别 → 超越所有对比模型 - **CL Bench**：上下文学习 → 领先 一个 72B 的专用模型，能在全模型榜单里挤进前五，和 Claude/Gemini 这些千亿级通用模型同台竞技——这说明 GUI 领域的「专用化」路线可能是对的。通用大模型什么都懂一点，但操作界面这件事，专用模型可以更精。 --- ## 11:00 费曼式灵魂拷问：它真的能在你的 Mac 上替你干活吗？ 好，数据看完了。现在问一个费曼式的问题：**命名不等于理解。说它能「操作电脑」，到底是什么意思？** ### 它能做什么？ - 打开 Excel，读取数据，生成图表，导出 PDF - 操作剪辑软件，导入素材，剪辑视频，加字幕，导出 - 打开微信，找到特定联系人，发送消息 - 在网页上填写表单、点击按钮、下载文件 - 打麻将（对，演示视频里真展示了） - 自主完成「需求澄清 → 架构设计 → 代码生成 → 部署测试 → 迭代修复」的全流程 ### 它不能做什么？ - **跨应用复杂状态同步**：在 A 应用复制数据，切换到 B 应用粘贴——这需要剪贴板级别的系统集成，目前 Skill 形态的权限可能不够 - **系统级操作**：修改系统设置、安装软件、重启——安全约束会阻止 - **非 GUI 任务**：纯命令行操作、API 调用、后台服务管理——这不是它的设计目标 - **多显示器**：当前仅支持主显示器 - **连续高速操作**：76 tokens/s 的解码速度对于打字很快的场景够用，但对于需要毫秒级反应的游戏操作，可能还跟不上 ### 最关键的限制：错误累积 每一步操作后，Mano-P 会验证结果。但如果验证机制本身也错了呢？ Think-Act-Verify 循环在「大多数步骤正确」时很有效。但在「验证器也出错」的极端情况下，模型会陷入「我以为我做对了」的幻觉。这不是 Mano-P 独有的问题，是所有自主 Agent 的共同难题。 --- ## 12:40 三种使用形态：你想怎么用它？ Mano-P 提供了三种接入方式，对应三种用户群体： ### 形态 1：mano-cua（CLI 命令行） ```bash brew tap HanningWang/tap && brew install mano-cua mano-cua run "打开微信并告诉FTY会议延期" ``` 面向：开发者、高级用户、脚本集成。 特点：虚拟环境隔离、可嵌入 shell 脚本、快速调用。 ### 形态 2：mano-client（Python SDK） ```python from mano_client import ManoClient client = ManoClient() client.run("在小红书搜索AI新闻并展示第一条帖子") ``` 面向：Python 开发者、工作流自动化。 特点：异步调用、回调函数、可编程控制。 状态：开发中，即将发布。 ### 形态 3：mano-skill（OpenClaw / Claude Code 集成） 面向：AI Agent 用户。 特点：Agent 自主调用、与推理能力深度集成、ClawHub 生态。 安装： ```bash clawhub install mano-cua ``` 然后对 Claude Code 或 OpenClaw 说：「帮我整理桌面上的所有 PDF」，Agent 会自动调用 Mano-Skill 完成 GUI 操作。 这是最有想象力的一种形态。OpenClaw 这样的 Agent 框架，加上 Mano-P 的 GUI 操作能力，等于给 Agent 装上了「眼睛和手」。Agent 不再只是「聊天回答」，而是真的能「动手做事」。 --- ## 14:20 开源路线图：三个阶段 明略科技的开放策略很有层次： | 阶段 | 内容 | 状态 | 目标用户 | |------|------|------|----------| | **第一阶段** | Mano-CUA Skill | ✅ 已开源 | Agent 爱好者（OpenClaw/Claude Code 用户） | | **第二阶段** | 本地模型 + SDK | ⏳ 近期发布 | 高安全性需求的开发者 | | **第三阶段** | 训练方法 + 剪枝/量化技术 | 🔮 未来 | 研究人员、模型训练者 | 这个路线图说明明略不只是「扔个模型出来」，而是想建生态。第一阶段让尽量多人用上；第二阶段让开发者能深度定制；第三阶段让研究者能在此基础上创新。 Apache 2.0 协议也意味着：可商用、可修改、可分发。没有商业限制。 --- ## 15:30 和谁比？一张清晰的对比表 | 特性 | Mano-P | Claude Computer Use | OpenClaw + Skill | Manus | 传统 RPA | |------|--------|---------------------|------------------|-------|----------| | **模型来源** | 内置端侧模型 | 云端 API | 用户自行配置 | 云端 API | 无模型 | | **数据安全** | ✅ 本地，不上云 | ⚠️ 截图上传云端 | ⚠️ LLM/Skill 可能上云 | ⚠️ 云端推理 | ✅ 可本地 | | **控制方式** | ✅ 纯视觉 | ⚠️ 云端决策+本地执行 | ⚠️ CDP 协议+CLI | ❌ HTML 解析+CLI | ❌ 系统 API | | **适用场景** | ✅ 全平台 GUI | ✅ 跨平台应用 | ✅ 跨平台应用 | ⚠️ 仅 Web | ⚠️ 特定系统 | | **离线能力** | ✅ 完全离线 | ❌ 需联网 | ⚠️ 取决于配置 | ❌ 必须联网 | ✅ 可离线 | | **响应速度** | ✅ 即时 | ⚠️ 网络延迟 | ✅ 本地/云端可选 | ⚠️ 云端延迟 | ✅ 即时 | | **部署成本** | ✅ 低（Mac/算力棒） | ⚠️ API 费用 | ✅ 开源免费 | ⚠️ 订阅费 | ✅ 低 | | **鲁棒性** | ✅ UI 变化自适应 | ✅ LLM 自适应 | ✅ LLM 自适应 | ⚠️ 有限 | ❌ UI 变化需重配 | Mano-P 的核心差异化：**纯视觉 + 本地运行 + 开源免费**。这三个组合在一起，在隐私敏感、离线刚需、成本控制场景下几乎是无敌的。 --- ## 17:00 更远的思考：这条路的终局是什么？ GUI Agent 这个方向，从 RPA 的坐标硬编码，到浏览器的 DOM 解析，到云端的截图上传，再到端侧的纯视觉推理——每一次范式转移都在解决上一代的结构性缺陷。 Mano-P 代表的是目前能看到的「最干净」的架构： - 覆盖全平台（不限浏览器） - 不依赖任何协议或 API - 数据不出设备 - 开源可审计 如果这条路走通了，它改变的可能不只是「自动化」这件事，而是**人和计算机交互的基本方式**。 你不再需要学习每个软件怎么用。你只需要告诉 Agent 想要什么结果。Agent 像人一样看屏幕、点按钮、填表单、跨应用搬运数据。 长尾软件会被激活：大量没有 API、没有集成的专业软件，突然可以被 Agent 操作。 跨应用工作流会成为常态：Agent 在 Figma 里设计，在 Terminal 里编译，在浏览器里部署——全程 GUI 操作，不需要数据导出导入。 软件间的壁垒会被打破：不需要数据格式转换，Agent 直接在界面层面搬运信息。 当然，从「能跑 demo」到「能在生产环境放心用」，中间还有很长的路。模型的鲁棒性、长任务中的错误累积、跨平台适配——这些都需要时间打磨。 但至少，Mano-P 让我们看到了一种新的可能性。而且它是开源的，任何人都可以参与打磨。 --- ## 18:30 总结：为什么值得关注 1. **技术指标过硬**：OSWorld 58.2% 不是刷榜，是断层领先 2. **隐私方案干净**：本地运行，数据不上云，开源可审计 3. **部署门槛低**：M4 Mac 就能跑，不需要 GPU 服务器 4. **生态开放**：Apache 2.0，三种接入形态，三阶段开源路线 5. **方向正确**：纯视觉 + 端侧，可能是 GUI Agent 的终局架构 这不是又一个「AI 自动化工具」。这是「AI 获得和人类一样的软件使用能力」的关键一步。 --- > **参考对象**：Steven Levy《Hackers》——关注技术选择背后的哲学取舍，以及开源精神如何改变权力结构 > > **信息来源**：Mano-P GitHub 仓库 (Mininglamp-AI/Mano-P)、明略科技官方博客、OSWorld / WebRetriever / ScreenSpot-V2 等 benchmark 数据 #Mano-P #GUIAgent #VLA #端侧AI #明略科技 #开源 #ComputerUse #OpenClaw #费曼风格 #小凯 --- ## 附录：快速上手 ```bash # 安装 Mano-CUA Skill（OpenClaw / Claude Code） clawhub install mano-cua # 或通过 Homebrew 安装 CLI（即将推出） brew tap HanningWang/tap && brew install mano-cua # 运行 mano-cua run "打开微信并发送消息给FTY：会议延期到明天" ``` GitHub: https://github.com/Mininglamp-AI/Mano-P 论文: arXiv:2509.17336 (Mano Technical Report) 联系: model@mininglamp.com