在前几篇文章中我们已经分析了 UI-TARS 的 Prompt、动作空间以及Thought Action输出格式。其中prompt.py里最重要的三个模板是COMPUTER_USE_DOUBAO MOBILE_USE_DOUBAO GROUNDING_DOUBAO上一篇文章我们重点讲了Thought Action为什么是 GUI Agent 的最小决策闭环。这一篇我们继续深入prompt.py比较桌面端和移动端 Prompt 的差异。很多人第一次看 UI-TARS 的移动端 Prompt 时会注意到它多了几个特殊动作open_app press_home press_back long_press而桌面端 Prompt 里则有hotkey left_double right_single这背后不是简单的 API 差异而是桌面端和移动端交互范式的根本不同。一、先看两个 Prompt 的共同点在prompt.py中COMPUTER_USE_DOUBAO和MOBILE_USE_DOUBAO的开头基本一致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.两者的输出格式也一样Thought: ... Action: ...源码中可以看到桌面端和移动端模板都要求模型在每一步先输出Thought再输出Action。这说明无论是操作电脑还是操作手机UI-TARS 都把任务执行看成一个连续的 Agent Loop而不是一次性脚本生成。它们共同的基本逻辑是当前任务 ↓ 历史动作 ↓ 当前截图 ↓ Thought 判断 ↓ Action 执行 ↓ 下一轮截图也就是说桌面端和移动端的共同基础是根据当前截图和任务历史输出下一步动作。真正的差异出现在 Action Space。二、桌面端 COMPUTER_USE 的动作空间COMPUTER_USE_DOUBAO的动作空间包括click(pointpointx1 y1/point) left_double(pointpointx1 y1/point) right_single(pointpointx1 y1/point) drag(start_pointpointx1 y1/point, end_pointpointx2 y2/point) hotkey(keyctrl c) type(contentxxx) scroll(pointpointx1 y1/point, directiondown or up or right or left) wait() finished(contentxxx)官方 README 也说明COMPUTER_USE推荐用于 Windows、Linux、macOS 等桌面环境支持单击、双击、右键、拖拽、快捷键、文本输入、滚动等常见桌面操作适合浏览器、办公软件和文件管理等任务。这些动作明显带有桌面端特征。比如双击文件打开 右键文件弹出菜单 CtrlC 复制 CtrlV 粘贴 CtrlS 保存 AltTab 切换窗口这些都是电脑用户非常熟悉的操作。所以桌面端 Prompt 的核心不是“点屏幕”而是模拟一个熟练的电脑用户。三、移动端 MOBILE_USE 的动作空间MOBILE_USE_DOUBAO的动作空间是click(pointpointx1 y1/point) long_press(pointpointx1 y1/point) type(content) scroll(pointpointx1 y1/point, directiondown or up or right or left) open_app(app_name) drag(start_pointpointx1 y1/point, end_pointpointx2 y2/point) press_home() press_back() finished(contentxxx)官方 README 明确说明MOBILE_USE推荐用于移动设备或 Android 模拟器包含long_press、open_app、press_home、press_back等移动端特有动作适合启动 App、滚动页面、填写输入框和在移动应用中导航。和桌面端相比移动端少了left_double right_single hotkey wait增加了long_press open_app press_home press_back这就是本文的重点。为什么手机端需要这些动作四、桌面和移动端的交互方式完全不同电脑的交互设备通常是鼠标 键盘 触控板 多窗口桌面 文件系统 菜单栏 右键菜单 快捷键手机的交互设备通常是触摸屏 手势 单窗口 App 返回键 主页键 应用启动器 长按菜单 系统导航栏也就是说两者虽然都属于 GUI但操作习惯完全不同。在桌面端用户经常通过键盘快捷键提高效率。例如CtrlC 复制 CtrlV 粘贴 CtrlS 保存 CtrlF 搜索 AltTab 切换窗口所以桌面端 Prompt 必须支持hotkey。在移动端用户没有传统键盘也没有右键菜单更没有双击打开文件这种统一习惯。移动端更常见的是点按 长按 滑动 返回 回主页 打开 App所以移动端 Prompt 必须支持long_press、press_back、press_home和open_app。这不是 UI-TARS 随便加的几个动作而是根据真实设备交互方式做出的动作空间差异化设计。五、为什么 mobile 需要 open_appopen_app的格式是open_app(app_name)这是移动端 Prompt 中非常关键的动作。因为手机任务经常从“打开某个 App”开始。例如打开微信给某人发消息 打开地图搜索附近餐馆 打开设置关闭蓝牙 打开浏览器搜索资料 打开相册选择一张图片如果没有open_app模型只能通过屏幕点击来打开 App。这会带来很多问题App 图标可能不在当前桌面页 桌面可能有多个分页 App 可能在文件夹里 图标位置因设备不同而不同 用户可能刚好停留在某个 App 内部也就是说单纯依赖click打开 App会让任务变得非常不稳定。open_app则把“启动应用”抽象成一个系统级动作。模型只需要输出Action: open_app(app_nameChrome)外层执行系统就可以通过移动端自动化接口启动对应 App。这比让模型在桌面图标里找 Chrome 稳定得多。所以open_app的本质是把移动端任务中高频的“启动应用”动作从视觉点击提升为系统级动作。六、为什么桌面端没有 open_app有人可能会问电脑端也要打开应用为什么COMPUTER_USE没有open_app这是一个很好的问题。从理论上说桌面端也可以增加类似动作open_app(app_nameChrome) open_file(pathxxx) switch_window(titlexxx)但 UI-TARS 当前COMPUTER_USE_DOUBAO的设计更偏基础 GUI 操作层。它用这些动作覆盖桌面任务click double click right click drag hotkey type scroll wait finished在桌面环境中打开应用通常可以通过多种方式完成点击桌面图标 双击快捷方式 打开开始菜单搜索 使用快捷键 从任务栏启动 从文件管理器打开而移动端的 App 启动更像一个标准系统动作。因此open_app对移动端更必要。当然如果你基于 UI-TARS 做桌面自动化产品完全可以扩展一个桌面版open_app但那就需要同步修改 Prompt、Parser 和执行层。七、为什么 mobile 需要 press_homepress_home()表示按下手机主页键。这个动作在移动端非常重要。因为手机通常是单窗口 App 交互用户经常需要从当前 App 回到系统主页再打开另一个 App。例如从微信回到桌面 打开浏览器查资料 再回到微信发送内容如果没有press_home模型只能依赖界面上的返回按钮或者系统手势。但不同 App 的界面差异很大有的 App 左上角有返回按钮 有的 App 底部有 Tab 有的 App 返回键会关闭弹窗 有的 App 返回键会退出页面 有的 App 没有明显的返回入口主页键则是一个更稳定的系统级操作。它不依赖当前 App 的 UI 布局。所以press_home的价值是让 Agent 能从复杂 App 状态中跳回一个确定的起点。这对移动端多步骤任务非常有用。例如当前停留在某个深层页面 不知道如何返回主界面 先 press_home() 再 open_app(...)这个组合非常常见press_home() open_app(app_nameSettings)它相当于给 Agent 提供了一个“重置导航状态”的能力。八、为什么桌面端没有 press_home桌面端没有统一意义上的“主页键”。在 Windows、macOS、Linux 上用户可以最小化窗口 切换窗口 打开开始菜单 点击 Dock 回到桌面 使用 AltTab 使用任务栏但这些不是同一个抽象动作。桌面系统是多窗口并行环境不像手机那样以单个前台 App 为核心。所以桌面端更需要hotkey click double click right click drag而不是press_home。这也说明动作空间设计必须尊重平台交互模型。不能简单地把手机动作搬到电脑上也不能把电脑动作硬塞到手机里。九、为什么 mobile 需要 press_backpress_back()是移动端最重要的导航动作之一。在 Android 中返回动作承担了很多功能返回上一页 关闭弹窗 关闭键盘 退出当前页面 回到上一个 App 取消当前操作手机用户非常依赖返回键。例如进入详情页后返回列表 打开设置子页面后返回上一级 弹窗出现后按返回关闭 输入完成后返回收起键盘如果没有press_back模型只能寻找界面上的返回按钮。但返回按钮的位置和样式并不统一有的在左上角 有的是箭头图标 有的是文字“返回” 有的页面没有明显返回按钮 有的返回按钮被隐藏在系统手势里所以press_back是移动端 Agent 非常关键的系统导航能力。它可以让模型在不依赖具体 UI 元素的情况下完成回退操作。这也是为什么MOBILE_USE_DOUBAO必须把它放进动作空间。源码中可以看到移动端模板明确包含press_back()而桌面端模板没有对应动作。十、press_back 和 scroll、click 的关系press_back并不是替代click。它们解决的问题不同。click 操作界面中的具体元素。 scroll 查看更多内容。 press_back 执行系统级返回。例如当前页面商品详情页 目标回到商品列表 方案一 点击左上角返回箭头 方案二 press_back()如果返回箭头清晰可见模型可以 click。如果按钮不可见、界面复杂或者返回逻辑是系统级的press_back更稳。所以移动端 Prompt 同时保留了click和press_back。一个负责视觉元素操作一个负责系统导航。十一、为什么 mobile 需要 long_presslong_press的格式是long_press(pointpointx1 y1/point)长按是移动端非常常见的交互。例如长按消息复制 长按图片保存 长按图标弹出菜单 长按文本选择 长按文件进行多选桌面端通常用右键实现类似功能。比如桌面端右键文件 → 弹出菜单 移动端长按文件 → 弹出菜单所以你会看到一个很自然的对应关系桌面端 right_single 移动端 long_press这两者底层动作不同但交互语义相似打开某个对象的上下文操作菜单。这正体现了 UI-TARS 论文中 Unified Action Modeling 的思想跨平台动作应该尽量抽象到语义层面而不是死盯某个具体设备 API。论文摘要中也提到UI-TARS 通过统一动作建模把跨平台动作标准化到统一空间并结合 grounding 实现精确交互。十二、桌面端为什么需要 hotkey桌面端 Prompt 里有hotkey(keyctrl c)源码注释还要求快捷键用空格分隔、使用小写并且不要在一次 hotkey 动作中使用超过 3 个按键。这是桌面端非常重要的能力。因为很多电脑操作中快捷键比鼠标点击更高效、更稳定。例如复制ctrl c 粘贴ctrl v 保存ctrl s 查找ctrl f 全选ctrl a 切换窗口alt tab如果没有 hotkey模型可能需要通过菜单路径完成操作点击 Edit 点击 Copy这在不同软件里菜单位置可能不同。而快捷键在很多桌面软件中更统一。所以桌面端必须支持hotkey。移动端没有传统物理键盘环境因此MOBILE_USE_DOUBAO没有hotkey。这不是能力缺失而是平台交互习惯不同。十三、桌面端为什么需要 left_double 和 right_single桌面端 Prompt 里还有left_double(pointpointx1 y1/point) right_single(pointpointx1 y1/point)这两个动作在电脑环境里非常常见。双击打开文件 打开文件夹 启动桌面程序 进入列表项右键打开上下文菜单 复制文件 重命名文件 删除文件 另存为 查看属性在移动端这两个动作通常不成立。手机上没有鼠标右键。双击也不是通用的“打开”动作更多是特定 App 内部手势比如图片放大、地图缩放等。所以移动端不需要把left_double和right_single放进基础动作空间。相反移动端用long_press press_back press_home open_app来表达自己更常见的操作。十四、两套 Prompt 体现的是“共享动作 平台扩展”把桌面端和移动端放在一起看会发现 UI-TARS 并不是完全设计了两套无关动作。它们有共享部分click drag type scroll finished这些动作在桌面和移动端都成立。它们也有平台特有部分。桌面端特有left_double right_single hotkey wait移动端特有long_press open_app press_home press_back这种设计可以总结为共享动作解决跨平台通用交互 平台动作解决设备特有交互。这正是 Unified Action Modeling 的工程化落地。论文中把 UI-TARS 描述为仅依赖截图输入、执行类似人类键盘鼠标操作的 native GUI agent并强调其核心能力包括 perception、action、reasoning 和 memory其中 action 能力要求模型在预定义动作空间内准确预测并 grounding 动作。十五、为什么移动端更需要系统级动作桌面端的很多操作可以通过可见 UI 完成。例如菜单栏 任务栏 窗口按钮 右键菜单 快捷键 文件路径移动端则更依赖系统导航。原因有几个。第一手机屏幕空间小。很多功能不会同时显示在屏幕上需要进入多层页面。第二手机通常是单前台 App。用户不是同时操作多个窗口而是在一个 App 内不断前进、返回、切换。第三系统导航承担重要角色。返回、主页、打开 App 是手机用户每天都在用的基础操作。第四App UI 差异更大。同样是“返回”不同 App 可能有不同按钮位置但系统返回动作更统一。所以移动端 Prompt 必须提供系统级动作。如果只提供 click、type、scrollAgent 很容易被困在某个 App 的深层页面里。十六、一个移动端任务示例假设用户任务是打开浏览器搜索 UI-TARS。移动端 Agent 可能这样执行Thought: 当前不确定是否在浏览器中我需要先打开浏览器 App。 Action: open_app(app_nameChrome)然后Thought: 浏览器已经打开我需要点击搜索框输入关键词。 Action: click(pointpoint520 130/point)接着Thought: 搜索框已经获得焦点现在输入关键词并提交搜索。 Action: type(contentUI-TARS\n)如果任务完成Thought: 搜索结果已经显示任务完成。 Action: finished(content已完成搜索。)如果用户还要求回到主页Thought: 当前搜索已经完成现在需要回到手机主页。 Action: press_home()可以看到open_app和press_home让移动端 Agent 不必完全依赖图标和页面按钮。这会让任务更稳定。十七、一个复杂移动端切换任务示例再看一个更能体现移动端差异的任务从浏览器复制一段内容然后打开微信发给朋友。移动端 Agent 可能需要open_app(app_nameChrome)找到页面内容后long_press(pointpoint480 650/point)选择复制后press_home()再打开微信open_app(app_nameWeChat)进入聊天界面后click(pointpoint420 720/point) type(content...)如果进入了错误页面可以press_back()这里如果没有open_app press_home press_back long_pressAgent 就很难完成这种跨 App、多页面、需要系统导航的任务。十八、二次开发时如何扩展桌面端和移动端动作如果你想基于 UI-TARS 做自己的自动化项目动作空间可以扩展但要遵循一个原则Prompt、Parser、Executor 必须同步修改。比如你想给桌面端增加open_app(app_name) switch_window(title) close_window()那就需要1. 在 prompt.py 中增加动作说明 2. 在 action_parser.py 中增加解析逻辑 3. 在执行层实现对应动作 4. 增加测试用例 5. 增加安全限制如果只改 Prompt模型可能会输出新动作但程序无法执行。如果只改执行层模型不知道这个动作存在。动作空间本质上是三方协议模型知道可以输出什么 Parser 知道如何解析 Executor 知道如何执行。所以扩展动作必须成套进行。十九、哪些动作适合加入桌面端如果做桌面自动化比较适合扩展的动作包括open_app(app_name) switch_window(title) activate_window(title) close_window() copy_selected_text() paste_text(content) open_file(path) run_command(command)但要注意高风险动作需要谨慎。例如delete_file(path) send_email(...) submit_payment(...)这类动作最好不要直接让模型执行而是加用户确认。因为 GUI Agent 操作的是真实系统一旦误执行可能造成数据丢失或安全问题。二十、哪些动作适合加入移动端如果做移动端自动化可以考虑扩展press_enter() swipe_up() swipe_down() switch_app() open_notification_panel() input_otp(code)但同样要谨慎。例如确认支付 删除聊天记录 发送消息 授权隐私权限这类动作最好做安全拦截。移动端任务经常涉及账号、聊天、支付、定位和隐私因此比普通桌面点击更需要权限控制。二十一、从 Prompt 差异看 UI-TARS 的设计思想通过比较COMPUTER_USE_DOUBAO和MOBILE_USE_DOUBAO可以总结出 UI-TARS 的一个重要设计思想动作空间应该统一但不能僵化。统一的地方在于都用 Thought Action 都用函数调用式 Action 都用 point 表示坐标 都把动作限制在可解析的集合里 都通过 finished 表示任务结束。差异化的地方在于桌面端保留右键、双击、快捷键 移动端保留长按、打开 App、返回、主页。这就是好的跨平台 Agent 设计。不是强行让所有设备使用同一套动作而是在统一协议下保留平台特性。总结这篇文章我们对比了 UI-TARS 中桌面端和移动端 Prompt 的差异。桌面端COMPUTER_USE更强调hotkey left_double right_single drag wait因为电脑用户常用键盘快捷键、右键菜单、双击打开和多窗口操作。移动端MOBILE_USE更强调open_app press_home press_back long_press因为手机任务高度依赖系统导航、单前台 App、触摸手势和跨 App 切换。所以open_app、press_home、press_back不是可有可无的小功能而是移动端 GUI Agent 能否稳定执行任务的关键动作。从更高层看这体现了 UI-TARS 的动作空间设计原则共享动作保持统一 平台动作保留差异 模型输出保持可解析 执行层动作保持可落地。
UI-TARS 源码解析 #8：桌面端与移动端 Prompt 差异：为什么 mobile 要支持 open_app、press_home、press_back？
在前几篇文章中我们已经分析了 UI-TARS 的 Prompt、动作空间以及Thought Action输出格式。其中prompt.py里最重要的三个模板是COMPUTER_USE_DOUBAO MOBILE_USE_DOUBAO GROUNDING_DOUBAO上一篇文章我们重点讲了Thought Action为什么是 GUI Agent 的最小决策闭环。这一篇我们继续深入prompt.py比较桌面端和移动端 Prompt 的差异。很多人第一次看 UI-TARS 的移动端 Prompt 时会注意到它多了几个特殊动作open_app press_home press_back long_press而桌面端 Prompt 里则有hotkey left_double right_single这背后不是简单的 API 差异而是桌面端和移动端交互范式的根本不同。一、先看两个 Prompt 的共同点在prompt.py中COMPUTER_USE_DOUBAO和MOBILE_USE_DOUBAO的开头基本一致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.两者的输出格式也一样Thought: ... Action: ...源码中可以看到桌面端和移动端模板都要求模型在每一步先输出Thought再输出Action。这说明无论是操作电脑还是操作手机UI-TARS 都把任务执行看成一个连续的 Agent Loop而不是一次性脚本生成。它们共同的基本逻辑是当前任务 ↓ 历史动作 ↓ 当前截图 ↓ Thought 判断 ↓ Action 执行 ↓ 下一轮截图也就是说桌面端和移动端的共同基础是根据当前截图和任务历史输出下一步动作。真正的差异出现在 Action Space。二、桌面端 COMPUTER_USE 的动作空间COMPUTER_USE_DOUBAO的动作空间包括click(pointpointx1 y1/point) left_double(pointpointx1 y1/point) right_single(pointpointx1 y1/point) drag(start_pointpointx1 y1/point, end_pointpointx2 y2/point) hotkey(keyctrl c) type(contentxxx) scroll(pointpointx1 y1/point, directiondown or up or right or left) wait() finished(contentxxx)官方 README 也说明COMPUTER_USE推荐用于 Windows、Linux、macOS 等桌面环境支持单击、双击、右键、拖拽、快捷键、文本输入、滚动等常见桌面操作适合浏览器、办公软件和文件管理等任务。这些动作明显带有桌面端特征。比如双击文件打开 右键文件弹出菜单 CtrlC 复制 CtrlV 粘贴 CtrlS 保存 AltTab 切换窗口这些都是电脑用户非常熟悉的操作。所以桌面端 Prompt 的核心不是“点屏幕”而是模拟一个熟练的电脑用户。三、移动端 MOBILE_USE 的动作空间MOBILE_USE_DOUBAO的动作空间是click(pointpointx1 y1/point) long_press(pointpointx1 y1/point) type(content) scroll(pointpointx1 y1/point, directiondown or up or right or left) open_app(app_name) drag(start_pointpointx1 y1/point, end_pointpointx2 y2/point) press_home() press_back() finished(contentxxx)官方 README 明确说明MOBILE_USE推荐用于移动设备或 Android 模拟器包含long_press、open_app、press_home、press_back等移动端特有动作适合启动 App、滚动页面、填写输入框和在移动应用中导航。和桌面端相比移动端少了left_double right_single hotkey wait增加了long_press open_app press_home press_back这就是本文的重点。为什么手机端需要这些动作四、桌面和移动端的交互方式完全不同电脑的交互设备通常是鼠标 键盘 触控板 多窗口桌面 文件系统 菜单栏 右键菜单 快捷键手机的交互设备通常是触摸屏 手势 单窗口 App 返回键 主页键 应用启动器 长按菜单 系统导航栏也就是说两者虽然都属于 GUI但操作习惯完全不同。在桌面端用户经常通过键盘快捷键提高效率。例如CtrlC 复制 CtrlV 粘贴 CtrlS 保存 CtrlF 搜索 AltTab 切换窗口所以桌面端 Prompt 必须支持hotkey。在移动端用户没有传统键盘也没有右键菜单更没有双击打开文件这种统一习惯。移动端更常见的是点按 长按 滑动 返回 回主页 打开 App所以移动端 Prompt 必须支持long_press、press_back、press_home和open_app。这不是 UI-TARS 随便加的几个动作而是根据真实设备交互方式做出的动作空间差异化设计。五、为什么 mobile 需要 open_appopen_app的格式是open_app(app_name)这是移动端 Prompt 中非常关键的动作。因为手机任务经常从“打开某个 App”开始。例如打开微信给某人发消息 打开地图搜索附近餐馆 打开设置关闭蓝牙 打开浏览器搜索资料 打开相册选择一张图片如果没有open_app模型只能通过屏幕点击来打开 App。这会带来很多问题App 图标可能不在当前桌面页 桌面可能有多个分页 App 可能在文件夹里 图标位置因设备不同而不同 用户可能刚好停留在某个 App 内部也就是说单纯依赖click打开 App会让任务变得非常不稳定。open_app则把“启动应用”抽象成一个系统级动作。模型只需要输出Action: open_app(app_nameChrome)外层执行系统就可以通过移动端自动化接口启动对应 App。这比让模型在桌面图标里找 Chrome 稳定得多。所以open_app的本质是把移动端任务中高频的“启动应用”动作从视觉点击提升为系统级动作。六、为什么桌面端没有 open_app有人可能会问电脑端也要打开应用为什么COMPUTER_USE没有open_app这是一个很好的问题。从理论上说桌面端也可以增加类似动作open_app(app_nameChrome) open_file(pathxxx) switch_window(titlexxx)但 UI-TARS 当前COMPUTER_USE_DOUBAO的设计更偏基础 GUI 操作层。它用这些动作覆盖桌面任务click double click right click drag hotkey type scroll wait finished在桌面环境中打开应用通常可以通过多种方式完成点击桌面图标 双击快捷方式 打开开始菜单搜索 使用快捷键 从任务栏启动 从文件管理器打开而移动端的 App 启动更像一个标准系统动作。因此open_app对移动端更必要。当然如果你基于 UI-TARS 做桌面自动化产品完全可以扩展一个桌面版open_app但那就需要同步修改 Prompt、Parser 和执行层。七、为什么 mobile 需要 press_homepress_home()表示按下手机主页键。这个动作在移动端非常重要。因为手机通常是单窗口 App 交互用户经常需要从当前 App 回到系统主页再打开另一个 App。例如从微信回到桌面 打开浏览器查资料 再回到微信发送内容如果没有press_home模型只能依赖界面上的返回按钮或者系统手势。但不同 App 的界面差异很大有的 App 左上角有返回按钮 有的 App 底部有 Tab 有的 App 返回键会关闭弹窗 有的 App 返回键会退出页面 有的 App 没有明显的返回入口主页键则是一个更稳定的系统级操作。它不依赖当前 App 的 UI 布局。所以press_home的价值是让 Agent 能从复杂 App 状态中跳回一个确定的起点。这对移动端多步骤任务非常有用。例如当前停留在某个深层页面 不知道如何返回主界面 先 press_home() 再 open_app(...)这个组合非常常见press_home() open_app(app_nameSettings)它相当于给 Agent 提供了一个“重置导航状态”的能力。八、为什么桌面端没有 press_home桌面端没有统一意义上的“主页键”。在 Windows、macOS、Linux 上用户可以最小化窗口 切换窗口 打开开始菜单 点击 Dock 回到桌面 使用 AltTab 使用任务栏但这些不是同一个抽象动作。桌面系统是多窗口并行环境不像手机那样以单个前台 App 为核心。所以桌面端更需要hotkey click double click right click drag而不是press_home。这也说明动作空间设计必须尊重平台交互模型。不能简单地把手机动作搬到电脑上也不能把电脑动作硬塞到手机里。九、为什么 mobile 需要 press_backpress_back()是移动端最重要的导航动作之一。在 Android 中返回动作承担了很多功能返回上一页 关闭弹窗 关闭键盘 退出当前页面 回到上一个 App 取消当前操作手机用户非常依赖返回键。例如进入详情页后返回列表 打开设置子页面后返回上一级 弹窗出现后按返回关闭 输入完成后返回收起键盘如果没有press_back模型只能寻找界面上的返回按钮。但返回按钮的位置和样式并不统一有的在左上角 有的是箭头图标 有的是文字“返回” 有的页面没有明显返回按钮 有的返回按钮被隐藏在系统手势里所以press_back是移动端 Agent 非常关键的系统导航能力。它可以让模型在不依赖具体 UI 元素的情况下完成回退操作。这也是为什么MOBILE_USE_DOUBAO必须把它放进动作空间。源码中可以看到移动端模板明确包含press_back()而桌面端模板没有对应动作。十、press_back 和 scroll、click 的关系press_back并不是替代click。它们解决的问题不同。click 操作界面中的具体元素。 scroll 查看更多内容。 press_back 执行系统级返回。例如当前页面商品详情页 目标回到商品列表 方案一 点击左上角返回箭头 方案二 press_back()如果返回箭头清晰可见模型可以 click。如果按钮不可见、界面复杂或者返回逻辑是系统级的press_back更稳。所以移动端 Prompt 同时保留了click和press_back。一个负责视觉元素操作一个负责系统导航。十一、为什么 mobile 需要 long_presslong_press的格式是long_press(pointpointx1 y1/point)长按是移动端非常常见的交互。例如长按消息复制 长按图片保存 长按图标弹出菜单 长按文本选择 长按文件进行多选桌面端通常用右键实现类似功能。比如桌面端右键文件 → 弹出菜单 移动端长按文件 → 弹出菜单所以你会看到一个很自然的对应关系桌面端 right_single 移动端 long_press这两者底层动作不同但交互语义相似打开某个对象的上下文操作菜单。这正体现了 UI-TARS 论文中 Unified Action Modeling 的思想跨平台动作应该尽量抽象到语义层面而不是死盯某个具体设备 API。论文摘要中也提到UI-TARS 通过统一动作建模把跨平台动作标准化到统一空间并结合 grounding 实现精确交互。十二、桌面端为什么需要 hotkey桌面端 Prompt 里有hotkey(keyctrl c)源码注释还要求快捷键用空格分隔、使用小写并且不要在一次 hotkey 动作中使用超过 3 个按键。这是桌面端非常重要的能力。因为很多电脑操作中快捷键比鼠标点击更高效、更稳定。例如复制ctrl c 粘贴ctrl v 保存ctrl s 查找ctrl f 全选ctrl a 切换窗口alt tab如果没有 hotkey模型可能需要通过菜单路径完成操作点击 Edit 点击 Copy这在不同软件里菜单位置可能不同。而快捷键在很多桌面软件中更统一。所以桌面端必须支持hotkey。移动端没有传统物理键盘环境因此MOBILE_USE_DOUBAO没有hotkey。这不是能力缺失而是平台交互习惯不同。十三、桌面端为什么需要 left_double 和 right_single桌面端 Prompt 里还有left_double(pointpointx1 y1/point) right_single(pointpointx1 y1/point)这两个动作在电脑环境里非常常见。双击打开文件 打开文件夹 启动桌面程序 进入列表项右键打开上下文菜单 复制文件 重命名文件 删除文件 另存为 查看属性在移动端这两个动作通常不成立。手机上没有鼠标右键。双击也不是通用的“打开”动作更多是特定 App 内部手势比如图片放大、地图缩放等。所以移动端不需要把left_double和right_single放进基础动作空间。相反移动端用long_press press_back press_home open_app来表达自己更常见的操作。十四、两套 Prompt 体现的是“共享动作 平台扩展”把桌面端和移动端放在一起看会发现 UI-TARS 并不是完全设计了两套无关动作。它们有共享部分click drag type scroll finished这些动作在桌面和移动端都成立。它们也有平台特有部分。桌面端特有left_double right_single hotkey wait移动端特有long_press open_app press_home press_back这种设计可以总结为共享动作解决跨平台通用交互 平台动作解决设备特有交互。这正是 Unified Action Modeling 的工程化落地。论文中把 UI-TARS 描述为仅依赖截图输入、执行类似人类键盘鼠标操作的 native GUI agent并强调其核心能力包括 perception、action、reasoning 和 memory其中 action 能力要求模型在预定义动作空间内准确预测并 grounding 动作。十五、为什么移动端更需要系统级动作桌面端的很多操作可以通过可见 UI 完成。例如菜单栏 任务栏 窗口按钮 右键菜单 快捷键 文件路径移动端则更依赖系统导航。原因有几个。第一手机屏幕空间小。很多功能不会同时显示在屏幕上需要进入多层页面。第二手机通常是单前台 App。用户不是同时操作多个窗口而是在一个 App 内不断前进、返回、切换。第三系统导航承担重要角色。返回、主页、打开 App 是手机用户每天都在用的基础操作。第四App UI 差异更大。同样是“返回”不同 App 可能有不同按钮位置但系统返回动作更统一。所以移动端 Prompt 必须提供系统级动作。如果只提供 click、type、scrollAgent 很容易被困在某个 App 的深层页面里。十六、一个移动端任务示例假设用户任务是打开浏览器搜索 UI-TARS。移动端 Agent 可能这样执行Thought: 当前不确定是否在浏览器中我需要先打开浏览器 App。 Action: open_app(app_nameChrome)然后Thought: 浏览器已经打开我需要点击搜索框输入关键词。 Action: click(pointpoint520 130/point)接着Thought: 搜索框已经获得焦点现在输入关键词并提交搜索。 Action: type(contentUI-TARS\n)如果任务完成Thought: 搜索结果已经显示任务完成。 Action: finished(content已完成搜索。)如果用户还要求回到主页Thought: 当前搜索已经完成现在需要回到手机主页。 Action: press_home()可以看到open_app和press_home让移动端 Agent 不必完全依赖图标和页面按钮。这会让任务更稳定。十七、一个复杂移动端切换任务示例再看一个更能体现移动端差异的任务从浏览器复制一段内容然后打开微信发给朋友。移动端 Agent 可能需要open_app(app_nameChrome)找到页面内容后long_press(pointpoint480 650/point)选择复制后press_home()再打开微信open_app(app_nameWeChat)进入聊天界面后click(pointpoint420 720/point) type(content...)如果进入了错误页面可以press_back()这里如果没有open_app press_home press_back long_pressAgent 就很难完成这种跨 App、多页面、需要系统导航的任务。十八、二次开发时如何扩展桌面端和移动端动作如果你想基于 UI-TARS 做自己的自动化项目动作空间可以扩展但要遵循一个原则Prompt、Parser、Executor 必须同步修改。比如你想给桌面端增加open_app(app_name) switch_window(title) close_window()那就需要1. 在 prompt.py 中增加动作说明 2. 在 action_parser.py 中增加解析逻辑 3. 在执行层实现对应动作 4. 增加测试用例 5. 增加安全限制如果只改 Prompt模型可能会输出新动作但程序无法执行。如果只改执行层模型不知道这个动作存在。动作空间本质上是三方协议模型知道可以输出什么 Parser 知道如何解析 Executor 知道如何执行。所以扩展动作必须成套进行。十九、哪些动作适合加入桌面端如果做桌面自动化比较适合扩展的动作包括open_app(app_name) switch_window(title) activate_window(title) close_window() copy_selected_text() paste_text(content) open_file(path) run_command(command)但要注意高风险动作需要谨慎。例如delete_file(path) send_email(...) submit_payment(...)这类动作最好不要直接让模型执行而是加用户确认。因为 GUI Agent 操作的是真实系统一旦误执行可能造成数据丢失或安全问题。二十、哪些动作适合加入移动端如果做移动端自动化可以考虑扩展press_enter() swipe_up() swipe_down() switch_app() open_notification_panel() input_otp(code)但同样要谨慎。例如确认支付 删除聊天记录 发送消息 授权隐私权限这类动作最好做安全拦截。移动端任务经常涉及账号、聊天、支付、定位和隐私因此比普通桌面点击更需要权限控制。二十一、从 Prompt 差异看 UI-TARS 的设计思想通过比较COMPUTER_USE_DOUBAO和MOBILE_USE_DOUBAO可以总结出 UI-TARS 的一个重要设计思想动作空间应该统一但不能僵化。统一的地方在于都用 Thought Action 都用函数调用式 Action 都用 point 表示坐标 都把动作限制在可解析的集合里 都通过 finished 表示任务结束。差异化的地方在于桌面端保留右键、双击、快捷键 移动端保留长按、打开 App、返回、主页。这就是好的跨平台 Agent 设计。不是强行让所有设备使用同一套动作而是在统一协议下保留平台特性。总结这篇文章我们对比了 UI-TARS 中桌面端和移动端 Prompt 的差异。桌面端COMPUTER_USE更强调hotkey left_double right_single drag wait因为电脑用户常用键盘快捷键、右键菜单、双击打开和多窗口操作。移动端MOBILE_USE更强调open_app press_home press_back long_press因为手机任务高度依赖系统导航、单前台 App、触摸手势和跨 App 切换。所以open_app、press_home、press_back不是可有可无的小功能而是移动端 GUI Agent 能否稳定执行任务的关键动作。从更高层看这体现了 UI-TARS 的动作空间设计原则共享动作保持统一 平台动作保留差异 模型输出保持可解析 执行层动作保持可落地。
