Computer Use API 与 GUI 自动化

• 理解坐标偏移的来源
• 设计坐标到元素的安全映射
• 执行前二次定位

坐标偏移的主要来源包括：分辨率与 DPI 缩放（不同屏幕/缩放比下同一逻辑坐标对应不同物理像素）、滚动（页面滚动后元素位置变化）、窗口尺寸变化（布局重排导致元素位移）、CSS transform 与缩放。为避免偏移，执行前应做二次定位：先把屏幕坐标转换为视口坐标（考虑缩放因子与滚动偏移），再用 elementFromPoint 或视觉/DOM 交叉验证确认该坐标处确为目标元素，而非仅凭截图坐标直接点击。具体做法：截图时记录视口与设备像素比、滚动位置、窗口尺寸；换算坐标时通过 scrollX/scrollY 和 devicePixelRatio 修正；点击前用 elementFromPoint 验证命中元素，与预期目标匹配，匹配失败则重新定位。这样即使坐标有偏移也能在动作前拦截。

坐标偏移的根源是"坐标系不一致"。截图坐标、视口坐标、DOM 坐标、设备像素坐标之间存在转换关系，执行前必须统一坐标系并做命中测试二次定位，避免盲目点击。

• 理解系统级 UI 的特殊性
• 识别高失败区域的原因
• 设计处理策略

这些区域是高失败区，因为它们跨越了浏览器/应用沙箱边界，进入操作系统原生 UI 层。桌面通知：属于系统级 UI，可能不在可访问性树内、坐标不可预测、且是瞬态弹出。系统对话框（如保存文件、权限确认）：是原生窗口，不是普通 DOM/应用内控件，Agent 无法用常规定位工具访问，且可能阻塞任务。文件选择器：是系统级文件对话框，Agent 难以直接操作，通常需要绕过或用系统级 API 处理。跨应用拖放：涉及操作系统级拖放协议、跨进程数据传递，坐标精确性和时序要求极高，模型难以稳定复现。处理策略：尽可能用应用内 API 或快捷键替代（如直接指定文件路径、用键盘操作），对系统对话框设置人工接管或专门的系统级工具（如 pyautogui 控制的系统 UI），并记录这些操作的高失败率、要求更强的验证。

高失败源于"系统级 UI 不可用常规 DOM 定位"。识别这些区域并采用替代路径（API、快捷键、系统级工具、人工接管）是提升成功率的关键，而非盲目依赖坐标点击。

• 设计误操作后的恢复流程
• 理解状态验证与撤销
• 避免滚雪球式错误

模型误点后应采用"验证—撤销—重规划—人工接管"的恢复链，而非继续盲点。状态验证：动作后立即检查页面状态（元素变化、URL、弹窗、数据值），确认动作是否生效、是否产生预期效果，若状态不符则判定误操作。撤销：对可撤销操作执行撤销（如按 Ctrl+Z、关闭误开的弹窗、导航回退），恢复误操作前状态。重规划：根据当前正确状态重新识别目标与步骤，规划新的动作序列，而不是沿用错误路径。人工接管：当误操作涉及不可逆副作用（误删、误提交、误付款）或多次重规划仍失败时，立即停止并交人工处理，展示当前状态与错误轨迹。核心原则是"每步验证、误操即停、可撤则撤、不可撤则人工"，避免在同一错误状态下反复点击造成更大损失。

误点后的关键是不继续盲目操作。状态验证发现偏差，撤销回退，重规划纠正，不可逆则人工接管。这个链条能防止"小错误演变成大事故"。

• 设计成本与速率控制
• 平衡成本与成功率
• 应对速率限制

控制成本与成功率需多方面平衡。截图频率：用增量截图与差异检测，只在页面变化或决策点截图，避免每步都截。动作轮次：设置最大动作轮次上限（步骤预算），超限即停止，防止模型无限循环，同时用"早期验证"减少无效轮次。模型成本：按任务复杂度选择模型（简单任务用便宜快速模型，复杂任务用强模型），对长任务控制上下文窗口避免膨胀。速率限制：对模型 API 做限流与重试策略（指数退避、并发控制、队列），避免 429；对网页操作也遵守目标站点速率限制。维持成功率的关键是"在预算内完成任务"：用步骤预算 + 状态验证保证任务收敛，用截图优化降本，用限流保证稳定。还应监控成功率与成本的帕累托曲线，找到最优预算点。

