UI-TARS Desktop 实测：字节的多模态 Agent 怎么用截图操作电脑

公司有个老系统，没 API，没文档，每天手动录数据录到想辞职。写 RPA 脚本吧，页面一改就全崩。Selenium 抓元素吧，这系统是 Canvas 画的，DOM 里啥也没有。

上周试了字节开源的 UI-TARS Desktop，用了三天。说说真实体验。

这东西干什么的

UI-TARS Desktop 是字节跳动开源的 GUI 自动化 Agent。核心思路很简单：给 AI 看屏幕截图，告诉它你要干什么，它自己点鼠标、敲键盘。

跟传统 RPA 的区别在于，它不需要提前录制操作路径，不依赖 DOM 结构，也不用写 XPath。它看截图就能识别按钮在哪、输入框在哪，跟人看屏幕的方式一样。

GitHub 上 35k+ star，Apache 2.0 协议，仓库里有两个子项目：

Agent TARS：开发者用的通用 Agent，CLI + Web UI，支持 MCP 工具
UI-TARS Desktop：桌面应用，Electron 写的，用来控制本地或远程电脑

底层模型是 UI-TARS 系列 VLM（Vision-Language Model），7B 参数起步，专门为 GUI 理解训练过。

架构拆解：三种浏览器控制策略

UI-TARS 最有意思的设计是它的混合浏览器 Agent。不像 Playwright 只能操作 DOM，也不像纯截图方案只能点坐标，它同时支持三种策略，运行时自动切换。

GUI Agent 模式（纯视觉）

截图 → VLM 识别 → 输出像素坐标 → 模拟点击。最通用，Canvas、Flash、任何界面都能用。缺点是每步都要跑一次 VLM 推理，慢。

ini 复制代码

截图 → VLM 推理 → click(start_box='(27,496)') → 执行

DOM 模式（结构化交互）

跳过截图，直接读页面 DOM 树、accessibility tree，用 Playwright API 操作元素。快，但碰上没有语义标签的页面就抓瞎。

混合模式（推荐）

DOM 能用就用 DOM，DOM 不行就切视觉。一个任务里可以来回切。比如填表单用 DOM 模式，验证码用视觉模式。

策略选择靠 context engineering pipeline 决定，不需要手动配。我跑了几个测试任务，填表单基本全走 DOM，碰到一个 SVG 图表就自动切到视觉模式，确实能感知到速度差异------DOM 模式一步几十毫秒，视觉模式一步要 2-3 秒。

本地部署：从零跑起来

Agent TARS 最快的方式，一行命令：

bash 复制代码

npx @agent-tars/cli@latest

默认用 Doubao 模型。想用 Claude：

bash 复制代码

export ANTHROPIC_API_KEY=sk-ant-xxx
npx @agent-tars/cli@latest --model claude-opus-4-6

带 Web UI 启动：

bash 复制代码

npx @agent-tars/cli@latest --ui

浏览器打开后就是个对话框，输入自然语言指令，右侧实时显示屏幕截图和 Agent 的操作过程。

如果要用 UI-TARS Desktop 桌面应用：

bash 复制代码

git clone https://github.com/bytedance/UI-TARS-desktop.git
cd UI-TARS-desktop
pnpm install
pnpm run dev:desktop

也可以去 Releases 页面直接下 dmg 或 exe。

想本地跑模型不走 API，可以用 LM Studio 加载 UI-TARS-1.5-7B：

bash 复制代码

# LM Studio 启动后，加载 UI-TARS-1.5-7B-Q4_K_M
npx @agent-tars/cli@latest \
  --provider lm-studio \
  --model.id ui-tars-1.5-7b \
  --model.baseURL http://localhost:1234/v1

7B 量化版 4GB 显存就能跑，RTX 4060 够用。

实际效果：Benchmark 数据

不看跑分不踏实。UI-TARS 2 的成绩单（2025 年 9 月版本，23B active 参数 / 230B MoE）：

基准测试	UI-TARS 2	Claude Computer Use	OpenAI Operator
OSWorld (50步)	47.5%	22.0%	38.1%
AndroidWorld	73.3%	~35%	-
WebVoyager	84.8%	56%	87%
SWE-Bench	68.7%	-	-

OSWorld 成绩是 Claude 的两倍多。坐标定位准确率 ScreenSpot-V2 拿到 94.2%------点按钮时，100 次里 94 次点对位置。

不过这是 72B 满参数的成绩。本地跑 7B 量化版，体感准确率大概 80% 出头，复杂页面会差一些。

MCP 集成：不止截图点点点

Agent TARS 原生支持 MCP（Model Context Protocol），能同时连多个 MCP server：

bash 复制代码

npx @agent-tars/cli@latest \
  --mcp-server filesystem \
  --mcp-server github \
  --mcp-server postgresql

