<!-- title: 看见即烧钱：自主体感知架构实测 -->

# 看见即烧钱：自主体感知架构实测

2026 年最热闹的赛道不是多智能体协作，而是**让模型直接接管你的鼠标键盘**——Computer Use / GUI 自主体。从 OpenAI Operator、Anthropic Computer Use、Google Gemini（Project Mariner 一脉），到微软 UFO、字节 UI-TARS、开源 OpenHands、SWE-agent，一条全新赛道在半年内塞满了玩家。但当你真正把它们放上 OSWorld 这个最权威的桌面操作基准去跑，会发现一个被厂商刻意回避的残酷事实：**决定自主体上限的根本不是模型有多聪明，而是它"怎么看屏幕"**。截图+视觉路线撞在约 66% 的成功率天花板，且每个任务仅"看"这一动作就烧掉 3 万到 4 万 token；而默默走无障碍树（Accessibility Tree）的方案，能用低 10 到 30 倍的 token 成本跑到 70% 以上。本文用 OSWorld 实测数据，拆穿这条"看见即烧钱"的感知税。

## 一、核心结论速览：感知架构即命运

业界对"自主体如何理解屏幕"给出了三条截然不同的技术路线，它们在 OSWorld 2026 年 2 月的实测数据上呈现出清晰的分层：

| 自主体方案 | 感知架构 | OSWorld 成功率 | 单步 token | 单任务耗时 | 典型代表 |
|-----------|---------|--------------|-----------|-----------|---------|
| AskUI VisionAgent | 截图+视觉 | **66.2%** | ~3,500 | N/A | 纯视觉商用 |
| UI-TARS 2（字节） | 截图+视觉 | **47.5%** | ~2,800 | 12–18 min | 开源视觉模型 |
| OpenAI CUA（o3） | 截图+视觉 | **42.9%** | ~4,200 | 15–20 min | Operator 底座 |
| Claude Computer Use | 截图+视觉 | **22–28%** | ~3,800 | 10–15 min | Anthropic 工具 |
| DirectShell（预估） | 无障碍树 | **~70%+** | 50–200 | <2 min | 结构化读取 |
| 人类基线 | — | **72.4%** | — | 30s–2min | — |

数据来自 OSWorld-Verified 公开榜单与多份技术拆解。规律极其刺眼：**截图方案的群体天花板卡在 66%，距离人类基线 72.4% 仍有 6 个百分点；而无障碍树方案以不到截图方案 1/20 的感知 token，逼近甚至超过这个天花板。** 换句话说，多数团队在拼命换更大的模型，却没意识到真正的瓶颈卡在"感知"这一层。

## 二、三大厂商的架构对赌

把镜头拉到厂商层面，三巨头对 Computer Use 下的是完全不同的赌注，这直接决定了你能拿它们干什么：

- **Anthropic —— 可移植工具**。Claude Computer Use（2024 年 10 月公测）把"截图+鼠标键盘"封装成一个标准 tool，通过 Messages API 暴露，运行环境由你自己负责。它能在 Docker 容器、远程 Mac、虚拟机里随处跑，不绑定任何 OS。代价是部署负担全压在你肩上。Claude Opus 4.7（2026 年 4 月 16 日发布）首次把 2,576 像素的高分辨率视觉改进内置进来。
- **OpenAI —— 桌面原生后台会话**。Codex Background Computer Use（2026 年 4 月 16 日随"Codex for almost everything"发布）在 macOS 上跑 Codex Agent 的独立桌面会话，可以并行于工程师的主工作站。配置少，但可移植性窄。
- **Google —— 浏览器锚定**。Gemini Computer Use 源自 Project Mariner，优先 DOM 感知而非像素解析，网页工作流上最强，原生桌面较弱。

记住一句话：**选 Computer Use 不是选模型，是选部署形态**。需要跨平台到处跑选 Claude，需要 macOS 后台并行选 Codex，需要纯网页自动化选 Gemini。

## 三、截图+视觉路线：通用却昂贵的玻璃天花板

这是当下最主流的方案，也是 Operator、Claude Computer Use、Mariner 的共同底座。流程很直白：截屏 → 嵌入多模态 Prompt → LLM 输出坐标与动作 → 输入注入执行 → 循环。核心代码骨架长这样：

