1. 移动端自动化测试的现状与ARTEMIS的切入点移动端自动化测试这件事做过的人都懂——它不像后端接口测试那样干净利落也不像Web端那样有成熟的DOM结构可以依赖。一台真机摆在面前屏幕分辨率、系统版本、厂商定制ROM、输入法弹窗、权限弹窗、网络切换、来电打断……任何一个变量都能让一条昨天还跑得好好的用例今天直接挂掉。更别提现在App里大量使用自绘UI、Flutter、React Native、游戏引擎渲染传统的基于控件树的定位方式经常抓瞎。而大语言模型LLM的介入给这个领域带来了一个全新的思路不再依赖精确的控件ID和层级路径而是让模型像人一样“看”屏幕、“理解”界面、“决定”下一步操作。这个方向这两年涌现了不少探索性工作ARTEMIS就是其中一个比较有代表性的尝试。它做的事情简单说就是把移动端GUI自动化的“感知-决策-执行”闭环用LLM重新组织了一遍并且提出了一个双模式架构来应对不同复杂度的任务场景。这篇文章我会从架构层面把ARTEMIS拆开来讲重点放在它的双模式设计到底解决了什么问题、两种模式各自的适用边界在哪里、以及如果我们要自己复现或借鉴这套思路需要注意哪些工程细节。适合已经在做移动端自动化、想了解LLM如何落地到GUI操作场景的测试开发同学也适合对多模态Agent感兴趣但还没找到具体切入点的工程师。2. 为什么移动端GUI自动化需要“双模式”2.1 单模式架构的三个死结在ARTEMIS出现之前大多数LLM驱动的GUI Agent都采用单一模式把当前屏幕截图丢给多模态模型模型输出一个动作点击坐标、输入文本、滑动方向执行后再截图循环往复。这个模式听起来很直接但实际跑起来会撞上三堵墙。第一堵墙是推理成本与延迟。每一步都调用一次多模态大模型一次截图编码加上推理动辄几秒。一个包含20步操作的测试用例光模型推理就要花掉一两分钟。如果测试套件里有上百条用例这个时间成本是不可接受的。而且很多步骤其实是“傻瓜操作”——比如点击一个明确的按钮、在输入框里填一段文本这些根本不需要大模型来“思考”。第二堵墙是长程任务的上下文爆炸。移动端一个完整的业务流程可能涉及几十步操作如果每一步都把完整截图和历史动作序列塞进上下文token消耗会迅速膨胀。更麻烦的是当上下文过长时模型对早期步骤的记忆会衰减容易出现“忘记自己已经登录过了”“重复点击同一个按钮”这类问题。第三堵墙是错误恢复能力弱。单模式架构下如果某一步点击偏了、弹窗没关掉、页面加载慢了模型往往缺乏足够的“元认知”来判断当前状态是否异常。它只会基于当前截图继续输出下一个动作而不是回头检查“我上一步的操作到底生效了没有”。2.2 双模式的核心设计哲学分而治之ARTEMIS的双模式架构本质上是对任务复杂度做了一次分层。它把操作分成两类一类是确定性操作比如“点击坐标(x,y)”“输入文本‘hello’”“按下返回键”这些动作的语义明确、执行结果可预期另一类是探索性操作比如“找到登录入口”“判断当前页面是否加载完成”“决定下一步该点哪里”这些需要理解界面语义、做判断和规划。对应地ARTEMIS设计了两条路径快速模式面向确定性操作走轻量级的执行链路不调用重型多模态模型或者只调用一个小的视觉定位模型来完成“元素定位”这一件事。深度模式面向探索性操作调用完整的多模态LLM进行界面理解、任务规划和异常判断。这个设计的精妙之处在于它不是一个静态的开关而是一个动态路由机制。系统会根据当前任务的状态、历史执行情况、界面变化程度来决定这一步走快速模式还是深度模式。简单页面、明确目标走快速通道页面结构复杂、目标模糊、或者前一步执行失败自动升级到深度模式。2.3 两种模式的边界划分与切换逻辑那具体怎么判断该走哪条路ARTEMIS的切换逻辑大致基于几个信号判断信号走快速模式走深度模式当前步骤是否有明确的目标元素描述是且元素在屏幕中可见否或元素不可见需要滚动查找上一步操作是否成功执行成功且页面已稳定失败、超时或页面未变化当前页面是否出现过是已有缓存的元素定位信息否首次遇到该页面任务剩余步骤是否明确是有预定义的步骤序列否需要模型动态规划界面变化幅度小局部刷新大整页跳转或弹窗覆盖这个表格是我根据ARTEMIS论文和类似系统的常见实践整理的实际实现中每个信号的权重和阈值需要根据具体App和测试场景调优。但核心思想是一致的能用便宜方式解决的绝不调用昂贵模型只有真正需要“理解”的时候才升级到深度模式。注意快速模式和深度模式的划分不是绝对的。有些系统会把“元素定位”也交给一个小型的视觉模型比如基于YOLO或Grounding DINO的检测器这样快速模式本身也具备一定的视觉理解能力只是不做任务级规划。3. ARTEMIS双模式架构的模块拆解3.1 感知层截图、控件树与视觉特征的融合ARTEMIS的感知层不是单纯依赖截图也不是单纯依赖控件树而是做了多源信息的融合。这一点很关键因为移动端自动化的一个核心痛点是控件树经常拿不到有效信息自绘UI、WebView、Flutter而纯视觉方案又缺乏精确的文本和层级信息。它的感知层大致输出三类数据原始截图用于多模态模型的视觉理解以及视觉定位模型的输入。控件树Accessibility Tree通过系统提供的无障碍服务获取包含控件的类名、文本、content-desc、bounds等属性。这部分信息在原生控件上非常可靠但在自绘UI上可能为空或只有最外层容器。视觉特征向量对截图做轻量级处理如边缘检测、文本区域检测、图标检测提取出候选的可交互区域。这部分用于在控件树失效时做兜底。这三类数据会一起送入后续的决策模块。快速模式下系统优先使用控件树中的bounds信息来定位元素如果控件树中找不到目标则退而使用视觉特征向量做匹配。深度模式下截图和控件树摘要会一起送给LLM让模型综合判断。3.2 决策层快速模式与深度模式的调度器决策层是ARTEMIS的大脑也是双模式架构的核心实现处。它包含一个调度器和两个执行器。调度器的输入是当前任务状态剩余步骤、当前步骤描述、历史执行记录和感知层输出。它输出一个决策这一步走快速模式还是深度模式。调度器的实现可以是一个规则引擎也可以是一个轻量级分类模型。ARTEMIS论文中采用的是规则启发式的方案因为规则引擎的可解释性更强调试起来也方便。快速执行器的职责很聚焦给定一个目标元素描述比如“登录按钮”“用户名输入框”在感知层输出中找到对应的元素返回其坐标或操作句柄。它不负责理解页面整体语义也不做任务规划。实现上它可以是一个基于控件树文本匹配的查找器也可以是一个小的视觉定位模型。深度执行器的职责则宽泛得多它接收完整截图和任务上下文输出一个结构化的动作指令可能包含“先滚动找到某个元素”“点击某个区域”“输入文本”“等待页面加载”等。它本质上是一个多模态Agent需要具备一定的推理和规划能力。3.3 执行层动作原语与反馈采集执行层负责把决策层输出的动作指令转化为真实的设备操作。ARTEMIS定义了一套动作原语包括tap(x, y)点击坐标tap_element(element_id)点击某个已定位的元素input_text(text)在焦点输入框中输入文本swipe(direction, distance)滑动back()返回键home()Home键wait(ms)等待assert(condition)断言执行层在完成动作后会采集反馈信息操作是否成功执行、页面是否发生变化、是否有弹窗出现、当前前台Activity是什么。这些反馈会回传给调度器用于判断下一步的模式选择。实操心得动作执行后的“页面是否变化”判断不能简单用截图像素差。因为有些页面有动画、有倒计时、有视频播放像素差会一直很大。更可靠的方式是结合控件树的结构变化和前台Activity的变化来判断。如果控件树根节点的子节点数量或关键属性变了或者Activity切换了才认为页面发生了实质性变化。3.4 记忆层短期上下文与长期经验库ARTEMIS还有一个容易被忽略但很重要的模块记忆层。它分两部分短期记忆当前测试用例的执行历史包括每一步的截图摘要、动作、结果。这部分用于深度模式下的上下文构建让模型知道“我已经做了什么”。长期记忆跨用例积累的页面元素定位信息、常见弹窗处理策略、页面跳转关系。这部分用于加速快速模式比如某个页面的“登录按钮”坐标已经被记录过下次直接查表即可不需要重新定位。长期记忆的引入让ARTEMIS在重复执行相似测试用例时速度会越来越快。这也是它区别于一次性Agent的重要特征。4. 快速模式的实现细节与性能优化4.1 元素定位的三种策略快速模式的核心任务是“给定描述找到元素”。ARTEMIS实现了三种定位策略按优先级依次尝试策略一控件树精确匹配。在Accessibility Tree中查找text、content-desc、resource-id与目标描述匹配的节点。匹配支持精确匹配、包含匹配和正则匹配。这是最快、最准的方式但前提是App的无障碍信息完整。策略二控件树模糊匹配。当精确匹配失败时对目标描述做分词和同义词扩展然后在控件树中做模糊匹配。比如目标描述是“登录按钮”而控件树中有一个按钮的text是“登 录”模糊匹配可以命中。策略三视觉模板匹配。当控件树中完全找不到时使用预存的元素截图模板在当前屏幕截图中做模板匹配。这种方式适合图标按钮、自绘控件。模板可以来自长期记忆库也可以由深度模式在首次遇到时生成并存入。三种策略的耗时依次递增但都远低于调用多模态LLM。实测下来策略一通常在50ms内完成策略二在200ms内策略三在500ms左右。而一次多模态LLM调用通常需要2-5秒。4.2 缓存机制与失效策略快速模式之所以快缓存功不可没。ARTEMIS的缓存分两级页面级缓存以“前台Activity 页面结构哈希”为key缓存该页面上所有已定位元素的坐标。下次进入同一页面时直接查缓存。元素级缓存以“元素描述 页面key”为key缓存元素的定位策略和坐标。当页面结构发生小幅度变化时元素级缓存可以配合相对坐标做微调。缓存失效的策略也很重要。ARTEMIS在以下情况会主动清除或更新缓存页面结构哈希发生显著变化控件树节点数量变化超过30%元素定位连续失败两次前台Activity切换屏幕方向或分辨率变化注意缓存不能过度依赖。我见过一些实现为了追求速度缓存了过于激进的坐标信息结果App一次小版本更新后所有缓存全部失效反而导致大量误点击。建议缓存时同时记录元素的多个属性text、content-desc、相对位置失效判断综合多个信号。4.3 快速模式的适用边界与误判处理快速模式不是万能的。它的适用边界很明确目标元素在当前屏幕可见且描述足够具体。如果目标元素需要滚动才能看到或者描述本身模糊比如“那个提交按钮”页面上有三个提交按钮快速模式就会失效或误判。误判的处理机制是快速模式执行动作后调度器会检查执行结果。如果发现点击后页面没有按预期变化或者出现了异常弹窗调度器会将这一步标记为“快速模式失败”然后自动升级到深度模式重新执行。这个降级机制保证了系统的鲁棒性。5. 深度模式的推理链路与Prompt工程5.1 多模态输入的组织方式深度模式的核心是把“当前屏幕状态”和“任务上下文”组织成多模态LLM能理解的输入。ARTEMIS的输入组织方式大致如下系统提示词定义模型的角色移动端GUI操作助手、可用的动作空间、输出格式要求。任务描述当前测试用例的目标比如“完成登录流程并进入首页”。执行历史最近N步的动作和结果摘要N通常取5-10避免上下文过长。当前截图经过压缩和标注的屏幕截图。标注包括在截图上叠加控件树的bounds框和编号方便模型引用。控件树摘要对控件树做剪枝只保留可交互节点和文本节点以结构化文本形式呈现。这种多源输入的组织方式让模型既能“看”到视觉信息又能“读”到结构信息比纯截图输入的效果好很多。5.2 动作空间的约束与输出解析深度模式的输出必须严格约束在预定义的动作空间内否则解析会非常麻烦。ARTEMIS要求模型输出JSON格式的动作指令比如{ action: tap, target: {type: element, id: 3}, reason: 点击登录按钮进入登录页面 }或者{ action: swipe, direction: up, reason: 向上滚动查找更多选项 }输出解析器会校验action字段是否在允许列表内target是否有效。如果解析失败会触发重试或降级到规则兜底。实操心得Prompt里一定要给模型“拒绝执行”的选项。有些时候当前页面状态异常比如网络错误页、崩溃弹窗模型强行操作只会让情况更糟。让模型可以输出{action: abort, reason: ...}然后由上层决定是重试还是标记用例失败。5.3 长程任务的上下文压缩策略深度模式在长程任务中最大的挑战是上下文长度。ARTEMIS采用了两种压缩策略策略一滑动窗口 摘要。只保留最近K步的完整信息更早的步骤压缩成一段文字摘要比如“已完成打开App、点击我的、点击登录、输入用户名”。摘要由模型自己生成或者用规则模板生成。策略二关键帧保留。对于页面发生重大跳转的步骤保留其截图和控件树摘要作为关键帧对于同一页面内的连续操作只保留最后一步的完整信息。这两种策略结合使用可以把一个50步的任务上下文控制在模型窗口的合理范围内。6. 双模式协同的工程实现与调优6.1 模式切换的触发条件与优先级模式切换的触发条件需要仔细设计否则会出现“该快的时候不快该深的时候不深”的问题。ARTEMIS的触发逻辑大致是默认走快速模式如果当前步骤有明确的目标元素描述且该元素在缓存或控件树中可定位直接走快速模式。以下情况强制走深度模式当前步骤是任务的第一步或最后一步需要理解整体状态上一步快速模式执行失败当前页面首次出现且缓存中没有该页面的任何信息任务描述中包含“判断”“确认”“如果”等需要推理的关键词检测到异常弹窗或页面状态异常以下情况优先走快速模式当前页面已有缓存且缓存未失效当前步骤是重复性操作如连续输入多个表单字段上一步深度模式已经明确了当前页面的操作路径6.2 性能与准确率的平衡调参双模式架构的调参目标是在保证准确率的前提下尽可能提高快速模式的占比。ARTEMIS论文中给出的经验值是在典型测试用例中快速模式占比70%-85%是比较健康的区间。如果快速模式占比过低说明缓存和定位策略需要优化如果过高但准确率下降说明快速模式的判定条件太宽松。调参时建议关注几个指标指标含义健康范围快速模式占比快速模式执行步数 / 总步数70%-85%快速模式成功率快速模式中无需降级的比例90%深度模式调用频率每用例平均深度模式调用次数3-8次平均单步耗时从截图到动作执行完成快速1s深度6s用例通过率端到端测试通过率95%这些指标需要在实际项目中持续监控和调整。6.3 异常场景下的降级与恢复异常场景是移动端自动化的常态。ARTEMIS在双模式框架下设计了几种降级和恢复策略快速模式定位失败自动升级到深度模式由模型重新理解页面并给出操作。深度模式输出无效重试一次如果仍无效则回退到规则兜底比如点击屏幕中心、按返回键。连续多步失败暂停当前用例截图保存现场标记为“需人工介入”然后重置App状态继续下一条用例。弹窗干扰检测到系统弹窗权限、更新、广告时优先走快速模式中的弹窗处理规则库如果规则库中没有匹配再交给深度模式判断。注意弹窗处理是移动端自动化最烦人的问题之一。建议在长期记忆库中专门维护一个弹窗规则库记录常见弹窗的关闭按钮位置和文案特征。这个库越丰富快速模式的处理能力就越强。7. 常见问题与排查技巧实录7.1 快速模式定位不准的排查思路快速模式定位不准通常有几个原因控件树信息缺失App使用了自绘UI或FlutterAccessibility Tree中只有最外层容器。排查方法是打印控件树看目标元素是否存在。如果不存在需要依赖视觉定位策略。文本匹配规则太严格目标描述和控件文本存在大小写、空格、标点差异。排查方法是打开模糊匹配日志看匹配得分。缓存过期页面结构已变化但缓存未失效。排查方法是检查页面结构哈希的计算逻辑看是否覆盖了关键属性。多元素匹配冲突页面上有多个相似元素定位到了错误的那个。排查方法是输出所有匹配元素的坐标和属性人工确认。7.2 深度模式“胡说八道”的抑制方法深度模式偶尔会输出看似合理但实际错误的操作比如点击一个不存在的元素、输入错误的文本。抑制方法包括加强输出约束在Prompt中明确要求模型只能引用截图中标注过的元素编号不能凭空捏造。后置校验对模型输出的坐标做范围校验对元素编号做存在性校验。多步一致性检查如果模型连续两步的操作逻辑矛盾比如先输入文本又立刻清空触发人工确认。温度参数调低深度模式的temperature建议设置在0.1-0.3减少随机性。7.3 双模式切换频繁抖动的解决模式切换抖动是指系统在快速模式和深度模式之间反复横跳导致性能下降。解决方法增加切换冷却时间一次深度模式调用后至少接下来2步优先尝试快速模式。引入滞后判断不要因为单次快速模式失败就立刻升级而是连续两次失败才升级。页面级模式锁定对于已知结构稳定的页面强制走快速模式对于已知复杂的页面强制走深度模式。7.4 常见问题速查表问题现象可能原因排查方法解决方向点击无反应坐标偏移、元素被遮挡截图标注点击位置校准坐标、增加等待输入文本失败输入框未聚焦、输入法拦截检查焦点状态先点击输入框再输入页面加载判断错误动画干扰、异步加载检查控件树变化改用Activity关键元素判断弹窗未处理规则库缺失截图记录弹窗补充弹窗规则深度模式超时模型响应慢、上下文过长检查token数压缩上下文、换小模型用例间状态污染App未重置检查App状态每用例前重启App或清数据8. 从ARTEMIS架构看LLM移动端自动化的落地建议如果你打算在自己的项目中借鉴ARTEMIS的双模式思路我的建议是不要一上来就追求全链路LLM化。先把快速模式做扎实——控件树解析、元素定位、缓存机制、弹窗规则库这些是地基。地基打好了深度模式只需要处理那些真正需要“理解”的少数场景整体系统的稳定性和性能都会好很多。另一个体会是长期记忆库的价值被很多人低估了。一个持续积累的页面元素库和弹窗规则库能让快速模式的覆盖率随着时间推移不断提升。我见过一个团队他们的自动化系统跑了三个月后快速模式占比从最初的40%提升到了85%靠的就是长期记忆库的积累。最后双模式架构的调试比单模式复杂因为你要同时关注两条路径的行为和它们之间的切换。建议在早期就建立完善的日志和可视化工具把每一步的模式选择、定位结果、执行反馈都记录下来。这样出问题时你能快速定位是快速模式的锅还是深度模式的锅还是调度器的判断逻辑有问题。