UI-TARS 源码解析 #4：UI-TARS 与传统 RPA 的区别：为什么它不是简单的坐标点击脚本？

在前几篇文章中，我们已经从三个角度认识了 UI-TARS：

第一篇，我们讲了 GUI Agent 是什么，为什么 AI 开始具备"看屏幕、点按钮"的能力。

第二篇，我们梳理了 UI-TARS 仓库结构，明确它主要开源的是 Prompt、动作解析、坐标转换和 pyautogui 代码生成这一套推理后处理链路。

第三篇，我们分析了论文中的三个核心思想：

复制代码

Enhanced Perception
Unified Action Modeling
System-2 Reasoning

这一篇，我们换一个角度看 UI-TARS：

UI-TARS 和传统 RPA 到底有什么区别？

它为什么不是简单的坐标点击脚本？

如果最终也是调用 pyautogui 点击鼠标，它和普通自动化脚本有什么本质不同？

这是很多人第一次接触 UI-TARS 时最容易产生的误解。

因为从结果看，它确实也会输出：

复制代码

click
type
scroll
hotkey
drag

这些动作最后也会变成鼠标键盘操作。

但问题在于：

传统 RPA 的核心是"录制和回放"，UI-TARS 的核心是"观察、理解、推理和行动"。

这两者看起来都在操作界面，但底层逻辑完全不同。

一、传统 RPA 是怎么工作的？

传统 RPA，简单说就是把人的操作流程固化下来。

例如，一个财务人员每天都要做这件事：

复制代码

打开 ERP 系统
登录账号
点击报表菜单
选择昨天日期
导出 Excel
发送给主管

传统 RPA 的做法通常是：

复制代码

录制操作
    ↓
保存步骤
    ↓
设置固定规则
    ↓
定时回放

它可能会记录：

复制代码

点击第一个按钮
等待 2 秒
输入账号
点击登录
等待页面加载
点击坐标 820, 360
选择日期
点击导出

这种方式在稳定环境下很好用。

如果界面永远不变、按钮位置固定、网络速度稳定、弹窗不会乱出现，那么传统 RPA 可以非常高效。

但它有一个天然问题：

它不是真的理解界面，只是在按流程执行。

二、坐标脚本最大的问题：环境一变就失效

假设你录制了一个自动化脚本：

复制代码

点击 800, 300
等待 1 秒
点击 950, 500
输入内容
点击 1200, 700

今天可以运行。

但明天可能因为下面任何一个原因失败：

复制代码

窗口位置变了
分辨率变了
软件升级了
按钮位置挪了
页面多了一个弹窗
网络卡顿导致页面没加载完
主题颜色变了
语言切换了
表格多了一行
菜单折叠了

这时候脚本仍然会机械地点击原来的坐标。

它不会知道：

复制代码

我点错了
按钮已经不在这里了
页面还没加载出来
现在有个弹窗挡住了
用户真正想点的是"导出"按钮

所以，传统 RPA 常常需要大量异常处理。

比如：

复制代码

如果出现弹窗，就关闭
如果按钮找不到，就重试
如果页面没加载，就等待
如果坐标偏移，就重新录制

这些规则越写越多，自动化流程就越来越脆弱。

三、UI-TARS 的出发点不是"录制"，而是"理解"

UI-TARS 的定位完全不同。

论文中明确说，UI-TARS 是一个 Native GUI Agent Model，它只依赖截图作为输入，并执行类似人类的键盘和鼠标操作。也就是说，它不是通过 DOM、Accessibility Tree、插件接口或后台 API 来理解软件，而是像人一样看当前屏幕，再决定下一步做什么。

这就和传统 RPA 形成了根本差异。

传统 RPA 的思路是：

复制代码

我之前怎么做
现在就怎么重复

UI-TARS 的思路是：

复制代码

我现在看到了什么
当前任务进行到哪一步
下一步应该操作哪个界面元素
该用什么动作完成

这就是 GUI Agent 和录制脚本之间最大的区别。

一个是流程复现。

一个是实时决策。

四、传统 RPA 依赖"固定流程"，UI-TARS 依赖"当前状态"

传统 RPA 的执行逻辑通常是线性的：

