“脚本跑不动了”“用例又废了”“这个页面控件树拿不到 key”——如果你在做移动端自动化测试，这几句话大概率不陌生。系列走到第七篇，移动端自动化也聊到第三篇，前两篇我们主要讨论了传统脚本方案的维护难题：依赖系统控件树，遇到跨平台自绘引擎、动态布局、WebView 内嵌页面就全线崩溃；纯坐标录制的方案更不用提，换台设备就重来一遍。这个背景下，LLM 驱动的自动化测试成了绕不开的方向——让智能体像测试工程师一样，看着屏幕截图决定下一步点哪里，而不是死守着一堆随时失效的定位器。

这篇要拆的是两条具体技术路线：社区开源的 Mobile-Agent-v3，以及我们团队自研的 GUI-Owl 界面理解模型。前者适合快速搭起一个能跑通的智能体基线，后者适合对定位精度、离线部署、私有化合规有硬指标的落地场景。我会把两者的设计逻辑、短板边界、落地管线完整过一遍，并结合实测经验给出一份可以“抄作业”的选型参考。无论你是刚准备引入智能体测试，还是已经在脚本自动化的坑里挣扎，这篇文章都值得看完。

1. 从脚本录回到 GUI 理解：移动 UI 自动化的三条岔路

1.1 为什么控件树还能用，大家却都想换了

早期移动端自动化几乎全靠系统控件树。原生页面里每个控件都暴露元素信息、坐标边界和可用状态，脚本通过选择器定位再执行点击或输入，这套机制在原生页面、结构稳定的 App 内部依然好使。但最近五六年风向明显变了：跨平台自绘引擎大量出现，页面渲染不依赖系统原生控件，树里要么是空壳节点，要么整棵树只有一两个自定义 View；iOS 和 Android 双端对同一业务页面的树结构又不一样，脚本选择器根本没法复用。

改版导致的雪崩更棘手。运营位一调整、按钮文案一变、容器层级一重构，脚本直接红一片，而且不是改一两个选择器能修好的，往往是整条用例链路重写。我自己做过粗略统计，一个中型 App 每个版本迭代，回归脚本里大约有四分之一到三分之一的用例需要不同程度返工，维护成本已经接近甚至超过手工执行。这不是脚本写得烂，是技术路线本身的脆弱性：把测试意图和页面结构强绑定，结构一动，意图就无处附着。

1.2 纯视觉方案为什么只解决了一半问题

既然控件树不靠谱，自然会想到视觉方案。OCR 识别文字、截图对比找差异、图像匹配做断言，这些手段在不依赖控件树的情况下能解决“页面里有什么”的问题。但痛点也很明确：OCR 能读出“立即购买”四个字，却不知道它到底是按钮、文本还是广告浮层的一部分；截图比对能告诉你“页面变了、有弹窗”，但说不清该怎么交互，是点关闭还是划走。

纯视觉方案本质上把“看”和“做”拆成了两套独立系统，中间缺少一个能统一感知与决策的环节。早期我们团队也走过这条路，用截图比对加坐标模板硬凑交互，结果是模板库膨胀得比脚本选择器还快，每台设备的屏幕比例不同，模板就失效——相当于把定位问题换了个形式继续存在。

1.3 LLM 智能体补上的是“感知到决策”的缝隙

LLM 驱动的移动端自动化，核心变化在于把“界面理解”和“任务规划”合并成一个智能体：输入是截图、任务描述和历史动作，输出是结构化的下一步操作。它不再执着于某个按钮的唯一 ID，而是像人一样“看到画面、理解意图、决定动作”。

这个转变的直接收益是：界面的表达层怎么变，智能体只要还能从截图中理解语义，用例就能继续跑。比如“加入购物车”按钮从右上角移到右下角、从纯文字变成图标加文字，对传统脚本是致命改动，对智能体来说只是坐标变化。Mobile-Agent-v3 和自研 GUI-Owl 都是这个思路的具体实现，但两者的设计哲学差异很大，下面展开聊。

2. Mobile-Agent-v3 的设计逻辑：分层决策是它最值得抄的作业