成本与成功率是权衡关系。控制手段（截图频率、轮次上限、模型分级、限流）都要在"完成任务"前提下优化，通过预算与帕累托曲线实现成本与成功的平衡。

• 理解系统级认证对话框的风险
• 认识模型盲点的危害
• 设计强制人工接管

UAC、sudo、密码输入等系统对话框涉及操作系统级权限与认证，强制人工接管是必要的。原因：一是安全风险，这些对话框用于授予系统权限，模型盲点可能意外授予高权限、输入错误密码或触发敏感授权，且无法得知模型是否被恶意诱导；二是安全边界，系统认证对话框通常不在应用可访问性树内，模型无法可靠理解其内容，盲目点击可能误触"允许"或"拒绝"；三是合规与责任，系统权限授予应由明确的人类决策负责。处理策略：检测到系统认证对话框（进程/窗口特征、UAC 标志）时，模型立即暂停并弹出人工接管，等待人工完成密码输入或权限确认，期间不执行任何动作，人工完成后由 Agent 检测到对话框关闭再继续；同时记录该操作到审计日志。

系统认证对话框是"权限授予的临界点"，模型盲点可能造成不可逆的安全后果。强制人工接管保护了系统权限边界，并以人类决策承担合规责任。

• 设计特殊控件的成功率评估
• 理解提升策略
• 识别特殊控件的替代路径

评估与提升这些特殊控件应从"替代路径优先、坐标兜底"入手。评估：把这些操作单独建评测集，统计成功率、失败模式（坐标偏移、时序问题、系统拦截），并评估不同替代方案的成功率。提升策略：跨应用拖放——优先用系统剪贴板/API 或键盘命令替代拖放（如复制粘贴、发送文件路径），或用 OS 级拖放库（如 pyautogui/drag）并验证目标；文件选择器——优先用设置文件路径的 API（如 Playwright 的 setInputFiles、发送到文件对话框的路径），避免直接在系统对话框上点击；右键菜单——优先用键盘快捷键（如 Shift+F10、Ctrl+Shift+M）或应用内 API 触发菜单，再点击菜单项，并用可访问性树读取菜单项。共性做法是"能用 API/快捷键则不用坐标"，同时记录每一步的验证结果，形成可量化指标。

特殊控件的高失败源于系统级交互。提升的核心是"减少对坐标的依赖"，用 API、快捷键、剪贴板等确定性路径替代，并建立独立评测集量化成功率。

• 理解截图与坐标不一致的处理
• 认识无障碍树的兜底价值
• 设计混合定位策略

截图与坐标不一致时，应回退到无障碍树以降低错误率。当视觉截图识别出的元素与坐标映射的结果不一致，或坐标定位命中错误元素时，说明视觉/坐标链路不可靠。此时应回退到无障碍树（若可用）：用无障碍树读取元素的语义（role、name、value、state），通过语义定位目标元素，再获取其正确的坐标或直接执行语义操作。无障碍树提供确定性的元素信息，比坐标更可靠，能纠正视觉识别的偏差。若无障碍树也不可用，则回退到 DOM 结构定位或人工确认。这种"视觉→无障碍树→DOM→人工"的降级链能有效降低错误率：视觉提供候选，无障碍树验证语义，坐标只负责最终执行。

截图与坐标不一致说明"视觉信息不可靠"。回退到无障碍树是引入一个更可靠的信息源来验证和纠正，用语义定位替代不确定的坐标定位，是降低错误率的有效手段。

• 理解坐标模型的迁移性
• 评估迁移成本
• 设计跨分辨率适配

坐标模型迁移成本主要来自"坐标系的非标准化"。评估维度包括：模型是否依赖绝对坐标（绝对坐标在不同分辨率/DPI 下失效，需重新校准）、是否依赖相对/语义定位（相对定位与语义定位迁移成本低）、训练数据的分辨率分布（只在特定分辨率训练会过拟合）。迁移成本评估：需在目标分辨率/DPI 上重新评测成功率、重新校准点击映射、可能需重新训练或微调视觉定位模型。降低迁移成本的手段：使用语义定位（无障碍树、DOM）作为主要定位，坐标仅作为最终执行；用相对坐标或归一化坐标；在多种分辨率下做数据增强与评测；运行时动态适配（根据 devicePixelRatio 和视口换算坐标）。总体而言，坐标迁移成本高，应尽量用分辨率无关的定位方式来降低。

