LLM驱动移动端自动化测试：Mobile-Agent-v3与GUI-Owl模型路线对比

1. 移动端自动化测试的现状与核心痛点

移动端自动化测试这件事，做过的人都懂，它跟Web端完全不是一个量级的复杂度。Web端你至少还能靠DOM树、XPath、CSS选择器去精确定位元素，哪怕页面改版，大部分时候改改选择器就能跑。但移动端呢？Android有View树，iOS有Accessibility层，听起来好像也有层级结构可以抓，但实际跑起来你会发现，系统控件和自绘控件的混合、WebView和原生页面的嵌套、动态加载和懒加载的时序问题，分分钟让你的脚本变成“一次性用品”——今天跑通，明天就挂。

更别提跨应用操作了。一个完整的用户旅程往往涉及多个App之间的跳转，比如从社交App分享内容到电商App，再跳转到支付App完成交易。传统的自动化框架，像Appium、UiAutomator、XCUITest这些，本质上都是“单应用视角”的工具，它们的设计初衷是测试你自己开发的那个App，而不是模拟一个真实用户在手机上的完整行为链路。

这就是为什么最近一两年，LLM驱动的移动端自动化方案开始密集涌现。大家逐渐意识到，与其写死一堆选择器和坐标，不如让模型像人一样“看着屏幕做决策”。而Mobile-Agent-v3和自研GUI-Owl模型路线，正是在这个背景下值得深入拆解的两条技术路径。

这篇文章适合谁看？如果你正在做移动端自动化测试，或者你在探索LLM在GUI交互领域的落地，再或者你单纯想了解“让AI自己玩手机”这件事到底是怎么实现的，那接下来的内容应该能给你不少参考。我会从整体设计思路讲到具体实操细节，包括模型选型、任务编排、异常处理这些一线才会踩到的坑。

2. 两条技术路线的整体设计与选型考量

2.1 Mobile-Agent-v3的架构思路：多Agent协作+视觉感知

Mobile-Agent-v3的核心设计哲学可以用一句话概括：把“看屏幕-做决策-执行动作”这个循环拆成多个专职Agent来协作完成。它不是一个单一的大模型在端到端地输出动作序列，而是一个多Agent系统。

具体来说，它通常包含这几个角色：

• Perceptor（感知Agent）：负责截取当前屏幕，调用视觉模型对界面进行理解，输出结构化的界面描述，包括可交互元素列表、每个元素的位置和语义信息。
• Planner（规划Agent）：根据用户给出的任务目标和当前界面状态，决定下一步该做什么。比如“打开设置”这个任务，当前在桌面，Planner会决定先点击“设置”图标。
• Operator（执行Agent）：把Planner的决策翻译成具体的操作指令，比如点击坐标(x, y)、滑动方向、文本输入等。
• Reflector（反思Agent）：在动作执行后评估结果，判断任务是否推进、是否出现了意外情况，必要时触发重新规划。

这种架构的好处很明显：每个Agent的职责单一，prompt可以针对性优化，而且Reflector的存在让系统具备了一定的自我纠错能力。但代价是链路长、延迟高，每个步骤都要经过多次模型调用，对实时性要求高的场景不太友好。

注意：Mobile-Agent-v3的论文和开源实现中，Perceptor通常依赖的是通用的视觉语言模型（VLM），而不是专门为GUI场景训练的模型。这意味着它在理解复杂界面时可能会有信息损失，尤其是面对自定义控件、游戏界面、视频播放器这类非标准UI时。

2.2 GUI-Owl自研路线的动机：为什么要自己训模型

既然有Mobile-Agent-v3这样的通用方案，为什么还要走自研GUI-Owl模型这条路？答案其实很直接：通用VLM在GUI理解这件事上，不够专。

我举个例子你就明白了。你拿一张手机截图去问通用VLM“这个页面上有哪些可以点击的按钮”，它可能会告诉你“有一个搜索框、一个设置图标、一个返回按钮”，听起来没错对吧？但如果你问它“搜索框的精确像素坐标是多少”，它大概率给不出准确答案。而自动化测试恰恰需要精确坐标来执行点击。

