引言：从规则匹配到视觉理解的范式跃迁

桌面自动化正在经历一次底层架构级的范式转移。

RPA（Robotic Process Automation）凭借"录制-回放"的低门槛范式统治了企业流程自动化十余年。但当应用界面日趋动态化、跨平台需求激增时，基于 DOM 树和元素选择器的技术路线正在系统性地触碰天花板。GUI Agent（图形界面智能体）作为全新自动化范式应运而生——不依赖预定义元素路径，而是通过视觉理解直接"看懂"屏幕，像人类一样操作任意应用。

明略科技开源的 Mano-P 是这一新范式的代表性项目，提出了 GUI-VLA（Vision-Language-Action）统一架构，在 OSWorld 基准测试中达到 58.2% 的成绩，WebRetriever Protocol I 上以 41.7 NavEval 超越 Gemini 2.5 Pro（40.9）和 Claude 4.5 Sonnet（31.3）。配套的明略科技推出的 Cider SDK 则解决了端侧部署的推理加速问题。

本文从架构层面深入对比两种范式的技术差异，以 Mano-P 的工程实践为核心案例，解析视觉驱动方案的完整技术栈。全文基于 Apache 2.0 开源协议下的公开技术文档。

[外链图片转存中…(img-yczpz5Bv-1779789032386)]

一、RPA 架构深度解析：四层技术栈与结构性技术债

1.1 规则引擎层

RPA 的核心决策引擎本质上是一个有限状态机（FSM）+ 条件分支树。流程设计器产出的"自动化流程"最终编译为 if-else 条件链和顺序执行队列。

技术债务：规则引擎的表达能力上限是确定的——它只能处理设计时已预见的分支。当实际执行遇到设计者未覆盖的界面状态（弹窗、加载中、版本变更），系统直接进入异常状态。行业实践中，一个包含 50 个节点的 RPA 流程通常需要额外 30-40 个异常处理节点，规则膨胀速度远超业务逻辑本身。

1.2 元素选择器层

选择器是 RPA 与 UI 的唯一接口。技术栈包括：

• Web 场景：XPath / CSS Selector / DOM 属性组合
• 桌面场景：Win32 API Hook / UIAutomation / Accessibility Tree
• 移动端：UIAutomator（Android）/ XCTest（iOS）

技术债务：选择器的根本问题是脆弱性与耦合性。一次前端框架升级（如 React 类名 hash 变化）可以导致数百个选择器同时失效。据 Forrester 调研，大型 RPA 部署中 30%-50% 的持续运维成本用于应对 UI 变更导致的选择器修复。更深层的问题是：选择器本质是"结构匹配"而非"语义理解"——它知道 /html/body/div[3]/button[2] 的位置，但不理解这个按钮的含义是"提交订单"。

1.3 流程编排层

流程编排器负责将原子操作（点击、输入、等待）组装为业务流程。主流方案采用可视化拖拽 + 低代码配置。

技术债务：编排层的可维护性随流程复杂度超线性下降。当流程涉及多应用跳转、条件嵌套超过 3 层、循环内含异步等待时，可视化流程图退化为不可读的"意大利面条"。更关键的是——编排层无法抽象和复用。A 应用的"登录流程"和 B 应用的"登录流程"在 RPA 中是两套完全独立的脚本，尽管它们的语义完全相同。

1.4 异常处理链

异常处理是 RPA 架构中被严重低估的复杂度来源。典型实现包括：超时重试、截图比对、备选选择器回退、人工兜底通知。

技术债务：异常处理本身会产生新的异常。重试逻辑可能在动态页面上重复执行已成功的操作；截图比对在分辨率或主题变化时失效；备选选择器增加了维护面。这形成了一个技术债螺旋——为解决脆弱性引入的机制本身也是脆弱的。

二、GUI Agent 架构深度解析：视觉编码 → 语言推理 → 动作预测 → 奖励优化

2.1 视觉编码器（Vision Encoder）

GUI Agent 的第一层是将屏幕像素转化为可供语言模型处理的语义表示。主流方案采用 Vision Transformer（ViT）架构：