坐标迁移成本取决于"定位对坐标的依赖程度"。依赖绝对坐标则成本高（需重新校准/训练），依赖语义与相对定位则成本低（可迁移）。选型应优先降低坐标依赖。

• 理解多显示器与屏幕切换的坐标问题
• 设计坐标映射与设备识别
• 处理虚拟屏幕坐标

跨设备与多显示器切换时，坐标系统比单屏复杂。关键是理解"虚拟屏幕坐标"（virtual screen coordinates）：多显示器环境下，各显示器在虚拟桌面上有不同偏移（可为负），坐标是全局虚拟坐标而非单屏局部坐标。处理策略：记录当前活动的显示器与其坐标范围、分辨率和 DPI；计算目标元素相对整个虚拟屏幕的全局坐标；切换设备或显示器时重新枚举显示器与坐标，重新校准；对跨屏窗口，用窗口位置与显示器边界计算实际坐标。避免在切换后沿用旧坐标，而应在每次动作前用当前屏幕参数重新定位目标窗口并换算坐标。多显示器下还应识别目标元素所在显示器，用对应的 DPI 换算，防止因缩放不一致导致偏移。

多显示器/跨设备的核心是"全局虚拟坐标 + 显示器感知"。坐标计算必须基于当前显示器的范围、DPI 与偏移，切换后重新校准，避免用旧坐标导致误点。

• 理解多模态与纯坐标的差异
• 权衡质量与成本
• 设计混合输入

多模态输入（截图 + DOM）与纯坐标输入在质量与成本上存在显著权衡。多模态输入：模型同时看到视觉截图和 DOM 结构，能理解页面语义、布局、上下文，定位更准确、鲁棒性更高，能处理长尾页面，但 Token 成本高、延迟大、依赖多模态模型。纯坐标输入：成本低、延迟低，但模型缺乏对页面语义的理解，只能"看到"坐标点，无法理解元素含义，面对布局变化、动态页面极易出错，成功率低。权衡原则：对需要理解语义的关键决策（目标选择、复杂表单、异常处理）用多模态输入；对简单、确定的动作（已定位的按钮点击）可用纯坐标或轻量输入。实践中常采用"多模态理解 + 坐标执行"的混合：多模态模型识别目标并生成元素句柄，执行层用坐标/句柄执行。

权衡的核心是"信息丰富度 vs 成本"。多模态提供语义理解换取质量，纯坐标用低成本换取低质量。混合方案"多模态理解、坐标执行"兼顾质量与成本。

• 理解分辨率与成本/精度的关系
• 设计帕累托边界分析
• 选择最优分辨率

截图分辨率影响识别精度与 Token 成本：分辨率越高，细节越清晰、识别精度越高，但 Token 成本越高、模型可能缩放导致边际收益递减。帕累托边界分析：固定任务集，在不同分辨率下测量识别精度与 Token 成本，绘制"成本—精度"曲线，找到帕累托前沿（无法在不增加成本的情况下提升精度的点）。选定策略：对需要精细识别的任务（小控件、密集文本）用高分辨率；对粗粒度任务（大按钮、整页布局）用低分辨率；对不同区域可用不同分辨率（目标区域高分辨率，其余低分辨率）。同时考虑模型的输入分辨率上限（超出会被压缩，浪费成本）。实践上做分辨率扫描实验，找到"精度收益拐点"的分辨率，避免一味提高分辨率。

帕累托边界是"精度与成本的最优折中"。分辨率提升有收益拐点，超过后成本增加但精度不再显著提升。通过扫描实验找到拐点，按任务类型分级选择分辨率。

• 理解两者的范围差异
• 比较定位与访问能力
• 对比安全边界

Computer Use 与 Browser Use 在多个维度有差异。操作系统范围：Browser Use 局限于浏览器内页面，Computer Use 操作整个操作系统（跨应用、桌面、系统对话框）。坐标精度：Browser Use 有 DOM 可精确到元素，Computer Use 依赖屏幕坐标，易受分辨率/缩放/窗口影响，精度较低。可访问性树：Browser Use 有完整的页面可访问性树，语义定位可靠；Computer Use 的桌面可访问性树（如 Windows UIA、macOS AX）覆盖不完整、跨应用差异大，语义定位受限。沙箱面：Browser Use 沙箱在浏览器层（网络、Cookie、权限由浏览器控制），攻击面小；Computer Use 沙箱在整个操作系统层，Agent 能访问文件系统、剪贴板、系统权限，攻击面大、风险高。总体而言，Browser Use 更受控、更精准、更安全，Computer Use 范围更广但更脆弱、更危险。

