尧图网站建设 
UI-TARS 实践用视觉模型驱动 Android 自动化测试【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS把 Android 真机连上电脑截一张 App 登录页把图交给 UI-TARS三行 prompt 就能让它把登录点完。这篇带你看清这条视觉驱动的自动化测试链路怎么搭、哪些环节会翻车。从截图到动作UI-TARS 的视觉驱动执行链路先建立心智模型再谈怎么跑。整条链路是五个环节咬合的截图输入抓一张当前屏幕的原始像素图VLM 理解界面把图丢给视觉语言模型这里是 UI-TARS-1.5模型看到按钮、输入框这些控件生成动作指令模型先写一段Thought计划再给出一行Action如click(start_box...)坐标解析把模型报的像素坐标归一化再乘回原图尺寸得到真正要点的像素设备执行把坐标喂给pyautogui桌面或adb input tap手机执行后重新截图进入下一轮。关键点在第 4 步模型不是在原图坐标系上报告位置而是在一张被智能缩放后的图上报告所以坐标必须还原一次。UI-TARS 官方把这套感知、动作、推理拆成了分层结构安装 ui-tars 并跑通第一个解析用例这里有个容易踩的坑PyPI 上的ui-tars包只做后半段——解析模型文本、换算坐标、生成pyautogui代码。它不帮你截图、也不直接调模型模型本身要另外部署HuggingFace Endpoint 或本地。所以跑通第一个用例先验证这条解析链路而不是端到端操作手机。先装包一条命令即可pip install ui-tars下面用一个假的模型响应跑一遍解析和代码生成确认装对了from ui_tars.action_parser import ( parse_action_to_structure_output, parsing_response_to_pyautogui_code, ) # 模型返回的一条典型响应Thought Action response Thought: 登录按钮在屏幕中下方\nAction: click(start_box(540,1873)) w, h 1080, 2400 # ← 你的设备实际值宽, 高 actions parse_action_to_structure_output( response, factor1000, origin_resized_heighth, origin_resized_widthw, model_typeqwen25vl, ) print(actions[0][action_type], actions[0][action_inputs]) # 期望看到 click 归一化 start_box print(parsing_response_to_pyautogui_code(actions, image_heighth, image_widthw))成功的信号第一行打印出click和一个[x, y, x, y]形式的归一化坐标第二行打印出一段以pyautogui.click(...)结尾的脚本。能看到这两行说明解析与坐标换算都通了。核心机制拆解动作空间、Prompt 模板与坐标映射这一节按模块讲重点看每个齿轮和相邻齿轮怎么咬合而不是罗列亮点。动作空间定义输入是模型被允许使用的操作集合输出是模型只能从这个集合里挑的动作。移动端模板MOBILE_USE_DOUBAO里列了click(point...)、long_press(point...)、type(content...)、scroll(point..., direction...)、open_app(app_name...)、drag(start_point..., end_point...)、press_home()、press_back()、finished(content...)。边界模板里没有swipe横向/纵向拖拽只能用drag表达写swipe会被解析器当未知动作丢弃。Prompt 模板输入是模板字符串加任务指令输出是发给模型的 system prompt。直接从ui_tars.prompt拿现成常量移动端用MOBILE_USE_DOUBAO它有两个占位符{language}和{instruction}把任务描述填进{instruction}即可桌面端换COMPUTER_USE_DOUBAO。注意占位符不填全会让Thought的语言和任务描述不确定建议显式format后再发。坐标映射输入是原始截图宽高输出是归一化坐标与可落地的像素点。这一步最容易出错用仓库自带函数算一遍from ui_tars.action_parser import smart_resize w, h 1080, 2400 # ← 原始截图宽高 rh, rw smart_resize(h, w) # 模型实际看到的尺寸两边都是 28 的倍数 nx, ny 540 / rw, 1873 / rh # 模型在 rw×rh 空间报 (540,1873)先归一化 px, py nx * w, ny * h # 再乘回原图得到真正要点的像素 print(px, py)边界只有当你发给模型的图确实被缩放到smart_resize算出的尺寸时坐标才准。如果你自己改过图再发映射就整体偏移得人工校准。响应解析输入是模型原始文本输出是结构化 dict含action_type、action_inputs、thought。from ui_tars.action_parser import parse_action_to_structure_output as P resp Thought: 登录按钮在中下方\nAction: click(start_box(540,1873)) a P(resp, factor1000, origin_resized_height2400, origin_resized_width1080, model_typeqwen25vl) print(a[0][action_type], a[0][action_inputs]) # click 与归一化 start_box边界factor参数只对非qwen25vl的模型生效qwen25vl 走上面的smart_resize路径type(content...)里若带单引号/换行解析器会尝试转义但复杂转义仍可能失败需要兜底。一次完整登录走查从截图到执行验证以自动登录为例按五步走重点看每一步为什么这么做。1. 输入抓一张登录页截图1080×2400把MOBILE_USE_DOUBAO.format(instruction启动某 App输入账号 demo_user 和密码点登录, language中文)连同截图发给模型。这里指令要写清账号/密码是什么因为模型不会猜。2. 模型原始响应模型先给一段Thought账号密码已填好登录按钮在中下方再给一行Action: click(start_box(540,1873))。这是文本还不能直接执行。3. 解析成结构化动作from ui_tars.action_parser import parse_action_to_structure_output w, h 1080, 2400 # ← 你的设备实际值宽, 高 step Thought: 账号密码已填好登录按钮在中下方\nAction: click(start_box(540,1873)) a parse_action_to_structure_output( step, factor1000, origin_resized_heighth, origin_resized_widthw, model_typeqwen25vl) box eval(a[0][action_inputs][start_box]) # 归一化 [x, y, x, y] x, y int(box[0] * w), int(box[1] * h) # 还原到原图像素 print(adb shell input tap, x, y) # 移动端用 adb 落地为什么这么做解析出的start_box是归一化值乘回原图宽高才得到adb能直接用的整数坐标。桌面环境则把这步换成parsing_response_to_pyautogui_code坐标完全一样。4. 执行把x, y交给adb shell input tap x y手机或pyautogui.click(x, y)桌面type类动作则直接落content不需要坐标。执行后重新截图作为下一轮输入。5. 结果验证不要相信模型说自己登录成功了。截新图用肉眼或一个简单的像素/文本断言确认登录页已消失、进入了主页才算这步通过。基准数据与当前局限先说数字均来自官方 README 的在线基准100 步以内、temperature 接近 0 的评估条件Android WorldPhone Use55 个任务UI-TARS-1.5 拿到64.2前 SOTA 为 59.5OSWorldComputer Use100 步42.5前 SOTA 38.1ScreenSpot-V2 / ScreenSpotPro纯定位94.2 / 61.6。但它目前做不好的事也得摆出来误识别与幻觉官方 Limitations 明确写模型在模糊或陌生界面里会给出错误描述、点错元素、或基于错误推断采取次优动作。算力开销7B 模型推理吃 GPU长流程里单步延迟和成本都上得去不适合高频批量跑。场景偏科开源的 UI-TARS-1.5-7B 主打通用电脑/手机操作没针对游戏场景优化游戏上更大版本的 1.5 才占优WebView 内嵌表单、CAPTCHA 这类仍是重灾区甚至官方单独提示它能绕验证码带来的滥用风险。生产环境落地注意事项重试与退避关键步骤失败别立刻放弃重试 2~3 次并指数退避连续失败就整轮重截图重来避免在错误页面上继续叠加操作。坐标偏移校准真机常有状态栏/导航栏吃掉一部分像素上线前用一两个已知按钮标定一次偏移量offset_x/offset_y再统一加回去。多分辨率适配务必把真实截图宽高传进origin_resized_*并保证发给模型的图与smart_resize算出的尺寸一致换机型只改w, h其余逻辑不动。超时与兜底每步设推理和执行的超时type解析失败或坐标越界时落到一个默认动作如press_back回退而不是直接崩。日志与可观测把每一步的Thought、Action、解析后的坐标都记下来配合截图存盘出错时能回放到底哪一步偏了。⚠ 注意pyautogui生成的脚本默认time.sleep(1)真机执行前确认延迟够用否则会点太快。它是目前最接近看截图就能操作手机的开源视觉方案。想快速感受装上包后把上面第一节的 smoke 测试贴进终端跑一遍看打印出的click与坐标。核心源码codes/ui_tars/ 部署文档README_deploy.md 测试数据data/test_messages.json【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 UI-TARS 实践：用视觉模型驱动 Android 自动化测试
UI-TARS 实践用视觉模型驱动 Android 自动化测试【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS把 Android 真机连上电脑截一张 App 登录页把图交给 UI-TARS三行 prompt 就能让它把登录点完。这篇带你看清这条视觉驱动的自动化测试链路怎么搭、哪些环节会翻车。从截图到动作UI-TARS 的视觉驱动执行链路先建立心智模型再谈怎么跑。整条链路是五个环节咬合的截图输入抓一张当前屏幕的原始像素图VLM 理解界面把图丢给视觉语言模型这里是 UI-TARS-1.5模型看到按钮、输入框这些控件生成动作指令模型先写一段Thought计划再给出一行Action如click(start_box...)坐标解析把模型报的像素坐标归一化再乘回原图尺寸得到真正要点的像素设备执行把坐标喂给pyautogui桌面或adb input tap手机执行后重新截图进入下一轮。关键点在第 4 步模型不是在原图坐标系上报告位置而是在一张被智能缩放后的图上报告所以坐标必须还原一次。UI-TARS 官方把这套感知、动作、推理拆成了分层结构安装 ui-tars 并跑通第一个解析用例这里有个容易踩的坑PyPI 上的ui-tars包只做后半段——解析模型文本、换算坐标、生成pyautogui代码。它不帮你截图、也不直接调模型模型本身要另外部署HuggingFace Endpoint 或本地。所以跑通第一个用例先验证这条解析链路而不是端到端操作手机。先装包一条命令即可pip install ui-tars下面用一个假的模型响应跑一遍解析和代码生成确认装对了from ui_tars.action_parser import ( parse_action_to_structure_output, parsing_response_to_pyautogui_code, ) # 模型返回的一条典型响应Thought Action response Thought: 登录按钮在屏幕中下方\nAction: click(start_box(540,1873)) w, h 1080, 2400 # ← 你的设备实际值宽, 高 actions parse_action_to_structure_output( response, factor1000, origin_resized_heighth, origin_resized_widthw, model_typeqwen25vl, ) print(actions[0][action_type], actions[0][action_inputs]) # 期望看到 click 归一化 start_box print(parsing_response_to_pyautogui_code(actions, image_heighth, image_widthw))成功的信号第一行打印出click和一个[x, y, x, y]形式的归一化坐标第二行打印出一段以pyautogui.click(...)结尾的脚本。能看到这两行说明解析与坐标换算都通了。核心机制拆解动作空间、Prompt 模板与坐标映射这一节按模块讲重点看每个齿轮和相邻齿轮怎么咬合而不是罗列亮点。动作空间定义输入是模型被允许使用的操作集合输出是模型只能从这个集合里挑的动作。移动端模板MOBILE_USE_DOUBAO里列了click(point...)、long_press(point...)、type(content...)、scroll(point..., direction...)、open_app(app_name...)、drag(start_point..., end_point...)、press_home()、press_back()、finished(content...)。边界模板里没有swipe横向/纵向拖拽只能用drag表达写swipe会被解析器当未知动作丢弃。Prompt 模板输入是模板字符串加任务指令输出是发给模型的 system prompt。直接从ui_tars.prompt拿现成常量移动端用MOBILE_USE_DOUBAO它有两个占位符{language}和{instruction}把任务描述填进{instruction}即可桌面端换COMPUTER_USE_DOUBAO。注意占位符不填全会让Thought的语言和任务描述不确定建议显式format后再发。坐标映射输入是原始截图宽高输出是归一化坐标与可落地的像素点。这一步最容易出错用仓库自带函数算一遍from ui_tars.action_parser import smart_resize w, h 1080, 2400 # ← 原始截图宽高 rh, rw smart_resize(h, w) # 模型实际看到的尺寸两边都是 28 的倍数 nx, ny 540 / rw, 1873 / rh # 模型在 rw×rh 空间报 (540,1873)先归一化 px, py nx * w, ny * h # 再乘回原图得到真正要点的像素 print(px, py)边界只有当你发给模型的图确实被缩放到smart_resize算出的尺寸时坐标才准。如果你自己改过图再发映射就整体偏移得人工校准。响应解析输入是模型原始文本输出是结构化 dict含action_type、action_inputs、thought。from ui_tars.action_parser import parse_action_to_structure_output as P resp Thought: 登录按钮在中下方\nAction: click(start_box(540,1873)) a P(resp, factor1000, origin_resized_height2400, origin_resized_width1080, model_typeqwen25vl) print(a[0][action_type], a[0][action_inputs]) # click 与归一化 start_box边界factor参数只对非qwen25vl的模型生效qwen25vl 走上面的smart_resize路径type(content...)里若带单引号/换行解析器会尝试转义但复杂转义仍可能失败需要兜底。一次完整登录走查从截图到执行验证以自动登录为例按五步走重点看每一步为什么这么做。1. 输入抓一张登录页截图1080×2400把MOBILE_USE_DOUBAO.format(instruction启动某 App输入账号 demo_user 和密码点登录, language中文)连同截图发给模型。这里指令要写清账号/密码是什么因为模型不会猜。2. 模型原始响应模型先给一段Thought账号密码已填好登录按钮在中下方再给一行Action: click(start_box(540,1873))。这是文本还不能直接执行。3. 解析成结构化动作from ui_tars.action_parser import parse_action_to_structure_output w, h 1080, 2400 # ← 你的设备实际值宽, 高 step Thought: 账号密码已填好登录按钮在中下方\nAction: click(start_box(540,1873)) a parse_action_to_structure_output( step, factor1000, origin_resized_heighth, origin_resized_widthw, model_typeqwen25vl) box eval(a[0][action_inputs][start_box]) # 归一化 [x, y, x, y] x, y int(box[0] * w), int(box[1] * h) # 还原到原图像素 print(adb shell input tap, x, y) # 移动端用 adb 落地为什么这么做解析出的start_box是归一化值乘回原图宽高才得到adb能直接用的整数坐标。桌面环境则把这步换成parsing_response_to_pyautogui_code坐标完全一样。4. 执行把x, y交给adb shell input tap x y手机或pyautogui.click(x, y)桌面type类动作则直接落content不需要坐标。执行后重新截图作为下一轮输入。5. 结果验证不要相信模型说自己登录成功了。截新图用肉眼或一个简单的像素/文本断言确认登录页已消失、进入了主页才算这步通过。基准数据与当前局限先说数字均来自官方 README 的在线基准100 步以内、temperature 接近 0 的评估条件Android WorldPhone Use55 个任务UI-TARS-1.5 拿到64.2前 SOTA 为 59.5OSWorldComputer Use100 步42.5前 SOTA 38.1ScreenSpot-V2 / ScreenSpotPro纯定位94.2 / 61.6。但它目前做不好的事也得摆出来误识别与幻觉官方 Limitations 明确写模型在模糊或陌生界面里会给出错误描述、点错元素、或基于错误推断采取次优动作。算力开销7B 模型推理吃 GPU长流程里单步延迟和成本都上得去不适合高频批量跑。场景偏科开源的 UI-TARS-1.5-7B 主打通用电脑/手机操作没针对游戏场景优化游戏上更大版本的 1.5 才占优WebView 内嵌表单、CAPTCHA 这类仍是重灾区甚至官方单独提示它能绕验证码带来的滥用风险。生产环境落地注意事项重试与退避关键步骤失败别立刻放弃重试 2~3 次并指数退避连续失败就整轮重截图重来避免在错误页面上继续叠加操作。坐标偏移校准真机常有状态栏/导航栏吃掉一部分像素上线前用一两个已知按钮标定一次偏移量offset_x/offset_y再统一加回去。多分辨率适配务必把真实截图宽高传进origin_resized_*并保证发给模型的图与smart_resize算出的尺寸一致换机型只改w, h其余逻辑不动。超时与兜底每步设推理和执行的超时type解析失败或坐标越界时落到一个默认动作如press_back回退而不是直接崩。日志与可观测把每一步的Thought、Action、解析后的坐标都记下来配合截图存盘出错时能回放到底哪一步偏了。⚠ 注意pyautogui生成的脚本默认time.sleep(1)真机执行前确认延迟够用否则会点太快。它是目前最接近看截图就能操作手机的开源视觉方案。想快速感受装上包后把上面第一节的 smoke 测试贴进终端跑一遍看打印出的click与坐标。核心源码codes/ui_tars/ 部署文档README_deploy.md 测试数据data/test_messages.json【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考