UI-TARS 源码解析 #24：UI-TARS、UI-TARS-desktop 与 Midscene.js：桌面自动化和浏览器自动化怎么选？

前面二十多篇文章，我们一直围绕 UI-TARS 主仓库做源码解析。

我们分析了：

prompt.py
action_parser.py
parse_action
parse_action_to_structure_output
parsing_response_to_pyautogui_code
smart_resize
坐标映射
pyautogui 执行
安全边界
Windows 二次开发

到这里，一个很自然的问题就出现了：

如果我要做自动化产品，到底应该选 UI-TARS、UI-TARS-desktop，还是 Midscene.js？

这个问题很关键。

因为它们看起来都和“AI 自动操作界面”有关，但定位并不完全一样。

简单说：

UI-TARS：
更像底层模型 + Prompt + Action Parser + 坐标协议。

UI-TARS-desktop：
更像开箱即用的本地桌面 GUI Agent 应用。

Midscene.js：
更偏面向浏览器、UI 测试和跨平台视觉驱动自动化的开发者工具。

这篇文章就来系统比较三者的定位、适合场景和选择策略。

---

一、先看 UI-TARS 主仓库的定位

UI-TARS 主仓库的核心定位是：

Pioneering Automated GUI Interaction with Native Agents。

官方 README 中说明，UI-TARS-1.5 是一个开源多模态 Agent，能够在虚拟世界中执行多样任务，并且通过 reasoning before action 的方式增强推理与适应能力；主仓库还提供 HuggingFace Models、部署文档、论文、UI-TARS-desktop 和 Midscene.js 的入口。

从源码层面看，UI-TARS 主仓库更适合研究和二次开发。

它提供的是这些基础能力：

1. GUI Agent 模型思路；
2. Thought + Action 输出协议；
3. COMPUTER_USE / MOBILE_USE / GROUNDING Prompt；
4. action_parser.py；
5. 坐标转换和 smart_resize；
6. pyautogui 代码生成；
7. HuggingFace Endpoint 部署说明；
8. 坐标处理说明和测试示例。

也就是说，UI-TARS 主仓库不是一个完整桌面产品，而是更像一套 GUI Agent 的基础组件。

你可以把它理解成：

模型能力
+
动作协议
+
后处理代码

如果你想自己做一个 Windows 自动化 App，UI-TARS 主仓库最有价值的地方不是直接拿来运行，而是学习它的架构：

截图
  ↓
视觉语言模型
  ↓
Thought + Action
  ↓
Parser
  ↓
结构化动作
  ↓
pyautogui

---

二、UI-TARS 主仓库适合什么人？

UI-TARS 主仓库适合这几类人。

1. 想研究 GUI Agent 原理的人

比如你想搞清楚：

模型如何看截图？
动作空间怎么设计？
坐标如何归一化？
Qwen2.5-VL 坐标如何还原？
模型输出如何转 pyautogui？

那 UI-TARS 主仓库非常适合。

因为它把 Prompt、Parser、坐标和 pyautogui 生成都拆得比较清楚。

2. 想做自研桌面自动化产品的人

比如你要做：

Windows 自动操作助手
桌面 RPA + AI
AI 录制回放增强
自然语言控制软件
远程桌面自动操作

你可以参考 UI-TARS 的动作协议和后处理逻辑。

但要注意，产品化时需要自己补：

窗口管理
DPI 适配
安全执行器
日志系统
人工确认
任务模板
失败恢复

3. 想换模型、换执行器的人

UI-TARS 主仓库的分层很适合二次开发。

你可以：

换模型；
换 Prompt；
换 Parser；
换 pyautogui 为其他执行器；
改动作空间；
接入自己的 Windows App。

所以 UI-TARS 更像“底层参考实现”。

---

三、再看 UI-TARS-desktop 的定位

UI-TARS-desktop 则更接近一个可以直接使用的桌面应用。