差异的本质是"作用域不同"。Browser Use 在受限的浏览器语义世界，Computer Use 在开放的系统世界。因此 Browser Use 语义精度高、风险低，Computer Use 范围广但需要更强的沙箱与权限控制。

• 理解两家 Computer Use 方案
• 比较沙箱边界与模型版本
• 评估能力差异

Anthropic Computer Use 与 OpenAI Operator/Computer Use 是两家主流的 Computer Use 方案，存在差异。能力上：两者都支持"看屏幕—点/键操作—验证"的循环，但模型实现不同（Anthropic 用 Claude 系列，OpenAI 用 GPT 系列），在视觉理解、动作规划、长任务稳定性上各有侧重。模型版本：两者都随模型迭代更新（如 Claude 的 computer-use 工具、OpenAI 的 Operator 及其 CUA 模型），且官方强调应使用最新可用模型而非固定旧 preview。沙箱边界：Anthropic 强调 Computer Use 在受控容器/环境中运行，动作需基于当前屏幕截图；OpenAI Operator 提供独立的云端浏览器环境（CUA 模型控制），强调隔离与不可变沙箱。差异还体现在：是否支持浏览器内操作（Operator 偏向浏览器）、API 形式、权限模型、成本与速率限制。选型应根据具体环境（云端 vs 本地）、模型能力、成本与合规要求评估。

两家方案核心思路一致（观察—动作—验证），差异主要在模型实现、运行环境（云端沙箱 vs 本地容器）、能力侧重与成本。选型需结合部署环境与模型版本策略。

• 理解国产 GUI Agent 的能力
• 比较视觉理解与操作能力
• 评估适用场景

国产 GUI Agent 在 GUI 自动化上各有特点。Qwen2.5-VL：是阿里通义的多模态视觉模型，具备强大的视觉理解能力，可识别屏幕/页面元素并输出操作，适合作为 GUI Agent 的视觉底座，可用于截图理解、元素定位、坐标生成。UI-TARS：是字节跳动开源的原生 GUI Agent 模型，专门针对"屏幕理解—动作决策"训练，支持跨平台 GUI 操作，强调端到端的 GUI 推理（理解界面、规划动作、执行点击/输入），适合桌面与网页 GUI 自动化。AutoGLM：是智谱的 GUI Agent，通过屏幕理解与操作闭环，支持手机/桌面应用的自动化操作，强调实际设备的 GUI 任务执行。三者定位差异：Qwen2.5-VL 偏视觉底座模型，UI-TARS 偏专用 GUI Agent 模型，AutoGLM 偏产品化的 GUI 自动化。选型需评估其视觉精度、操作稳定性、跨平台（Windows/macOS/移动）、部署成本与生态。

国产 GUI Agent 通常以"视觉理解 + 动作生成"为核心，差异在模型定位（通用视觉 vs 专用 GUI）、平台覆盖与产品化程度。选型按具体任务与部署环境评估。

• 理解跨平台系统级访问差异
• 设计平台适配
• 管理权限与接口

Computer Use 在三个平台上的系统级访问差异显著。剪贴板：macOS 用 pbpaste/pbcopy 或 NSPasteboard，Windows 用 Win32 剪贴板 API，Linux 用 xclip/xsel 或 Wayland 剪贴板，格式与权限各有不同。通知：macOS 通知中心、Windows 通知、Linux 通知（libnotify/D-Bus），获取与操作通知的 API 各异。文件系统：macOS 有沙盒/权限（TCC 需用户授权访问特定目录），Windows 有 ACL 权限，Linux 权限模型不同。处理策略：抽象一层平台无关的"系统能力接口"，根据不同平台实现后端；对权限（如 macOS 的可访问性权限、屏幕录制权限、TCC）需在首次使用时申请并处理授权；对剪贴板、文件系统做统一封装，返回结构化结果；对键盘/鼠标模拟（macOS 需辅助功能权限等）注意平台差异。跨平台开发应把系统级操作封装为可插拔的适配器，隔离平台差异。

系统级访问的本质是"平台 API 差异"。通过平台适配层统一接口，处理各平台权限与 API 差异，是跨平台 Computer Use 的关键，否则坐标与系统调用会因平台而异。

• 理解模型 ID 的动态性
• 认识写死旧 preview 的风险
• 设计模型版本管理

