🖥️ Computer Use 主流方案与工具调研（2026-11） #

1. 概念厘清：Computer Use、Browser Use、GUI Agent #

关键区别：Computer Use 是“控制范围”概念（整台电脑），不是“感知方式”概念。它既可以用截图，也可以用 Windows UI Automation / macOS AX / Android AccessibilityService；具体走哪条，取决于 模型 + Harness，而不是这个名字。

1.1 技术闭环 #

任务 → 状态感知（截图 / 无障碍树 / DOM）→ 多模态或文本模型推理
     → 动作（坐标点击 / 元素点击 / 键盘 / 脚本）
     → 执行环境 → 新状态 → 循环 → 完成/求助/超步数终止

关键能力拆成三块：

1. GUI Grounding：把“点击登录按钮”映射到屏幕坐标。
2. Planning：把长任务拆成可执行步骤，维护中间状态。
3. Error Recovery：识别失败、回退、重试、向人求助。

1.2 四条感知 / 动作路线（重点） #

不是所有 CUA 都靠截图。按“模型看到了什么、动作怎么表达”分，至少有四条路线：

flowchart TD
    T["用户任务"] --> Q{"目标界面有可靠的结构化通道吗？"}

    Q -->|"有：标准 Web / 原生控件 / 表单"| S1["无障碍树 / DOM 快照"]
    Q -->|"没有：Canvas / 游戏 / 远程桌面 / 自绘控件"| V1["屏幕截图"]

    S1 --> S2["结构化元素<br/>role · name · value · bounds · state"]
    V1 --> V2["视觉模型<br/>OCR · grounding · 布局理解"]

    S2 --> S3["元素动作<br/>click(element_42)<br/>click(role=Button, name=Save)"]
    V2 --> V3["坐标动作<br/>click(x, y) · type · key"]

    S3 --> E["执行环境<br/>浏览器 / 桌面 VM / 云电脑"]
    V3 --> E

    E --> R{"结果验证"}
    R -->|"成功"| N["下一步 / 完成"]
    R -->|"失败：元素为空 / 标签重复 / 树与像素不一致"| F["切换到另一通道"]
    F --> S1
    F --> V1
    N --> Q

    classDef struct fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20;
    classDef vision fill:#fff3e0,stroke:#ef6c00,color:#e65100;
    classDef env fill:#e3f2fd,stroke:#1565c0,color:#0d47a1;
    classDef task fill:#f3e5f5,stroke:#6a1b9a,color:#4a148c;
    class S1,S2,S3 struct;
    class V1,V2,V3 vision;
    class E,R env;
    class T,Q,N,F task;

什么是无障碍 API（a11y API） #

无障碍 API 是操作系统 / 浏览器暴露给辅助技术（屏幕阅读器、语音控制、UI 测试）的一套结构化 UI 接口。它把屏幕上的界面描述成一棵树：

• 节点：窗口 → 面板 → 按钮、输入框、菜单、列表项……
• 属性：role / control type、name / label、value、description、bounds、enabled、focused、checked、selected、expanded、editable、password、scrollable
• 动作：invoke / click、set value、toggle、select、expand / collapse、scroll、focus

例如一个“保存”按钮在树里可能是：

role=button, name="Save", bounds=(812, 433, 88, 32), enabled=true, focusable=true

Agent 看到的是“保存按钮”，可以直接 click(element_42)，由驱动调用系统的 InvokePattern / AXPerformAction，不需要截图和坐标。

各平台实现

和 DOM 的关系：DOM 是网页的文档结构；浏览器无障碍树是 DOM 的语义投影（过滤纯展示节点，补充 role/name/state）。桌面无障碍树则是操作系统层面的控件树。两者都算“结构化通道”，但不是同一个东西。

注意：无障碍 API 不是为 Agent 设计的，而是给辅助技术用的。所以会有覆盖不全、树与像素不一致、平台碎片化、权限申请（macOS 辅助功能权限、Android 无障碍服务）等问题。

为什么很多团队选无障碍 API #

• 确定性：元素有 role、name、bounds、states，选的是“保存按钮”，不是“坐标 (812, 433)”。
• 快且便宜：结构化文本比截图 token 少得多；元素动作通常是毫秒级 COM/API 调用，不需要每步跑视觉模型。
• 可验证：元素动作可以由 driver 确认是否真的触发；部分平台还能后台执行，不抢占鼠标。
• 抗视觉变化：DPI、主题、分辨率、窗口位置变化不影响语义选择器。
• 状态更完整：能拿到 isScrollable、isEditable、isFocused、isPassword 等截图看不出的状态。

