移动端自动化测试新范式：LLM视觉理解与Agent框架的分工协同

上一次写到移动端自动化的时候，我们还在纠结怎么让大模型稳定地找到那个“登录”按钮。这次聊的是两条相对成型的路线：一个是 Mobile-Agent-v3 这种通用智能体框架直接拿来做测试执行，另一个是我们自己折腾的 GUI-Owl 视觉理解模型。这两个名字最近在我们这边出现频率很高，如果你在关注 LLM 自动化测试，大概率也会遇到类似的选择题——直接用别人的 Agent 框架，还是从 GUI 理解层自己造轮子。

先说结论我再展开：两条路线不是替代关系，而是分工关系。Mobile-Agent-v3 解决的是“怎么指挥机器动手”，GUI-Owl 解决的是“机器到底看清了没有”。这两件事在移动端自动化里经常被混为一谈，但实际拆开做的时候，你会发现它们各自有一套完全独立的难点。这篇文章把我们在模拟项目 X 和几个跨平台系统里的实测过程、踩坑记录、选型逻辑都整理出来，希望能帮你少走一点弯路。

1. 为什么移动端自动化比 Web 端更依赖 LLM 的“视觉”

1.1 移动端自动化的三个痛点：层级爆炸、控件漂移、多平台碎片化

做 Web 自动化的时候，我们惯用的思路是定位 DOM 元素：id、class、XPath，只要前端结构不折腾，脚本稳定性就不错。但到了移动端，这套逻辑经常会失灵。首先是层级爆炸问题，原生 Android 的 View 树在复杂页面里能有三四百层，同一屏内容经常被拆成若干个嵌套布局，你靠 XPath 定位一个按钮，路径长到本身就是一个脆弱环节。小程序和 Flutter 这类跨端技术更夸张，很多情况下你拿到的不是标准控件树，而是一整块渲染后的画布，DOM 思维直接失效。

第二个痛点是控件漂移。移动端的 UI 改版频率高、发布周期短，今天还在的“我的”Tab，下个版本可能就把文案改成了“个人中心”，图标换了个样式。传统脚本的定位器本质上绑死的是“控件当前的长相”，一旦设计和交互改动，测试资产就变成一堆废代码。我们维护过一套旧的 Appium 用例，每次发版都要花半天修 selector，这个投入在快节奏的移动迭代里很难接受。

第三个痛点更难绕开，就是多平台碎片化。Android、iOS、鸿蒙、小程序、各种平板适配，每个平台的控件树格式、截图渲染方式、交互事件模拟机制都不一样。如果你给每个平台都写一套专用的定位逻辑，维护成本会直线上升。LLM 的思路之所以诱人，是因为它把“界面分析”这件事统一到了视觉语义层面，不管底层是哪个端，本质上都是“看一张截图”加“理解用户意图”，这套逻辑天然跨平台。

1.2 LLM 介入的角色定位：从“替代 XPath”到“替代测试用例编写者”

很多团队最开始用 LLM 做移动端自动化，想法很简单：让大模型帮我生成 Appium 脚本，把定位符写出来。这个方向我试过，效果一般。原因在于，大模型根据截图和 XML 生成静态脚本，本质上还是一次性预测，它并不知道运行之后屏幕上到底发生了什么。真正有价值的用法，是让 LLM 进入执行循环，像人一样观测、判断、行动、再观测，每一步都基于最新截图做决策，而不是离线生成一整套用例。

我在实际项目中验证下来，LLM 介入移动端自动化有两个不同的层级。低层级是替代定位器，让大模型从截图中找元素坐标，减少对 XML 的依赖。高层级是替代用例设计者，让大模型理解业务步骤，比如“进入设置页，打开 Wi-Fi，连接名为 test 的热点”，然后自己规划出操作序列。这两个层级并不互斥，但难度差很多。Mobile-Agent-v3 走的是比较完整的高层级路线，GUI-Owl 则先在低层级把“视觉基础能力”打扎实，再往上走。

1.3 两条路线的关系图谱：大脑与眼睛的分工

在我们团队内部，一直用“大脑”和“眼睛”来区分这两条线。Mobile-Agent-v3 作为大脑，负责意图理解、任务规划、错误恢复，它决定下一步该做什么。GUI-Owl 作为眼睛，负责把一张复杂截图解析成结构化的界面状态，告诉大脑：登录框在坐标 (540, 960)，密码框在 (540, 1120)，当前按钮是可点状态还是置灰状态。大脑可以更换，眼睛也可以更换，两者之间的接口是“结构化的界面状态描述”。