GUI-Owl的思路就是：用一个专门在GUI数据上训练过的模型，同时完成界面理解和元素定位两个任务。它的输出不是一段自然语言描述，而是结构化的数据——每个可交互元素的类型、文本内容、边界框坐标、是否可点击、是否可输入等等。

这条路线背后的技术选型考量主要有三点：

第一，数据质量可控。自研模型可以使用自己标注的GUI数据集，标注粒度可以精确到像素级，而且可以针对自己业务中常见的界面类型做定向增强。

第二，推理效率更高。专用模型通常比通用VLM小得多，推理速度快，可以部署在端侧或者靠近端侧的边缘节点，减少网络延迟。

第三，输出格式稳定。通用VLM的输出是自然语言，解析起来需要额外的后处理，而且格式可能不稳定。GUI-Owl直接输出JSON格式的结构化数据，下游系统消费起来非常方便。

当然，自研路线也有明显的代价：需要标注数据、需要训练资源、需要持续迭代维护。所以选哪条路，取决于你的团队规模、业务场景和长期规划。

2.3 两条路线的对比与适用场景

实际项目中，这两条路线并不是互斥的。我见过比较务实的做法是：用GUI-Owl做界面理解和元素定位，用Mobile-Agent-v3的多Agent框架做任务规划和异常处理。这样既保证了感知层的精度，又保留了决策层的灵活性。

3. 核心细节解析与实操要点

3.1 界面感知层的实现细节

不管走哪条路线，界面感知都是第一步。这一步的目标是把一张屏幕截图变成机器可以理解的结构化信息。

对于Mobile-Agent-v3路线，感知层通常是这样实现的：截取当前屏幕后，调用VLM生成界面描述。Prompt的设计非常关键，需要明确告诉模型输出格式。比如：

你是一个移动端界面分析助手。请分析这张截图，输出JSON格式的界面元素列表。 每个元素包含：type（类型）、text（文本）、bbox（边界框坐标[x1,y1,x2,y2]）、clickable（是否可点击）。 只输出JSON，不要输出其他内容。

但实测下来，通用VLM的输出经常不稳定——有时候坐标偏了几十像素，有时候漏掉了某些元素，有时候JSON格式都不对。所以实际工程中通常需要加一层校验和修正逻辑。

对于GUI-Owl路线，感知层的实现就更直接了。模型直接输出结构化的元素列表，每个元素带有精确的边界框。但这里有个关键细节：模型的输出坐标系需要和实际屏幕分辨率对齐。如果模型训练时用的是1080x2400的截图，而实际设备是1440x3200，那就需要做坐标缩放。

# 坐标缩放示例 def scale_bbox(bbox, model_resolution, device_resolution): model_w, model_h = model_resolution device_w, device_h = device_resolution scale_x = device_w / model_w scale_y = device_h / model_h x1, y1, x2, y2 = bbox return [ int(x1 * scale_x), int(y1 * scale_y), int(x2 * scale_x), int(y2 * scale_y) ]

提示：坐标缩放看起来简单，但实际项目中经常出问题。建议在模型训练阶段就统一使用固定分辨率，推理时也先把截图resize到该分辨率，再缩放回设备坐标。这样可以避免模型在不同分辨率下表现不一致。

3.2 任务规划与动作序列生成

感知层输出的是“当前屏幕上有什么”，规划层要解决的是“接下来该做什么”。

Mobile-Agent-v3的Planner通常是一个LLM，输入包括：用户任务描述、当前界面元素列表、历史动作记录。输出是下一步的动作指令。Prompt的设计需要考虑几个关键点：

• 任务分解：把“在电商App上买一瓶洗发水”这种高层任务拆解成可执行的步骤序列。
• 上下文管理：历史动作记录不能无限增长，需要做摘要或截断，否则会超出模型上下文窗口。
• 异常处理：如果上一步动作没有产生预期效果，Planner需要能够识别并调整策略。