有厂商/工程文章给出的经验值是：标准业务 App 里约 95% 的点击可以走无障碍树，剩下约 5% 用视觉兜底。这个比例不是定律，但方向是对的。

什么时候必须回到截图 #

• Canvas / 游戏 / CAD / 视频编辑：整个窗口在 AX 树里可能只有一个不透明节点。
• 远程桌面 / Citrix / VDI：宿主端只看到一块位图。
• Electron / 自绘控件 / 关闭了 UIA provider 的遗留系统：AX 树为空或与像素不一致。
• Flutter / WebView 没写 Semantics/ARIA：结构树缺元素。
• 视觉内容本身：图表、图片、验证码、颜色/布局判断。
• AX 树出现重复标签、空标签、stale bounds：需要截图消歧。

动作语法也不同 #

1.3 动作空间的优先级 #

生产系统里不要一味用像素级操作，推荐顺序：

API / MCP 工具  >  无障碍树 / DOM 元素动作  >  截图 + 坐标点击

• 有 API 就用 API：更快、更便宜、更可验证。
• 标准控件、网页、表单优先 AX/DOM：Browser Use、Playwright MCP、Stagehand 这类方案 token 效率高。
• 只有 Canvas、远程桌面、游戏、legacy 系统才用纯视觉。
• 真实任务跨界面时，用同一个 click 工具做路由：这一轮哪个通道看到了元素就用哪个，不要在 Agent 之间来回切换。

2. 市场格局速览 #

2.1 商业方案 #

各方案感知通道对照 #

以官方文档和公开资料为准；产品迭代快，具体版本可能变化。

2.2 开源模型 #

2.3 开源框架 / 工具 #

2.4 环境 / 沙箱基础设施 #

选择原则：只操作网页 → 浏览器基础设施；要操作桌面 App / 文件 / 终端 → 完整 VM 或云电脑。

3. 重点方案拆解 #

3.1 Anthropic：Claude Computer Use + Cowork #

API 形态

• 通过 Messages API 传入截图和 computer_toolset_20260801 工具定义，模型返回动作；你的 agent loop 执行动作、再回传截图。
• 当前工具集约 17 个成员工具，覆盖 screenshot、left_click、type、key、scroll、zoom 等；不再需要 beta header。
• 可用平台：Claude API、Google Vertex AI、Amazon Bedrock；部分企业云仍在 beta。
• 支持模型（截至 2026-11 公开资料）：Claude Opus 4.8 / 5 / 5.5、Sonnet 5 / 5.5、Fable 5 / 5.1 等。

产品形态：Cowork

• 2026-01 研究预览，2026-04 GA；Claude 桌面端的 agent 模式。
• 本地优先：在本地 VM / 指定文件夹里读写文件，能操作 Office 文档、浏览器、连接器。
• 50+ 连接器：Google Calendar、Slack、Gmail、Linear、Jira、Notion、GitHub、Stripe、Figma 等。
• 支持 Manual / Auto / Skip 三种审批模式；购买等不可逆动作仍会询问。
• 适合：文件密集、文档处理、NDA 敏感、本地数据不想上云的任务。
• 不适合：多小时后台异步任务、需要大规模并发的场景。

评价

• 优势：桌面推理和文档处理强；API 控制粒度细；企业云覆盖广。
• 代价：API 只给“模型 + 工具”，沙箱、会话状态、恢复、审计都要自己做；每一步都带截图，长任务 token 成本高。

3.2 OpenAI：computer use / ChatGPT Agent #

• Operator 已下线：2025-08-31 关闭，并入 ChatGPT Agent。老教程里的 Operator 信息已过时。
• 当前 API 是 Responses API 的 computer 工具，两种模式：
  1. 结构化动作：返回 computer_call，内含有序 actions[]（点击、输入、滚动等），你逐条执行。
  2. 生成自动化代码：模型写 Playwright / PyAutoGUI 代码，适合可复核、可复跑的固定流程；官方推荐 GPT-6 Astra 走代码路径。
• 你仍然要负责：隔离环境、截图采集、状态管理、安全策略。
• 优势：代码生成模式对重复流程效率高；API 生态成熟。
• 劣势：桌面场景的“看屏幕”能力与 Claude 相比没有明显优势；托管产品能力主要在 ChatGPT 内。

3.3 Google：Gemini Computer Use + Chrome Auto Browse #

• Gemini Computer Use：
  • 输出 0–999 归一化坐标，客户端映射到实际分辨率。
  • 支持 browser / mobile（Android）/ desktop 三种 environment。
  • 推荐 Gemini 3.8 Flash；2026-06 起 computer use 成为 Gemini 3.5 Flash 的内置工具。
  • 内置安全策略：购买、敏感数据、通信、注册账号、法律协议等会要求确认；prompt injection 检测需显式开启。
  • 仍是 Preview，官方明确提示可能有错误和安全漏洞。