• 输入：屏幕截图（典型分辨率 1920×1080 或更高）
• Patch 化：将图像切分为固定大小的 patch（如 14×14 或 16×16 像素），每个 patch 线性投影为一个 token
• 位置编码：注入二维位置信息，保留空间关系
• 输出：视觉 token 序列（一张 1080p 截图可产生 1000+ 视觉 token）

GUI 场景对视觉编码器有独特要求：必须同时具备全局布局感知（理解页面整体结构）和细粒度文本识别（读取小字体 UI 元素）能力。这要求编码器在高分辨率输入上保持足够的 token 密度，但这又与推理效率直接矛盾——这正是后文 GSPruning 要解决的核心问题。

2.2 语言模型（Language Model as Reasoning Core）

语言模型是 GUI Agent 的"大脑"，承担三重职责：

1. 意图理解：将用户的自然语言指令分解为可执行的子目标序列
2. 状态推理：基于当前视觉观察，判断任务进度和下一步应执行的操作
3. 上下文记忆：在多步骤任务中维护操作历史，避免重复或遗漏

GUI Agent 对语言模型的要求与通用聊天场景有本质区别：它需要在结构化输出约束下进行推理——输出必须是合法的动作指令（坐标 + 动作类型），而非自由文本。这对模型的 instruction following 和 grounding 能力提出了极高要求。

2.3 动作空间设计（Action Space）

动作空间定义了 Agent 可执行的原子操作集合。设计权衡的核心是表达力 vs 可学习性：

• 坐标级动作：click(x, y)、type(text)、scroll(direction)、drag(x1,y1,x2,y2)
• 语义级动作：select_element(description)、fill_form(field, value)

坐标级方案（Mano-P 采用的方案）的优势在于通用性——不依赖任何中间层，直接与屏幕像素对应。代价是需要模型具备精确的空间定位能力。语义级方案依赖 Accessibility Tree 等中间表示，本质上又回到了 RPA 的路径依赖。

2.4 奖励模型与强化学习

GUI Agent 的训练需要明确的成功/失败信号。奖励设计的难点在于 GUI 操作的结果延迟性——一个点击动作是否正确，可能要到 3-5 步之后才能判断。

典型奖励信号包括：

• 任务完成奖励：最终状态是否达到目标
• 中间步骤奖励：基于 UI 状态变化的进度估计
• 效率惩罚：冗余操作和错误操作的负反馈

强化学习使模型从"模仿人类轨迹"进化到"自主探索更优策略"——这是 GUI Agent 超越纯监督学习方案的关键能力来源。

三、明略科技 Mano-P 技术实现详解

3.1 GUI-VLA 统一架构

明略科技开源的 Mano-P 项目提出 GUI-VLA（Vision-Language-Action）统一架构，核心设计理念是将视觉理解、语言推理、动作执行整合到单一端到端模型中，而非传统的多模块 pipeline。

传统 pipeline 方案（OCR → 元素检测 → LLM 规划 → 动作执行）的问题在于：模块间信息损失、错误级联放大、无法端到端优化。GUI-VLA 的统一架构将这些能力内化为模型的不同功能层，通过共享的表示空间实现视觉-语言-动作的无缝对齐。

架构上：

• 视觉编码器负责 GUI 截图理解，产出空间感知的视觉特征
• 语言模型骨干融合视觉特征和文本指令，进行多步推理
• 动作头将推理结果解码为坐标和动作类型的结构化输出

这种统一设计的关键优势是端到端可优化性——奖励信号可以从最终的动作结果一路反传到视觉编码层，使整个系统协同进化。

3.2 三阶段训练管线

Mano-P 采用精心设计的三阶段渐进式训练策略：

Stage 1：SFT 阶段（行为克隆）

监督微调阶段通过大规模人机交互轨迹数据进行行为克隆（Behavior Cloning）。训练数据包括：GUI grounding 数据（截图-元素坐标对）和 Agent 轨迹数据（多步操作序列）。

这一阶段的核心目标是建立两个基础能力：

1. 视觉 grounding——“看到 UI 元素，输出精确坐标”
2. 操作模式识别——“在特定界面状态下，人类通常怎么操作”

行为克隆的局限性在于它只能学习到数据分布内的行为，无法处理 out-of-distribution 场景。这由后续阶段弥补。

Stage 2：Offline RL（优势学习）