复制代码

Step 1
Step 2
Step 3
Step 4
Step 5

它假设每一步都会按预期发生。

但 UI-TARS 更像一个循环：

复制代码

截图
  ↓
观察界面
  ↓
思考下一步
  ↓
输出动作
  ↓
执行动作
  ↓
重新截图
  ↓
继续判断

这意味着 UI-TARS 的每一步都不是简单执行预设命令，而是基于当前屏幕状态重新判断。

例如，用户任务是：

复制代码

帮我导出今天的销售报表

传统 RPA 可能固定执行：

复制代码

点击菜单 A
点击按钮 B
输入日期
点击导出

而 UI-TARS 更接近：

复制代码

我看到当前页面是登录页，所以先登录。
我看到登录成功后进入首页，所以寻找报表菜单。
我看到报表菜单在左侧导航栏，所以点击它。
我看到日期选择器，所以输入今天日期。
我看到导出按钮，所以点击导出。
我看到下载完成提示，所以任务结束。

也就是说，UI-TARS 的动作是由"当前观察 + 用户目标"动态生成的。

五、UI-TARS 不是不点击坐标，而是不"死记坐标"

这里要特别澄清一个误区。

UI-TARS 最后确实也会输出坐标。

比如：

复制代码

Action:
click(point='<point>200 300</point>')

或者经过解析后变成：

复制代码

pyautogui.click(x, y)

所以有人会说：

这不还是坐标点击吗？

问题在于：

坐标只是最终执行形式，不是决策来源。

传统坐标脚本是：

复制代码

因为录制时点过 200,300，所以现在继续点 200,300。

UI-TARS 是：

复制代码

因为我看到"导出"按钮在这个位置，所以现在点击这个位置。

两者表面都是点击坐标，但来源完全不同。

前者是记忆坐标。

后者是理解界面后生成坐标。

这就像人类操作电脑时，也是在点击坐标。但人不是记住"导出按钮永远在 934, 512"，而是看到按钮在哪里，就把鼠标移动到哪里。

UI-TARS 模型的核心价值也在这里：它把自然语言任务和当前截图中的目标元素联系起来，再把目标元素映射成动作坐标。

六、UI-TARS 的 Prompt 已经体现出 Agent 思维

从 UI-TARS 的 prompt.py 可以看到，它并不是让模型随便输出一段文字，而是要求模型按照固定格式输出：

复制代码

Thought: ...
Action: ...

其中桌面端 COMPUTER_USE 模板支持点击、双击、右键、拖拽、快捷键、输入、滚动、等待和完成等动作；移动端模板还增加了长按、打开 App、返回主页、返回上一级等移动端动作。

这说明 UI-TARS 的动作不是录制出来的一串坐标，而是一个标准化动作空间：

复制代码

click
left_double
right_single
drag
hotkey
type
scroll
wait
finished

更重要的是，它要求模型先写 Thought。

例如：

复制代码

Thought:
我需要先找到页面右上角的搜索框，并点击它以输入关键词。

Action:
click(point='<point>850 120</point>')

这个 Thought 体现的是"为什么要做这个动作"。

传统 RPA 通常只有动作，没有理由。

UI-TARS 则把"观察、意图、动作"绑定在一起。

七、传统 RPA 的动作来自人，UI-TARS 的动作来自模型

传统 RPA 里的动作通常来自人工录制。

也就是说，系统并不知道为什么这一步要点击这里。

它只知道：

复制代码

用户当时点击了这里。

而 UI-TARS 的动作来自模型推理。

模型看到截图后，需要自己判断：

复制代码

当前界面是什么？
任务目标是什么？
哪个元素和目标相关？
应该点击、输入、拖拽还是等待？
动作完成后可能发生什么？

论文把这类能力归纳为 Enhanced Perception、Unified Action Modeling 和 System-2 Reasoning：前者让模型理解 GUI 元素和界面上下文，中间让不同平台动作统一到一个动作空间，后者让模型在多步骤任务中进行任务分解、反思和里程碑识别。

这就是为什么 UI-TARS 更接近"Agent"，而不是"脚本"。

八、UI-TARS 的工程链路：文本动作到可执行代码