2.1 从“一图一动作”到“分层决策”

最早一批 LLM 操作手机的方案，做法很直接：把整张截图丢给大模型，让它输出一个动作，执行后截新图再丢进去。这个流程逻辑上没问题，实测却不太行得通——每一步都调用大模型，延迟高、成本贵，一个十步的任务要来回十几次推理，长任务跑到后面模型还会因为上下文过长而“丢”掉前面操作过的页面状态。更现实的问题是，大模型每一步都要处理全图，截图里大量与当前任务无关的区域也在消耗注意力，经常出现盯着弹窗疯狂点、该找的核心按钮反而视而不见的情况。

Mobile-Agent-v3 的核心改进是引入分层决策：任务一开始由大模型拆解成若干子目标，之后每一步的常规操作交给轻量级视觉模型来决策，只有遇到异常、置信度低、页面状态看不懂时才回到大模型兜底。这就像团队里老带新——轻量模型负责跑正常流程，疑难杂症才请资深专家出马。实测下来，任务级规划和原子动作级执行的解耦，能把单步推理成本降一个量级，长任务的成功率也更稳定。

2.2 感知、动作原语、记忆缓冲与自省反馈

在我看来，Mobile-Agent-v3 可以被拆成四个可以独立评估的模块：

• 感知模块：输入是截屏、当前页面关键信息（比如顶层页面标识），必要时补充部分控件树。它不强求完整树结构，重点放在“当前屏幕发生了什么变化”。
• 动作原语集：点击、滑动、输入、返回、长按、滚动。限定的一小组原子动作，比让模型自由输出鼠标轨迹或任意手势要收敛得多，搜索空间小了，模型的决策准确率自然上升。
• 记忆缓冲：保存最近几步的截图和动作，目的是防止同一动作被反复执行。没有这个缓冲，模型很容易在弹窗和主页面之间“鬼打墙”。
• 自省反馈：动作执行后再截屏，和动作前的画面做对比，如果视觉状态压根没变化，就判定动作无效，回退一步换方案。这是智能体“知道自己错了”的关键机制。

复现这套方案时，有个细节值得注意：轻量模型在高密度 UI 截图上很容易翻车——电商首页、信息流、设置页这种文字和图标的密集区域，小模型经常把相邻控件认混。我们的解法是把输入从整张全图改成动作候选区域的局部裁剪，再叠加 OCR 文本线索，相当于用感知前处理替模型做了注意力聚焦，而不是指望小模型自己学会“该看哪里”。

2.3 开源方案的天花板：三个绕不开的边界

Mobile-Agent-v3 最大的价值是验证了“LLM 智能体操作手机”这条路可行，并且给出了工程化的基础框架。但把它放到真实的企业测试环境里，边界也很明显：

• 数据安全与合规。走云端大模型意味着截图要出网，对有合规审计要求、核心业务流程敏感的产品来说，这一条基本就否掉了。不要说“反正截图看不出什么”，测试环境的数据也是资产。
• 可定制性差。当你发现某个具体页面的元素定位长期不准，想从模型侧做针对性优化，开源权重和训练管线并不是为测试场景设计的，你想调无从下手。
• 评估维度错位。开源方案的目标是“完成手机操作任务”，不是“把回归用例跑稳”。它不区分哪些操作是核心断言节点、哪些失败要立即重试、哪些接口要校验返回值，这些测试特有的逻辑还得自己在外部框架里额外写。

四个模块再完善，模型本身不可控，落地就越走越累。这是驱动我们去做自研 GUI-Owl 的直接原因。

3. GUI-Owl 模型路线：为什么自研“界面理解专家”而不是继续堆通用大模型

3.1 偏向“测试优先”的界面理解模型

自研 GUI-Owl 时，团队内部争论过一个问题：是直接微调一个通用多模态大模型，还是另起炉灶做专业模型。通用大模型当然强大，但它被训练来应对“世界上的所有图片”，对 UI 元素边界框的精确定位、小字号文本的识别、图标语义的判定并不是它的强项，更不是它的优化目标。打个比方，通用模型像一个见多识广的人，进入一个陌生页面也能看个大概；GUI-Owl 的设计目标是做一个只研究界面截图的老测试，清楚主按钮在哪、广告弹窗长什么样、哪个区域是点击热区。