UI-TARS-desktop 中文 README 中写到，UI-TARS Desktop 是一个由 UI-TARS 和 Seed-1.5-VL/1.6 系列模型驱动的原生 GUI agent，可在本地计算机上使用；功能包括基于视觉语言模型的自然语言控制、截图和视觉识别、精确鼠标键盘控制、跨平台支持、实时反馈和状态显示等。

这和 UI-TARS 主仓库不一样。

UI-TARS 主仓库更偏：

模型 + Prompt + Parser + 代码示例

UI-TARS-desktop 更偏：

桌面应用 + 本地操作器 + 可视化界面 + 实际控制体验

官方 README 也提到，UI-TARS 主仓库提供 UI-TARS-desktop 版本，可以在本地个人设备上操作。

所以，如果你不是想从零写一个 Agent，而是想先体验“AI 控制电脑”，UI-TARS-desktop 更直接。

---

四、UI-TARS-desktop 适合什么场景？

UI-TARS-desktop 更适合这些场景。

1. 想快速体验 AI 控制电脑

比如你想试试：

让 AI 打开软件；
让 AI 操作浏览器；
让 AI 点设置项；
让 AI 在本地桌面完成简单任务。

这类场景不一定需要先研究 action_parser.py。

直接用 UI-TARS-desktop 更快。

2. 想看完整产品形态

如果你要做自己的 Windows 自动化产品，UI-TARS-desktop 可以作为参考对象。

你可以观察它如何处理：

任务输入；
模型调用；
执行反馈；
界面状态显示；
用户体验；
本地操作；
远程操作。

3. 想做“人机协作式桌面 Agent”

UI-TARS-desktop 的价值不只是自动执行，还在于它更接近产品。

它能启发我们设计：

执行前确认；
任务进度展示；
截图反馈；
用户接管；
操作日志；
失败提示。

这些是 UI-TARS 主仓库里比较少涉及的部分。

---

五、Midscene.js 的定位

Midscene.js 的定位和 UI-TARS 不完全一样。

Midscene 官方介绍中写到，它是一个开源 SDK，用于 vision-driven UI testing and automation；用户用自然语言描述步骤，Midscene 驱动多模态模型规划和操作界面，可以覆盖 web、mobile、desktop，甚至 <canvas> 等界面。

但从实际使用入口看，Midscene.js 对浏览器和前端测试开发者特别友好。

官方文档明确提到，它可以接入现有 Playwright 或 Vitest 测试，也可以通过 Skills 让 AI agent 自主测试 UI；它还强调不用追逐 DOM selector，能够基于用户实际看到的视觉结果做断言，并生成可回放的视觉报告。

Midscene 的 Playwright 集成文档中也写到，它可以直接在脚本中调用 Midscene Agent，适合快速原型、数据采集和自动化脚本；也可以集成到 Playwright 测试用例中，适合 UI testing 场景。

所以，Midscene.js 更像：

AI + Playwright / Puppeteer / Chrome Extension / CLI

它更贴近前端、浏览器自动化和 UI 测试工作流。

---

六、Midscene.js 适合什么场景？

Midscene.js 适合这些任务。

1. 浏览器自动化

比如：

打开网页；
点击按钮；
填写表单；
滚动页面；
采集页面信息；
自动注册测试账号；
检查页面状态。

Midscene 的 Skills 文档中写到，@midscene/web 支持浏览器自动化，并提供默认 Puppeteer headless、Bridge 模式使用自己的 Chrome、CDP 模式连接浏览器调试端点等三种模式。

这说明它很适合浏览器场景。

2. 前端 UI 测试

传统 Playwright 测试依赖 selector。

例如：

page.locator('#submit').click()

但 UI 经常变化：

id 改了；
class 改了；
DOM 结构变了；
组件库升级了；
按钮位置变了。

Midscene 更强调用视觉和自然语言描述动作或断言。

例如：

