GUI 智能体本地运行的架构取舍

GUI Agent 搬到本机，变化不只是省掉一次云端 API 调用。原文以开源项目 Mano-P 为参照，讨论了延迟、隐私、故障、内存和模型选型五件事：云端替你遮住的成本，到了本地都要自己算。

对想让 AI 操作桌面软件的开发者，这篇最有用的提醒是：先核算每轮截图的处理时间和整机内存，再判断模型能不能胜任。参数更大，未必更适合 GUI 任务。

本地推理为什么仍要等几秒

云端延迟主要来自网络往返和服务排队，开发者能控制的部分有限。本地推理则要拆成两个阶段：预填充（prefill）负责处理输入，解码（decode）负责逐个生成输出。GUI Agent 每轮读取截图、理解指令、生成动作，都要支付这两笔时间。

原文给出一组数据：在 M4 Pro 上，一个采用 w4a16 量化的 4B 模型，预填充速度约为 476 tokens/s，解码速度约为 76 tokens/s。w4a16 指权重使用 4 位、激活使用 16 位表示。

如果一轮截图加指令需要预填充 2,000 tokens，首个动作 token 出现前就要等约四秒。这还没有算完后续生成和动作执行。

判断 GUI Agent 快不快，要看完整操作循环，不能只看生成速度。

原文没有给出对应云端方案的对照测试，因此这组数字能帮助估算本地等待时间，不能证明本地一定比云端快或慢。

截图留在本机，故障也留给自己

作者把隐私变化概括为从政策承诺转向结构保证：调用云端时，截图需要发出去，数据如何保存依赖供应商承诺；完全在设备端运行时，屏幕内容可以留在机器上。

Mano-P 的定位就是在 Apple Silicon 上完全本地运行的开源 GUI Agent，截图不离开设备。作者认为，这让涉及凭据、患者记录和内部工具的工作更容易落地。

不过，「无需耗时数月的安全审查」是作者的判断，原文没有提供案例或审查数据。截图不上传，确实减少了一条外传路径；但应用权限、日志保存和操作授权，仍需要单独检查。

故障归属也变了。云端服务异常时，开发者通常只能看状态页、等待或重试。本地 Agent 则可能在任务中途耗尽内存，也可能因为量化模型跟不住长指令链而偏离目标。

这些问题可以通过进程和内存映射排查，但可排查不等于容易修。资源不足可以定位，长任务中的理解偏差仍需要观察和复现。

模型选型要同时算内存和任务成绩

原文称，同一个 4B 模型的内存峰值约为 4.3GB。在 16GB 笔记本上，作者认为余量已经偏紧；到了 32GB，才有空间考虑按需加载第二个模型。

这里要算的是整机预算。操作系统、浏览器和目标应用也在消耗内存，4.3GB 不是整个自动化工作流的总占用。

作者还提出，把部分屏幕文字识别交给操作系统级 OCR，可以减少模型侧的内存负担。原文所谓「不占模型内存」，不能理解成 OCR 不消耗系统资源。

模型能力则要看任务训练。原文声称，一个针对 GUI 训练的 4B 模型，在 OSWorld 上以 58.2% 排名第一，超过参数量大得多的通用模型。它支持的方向是：GUI 专项训练可能比单纯增加参数更有效。

但原文没有交代该模型名称、榜单日期、评测配置，以及这些数字是否来自作者亲测。将这项成绩用于选型前，仍需要核对具体条件。

我的判断

这篇最有价值的部分，是把「能在本地跑」拆成了可核算的问题：输入要处理多久、模型占多少内存、任务失败后由谁排查。对桌面自动化，这些比一句「支持本地部署」更有帮助。

我赞同优先看任务适配程度，但「专项训练胜过参数规模」在这里仍缺少完整对照。58.2% 的成绩也不足以说明它能可靠完成你手里的长流程。

本地与云端之间同样没有普遍赢家。原文没有提供同任务下的速度、成功率和成本对照；关于整体架构优劣的判断，仍属于经验之谈。本地适合把屏幕数据边界放在前面的场景，代价是自己承担设备资源和运行维护。

能拿来做什么

• 给现有 GUI Agent 分别记录预填充、解码和动作执行时间，先找出每轮等待发生在哪里，再决定优化输入还是更换模型。
• 在日常开发笔记本上试跑时，把浏览器、IDE 和目标应用一起打开，观察完整任务的内存峰值，不要只测模型加载后的占用。
• 对文字密集的桌面流程，尝试用系统 OCR 承担部分识别工作，并检查它是否影响后续动作判断。
• 评估小模型时，选取自己实际要自动化的流程验证，重点观察长指令链是否偏航，不要只凭参数量或单项榜单决定。