尧图网站建设 
UI-TARS截图驱动移动端 UI 自动化测试【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS回归测试排到第 12 天你又停在同一个地方——页面换了个组件整套 XPath 定位脚本集体失效。UI-TARS 换了个思路它不读控件树只看一张截图用视觉语言模型自己判断下一步点哪里、填什么内容再把结果转成可执行的自动化动作。UI-TARS 是字节跳动 Seed 开源的原生 GUI 智能体模型给一张截图加一句任务它输出一段 Thought 推理加一个具体动作。在 Android World 手机基准上它拿到 64.2此前最佳是 59.5OSWorld100 步桌面任务得分 42.5高于此前 200 步才拿到的 38.1。从一张截图到一次点击感知、推理、动作三层怎么串起来传统自动化把看屏幕和决定动作拆成两三个模块先跑一遍 DOM 解析拿到控件树再靠规则映射到点击坐标界面一变整条链就断。UI-TARS 把感知、推理、grounding、记忆压进同一个视觉语言模型里截图直接作为输入动作直接从输出里解析中间没有控件 ID这个脆弱环节。感知层把画面变成模型能读的信号模型接收的不只是像素。仓库给出的能力清单包括元素描述Element Description、密集字幕Dense Captioning、Set-of-Mark 等——先把这是什么界面、有哪些可点的东西变成结构化理解再决定下一步。推理层System-2先想清楚再动手1.5 版引入了基于强化学习的推理动作前先生成 Thought多步思考清楚再执行。这条推理链正是模型能输出 Thought Action 两段式结果的来源。动作层一套跨平台统一的动作空间click、type、scroll、hotkey、drag是桌面与移动端共用的基础动作移动端额外加了long_press、open_app、press_home、press_back。动作空间统一同一套框架就能覆盖桌面和手机两类任务。5 分钟跑通从模型输出生成 pyautogui 脚本模型吐出来的是一句人话加坐标真正落地还差一步把它变成能驱动鼠标的代码。仓库的ui_tars.action_parser就干这件事。下面这段是最小可用链路输入一句模型响应输出 pyautogui 调用from ui_tars.action_parser import ( parse_action_to_structure_output, parsing_response_to_pyautogui_code, ) response Thought: Click the button\nAction: click(start_box(100,200)) original_image_width, original_image_height 1920, 1080 parsed parse_action_to_structure_output( response, factor1000, origin_resized_heightoriginal_image_height, origin_resized_widthoriginal_image_width, model_typeqwen25vl, ) print(parsing_response_to_pyautogui_code(parsed, image_heightoriginal_image_height, image_widthoriginal_image_width))运行后你会看到一段import pyautogui加pyautogui.click(x, y, buttonleft)的代码坐标已换算成原始分辨率下的真实像素。坐标这一步最容易踩坑。Qwen 2.5-VL 系模型输出绝对坐标但模型看到的图是被 smart_resize 调整过的要先把输出坐标按缩放后尺寸归一化、再乘回原图尺寸才能点对位置。这段换算可以单独验证from ui_tars.action_parser import smart_resize model_output_width, model_output_height 197, 525 width, height 1920, 1080 new_height, new_width smart_resize(height, width) new_x int(model_output_width / new_width * width) new_y int(model_output_height / new_height * height) print(new_x, new_y)运行后打印出换算后的坐标标回截图上就能确认模型到底想点哪里完整推导和可视化见 README_coordinates.md。视觉模型 vs 传统选择器哪些场景值得切换判断要不要切到视觉驱动先看硬数字而不是感觉。元素定位精度上ScreenSpotPro 得分 UI-TARS-1.5 为 61.6OpenAI CUA 23.4、Claude 3.7 为 27.7ScreenSpot-V2 上 94.2OpenAI CUA 87.9。整任务完成率上Android World 64.2 对此前 59.5Windows Agent Arena50 步42.1 对 29.8。维度传统选择器Appium/EspressoUI-TARS 视觉驱动元素定位依赖 id / XPath / resource-id截图 坐标无需控件树界面改版适应性控件一变脚本作废视觉理解布局变化更鲁棒跨平台桌面 / 移动端各写一套统一动作空间一套框架非标准 / 自绘控件常无法识别像素级定位可点成本本地免费需 GPU7B 建议 L40S / A100要切换的信号很明确被测界面没有稳定控件树、自绘控件多、桌面与移动端都要覆盖、改版频繁。反向看纯 Web 端 UI-TARS 也并非全面领先——WebVoyager 上它 84.8OpenAI CUA 是 87两者接近7B 版本官方也说明未针对游戏场景优化重度游戏自动化要用完整 1.5 模型。谁适合用看完第一步做什么适合三类人一是做移动端 / 桌面回归与兼容性测试、选择器维护成本高的团队二是要同时覆盖桌面和手机的跨平台自动化三是被测对象自绘控件多、拿不到干净控件树的场景。看完可以直接做的三件事 装包并跑通上面的解析链路pip install ui-tars用一句模型响应验证坐标换算正确。 按目标平台选 prompt 模板手机任务用MOBILE_USE_DOUBAO桌面用COMPUTER_USE_DOUBAO只评 grounding 用GROUNDING_DOUBAO三个模板在 codes/ui_tars/prompt.py 里。 把坐标处理接进自己的执行层先看仓库的坐标处理文档确认红点落在预期按钮上再接自动化执行。需要源码时git clone https://gitcode.com/GitHub_Trending/ui/UI-TARS本地或 HuggingFace Endpoint 部署二选一7B 模型建议 L40S / A100 级别 GPU。那天卡住的第 12 天回归瓶颈不在写脚本而在点没点对。把上面两段代码跑通你第一次视觉驱动的回归只需换掉定位那一段模型看图、给出坐标、解析成 pyautogui剩下交给执行层。先拿一个最熟悉的页面试确认红点落在按钮上再往整个流程推。【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 UI-TARS：截图驱动移动端 UI 自动化测试
UI-TARS截图驱动移动端 UI 自动化测试【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS回归测试排到第 12 天你又停在同一个地方——页面换了个组件整套 XPath 定位脚本集体失效。UI-TARS 换了个思路它不读控件树只看一张截图用视觉语言模型自己判断下一步点哪里、填什么内容再把结果转成可执行的自动化动作。UI-TARS 是字节跳动 Seed 开源的原生 GUI 智能体模型给一张截图加一句任务它输出一段 Thought 推理加一个具体动作。在 Android World 手机基准上它拿到 64.2此前最佳是 59.5OSWorld100 步桌面任务得分 42.5高于此前 200 步才拿到的 38.1。从一张截图到一次点击感知、推理、动作三层怎么串起来传统自动化把看屏幕和决定动作拆成两三个模块先跑一遍 DOM 解析拿到控件树再靠规则映射到点击坐标界面一变整条链就断。UI-TARS 把感知、推理、grounding、记忆压进同一个视觉语言模型里截图直接作为输入动作直接从输出里解析中间没有控件 ID这个脆弱环节。感知层把画面变成模型能读的信号模型接收的不只是像素。仓库给出的能力清单包括元素描述Element Description、密集字幕Dense Captioning、Set-of-Mark 等——先把这是什么界面、有哪些可点的东西变成结构化理解再决定下一步。推理层System-2先想清楚再动手1.5 版引入了基于强化学习的推理动作前先生成 Thought多步思考清楚再执行。这条推理链正是模型能输出 Thought Action 两段式结果的来源。动作层一套跨平台统一的动作空间click、type、scroll、hotkey、drag是桌面与移动端共用的基础动作移动端额外加了long_press、open_app、press_home、press_back。动作空间统一同一套框架就能覆盖桌面和手机两类任务。5 分钟跑通从模型输出生成 pyautogui 脚本模型吐出来的是一句人话加坐标真正落地还差一步把它变成能驱动鼠标的代码。仓库的ui_tars.action_parser就干这件事。下面这段是最小可用链路输入一句模型响应输出 pyautogui 调用from ui_tars.action_parser import ( parse_action_to_structure_output, parsing_response_to_pyautogui_code, ) response Thought: Click the button\nAction: click(start_box(100,200)) original_image_width, original_image_height 1920, 1080 parsed parse_action_to_structure_output( response, factor1000, origin_resized_heightoriginal_image_height, origin_resized_widthoriginal_image_width, model_typeqwen25vl, ) print(parsing_response_to_pyautogui_code(parsed, image_heightoriginal_image_height, image_widthoriginal_image_width))运行后你会看到一段import pyautogui加pyautogui.click(x, y, buttonleft)的代码坐标已换算成原始分辨率下的真实像素。坐标这一步最容易踩坑。Qwen 2.5-VL 系模型输出绝对坐标但模型看到的图是被 smart_resize 调整过的要先把输出坐标按缩放后尺寸归一化、再乘回原图尺寸才能点对位置。这段换算可以单独验证from ui_tars.action_parser import smart_resize model_output_width, model_output_height 197, 525 width, height 1920, 1080 new_height, new_width smart_resize(height, width) new_x int(model_output_width / new_width * width) new_y int(model_output_height / new_height * height) print(new_x, new_y)运行后打印出换算后的坐标标回截图上就能确认模型到底想点哪里完整推导和可视化见 README_coordinates.md。视觉模型 vs 传统选择器哪些场景值得切换判断要不要切到视觉驱动先看硬数字而不是感觉。元素定位精度上ScreenSpotPro 得分 UI-TARS-1.5 为 61.6OpenAI CUA 23.4、Claude 3.7 为 27.7ScreenSpot-V2 上 94.2OpenAI CUA 87.9。整任务完成率上Android World 64.2 对此前 59.5Windows Agent Arena50 步42.1 对 29.8。维度传统选择器Appium/EspressoUI-TARS 视觉驱动元素定位依赖 id / XPath / resource-id截图 坐标无需控件树界面改版适应性控件一变脚本作废视觉理解布局变化更鲁棒跨平台桌面 / 移动端各写一套统一动作空间一套框架非标准 / 自绘控件常无法识别像素级定位可点成本本地免费需 GPU7B 建议 L40S / A100要切换的信号很明确被测界面没有稳定控件树、自绘控件多、桌面与移动端都要覆盖、改版频繁。反向看纯 Web 端 UI-TARS 也并非全面领先——WebVoyager 上它 84.8OpenAI CUA 是 87两者接近7B 版本官方也说明未针对游戏场景优化重度游戏自动化要用完整 1.5 模型。谁适合用看完第一步做什么适合三类人一是做移动端 / 桌面回归与兼容性测试、选择器维护成本高的团队二是要同时覆盖桌面和手机的跨平台自动化三是被测对象自绘控件多、拿不到干净控件树的场景。看完可以直接做的三件事 装包并跑通上面的解析链路pip install ui-tars用一句模型响应验证坐标换算正确。 按目标平台选 prompt 模板手机任务用MOBILE_USE_DOUBAO桌面用COMPUTER_USE_DOUBAO只评 grounding 用GROUNDING_DOUBAO三个模板在 codes/ui_tars/prompt.py 里。 把坐标处理接进自己的执行层先看仓库的坐标处理文档确认红点落在预期按钮上再接自动化执行。需要源码时git clone https://gitcode.com/GitHub_Trending/ui/UI-TARS本地或 HuggingFace Endpoint 部署二选一7B 模型建议 L40S / A100 级别 GPU。那天卡住的第 12 天回归瓶颈不在写脚本而在点没点对。把上面两段代码跑通你第一次视觉驱动的回归只需换掉定位那一段模型看图、给出坐标、解析成 pyautogui剩下交给执行层。先拿一个最熟悉的页面试确认红点落在按钮上再往整个流程推。【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考