点击登录按钮；
确认页面显示成功提示；
检查红色错误提示是否出现。

官方介绍也强调，它可以验证用户实际看到的视觉结果，而不仅是 DOM 节点是否存在。

3. 你主要操作的是 Web，而不是整个 Windows 桌面

如果你的自动化对象是：

网页后台；
SaaS 系统；
电商页面；
CRM；
管理后台；
网页表单；
前端测试页面；
Chrome 中的业务流程。

那 Midscene.js 通常比自己用 pyautogui 操作整个桌面更合适。

因为浏览器自动化有更多结构化能力：

URL；
DOM；
Network；
Console；
Cookie；
LocalStorage；
Playwright/CDP；
页面上下文。

这些能力是纯桌面截图自动化很难直接拿到的。

---

七、三者最核心的区别

可以这样概括三者：

UI-TARS：
底层模型和 GUI Agent 代码参考。

UI-TARS-desktop：
面向本地电脑的开箱即用桌面 Agent 应用。

Midscene.js：
面向浏览器、UI 测试和多平台视觉自动化的开发者工具。

再换一种说法：

想研究原理和二次开发：
选 UI-TARS。

想直接体验本地电脑操作：
选 UI-TARS-desktop。

想做浏览器自动化、前端测试、Web 表单操作：
优先看 Midscene.js。

---

八、桌面自动化和浏览器自动化的本质区别

桌面自动化面对的是整个操作系统。

它可以操作：

浏览器
记事本
VS Code
文件管理器
企业客户端
微信
剪映
远程桌面
各种传统 Windows 软件

浏览器自动化面对的是浏览器里的网页。

它主要操作：

页面
DOM
表单
按钮
弹窗
网络请求
Cookie
浏览器上下文

所以二者的边界很清楚：

如果目标在浏览器里：
优先浏览器自动化。

如果目标跨多个桌面应用：
考虑桌面自动化。

如果目标是传统 Windows 客户端：
基本只能桌面自动化或系统级自动化。

如果目标是前端测试：
优先 Midscene.js / Playwright 体系。

---

九、为什么浏览器自动化通常更稳？

浏览器自动化通常比纯桌面自动化更稳，原因是它可以利用浏览器结构化信息。

比如 Playwright 可以直接处理：

页面加载；
元素定位；
点击；
输入；
等待网络；
读取文本；
截图；
断言；
Cookie；
多标签页。

Midscene.js 又在此基础上加入视觉驱动和自然语言能力。

官方文档也提到，Midscene 可以集成到 Playwright 流程中，用于 AI-driven testing or automation。

相比之下，桌面自动化更多依赖截图和坐标：

截图识别；
坐标点击；
键盘输入；
滚轮滚动；
窗口焦点；
DPI 缩放；
多显示器；
弹窗遮挡。

这些因素都会让稳定性下降。

所以，只要任务能在浏览器里完成，浏览器自动化通常是更优先的选择。

---

十、为什么桌面自动化仍然不可替代？

虽然浏览器自动化更稳，但桌面自动化仍然不可替代。

因为很多场景不在浏览器里。

例如：

Windows 桌面软件；
老旧企业客户端；
只提供 GUI 的工具；
本地文件操作；
视频剪辑软件；
IDE；
远程桌面；
工业软件；
游戏或模拟器；
跨应用复制粘贴。

这些场景没有 DOM，也没有 Playwright。

你只能通过：

屏幕截图；
视觉识别；
鼠标键盘；
窗口管理；
OCR；
坐标转换。

来操作。

这就是 UI-TARS 和 UI-TARS-desktop 的价值。

UI-TARS 论文也把自己定义为 Native GUI Agent，强调仅通过截图感知界面，并执行键盘鼠标等类人交互。

---

十一、一个选择原则：先问目标在哪

选择工具时，先问第一个问题：

我要操作的目标在哪里？

如果目标是网页：