当然，光有模型推理还不够。

模型输出的是文本。

操作系统需要的是具体鼠标键盘事件。

所以 UI-TARS 仓库里非常重要的一部分，就是把模型输出解析成可执行代码。

codes/README.md 里说明，ui-tars 是一个 Python 包，用来把 VLM 生成的 GUI 动作指令解析成可执行的 pyautogui 代码，并支持坐标转换和智能图像缩放。

整体链路可以理解为：

复制代码

模型输出：
Thought: 点击导出按钮
Action: click(point='<point>200 300</point>')

        ↓

结构化动作：
{
  "action_type": "click",
  "action_inputs": {
    "start_box": ...
  },
  "thought": ...
}

        ↓

pyautogui 代码：
pyautogui.click(x, y)

从源码看，parse_action 会使用 Python AST 解析 action 字符串，parse_action_to_structure_output 会处理 point、start_point、end_point 到 start_box、end_box 的格式转换，parsing_response_to_pyautogui_code 则把结构化动作转成 pyautogui 脚本。

这一步非常关键。

它把"不稳定的模型文本输出"变成了"程序可以消费的结构化动作"。

传统 RPA 通常是人先定义动作，程序直接执行；UI-TARS 则是模型先生成动作，再由 parser 统一解析、校验和转换。

九、坐标缩放也说明它不是普通点击脚本

传统坐标脚本通常直接保存屏幕坐标：

复制代码

x = 800
y = 300

但 UI-TARS 必须处理一个更复杂的问题：

模型看到的图片尺寸，可能和真实屏幕尺寸不一样。

例如：

复制代码

真实屏幕：1920 × 1080
模型输入图像：经过 resize
模型输出坐标：基于缩放后的图像
最终执行：必须还原到真实屏幕

所以源码中有 smart_resize、坐标归一化、坐标还原等逻辑。

smart_resize 的注释说明，它会在保持宽高比的基础上，让图片尺寸满足特定因子整除，并让总像素数落在最小和最大像素范围内。

这和普通坐标点击完全不同。

普通脚本假设：

复制代码

坐标就是坐标。

UI-TARS 必须考虑：

复制代码

模型输入尺寸
原始截图尺寸
坐标归一化
模型类型
真实屏幕映射

所以它不是"点某个死坐标"，而是"把模型理解到的位置映射回真实屏幕"。

十、传统 RPA 处理异常靠规则，UI-TARS 处理异常靠重新观察

传统 RPA 面对异常，一般靠预设规则。

比如：

复制代码

如果出现"错误"弹窗，点击确定
如果 10 秒没加载，刷新页面
如果找不到按钮，重新打开窗口

这种方式的问题是，规则永远写不完。

真实软件环境太复杂：

复制代码

弹窗文案可能变化
按钮可能换位置
页面可能加载一半
账号可能被踢下线
浏览器可能提示保存密码
文件名可能重复
权限可能不足

UI-TARS 的思路更像人。

当执行动作后，它会重新截图，再根据新界面判断下一步。

例如：

复制代码

我点击了导出按钮，但页面出现权限提示。
下一步应该关闭提示，或者提示用户没有权限。

我输入了关键词，但搜索结果没有出现。
下一步应该等待，或者检查输入框是否真的获得焦点。

我点击了登录按钮，但仍停留在登录页。
可能账号密码错误，需要重新检查提示信息。

这就是 Agent 闭环。

它不是提前穷举所有异常，而是每一步都重新观察环境。

当然，这并不代表 UI-TARS 一定不会失败。官方 README 也提到，UI-TARS-1.5 仍可能在模糊或陌生环境中产生不准确描述、误识别 GUI 元素或采取次优动作。

但它的失败模式和传统 RPA 不同。

传统 RPA 是"流程断了"。

UI-TARS 是"理解错了"或"推理错了"。

前者靠重录和规则修复，后者靠更好的模型、Prompt、反馈、约束和安全机制修复。

十一、传统 RPA 更适合稳定流程，UI-TARS 更适合动态界面

这并不是说 UI-TARS 一定比传统 RPA 全面更好。

两者适合的场景不同。

传统 RPA 适合：

复制代码