Computer Use 模型 ID 与稳定性应按官方模型目录核查，原因：一是模型 ID 会随版本迭代变化，官方会发布新模型、弃用旧模型，写死旧 preview 会导致模型不可用或服务降级；二是 preview 模型通常不稳定，能力会变化、可能被淘汰，不适合生产依赖；三是不同环境（厂商、区域）模型 ID 可能不同。正确做法：从官方模型目录/API 动态获取当前可用模型 ID，配置化而非硬编码；对模型版本做监控（检测弃用通知、能力变化）；用稳定版本别名（如某模型的最新稳定版）而非固定 preview；在提交前通过官方目录核查模型 ID 的有效性。这避免"模型 ID 失效导致生产故障"。

写死旧 preview 的风险是"模型演进导致失效"。模型 ID 是动态的，应配置化、从官方目录核查、用稳定版本，并监控弃用，保证生产稳定。

• 理解 GUI Agent 与 RPA 的互补
• 设计混合自动化架构
• 按稳定性分配责任

GUI Agent 与传统 RPA 应形成混合方案：确定性流程用 RPA，长尾/异常用 Agent。RPA 的优势是确定性：选择器（基于 UI 元素、坐标、OCR 的正则），录制流程（录制操作序列回放），确定性规则（明确的 if-then 分支），适合稳定、高频、可重复的流程，执行快、可审计、成本低。GUI Agent 的优势是泛化：理解上下文、处理变化、异常恢复。混合方案设计：主流程用 RPA 的确定性步骤（选择器定位 + 录制动作），当 RPA 选择器失效、页面变化、出现异常分支时，降级到 GUI Agent 重新理解页面并生成动作；Agent 发现的新稳定路径可固化回 RPA。架构上，RPA 提供确定性执行基层，Agent 提供智能决策与异常接管，两者通过统一的流程编排与日志授权衔接。

混合的关键是"确定性优先、智能兜底"。RPA 处理稳定路径，Agent 处理变化与异常，并把 Agent 发现的稳定路径固化回 RPA，兼顾效率与泛化。

• 理解"看—动"循环成本
• 设计循环频率控制
• 平衡观测与效率

"看—动"循环频率过高会导致截图爆炸（每步截图、Token 激增）与过度推理（模型在不必要的地方消耗推理）。控制策略：改变触发——仅在屏幕变化、动作后、或到达决策点时截图，而非每步都看；批量动作——在稳定状态下连续执行多个确定动作（如连续输入），只在需要确认时观察；差异检测——用像素/DOM 差异判断是否值得重新截图，无变化则复用上次观察；推理预算——为每个任务设置推理轮次上限，避免无意义的循环；分层决策——把"看"细分为"全屏看"（少数）与"局部看"（多数），用局部截图完成多数动作。同时用"动作后验证"替代"每步观察"，只在验证失败时回看。目标是用最少的截图与推理完成最多确认。

循环频率控制的核心是"只在需要时观察"。用差异检测、批量动作、决策点触发替代每步截图，配合推理预算，避免成本爆炸保持效率。

• 设计可观测性日志
• 理解各类记录的用途
• 平衡记录与脱敏

Computer Use 的可观测性应记录完整操作轨迹，包括：截图（动作前后，用于视觉回溯与审计）、操作类型（click、type、scroll、key、drag 等）、目标坐标（屏幕坐标与目标元素描述）、操作结果（成功/失败、状态码、系统响应）、操作上下文（时间戳、应用的窗口、当前任务 ID）、输入的内容（脱敏后）。这些记录用于：失败回放（复现操作序列）、审计（谁在何时执行了什么）、安全（检测异常操作）、性能分析（成功率、耗时）。注意脱敏：操作输入中的密码、敏感数据需掩码；截图若含敏感信息需脱敏处理。可观测性应作为系统固有能力，记录到结构化日志，并支持按任务/时间/操作类型检索。

可观测性是把"Agent 行为"变成可审计、可分析的数据。截图、操作类型、坐标、结果、上下文五类信息覆盖"做了什么、在哪做、结果如何"，是故障排查与合规审计的基础。

• 理解模型推理的局限
• 认识 OCR/视觉模型辅助的价值
• 设计混合识别