所以 GUI-Owl 被定位成一个中小参数规模、可私有化部署、以截图输入为主、以结构化界面语义输出的视觉语言模型。它的职责不是闲聊、不是写代码，而是把“当前屏幕里有哪些可交互元素、分别是什么、在哪、应该怎么操作”这件事做到尽可能高的精度。

3.2 数据基建：GUI 问答对是怎么造出来的

做专业模型的第一个现实问题是数据从哪里来。通用模型还能靠网络数据预训练，GUI 理解模型的训练数据几乎只能自己构造和沉淀，这也是整个路线里最耗时、最容易被低估的一环。

我们主要用了三类数据来源：

• 合成数据：基于页面布局结构，把控件树直接渲染成接近真实 UI 的截图，训练样本的文本标签和元素坐标边界是生成过程中自动伴随的。这种方式能低成本拿到几十万量级的带标注数据，是冷启动的基础。
• 轨迹数据：在测试机上录制人工操作视频和操作日志，形成“看到某界面 → 执行某动作 → 界面变化”的三元组。它让模型学到的不是机械的坐标映射，而是“对某种视觉状态采取某种动作”的决策模式。
• 伪标注数据：用现有多模态大模型对真实截图批量生成元素描述和初步坐标，再人工抽检修正。伪标注有噪声，但胜在覆盖面广，对长尾页面很有帮助。

一条典型的训练样本长这样：

{ "image": "device_screenshot_001.png", "instruction": "点击确定按钮提交订单", "elements": [ {"bbox": [412, 1180, 658, 1260], "type": "button", "text": "确定"}, {"bbox": [100, 620, 720, 900], "type": "card", "content": "订单详情"} ], "output_action": {"intent": "TAP", "target_index": 0} }

数据清洗阶段，我们会刻意做多分辨率、多机型的等价渲染，保证同一个元素在不同设备上截图的标注一致。这个步骤不做，模型很容易把“位置”当成“身份”来学，换台设备就懵了。

3.3 模型结构与训练策略：让“眼睛”和“嘴”各自专注

GUI-Owl 的结构大概是三件套：高分辨率视觉编码器负责提取 UI 细节，元素检测头负责输出候选框和元素类型，轻量语言解码器负责把界面状态组织成结构化动作指令。视觉编码器的输入不能像通用模型那样直接把截图压成小图，那会让小号文字和图标细节全丢。我们采用的是分块高分辨率编码，把截图切成重叠区域块分别编码，再融合多尺度特征。

训练策略分两阶段。第一阶段是对齐预训练：把 UI 截图和对应的界面文本描述做对比学习，让视觉特征和语义表达落在同一个空间里，模型看到新页面时能建立“这东西是输入框、那东西是底部导航”的基础认知。第二阶段是指令微调：喂入大量“界面截图 + 操作指令 + 期望动作”的样本，学会从“看懂界面”到“做出动作”。两阶段的边界要划清楚，混着训容易让模型什么都学不精。

评估指标我们不看对话流畅度，只看测试相关的硬指标：元素定位 Top-1 IoU、动作类型准确率、任务完成率、平均步骤数。下表是我们内部做过的一组对比，放在同一个虚构电商 App 回归数据集上：

我在这里解释一下：这些数字只是“可供参考的量级”，不作为绝对结论，因为具体表现和数据集强相关。但趋势是稳定的：专用模型在定位精度和测试完成率上更占优，通用小模型在未知页面的泛化上可能更灵活——这正好引出一个关键观点：两者不是替代关系，而是互补关系。

3.4 和 Mobile-Agent-v3 内置小模型的本质区别

