绝大多数 GUI Agent 方案都绕不开一个前提：它需要持续截取你的屏幕。
这不是设计缺陷，而是技术本质。
传统自动化工具（Selenium、PyAutoGUI 等）靠 DOM 结构或 accessibility API 来「读懂」界面，但这套机制在网页之外基本失效——遇到原生桌面软件、复杂的 ERP 系统、游戏界面，它们就抓瞎了。新一代 GUI Agent 的解法是纯视觉推理：截图作为输入，视觉语言模型来理解「当前界面是什么」「下一步该点哪里」「任务有没有完成」。这是让 Agent 真正能处理任意界面的核心机制。
但截图意味着信息流动的起点。截图被发到哪里处理，决定了你的数据安全边界在哪里。
对个人用户来说，这个问题或许还好接受。但对于处理内部系统、财务数据、医疗记录或涉密业务界面的企业开发者，这是一个必须认真回答的工程问题。
Mano-P 是什么？
Mano-P 是明略科技开源的视觉语言 GUI Agent，核心定位是纯视觉驱动的跨平台 GUI 自动化，不依赖 API 接口或 accessibility 框架，完全基于屏幕截图进行推理和操作。
它目前在两个主流 GUI 自动化评测上有亮眼的表现：
- OSWorld（专项模型）：58.2% 成功率，开源模型排名第一，领先第二名 opencua-72b 超过 13 个百分点
- WebRetriever Protocol I：41.7 NavEval，超过 Gemini 2.5 Pro Computer Use（40.9）和 Claude 4.5 Computer Use（31.3）
Mano-P 目前支持三种接入方式：
- mano-cua：命令行工具，
brew install mano-cua，最快的上手路径 - mano-skill：ClawHub Skill 形态，可直接挂入 OpenClaw / Claude Code 等 Agent 框架
- mano-client：Python SDK（计划中，尚未发布）
这篇文章重点不在于评测成绩，而在于一个更具体的工程问题：当 Mano-P 在截图、推理、执行操作的过程中，你的数据到底在哪里？
两种运行模式，两种数据流
Mano-P 目前提供两种运行形态，数据流向完全不同，需要分开理解。
云端模式
在云端模式下，本地客户端（mano-cua）将每一轮的屏幕截图和任务描述文本发送至 mano.mininglamp.com，由服务端的视觉语言模型完成推理，再将操作指令（坐标、点击类型、输入内容等）返回给本地执行。
这里有一个值得注意的边界设计：云端模式不访问本地文件系统、剪贴板和凭证管理器。 传输到服务端的，只有截图和任务描述，不存在主动扫描磁盘或读取密码的机制。
对于个人用户的日常自动化需求，这个数据模型已经足够清晰。但对企业场景而言，"截图上云"这件事本身可能就是问题所在——很多公司的内部系统截图属于受控数据，一旦涉及合规审查，截图是否离开内网往往是一条硬线。
本地模式（4B 量化模型）
本地模式是另一条路，也是对数据安全要求更高的场景的解法。
Mano-P 的 4B 量化（w4a16）版本可以直接在搭载 M4 芯片、32GB 内存的 Mac 上本地运行（Mac mini 或 MacBook 均可）。截图在本地被处理，推理在本地完成，数据全程不出设备，不依赖任何外部网络请求。
官方公布的本地推理性能数据如下：
| 指标 | 数值 |
|---|---|
| Prefill速度 | 476 tokens/s |
| Decode速度 | 76 tokens/s |
| 峰值内存占用 | 4.3 GB |
对于一个 4B 量化模型来说，476 tok/s 的预填充速度在端侧是相当可用的。从截图输入到操作指令输出的完整推理链路在本机闭环完成，无需网络连接。
两种模式的安全边界对比
| 维度 | 云端模式 | 本地模式（4B） |
|---|---|---|
| 截图去向 | 发送至 mano.mininglamp.com | 本机处理，不出设备 |
| 本地文件访问 | 不访问 | 不访问 |
| 剪贴板访问 | 不访问 | 不访问 |
| 凭证/密码访问 | 不访问 | 不访问 |
| 网络依赖 | 需要联网 | 不需要 |
| 适用场景 | 个人使用、外部网络任务 | 企业内网、高安全场景 |
核心差别只有一个：截图有没有离开本地机器。
对于企业开发者，选择本地模式意味着可以在不违反数据合规要求的前提下使用 GUI Agent 能力。这不是因为云端模式不可信，而是因为数据出境这件事本身在很多场景下就是合规红线，和服务商的信誉无关。
如果需要更强能力：72B 模型的本地部署
4B 量化模型在一般 GUI 自动化任务上足够用，但如果场景需要更强的视觉理解能力（比如复杂多步骤任务、非标准界面），Mano-P 也支持 72B 大参数模型的本地部署。
方案是通过 USB 4.0+ 算力棒连接到 Mac，将算力棒作为推理单元运行 72B 模型。数据安全边界与 4B 本地模式相同：截图和任务数据留在本地网络范围内，不上传至外部服务器。
这个方案更适合对推理能力有强要求、同时又有严格安全合规约束的企业场景——在不破坏数据边界的前提下，把 AI 能力拉到最高点。
对开发者的选型建议
个人开发者 / 低敏感任务：
brew install mano-cua，云端模式开箱即用，无需任何额外配置。截图只上传至 mano.mininglamp.com，不读本地文件。
企业内网 / 涉密界面自动化： 选本地模式。确认设备满足 M4 + 32GB，安装 4B 量化模型，推理完全在本地闭环。如果 4B 的推理能力不够，考虑算力棒方案运行 72B 模型。
想集成进现有工作流（OpenClaw / Claude Code）： 通过 mano-skill 集成，GUI 自动化能力作为 Skill 挂入 Agent 框架。底层的数据流向取决于你选择的运行模式，和上面两种情况一一对应。
写在最后
AI Agent 的数据安全问题，本质上是「数据在哪里处理」的问题，而不是「服务商值不值得信任」的问题。对于负责任的开发者，弄清楚这张截图的完整生命周期——从哪里生成、发到哪里、谁在处理、有没有持久化——是评估任何 AI 工具的基础功课。
Mano-P 在这件事上的设计是明确的：云端模式截图上云但不读本地文件，本地模式全程数据不出设备。开发者按照自己的场景选对应的模式，安全边界清晰可查。
项目持续迭代中，Phase 2 将开放本地模型 + SDK（面向高安全要求开发者），Phase 3 将开源训练方法论和模型压缩技术（面向研究者）。
Github：github.com/Mininglamp-…