Computer Use 仍需 OCR/视觉模型辅助，是因为通用模型的推理有局限：一是屏幕复杂，通用模型对密集 UI、小控件、非标准控件的识别精度不足，可能误判控件类型或位置；二是坐标精度，模型输出的坐标可能不精确，需结合视觉模型精确定位；三是鲁棒性，模型对特定 UI 风格过拟合。OCR/视觉模型辅助的价值：OCR 精确提取屏幕文本（识别标签、按钮文字、表单字段），专用视觉模型（目标检测）精确识别控件边界与类型，为通用模型提供结构化、精确的输入，减少幻觉与误判。合理架构是"通用模型做规划决策，OCR/视觉模型做精确识别"，两者结合：通用模型理解意图，视觉模型提供精确控件信息，最后执行。模型推理的局限在于它擅长高层推理而非精确的像素级识别，需专用视觉模型补齐。

通用模型善于"理解与规划"，但在"精确识别密集控件"上能力有限。OCR/视觉模型提供精确的文本与控件边界信息，是提高识别精度、减少误判的必要辅助。

• 理解成本构成
• 设计预算控制策略
• 平衡质量与成本

Computer Use 的成本包括模型调用（推理 Token）、截图（传输与存储）、视觉推理（额外视觉模型调用）。在预算内完成长任务需多管齐下：截图优化——用增量截图、区域裁剪、差异检测，减少每次动作的截图与传输成本；模型分级——按任务复杂度选择模型（简单动作用便宜模型，复杂决策用强模型），减少强模型调用；上下文控制——压缩历史，只保留关键状态，避免长任务 Token 膨胀；视觉推理预算——复用已识别的元素信息，避免重复视觉推理；动作轮次预算——限制定次数，避免模型无限循环；批处理——把多个简单操作合并为一次决策。同时监控单任务成本与成功率，建立成本预算上限，超限时降级（如转人工或简化策略）。目标是在成本预算内完成高成功率的任务。

成本控制的关键是"三大来源（调用、截图、视觉推理）分别优化"。用增量/裁剪降截图，用分级降调用，用压缩降上下文，用预算限轮次，才能让长任务在预算内完成。

• 设计失败时的状态保存
• 理解用户接管所需信息
• 处理敏感信息

任务失败时保存"最终状态截图"是用户接管的关键。应保存：失败时的屏幕截图（含当前界面状态，让用户看到系统停在何处）、已执行动作序列与结果（让用户了解失败路径）、失败原因（错误信息、异常类型）、当前任务上下文（目标、已处理数据）。这些信息应打包成"接管包"，通过 UI 或消息呈现给用户，附上明确的接管操作指引（如"请在此处处理验证码后再继续"）。保存时需脱敏：截图中的敏感信息（密码框、个人数据）应遮挡，动作日志中的敏感输入需掩码。接管后，用户可基于截图与上下文手动完成剩余步骤，或修正后让 Agent 继续。设计上应保证"失败即保存"，并把接管包与任务 ID 关联，便于追溯。

最终状态截图是"人机交接的桥梁"。它让用户无需重新探索即可理解当前状态并接管，配合动作日志与失败原因，构成完整的接管上下文，同时需脱敏。

• 理解各方案的观察—动作循环
• 比较输入输出与工具抽象
• 评估适用场景

三家方案的观察—动作循环核心一致，但实现有差异。Anthropic Computer Use：以"截图 + 工具调用"为核心，模型观察屏幕截图，输出动作（点击、输入、滚动、按键），通过 computer-use 工具执行，强调基于当前截图的动作生成，配合 UI 验证。OpenAI Computer Use/Operator：以专用 CUA 模型为核心，观察截图并输出高层动作序列，在云端隔离浏览器环境执行，强调端到端的目标驱动与多步规划。Qwen2.5-VL：是视觉基础模型，提供"视觉理解 + 动作输出"能力，观察截图理解界面，输出动作或坐标，定位上更偏基础视觉模型，可被集成到自定义 GUI Agent 框架。差异体现在：观察粒度（截图 vs 多模态融合）、动作抽象（全屏截图+原始动作 vs 高层规划）、环境（本地 vs 云端沙箱）、开放性（专用 API vs 可集成模型）。选型根据是否需云端隔离、是否需要自定义编排、模型能力与成本。

三家的循环都是"观察—动作—验证"，但抽象层级与运行环境不同：Anthropic 偏工具化，OpenAI 偏云端目标驱动，Qwen2.5-VL 偏可集成视觉底座。理解差异便于选型。

• 理解两者的成熟度与稳定性对比
• 认识生态差异
• 设计互补应用