很多朋友问我，GUI-Owl 是不是就是 Mobile-Agent-v3 里那个轻量决策模型的重复造轮子。我的回答是：方向不同。v3 内置小模型的目标是“在多数常规页面上做出正确的下一步动作”，它仍然是一个通用界面操作器，面向的任务集是开放的；GUI-Owl 的目标是“在测试场景内做到高精度的元素理解和动作生成”，面向的任务集是收敛的、可评估的、以回归测试和冒烟测试为核心的。

这个差别体现在细节上：GUI-Owl 对“动作无效”“页面无变化”“元素遮挡”这类测试特有的失败模式做了专门的样本增强；评估指标向回归测试倾斜；推理输出做了结构化约束，保证能被下游执行器直接解析。换句话说，Mobile-Agent-v3 的小模型是一个合格的“通用执行助理”，GUI-Owl 是一个被调教过的“测试专项执行器”。

4. 从 GUI-Owl 到可跑的 Agent：落地管线的五个模块

只有模型没有管线，GUI-Owl 也只是一个离线评测集上的高分数。真正让它变成能在设备上连续执行任务的 Agent，需要下面五个模块协同工作。

4.1 感知模块：不是把整张截图都扔给模型

感知层的第一件事是去重。测试场景里，连续两帧截图经常一模一样，没必要每次都推理。我们会缓存上一帧的特征，如果当前帧和上一帧没有差异，直接复用决策结果。第二件事是差分检测：只对变化区域做裁剪推理，比如弹窗出现、列表滚动，核心变化区域往往只占屏显的一小部分，全图推理是巨大的算力浪费。

除了截图，感知层还会尽量叠加顶层页面标识和可访问性树（能拿到的时候）。注意，可访问性树永远是辅助信息而不是主依赖——在自绘引擎页面里它可能完全不可信，但原生页面里它又能提供精确的文本标签，和视觉结果互相印证，能显著提升决策置信度。

4.2 决策模块：结构化输出与置信度兜底

GUI-Owl 的推理结果不是自由文本，而是严格的结构化动作指令：

{ "intent": "TAP", "target": { "bbox": [412, 1180, 658, 1260], "element_type": "button" }, "param": { "text_hint": "确定" } }

结构化的好处是下游执行器零解析成本，而且可以在执行前做合法性校验——比如判断目标框是否在屏幕范围内、是否在已知的可操作区域、是否被其他浮层覆盖。模型输出置信度低于设定阈值时，不会硬着头皮执行，而是把当前截图转交给通用大模型或标注为待人工确认。这个兜底机制是整条管线稳定性的关键：宁可慢一点，不要错一步。

4.3 执行与状态回传：点击之后必须有一个“确认”

执行模块负责把结构化指令转成设备控制层的原生调用，坐标映射、手势合成、防误触逻辑都在这一层。这里要特别强调“点击后的二次确认”：每次动作执行完，必须立刻截一张新图，和动作前的截图做状态对比，确认页面确实发生了变化。如果点击后画面毫无变化，基本可以判定动作执行失败，需要触发回退和重试逻辑，而不是无脑进入下一步。

这个二次确认逻辑听起来简单，实际救过我们很多次：目标元素被浮层遮挡、坐标映射偏差、动画还没结束就点了下一处，这些异常如果不靠状态对比兜住，后面的步骤会连锁崩盘。

4.4 记忆与自省：跑长任务不迷路

GUI-Owl 短期记忆保存最近若干步的截图和动作，用于循环检测：如果模型连续多步执行相同动作但页面无实质推进，说明进入了死循环，要切换兜底策略——通常是回退到上一个关键节点，或者干脆重启当前子任务。

长期任务记忆则按任务维度缓存“已经完成哪些子目标”“哪些页面的哪些操作曾经失败过”，比如“设置页的保存按钮经常被键盘遮挡，需要先收起键盘再点击”这类失败模式，会在后续同类型任务里直接复用。这层记忆让智能体不只是机械执行当前步，而是逐渐积累出对一个具体 App 的“测试经验”。

4.5 一个典型回归任务跑完长什么样