```python
class ScreenshotAgent:
    def step(self, goal: str) -> dict:
        shot = pyautogui.screenshot().resize((1024, 768))
        img_b64 = encode_jpeg(shot, quality=80)          # 一张图 1.2k–5k tokens
        resp = llm.chat(model="gpt-4o",
            messages=[{"role": "user", "content": [
                {"type": "text", "text": f"目标: {goal}，给出下一步动作"},
                {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{img_b64}"}}]}],
            tools=[{"type": "function",
                    "function": {"name": "computer_action",
                    "parameters": {"action": {"enum": ["click","type","scroll","hotkey"]},
                                   "x": {"type": "integer"}, "y": {"type": "integer"}}}}])
        return resp.choices[0].message.tool_calls[0].function.arguments
```

**优势**：通用性最强——任何 GUI 都能操作，无需目标应用支持 API；跨平台一致；实现门槛低。这也是为什么"AI 数字员工"类产品几乎清一色套这层壳。

**劣势**：每一帧截图要吃掉 1,200 到 5,000 个 token（GPT-4o/Claude 级别）；每步 2 到 5 秒的"截屏+推理+注入"延迟；LLM 坐标预测有固有误差，密集 UI 上尤其严重；分辨率缩放比一变坐标就漂；最致命的是上下文窗口——截图方案跑到第 10 步基本就把历史挤爆了。

**变现陷阱**：这条路线最容易被包装成训练营，也最容易亏钱。一个 10 步任务，光是"感知"就要烧 3 万到 4 万 token，算上推理和重试，单任务成本轻易破 1 美元。若按"帮你自动填 100 张报销单"这种高频场景计费，毛利率会被 API 账单吃光。**做截图自主体产品，第一性原理是先算清 token 经济账，再谈产品形态**。

## 四、无障碍树路线：被严重低估的捷径

这才是真正的"作弊码"。DirectShell、Windows-MCP、computer-mcp 等项目的核心洞察是：**操作系统早就以结构化文本的形式描述了屏幕上所有 UI 元素，为什么还要让模型去"看"截图？** 以 DirectShell 的 `.a11y.snap` 为例，整个视口被压缩成几行可操作文本：

```
[1] [keyboard] "Adressfeld"   @ 168,41   (2049x29)
[2] [click]    "Neuer Chat"   @ 45,200   (200x30)
[3] [keyboard] "Einen Prompt" @ 999,1177 (1069x37)
[4] [click]    "Einstellungen"@ 1800,1350 (150x20)
# 4 operable elements in viewport
```

截图方案需要 1,200 到 5,000 token 才能传达的画面，这里几十个 token 搞定。而且操作直接按元素 ID 走，不存在坐标偏差：

```python
class AccessibilityAgent:
    def find_and_click(self, name_pattern: str):
        row = self.conn.execute(
            "SELECT id FROM elements WHERE name LIKE ? AND interactive=1 LIMIT 1",
            (f"%{name_pattern}%",)).fetchone()
        self.conn.execute("INSERT INTO action_queue (action, target_id) VALUES (?,?)",
                          ("click", row[0]))     # 按 ID 操作，零坐标误差
```

各平台都有成熟的无障碍 API：Windows 的 UI Automation（UIA，2005 年）、macOS 的 NSAccessibility（2001）、Linux 的 AT-SPI2（2001）、Android 的 AccessibilityService（2009）、Web 的 ARIA+DOM（2014）。这意味着这是一套**存在了二十年的基础设施**，自主体只是第一次学会用它。

**优势**：token 效率高 10 到 30 倍（50–200 vs 1,200–5,000）；本地 API 调用 <200ms，无需网络往返；按元素 ID 操作精度极高；省下的 token 能保留数百步对话历史。

**劣势**：平台相关（每个 OS 要单独适配）；目标应用必须正确实现无障碍支持——游戏引擎、自绘 Canvas、Electron 套壳里没做 a11y 的应用会直接致盲。

**变现机会**：这是企业级桌面自动化的金矿。SAP、Oracle EBS、老旧 Win32 胖客户端、内部 SSO 后台——这些恰恰是 API 化最难、RPA 最贵、无障碍树最完整的地方。**把无障碍树路线包装成"非侵入式桌面自动化"，客单价和续费率都远高于截图套壳产品**。