后台管理系统
网页表单
电商网站
SaaS 工具
网页测试

优先：

Midscene.js
Playwright
Puppeteer
浏览器自动化

如果目标是本地软件：

Windows 客户端
文件管理器
VS Code
剪映
微信
企业内部软件

优先：

UI-TARS-desktop
UI-TARS + 自研执行器
pyautogui / pywinauto

如果目标跨浏览器和本地软件：

浏览器下载文件
打开本地软件处理
再上传结果

就需要：

桌面自动化
+
浏览器自动化

这种情况可以采用混合架构。

---

十二、UI-TARS 主仓库：适合当“底层能力库”

如果你是程序员，想开发自己的自动化产品，UI-TARS 主仓库最适合当底层参考。

你可以借鉴它的：

Action Space 设计；
Thought + Action 输出格式；
point / start_box / end_box 坐标协议；
smart_resize 坐标适配；
parse_action_to_structure_output；
parsing_response_to_pyautogui_code；
HuggingFace Endpoint 部署方式；
安全边界设计思路。

但你不应该简单地：

模型输出什么就 exec 什么。

前面文章已经讲过，UI-TARS 的 pyautogui 代码生成适合学习和原型，但产品化最好改成安全执行器。

UI-TARS 的价值是给你“协议和链路”，不是替你完成全部产品工程。

---

十三、UI-TARS-desktop：适合当“成品参考”

UI-TARS-desktop 更适合当成品参考。

它能让你观察一个桌面 Agent 应该具备哪些产品模块：

任务输入框；
截图展示；
模型推理过程；
操作反馈；
状态显示；
本地控制；
浏览器控制；
远程操作；
用户接管。

官方 UI-TARS-desktop README 也明确列出功能，包括自然语言控制、截图和视觉识别、精确鼠标键盘控制、跨平台支持、实时反馈和状态显示。

如果你要做自己的 Windows 自动化 App，可以把 UI-TARS-desktop 当作参考产品，而不是只看 action_parser.py。

因为真实用户关心的不只是：

模型能不能输出 click

还关心：

我能不能看到它要点哪里？
能不能暂停？
点错了怎么办？
日志在哪？
能不能回放？
能不能限定只操作某个窗口？

这些都属于产品层设计。

---

十四、Midscene.js：适合当“浏览器自动化开发框架”

如果你的目标是浏览器，Midscene.js 会更贴近开发工作流。

它有几个明显优势：

更容易接入 Playwright；
更适合前端测试；
可以使用 Chrome Extension 快速体验；
支持 Bridge 模式操作当前 Chrome；
支持 CDP 连接浏览器；
更适合网页表单和 UI 断言。

Midscene 的 Skills 文档中明确列出 @midscene/web 的浏览器自动化能力，包括默认 Puppeteer headless、Bridge 使用自己的 Chrome、CDP 连接浏览器调试端点；同一页还列出 @midscene/computer、@midscene/android、@midscene/ios、@midscene/harmony 等平台包。

所以 Midscene.js 并不只是“只能浏览器”，但它对 Web 自动化和 UI 测试尤其友好。

---

十五、做副业产品时怎么选？

如果目标是做一个能变现的小产品，建议这样选。

1. 做网页自动化工具

例如：

自动填写网页表单；
网页数据采集；
SaaS 后台批量操作；
前端 UI 测试；
网页流程检测。

优先选：

Midscene.js + Playwright

原因是浏览器场景更容易稳定，也更容易做成可重复任务。

2. 做 Windows 本地自动化工具

例如：

自动操作剪映；
自动操作本地客户端；
自动处理文件；
自动控制多个桌面软件；
录制回放 + AI 增强。

优先参考：

UI-TARS + pyautogui / pywinauto
或者
UI-TARS-desktop

原因是这些任务离不开桌面控制。

3. 做“AI 测试工具”

例如：

前端页面自动验收；
UI 视觉断言；
自动跑业务流程；
生成测试报告。