这个分工不是理论设计，而是被实践逼出来的。我们最早用一个通用多模态大模型同时承担规划与视觉理解，结果发现上下文窗口撑不住，长任务跑到一半就把前面的截图信息忘光了。后来改成定期压缩历史、让视觉模型单独负责识别，规划模型只处理概要信息，稳定性明显提升。这个经历让我意识到，移动端自动化里的模型选型，本质上是一个系统工程问题，不是单点模型能力问题。

2. Mobile-Agent-v3 框架拆解与实测

2.1 从 v1 到 v3：从“能执行”到“能纠错”

Mobile-Agent 这个系列我们是从 v1 开始跟进的。v1 的核心思路，是把移动操作任务建模成“指令理解 + 截图输入 + 操作输出”，模型直接输出点击、滑动、输入等高层操作原语。这个阶段最大的问题是容错率低，一旦模型输出不合法动作，或者截图理解偏差，整个任务就断掉，必须人工介入。

v2 改进的方向是增加了自我反思模块，让 Agent 在每次操作后重新观察截图，对比预期状态与实际状态，决定是继续、修正还是回溯。这个机制解决了一部分执行中途跑偏的问题。但我们实测发现，反思模块如果直接塞给通用大模型，它会开始“脑补”：明明截图里没有关键元素，模型却为了自洽，硬说看到了。这让反思本身变得不可靠。

v3 的架构我们拆开看，关键变化是把流程拆成了“预分析、分解、执行、反思、总结”的闭环，同时引入了更细粒度的环境观测。它不再要求模型一口气从任务描述直接跳到操作序列，而是先对任务做全局理解，拆成若干子步骤，每个子步骤走一遍“感知-决策-执行-校验”的循环。这样做的好处，是把长任务的错误局部化，某一步失败不会导致整体崩盘。我们在模拟项目 X 的支付流程上跑过，任务包含 14 个子步骤，中途模拟了一次网络延迟和一次页面弹窗遮挡，v3 这种分层结构能自己定位到失败动作并重试，成功率比单轮规划提升了接近一倍。

2.2 执行循环中的关键模块

我们把 Mobile-Agent-v3 的执行循环拆开，通常会看到四个关键模块：环境观测器、任务规划器、动作执行器、状态校验器。

环境观测器负责把当前的屏幕截图、控件层级、系统日志等信息统一处理成模型可读的上下文。这里有个细节值得注意：直接把原始 XML 塞给模型是不可行的，信息量太大、噪音太多，而且很多控件属性对任务决策没有帮助。v3 的做法通常会先做信号抽取，把可见文本、可点击元素、输入框类型等关键属性整理成结构化描述，再结合截图一起输入。这样既保留了视觉信息，又不会让上下文爆炸。

任务规划器负责把用户目标分解为子任务。我们在实践里发现，分解的粒度要跟执行反馈频率匹配：如果子任务太大，比如“完成整个购物流程”，模型很难判断当前进度；如果子任务太小，比如“点击坐标 (100, 200)”，模型又变成了笨拙的遥控器，失去了规划的灵活性。比较实用的粒度是“一个业务步骤”，比如“在搜索框输入关键词并点击搜索按钮”，这样一个动作组能在一次验证中完成，也便于回溯。

动作执行器负责把模型输出的高层动作翻译成真实系统调用。这里涉及一个很常见的坑：模型输出的动作类型和自动化框架支持的动作类型可能不对齐。比如模型说“长按图标”，但底层框架可能没有直接的长按封装，需要组合 touch 事件。我们这边的做法是维护一个动作映射层，把 Agent 可用的原语集合并集，每个原语有对应的 exec 实现和返回值反馈。

状态校验器是容错能力的关键。它的职责不是简单地检查“操作是否成功”，而是基于操作后的截图判断，预期界面状态是否出现。比如点击“登录”按钮后，校验器要判断是跳转到了首页、弹出了错误提示，还是界面没反应。这个判断如果做不好，后续的反思机制就会失去依据。我们一开始用通用模型做校验，后来发现它在“界面没反应”和“页面还在加载中”这两个状态之间经常混淆，最终还是在校验器前面加了一个 GUI-Owl 输出的等待状态标识，才算真正稳定下来。

2.3 用 Mobile-Agent-v3 跑移动测试的注意事项

如果你打算直接拿 Mobile-Agent-v3 这套思路跑移动端测试，有三个注意事项是我反复踩过之后总结出来的。