## 五、视觉 Grounding 中间件：给截图装上骨架

截图路线并非没有救。微软 OmniParser 和字节 UI-TARS 这类"视觉接地中间件"，专门解决一个具体痛点：**原始多模态模型不知道该点哪**。它们把截图解析成结构化的元素列表加边界框，再喂给推理模型。

这一层把"像素 → 可点击区域"的不确定性从 LLM 身上卸下来，交给一个专门的小模型。UI-TARS 2.0 正是靠这套机制把 OSWorld 拉到 47.5%。代价是多了一级推理阶段，延迟和成本上升，但精度提升往往值得。

**适用场景**：当目标应用没有无障碍树（比如游戏化界面、设计软件画布），又不能用 DOM 时，视觉 grounding 是唯一能救回精度的手段。它是截图路线的"补丁"，不是替代品。

## 六、混合感知路由：生产环境的真正答案

成熟的落地系统几乎没人纯走一条路。生产级架构是**感知决策路由器**：优先无障碍树，浏览器场景用 DOM，最后才 fallback 到截图：

```python
class HybridPerception:
    def perceive(self, ctx):
        a11y = self.get_a11y_tree(ctx.app)
        if a11y and self.sufficient(a11y, ctx.goal):
            return Result(source="a11y", confidence=0.95)      # 优先：最便宜最准
        if ctx.is_browser:
            dom = self.get_dom(ctx.browser)
            if dom: return Result(source="dom", confidence=0.90)
        return Result(source="vision",                          # 兜底：最贵最不准
                      elements=self.vision.analyze(self.shot(ctx), ctx.goal),
                      confidence=0.60)
```

这套路由的逻辑是**按置信度和成本排序降级**：能用结构化数据就绝不烧像素。它的工程价值在于——90% 的真实任务落在 a11y 或 DOM 分支，只有少数自绘界面才走到昂贵的视觉兜底。整体平均 token 成本能压到纯截图方案的 1/5 以下，而覆盖率几乎不掉。**如果你要做训练营，"混合感知路由"才是最值得教的那一课**，因为它直接决定了学员做出的产品能不能赚钱。

## 七、开源桌面自主体生态与成本经济学

开源生态已经分层清晰：**软件工程向**有 OpenHands（前 OpenDevin，能写码、跑命令、浏览网页）和 Princeton 的 SWE-agent（专攻 SWE-bench，靠特化的 agent-computer interface）；**桌面操控向**有微软 UFO（UI Follower，Windows 应用 GUI 自动化，视觉接地 + API 级控制双管齐下）、Self-Operating Computer、OS-Copilot、智谱 AutoGLM。微软还把战火烧到了平台层——Copilot Studio 的 Computer-Use Agent 在 2026 年 5 月 13 日进入 GA，底层同时挂载 OpenAI CUA 和 Claude Sonnet 4.5，每一步操作经 Purview 审计日志记录，按 5 个 Copilot Credit/步计费。

把这些放回成本视角，差距触目惊心：

| 指标 | 截图+视觉方案 | 无障碍树方案 | 倍数 |
|-----|-------------|------------|------|
| 10 步任务感知 token | 30,000–40,000 | 500–2,000 | **15–20×** |
| 单步延迟 | 2–5 s | <200 ms | **10–25×** |
| 可维持历史步数 | ~10 步 | 数百步 | **20×+** |
| OSWorld 成功率 | 22%–66% | ~70%+ | 反超 |

**结论一句话**：凡是把 Computer Use 当成"换个更强的模型就能解决"的团队，都会在 token 账单和 OSWorld 成功率面前碰壁。真正的杠杆是**感知层降级**——从像素退回到结构化数据。

## 八、感知决策流与选型全景图

下面这张图把自主体在每一步"如何感知"的决策路径画清楚，它是理解整套架构的关键：