优先选：

Midscene.js

因为它官方定位就是 vision-driven UI testing and automation，并且强调可以接入 Playwright 或 Vitest 测试。

4. 做“通用电脑助手”

例如：

帮我操作电脑完成任务；
跨浏览器、文件、软件；
执行多步骤桌面流程。

优先看：

UI-TARS-desktop

或者基于 UI-TARS 自己做一个更小范围的垂直 Agent。

---

十六、稳定性比较

从稳定性上看，通常可以这样排：

API 自动化
  >
浏览器 DOM 自动化
  >
浏览器视觉自动化
  >
桌面视觉自动化

也就是说：

能用 API，就不要点界面；
能用 Playwright selector，就不要纯视觉点击；
网页场景优先浏览器自动化；
跨桌面软件才上 GUI Agent。

这不是说桌面 GUI Agent 没价值，而是说它的使用成本更高。

桌面自动化要额外处理：

DPI；
窗口偏移；
多显示器；
遮挡；
焦点；
输入法；
权限；
误点击。

浏览器自动化的问题则更多集中在：

页面变化；
登录态；
反自动化；
验证码；
动态渲染；
selector 变化；
跨域 iframe。

所以，选择工具时要看任务对象，不要只看哪个项目更火。

---

十七、成本比较

成本也要考虑。

UI-TARS 这类视觉 GUI Agent，每一步通常都要：

截图
上传图片
模型推理
解析动作
执行
再截图

如果一个任务需要 20 步，就可能调用模型 20 次。

Midscene.js 做视觉自动化时也会调用多模态模型，但在浏览器测试场景里，它可以和 Playwright 流程结合，把部分稳定步骤写成普通脚本，把不稳定或视觉依赖强的地方交给 AI。Midscene 的 Playwright 集成文档也把“直接调用 Agent 做快速原型”和“集成到 Playwright 测试用例”作为两种方式。

所以比较现实的做法是：

稳定步骤：
用传统自动化脚本。

容易变化、难写 selector 的步骤：
用 AI 视觉自动化。

高风险步骤：
人工确认。

不要把所有步骤都交给 AI。

---

十八、安全比较

安全角度也不同。

桌面自动化风险更大，因为它能操作整个电脑：

文件；
软件；
系统设置；
本地数据；
剪贴板；
远程桌面；
企业客户端。

浏览器自动化风险主要集中在浏览器上下文：

账号登录态；
表单提交；
付款页面；
后台管理系统；
隐私数据；
下载上传。

UI-TARS 官方 README 的 Limitations 提到模型可能误识别 GUI 元素、产生不准确描述或次优动作，同时 GUI 自动化能力也可能被滥用。

所以，不管选哪种，都需要安全层。

最低限度要有：

动作白名单；
高风险动作确认；
验证码转人工；
敏感信息不自动输入；
执行日志；
用户随时停止；
连续失败自动停止。

---

十九、一个实用选择表

可以用下面这张表快速判断。

场景：研究 GUI Agent 原理
优先选择：UI-TARS 主仓库
原因：Prompt、Parser、坐标、pyautogui 生成都能学到

场景：快速体验 AI 操作电脑
优先选择：UI-TARS-desktop
原因：更接近开箱即用的桌面应用

场景：做自己的 Windows 自动化产品
优先选择：UI-TARS + 自研执行器
原因：需要控制安全、窗口、DPI、日志、任务模板

场景：网页自动填写、网页操作
优先选择：Midscene.js / Playwright
原因：浏览器自动化更稳，工具链更成熟

场景：前端 UI 测试
优先选择：Midscene.js
原因：官方定位就是 vision-driven UI testing and automation

场景：传统 Windows 客户端
优先选择：UI-TARS / UI-TARS-desktop / pyautogui / pywinauto
原因：没有 DOM，只能走桌面自动化

