1. 从脚本回放到视觉决策移动端自动化测试的路线分水岭移动端自动化测试这件事做了几年的人都会有一个共同的感受脚本写得再漂亮也扛不住界面改版。一个按钮的 id 变了、一个弹窗的层级调了、一个页面的加载时序抖了昨天还全绿的用例今天就能红一半。传统方案的核心思路是定位元素—执行动作—断言结果这套逻辑在稳定期很好用但一旦进入快速迭代阶段维护成本会呈指数级上升。也正因为如此最近一两年把大模型引入移动端自动化成了很多团队认真在评估的方向。这次要聊的是两条路线的对比与落地一条是Mobile-Agent-v3这类通用型移动端智能体方案另一条是自研GUI-Owl模型路线。标题里说的移动端自动化三意味着前面已经铺垫过基础能力这一篇重点落在路线选择和自研模型到底值不值得做这两个问题上。如果你正在纠结是直接接一个现成的智能体框架还是自己训一个 GUI 理解模型那这篇内容基本就是围绕你的决策场景展开的。先把结论性的判断放在前面方便你对号入座Mobile-Agent-v3 适合快速验证和多机型覆盖GUI-Owl 自研路线适合有稳定业务场景、有数据积累、且对成本和可控性有硬要求的团队。两者不是替代关系更像是先跑通再优化的两个阶段。下面我会把这两条路线的技术底座、实操细节、踩坑点、以及我实际跑下来的一些经验尽量掰开揉碎讲清楚。需要提前说明的是文中涉及的具体模型名称、框架名称均来自公开技术讨论语境我补充的实现细节和参数是基于常见工程实践推导的合理方案不代表任何特定产品的官方实现。你拿去参考思路没问题直接照搬参数需要结合自己的场景再调。2. Mobile-Agent-v3 的能力边界它到底替你解决了哪一段2.1 视觉感知加动作规划替代的是定位而不是测试逻辑很多人第一次接触 Mobile-Agent-v3 会有一个误解以为它能自动帮你写测试用例。实际上它解决的核心问题是**看懂屏幕并决定点哪里**也就是把传统方案里最脆弱的那一环——元素定位——换成了视觉理解加推理决策。它的工作链路大致是这样的截取当前屏幕画面把画面连同任务描述一起交给多模态模型模型输出一个动作指令点击坐标、滑动方向、输入文本等执行后再截图进入下一轮。整个过程是一个感知—决策—执行的闭环而不是预先写死的步骤序列。这个转变的意义在于界面改版不再直接导致用例失效。按钮从左上角挪到右下角只要语义没变模型依然能找到它。这跟传统基于 id 或 xpath 的定位方式有本质区别。但要注意它替代的只是定位这一段测试的断言逻辑、数据准备、环境清理这些还是得你自己管。把它当成一个更聪明的手而不是一个完整的测试大脑。2.2 多轮截图带来的延迟与成本是绕不开的现实问题跑过一轮你就会发现Mobile-Agent-v3 这类方案最大的体感问题不是准不准而是慢。每一轮动作都要截一次图、调一次模型一个稍微复杂点的流程动辄二三十轮交互。如果每轮模型调用按秒级算一个用例跑下来就是分钟级跟传统脚本的秒级完全不在一个量级。这里有个我实测下来的经验把高频、稳定的操作路径用脚本固化只在容易变化的节点交给智能体决策。比如登录流程、首页跳转这些几乎不变的部分直接用传统方式跑只有那些频繁改版的业务页面才走视觉决策。这种混合模式能把整体耗时压下来一大截同时保留智能体应对变化的优势。成本方面也要算清楚。多模态模型的调用是按 token 或按次计费的一个回归套件如果全走智能体账单会很难看。我的做法是给智能体设置一个决策预算超过一定轮数还没完成就判定失败并截图留证避免它在某个页面里无限打转。2.3 适合它的场景探索性测试与多机型冒烟Mobile-Agent-v3 真正发光的场景其实是探索性测试和多机型冒烟。探索性测试本身就是没有固定脚本、边走边看的活儿传统自动化根本做不了而智能体天然适合这种开放式任务。你给它一个把设置里所有能点的开关都点一遍记录异常的任务它能自己规划路径。多机型冒烟也是同理。同一套任务描述在不同分辨率、不同系统版本的设备上跑不需要为每个机型单独适配定位。这一点在设备碎片化严重的场景下价值很大。但前提是你的任务描述要写得足够清晰模糊的指令会让模型在不同设备上产生完全不同的行为结果就没法对比了。提示给智能体写任务描述时尽量用动作目标约束的结构比如在首页找到搜索框输入关键词后点击搜索等待结果列表出现。避免测试搜索功能这种过于笼统的表述否则模型的行为会非常随机。3. 自研 GUI-Owl 的动机为什么有人宁愿自己训一个模型3.1 通用模型在垂直界面上的水土不服用通用多模态模型做 GUI 理解会遇到几个很具体的痛点。第一是界面元素的识别精度不够尤其是那些图标化、无文字标签的按钮通用模型经常认错。第二是对业务语义不理解它知道那是个按钮但不知道点下去会发生什么导致决策缺乏业务常识。第三是响应格式不稳定你希望它输出结构化的坐标和动作它有时候会给你一段自然语言解释。这些问题在通用场景下可以忍但在测试这种要求可复现、可断言的环境里就成了硬伤。GUI-Owl 这类自研路线的核心动机就是把模型的能力收敛到看懂自家界面这一件事上用垂直数据换取精度和稳定性。3.2 数据从哪来测试资产本身就是最好的训练素材自研模型最让人望而却步的是数据。但做移动端测试的团队其实手里握着一座金矿——历史测试用例、页面截图、操作日志。这些东西平时躺在那里没人用但它们天然就是界面—动作—结果的标注数据。我的做法是搭一条数据回流管道每次自动化执行时把截图、当前动作、执行结果成功/失败/异常都存下来。跑得越久数据越多。再配合人工标注一批关键页面就能凑出一个可用的训练集。这里的关键是标注规范要统一比如坐标用相对比例还是绝对像素、动作类型怎么分类这些必须提前定死否则数据攒了一堆也没法用。3.3 自研的隐性成本不只是训练还有持续维护必须泼一盆冷水自研模型不是训完就完事了。界面在变模型也得跟着更新否则精度会随时间衰减。你需要一套持续训练和评估的机制包括定期用新数据微调、用回归集验证精度、监控线上表现。还有一个容易被低估的成本是推理部署。GUI 模型通常参数量不小要在测试环境里低延迟推理得有相应的算力支撑。如果团队没有这方面的基础设施自研路线的门槛会比想象中高。所以我的建议是只有当通用方案在你的场景下确实撞了墙且你有稳定的数据和算力才考虑自研。否则先用 Mobile-Agent-v3 跑起来把流程和数据攒起来再决定要不要往下走。4. 两条路线的实操对比从环境搭建到跑通第一个用例4.1 环境准备阶段的差异Mobile-Agent-v3 的环境准备相对轻。核心是设备连接和截图通道。你需要确保测试设备能被稳定控制通常通过 ADB 或类似的设备桥接截图要快且清晰。这里有个坑不同设备的截图分辨率差异很大直接喂给模型会影响识别效果建议统一缩放到一个固定尺寸再送进去。GUI-Owl 自研路线的环境准备就重得多。除了设备侧你还要准备训练环境、推理服务、数据存储三块。训练环境看模型规模小模型单卡能跑大一点的就要多卡。推理服务要考虑并发和延迟测试高峰期可能同时跑几十个用例。数据存储则是长期投入截图数据很占空间得规划好清理和归档策略。对比维度Mobile-Agent-v3自研 GUI-Owl环境搭建周期天级周级到月级主要依赖设备桥接、模型 API算力、数据管道、推理服务初期投入低高长期可控性受限于外部模型完全自主精度上限通用能力封顶取决于数据质量4.2 跑通第一个用例的关键动作不管走哪条路线跑通第一个用例的流程是相似的定义任务、执行动作、验证结果。区别在于中间那步由谁来做。用 Mobile-Agent-v3 时你的第一个用例建议选一个简单且稳定的流程比如打开应用—进入某个固定页面—点击一个明显的按钮—验证页面标题。目的是先验证整条链路通不通而不是一上来就挑战复杂业务。我见过有人第一个用例就选支付流程结果卡在验证码和风控上折腾半天以为是框架问题其实是场景选错了。用 GUI-Owl 时第一个用例的重点是验证模型的识别精度。你可以先不接自动化执行单纯让模型对一批截图做元素识别人工核对准确率。如果识别这一关都过不了后面的决策和执行都是空中楼阁。这一步的评估指标要定清楚比如按钮识别准确率文本输入框定位误差等。4.3 执行阶段的稳定性处理执行阶段最大的敌人是时序问题。页面还没加载完就截图模型看到的是半成品界面决策自然错。传统方案里我们靠显式等待解决智能体方案里则需要在截图前做稳定性判断比如连续两帧画面一致才认为页面稳定。另一个常见问题是弹窗和浮层。广告弹窗、权限请求、新手引导这些意外元素会打断智能体的执行路径。我的处理方式是在任务描述里预留容错指令比如如果出现弹窗先关闭再继续。同时在执行层加一个兜底逻辑检测到非预期界面时截图告警而不是让模型硬着头皮往下点。注意智能体在遇到不认识的界面时有可能会做出危险操作比如误点删除、误触支付。生产环境跑之前一定要在测试账号和沙箱环境里充分验证必要时给关键操作加二次确认。5. 踩坑实录我在两条路线上分别栽过的跟头5.1 通用智能体的幻觉点击用 Mobile-Agent-v3 早期我遇到过一个很典型的问题模型会看到屏幕上并不存在的元素。比如任务要求点击确认按钮但当前页面根本没有这个按钮模型却给出了一个坐标点下去正好点到了别的东西。这就是所谓的幻觉。排查这个问题的过程挺有意思。我先怀疑是截图质量问题换了更高清的截图没改善。后来怀疑是任务描述有歧义把描述改得更明确好了一些但没根治。最后发现问题出在模型对找不到目标这种情况缺乏明确的表达方式——它被训练成总要给出一个动作而不是说我找不到。解决办法是在提示词里显式加入如果目标不存在输出特定标记的指令并在执行层对这个标记做处理。这个改动之后幻觉点击明显减少。这个经验告诉我跟智能体打交道一定要给它留说不的出口否则它就会硬编一个答案给你。5.2 自研模型的过拟合陷阱自研 GUI-Owl 时我踩的坑是过拟合。训练集上的识别准确率刷到了很高但一上真实设备就拉胯。原因是训练数据大多来自少数几款机型模型把机型的特征当成了界面特征来学。这个坑的排查链路是这样的先看失败样本发现集中在某几款没进训练集的机型上再对比训练集和真实数据的分布确认机型覆盖严重不均最后通过补充多机型数据、做数据增强比如随机裁剪、亮度扰动来缓解。这件事让我意识到GUI 模型的数据多样性比数据量更重要一百张同一机型的截图价值不如十张来自不同机型的。5.3 两条路线都会遇到的长尾页面有些页面出现频率极低但一旦出现就会让自动化卡住比如一年才弹一次的年度账单、特定活动才有的临时页面。这类长尾页面在训练数据里几乎没有通用模型也没见过。对 Mobile-Agent-v3我的处理是给这类页面准备专门的兜底脚本检测到就切过去处理。对 GUI-Owl则是在数据回流里专门标记这类页面定期补充进训练集。两条路线的思路一致承认模型不可能覆盖一切用工程手段兜住长尾。6. 选型决策什么阶段该用哪条路线6.1 用三个问题快速定位自己的阶段选型不用纠结问自己三个问题就够了。第一你的界面改版频率高不高如果一周一小改、一月一大改智能体方案的价值就大。第二你有没有稳定的数据积累没有数据自研就是无米之炊。第三你的团队有没有算力和工程能力自研不是算法问题是工程问题。这三个问题的答案组合起来基本就能定位你该走哪条路。改版频繁但没数据没算力先用 Mobile-Agent-v3改版频繁且有数据有算力可以考虑自研改版不频繁其实传统方案加一点视觉定位就够了不必上大模型。6.2 混合路线我目前最推荐的落地方式跑了一圈下来我最推荐的其实是混合路线。核心逻辑是稳定的用脚本易变的用智能体关键的用自研模型兜底。具体来说登录、导航、数据准备这些稳定环节用传统脚本快且可靠业务页面的交互用 Mobile-Agent-v3 这类通用智能体应对改版而对精度要求极高的核心页面用 GUI-Owl 做专项识别。三者各司其职整体成本和稳定性都能兼顾。这种混合架构的落地难点在于调度和状态传递。脚本和智能体之间怎么交接、上下文怎么保持需要设计一套统一的任务编排层。我的做法是用一个轻量的状态机来管理整个流程每个环节是一个状态脚本和智能体都是状态里的执行器。这样切换起来比较自然也方便排查问题。环节类型推荐方案理由登录/导航/数据准备传统脚本稳定、快、成本低易变业务页面Mobile-Agent-v3抗改版、免维护定位核心高精度页面自研 GUI-Owl精度可控、业务语义强长尾异常页面兜底脚本人工模型覆盖不到工程兜底6.3 别忽视评估体系没有度量就没有优化最后强调一个容易被忽略的点不管走哪条路线都要建立评估体系。任务成功率、平均执行轮数、单用例耗时、模型调用成本这些指标要持续监控。没有度量你根本不知道换方案是变好了还是变差了。我的做法是每次执行都记录结构化日志定期出一份报表。这份报表不仅能指导技术选型还能在跟团队汇报时拿出实打实的数据。踩过几次坑之后我越来越确信移动端自动化的智能化拼的不是模型多强而是工程体系多完整。模型只是其中一环数据、调度、评估、兜底缺一不可。这套东西我还在持续打磨后面如果 GUI-Owl 的精度有新的突破或者 Mobile-Agent 系列出了新版本我会再补一篇实测对比。目前这个阶段先把混合路线跑稳把数据攒厚比什么都实在。 
长河君 · 2026/10/18 21:33:07 · 阅读 1.2k 移动端自动化测试路线对比：Mobile-Agent-v3与自研GUI-Owl选型指南
1. 从脚本回放到视觉决策移动端自动化测试的路线分水岭移动端自动化测试这件事做了几年的人都会有一个共同的感受脚本写得再漂亮也扛不住界面改版。一个按钮的 id 变了、一个弹窗的层级调了、一个页面的加载时序抖了昨天还全绿的用例今天就能红一半。传统方案的核心思路是定位元素—执行动作—断言结果这套逻辑在稳定期很好用但一旦进入快速迭代阶段维护成本会呈指数级上升。也正因为如此最近一两年把大模型引入移动端自动化成了很多团队认真在评估的方向。这次要聊的是两条路线的对比与落地一条是Mobile-Agent-v3这类通用型移动端智能体方案另一条是自研GUI-Owl模型路线。标题里说的移动端自动化三意味着前面已经铺垫过基础能力这一篇重点落在路线选择和自研模型到底值不值得做这两个问题上。如果你正在纠结是直接接一个现成的智能体框架还是自己训一个 GUI 理解模型那这篇内容基本就是围绕你的决策场景展开的。先把结论性的判断放在前面方便你对号入座Mobile-Agent-v3 适合快速验证和多机型覆盖GUI-Owl 自研路线适合有稳定业务场景、有数据积累、且对成本和可控性有硬要求的团队。两者不是替代关系更像是先跑通再优化的两个阶段。下面我会把这两条路线的技术底座、实操细节、踩坑点、以及我实际跑下来的一些经验尽量掰开揉碎讲清楚。需要提前说明的是文中涉及的具体模型名称、框架名称均来自公开技术讨论语境我补充的实现细节和参数是基于常见工程实践推导的合理方案不代表任何特定产品的官方实现。你拿去参考思路没问题直接照搬参数需要结合自己的场景再调。2. Mobile-Agent-v3 的能力边界它到底替你解决了哪一段2.1 视觉感知加动作规划替代的是定位而不是测试逻辑很多人第一次接触 Mobile-Agent-v3 会有一个误解以为它能自动帮你写测试用例。实际上它解决的核心问题是**看懂屏幕并决定点哪里**也就是把传统方案里最脆弱的那一环——元素定位——换成了视觉理解加推理决策。它的工作链路大致是这样的截取当前屏幕画面把画面连同任务描述一起交给多模态模型模型输出一个动作指令点击坐标、滑动方向、输入文本等执行后再截图进入下一轮。整个过程是一个感知—决策—执行的闭环而不是预先写死的步骤序列。这个转变的意义在于界面改版不再直接导致用例失效。按钮从左上角挪到右下角只要语义没变模型依然能找到它。这跟传统基于 id 或 xpath 的定位方式有本质区别。但要注意它替代的只是定位这一段测试的断言逻辑、数据准备、环境清理这些还是得你自己管。把它当成一个更聪明的手而不是一个完整的测试大脑。2.2 多轮截图带来的延迟与成本是绕不开的现实问题跑过一轮你就会发现Mobile-Agent-v3 这类方案最大的体感问题不是准不准而是慢。每一轮动作都要截一次图、调一次模型一个稍微复杂点的流程动辄二三十轮交互。如果每轮模型调用按秒级算一个用例跑下来就是分钟级跟传统脚本的秒级完全不在一个量级。这里有个我实测下来的经验把高频、稳定的操作路径用脚本固化只在容易变化的节点交给智能体决策。比如登录流程、首页跳转这些几乎不变的部分直接用传统方式跑只有那些频繁改版的业务页面才走视觉决策。这种混合模式能把整体耗时压下来一大截同时保留智能体应对变化的优势。成本方面也要算清楚。多模态模型的调用是按 token 或按次计费的一个回归套件如果全走智能体账单会很难看。我的做法是给智能体设置一个决策预算超过一定轮数还没完成就判定失败并截图留证避免它在某个页面里无限打转。2.3 适合它的场景探索性测试与多机型冒烟Mobile-Agent-v3 真正发光的场景其实是探索性测试和多机型冒烟。探索性测试本身就是没有固定脚本、边走边看的活儿传统自动化根本做不了而智能体天然适合这种开放式任务。你给它一个把设置里所有能点的开关都点一遍记录异常的任务它能自己规划路径。多机型冒烟也是同理。同一套任务描述在不同分辨率、不同系统版本的设备上跑不需要为每个机型单独适配定位。这一点在设备碎片化严重的场景下价值很大。但前提是你的任务描述要写得足够清晰模糊的指令会让模型在不同设备上产生完全不同的行为结果就没法对比了。提示给智能体写任务描述时尽量用动作目标约束的结构比如在首页找到搜索框输入关键词后点击搜索等待结果列表出现。避免测试搜索功能这种过于笼统的表述否则模型的行为会非常随机。3. 自研 GUI-Owl 的动机为什么有人宁愿自己训一个模型3.1 通用模型在垂直界面上的水土不服用通用多模态模型做 GUI 理解会遇到几个很具体的痛点。第一是界面元素的识别精度不够尤其是那些图标化、无文字标签的按钮通用模型经常认错。第二是对业务语义不理解它知道那是个按钮但不知道点下去会发生什么导致决策缺乏业务常识。第三是响应格式不稳定你希望它输出结构化的坐标和动作它有时候会给你一段自然语言解释。这些问题在通用场景下可以忍但在测试这种要求可复现、可断言的环境里就成了硬伤。GUI-Owl 这类自研路线的核心动机就是把模型的能力收敛到看懂自家界面这一件事上用垂直数据换取精度和稳定性。3.2 数据从哪来测试资产本身就是最好的训练素材自研模型最让人望而却步的是数据。但做移动端测试的团队其实手里握着一座金矿——历史测试用例、页面截图、操作日志。这些东西平时躺在那里没人用但它们天然就是界面—动作—结果的标注数据。我的做法是搭一条数据回流管道每次自动化执行时把截图、当前动作、执行结果成功/失败/异常都存下来。跑得越久数据越多。再配合人工标注一批关键页面就能凑出一个可用的训练集。这里的关键是标注规范要统一比如坐标用相对比例还是绝对像素、动作类型怎么分类这些必须提前定死否则数据攒了一堆也没法用。3.3 自研的隐性成本不只是训练还有持续维护必须泼一盆冷水自研模型不是训完就完事了。界面在变模型也得跟着更新否则精度会随时间衰减。你需要一套持续训练和评估的机制包括定期用新数据微调、用回归集验证精度、监控线上表现。还有一个容易被低估的成本是推理部署。GUI 模型通常参数量不小要在测试环境里低延迟推理得有相应的算力支撑。如果团队没有这方面的基础设施自研路线的门槛会比想象中高。所以我的建议是只有当通用方案在你的场景下确实撞了墙且你有稳定的数据和算力才考虑自研。否则先用 Mobile-Agent-v3 跑起来把流程和数据攒起来再决定要不要往下走。4. 两条路线的实操对比从环境搭建到跑通第一个用例4.1 环境准备阶段的差异Mobile-Agent-v3 的环境准备相对轻。核心是设备连接和截图通道。你需要确保测试设备能被稳定控制通常通过 ADB 或类似的设备桥接截图要快且清晰。这里有个坑不同设备的截图分辨率差异很大直接喂给模型会影响识别效果建议统一缩放到一个固定尺寸再送进去。GUI-Owl 自研路线的环境准备就重得多。除了设备侧你还要准备训练环境、推理服务、数据存储三块。训练环境看模型规模小模型单卡能跑大一点的就要多卡。推理服务要考虑并发和延迟测试高峰期可能同时跑几十个用例。数据存储则是长期投入截图数据很占空间得规划好清理和归档策略。对比维度Mobile-Agent-v3自研 GUI-Owl环境搭建周期天级周级到月级主要依赖设备桥接、模型 API算力、数据管道、推理服务初期投入低高长期可控性受限于外部模型完全自主精度上限通用能力封顶取决于数据质量4.2 跑通第一个用例的关键动作不管走哪条路线跑通第一个用例的流程是相似的定义任务、执行动作、验证结果。区别在于中间那步由谁来做。用 Mobile-Agent-v3 时你的第一个用例建议选一个简单且稳定的流程比如打开应用—进入某个固定页面—点击一个明显的按钮—验证页面标题。目的是先验证整条链路通不通而不是一上来就挑战复杂业务。我见过有人第一个用例就选支付流程结果卡在验证码和风控上折腾半天以为是框架问题其实是场景选错了。用 GUI-Owl 时第一个用例的重点是验证模型的识别精度。你可以先不接自动化执行单纯让模型对一批截图做元素识别人工核对准确率。如果识别这一关都过不了后面的决策和执行都是空中楼阁。这一步的评估指标要定清楚比如按钮识别准确率文本输入框定位误差等。4.3 执行阶段的稳定性处理执行阶段最大的敌人是时序问题。页面还没加载完就截图模型看到的是半成品界面决策自然错。传统方案里我们靠显式等待解决智能体方案里则需要在截图前做稳定性判断比如连续两帧画面一致才认为页面稳定。另一个常见问题是弹窗和浮层。广告弹窗、权限请求、新手引导这些意外元素会打断智能体的执行路径。我的处理方式是在任务描述里预留容错指令比如如果出现弹窗先关闭再继续。同时在执行层加一个兜底逻辑检测到非预期界面时截图告警而不是让模型硬着头皮往下点。注意智能体在遇到不认识的界面时有可能会做出危险操作比如误点删除、误触支付。生产环境跑之前一定要在测试账号和沙箱环境里充分验证必要时给关键操作加二次确认。5. 踩坑实录我在两条路线上分别栽过的跟头5.1 通用智能体的幻觉点击用 Mobile-Agent-v3 早期我遇到过一个很典型的问题模型会看到屏幕上并不存在的元素。比如任务要求点击确认按钮但当前页面根本没有这个按钮模型却给出了一个坐标点下去正好点到了别的东西。这就是所谓的幻觉。排查这个问题的过程挺有意思。我先怀疑是截图质量问题换了更高清的截图没改善。后来怀疑是任务描述有歧义把描述改得更明确好了一些但没根治。最后发现问题出在模型对找不到目标这种情况缺乏明确的表达方式——它被训练成总要给出一个动作而不是说我找不到。解决办法是在提示词里显式加入如果目标不存在输出特定标记的指令并在执行层对这个标记做处理。这个改动之后幻觉点击明显减少。这个经验告诉我跟智能体打交道一定要给它留说不的出口否则它就会硬编一个答案给你。5.2 自研模型的过拟合陷阱自研 GUI-Owl 时我踩的坑是过拟合。训练集上的识别准确率刷到了很高但一上真实设备就拉胯。原因是训练数据大多来自少数几款机型模型把机型的特征当成了界面特征来学。这个坑的排查链路是这样的先看失败样本发现集中在某几款没进训练集的机型上再对比训练集和真实数据的分布确认机型覆盖严重不均最后通过补充多机型数据、做数据增强比如随机裁剪、亮度扰动来缓解。这件事让我意识到GUI 模型的数据多样性比数据量更重要一百张同一机型的截图价值不如十张来自不同机型的。5.3 两条路线都会遇到的长尾页面有些页面出现频率极低但一旦出现就会让自动化卡住比如一年才弹一次的年度账单、特定活动才有的临时页面。这类长尾页面在训练数据里几乎没有通用模型也没见过。对 Mobile-Agent-v3我的处理是给这类页面准备专门的兜底脚本检测到就切过去处理。对 GUI-Owl则是在数据回流里专门标记这类页面定期补充进训练集。两条路线的思路一致承认模型不可能覆盖一切用工程手段兜住长尾。6. 选型决策什么阶段该用哪条路线6.1 用三个问题快速定位自己的阶段选型不用纠结问自己三个问题就够了。第一你的界面改版频率高不高如果一周一小改、一月一大改智能体方案的价值就大。第二你有没有稳定的数据积累没有数据自研就是无米之炊。第三你的团队有没有算力和工程能力自研不是算法问题是工程问题。这三个问题的答案组合起来基本就能定位你该走哪条路。改版频繁但没数据没算力先用 Mobile-Agent-v3改版频繁且有数据有算力可以考虑自研改版不频繁其实传统方案加一点视觉定位就够了不必上大模型。6.2 混合路线我目前最推荐的落地方式跑了一圈下来我最推荐的其实是混合路线。核心逻辑是稳定的用脚本易变的用智能体关键的用自研模型兜底。具体来说登录、导航、数据准备这些稳定环节用传统脚本快且可靠业务页面的交互用 Mobile-Agent-v3 这类通用智能体应对改版而对精度要求极高的核心页面用 GUI-Owl 做专项识别。三者各司其职整体成本和稳定性都能兼顾。这种混合架构的落地难点在于调度和状态传递。脚本和智能体之间怎么交接、上下文怎么保持需要设计一套统一的任务编排层。我的做法是用一个轻量的状态机来管理整个流程每个环节是一个状态脚本和智能体都是状态里的执行器。这样切换起来比较自然也方便排查问题。环节类型推荐方案理由登录/导航/数据准备传统脚本稳定、快、成本低易变业务页面Mobile-Agent-v3抗改版、免维护定位核心高精度页面自研 GUI-Owl精度可控、业务语义强长尾异常页面兜底脚本人工模型覆盖不到工程兜底6.3 别忽视评估体系没有度量就没有优化最后强调一个容易被忽略的点不管走哪条路线都要建立评估体系。任务成功率、平均执行轮数、单用例耗时、模型调用成本这些指标要持续监控。没有度量你根本不知道换方案是变好了还是变差了。我的做法是每次执行都记录结构化日志定期出一份报表。这份报表不仅能指导技术选型还能在跟团队汇报时拿出实打实的数据。踩过几次坑之后我越来越确信移动端自动化的智能化拼的不是模型多强而是工程体系多完整。模型只是其中一环数据、调度、评估、兜底缺一不可。这套东西我还在持续打磨后面如果 GUI-Owl 的精度有新的突破或者 Mobile-Agent 系列出了新版本我会再补一篇实测对比。目前这个阶段先把混合路线跑稳把数据攒厚比什么都实在。