```mermaid
flowchart TD
    Goal[任务指令] --> Loop{Agent Loop}
    Loop --> Route{感知决策路由器}

    Route -->|"优先: 结构化最便宜"| A11y[无障碍树<br/>UIA/AX/AT-SPI2<br/>50-200 tokens/步]
    Route -->|"浏览器场景"| DOM[DOM + ARIA<br/>Playwright 驱动<br/>确定性高]
    Route -->|"自绘/无 a11y 兜底"| Vision[截图+视觉<br/>OmniParser/UI-TARS 接地<br/>1200-5000 tokens/步]

    A11y -->|"confidence 0.95"| Exec
    DOM -->|"confidence 0.90"| Exec
    Vision -->|"confidence 0.60"| Exec

    Exec[统一动作执行层<br/>元素ID 或 坐标 注入] --> App[目标应用 GUI]
    App -->|"状态反馈"| Loop
    Loop -->|"完成判定"| Done{任务完成?}
    Done -->|否| Route
    Done -->|是| End[输出结果]

    classDef cheap fill:#d4edda,stroke:#28a745
    classDef mid fill:#fff3cd,stroke:#ffc107
    classDef costly fill:#f8d7da,stroke:#dc3545
    class A11y,DOM cheap
    class Vision costly
```

绿色路径是你要尽可能让流量走的方向，红色路径是代价最高、应作为最后兜底的分支。一个成熟自主体 80% 以上的步骤应落在绿色区域。

## 九、按场景的推荐方案

| 你的场景 | 推荐感知架构 | 推荐工具/平台 | 理由 |
|---------|------------|-------------|------|
| 企业桌面自动化（SAP/Win32 胖客户端） | 无障碍树优先 + 视觉兜底 | Windows-MCP / UFO / DirectShell | a11y 完整，token 成本低，精度高 |
| 网页 SaaS 工作流（表单/数据抓取） | DOM 锚定 | Browser-Use / Vercel Agent-Browser / Gemini | DOM 确定性远胜像素，延迟低 |
| 跨平台"随处跑"的通用自主体 | 可移植截图工具 | Claude Computer Use（Opus 4.7） | 不绑定 OS，Docker/远程 Mac 通用 |
| macOS 后台并行多任务 | 桌面原生会话 | Codex Background Computer Use | 原生并行，配置少 |
| 自绘界面/游戏/设计软件 | 视觉 grounding | OmniParser + UI-TARS | 无 a11y 无 DOM，只能靠视觉接地救精度 |
| 软件工程/修 GitHub Issue | 专用 ACI | OpenHands / SWE-agent | SWE-bench 针对性优化 |
| 高频批量化产品（变现） | 混合路由 | 自建 a11y→DOM→vision 路由 | 单任务成本压到截图方案 1/5，毛利率才立得住 |

**一句话选型原则**：能用结构化数据就绝不烧像素——DOM 能解决就别截图，无障碍树能解决就别 DOM，三者都不行才上视觉，并且一定要配 grounding 中间件降误差。

## 参考来源

1. [Computer Use Agent 的感知架构之战：截图视觉 vs 无障碍树](https://github.com/kejun/blogpost/blob/main/2026-04-27-computer-use-agent-perception-architecture-screenshot-vs-accessibility.md) — OSWorld 2026 三架构实测数据表（成功率、token/步、耗时）、DirectShell `.a11y.snap` 示例与混合路由代码
2. [Computer Use Agents 2026: Claude vs OpenAI vs Gemini](https://www.digitalapplied.com/blog/computer-use-agents-2026-claude-openai-gemini-matrix) — 三大厂商架构对赌（可移植/桌面原生/浏览器锚定）、OSWorld-Verified Q2 基准与任务可靠性矩阵
3. [Computer Use Agents：让模型直接操作你的电脑](https://www.diors.tech/blog/073-computer-use-agents) — Computer Use vs Function Calling 本质差异、OSWorld/Operator/Claude 工程实现拆解
4. [Computer Use 技术原理全解析：Codex、Claude、实在Agent 三大技术路线对比](https://blog.csdn.net/caiwuAgent/article/details/161679042) — 2026 年三路线技术原理与国产厂商跟进情况
5. [CLAW 能力评测全解 — 9 个 benchmark、5 类共识指标](https://www.ai-insight.org/reports/computer-using-agent-cua-evaluation-2026) — Operator/Computer Use/UI-TARS/Browser-Use 的 9 大评测基准与共识指标体系

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