GUI Agent 与传统 RPA 在工具成熟度、稳定性、生态上互补。成熟度：RPA（如 UiPath、Automation Anywhere）成熟度高，有完善的记录器、流程编排、调度、监控、版本管理与企业级支持；GUI Agent 相对较新，工具链仍在演进，成熟度较低。稳定性：RPA 基于确定性选择器与录制，稳定、可重复；GUI Agent 概率性，一次成功不可复现，但能适应变化。生态：RPA 有成熟的企业生态（连接器、模板、社区、合规认证）；GUI Agent 生态较新，但发展快，且能利用 LLM 生态。互补方式：成熟稳定的核心流程用 RPA（保障可靠性与企业合规），变化频繁、长尾、需要理解的场景用 GUI Agent（提供泛化）；RPA 处理 80% 稳定流程，GUI Agent 处理 20% 长尾流程，并用 Agent 的能力补充 RPA 对动态页面的短板。两者共享编排与审计层。

互补的本质是"成熟度与泛化能力的互补"。RPA 提供成熟稳定与生态，GUI Agent 提供泛化与智能，按稳定性分层使用，既保障可靠又覆盖长尾。

• 评估生产环境写操作的风险
• 设计写操作的控制策略
• 平衡自动化能力与安全

GUI Agent 在生产环境直接修改业务数据是高风险的，不应默认允许，而应通过严格管控。核心考量：GUI 操作是概率性的，误操作可能修改或删除真实业务数据，且不可逆，影响面大。正确策略是"分级授权 + 强制审批"：只读操作（查询、抽取、导航）可自动执行；写操作（新增、修改）需按风险分级，高风险写操作（删除、付款、覆盖、批量修改）必须在执行前强制人工审批，并展示将要执行的动作与影响；执行后做验证与审计。同时用"预览/模拟"验证目标正确性，用权限最小化限制 Agent 只能访问必要系统。通过"只读默认、写操作审批、敏感操作双人/人工确认"，既允许 Agent 完成必要修改，又控制风险。绝不能无条件放行 Agent 直接写生产数据。

生产写操作的风险是"不可逆 + 概率性"。只读默认、写操作分级审批、高风险强制人工确认，是让 Agent 在受控范围内完成业务修改的关键，避免默认放行。

• 理解视觉推理成本
• 设计检测结果缓存
• 处理缓存失效

目标检测和 OCR 结果缓存能显著减少重复视觉推理成本。策略：把"屏幕区域 → 检测/OCR 结果"的映射缓存，同一屏幕或区域在未变化时复用结果，避免重复调用视觉模型。实现：以屏幕截图哈希或区域快照为缓存键，缓存该区域的检测 bbox、OCR 文本、元素属性；通过像素/屏幕差异检测判断界面是否变化，未变化则直接命中缓存；对缓存设置有效期与容量上限，避免内存膨胀。注意缓存失效：屏幕变化（窗口移动、内容更新、滚动）时须使相关区域缓存失效，重新检测。对高频重复操作（同一表格多次点击、同一表单多次读取）缓存收益最大。缓存应与任务生命周期绑定，避免跨任务污染。

缓存的关键是"把视觉推理结果复用"。以界面区域为键、差异检测驱动失效，能避免对未变化界面的重复推理，显著降低成本，同时保证缓存正确性。

• 理解相近按钮的语义差异
• 设计风险识别
• 防止误操作

"关闭"与"确认"按钮语义相近但风险截然不同，需严格区分。关闭（X、Cancel、Close）通常是放弃操作，风险低；确认（OK、Submit、Delete、Save）执行操作，可能不可逆、风险高。区分方法：通过按钮文本精确匹配（Close vs Confirm vs Delete），结合可访问性/按钮语义（destructive 样式、图标含义）与上下文（弹窗标题、操作对象）判断；对高风险按钮（Delete、Confirm、Submit、Pay）在点击前做语义确认，必要时人工审批。对"误点"防护：用按钮文本白名单/黑名单，明确哪些是高风险动作；对高风险按钮增加二次确认步骤或人工确认；记录点击高风险的按钮到审计日志。目标是对"看起来像确认"的高风险按钮施加额外检查，避免误点造成不可逆操作。

关闭与确认的区分靠"语义 + 上下文 + 风险分级"。按钮文本、可访问性名称、弹窗上下文共同决定风险等级，高风险按钮需额外确认与审计，防止误点。

• 设计临时元素测试
• 理解弹窗/悬浮层的动态性
• 评估稳定性

