引言：一个正在发生的技术迁移

如果你最近关注过AI Agent领域的技术趋势，可能已经注意到一个明显的信号：越来越多的开发者和团队开始认真考虑端侧部署方案。

这不是因为云端方案不好用——相反，GPT-4o、Claude、Gemini这些云端模型在能力上仍然占据优势。但在GUI Agent这个特定场景下，"能力"只是评估维度之一。当你的AI需要持续截取屏幕来理解和操作GUI时，数据主权和响应延迟这两个维度的权重会急剧上升。

本文从技术选型的角度，梳理端侧GUI Agent面临的核心挑战、当前可行的技术路径，以及一个具体的开源实现方案——Mano-P（GUI-Aware Agent Model for Edge Devices，Apache 2.0许可证）的架构决策和背后的思考。

端侧部署的三个核心驱动力

1. 数据不出设备：从"承诺"到"架构保证"

云端GUI Agent的工作模式是：截屏 → 上传 → 云端推理 → 返回指令。这意味着你的屏幕内容（可能包含代码、邮件、聊天记录、敏感文档）持续流向远端服务器。

对于个人开发者，这也许是可接受的风险。但对于企业级场景，这是一个架构层面的硬约束——很多企业的安全策略明确禁止将屏幕数据传输到外部。

端侧部署将数据流完全封闭在设备内部：截图在本地生成、在本地推理、推理结果在本地执行。这不是隐私政策层面的"承诺"，而是物理层面的"不可能泄露"。

2. 延迟与可用性：去掉网络往返

一个典型的云端GUI Agent交互循环：

截屏(~50ms) → 图像编码(~20ms) → 网络上传(~200-500ms) 
→ 云端推理(~1-3s) → 网络下载(~50ms) → 执行操作(~100ms)

网络往返占了总延迟的相当比例，而且波动大——在网络不稳定时，体验会断崖式下降。

端侧推理的延迟模型要简洁得多：

截屏(~50ms) → 本地推理(~500ms-1s) → 执行操作(~100ms)

在Apple M4 Pro上，一个4B量化模型（w4a16）可以达到prefill 476 tokens/s、decode 76 tokens/s的速度，峰值内存仅4.3GB。这意味着一次完整的"看屏幕→给出操作"的循环可以在1秒内完成，而且延迟是确定性的，不受网络状况影响。

3. 离线可用：真正的"Personal AI"

这一点经常被忽视：云端Agent在没有网络时完全不可用。而一个本地运行的Agent，在飞机上、在弱网环境下、在任何断网场景下都能正常工作。

这看起来是一个边缘场景，但如果我们把AI Agent看作操作系统级别的基础设施（这也是行业正在走的方向），那么"离线不可用"就变成了一个根本性缺陷。

技术挑战：端侧小模型能不能撑起GUI Agent？

承认一个现实：端侧设备能跑的模型通常在4B-7B参数级别，和云端几百B的模型在raw capability上确实有差距。端侧GUI Agent的技术挑战集中在三个方面：

挑战1：视觉理解精度

GUI场景要求模型能够精确识别屏幕元素的位置、类型、状态和层级关系。按钮的边界差几个像素，点击就会出错。这对视觉理解的精度要求非常高。

技术路线上目前有两种主流方案：

• Accessibility Tree方案：通过系统无障碍API获取结构化UI信息，精确但依赖平台实现质量
• 纯视觉方案：直接从截图像素推断，不依赖系统API，跨平台能力强，但对模型要求更高

纯视觉方案的优势在于架构简洁——不需要和系统API打交道，数据流路径最短，安全边界最清晰。代价是需要模型在有限参数量下实现足够的视觉理解精度。

挑战2：推理效率

GUI Agent需要多轮交互——每一步操作后都要重新截屏、重新推理。如果单次推理需要5秒以上，整个交互体验就不可接受了。

这里有两个关键的优化方向：

模型量化。 W4A16量化在当前技术条件下已经比较成熟，4B模型量化后峰值内存可控制在5GB以内，在主流消费级硬件上运行无压力。