离线强化学习阶段引入 Advantage Learning，在已有轨迹数据上学习哪些动作比平均策略更好。通过对比同一状态下不同动作的最终任务完成率，模型学会区分"好的操作"和"可行但次优的操作"。

Offline RL 的优势在于：不需要实时环境交互（计算成本低），同时能超越纯行为克隆的性能上限。通过优势函数估计，模型对自身决策获得了"好坏判断"能力。

Stage 3：Online RL（环境交互）

在线强化学习阶段让模型与真实 GUI 环境交互，基于实际执行结果进行策略优化。这一阶段解决的是 Offline RL 数据覆盖不足的问题——模型可以探索训练数据中未出现过的状态空间。

三阶段管线的设计哲学是从确定性到探索性：先让模型学会模仿，再让它学会判断好坏，最后让它自主探索更优策略。

3.3 Mano-Action：双向自强化学习方法

Mano-P 提出 Mano-Action 双向自强化学习方法，这是超越传统单向 RL 的关键创新。

传统 RL 是单向的：Agent 在环境中行动 → 获得奖励 → 更新策略。Mano-Action 引入双向强化机制：

• 正向：Agent 执行动作 → 环境反馈 → 策略更新（标准 RL）
• 反向：成功轨迹回溯 → 提取关键决策点 → 生成高质量训练样本 → 回注 SFT 数据

这形成了一个自强化循环：RL 产出的优质轨迹反哺监督学习数据，提升后的监督模型又为 RL 提供更好的初始策略。双向自强化避免了纯 RL 训练中常见的样本效率低和不稳定性问题。

3.4 Think-Act-Verify 推理循环

在推理阶段，Mano-P 采用结构化的 Think-Act-Verify 循环：

• 截屏（Observe）：获取当前屏幕状态
• 推理（Think）：分析界面状态 + 回顾操作历史 + 规划下一步
• 执行（Act）：生成并执行具体操作指令
• 验证（Verify）：重新截屏，对比预期状态与实际状态
• 修正（Correct）：若验证失败，回滚或采取补救操作

相比简单的 ReAct 范式，Think-Act-Verify 的关键差异在于显式的验证步骤。多步骤 GUI 任务中，单步错误会级联放大——第 3 步的误点击可能导致后续所有操作都在错误的页面上执行。验证机制将错误控制在局部范围，显著提升了长序列任务的成功率。

3.5 GSPruning：锚点保留 + 语义异常值检测

GSPruning（Grounding-guided Spatial Pruning）是 Mano-P 解决视觉 token 效率问题的核心方案，包含两个协同机制：

锚点保留（Anchor Preservation）：在 token 裁剪过程中，保留能够表征全局空间结构的"锚点" token。这些锚点均匀分布在屏幕的关键位置（四角、中心、分隔线等），确保裁剪后的 token 集仍能重建页面的整体布局信息。

语义异常值检测（Semantic Outlier Detection）：利用 GUI grounding 阶段习得的注意力分布，识别视觉特征空间中的"异常值"——即与周围 token 语义差异显著的 token。这些异常值通常对应于关键 UI 元素（按钮、输入框、文本标签），即使在高度裁剪的情况下也被优先保留。

量化效果：GSPruning 在仅保留 25.09% 的视觉 token 时，OSWorld 上的 Success Rate 为 0.370，对比未裁剪 baseline 的 0.390 仅下降 0.02——几乎可以忽略的性能损失换来了 2-3 倍的推理吞吐提升。

这一设计的工程意义在于：端侧设备的内存和算力是硬约束，GSPruning 使得 GUI Agent 在 MacBook 等消费级设备上的实时交互成为可能。

四、明略科技 Cider SDK：端侧推理加速引擎

明略科技推出的 Cider SDK 是专为 GUI Agent 端侧部署设计的推理加速引擎，核心解决 Apple Silicon 平台上视觉-语言模型的推理效率问题。

4.1 量化方案：W8A8 / W4A8 激活量化

与社区主流方案（MLX W4A16——仅权重量化，激活保留 FP16）不同，Cider 采用激活量化策略：

• W8A8：权重 INT8 + 激活 INT8，精度-速度平衡最优解
• W4A8：权重 INT4 + 激活 INT8，极致压缩，适合内存受限场景