流程固定
界面稳定
输入输出规则明确
异常情况少
对确定性要求高
已有成熟系统集成

例如：

复制代码

固定格式报表导出
批量录入标准字段
定时下载账单
内部系统重复操作

UI-TARS 更适合：

复制代码

界面变化较多
任务目标用自然语言描述
步骤不完全固定
需要看屏幕判断状态
需要跨软件操作
需要一定推理能力

例如：

复制代码

根据当前页面提示继续操作
在不同网站中查找信息
跨浏览器、文件管理器和办公软件完成任务
处理未知弹窗
完成多步骤桌面操作

所以，更准确的理解是：

传统 RPA 是确定流程自动化。

UI-TARS 是视觉驱动的智能操作 Agent。

十二、从开发者角度看：UI-TARS 能给自动化产品带来什么？

如果你正在做桌面自动化产品，UI-TARS 的价值不只是"替代 pyautogui"。

pyautogui 只是执行层。

真正值得借鉴的是它的架构：

复制代码

截图
  ↓
VLM 理解
  ↓
Thought + Action
  ↓
Action Parser
  ↓
坐标转换
  ↓
pyautogui 执行
  ↓
重新截图

这套架构可以给传统自动化工具增加三种能力。

第一，增加视觉理解。

不再只是找固定图片模板，而是让模型理解当前界面上有哪些元素，以及它们和任务目标的关系。

第二，增加动作抽象。

不再把自动化流程直接写成散乱脚本，而是统一成：

复制代码

click
type
scroll
drag
hotkey
wait
finished

这种可解析、可记录、可回放、可审计的动作空间。

第三，增加推理闭环。

不再假设每一步都会成功，而是在每次操作后重新观察屏幕，根据结果调整下一步。

这也是 UI-TARS 最值得普通开发者学习的地方。

十三、为什么说 UI-TARS 不是简单坐标点击脚本？

现在可以回到标题里的问题。

UI-TARS 最后确实会点击坐标。

但它不是简单坐标点击脚本，原因有五点：

复制代码

第一，坐标不是人工录制的，而是模型根据当前截图动态生成的。

第二，模型不是只输出动作，还要输出 Thought，说明当前判断和下一步理由。

第三，动作不是自由文本，而是经过统一动作空间约束。

第四，坐标不是直接使用，而是经过缩放、归一化和真实屏幕映射。

第五，每次动作后都会重新观察屏幕，形成连续决策闭环。

所以，UI-TARS 和传统坐标脚本的区别，不在于"最后有没有点击坐标"。

而在于：

这个坐标是怎么来的。

如果坐标来自录制回放，它就是传统自动化。

如果坐标来自视觉理解、任务推理和动态 grounding，它就是 GUI Agent。

十四、一个简单对比

可以用下面这张表来总结：

复制代码

传统 RPA：
输入：人工录制流程
核心：固定规则和回放
界面理解：弱
异常处理：依赖预设规则
动作来源：人提前定义
适合场景：稳定、重复、确定流程

UI-TARS：
输入：用户任务 + 当前截图
核心：视觉理解、推理和动作生成
界面理解：强
异常处理：重新观察和推理
动作来源：模型实时生成
适合场景：动态、多步骤、需要判断的 GUI 任务

从这个角度看，UI-TARS 不是 RPA 的简单升级，而是另一条路线：

从"流程自动化"走向"界面智能体"。

总结

这篇文章我们重点比较了 UI-TARS 和传统 RPA 的区别。

传统 RPA 的核心是：

复制代码

录制人的操作
然后按固定流程回放

UI-TARS 的核心是：

复制代码

看当前屏幕
理解界面状态
推理下一步
生成标准动作
映射到真实坐标
执行后再次观察

所以，虽然两者最后都可能调用鼠标键盘，但底层逻辑完全不同。

传统 RPA 更像一条提前铺好的轨道。

UI-TARS 更像一个能看路、判断路况、再决定怎么走的驾驶员。

这也是为什么我们不能把 UI-TARS 理解成"更高级的坐标点击脚本"。

它真正代表的是一种新的自动化范式：

从规则驱动自动化，走向视觉驱动的 GUI Agent。