视觉Token剪枝。 屏幕截图中有大量信息冗余（空白区域、重复背景、无关UI装饰）。通过GS-Pruning（基于梯度敏感度的剪枝策略），可以在推理前裁剪掉不重要的视觉token，显著降低推理的计算量和内存消耗，同时基本不影响对关键UI元素的理解。

挑战3：操作可靠性

小模型单次推理的准确率不如大模型，这是客观事实。关键在于如何通过工程设计来弥补。

一个有效的策略是think-act-verify循环：

1. Think：模型分析当前截图，推理应该执行什么操作
2. Act：执行操作（点击、输入、滚动等）
3. Verify：操作后重新截图，验证执行结果是否符合预期，不符则回退重试

这个设计的巧妙之处在于：本地推理的边际成本几乎为零，所以可以通过多次轻量推理来提高整体成功率。

Mano-P的架构决策

Mano-P（“Mano"在西班牙语中意为"手”，"P"代表Person & Party）在上述技术挑战上做了一组具体的架构决策，这里做一些技术拆解。

选择纯视觉路线

不依赖Accessibility Tree，直接从截图理解GUI。这个选择让整个系统的数据流非常干净——输入就是截图和自然语言指令，输出就是操作序列。没有需要联网获取的外部依赖，数据链路在本地完全闭合。

三阶段训练流程

训练采用了一个渐进式的方案：

1. SFT（监督微调）：用标注的GUI操作数据建立基础能力
2. 离线RL（强化学习）：从已有的操作轨迹数据中学习策略优化
3. 在线RL：在真实GUI环境中交互，进一步迭代模型

这个流程的设计逻辑是：SFT建立基线，离线RL利用存量数据做低成本优化，在线RL做最后的精细调优。三个阶段的数据需求和计算成本逐步递增，但每个阶段都在前一阶段的基础上有明确的增量收益。

Benchmark表现

几个关键数字：

• OSWorld基准：58.2%成功率（同基准下第二名为45.0%）
• WebRetriever Protocol I：NavEval得分41.7（对比Gemini 2.5 Pro的40.9、Claude 4.5的31.3）

这些成绩需要放在上下文里理解：这是一个4B参数量化模型，在消费级硬件上本地运行的结果。在端侧约束条件下达到这个水平，说明"小模型 + 精细训练"这条技术路径是有明确可行性的。

硬件适配

目前支持两种运行环境：

• Apple M4 + 32GB RAM：利用Apple Silicon的统一内存架构和Neural Engine
• 算力棒 USB 4.0：以外置硬件形式为普通PC提供推理能力

这两个选择覆盖了当前消费级硬件的主流形态，也暗示了一个技术趋势：端侧AI的硬件门槛正在快速下降。

开源路线图与开发者参与

Mano-P采用三阶段开源策略：

阶段	内容	状态
Phase 1	Skill层（核心能力模块）	✅ 已开源
Phase 2	本地模型 + SDK	计划中
Phase 3	训练方法 + 量化技术	计划中

许可证是Apache 2.0——这意味着商业使用也没有限制。对于想在端侧AI Agent方向做技术探索的开发者和团队，可以在Phase 1的基础上进行二次开发和集成。

写在最后：AI for Personal不是口号

"AI for Personal"听起来像一句营销语，但从技术架构角度看，它指向一个具体的工程目标：让AI推理完全在用户自己的设备上完成，数据主权完全归用户所有。

这不是一个简单的部署位置变更。它要求在模型压缩、推理优化、训练策略、硬件适配等多个维度上做系统性的技术突破。当前的端侧方案还远谈不上完美——小模型的能力上限、硬件兼容性、复杂任务的成功率都有大量提升空间。

但方向是清晰的。当端侧硬件算力每年翻一番、模型压缩技术持续进步时，云端和端侧的能力差距正在以可见的速度缩小。在数据安全日益重要的今天，提前在端侧架构上做投入，既是技术判断，也是价值取向。

代码：Mininglamp-AI/Mano-P