目前，最新版本的Midscene.js已适配了至少五种知名的多模态大模型，包括GPT-4o、Qwen-2.5-VL、UI-TARS、Gemini-2.5-Pro、Doubao-1.5-thinking-vision-pro等。这些模型主要分为两大类：
1. 通用多模态 LLM：接受文本和图像输入的模型，比如GPT-4o 。
2. 支持视觉定位的 VL 模型：除了接受文本和图像输入外，模型还可以给出指定元素的坐标信息（Visual Grounding），包括 Qwen-2.5-VL, Gemini-2.5-Pro， Doubao-1.5-thinking-vision-pro 和 UI-TARS。
这两种模型的主要区别在于是否具有视觉定位（Visual Grounding）的能力。接下来详细解读一下这两种不同模型定位元素的原理：
GPT-4o
Midscene刚推出时，主要适配的是GPT-4o。这种模型使用采用元素标记（Element Markup）的方式来定位界面元素。当需要定位界面元素时，Midscene会给GPT-4o发送两种信息：
● 从DOM提取的关键信息
● 添加了视觉标记的页面截图
从DOM提取关键信息的方法
DOM提取过程通过深度优先搜索（DFS）遍历整个DOM树，这个函数会递归遍历DOM节点，为每个有意义的元素收集信息。Midscene提取的关键DOM信息包括：
● 元素标识：唯一哈希ID、索引ID
● 元素类型：文本、按钮、图片、链接、容器等
● 位置信息：边界框坐标、中心点坐标
● 内容信息：文本内容、属性信息
● 状态信息：可见性、缩放比例
● 结构信息：HTML标签名、节点层级关系
提取的DOM信息会被转换为AI模型可理解的格式：
1. 首先将DOM树转换为扁平化的元素列表
2. 然后创建元素ID到元素对象的映射
3. 接下来生成页面描述文本，包含页面尺寸和元素树结构
4. 最后提供按ID和位置查找元素的方法
为页面截图添加视觉标记的方法
Midscene使用可视化组件在截图上添加元素标记。这个过程主要通过Blackboard组件实现，这一组件使用PIXI.js图形引擎在截图上叠加视觉标记。元素标记的生成过程会遍历从DOM提取的所有元素，为每个元素创建矩形标记，然后根据元素类型应用不同的颜色和样式，并将标记添加到相应的容器中。
对于GPT-4o，Midscene使用专门的提示词模板，这个提示词会要求模型分析截图和元素描述信息，然后根据用户描述定位目标元素，最后返回包含选择理由和元素ID的JSON数据。
从原理上看，GPT-4o的局限性在于：
1. 成本很高：每次需要同时发送界面截图和DOM树，这会消耗更多的Token，效率也很低；
2. 内容限制：它无法处理跨域的 <iframe /> 或 <canvas /> 标签中的内容。
3. 分辨率限制：它无法处理分辨率超过 2000x768 的图像，超尺寸输入会导致输出质量下降。
4. 不支持 Android 自动化：它不支持 Android 自动化。因为现实场景中的 Android 应用的 UI 结构非常复杂，在其 UI 技术栈上做适配工作的难度太大。因此在Android 自动化场景中，Midscene官方决定只适配支持视觉定位的 VLM 模型。
Qwen-VL
在适配了具有原生视觉定位能力的模型之后，Midscene只需发送截图给VLM模型，而不需要发送DOM树信息，这使得token使用量比之前减少了30-50%。这些模型使用视觉定位能力直接从截图中识别元素位置，返回边界框坐标。比如，Qwen-VL返回的坐标格式为 [xmin, ymin, xmax, ymax]。
此外，在调用Qwen-VL时，Midscene还会设置特殊的配置参数，如 `vl_high_resolution_images: true` 以支持高分辨率图像处理。
从原理上看，使用Qwen-VL有如下优势：
1.低成本：和 gpt-4o 相比，它可以节省 30% 到 50% 的 token 数量。在阿里云官方部署版本中，费用消耗可以下降 80% 以上。
2.高分辨率支持：Qwen-2.5-VL 支持更高的分辨率输入，足以满足大多数情况。
3.开源：这是一个开源模型，因此你可以选择使用云提供商已经部署好的版本，或者自己部署到你自己的服务器上。
Midscene官方指出，Qwen-VL 的缺点在于小图标识别能力较差和断言能力不足。不过根据我的实测体验来看，模型这两种能力是相当不错的，足以支持大部分基础的自动化测试场景。
UI-TARS
之前我写过一篇文章介绍过UI-TARS，这是一个专为GUI 任务而生的智能体模型。它也具备优秀的原生视觉定位能力，因此仅需要以截图作为输入。它很擅长执行人类常用的交互（如键盘和鼠标操作），在多个 GUI 基准测试中取得了顶尖性能。而且它也是一个开源模型，并提供了不同大小的版本，其中UI-TARS-1.5还具有深度思考的能力，在复杂任务（如“订最便宜的机票”）中会分解步骤、规划路径，甚至发现错误后自我纠正。
和Qwen-VL要求详细具体的操作步骤不同，在 UI-TARS 中推荐使用目标驱动的提示词（target-driven prompt），如“使用用户名 foo 和密码 bar 登录”，它会逐步完成动作规划并执行。
UI-TARS和Qwen-VL最显著的区别在于动作规划机制：
Qwen-VL的规划机制
Qwen-VL主要使用传统的LLM规划方式 。它的规划特点是：
- 单次规划：通常进行一次性的步骤规划，而不是循环式的动态规划
- 基于提示模板：使用不同的系统提示模板来指导规划过程
- 坐标适配：使用adaptQwenBbox函数处理特定的坐标格式
UI-TARS的动作规划机制
UI-TARS具有完整的端到端动作规划能力。它使用专门的vlmPlanning函数进行规划，并通过actionToGoal方法实现目标驱动的多步骤规划 。
UI-TARS的规划过程包括：
- 循环规划执行：通过while循环持续规划直到任务完成，最多执行40步
- 动作转换：将模型输出的原始动作转换为可执行的操作序列，支持点击、拖拽、输入、滚动等多种动作类型
- 坐标处理：使用convertBboxToCoordinates函数将边界框转换为精确坐标
使用UI-TARS有这些优势：
1. 适用于探索性场景：UI-TARS 在开放性任务场景中表现出色，例如 “帮我发一条微博”这种模糊的表述，它能多次进行尝试，直到找到正确的操作步骤。
2. 速度：以火山引擎部署的 doubao-1.5-ui-tars 作为基准，它的返回速度快于其他模型。
3. 开源：UI-TARS 是一个开源模型，因此可以选择部署到你自己的服务器上。
4. 更简洁的测试脚本：目标驱动的提示词会比步骤驱动的提示词要简洁得多。
比如，对于登录操作，如果用Qwen-VL模型，建议编写这样的测试脚本：
await ai('在用户名输入框中输入admin'); await ai('在密码输入框中输入test123456'); await ai('输入验证码'); //AI会自己识别验证码是啥 await ai('点击登录按钮');而如果使用UI-TARS模型，只需要把脚本缩减为一句话：
await ai('使用账号admin和密码test123456登录系统');5.“自愈”能力：UI-TARS能够主动处理一些可能导致 UI 自动化测试失败的问题，比如发现页面延迟的时候进行智能等待，发现非预期弹框的时候主动关闭弹窗，以及操作失败时主动进行不同方式的重试。
不过，UI-TARS也存在一些不足：
1. “过度”智能：UI-TARS的“自主性”过强，有时会根据自己的经验判断做出一些超出使用者预期的行为。比如，在输入用户名和密码之后，哪怕脚本中还未指定下一步，UI-TARS也会主动点击登录按钮，这样的超前行为在某些场景下让人感到难以控制，为测试造成了不必要的麻烦。类似的，在一次操作失败后，UI-TARS会“执着地”进行反复探索和尝试，这也会消耗更多的Token。
2. 无法固定操作路径：UI-TARS 具备较强的探索能力，它可能会主动多次尝试不同的操作路径，这可能会导致每次调用时操作路径不固定。因此，如果对于自动化测试的可重复性要求较高的场景，不建议使用UI-TARS。
3. 断言能力较差：在某些情况下，UI-TARS 的断言能力可能不如 gpt-4o。根据实测体验，UI-TARS在某些情况下的文字识别精确度也不如Qwen-VL。
模型选型建议
● 需Android自动化/高分辨率/低成本：优先选择VL模型（如Qwen-VL、UI-TARS）而非GPT-4o。
● 任务明确且步骤固定：Qwen-VL类模型（提示词简单、成本可控）。
● 探索性/模糊任务（如“发微博”）：UI-TARS类模型（目标驱动提示词更简洁，支持自主尝试）。
● 需严格控制操作路径/高断言精度：谨慎选择UI-TARS（路径不固定、断言能力弱）；通用LLM（如GPT-4o）因Android适配限制，仅推荐非移动端场景。
