移动端自动化测试在接入大模型之后最大的变化不是“执行更快了”而是“维护逻辑变了”。过去我们维护一套 UI 用例核心资产是控件定位表达式和页面对象模型每次版本迭代光修 locator 就要花掉三分之一的时间。走到这个系列的第七篇我想认真聊聊 Mobile-Agent-v3 和自研 GUI-Owl 模型这条路线——前者是人气持续走高的开源智能体框架后者是我们团队在生产环境里坚持自研的视觉感知路线。两条路线解决的问题其实是同一个怎么让模型真正“看懂”移动端屏幕并稳定地输出可执行的动作。这篇文章会把两套方案的内部机制、训练数据构造、部署链路和实测数据全部摊开来讲适合已经在做移动端自动化、正准备向 LLM 驱动方案迁移的测试开发同学参考。1. 为什么移动端 UI 测试到了必须换路线的拐点1.1 传统自动化框架的维护成本是线性增长的很多团队在移动端自动化上走过相似的路径从纯坐标脚本到控件树定位再到引入 OCR 做兜底。但这三种方式都有同一个根源问题——它们都是“规则驱动”的规则越多维护成本越不可控。拿控件树定位来说App 版本更新后 LinearLayout 变成了 ConstraintLayout或者某个控件加了新的 id 前缀脚本立刻挂掉。OCR 也有自己的毛病服务端返回的动态字段、图片上的活动文案、深色模式下的前景色变化都会让识别结果突然不可用。我在某金融理财 App 的回归测试里见过最典型的一个例子首页资产卡片上的数字从普通字体切成 DIN 字体后全部 OCR 断言批量失败排查花了两天最后发现只是字体变更导致字符分割偏移了三个像素。坐标脚本更不用提不同分辨率的适配几乎靠“堆叠 if 语句”一套 300 条的冒烟用例每季度要整体修复一轮。这不是某个方案不够好而是移动端 UI 本身具备高度的视觉驱动特性规则驱动的自动化永远在“被 UI 变更牵着走”的被动位置。1.2 LLM 进来之后范式悄悄完成了切换大模型驱动的自动化测试核心变化是把“脚本描述状态”换成了“模型理解屏幕”。测试用例不再需要逐行写清楚某个按钮在哪个父节点下、偏移量是多少、等多少秒出现而是直接给模型一个任务指令比如“进入资产页面确认昨日收益数值已刷新”模型自己完成屏幕感知、目标定位、动作规划、结果验证这条链路。这样一来UI 变动带来的维护冲击被大幅吸收。控件树变了、元素层级重构了只要视觉呈现没有本质变化模型依然能依靠截图内容完成任务。我们在实验组的数据很直接UI 回归用例的脚本维护时间从每周 6 人时降到每周 1.5 人时但用例数量并没有减少这是规则框架做不到的。1.3 移动端场景的特殊约束决定了技术选型方向移动端自动化比 Web 端更麻烦的地方在于约束条件非常多屏幕尺寸碎片化、页面层级深、有横竖屏切换、有 Native 与 WebView 混排、有各类系统权限弹窗和广告卡片。更重要的是移动端的用户路径是高度“非线性的”一个任务往往要跨越三个以上的页面甚至在多个 App 之间来回跳转。Mobile-Agent-v3 这类方案之所以被关注就是因为它从设计上就针对这些约束做了处理以截图视觉输入为主、保留 XML 层级作为辅助信号动作空间收敛为少量原子操作并支持跨应用路径规划。它不是简单把 Web 端的思路搬过来而是真正往“移动智能体”的方向走了。这也是我们后来敢于选择自研 GUI-Owl 模型的信心来源——先看清楚这个拐点再决定自己站在哪里。2. Mobile-Agent-v3 的动作收敛从“看到屏幕”到“知道下一步点哪里”2.1 输入输出链路与感知层设计Mobile-Agent-v3 的处理链路可以拆成四个环节任务解析、屏幕感知、动作决策、执行反馈。任务解析发生在真实设备操作之前模型先把用户给出的自然语言指令拆成可验证的子目标。比如“帮我把收货地址改成公司地址”这个任务会先拆出“打开个人中心”“进入地址管理”“修改地址”“保存并验证”这样一个粗粒度的步骤序列——这只是规划不是最终动作。屏幕感知环节是 v3 比较有代表性的部分。它不像 Appium 那样依赖控件树解析而是把当前屏幕截图 组件层级信息一起丢给视觉语言模型让模型根据屏幕内容直接判断“现在处于什么页面”“哪些元素可以交互”“下一步该做什么”。这里有一个容易被忽略的细节视觉感知是带空间锚定的。模型不是只输出“我看到一个返回按钮”这样的描述还需要把按钮的坐标区域、控件类型、可操作状态一并输出后续的动作决策才有落点。这个设计的妙处在于它把“理解”和“定位”合在了一起。传统自动化里理解和定位是两个步骤——OCR 负责理解、坐标表负责定位任何一边出错都会导致失败。v3 把两端放进同一个模型降低了对中间特征的依赖也减少了定位漂移带来的连锁故障。2.2 动作空间为什么这么设计Mobile-Agent-v3 将动作输出收敛为 Tap、Input、Swipe、Back、Open App 等少数几类。为什么要收敛因为动作空间太大模型决策的复杂度会指数级上升。想象一下如果模型需要自己生成一段可编程的点击路径而不是输出一个简单的“点击坐标”那么每次决策都相当于一次程序生成错误率必然高。实际执行时模型输出的动作会带上必要的参数。Tap 动作输出坐标或目标元素 IDInput 动作输出目标字段和文本内容Swipe 动作输出起点、终点和持续时间。通过护栏层把动作参数限制在合法范围内比如点击不能落在控件边界之外、输入长度有上限从而避免模型偶尔出现的幻觉参数导致设备长期处于异常状态。我们还发现一个容易被忽略的点no-op 动作不做操作的观察动作在 v3 中的价值非常大。模型在验证页面刷新完成、确认状态变更时需要“看一眼就行”的能力。如果强行让每个决策都产生物理操作反而会在等待网络请求的间隙产生大量误触。v3 对 no-op 的支持其实是在教会模型“什么时候不该动手”。2.3 跨应用协作与任务记忆移动端任务往往不是单 App 内的线性操作。典型场景是从被测 App 跳到另一个 App执行某操作后再跳回来继续验证。Mobile-Agent-v3 在 v3 版本里引入了 App 图标感知机制来应对跨应用路径——模型需要识别屏幕上出现的不同 App 图标并理解“现在进入的是另一个应用需要切换到对应的操作上下文”。我做了一个假设移动智能体最容易被低估的是“任务记忆”。屏幕信息是瞬时的如果没有上下文记忆模型在第二步就会忘记第一步的目标。“进入个人中心—点地址管理—点新增地址”这个三步任务当完成第二跳时模型必须记得它正处于“新增地址”的子流程中且原始用户目标是“修改收货地址”。v3 的实现套路是维护一个内部状态队列把子目标、已执行动作、待验证结果都放进短期记忆每一步动作都基于“历史记忆 当前屏幕”联合决策。这样设计带来的直接收益是模型不会在跨 App 跳转回来之后误认为自己需要重新开始。我们在某音视频应用的实测中加入任务记忆后长链路任务的步骤准确率从 63% 提升到了 82%这个提升幅度比任何感知模块的升级都明显。3. 自研 GUI-Owl 模型路线我们决定不坐等框架升级的理由与做法3.1 再好的开源方案也未必兜得住你的业务界面Mobile-Agent-v3 本身已经很能打但当我们把它放进生产环境时还是遇到了几个绕不过去的真实问题。第一个是业务控件语义偏差。金融 App 里的 K 线图、理财收益卡、风险评估问卷里的滑块组件在通用模型眼里就是“一堆图形”模型往往识别不出“这是可以拖拽的风险偏好滑块”。另一个问题是深色模式与动态品牌视觉。很多业务已经全面切到深色模式背景色从白色变成深灰色通用模型的视觉特征会产生偏移按钮识别率和区域定位准确率明显下降。第三个问题是专业术语与断言逻辑模型不了解“昨日年化收益”“待收本金”“冻结金额”等业务字段之间的勾稽关系也就无法在测试用例里完成有效的状态验证。这三个问题有一个共同点它们不是通用感知能力不够而是领域专用知识不足。这促使我们开始思考自研路线——不推翻 Mobile-Agent-v3 的智能体框架但要替换和增强它的视觉感知底座让模型真正理解自家业务的 UI 语义。3.2 GUI-Owl 的模型结构双流输入与对齐训练自研 GUI-Owl 模型的结构设计一开始的目标就不是“再做一个通用 VLM”而是做一个面向 UI 理解的专用视觉编码器 定位头。它的核心结构包括双流输入、UI 语义编解码和动作映射三部分。双流输入是 GUI-Owl 最有特点的设计。路径一接收原始屏幕截图通过视觉编码器提取像素级特征路径二接收控件树的轻量特征例如控件的类型、文本内容、布局坐标、可见性编码成结构信息向量。两条流在中间层做交叉注意力对齐让模型学会两件事一是从截图中识别视觉元素的空间位置二是把控件树中的语义标签和视觉元素关联起来。对齐训练是整个自研路线的关键。我们需要构造“截图-控件树-语义描述”三元组数据教模型“这张图上的这个区域对应控件树中的哪个节点这个节点的作用是什么”。训练完成后GUI-Owl 输出的不是一段 text 描述而是一张UI 语义特征图每个 UI 元素都被标注了类别、位置、可见性、关键状态以及对应的业务标签。Mobile-Agent-v3 拿到的还是原始截图而我们的智能体拿到的是已经被业务语义标注过的视觉输入后续的动作决策自然更准确。3.3 训练数据构造比模型结构更花时间的活自研模型的成本大头不在训练而在数据。我们花了接近两个月构造 GUI-Owl 的训练数据集这里面的教训非常多单独拿出来说一点公开 GUI 数据集几乎都不适合业务场景。我们采取的方式是构建“业务 UI 截图 结构化标注”生产线。首先用脚本在我们自己的被测 App 上大量截图覆盖不同页面、不同状态正常态、空态、加载态、异常态、不同分辨率至少 5 种真机尺寸与不同深色模式开关状态形成原始截图池。接着把 Appium 自动 dump 出的控件树转成标注信息作为每个 UI 元素的初始化标签再做人工校对修正错误 id、无意义文本、重叠区域的层级关系。为了让模型学会更鲁棒的定位能力我们还做了数据增强随机裁剪、色彩扰动、添加模拟广告遮挡、叠加网络延迟时的半加载状态。这一步特别重要因为生产环境下测试用例经常在页面未完全渲染时就开始识别如果训练数据里没有这种“残缺画面”模型上线后就会在同一类问题上反复翻车。表格里整理一下吧我们构造数据时的几个关键比例数据维度数量/比例备注原始截图总量约 1.2 万张覆盖 35 个核心页面、4 种状态、5 种分辨率双流对齐标注约 9800 条截图区域 控件树节点 语义描述三元组业务标签自定义约 130 个例如收益卡风险滑块协议勾选负样本约 1800 条刻意标注遮挡、错位、未加载等异常画面数据增强后总量约 4.6 万条用于最终训练输入负样本特别值得说。如果数据里全是“干净、布局完整、渲染正常”的截图模型很难培养出对异常状态的敏感度。加负样本的目的是教会模型识别“这个区域看不清不应该点击”或者“页面还在加载中现在动手会有风险”。这批数据在减少误触方面发挥了决定性作用。3.4 模型蒸馏与推理服务落地GUI-Owl 的完整版模型很大不可能直接跑在测试设备或 CI 集群的每台机器上。我们采用了蒸馏方案用一个参数量较大的教师模型在业务数据上训练出高精度版本再蒸馏出一个轻量学生模型参数量约为教师模型的 18%用于日常推理。蒸馏过程中有两个关键考量必须提一下一是蒸馏数据的多样性单纯把训练集原样蒸馏一遍模型只会死记分布遇到新页面就失效我们专门采集了线上用户回放的会话数据来扩充蒸馏集。二是教师模型本身也会有 UI 误识因此蒸馏前我们加了人工抽检环节把教师模型的错误输出筛掉再喂给学生模型防止“AI 教 AI 教出系统性偏见”。基础设施方面我们把 GUI-Owl 部署成独立的推理服务通过 GPU 实例做批量识别。实测单次 UI 语义特征提取的延迟大约在 280 毫秒左右叠加 Mobile-Agent-v3 的规划耗时一个完整的任务动作决策在 1.5 秒内可以完成。对于测试执行来说这样的时延完全可以接受。4. 两条路线在真实项目里的实测对比与选型判断4.1 观察指标与测试环境为了公平评估我们拆了两组实验环境对照组直接用 Mobile-Agent-v3 的默认视觉模型 智能体框架实验组使用自研 GUI-Owl 模型替换感知层、保留 Mobile-Agent-v3 的决策框架。被测对象是同一个移动业务 App测试任务集是 300 条高频业务回归用例覆盖登录、理财购买流程、风险评估、账户设置、消息中心等核心模块。设备池使用同一批 8 台 Android 真机分辨率和系统版本均保持一致避免设备差异干扰结果。测试周期是两周每天跑两轮完整回归收集执行通过率、任务成功率单条用例从开始到最终验证完成的完整成功比例、误触率模型主动执行了错误点击操作的比例、平均耗时与脚本维护成本变化这几个核心指标。4.2 实测对比结果两周测试跑完数据差异非常明显。对照组 Mobile-Agent-v3 原版的任务成功率约为 74%这在通用场景下已经算不错了但放到业务回归的标准里还是不够看——300 条用例有接近四分之一要人工兜底。实验组接入 GUI-Owl 后任务成功率提升到了 89%净提升 15 个百分点主要提升发生在深色模式页面提升 21 个百分点和含图表页面的场景提升 27 个百分点恰好就是最初发现通用模型乏力的一线场景。误触率的变化也很有说服力。对照组误触率约为 6.2%实验组降到了 2.1%。本组数据的意义不只是数字本身它意味着 CI 夜间回归的报警量大幅度下降——误触往往会在业务环境里产生多余数据比如不小心把一笔测试订单提交了这类问题以前每个星期都要手工清理。我们实验期间实验组的“脏数据清理工时”从每周 2.5 人时降到了 0.5 人时左右。平均耗时方面对照组单条任务约 42 秒实验组约 38 秒。单看绝对值差异不大但考虑到实验组多做了业务语义分析和验证步骤这个接近的耗时反而说明 GUI-Owl 的感知效率更优——同样的时间预算内多做出了更精准的判断。4.3 两张表的对比整理再梳理一个直观一点的表格对比项Mobile-Agent-v3 默认路线自研 GUI-Owl v3 框架任务成功率74%89%深色模式页面准确率71%92%含图表页面的 UI 识别准确率64%91%误触率6.2%2.1%单条任务平均耗时42s38s业务语义验证能力弱仅通用描述强支持业务标签断言冷启动成本低开箱即用高数据构造 训练基础设施后续迭代空间依赖项目本体更新可自主沉淀业务数据持续优化这个表格列到“迭代空间”就是选型问题的核心了。如果你的团队现在需要快速跑通 LLM 驱动自动化并且业务页面是比较常规的布局列表、表单、简单按钮组Mobile-Agent-v3 原版已经够用冷启动速度决定了这是当前最优解。但如果你像我们一样业务里有大量动态图表、深色模式、专业术语强依赖的复杂场景且团队有算法或数据工程的人力储备自研路线在长期维度上会更值得投入——一次性的数据建设成本换来的是一套可持续演进的感知底座。4.4 给后来者的三点选型参考基于这次对比我总结出三条判断标准希望对正在决策的团队有帮助。第一看业务页面的结构化程度。页面越结构化表单、列表、设置项通用模型的优势越大不需要自研页面越视觉化图表、大图展示、自定义绘制控件自研专用模型带来的增益越明显。第二看团队的模型维护能力。自研路线并不仅仅是训练一个模型还要求团队能持续提供新版本页面的标注数据。具备测试数据管线能力、或者说能够把自动化脚本和标注流程打通才真正适合自研。否则模型半年不更新识别退化会非常快。第三看失败成本。如果自动化误操作会产生严重的业务副作用比如提交真实订单、修改线上配置那模型感知精度的价值就会高于开发成本值得花钱花时间去换取更低的误触率。反之自动化只是跑一跑功能冒烟可以接受少量失败后人工介入那么开箱即用的方案体验更好。5. 从 Demo 到全天候巡检部署落地中的坑和排查链路5.1 不同分辨率下的坐标漂移问题最开始我们以为模型输出的坐标是“物理像素坐标”后来发现实际拿到的是“归一化坐标”。在 1080p 设备上跑通的动作换到 1440p 设备上Tap 坐标直接偏移了几十个像素按钮点偏、点击无效、甚至误触相邻控件的问题集中爆发。排查过程花了一些时间。第一个燥点是登录页的“确认登录”按钮——在 1080p 设备上坐标稳定命中切到 1440p 宽屏设备后模型输出的 Tap 动作落在了按钮左上角大约 12 像素的位置连续三次没能触发登录。我们开始以为是 GUI-Owl 对宽高比的感知有问题后来通过打印模型返回的坐标范围和控件树中的真实 bounds 比对才发现模型输出的是相对屏幕宽高的比例坐标而执行层直接拿比例值当物理像素用了。解决方案是在动作映射层加一个坐标空间转换器把模型输出的归一化坐标乘以当前设备的实际屏幕宽高再做一次边界裁剪确保点击点落在目标控件的 bounding box 范围内。这个修复并不复杂但如果不做设备池每新增一种分辨率就会出一次问题。同样的转换也要用在 Swipe 动作的起终点上Pan 手势的变速参数同样需要按设备密度换算。5.2 广告卡片、弹窗与 Toast 引发的误判链路这类问题要讲得稍微展开一些因为排查链路确实非常长。现象是某条用例在夜间回归里执行到“收益详情页”时模型误判页面上出现了“新的理财推荐位”并自动点击了进去导致后续的所有断言全部失败。一开始我们怀疑是 GUI-Owl 对不同业务卡片区域的识别能力不够反复标注数据、重新训练但问题仍在偶发。后来把失败时刻的截图调出来比对发现那个“理财推荐位”其实是真实存在的一张运营位广告卡片只是当天夜里被运营同学替换成了新的视觉素材颜色和文案变化导致模型认为这是一个“从未见过的新功能入口”。根因比表面现象更深一层模型不区分“页面内容变更”和“可交互逻辑变更”。推荐位改了文案和配色但它的可点击性没有变用例的预期流程也不要求点击它模型却把“内容变化”解释为“出现了新任务目标”从而主动发起了点击。这个问题的解法分两层。执行层加了一个“任务目标过滤”机制每步动作前都会把“当前步骤的任务目标”和“模型感知到的新元素”做一次相关性判断如果新元素不在任务路径上不允许自动点击只做记录感知层继续补充广告卡片类的负样本数据教模型识别“这是与测试目标无关的运营内容”。修复后这类误触发下降了七成以上。5.3 推理延迟优化从 8 秒压到 2 秒最初整套链路跑通时一个简单的三步任务要花接近 8 秒夜间跑 300 条用例一跑就是四五个小时CI 窗口根本扛不住。定位延迟来源时发现耗时大头是 GUI-Owl 的推理没有做缓存复用——同一个页面在同一轮测试里会被反复截图、反复提取特征每次都跑一次完整推理。优化的第一个动作是加截图指纹缓存。对屏幕截图做感知哈希如果在短时间窗口内比如 30 秒碰到相同或接近相同的截图直接复用上一次的特征提取结果跳过模型推理。这个优化把页面重复访问场景下的推理次数压缩了接近一半。第二个动作是动作级别的批处理。原来的链路是一个动作一个推理请求GUI-Owl 推理一次、Mobile-Agent-v3 又推理一次两个模型串行执行每个步骤都要等两轮延迟。我们把 GUI-Owl 的频率降下来只有在“页面切换或出现异常截图”时才强制重新感知正常的按钮点击场景直接沿用最近一次的 UI 语义特征图决策框架只做一次轻量的状态比对。这样调整后单步动作的决策链路从 1.5 秒左右降到了 0.8 秒整体任务耗时也顺利控制到了 40 秒以内全部优化完成后夜间全量回归的完成时间从 5.2 小时缩短到了 2.1 小时。5.4 安全护栏测试数据隔离与敏感页面脱敏LLM 驱动的自动化有一个容易被忽视的风险模型的感知数据里可能包含真实用户信息。我们在一次灰度测试中发现GUI-Owl 会缓存用户中心的截图里面有明文手机号。这显然不能接受所以我们在数据链路源头加了脱敏处理。具体做法是在截图进入感知模块之前先做一次快速脱敏扫描对页面中疑似手机号、身份证号、真实姓名的文本区域执行模糊化遮盖后再交给模型。由于 GUI-Owl 是基于截图输入完成定位的脱敏并不会影响按钮位置判断只影响文本内容的识别对测试流程几乎没有干扰。此外我们还为智能体执行任务设置了动作白名单与频率限制禁止点击“注销账户”“删除资产”“确认转账”等高危入口同一步骤内的连点次数不能超过 2 次异常退出超过 3 次时自动中止任务并通知维护人员。这些护栏并不复杂但它们保证了自动化可以在无人值守的夜间安全运行也让团队敢把用例量继续往上加。如果让我回顾这轮从 Mobile-Agent-v3 到 GUI-Owl 自研路线的完整过程最深的感受是开源框架解决的是“从 0 到 1”的问题自研模型解决的是“从 1 到能用”的问题。两者不是互斥的对立方案而是不同投入阶段的合理选择。真正让方案落地的不是某一层模型的惊艳表现而是数据、执行链路、安全护栏和持续标注体系拼凑起来的那张完整的网。最后再补充一点个人体会自研模型的路线一定不要在项目初期就铺开先拿 Mobile-Agent-v3 快速验证你的业务场景哪些行、哪些不行把“不行”的清单攒起来再决定值不值得投入自研。我们就是这样做的省掉了大量盲目的重复建设也让 GUI-Owl 的训练目标从一开始就非常清晰。