第一，模型输出必须强约束。不要让大模型自由发挥动作格式，我们用的是 JSON 模式加枚举校验，动作类型限定为有限集合，坐标必须在当前分辨率范围内。违反格式的输出直接重试，重试三次还不行就判定失败。没有这个约束，执行过程中会出现各类莫名其妙的问题，比如模型输出负坐标、输出不存在的 action、甚至把中文描述塞进参数字段。

第二，长任务必须定期压缩记忆。v3 这类框架在跑长流程时，会把每一步的截图和思考过程都留在上下文里，最多跑到 20 步左右，上下文就明显膨胀。我们的做法，是每完成一个子任务，就把前面的详细记录压缩成一条摘要，只保留关键状态变化和确认信息，这样模型既不会丢失进度，又能控制上下文长度。

第三，慎用并行执行。移动端自动化最怕的其实是并行任务互相干扰，因为同一个设备同一时间只能有一个前台应用。我们试过用多台设备分配不同 Agent 任务，效果尚可，但在同一台设备上并行执行两个任务，基本必挂。如果你的场景是多设备调度，要把设备锁和任务队列设计好，否则 Agent 本身跑得再稳，调度层面也会把你坑得够惨。

3. 自研 GUI-Owl 模型路线的得与失

3.1 为什么要自研 GUI 理解模型

在围观完 Mobile-Agent-v3 之后，团队里其实有过一个争论：通用多模态大模型的能力已经很强，为什么还要自研一个 GUI 专属的视觉理解模型？这个问题我一开始也是用怀疑的态度对待的，直到在实际测试里反复栽跟头，才想明白几个关键理由。

第一是成本。通用大模型的 API 调用本身不便宜，而移动端测试的特点是并发量高、反复执行频率高。一次自动化回归要跑几十条用例，每条用例十几步操作，每一步都要调用一次视觉模型，算下来成本非常可观。自研模型虽然前期投入大，但一旦训练完成，本地部署推理的边际成本几乎可以忽略。

第二是延迟和稳定性。公网 API 的延迟波动我们实测过，最差的时候单次视觉识别要等十几秒，这在自动化测试的流程里是致命的。自研模型可以部署在内网，单次识别延迟能控制在 1 秒以内，而且不依赖外部服务的稳定性。

第三是可定制的特定能力。我们需要的 GUI 理解跟通用图像理解不完全一样：它要能区分“可点击”和“不可点击”的视觉状态，要能识别控件之间的父子层级关系，还要能对 OCR 结果做版面聚类。这些能力在通用模型里不是没有，但要么精度不够，要么自带完整能力太宽泛而我们只用得到一小部分。自研的优势，是可以在评测基准上精准调优，把测试场景相关的指标拉满。

3.2 GUI-Owl 的结构设计

GUI-Owl 这个名字，我们想表达的是“专门盯着 GUI 看的猫头鹰”。它的设计思路，是不要把通用视觉模型拿过来直接微调，而是从任务需求出发，重新规划模型的能力结构。

我们最终采用了三阶段结构：视觉编码、控件检测、版面语义分析。视觉编码阶段用的还是常规的视觉 Transformer，但训练分辨率经过了专门调整。移动端截图的设备和分辨率差异很大，我们实验后发现 840 到 1000 像素区间的输入分辨率最平衡，既能保留小字体的识别精度，又不会导致显存和延迟失控。

控件检测阶段负责出候选框，找出截图里所有可能是可交互元素的位置。这一层我们训练了专门的检测头，输出元素类型、坐标框和置信度。一开始直接让模型回归坐标，结果小目标经常偏得离谱，后来改成基于密集采样的目标检测思路，把每个可点击区域当作一个实例来回归，精度才提上去。

版面语义分析阶段是 GUI-Owl 跟普通检测模型拉开差距的地方。它会把检测到的元素按照视觉布局组织成结构化关系，比如“居中弹窗包含两个按钮，标题文本为 xxx”。这一层之所以重要，是因为 Mobile-Agent-v3 这类 Agent 框架在执行规划时，需要的不是孤立的一堆坐标，而是页面结构层面的理解。界面状态不好描述，Agent 就没办法做出高质量、可解释的决策。

3.3 训练思路与开源数据利用

数据是整个自研过程中最磨人的环节。GUI 领域有一个很现实的问题：公共的标注数据集规模都不大，而且品类偏窄。我们整理了自己踩过的三轮数据迭代思路，应该比上来就闷头标注要高效不少。

第一轮是借助开源的无标注截图做自监督预训练。我们收集了大量 App 截图和移动端网页截图，不做手工标注，只让模型学习“同一控件在不同尺度下仍指向同一位置”这类一致性任务。这一步不需要人力，能显著提升模型对界面结构的敏感度。

第二轮是半自动生成标注。我们利用系统自带的无障碍节点信息，把屏幕上的可点击元素、文本节点、输入框类型自动导出来。在 Android 上，AccessibilityNodeInfo 基本能拿到控件类型和文本内容，坐标也能通过 SDK 换算得到。这样我们就绕过了最痛苦的手工框选步骤，能大批量生成训练数据。

第三轮才是人工精修。我们抽查自动标注结果，专门修正那些容易错的地方，比如弹窗遮罩被误识别为顶层可点击区域、某些自定义控件无法被无障碍树覆盖等。实测下来，三轮下来训练数据规模能做到百万量级，其中人工精修的比例大概控制在 5% 到 10%。这个比例是有意的——纯自动标注数据多了，模型的错误中带有系统性偏差。

3.4 实测收益与局限

GUI-Owl 上线后，我们的收益主要体现在三个指标上。第一个是界面状态解析的准确性，和通用模型相比，在误报率控制上我们自己的模型确实明显更好。第二个是推理延迟，本地部署之后，一次完整页面的控件解析可以做到 0.3 到 1.2 秒之间，这让 Agent 可以频繁执行“观察-思考-行动”循环，而不必担心拖慢整体节奏。第三个是可解释性，因为我们自己的模型可以输出版面结构树，Agent 执行出错时能反查是哪一步识别错了，这比对着一个黑盒 API 的输出猜原因要方便得多。

但 GUI-Owl 的局限也很明显。最大的问题，是它处理动态变化的界面能力有限。游戏场景、视频播放、复杂动画页面，这类界面里的元素不断在运动，静态截图模型很难给出稳定结果。我们一开始还尝试在游戏界面做自动化，后来发现投入产出比太低，暂时搁置了。

另一个局限是对文本语义的理解深度不够。GUI-Owl 能做 OCR，能识别文本内容，但它不理解文本背后的业务含义。比如一个按钮叫“下一步”，它还知道这是可点击的；但如果界面上有三个按钮都叫“下一步”，它就无法区分哪个才是当前业务步骤里真正要点的那个。这时候就需要 Mobile-Agent-v3 这种有规划能力的框架，结合上下文做决策。这也印证了我最初的想法：眼睛负责看，大脑负责想，两者缺一不可。

4. 两条路线的协同与选型建议

4.1 三条核心指标对比

我们在一次内部评审里，整理了 Mobile-Agent-v3 与自研 GUI-Owl 在不同指标上的表现。下面这个对比表格基本能反映两类方案在真实项目中的体验差异：

从这个表能看出来，两条路线的收益周期差异很大。Mobile-Agent-v3 适合快速验证，先跑通流程，再逐步提升稳定性。GUI-Owl 路线适合已经明确要做长期智能测试平台、且具备算法团队资源的情况。

4.2 组合打法的典型架构

我们最终采用的，是一个组合式架构，而不是二选一。整体流程可以用一句话概括：GUI-Owl 负责把截图变成结构化的界面描述，Mobile-Agent-v3 的规划模块负责基于界面描述做决策，动作执行和校验又回到 GUI-Owl 的检测结果上。

这个架构里有个关键解耦点：规划模块不直接看原始截图，它只看 GUI-Owl 输出的结构化界面描述。这样做的好处很明显，一是上下文量大幅减少，原来一张截图就是一个大 block 的图像 token，现在变成几百字的文本描述；二是规划模块的模型选型范围更宽，因为它不要求多模态能力，很多轻量级纯文本模型也能胜任。我们甚至实验过用一个中型纯文本模型做规划，效果不比直接调用多模态大模型差，成本却低了一个数量级。

校验模块也做了类似的解耦。执行动作后，Agent 重新拉取截图，GUI-Owl 解析出新状态，规划模块将新旧状态做对比，判断动作是否生效。这样就把“界面是否变化”的判断从纯视觉任务，简化成了结构化状态之间的比较，准确率明显更高。

4.3 落地时机怎么判断

管理一个测试技术团队，有时候最难的不是技术选型，而是时机判断。我给出的建议是分阶段走。

如果你刚接触 LLM 自动化测试，还没有成型的流程，建议先从 Mobile-Agent-v3 这类框架入手，直接在一个小业务模块里做验证。此时的目标是跑通“截图-决策-执行-校验”的闭环，并观察瓶颈到底出现在规划层还是感知层。很多时候你会惊讶地发现，问题根本不在模型，而在环境：设备连接不稳定、应用启动时间不可控、网络环境太乱，这些杂音会严重干扰模型判断。

