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 下的是完全不同的赌注，这直接决定了你能拿它们干什么：
记住一句话：选 Computer Use 不是选模型，是选部署形态。需要跨平台到处跑选 Claude，需要 macOS 后台并行选 Codex，需要纯网页自动化选 Gemini。
这是当下最主流的方案，也是 Operator、Claude Computer Use、Mariner 的共同底座。流程很直白：截屏 → 嵌入多模态 Prompt → LLM 输出坐标与动作 → 输入注入执行 → 循环。核心代码骨架长这样：
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 走，不存在坐标偏差：
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 最贵、无障碍树最完整的地方。把无障碍树路线包装成"非侵入式桌面自动化"，客单价和续费率都远高于截图套壳产品。
截图路线并非没有救。微软 OmniParser 和字节 UI-TARS 这类"视觉接地中间件"，专门解决一个具体痛点：原始多模态模型不知道该点哪。它们把截图解析成结构化的元素列表加边界框，再喂给推理模型。
这一层把"像素 → 可点击区域"的不确定性从 LLM 身上卸下来，交给一个专门的小模型。UI-TARS 2.0 正是靠这套机制把 OSWorld 拉到 47.5%。代价是多了一级推理阶段，延迟和成本上升，但精度提升往往值得。
适用场景：当目标应用没有无障碍树（比如游戏化界面、设计软件画布），又不能用 DOM 时，视觉 grounding 是唯一能救回精度的手段。它是截图路线的"补丁"，不是替代品。
成熟的落地系统几乎没人纯走一条路。生产级架构是感知决策路由器：优先无障碍树，浏览器场景用 DOM，最后才 fallback 到截图：
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 成功率面前碰壁。真正的杠杆是感知层降级——从像素退回到结构化数据。
下面这张图把自主体在每一步"如何感知"的决策路径画清楚，它是理解整套架构的关键：
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 中间件降误差。
.a11y.snap 示例与混合路由代码[!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 等场景全覆盖。