我们用一个虚构的电商 App 下单回归来验证整条管线。任务拆解成：打开 App → 搜索商品 → 进详情 → 加入购物车 → 结算 → 选择收货地址 → 支付 → 确认完成。传统脚本的方案是写 8 个步骤的定位器和断言，任何一步改版就返工；GUI-Owl 的方案是只输入任务描述，智能体自己完成页面理解和动作执行。

实测结果中，整个流程平均耗时大约三分钟，十次任务成功完成七到八次，失败集中在支付页的第三方控件识别上。相比脚本方案，用例维护成本确实降了一个量级——页面按钮位置变动、文案调整都不影响智能体重新理解，只有业务流程本身发生变化才需要修改任务描述。这就是 GUI 理解路线对测试维护最实在的价值。

5. 两条路线怎么选：预算、数据、场景三个维度的决策清单

5.1 什么情况直接用 Mobile-Agent-v3 就够了

如果你的团队刚起步，手头没有标注数据，GPU 资源紧张，对数据外发也没有硬性合规限制，那我的建议非常直接：先用 Mobile-Agent-v3 这类开源方案搭一个 POC，跑通“截图 → 决策 → 执行 → 反馈”的闭环。这个阶段的目标不是精度，而是验证 LLM 智能体在你们的产品上到底可不可行、瓶颈在哪里。

开源方案的优势同样体现在快速迭代上：社区案例多、已知坑多、（相对的）评估也透明。用来做早期技术预研和内部演示，效率远高于从零训练一个模型。我自己见过不少团队在这个阶段跑出不错的效果，然后拿着这个结果去推动资源采购——这比空口论证“自研模型有多必要”要有说服力得多。

5.2 什么情况必须自研

反过来，如果下面几条命中两条以上，就值得启动自研路线了：

• 产品 UI 使用自绘引擎或重度动态布局，开源方案在关键页面频繁出错，且你无法从模型侧调优；
• 截图必须留在内网，合规和审计不允许走外部模型服务；
• 你已经沉淀或能够沉淀大量测试截图和操作轨迹，数据不再是稀缺品；
• 对元素定位精度和失败模式的可解释性有要求，需要在评估集上持续迭代模型。
• 团队里有能支撑训练和推理基础设施的人，而不是只有测试工程师。

我给一个明确建议：数据比 GPU 更稀缺。如果团队连一批带标注的截图都拿不出来，自研就是空中楼阁，再多算力也白搭。先积累数据资产，再谈自研模型。

5.3 混合路线：让开源模型做脑，自研模型做眼

最后聊一个我认为最务实的落地形态：混合架构。Mobile-Agent-v3 这类开源智能体继续承担任务规划和异常兜底，GUI-Owl 只接管其中“界面元素定位”这一步——把自身的高精度视觉理解作为感知层，开源方案专注于高层决策。两者通过统一接口对接：感知结果、动作原语、执行回执。

我们内部就是这样部署的：GUI-Owl 置信度高的样本，直接输出动作指令，不经过大模型；置信度不够的样本，连同原始截图一起交给开源大模型补充判断。这个模式兼顾了自研模型的精度优势和通用模型的长尾泛化能力，也把推理成本压到了可接受范围。后续 GUI-Owl 的迭代过程中，不断吸收“大模型补充判断”时发现的 bad case 作为新训练样本，模型越跑越准，对大模型的依赖会逐步减少。

从实际执行数据来看，混合架构上线一个月，回归用例的改动率明显下降，第三方混用界面（比如支付控件、广告 WebView）的通过率也稳定在几个关键业务线的接受范围内。这也是我目前在移动端智能化测试上最推荐的一条渐进式路径。

最后再分享一个我们在合规与工程实践中特别注意的小细节：自研模型的可解释性比准确率还重要。测试团队上智能化方案时，经常面临“为什么它点了这里、为什么不点那里”的质疑，如果用黑盒模型，一次误判就会让团队对整条路线失去信任。GUI-Owl 的每条决策都保留截图、裁剪区域、候选元素列表和置信度，可以随手拉出一条可视化的决策链路给评审用。这个能力虽然不直接体现在准确率指标里，却决定了这套方案能不能在真实测试团队里活下来。