基于 UI-TARS 的 Computer Use 实现

567 阅读16分钟

基于 UI-TARS 多模态视觉模型,结合 MCP(模型上下文协议)构建下一代跨平台的自主感知 GUI Agent 智能体系统,抛砖引玉,和大家一起探讨 GUI Agent 的技术、场景和未来!

UI-TARS 工程详见 github.com/bytedance/U…

术语表

名词解释
GUI AgentGUI Agent(图形用户界面智能体)是一类基于多模态视觉模型驱动的人工智能系统,能够自动推理并执行与图形界面(如 PC、Web、移动 APP 等)交互的任务。它可以模拟人类用户的操作,包括点击、输入、拖拽、读取界面信息等,从而自动完成用户提出的工作任务。
UI-TARSUI-TARS 是字节跳动开源一种能够自我学习的 GUI Agent ,下一代原生 GUI 代理模型,旨在使用类似人类的感知、推理和操作功能与图形用户界面(GUI)无缝交互。与传统的模块化框架不同,UI-TARS 将所有关键组件——感知、推理、反思和记忆——集成在一个视觉语言模型(VLM)中,实现端到端任务自动化,无需预定义的工作流或手动规则。详见 字节版Operator抢跑OpenAI? 直接免费开源, 网友:怒省200美元!
Computer UseComputer Use 最早由 Anthropic 提出的一种基于 Claude 3.5 Sonnet 模型的新功能,允许 AI 与虚拟机桌面环境交互,执行操作系统级别的任务。
MCPModel Context Protocol*(模型上下文协议)* 是一个开放协议,它规范了应用程序如何为LLMs提供上下文。可以将MCP想象为AI应用的USB-C端口。就像USB-C提供了一种标准方式,让你的设备连接到各种外设和配件,MCP也提供了一种标准方式,让你的AI模型连接到不同的数据源和工具。详见 基于 MCP 的 AI Agent 应用开发实践
UI AgentsUI Agents 技术是利用大模型技术(VLM / LLM)实现智能体对手机或电脑的自动操作,模拟人类行为完成指定任务
VLMVision Language Models(视觉语言模型), 是指可同时处理视觉和语言两种模态的模型。
MLLMMLLM,Multimodal Large Language Model(多模态大型语言模型,它利用强大的大型语言模型(LLMs)作为"大脑"来执行多模态任务。MLLM 的惊人涌现能力,如基于图像编写故事和无需 OCR 的数学推理。
SSEServer-sent Event*(SSE,服务器发送事件)*是一种基于 HTTP 连接的技术,允许服务器实时地、单向地向客户端推送数据。对于服务器只需要向客户端推送数据,而不需要从客户端接收数据的场景,它是 WebSockets 的一个简单且高效的替代方案。
VNCVNC(虚拟网络计算)是一种图形桌面共享系统,它使用远程帧缓冲区协议(RFB)远程控制另一台计算机。它通过网络将键盘和鼠标输入从一台计算机传输到另一台计算机,中继图形屏幕更新。
RPA*Robotic Process Automation(机器人流程自动化)*是一类流程自动化软件工具,通过用户界面使用和理解企业已有的应用,将基于规则的常规操作自动化。
HITLHuman-in-the-loop(HITL) 指需要和人进行交互的模型。其中人类判断被集成到自动化过程中,从而增强了人工智能系统的功能。

背景

为什么需要 GUI Agent?

人类使用电子设备的本质方式是什么?

  1. 视觉感知:通过眼睛观察和理解屏幕上的内容

  2. 手指操作:通过点击、滑动等手势与界面交互

  3. 目标导向:基于任务目标规划一系列操作步骤

2.png

GUI Agent 正是基于第一性原理,模拟人类使用电子设备的方式,实现真正的原生端到端的通用自动化。


Demo 演示

使用设备指令录屏
本地电脑(Computer Use)Please help me open the autosave feature of VS Code and delay AutoSave operations for 500 milliseconds in the VSCode setting(请帮我开启 VSCode 的自动保存功能,并在设置中将自动保存操作延迟500 毫秒)链接
本地浏览器(Browser Use)Could you help me check the latest open issue of the UI-TARS-Desktop project on Github? (你能帮我查看 Github 上 UI-TARS-Desktop 项目的最新未解决 issues 吗?)链接
远程虚拟机(Remote Computer)识别小票内容并整理到Execl链接
远程浏览器(Remote Browser)麦当劳点一个巨无霸套餐送到鼎好链接
电视(TV Use)播放长安的荔枝第 5 集链接

更多 showcases 见:seed-tars.com/showcase

详细设计

整体概览

要完成 GUI Agent 系统,需要用到三个核心构件:

  1. VLM(视觉模型): 负责理解屏幕内容和用户指令,根据用户指令+截图,生成自然语言指令(NL Command)。

  2. Agent Operator(代理操作):根据用户指令,调用模型、并通过 MCP Client 来调用设备能力。本质是个流程 workflow,通过 MCP 架构解耦了 LLM 在获取不同上下文的逻辑。

  3. Devices(外部设备):以 MCP Services 包提供出来,可以是 PC、Mobile、虚拟机、树莓派等,只要是电子设备都是外设,都可以接入 GUI Agent 系统中。


流程链路

GUI Agent 核心流程大致分为:

  1. 任务感知:系统接收用户通过自然语言或截图输入的指令,利用多模态模型解析并输出 NLCommand(例如:Action: click(start_box='(529,46)'))。

  2. 坐标映射:将模型感知的像素坐标转成屏幕坐标

  3. 指令转换:将解析后的 NLCommand 转换为可执行的 Command,中间涉及到一个坐标系的转换,将图像坐标系转成屏幕坐标系,为后续的执行做准备。

  4. 命令执行:调用 MCP Services,将转换后的命令进行执行

Agent 逻辑

GUI Agent 在 Agent 层主要是一个 Loop 循环逻辑,根据任务执行情况向客户端推送截图、模型输出、Action 等,所以只需要实现以下逻辑:

import { GUIAgent } from '@ui-tars/sdk';
import { NutJSOperator } from '@ui-tars/operator-nut-js';

const guiAgent = new GUIAgent({
  model: {
    baseURL: config.baseURL,
    apiKey: config.apiKey,
    model: config.model,
  },
  operator: new NutJSOperator(),
  onData: ({ data }) => {
    console.log(data)
  },
  onError: ({ data, error }) => {
    console.error(error, data);
  },
});

await guiAgent.run('send "hello world" to x.com');

Operator 可任意替换成对应操作工具 / 框架,例如:浏览器控制(operator-browser)、Android 设备控制(operator-adb)等

Responses API 增量推理

为了避免在一次请求中向模型 API 发送过多截图,我们在工程上引入了 Responses API(即支持上下文状态管理的模型请求方式)。通过该 API,我们可以在每一轮推理中增量发送一张截图,实现高效且稳定的多模态交互。

Responses API 优势主要体现在两点:

  • 增量推理能力:借助 KV-Cache 机制,模型仅需处理当前轮的注意力计算,哪怕是 100+ 轮对话,也能保持秒级响应
  • 对话状态托管:API 自动维护多轮上下文,无需在单次请求中重复传入大量图像,有效规避网关限制问题(如一次传入 10+ 张图像导致的请求体过大)。

任务感知(多模态模型)

由 UI-TARS 模型提供,定义 System Prompt,通过传入『截图』和『任务指令』,返回用于自然语言的++操作二元组(NLCommand)++,这样的好处在于和不同设备操作指令进行++解耦++。

以 PC MCP Server 提供的 System Prompt 为例:

You are a GUI agent. You are given a task and your action history, with screenshots. You need to perform the next action to complete the task.

## Output Format
```
Action_Summary: ...
Action: ...
```

## Action Space

click(start_box='[x1, y1, x2, y2]')
left_double(start_box='[x1, y1, x2, y2]')
right_single(start_box='[x1, y1, x2, y2]')
drag(start_box='[x1, y1, x2, y2]', end_box='[x3, y3, x4, y4]')
hotkey(key='')
type(content='') #If you want to submit your input, use "\n" at the end of `content`.
scroll(start_box='[x1, y1, x2, y2]', direction='down or up or right or left')
wait() #Sleep for 5s and take a screenshot to check for any changes.
finished()

## Note
- Use Chinese in `Action_Summary` part.

## User Instruction
{instruction}

模型输出的字段说明:

  • Action_Summary :操作的自然语言描述,带进多轮步骤
  • Action操作名(参数)的元组

我们以 PC 端上『打开 Chrome 浏览器』任务为例,截图尺寸是 2560 x 1440,模型输出的是 Action: left_double(start_box='(130,226)')

3.png

为什么 System Prompt click 是 [x1, y1, x2, y2] 两个坐标,而不直接返回一个坐标? 早期 UI-TARS 多模态模型并不只针对 Computer Use 场景进行训练,而是在物体检测(Object Detection)、识别理解等,生成对应框 Box(x1, y1, x2, y2)。 面向 Computer Use 场景时,x1=x2 时直接复用当成同一点位,不相等时取中心点 (x1+x2)/2


坐标映射

还是以上面的『打开 Chrome』为例:图像相对坐标**(130,226)是怎么算出最终的屏幕绝对坐标为:(332,325)**。


参数说明:

  • NLCommand(操作指令):模型输出的操作和坐标,模型在训练和推理时输出的是 0~1000 之间的坐标
  • factor(缩放因子):目前值为 1000(因为 UI-TARS 模型训练的坐标系是 1000x1000),对应 UI-TARS 模型输出的坐标值范围
  • width(屏幕宽度):2560px
  • height(屏幕高度): 1440px

相对坐标和绝对坐标

屏幕上的位置由 X 和 Y 笛卡尔坐标表示。X 坐标从左边的 0 开始,向右增加。与数学不同的是,Y 坐标从顶部的 0 开始,向下增加。

UI-TARS 模型的坐标系:
0,0       X increases -->
+---------------------------+
|                           | Y increases
| *(130, 226)               |     |
|   1000 x 1000 screen      |     |
|                           |     V
|                           |
|                           |
+---------------------------+ 999, 999

相对坐标:(0.02, 0.247)

映射到实际屏幕的坐标系上:
0,0       X increases -->
+---------------------------+
|                           | Y increases
| *(332, 325)               |     |
|   2560 x 1440 screen      |     |
|                           |     V
|                           |
|                           |
+---------------------------+ 1919, 1079


指令转换

不同设备都有特定的操作指令(又可以称为动作空间),通过不同设备 operator 对应 NLCommand 转成对应设备的操作指令。

目前支持的动作空间如下:

# PC
PC = Enums[
    "hotkey",        # 键盘按键
    "type",          # 键盘输入文本
    "scroll",        # 鼠标滚动
    "drag",          # 拖拽
    "click",         # 左键点击
    "left_double",   # 左键双击
    "right_single",  # 右键点击
]

# Android 手机
Mobile = Enums[
    "click",         # 单击
    "scroll",        # 上下左右滑动
    "type",          # 输入
    "long_press",    # 长按
    "KEY_HOME",      # 返回 Home
    "KEY_APPSELECT", # APP 切换
    "KEY_BACK",      # 返回
]

不同的设备操作需要模型增加对应的训练数据,才能更好地完成对应的任务。

这一步现在有 SDK 可直接使用 @ui-tars/action-parser,调用方式见用例


命令执行

拿到具体执行命令后,直接调用对应设备 MCP 的 execCommand 内部的方法,PC 和手机在执行远程命令执行时的流程图如下:

SDK(开发者工具)

如果对以上流程实现感到繁琐,可以使用 UI-TARS SDK 快速实现:

MCP Servers

UI-TARS 相关的 Operator 工具也支持以 MCP Server 方式提供使用:

  • Browser Operator:@agent-infra/mcp-server-browser --vision 开启

思考

当前基于视觉模型的 GUI Agent 方案,第一反应想到的是 Tesla FSD 自动驾驶的技术架构演进。

5.png

前提假设:人是通过眼睛(视觉)看到系统 UI 就可以操作,那 AI 也可以通过视觉达成。 达成条件:无限数据 + 大规模算力,直到解决所有边界 case。


基于视觉的 GUI Agent,在技术演进上的好处在于:

  • 训练数据易准备:只需要『指令』和『视觉图像』,大幅度减轻了模型训练数据处理和清洗的流程。
    • 如果输入再加上一个『DOM 结构』就会让模型训练陷入没有数据的困境中。
  • 跨端设备易集成:设备只需要提供截图和操作两个接口,不需要获取内部 DOM 结构,方便了不同设备进行集成。

不好的点在于:

  • 精准度不够:仅通过视觉就丢失了 UI 界面的层次结构(例如叠在后面的窗口、不在当前视窗的页面内容等),会造成对应的操作失准。

  • 延迟高:对指令+截图的推理和识别,需要模型有更强大的推理能力,同时在执行命令时,视觉方案会转换成指令系统(pyautogui 等)进行操作,中间链路过长。


应用场景

Agentic User Testing

像人操作一样去测试应用和产品。例如 TestDriver 是一个为 GitHub 设计的异步自动化测试,可以智能生成测试用例,通过模拟真实用户行为,提供比传统基于选择器的框架更广泛的测试覆盖,支持桌面应用程序、Chrome 扩展程序、拼写和语法、OAuth 登录、PDF 生成等多种功能测试。

6.png

由此可利用 Computer Use 进行端到端的功能验证,包括检查布局完整性、元素响应情况及视觉一致性。模型能快速指出界面问题,减少人工检查工作量,检查项包括:

  • 功能可用性(Availability):通过自然语言(例如:『PRD 文档』+『前端系分文档』),
  • 视觉一致性(Consistency):和**『设计稿』**是否一致,通过 CV 图像识别 + 模型操作后的日志,得到结论
  • 可访问性(Accessibility):无障碍检查

Schedule Tasks 定时任务

根据 ChatGPT Tasks 功能,可以实现『每天早上 9 点半自动打卡』的需求

7.png


C 端消费级

Computer Use 在 C 端消费级还不具备上线条件,要使用起来要解决几个问题:

  • 整体响应耗时:全链路端到端做不到毫秒级,C 端商业化落地就非常困难。整体使用体验会非常割裂。
  • 设备权限:截图和执行命令都是非常高的权限,除非一开始系统层内置 Computer Use。所以在 Demo 时采用了设备虚拟机,这样就有了最高权限。
  • 生态集成:目前生态怎么接入 Agent 中,似乎还有共识,不过从 MCP 中看到可以标准化接入的趋势。

例如:让 AI 给我发个红包、买杯咖啡等,和直接使用 UI 操作并没有多大优势。 暂时没想到好的落地场景,更多是以『iOS 捷径』RPA 方式。未来 Computer Use 如果以 Agent 作为流量入口,通过 MCP 来集成生态(例如吃喝玩乐 APP、README 应用说明书等),倒是很有想象力。


未来

愿景

从 2013 年上映的《Her》电影来看,AI 帮人类操作计算机完成任务的科幻场景,在一步步成为现实。

9.png

10.png


新一代人机交互范式

Human-in-the-loop

当 GUI Agent 无法处理需要人帮助时,将控制权交换给人类。 这就有点像『完全自动驾驶』里的『安全员』,当 AI 能力无法处理时,人进行参与,收集边界 case 数据,不断迭代 AI。

11.png

Bot-to-Bot 交互

  • 与 AI 系统进行协同和交互
  • 跨平台、跨系统任务传递

12.png

GUI Agent 用 AI Coding 生成贪吃蛇游戏


Q & A

为什么需要 AI 帮我操作设备?

起初我也有这个问题,AI 点咖啡不如我手动点几下,又快又不会出错。

长期来看:

  • 基于『人会越来越来懒』和『AI 越来越强』这两个认知前提下,模型能力发展到达临界点,Computer/Phone Use 会极大提升用户体验。

  • 那时候『人操作设备』就像『蒸汽机时代下使用马车』、『完全自动驾驶下人工』,那一天,我们会问**『为什么需要人自己操作设备?而不是用 AI』**



按自动驾驶行业的标准,GUI Agent 分级为:

分级名称定义任务参与度任务场景
L0无自动化操作任务完全由人类控制,自动系统不执行任何操作。所有
L1基本计算机辅助计算机提供某些辅助功能,如自动化工具或建议,但最终决策仍由用户做出。有限(例如:自动拼写检查、简单的数据输入自动填充)
L2(当前)计算机辅助执行(Copilot 阶段)计算机可以在特定任务中执行某些操作,但用户仍需干预或监督。人(80%) + AI(20%)有限。例如:需要用户调整
L3部分自动化(Agent 阶段)计算机可以在更多情况下独立执行任务,但仍需要用户在特定情况下介入。AI(50%) + 人(50%)有限
L4高度自动化计算机在大多数任务场景中能够自动处理,用户仅在特定情况下进行监督。AI(80%) + 人(20%)有限
L5完全自动化计算机完全自主完成任务,用户无需干预或操作。AI(100%)所有

和 RPA 的区别?

GUI Agent 是在接受『任务指令』后列出行动计划,并根据『实时的屏幕变化』进行下一步的思考、计划和操作。可以对++未知的界面++进行主动探索和试错;而 RPA 更多的是流程固定化操作,这是巨大的差异。 例如:界面突然弹窗,GUI Agent 是可以处理点『同意』或『不同意』

16.png

参考

MCP 相关:

相关论文: