移动端自动化测试新范式：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 路线投入周期集成现有框架为主1-2周可出初版数据准备加训练调优通常按月为单位硬件要求依赖大模型推理资源商用 API 或高配 GPU专属小模型成本适中可私有化延迟较高多轮交互和通用模型推理叠加较低一次推理可换取完整结构化界面描述可解释性依赖模型自身输出差异较大输出结构化解析过程便于追溯定位容错恢复框架级重试和回溯机制本身不执行恢复动作只提供状态判定跨端能力任务规划层相对通用需要针对不同端微调感知能力上下文负担每步都引入全局截图容易膨胀把视觉信息压缩成结构描述减轻上下文负担长期演进依赖外部模型能力和框架更新模型自主可控可随业务需求持续迭代从这个表能看出来两条路线的收益周期差异很大。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 高频问题速查表整个方案跑下来我们积累了一些高频问题。很多问题刚出现的时候排查起来特别费劲这里列一个速查表方便你遇到类似情况时直接对照。现象可能原因处理建议Agent 反复点击同一个位置界面无变化控件检测置信度不足把非可点区域当作按钮检查 GUI-Owl 对目标元素的置信度阈值适当降低尝试次数上限并记录截图长任务跑到中段突然忘记目标上下文过长导致早期信息被截断启用子任务摘要机制定期压缩历史保留关键状态截图里明明有按钮模型说没有输入分辨率过低小控件模糊提高输入分辨率或对目标区域做局部放大重识别XML 控件树与视觉布局不一致自定义控件或跨端渲染不暴露标准节点视觉为主、XML 为辅冲突时以视觉识别结果为准动作执行了但校验器判定失败页面加载动画导致截图变化不完整引入等待状态判断等网络请求和动画完成后再校验夜间批处理出现高失败率设备屏幕休眠或应用被系统杀掉关闭设备自动休眠配置保活策略应用异常时自动拉起模型输出非法动作格式提示词约束不足强制 JSON 输出动作类型枚举校验非法输出重试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 框架的接口能力因为移动端自动化的最终形态一定不是一个模型单打独斗而是一套相互配合的系统。最后分享一个小技巧无论是用现成框架还是自研模型都把“截图回放”和“步骤级日志”当作基础设施来建设。这两个东西平时不起眼但一旦系统跑起来它们才是让你能持续迭代下去的真正底牌。