GUI-Owl路线虽然不强调多Agent协作，但同样需要规划能力。常见的做法是在GUI-Owl之上再挂一个LLM做规划，或者用规则引擎处理常见任务流。

实操中我发现一个很有效的技巧：给Planner提供“页面类型”的元信息。比如当前页面是“首页”、“列表页”、“详情页”还是“表单页”，不同类型的页面有不同的操作模式。这个信息可以由感知层输出，也可以由单独的页面分类模型判断。

3.3 动作执行层的稳定性保障

动作执行看起来最简单——点击、滑动、输入文本，但实际上这是最容易出问题的环节。

点击操作的坑主要在于：模型输出的坐标可能不够精确，尤其是当目标元素比较小的时候。解决方案通常有两种：一是点击元素边界框的中心点，二是在边界框内随机采样多个点做点击。后者在元素较大时更稳定，因为可以避免点到边缘的无效区域。

滑动操作的坑在于：滑动的起始点和终点需要根据屏幕尺寸动态计算。比如“从屏幕底部向上滑动”这个动作，在不同尺寸的设备上，起始点的y坐标应该是屏幕高度的90%还是85%？这个需要根据实际设备做适配。

文本输入的坑最多。首先，你需要先点击输入框获取焦点；其次，输入法可能会弹出遮挡界面；再次，某些输入框有格式限制或自动补全。实操中建议的做法是：点击输入框后等待一段时间（通常500ms到1s），确认输入法弹出后再执行输入，输入完成后按返回键收起输入法。

# 文本输入的稳定实现 def input_text(device, text, input_box_bbox): # 点击输入框 center_x = (input_box_bbox[0] + input_box_bbox[2]) // 2 center_y = (input_box_bbox[1] + input_box_bbox[3]) // 2 device.click(center_x, center_y) time.sleep(0.8) # 等待输入法弹出 # 清空已有内容 device.clear_text() time.sleep(0.3) # 输入新内容 device.send_text(text) time.sleep(0.5) # 收起输入法 device.press_back() time.sleep(0.3)

注意：不同Android版本和不同输入法的行为差异很大。有些输入法在收到send_text后不会立即上屏，需要额外等待。建议在真机集群上做兼容性测试，记录每种设备+输入法组合的最佳等待时间。

4. 实操过程与核心环节实现

4.1 环境搭建与基础依赖

先把环境搭起来。以下是一个典型的开发环境配置：

# 基础环境 Python 3.10+ Android SDK (platform-tools, build-tools) ADB (Android Debug Bridge) # 核心依赖 pip install opencv-python # 图像处理 pip install pillow # 截图处理 pip install numpy # 数值计算 pip install requests # API调用 pip install uiautomator2 # Android自动化

如果你走GUI-Owl路线，还需要准备模型推理环境。如果模型部署在服务端，需要配置好API调用；如果部署在端侧，需要根据设备芯片选择对应的推理框架。

设备连接方面，建议使用真机而不是模拟器。模拟器虽然方便，但很多App会检测模拟器环境并限制功能，而且模拟器的渲染行为和真机有差异，可能导致模型识别效果下降。

# 检查设备连接 adb devices # 输出示例 # List of devices attached # ABC123456789 device

4.2 界面感知模块的完整实现

以GUI-Owl路线为例，界面感知模块的完整流程如下：

第一步：截图。通过ADB或uiautomator2获取当前屏幕截图。

import uiautomator2 as u2 from PIL import Image import io def capture_screen(device_serial): d = u2.connect(device_serial) screenshot = d.screenshot(format='pillow') return screenshot

第二步：预处理。把截图resize到模型输入尺寸，通常是固定的分辨率如1080x2400或720x1600。

def preprocess_image(image, target_size=(1080, 2400)): return image.resize(target_size, Image.LANCZOS)

第三步：模型推理。调用GUI-Owl模型获取界面元素列表。

def parse_ui(image): # 调用模型API response = call_gui_owl_api(image) # response示例： # { # "elements": [ # {"type": "button", "text": "搜索", "bbox": [100, 200, 300, 260], "clickable": true}, # {"type": "input", "text": "", "bbox": [50, 300, 1030, 380], "clickable": true} # ] # } return response["elements"]