只有当你确认了瓶颈，并且场景有足够的规模，比如每天要跑几百条用例、需要私有化部署、或者依赖外部大模型的成本已经不可接受的时候，再考虑启动 GUI-Owl 这样的自研路线。自研不是目的，是手段。如果团队没有模型训练的经验，我更建议先接开源小模型做适配，把数据管线跑通，再投入资源做真正意义上的预训练和微调。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

整个方案跑下来，我们积累了一些高频问题。很多问题刚出现的时候，排查起来特别费劲，这里列一个速查表，方便你遇到类似情况时直接对照。

5.2 一次典型排查实录：误点“自动更新”弹窗

说一个让我印象很深的案例。某个版本回归测试里，Agent 执行到支付流程前突然乱跑，连续点击了三个无关按钮。查日志发现 GUI-Owl 识别出了系统弹出的“自动更新”对话框，但这个对话框在开发环境里从来没有出现过，所以 Agent 的训练数据里缺少这类系统弹窗的样本。它不知道这个弹窗是什么，就错误地把它当作业务弹窗，点击了“确定”，结果跳到了应用市场。

这个问题的根本原因，是感知模型对系统级 UI 的覆盖不足。我们后面做两件事解决了：一是把系统弹窗、权限请求框等常见系统 UI 样本纳入训练集，二是给 Agent 增加一个规则过滤器，把不属于当前应用的顶层窗口标记为“阻断层”，不允许直接行动，而是先处理或者关闭它。这个规则过滤器看似简单，实际上对任务成功率的提升非常明显。

5.3 排查思路的三个原则

在大量的排查过程中，我总结出三个原则，也许对你有帮助。

第一，先分“感知错”还是“决策错”。同一个失败现象，可能来自感知层识别偏差，也可能是决策层的逻辑问题。判断方法很简单：把每一步的 GUI-Owl 输出单独回放，看识别结果是不是符合实际情况；如果符合实际问题出在决策，如果不符合问题出在感知。这一步先分清，能省下大半的排查时间。

第二，保留可复现的现场。每一条失败用例都要能回放当时的截图、模型输出、动作序列、系统日志。我们专门做了一个测试现场录制模块，每次 Agent 执行失败，会自动保存一份完整的时间线数据。没有这个基础，你每次排查都得凭现象猜原因，效率极低。

第三，不要过度拟合单个失败的用例。当一条用例反复失败时，你会很容易给它加一个特例分支，专门绕过那个问题。但这样做往往会让 Agent 的行为变得不可解释，甚至引入回归。我的建议，是在修复后先观察它在相似用例群上的表现，如果仍然有较高失败率，说明问题不在特例，而在于某个基础能力的缺失。

6. 后续扩展方向与个人体会

走到这一步，我们团队接下来的重点有三个。第一个是继续扩充 GUI-Owl 的端覆盖，把 iOS 和无障碍信息更少的平台纳入处理范围。目前 Android 端的无障碍节点相对较好，但 iOS 和小程序端的节点信息质量不稳定，我们需要更多针对性的训练数据。第二个是研究动作执行器的跨设备适配。当前动作执行最稳的是基于坐标模拟触摸，但在不同分辨率和不同机型的映射上还有优化空间。第三个是更细粒度的任务拆解策略，我们希望让 Mobile-Agent-v3 的规划模块学会根据界面变化动态调整子任务的粒度，而不是每次都用固定的拆分策略。

我个人这两轮踩下来最大的体会，是别迷信任何单一技术路线。Mobile-Agent-v3 这种框架的思维方式，本质上把“自动化测试”这件事从编写脚本变成了设计闭环流程，这是一个值得推广的转变。但闭环流程能不能跑得动，核心还是看感知层能不能给决策层提供足够准确、足够稳定的界面描述。如果没有这一层，再聪明的 Agent 也只是拿着模糊的眼镜在一片混乱里摸索。

至于选型，如果团队资源有限，我的建议是先走框架路线，把流程跑通，同时积累失败样本和评测数据。等数据量足够说明“问题主要出在视觉理解”这个结论时，再启动自研模型才是性价比最高的时候。如果你已经在自研路线上，也记得保留与 Agent 框架的接口能力，因为移动端自动化的最终形态一定不是一个模型单打独斗，而是一套相互配合的系统。

最后分享一个小技巧：无论是用现成框架还是自研模型，都把“截图回放”和“步骤级日志”当作基础设施来建设。这两个东西平时不起眼，但一旦系统跑起来，它们才是让你能持续迭代下去的真正底牌。