• Gemini in Chrome / Auto Browse：
  • 浏览器内置 agent，可完成比价、填表、订阅管理、报销等多步任务。
  • 截至 2026-08-31，仅限美国 Google AI Pro / Ultra 订阅用户。
• 优势：Android / 移动端自动化最强；与 Google 生态结合好。
• 劣势：桌面端生态不如 Anthropic/OpenAI；Preview 状态。

3.4 Microsoft：Foundry computer use + Fara #

• Azure AI Foundry Agent Service 的 computer use 工具：
  • 使用 computer-use-preview 模型；截图 → 动作 → 截图循环。
  • 支持 browser / windows / mac / ubuntu 环境声明。
  • 企业治理、区域部署、与 Azure 安全体系集成。
  • 仍是 Preview；官方强烈建议只在低权限 VM 上运行。
• Fara 1.5（开源权重）：
  • 4B / 9B / 27B 三个尺寸，MIT，基于 Qwen3.5，纯截图输入，不依赖 DOM 或可访问性树。
  • Fara1.5-9B：63.4% Online-Mind2Web、86.6% WebVoyager；27B：72.3% Online-Mind2Web。
  • 可在 Microsoft Foundry 托管，也可从 Hugging Face 下载；配套 Magentic-UI / Fara CLI harness。
  • 定位是浏览器为主的小型 CUA，适合端侧、隐私敏感、低成本场景。
• 优势：企业采购友好；小模型可本地/端侧；MIT 许可宽松。
• 劣势：Fara 主要面向 Web，不是完整桌面 Agent；Foundry 工具仍是 Preview。

3.5 Amazon：Nova Act #

• Python SDK + 托管浏览器 + AgentCore 运行时。
• 面向浏览器任务，按 agent-hour 计费（约 $4.75/agent-hour）。
• 适合已经在 AWS 上的团队；桌面能力有限。

3.6 消费级产品：Cowork / Manus / 千问 Go / Doubao Work #

选择建议

• 数据必须在本地、主要处理文件 → Cowork。
• 要 7×24 云端跑长任务、要云电脑 → Manus。
• 主要操作国内 App（淘宝、大麦、夸克）→ 千问 Go / Doubao Work。
• 要可编程、可审计、可集成 → 走 API，不要用消费级产品。

4. 基准与能力现状 #

4.1 主要 benchmark #

4.2 关键结论 #

1. OSWorld 1.0/Verified 已接近“能用”：头部模型 80% 左右，但仍有明显的任务类型短板。
2. OSWorld 2.0 暴露真实差距：论文报告的最佳二进制完成率约 20.6%，部分完成率约 54.8%（500 步预算）。长程任务中，Agent 容易丢失约束、忽略中途信息、跳过验证、该问人时自己猜。
3. 分数不可直接比较：分辨率、步数、是否批量工具调用、grader、是否修改任务，都会显著影响结果。看到“某模型 80%+”先问口径。
4. 开源与闭源差距在缩小：Qwen-CUA、EvoCUA、Agent S、OpenCUA 在部分 benchmark 上已接近或超过上一代闭源系统。
5. 移动端是独立战场：Gemini、AutoGLM、MAI-UI 在 AndroidWorld 上的表现不能直接迁移到桌面。

4.3 成本量级 #

成本优化

• 能用 API / MCP 就不要截图。
• 截图压缩、裁剪、zoom，只传必要区域。
• 批量动作（batched tool calls）减少往返。
• 用小模型做 grounding，大模型做规划。
• 设置硬步数/时间上限，失败快速回退人工。

5. 选型建议 #

5.1 决策树 #

你的任务主要在哪里？
├─ 只在网页
│   ├─ 需要反爬 / 大规模并发 / 托管浏览器
│   │   → Browserbase / Steel / Hyperbrowser + Stagehand / Browser Use
│   └─ 自建、可控成本
│       → Browser Use / Stagehand / Skyvern
│
└─ 需要操作桌面 App、文件、终端
    ├─ 要最快落地，可接受闭源 API
    │   → Claude / OpenAI / Gemini Computer Use + E2B / Scrapybara / Orgo
    ├─ 要自托管、数据不出域、可换模型
    │   → UI-TARS / Fara / OpenCUA / EvoCUA / Qwen-CUA + Agent S
    ├─ 面向非技术用户，开箱即用
    │   → Cowork / Manus / 千问 Go / Doubao Work
    └─ 已经在 Azure / AWS
        → Microsoft Foundry computer use / Amazon Nova Act