第四步：坐标映射。把模型输出的坐标映射回设备实际分辨率。

def map_coordinates(elements, model_size, device_size): model_w, model_h = model_size device_w, device_h = device_size scale_x = device_w / model_w scale_y = device_h / model_h for elem in elements: bbox = elem["bbox"] elem["device_bbox"] = [ int(bbox[0] * scale_x), int(bbox[1] * scale_y), int(bbox[2] * scale_x), int(bbox[3] * scale_y) ] return elements

4.3 任务规划模块的实现

任务规划模块的核心是一个LLM调用循环。以下是一个简化版的实现：

def plan_next_action(task, ui_elements, history, max_steps=20): system_prompt = """你是一个移动端自动化助手。根据用户任务和当前界面元素，决定下一步动作。 可用动作： - click(element_id): 点击某个元素 - input(element_id, text): 在输入框中输入文本 - swipe(direction): 滑动屏幕，direction为up/down/left/right - done(): 任务完成 - fail(reason): 任务失败 输出JSON格式：{"action": "click", "element_id": 3} """ user_prompt = f"""任务：{task} 当前界面元素： {format_elements(ui_elements)} 历史动作： {format_history(history[-5:])} 请决定下一步动作。""" response = call_llm(system_prompt, user_prompt) return parse_action(response)

这里有几个实操中总结出来的关键点：

历史动作的截断策略。不要把所有历史都塞进prompt，只保留最近5-10步就够了。更早的历史可以做摘要，比如“已经完成了登录操作”。

元素ID的稳定性。每次感知输出的元素列表可能顺序不同，所以需要给每个元素分配一个稳定的ID。通常的做法是用元素在列表中的索引作为ID，但这样在两次感知之间ID可能会变。更好的做法是用元素的文本+类型+大致位置生成一个哈希ID。

失败重试机制。如果LLM输出的动作格式不对，或者引用了不存在的元素ID，需要有一套重试逻辑。通常重试2-3次，如果还是失败就跳过这一步或者终止任务。

4.4 动作执行与结果验证

动作执行模块需要处理各种边界情况。以下是一个比较健壮的实现：

def execute_action(device, action, ui_elements): action_type = action["action"] if action_type == "click": elem = find_element_by_id(ui_elements, action["element_id"]) if elem is None: return False, "元素不存在" bbox = elem["device_bbox"] # 在边界框内随机采样点击，提高容错 x = random.randint(bbox[0] + 5, bbox[2] - 5) y = random.randint(bbox[1] + 5, bbox[3] - 5) device.click(x, y) time.sleep(1.0) # 等待界面响应 return True, "点击成功" elif action_type == "input": elem = find_element_by_id(ui_elements, action["element_id"]) if elem is None: return False, "输入框不存在" bbox = elem["device_bbox"] center_x = (bbox[0] + bbox[2]) // 2 center_y = (bbox[1] + bbox[3]) // 2 device.click(center_x, center_y) time.sleep(0.8) device.send_text(action["text"]) time.sleep(0.5) device.press_back() time.sleep(0.3) return True, "输入成功" elif action_type == "swipe": direction = action["direction"] w, h = device.window_size() if direction == "up": device.swipe(w//2, h*0.8, w//2, h*0.2, duration=0.3) elif direction == "down": device.swipe(w//2, h*0.2, w//2, h*0.8, duration=0.3) time.sleep(0.8) return True, "滑动成功" elif action_type == "done": return True, "任务完成" elif action_type == "fail": return False, action.get("reason", "未知原因")

结果验证是另一个关键环节。每次动作执行后，需要判断界面是否发生了预期变化。最简单的做法是对比动作前后的截图差异，如果差异很小，说明动作可能没有生效。更精细的做法是检查特定元素的状态变化，比如点击“登录”按钮后，检查是否出现了“首页”的元素。

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

5.1 模型识别不准怎么办