测试模型对弹窗、悬浮层等临时元素的处理稳定性，需设计专门的测试集与场景。测试集：包含各类弹窗（模态/非模态、通知、广告、确认框、权限提示）、悬浮层（tooltip、下拉、菜单、覆盖层）、时序性临时元素（延迟出现、自动消失、会遮挡目标）。测试维度：检测能力（能否识别临时元素并判断其性质）、决策正确性（是否被临时元素干扰而误点、是否正确处理关闭/忽略）、时序稳定性（能否等待元素出现/消失、处理延迟出现的遮挡）、鲁棒性（多次运行的一致性）。测试方法：在标准评测集上加入临时元素干扰场景，统计成功率与误操作率；用"注入弹窗"实验（在任务中随机插入弹窗）验证模型对干扰的抵抗；对比不同策略（等待 vs 忽略 vs 关闭）的表现。评估临时元素出现时任务是否被正确暂停或继续。

临时元素的稳定性测试核心是"干扰下的正确性"。用含弹窗/悬浮层的专门测试集验证检测、决策与时序处理，并统计误操作率，确保模型不被临时元素带偏。

• 理解分层 Agent 架构
• 设计高层规划与低层执行
• 保持长任务一致性

长任务下 GUI Agent 应采用分层策略：高层规划负责任务分解与目标管理，低层动作负责具体执行与验证。高层规划：把长任务分解为子目标（如"登录→填写表单→提交→验证"），规划步骤顺序，管理任务状态与进度，处理分支与异常选择，记录整体计划。低层动作：执行具体 GUI 操作（点击、输入、滚动），每步动作后做验证（确认目标生效、状态正确），失败时重试或上报高层。分层的好处：高层不受低层细节干扰，能保持长任务的目标一致性；低层专注精确执行，可复用、可验证。两者通过状态与结果协议衔接：低层返回动作结果，高层根据结果推进或调整计划。高层还负责异常处理（如连续失败时降级或转人工）与预算控制。

分层是"长任务可管理"的关键。高层规划保障目标与方向，低层动作验证保障执行正确性，两者分离避免"只见树木不见森林"，也避免低层细节淹没规划。

• 理解两者的场景分工
• 设计互补流程
• 按需求选择

Computer Use 与 Browser Use 应分工互补：Browser Use 处理浏览器内的网页任务（页面操作、表单填写、数据抽取），Computer Use 处理浏览器之外的桌面任务（桌面应用、系统文件、跨应用交互、系统对话框）。互补场景：当任务需要网页 + 桌面协同（如从网页下载文件再保存到桌面应用、在浏览器读取数据后写入本地软件）时，两者结合完成。分工原则：凡能通过浏览器完成的优先用 Browser Use（更精准、更安全、更便宜），需要访问桌面应用或系统资源时用 Computer Use。组合方式：Browser Use 负责网页部分，Computer Use 负责桌面部分，通过统一任务编排传递数据与状态。两者共享安全与审计框架，但 Browser Use 风险更低、Computer Use 需更强权限控制。

互补的本质是"场景分工"。Browser Use 是网页自动化首选（精准安全），Computer Use 覆盖桌面补充，按任务是否在浏览器内决定，跨域任务两者协同。

• 理解辅助场景的可访问性需求
• 设计无障碍输出
• 平衡自动化与辅助

在盲人或低视力用户辅助场景中，Computer Use 的可访问性设计应"以无障碍信息为核心，而非仅依赖视觉"。核心设计：输出应优先提供非视觉信息——用语音/文本描述界面状态（屏幕阅读器朗读 OCR 识别文本、元素语义、操作结果），而非仅依赖截图；用可访问性树/无障碍语义作为首选信息源，覆盖视觉缺失情况；对模型的"看"用"读"补充（OCR 文本 + 无障碍树 + 语音描述），让低视力用户通过听觉理解界面。操作设计：提供键盘导航、语音控制、可缩放、高对比度等辅助输入方式；对动作结果提供语音反馈。同时，Agent 可代用户执行操作（如"帮我点击确定"），用语音输出结果。整体上，可访问性设计让 Computer Use 成为低视力用户的辅助工具，而非仅面向普通用户的自动化。

辅助场景的关键是"把视觉信息转化为可访问信息"。用无障碍树、OCR、语音描述替代视觉依赖，并提供键盘/语音等辅助方式，让低视力用户能"听"与"控"界面。