5.2 按感知通道选（先问这一层） #

选模型之前，先判断目标界面有没有可靠的结构化通道。这往往比模型选择更决定成败。

5.3 按需求选 #

5.4 Build vs Buy #

6. 生产落地要点 #

6.1 安全：靠结构，不靠 prompt #

参考框架：OWASP LLM01（Prompt Injection）、LLM06（敏感信息泄露）、OWASP Agentic Guidance、NIST AI 600-1。

6.2 可靠性 #

• 状态校验：每步后确认 UI 是否真的变化，不要假设点击成功。
• 断点续跑：长任务要能暂停、恢复、重放。
• 幂等：重复执行不能造成重复下单/重复发送。
• 硬限制：步数、时间、token、下载大小、并发数。
• 回退人工：卡住时把控制权交还用户，不要静默重试。
• 私有评测集：用自己业务的任务集评估，指标看二进制完成率 + 单次成功成本，不只看公开 benchmark。

6.3 可观测性 #

一次合格的审计日志至少回答三个问题：

1. Agent 看到了什么？（截图 / DOM 快照，脱敏）
2. 为什么允许这个动作？（策略命中 / 人工审批）
3. 动作之后发生了什么？（结果、页面变化、下载文件哈希）

6.4 应用如何支持无障碍 API（给开发者） #

目标：让 Agent（和屏幕阅读器）能稳定拿到“这是什么控件、叫什么、什么状态、能做什么”，而不是只能看像素。

原则 #

1. 优先用原生控件：原生 button / input / list 自带 role、state、action；自定义 div / canvas 要自己补。
2. 每个可交互元素都有可访问名称：可见文本优先；图标按钮用 aria-label / contentDescription / accessibilityLabel。
3. 状态要真实：disabled、checked、expanded、selected、busy、invalid、password 不能只靠颜色/样式表达。
4. 暴露动作：不是“画了一个按钮”，而是“声明它是按钮，并支持 Invoke / Press / Click”。
5. 树与视觉同步：bounds、可见性、焦点、列表项要随 UI 更新；动画/虚拟列表容易产生 stale bounds。
6. 名称要唯一、可区分：多个“编辑”按钮要带上下文（“编辑收货地址”“编辑账单地址”）。
7. 不要泄露敏感信息：密码框标记 secure/password；不要把 token、完整手机号放进 name/value。
8. 键盘可操作：能 Tab 到、能 Enter/Space 触发、焦点可见、Modal 有焦点管理。

平台清单 #

给 Agent 的额外建议 #

• 加稳定标识：Windows AutomationId、macOS accessibilityIdentifier、Android resource-id（Compose 可用 testTag 辅助测试）、Web id / data-testid（data-testid 主要给 DOM Agent，不自动进 a11y 树）。
• 暴露自定义动作：Canvas 工具条可以提供“语义覆盖层”——每个可点区域对应一个透明的可访问按钮，或实现自定义 action。
• 虚拟列表：确保滚动动作可用，暴露 item count / isScrollable；不要只渲染可视区且不更新树。
• 状态变化发事件：Windows UIA event、ARIA live region、Android announceForAccessibility、iOS UIAccessibility.post。
• 提供降级路径：如果树不完整，至少让关键操作有键盘快捷键或可访问的菜单入口。

自测清单 #

• 只用键盘能完成核心流程
• 屏幕阅读器能读出每个控件的名称、角色、状态
• 每个可交互元素都有非空 name 和明确 role
• 没有重复到无法区分的 name
• disabled / checked / expanded / busy / error 状态可被读出
• Modal 打开后焦点进入，关闭后焦点回到触发点
• 虚拟列表滚动后，树里的元素和 bounds 同步更新
• 密码框不会被读出明文
• 用 Agent 跑 10 个真实任务，统计“元素找到率”和“回退截图率”

7. 趋势判断 #