这意味着 Agent 能在"看屏幕操作"和"直接调 API"之间灵活切换。比如你让它"查数据库里上周的订单数据，做个图表贴到 PPT 里"，查数据走 PostgreSQL MCP，操作 PPT 走 GUI。

SDK 扩展：写自己的 Operator

SDK 的核心接口就两个方法：

typescript 复制代码

import { GUIAgent, Operator } from '@ui-tars/sdk';

class MyCustomOperator implements Operator {
  // 截取当前屏幕
  async screenshot(): Promise<Buffer> {
    // 你的截图逻辑
    return screenshotBuffer;
  }

  // 执行 VLM 预测的操作
  async execute(action: ParsedAction): Promise<void> {
    switch (action.type) {
      case 'click':
        await myClickHandler(action.x, action.y);
        break;
      case 'type':
        await myTypeHandler(action.text);
        break;
      case 'scroll':
        await myScrollHandler(action.direction);
        break;
    }
  }
}

// 用你的 Operator 启动 Agent
const agent = new GUIAgent({
  operator: new MyCustomOperator(),
  model: {
    baseURL: 'https://api.example.com/v1',
    apiKey: 'your-key',
    model: 'ui-tars-1.5-7b'
  }
});

await agent.run('打开设置页面，把语言改成中文');

仓库里已经内置了四种 Operator：

Desktop Operator：nut.js，控制本地桌面
Browser Operator：Playwright，控制浏览器
ADB Operator：连 Android 设备
AIO Sandbox Operator：隔离环境跑不可信代码

写新 Operator 不需要改 Agent 循环逻辑，实现两个方法就行。

Event Stream：调试利器

传统 Agent 出问题只能看对话日志猜。UI-TARS 用 Event Stream 协议，每步操作都记录完整事件：

css 复制代码

[Screenshot Event] → [User Instruction] → [Thinking] → [Tool Call] → [Result] → [New Screenshot]

Web UI 里有个 Event Stream Viewer，能看到每一步的截图、VLM 的推理过程、执行的操作、操作后的截图。调试时这个东西价值巨大，能精确定位是"看错了"还是"点歪了"还是"理解错指令了"。

踩坑记录

用了三天踩的坑，分享出来：

1. Context Window 要调大

用 LM Studio 跑本地模型时，默认 context window 太小。UI-TARS 每步要传截图 + 历史操作 + 指令，token 消耗很大。建议调到 8192 以上，否则多步任务到后面会丢失前面的操作记忆。

2. 屏幕分辨率影响准确率

4K 屏幕下模型的坐标预测会偏。UI-TARS SDK 内部做了 DPR（Device Pixel Ratio）缩放，但本地 7B 模型在高分辨率下表现明显比 1080p 差。我的解决办法：把分辨率临时调到 1920x1080 再跑。

3. macOS 权限问题

Desktop Operator 需要"辅助功能"权限才能模拟键鼠操作。第一次跑会弹授权窗口，授权后要重启应用才生效。这个在 README 里没写清楚，我卡了半小时。

4. 多步任务容易漂移

超过 10 步的复杂任务，Agent 容易"忘记"最初的目标，开始在页面上乱逛。UI-TARS 1.5 加了 System-2 reasoning 做反思，但 7B 模型的反思能力有限。我的做法是把大任务拆成 3-5 步的小任务分批执行。

5. 中文输入法冲突

模拟键盘输入时，如果系统输入法状态是中文，type('hello') 会变成拼音输入。需要在 Operator 里加一步切换输入法的操作，或者用剪贴板粘贴代替键盘输入。

跟 RPA 和 Playwright 的定位对比

三者不是替代关系，是互补的：

Playwright/Selenium：Web 自动化首选，速度快、稳定、生态好。但只能操作浏览器，需要写代码。
传统 RPA（UiPath）：企业级 GUI 自动化，商业授权，录制+拖拽编程。UI 一变就要维护。
UI-TARS：自然语言驱动，不怕 UI 变动，能操作任何带 GUI 的软件。但速度慢，准确率目前还不到 100%。

实际项目里我的选择标准：有 API 用 API，有稳定 DOM 用 Playwright，既没 API 也没稳定 DOM 的遗留系统用 UI-TARS。

值不值得用

如果你的场景是：操作没有 API 的老旧系统、跨应用的桌面工作流、或者需要快速原型验证一个自动化想法，UI-TARS 值得试。一行 npx 命令就能跑起来，不需要写脚本、不需要分析 DOM。

如果你需要的是高频、高可靠的生产级自动化，现阶段还不够稳。94.2% 的坐标准确率听着高，但跑 20 步的任务，每步 94% 的话整体成功率只有 30%（0.94^20 ≈ 0.29）。这个数字在真正的生产环境里不够看。

但这是个快速进化的项目。从 1 月发布到 9 月，OSWorld 成绩从 24.6% 涨到 47.5%，不到一年翻了一倍。按这个速度，明年的生产可用性会好很多。

仓库地址：github.com/bytedance/UI-TARS-desktop