场景：跨浏览器和本地软件
优先选择：混合架构
原因：浏览器部分用 Midscene，桌面部分用 UI-TARS 思路

---

二十、混合架构可能是最终答案

真实产品里，不一定只能选一个。

最合理的架构可能是混合式：

浏览器任务：
Midscene.js / Playwright

桌面任务：
UI-TARS / UI-TARS-desktop / pyautogui / pywinauto

通用模型：
UI-TARS / 其他多模态模型

安全层：
统一动作白名单、确认、日志、失败检测

例如一个自动化流程：

1. 在网页后台下载订单 Excel；
2. 打开本地 Excel 或处理脚本；
3. 生成结果文件；
4. 回到网页上传；
5. 提交前人工确认。

可以这样分工：

网页下载和上传：
Midscene.js / Playwright

本地文件处理：
Python 脚本

本地软件操作：
UI-TARS 风格桌面 Agent

提交确认：
人工确认

这种架构比“全程靠一个 Agent 点屏幕”更稳定。

---

二十一、给 Windows 自动化产品的建议

如果你的目标是做 Windows 自动化 App，可以这样规划：

第一阶段：传统录制回放

先做好：

窗口识别；
坐标点击；
键盘输入；
录制回放；
日志；
任务节点。

第二阶段：AI 辅助动作生成

引入 UI-TARS 思路：

截图
  ↓
模型识别
  ↓
输出 click/type/scroll
  ↓
半自动确认

第三阶段：浏览器任务用 Midscene.js

如果用户要操作网页，不一定非要用桌面坐标。

可以接入：

Playwright
Midscene.js
Chrome Extension
CDP

第四阶段：统一任务编排

最终形成：

桌面节点
浏览器节点
脚本节点
人工确认节点
AI 判断节点

这比单纯做“AI 控制鼠标”更有产品价值。

---

二十二、不要把 GUI Agent 当万能工具

最后要强调一点：

UI-TARS、UI-TARS-desktop、Midscene.js 都不是万能的。

GUI Agent 的优势是：

能看见界面；
能处理没有 API 的软件；
能适应部分 UI 变化；
能用自然语言描述任务。

但它的短板也明显：

慢；
贵；
不稳定；
容易误点；
需要截图；
需要多轮验证；
高风险动作必须确认。

所以正确思路不是：

所有任务都让 AI 点屏幕。

而是：

能 API 就 API；
能脚本就脚本；
能 Playwright 就 Playwright；
只有界面无法结构化时，才让 GUI Agent 接管。

这才是实用的自动化工程路线。

---

总结

这篇文章我们比较了 UI-TARS、UI-TARS-desktop 和 Midscene.js。

可以这样总结：

UI-TARS：
适合研究 GUI Agent 原理和做底层二次开发。

UI-TARS-desktop：
适合快速体验本地电脑自动操作，也适合参考完整桌面 Agent 产品形态。

Midscene.js：
适合浏览器自动化、前端 UI 测试、Playwright 集成和视觉驱动网页操作。

选择时先问三个问题：

第一，目标是在浏览器里，还是在整个桌面里？

第二，我是要开箱即用，还是要二次开发？

第三，我更关心测试稳定性，还是通用桌面操作能力？

如果答案是“网页、测试、表单、浏览器流程”，优先选 Midscene.js。

如果答案是“Windows 软件、本地文件、跨应用操作”，优先看 UI-TARS / UI-TARS-desktop。

如果答案是“我要做自己的自动化产品”，建议采用混合架构：

浏览器部分：
Midscene.js / Playwright

桌面部分：
UI-TARS 思路 + 自研安全执行器

稳定流程：
传统脚本

高风险步骤：
人工确认

真正可靠的自动化产品，不是选一个最强 Agent，而是把不同工具放在合适的位置上。

这也是 UI-TARS 系列源码解析到这里最重要的工程结论：

GUI Agent 很强，
但它应该是自动化系统中的一层，
而不是全部。