1. 端到端 native CUA 成为主流：从“prompt + 工具链”转向“截图输入、动作输出”的专门模型；UI-TARS、Fara、OpenCUA、Qwen-CUA、EvoCUA 都是这个路线。
2. RL + 合成环境 + 数据飞轮：大规模可验证任务、云沙箱并行 rollout 成为训练基础设施；美团 EvoCUA、Qwen-CUA 都强调这一点。
3. 长程任务是新分水岭：OSWorld 2.0 把评测从“30 步小任务”推到“数百步真实工作流”，可靠性比单步 grounding 更重要。
4. 消费级产品与开发者 API 分化：Cowork / Manus / 千问 Go 面向普通用户；Computer Use API 面向开发者。两者能力同源，但产品形态完全不同。
5. 开源权重快速追赶：7B–32B 模型在特定场景已够用；端侧、隐私、成本是主要驱动力。
6. 标准化：MCP、统一的 computer tool schema、动作空间（click/type/scroll/key）正在收敛。
7. 安全成为采购门槛：prompt injection、凭证泄露、不可逆操作是 CUA 上生产的三大障碍；“沙箱 + 最小权限 + 人工审批 + 审计”会变成标配。
8. 混合动作空间成为共识：纯视觉不是最优解。生产系统会越来越多地采用“API/MCP 优先、无障碍树/DOM 次之、像素兜底”的路由式设计；关键不是选边，而是让同一个工具能在元素动作和坐标动作之间切换。

8. 参考资料 #

官方文档 / 产品 #

• Anthropic Computer Use: https://docs.anthropic.com/en/docs/agents-and-tools/computer-use
• Claude Cowork: https://claude.com/product/cowork
• OpenAI Computer Use: https://platform.openai.com/docs/guides/computer-use
• Gemini Computer Use: https://ai.google.dev/gemini-api/docs/computer-use
• Microsoft Foundry Computer Use: https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/computer-use
• Amazon Nova Act: https://aws.amazon.com/nova-act/
• Manus: https://manus.im
• Simular: https://simular.ai

开源项目 #

• UI-TARS Desktop / Agent TARS: https://github.com/bytedance/UI-TARS-desktop
• Microsoft Fara: https://github.com/microsoft/fara
• Agent S: https://github.com/simular-ai/Agent-S
• OpenCUA: https://github.com/xlang-ai/OpenCUA
• Browser Use: https://github.com/browser-use/browser-use
• trycua/cua: https://github.com/trycua/cua
• Steel Browser: https://github.com/steel-dev/steel-browser
• Skyvern: https://github.com/Skyvern-AI/skyvern
• OpenAdapt: https://github.com/OpenAdaptAI/OpenAdapt
• ByteBot: https://github.com/bytebot-ai/bytebot
• Open Interpreter: https://github.com/OpenInterpreter/open-interpreter
• Microsoft UFO: https://github.com/microsoft/UFO
• Microsoft Magentic-UI: https://github.com/microsoft/magentic-ui

感知 / 无障碍 #

• Playwright MCP（无障碍快照）: https://github.com/microsoft/playwright-mcp
• Microsoft UI Automation: https://learn.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-overview
• Apple Accessibility API（AXUIElement）: https://developer.apple.com/documentation/applicationservices/axuielement
• Android AccessibilityService: https://developer.android.com/reference/android/accessibilityservice/AccessibilityService
• Linux AT-SPI2: https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/
• trycua CUA：树 + 截图双通道: https://cua.ai/docs/concepts/capture-and-delivery-modalities
• LUMOS：无障碍 OS 层论文: https://arxiv.org/html/2606.30697
• GUI Agents: A Survey: https://arxiv.org/html/2412.13501v3

基础设施 #

• E2B: https://e2b.dev
• Daytona: https://www.daytona.io
• Orgo: https://www.orgo.ai
• Scrapybara: https://scrapybara.com
• Browserbase: https://www.browserbase.com
• Hyperbrowser: https://www.hyperbrowser.ai
• Kernel: https://www.kernel.sh
• Anchor Browser: https://anchorbrowser.io

Benchmark / 研究 #

• OSWorld 2.0: https://osworld-v2.xlang.ai/
• OSWorld: https://os-world.github.io/
• WebVoyager: https://github.com/MinorJerry/WebVoyager
• Online-Mind2Web: https://github.com/OSU-NLP-Group/Mind2Web
• AndroidWorld: https://github.com/google-research/android_world
• ScreenSpot-Pro: https://github.com/likaixin2000/ScreenSpot-Pro
• Qwen-CUA 论文: https://arxiv.org/html/2608.02352
• EvoCUA（美团）: https://tech.meituan.com/2026/01/26/EvoCUA.html

9. 待补充 / 后续验证 #

• 用自己业务的 20–50 个真实任务做一次横向 POC（Claude / OpenAI / UI-TARS / Browser Use）。
• 测一下截图分辨率、步数预算对成功率与成本的影响。
• 评估 E2B / Orgo / Scrapybara 在长任务暂停恢复上的实际表现。
• 关注 Gemini Computer Use 何时 GA、Microsoft Foundry computer use 何时脱离 Preview。
• 关注 OSWorld 2.0 的独立复现结果，避免只信厂商自报。