UI-TARS 点错位置怎么办GUI 自动化坐标定位的完整实战【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS光标明明落在了那个按钮上弹出来的却不是想要的菜单。用 UI-TARS 搭 GUI 自动化流程时这种“差一点就成功”的失败大多出在坐标定位这一环模型已经认出了目标元素但你的脚本真正点下去的位置偏了。好消息是这多数不是模型“眼神差”而是对模型输出的换算没做对。先看数据ScreenSpotPro 元素定位基准上 UI-TARS-1.5 得 61.6 分OpenAI CUA、Claude 3.7 分别是 23.4 和 27.7OSWorld 完整任务执行基准上是 42.5 对 36.4 对 28出自 README.md 的性能表。模型的定位底子够用坑在使用姿势。基准考察内容UI-TARS-1.5OpenAI CUAClaude 3.7ScreenSpotPro元素定位61.623.427.7OSWorld100 步完整任务执行42.536.428模型是怎么知道该点哪的UI-TARS 坐标定位机制一次说清核心就一句话模型报的不是你屏幕上的像素坐标而是“某张缩放后图像”上的坐标换算到你屏幕这步由你完成。第一关是坐标系。当前 UI-TARS 基于 Qwen2.5VL输出绝对坐标即喂给模型那张图上的像素位置更早的 Qwen2VL 输出相对坐标是 0–1000 的数值除以 factor1000得到比例。action_parser.py 源码注释直接写明 “Qwen2.5vl output absolute coordinates, qwen2vl output relative coordinates”解析函数会按 model_type 走两套不同换算这是你必须填对的开关。第二关是缩放。截图进模型前会先经过 smart_resize宽高被取整到 28代码常量 IMAGE_FACTOR的倍数总像素控制在 100×28×28 到 16384×28×28 之间同时尽量保住宽高比。所以模型报的坐标是相对缩放后的尺寸而言的想换回屏幕实际点位要用“原始尺寸 ÷ 缩放后尺寸”乘回去这一步最容易被忽略。第三块是提示模板。prompt.py 给了三份模板COMPUTER_USE 面向桌面Windows/Linux/macOS动作空间含 click、drag、hotkey、type、scroll 等MOBILE_USE 面向手机或 Android 模拟器多了 long_press、open_app、press_home 等移动端动作GROUNDING 只输出 Action 不带 Thought适合做纯定位评测。模板决定了模型允许使用的动作集合环境选错定位本身就可能跑偏。坐标定位验证与提升上线前做三件事验证的目标是区分“模型预测错了”和“换算错了”这两者的修法完全不同。把预测点画回截图一眼看出换算对不对做法不确定就别猜直接画。 怎么做README_coordinates.md 给了完整脚本——先用 smart_resize 算出缩放后尺寸再用“模型坐标 ÷ 缩放后尺寸 × 原始尺寸”换算最后用 matplotlib 在原图上打红点存成 som 图。 效果红点落在目标按钮里说明换算链路正确问题在模型预测红点偏了去查参数。十分钟就能把两类故障分开。把截图真实尺寸传给解析函数做法偏移最常见的来源是参数不是模型。 怎么做调用 parse_action_to_structure_output 时origin_resized_height / origin_resized_width 必须填喂给模型那张截图的真实像素尺寸model_type 要与实际模型一致parsed parse_action_to_structure_output( response, factor1000, origin_resized_height1080, origin_resized_width1920, model_typeqwen25vl, )效果qwen25vl 模式下解析器内部会用你传入的尺寸跑 smart_resize 再按比例缩放坐标。把显示器的逻辑分辨率填进来而截图是物理像素所有点击会整体偏一个系数任务从第一步起就废了。给坐标解析链路挂上单元测试做法换算验证通过后用测试把这个正确结果固定下来防止后续改动悄悄弄坏。 怎么做仓库的 action_parser_test.py 已有最小模板——喂一条 click 文本断言 action_type 是 click、解析结果里有 start_box。你实际用到的每类动作drag、scroll、type各补一个用例就是全链路的回归网text Thought: test\nAction: click(pointpoint200 300/point) actions parse_action_to_structure_output( text, factor1000, origin_resized_height224, origin_resized_width224 )效果换提示词或升级模型后先跑一遍测试套件能立刻分清是“模型变了”还是“解析代码坏了”排查时间大幅缩短。UI-TARS 坐标排坑四条“现象—原因—解法”速查现象所有点击整体偏移几十到几百像素。原因origin_resized_height/width 填了逻辑分辨率而截图是物理像素或反过来。解法打印 img.size 核对传截图真实尺寸。现象同一套代码一台机器正常另一台系统性偏移。原因系统显示缩放125%、150%让截图像素与光标系统坐标不一致。解法让截图与鼠标操作走同一坐标系并在目标机上用红点法复验。现象点在屏幕右下角光标却飞到左上角。原因model_type 配错绝对坐标被按相对坐标除以 factor1000。解法Qwen2.5VL 系模型用 model_typeqwen25vl。现象parse_action_to_structure_output 抛出 Action cant parse。原因模型输出缺右括号或格式破损。解法打印原始 response 检查格式单次生成异常就重试。先可视化再上线完整部署流程见 README_deploy.md坐标换算的完整实现在 action_parser.py。下次搭自动化流程时先把红点画出来——十分钟的验证成本远低于一整天调点错位的代价。【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 UI-TARS 点错位置怎么办：GUI 自动化坐标定位的完整实战
UI-TARS 点错位置怎么办GUI 自动化坐标定位的完整实战【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS光标明明落在了那个按钮上弹出来的却不是想要的菜单。用 UI-TARS 搭 GUI 自动化流程时这种“差一点就成功”的失败大多出在坐标定位这一环模型已经认出了目标元素但你的脚本真正点下去的位置偏了。好消息是这多数不是模型“眼神差”而是对模型输出的换算没做对。先看数据ScreenSpotPro 元素定位基准上 UI-TARS-1.5 得 61.6 分OpenAI CUA、Claude 3.7 分别是 23.4 和 27.7OSWorld 完整任务执行基准上是 42.5 对 36.4 对 28出自 README.md 的性能表。模型的定位底子够用坑在使用姿势。基准考察内容UI-TARS-1.5OpenAI CUAClaude 3.7ScreenSpotPro元素定位61.623.427.7OSWorld100 步完整任务执行42.536.428模型是怎么知道该点哪的UI-TARS 坐标定位机制一次说清核心就一句话模型报的不是你屏幕上的像素坐标而是“某张缩放后图像”上的坐标换算到你屏幕这步由你完成。第一关是坐标系。当前 UI-TARS 基于 Qwen2.5VL输出绝对坐标即喂给模型那张图上的像素位置更早的 Qwen2VL 输出相对坐标是 0–1000 的数值除以 factor1000得到比例。action_parser.py 源码注释直接写明 “Qwen2.5vl output absolute coordinates, qwen2vl output relative coordinates”解析函数会按 model_type 走两套不同换算这是你必须填对的开关。第二关是缩放。截图进模型前会先经过 smart_resize宽高被取整到 28代码常量 IMAGE_FACTOR的倍数总像素控制在 100×28×28 到 16384×28×28 之间同时尽量保住宽高比。所以模型报的坐标是相对缩放后的尺寸而言的想换回屏幕实际点位要用“原始尺寸 ÷ 缩放后尺寸”乘回去这一步最容易被忽略。第三块是提示模板。prompt.py 给了三份模板COMPUTER_USE 面向桌面Windows/Linux/macOS动作空间含 click、drag、hotkey、type、scroll 等MOBILE_USE 面向手机或 Android 模拟器多了 long_press、open_app、press_home 等移动端动作GROUNDING 只输出 Action 不带 Thought适合做纯定位评测。模板决定了模型允许使用的动作集合环境选错定位本身就可能跑偏。坐标定位验证与提升上线前做三件事验证的目标是区分“模型预测错了”和“换算错了”这两者的修法完全不同。把预测点画回截图一眼看出换算对不对做法不确定就别猜直接画。 怎么做README_coordinates.md 给了完整脚本——先用 smart_resize 算出缩放后尺寸再用“模型坐标 ÷ 缩放后尺寸 × 原始尺寸”换算最后用 matplotlib 在原图上打红点存成 som 图。 效果红点落在目标按钮里说明换算链路正确问题在模型预测红点偏了去查参数。十分钟就能把两类故障分开。把截图真实尺寸传给解析函数做法偏移最常见的来源是参数不是模型。 怎么做调用 parse_action_to_structure_output 时origin_resized_height / origin_resized_width 必须填喂给模型那张截图的真实像素尺寸model_type 要与实际模型一致parsed parse_action_to_structure_output( response, factor1000, origin_resized_height1080, origin_resized_width1920, model_typeqwen25vl, )效果qwen25vl 模式下解析器内部会用你传入的尺寸跑 smart_resize 再按比例缩放坐标。把显示器的逻辑分辨率填进来而截图是物理像素所有点击会整体偏一个系数任务从第一步起就废了。给坐标解析链路挂上单元测试做法换算验证通过后用测试把这个正确结果固定下来防止后续改动悄悄弄坏。 怎么做仓库的 action_parser_test.py 已有最小模板——喂一条 click 文本断言 action_type 是 click、解析结果里有 start_box。你实际用到的每类动作drag、scroll、type各补一个用例就是全链路的回归网text Thought: test\nAction: click(pointpoint200 300/point) actions parse_action_to_structure_output( text, factor1000, origin_resized_height224, origin_resized_width224 )效果换提示词或升级模型后先跑一遍测试套件能立刻分清是“模型变了”还是“解析代码坏了”排查时间大幅缩短。UI-TARS 坐标排坑四条“现象—原因—解法”速查现象所有点击整体偏移几十到几百像素。原因origin_resized_height/width 填了逻辑分辨率而截图是物理像素或反过来。解法打印 img.size 核对传截图真实尺寸。现象同一套代码一台机器正常另一台系统性偏移。原因系统显示缩放125%、150%让截图像素与光标系统坐标不一致。解法让截图与鼠标操作走同一坐标系并在目标机上用红点法复验。现象点在屏幕右下角光标却飞到左上角。原因model_type 配错绝对坐标被按相对坐标除以 factor1000。解法Qwen2.5VL 系模型用 model_typeqwen25vl。现象parse_action_to_structure_output 抛出 Action cant parse。原因模型输出缺右括号或格式破损。解法打印原始 response 检查格式单次生成异常就重试。先可视化再上线完整部署流程见 README_deploy.md坐标换算的完整实现在 action_parser.py。下次搭自动化流程时先把红点画出来——十分钟的验证成本远低于一整天调点错位的代价。【免费下载链接】UI-TARSPioneering Automated GUI Interaction with Native Agents项目地址: https://gitcode.com/GitHub_Trending/ui/UI-TARS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考