这是最常见的问题。表现包括：元素漏检、坐标偏移、类型判断错误。

排查思路：

首先确认截图质量。有些设备截图会有压缩伪影，或者分辨率过低导致小元素看不清。建议统一使用PNG格式截图，分辨率不低于1080p。

其次检查模型输入尺寸是否和训练时一致。如果模型训练用的是1080x2400，推理时用了720x1600，识别效果会明显下降。

再次，检查界面是否有动画或过渡效果。如果截图时界面正在动画中，模型看到的可能是中间状态。建议在截图前等待界面稳定，通常等待500ms到1s。

解决方案：

• 对识别结果做后处理，比如过滤掉面积过小的元素（可能是噪声），合并重叠的元素框。
• 对于关键元素，可以用模板匹配做二次确认。
• 建立常见界面的元素库，对高频页面做定向优化。

5.2 任务执行到一半卡住了

这种情况通常是规划层出了问题。可能的原因包括：LLM输出了无效动作、界面状态和预期不符、任务本身无法完成。

排查步骤：

1. 打印当前界面元素列表和历史动作记录，人工判断LLM的决策是否合理。
2. 检查是否有弹窗、广告、权限请求等意外界面遮挡了目标元素。
3. 检查网络状态，某些操作需要网络请求才能完成。

解决方案：

• 增加超时机制，单步动作超过一定时间未完成就判定失败。
• 增加弹窗检测和处理逻辑，遇到常见弹窗（如权限请求、更新提示）自动关闭。
• 设置最大步数限制，防止无限循环。

5.3 不同设备上表现不一致

这是移动端自动化的老大难问题。同样的脚本，在A设备上跑得好好的，换到B设备就各种问题。

常见差异来源：

实操中建议的做法是：建立设备适配层，把设备相关的参数（分辨率、系统版本、厂商）抽象成配置，核心逻辑不依赖具体设备。

5.4 常见问题速查表

提示：偶发失败是最难排查的。建议在关键步骤增加截图和日志记录，失败时自动保存现场信息，方便事后分析。

6. 从项目落地角度聊聊选型与演进

6.1 什么团队适合走哪条路

如果你是一个小团队，或者刚开始探索LLM驱动的移动端自动化，我建议先从Mobile-Agent-v3这类通用方案入手。原因很简单：启动成本低。你不需要标注数据，不需要训练模型，只需要调通API就能跑起来。虽然效果可能不是最优的，但能快速验证可行性，积累经验。

如果你已经明确了业务场景，而且有稳定的测试需求，那GUI-Owl自研路线值得投入。专用模型在特定场景下的表现，确实比通用方案好一个档次。尤其是当你需要精确坐标、需要高频调用、需要端侧部署的时候，自研模型的优势非常明显。

6.2 混合架构的实践思路

前面提到过，两条路线可以结合。我实际项目中比较推荐的架构是：

• 感知层：用GUI-Owl做界面理解和元素定位，输出结构化数据。
• 规划层：用通用LLM做任务规划和决策，输入是结构化的界面数据。
• 执行层：用规则引擎+异常处理做动作执行和结果验证。

这样分工的好处是：感知层用专用模型保证精度和速度，规划层用通用LLM保证灵活性，执行层用规则引擎保证稳定性。每一层都可以独立迭代，不会互相牵制。

6.3 后续可以扩展的方向

这个项目后续有几个值得探索的方向。一是多模态融合，除了截图，还可以结合UI树信息、系统日志等多源数据，提高感知准确率。二是端云协同，简单场景端侧推理，复杂场景云端推理，平衡延迟和效果。三是持续学习，把线上执行的失败案例自动收集起来，定期更新模型，形成数据飞轮。

我个人在实际操作中的体会是，LLM驱动的移动端自动化，目前还处于“能用但不够好用”的阶段。模型能力在快速进步，但工程侧的挑战同样巨大。真正决定项目成败的，往往不是模型本身，而是你对业务场景的理解、对异常情况的处理、对细节的打磨。踩过的坑越多，积累的经验越值钱。