激活量化的核心技术挑战在于激活值的动态范围远大于权重——权重在训练后固定，可以离线校准量化参数；但激活值随输入变化，需要在线量化。Cider 通过以下技术解决：

4.2 INT8 TensorOps 与量化粒度

INT8 TensorOps：充分利用 Apple Silicon ANE/GPU 的整数运算单元。FP16 矩阵乘法在 M 系列芯片上受限于浮点吞吐；INT8 运算理论吞吐翻倍，Cider 通过算子级优化实际兑现了这一硬件红利。

量化粒度选择：Cider 支持多种量化粒度配置，在精度与效率间提供灵活权衡：

量化粒度	加速比	适用场景
Per-channel	1.8x	精度敏感，对重要层保留更细粒度
Per-group (gs=128)	1.5x	平衡方案，适合大多数部署
Per-tensor	最高加速	速度优先，可接受轻微精度损失

Per-channel 量化为每个输出通道维护独立的 scale/zero-point，精度最优但校准开销较大；Per-group（group size=128）在相邻通道间共享量化参数，是精度和效率的工程最优解。

4.3 端侧实测性能

在 Apple M5 Pro 芯片上的实测数据：

指标	数值
Decode 速度	~80 tok/s
W8A8 Prefill 延迟	2.519s
Prefill 加速比	~12.7%（vs FP16 baseline）
对比 MLX(W4A16) 整体加速	1.4-2.2x

80 tok/s 的 decode 速度意味着一次典型的 Think-Act 推理（200-300 token）仅需 3-4 秒。结合 GSPruning 的 token 压缩，完整的"截屏→推理→执行"循环可控制在 5-6 秒内——这是 GUI Agent 从"实验室 Demo"走向"日常可用工具"的关键性能门槛。

五、两种范式技术对比总览

维度	RPA（规则驱动）	GUI Agent（视觉驱动，以 Mano-P 为例）
泛化能力	每应用单独适配，N 应用 = N 套脚本	跨应用通用，一个模型覆盖所有 GUI
UI 变更维护成本	高，30-50% 运维成本用于修复	低，视觉语义不变则行为不变
跨应用能力	需 DOM/AT/UIAutomator 三套栈	统一视觉接口，天然跨平台
非结构化界面	无法处理（Canvas/远程桌面）	正常工作，仅需屏幕像素
隐私安全性	需系统级 API 权限（AT/Hook）	仅需屏幕画面，无需侵入式权限
执行延迟	毫秒级（规则匹配 + API 调用）	秒级（视觉编码 + 模型推理），Cider 优化后 5-6s/循环
执行精度	确定性 100%（选择器命中时）	概率性，Think-Act-Verify 保障
复杂任务能力	受限于预定义分支	可处理开放式、模糊指令
模型规模	无模型，规则引擎轻量	4B-72B 参数，需 GPU/NPU/ANE
开源许可	商业授权为主	Mano-P：Apache 2.0 完全开源

六、评测数据与行业定位

6.1 OSWorld 基准

Mano-P 72B 在 OSWorld 基准测试中达到 58.2% 的 Success Rate。需要明确：72B 为评测模型，当前开源版本为 4B 参数量级，适合端侧部署场景。

6.2 WebRetriever Protocol I

在 Web 导航评测 NavEval 上：

模型	NavEval Score
Mano-P (明略科技)	41.7
Gemini 2.5 Pro	40.9
Claude 4.5 Sonnet	31.3

这一结果表明，明略科技开源的 Mano-P 在 Web 场景下的导航能力已达到或超越闭源商业模型水平，验证了 GUI-VLA 统一架构 + 三阶段训练管线的技术路线有效性。

6.3 适用场景判断

RPA 仍然适合：高频确定性流程（ERP 录入）、合规审计严格场景（金融交易）、简单重复操作。

GUI Agent 更优：跨应用复杂工作流、频繁迭代的 SaaS 界面、非标准化操作、端侧隐私场景。

两种范式是共存而非替代的关系。技术演进方向是 GUI Agent 持续扩展适用边界，而 RPA 收缩到"确定性内核"场景。

---

项目地址：

• Mano-P：https://github.com/Mininglamp-AI/Mano-P
• Cider SDK：https://github.com/Mininglamp-AI/cider

欢迎 Star⭐、issue、PR