上周我在给一个电商App做版本回归同一套流程用两台真机跑了三遍每一次都卡在“填写收货地址”这个页面上——不是输入框定位不到就是软键盘把提交按钮挡住。中途我停下手想如果这套操作逻辑能被一个AI Agent看明白并自己执行我干嘛还要一遍遍亲手点恰好那几天看到Google开源的ARTEMIS项目我就围着它研究了大半个月把AI Agent接管Android真机测试的完整链路摸了个遍。这篇文章不打算念官方文档而是想从一个移动端测试从业者的角度把ARTEMIS解决什么问题、模型怎么“看”屏幕、怎么做决策、怎么真正操作真机、多设备并发怎么扛、以及落地时踩过的坑一层层拆开讲清楚。适合正在做移动质量保障、想引入AI Agent做自动化测试的朋友哪怕你之前没怎么碰过Android自动化顺着思路也能跟下来。1. 先盘痛点为什么自动化搞了这么多年真机测试还是靠人肉聊ARTEMIS之前得先明白一个现实移动端自动化测试并不是没有工具恰恰是工具太多但大多数团队最后还是选择人肉回归。这不是懒而是脚本自动化有它的结构性天花板。1.1 录制回放和UI脚本为什么容易碎常见的自动化方案是录制回放或者基于UI定位符的脚本。录制回放看起来很美录一遍审计流程后面就能重复播放。但它本质上是把“操作路径”固化成坐标或控件路径只要页面结构稍微变化脚本就崩。举个很典型的例子Debug包和Release包构建方式不同某个控件的resource-id直接变了或者产品把原来用LinearLayout排布的按钮改成了ConstraintLayout层级深度一变原来依赖的xpath就失效了。这时候测试人员要做的不是“改一个参数”而是重新录制、重新维护定位符。一个App一个月迭代两版脚本维护成本几乎等于重写自然没有精力。更麻烦的是Android的UI hierarchy在动态页面里并不总是可信。列表快速滑动时节点来不及刷新WebView内部的内容往往只有一个节点弹窗、Toast、权限对话框在截图里很显眼但在UI树里处理得很别扭。脚本自动化在静态、稳定、结构简单的页面上很能打一到真实业务场景就力不从心。1.2 真机环境的碎片化不是段子另一个让人肉无法被替代的原因是环境矩阵。Android真机测试面对的变量实在太多维度常见问题ROM定制不同厂商对权限管理、后台策略、通知行为改得五花八门屏幕适配刘海屏、折叠屏、平板的分辨率和安全区差异会导致页面布局变化权限弹窗首次启动的权限弹窗出现时机和文案在不同版本上不同网络状态弱网、断网重连、网关校验对用例结果影响很大账号状态登录态、风控验证、多端互踢每个账号能跑的路径有限这些环境问题让“写死步骤”的脚本变得极其脆弱。自动化跑100条用例可能有20条不是业务bug而是环境干扰。维护人员需要花大量时间判断“这次失败是脚本问题还是环境问题”效率反而更低。1.3 ARTEMIS的赌注把操作路径交给模型实时决策ARTEMIS选择换一条路不再预先固化操作路径而是让AI Agent实时“看”当前屏幕状态自己决定下一步点哪里、输入什么、怎么校验结果。这相当于把测试执行从“按剧本演戏”变成了“带目标的探索式驾驶”。这种方式天然对页面结构变化不敏感。按钮从LinearLayout挪到ConstraintLayout截图里它的位置和文字还在模型就能找到页面新增了一个弹窗模型能根据当前屏幕调整策略权限对话框突然冒出来模型能认出它是干扰项然后点掉。它维护的不是控件定位符而是业务目标和implicit的界面常识。当然这种自由度也带来新的问题模型会不会点错、会不会在页面上乱逛、断言到底可不可信。这些都是后面要重点聊的但至少ARTEMIS给出了一个方向——让Agent像人一样测试而不是让脚本像机器一样死磕。2. 核心工作流一个Agent从“看屏幕”到“点按钮”的完整过程ARTEMIS这类框架在工程上一般抽象成四个层观测、决策、执行、校验。这四个层循环跑起来就是AI Agent在真机上的工作节奏。2.1 观测层截图和UI Hierarchy必须一起用AI Agent要接管真机第一步是理解屏幕。当前主流做法是双通道输入一张是设备截图另一份是UI结构数据。截图负责提供视觉语义。模型能通过图像理解看到一个页面大概是什么业务场景哪里有大按钮哪里是列表哪里有弹窗。但纯靠截图有一个问题LLM对元素的像素坐标定位经常不准。模型知道“登录按钮在屏幕中下方”但具体是x540、y880这个像素点光靠看图像容易偏。所以需要UI Hierarchy兜底。Android里可以通过UIAutomator或Accessibility服务拿到当前界面的控件树里面包含了每个可见控件的bounds、text、content-desc、resource-id。ARTEMIS会把控件树里的有效节点和截图里识别到的视觉区域做映射让模型既能“看懂”页面又能拿到精确的点击坐标。这里有一个实操上的细节UI Hierarchy在复杂页面上可能非常大一个商品详情页有几百个节点。直接把原始XML全丢给LLMToken消耗大而且干扰信息多。实际做的时候要先做裁剪只保留可见节点、去掉重复的父节点分组、把坐标归一化到屏幕宽高百分比。这一步处理得好不好直接影响模型决策的准确率。2.2 决策层ReAct模式在手机点屏上的变形决策层是Agent的大脑。它拿到“当前截图裁剪后的UI节点任务目标历史操作记录”然后决定下一步动作。ARTEMIS在决策上采取的思路和ReAct类似推理一小段行动一小步观察结果再推理。模型输出的是一个结构化的动作指令而不是自然语言。常见动作类型大概是这样{ thought: 当前页面是登录页目标需要进入个人中心先点击手机号输入框, action: tap, target: { text: 请输入手机号, coordinates: [540, 760] }, args: {} }其他常用动作还包括input输入文本、swipe滑动、back返回、wait等待、launch_app打开App等。把动作收敛成固定枚举而不是让模型自由输出是为了后续能安全执行和自动重试。Prompt也很关键。不能只给模型一句“完成这个任务”然后让它自由发挥。好的做法是给它一个类似业务验收标准的描述比如“进入设置页打开Wi-Fi连接名为TestLab的网络如果弹出密码框输入12345678最后确认已连接”。同时指定护栏规则比如“不点击涉及支付、删除、退出的按钮”“遇到系统权限弹窗时统一点击允许”。2.3 执行层和校验层adb桥接动作日志兜底断言模型输出JSON动作之后执行层负责把它变成真机上的真实操作。大多数框架在这一层还是靠adb打底也有用Appium、Android Instrumentation做中间层的。adb的tap/swipe/input text命令稳定可靠再加上对系统级弹窗、通知栏、应用切换的处理能力控制真机非常方便。校验层是我觉得最容易被人低估的部分。Agent执行完一系列操作后怎么判断任务有没有真的完成很多骗人的Demo是模型自己说“已完成”但这不靠谱属于自我幻觉。标准做法是多层校验模型视觉确认让模型看最后一张截图判断目标页面特征是否出现UI树断言检查关键控件是否存在、文本是否符合预期系统日志检测抓logcat里的FATAL EXCEPTION、ANR、无响应窗口等异常屏幕录像抽帧保留完整操作过程方便回放审计。ARTEMIS的设计里判别阶段应该和操作阶段做一定程度的剥离最好由独立的模型实例来验证结果避免同一个模型既当运动员又当裁判。如果验证不通过Agent要能回到上一个关键节点重新尝试而不是傻乎乎地在错误页面继续点。3. 真机接入与并发一台AI Agent是玩具一批设备才是生产力单台设备上跑通Agent只是第一步。真正在团队里用起来要面对的是“一批设备同时跑”的并发问题。热词里有人问“AI Agent怎么扛并发”在Android真机测试场景下这个问题的答案牵扯到设备状态隔离和模型服务限流。3.1 设备池和任务队列怎么设计真机测试天然需要设备池。常见做法是用STFSmartphone Test Farm这类设备管理平台统一接入真机Agent框架通过平台API拿设备。ARTEMIS执行任务时每台设备必须是一个独立Agent SessionSession里保存了这台设备当前的任务目标、操作历史、截图缓存和状态标志。“独立”两个字很关键。如果多个任务共享同一个Agent状态或者设备之间的操作历史串了AI Agent会把这台设备上看到的页面当成另一台设备的结果错误会非常隐蔽。实际做并发的时候每个Agent Session的上下文要完全隔离最好以设备ID为维度做Session key。任务调度可以采用队列加Worker的模式。用户提交一批测试任务队列服务按设备空闲状态分发一台设备同一时间只跑一个任务。简单的生产部署可以是Node.js或者Python进程监听Redis队列每台真机由单独Worker进程控制。3.2 并发瓶颈往往在模型服务不在设备很多人以为真机池数量决定并发上限真跑起来才发现瓶颈往往在模型推理这一环。每个Agent操作一步就要调用一次多模态模型一次推理少则一两秒复杂页面可能要七八秒。假设一个用例需要30步操作单条用例就要几十次模型调用。如果同时有10台设备在跑模型服务的TPS会瞬间被打满。面对这个瓶颈有几个实际可用的优化手段手段说明适用场景共享缓存对相同或相似的屏幕截图做缓存命中后跳过模型调用回归测试中重复页面多控制并发数给每台设备设置最大操作频率避免同时请求模型真机池规模小的时候最实用批量推理多设备截图拼成一张图一起推理省Token和请求数页面结构高度统一的任务失败重试上限单步操作失败重试超过3次就放弃避免死循环打爆模型所有场景都应该设置还有一个小技巧决策层的模型和校验层的模型可以用不同规格。决策层需要更强的视觉理解能力校验层可以用便宜快速的模型最终只有在模型判断存疑时才升级到大模型复核。这样成本能砍掉不少。3.3 设备侧的特殊干扰处理并发环境下更考验对Android设备特性的处理能力。权限弹窗、账号登录、软键盘、系统更新提示这些在单机跑的时候可以人工干预批量跑的时候必须让Agent自己搞定。以权限弹窗为例一个App首次启动可能会连续弹三四个权限请求。如果不做处理Agent可能在“允许/拒绝”的选择上纠结甚至误点。我在实践里会把系统弹窗规则写进Prompt护栏并做一个权限决策配置文件比如“测试机所有运行时权限一律允许”“GPS弹窗出现时点击OK”。这样做不是不尊重用户隐私而是测试环境本来就要保证操作路径不被弹窗阻断。软键盘也是一个容易被忽视的干扰源。输入框聚焦之后软键盘会遮挡屏幕下方内容AI Agent如果只看截图可能找不到被挡住的按钮。处理方式要么在输入完成后主动收起键盘要么在截图前等待键盘动画结束。这个小问题在并发跑APP时能让成功率差出十几个点。4. 本地跑ARTEMIS的第一步环境准备、依赖和一个能跑通的演示用例我知道很多朋友看前面章节会觉得很抽象。这一节直接说落地。ARTEMIS开源项目刚出的时候官方仓库的README比较偏工程向新手第一次跑容易卡在环境上。我按自己折腾的经验整理一个最小可用路径。4.1 环境与依赖我自己常用的环境组合是这样的组件版本建议用途Android SDK最新稳定版提供adb、aapt等工具Android Studio当前稳定版管理AVD模拟器、查看UI层级真机/模拟器Android 10及以上Agent执行对象Python3.10写控制脚本、调用模型APINode.js18跑管理台、任务队列Redis6.x任务队列、缓存模型API支持视觉的多模态模型屏幕理解和动作决策如果你本地实在没有Android设备可以先创建AVD模拟器跑通流程。模拟器在并发、镜像恢复、重置数据上比真机还方便唯一的问题是部分交互和真机有差异比如需要手势完成的隐私引导页、某些系统版本弹窗。另外要注意adb版本和设备的匹配。很多老设备用新版adb会连接不稳定用Android Studio自带的platform-tools最省心。连接好之后先用adb devices确认设备状态再跑一遍adb shell wm size确认分辨率避免Agent把坐标归一化做错。4.2 一个最简单的演示任务打开设置修改语言第一次跑ARTEMIS或者自己写的Agent循环我建议选一个业务风险低的短任务。比如“打开设置页进入语言与输入法把系统语言从中文切成英文”。这个任务步骤短、页面结构稳定、结果容易验证非常适合用来检查Agent管线的每一环是否正常。一个大致可控循环的代码骨架可以参考这种形式def run_agent_loop(device, task_prompt, max_steps30): history [] for step in range(max_steps): screenshot take_screenshot(device) ui_nodes get_ui_hierarchy(device, filteredTrue) action model_decide(screenshot, ui_nodes, task_prompt, history) execute_action(device, action) history.append(action) if is_task_done(device, task_prompt): return generate_test_report(device, history) return {status: timeout, history: history}这不是ARTEMIS的全部源码只是一个最朴素的示意。真实框架里会在决策前后加入很多状态管理比如记录当前Activity名、处理异常弹窗、对同一步操作去重。跑这个演示任务的时候我强烈建议人盯着屏幕看。不是为了监视而是要记录模型在哪个环节犯了傻。比如有些模型会在“语言与输入法”页面分辨不出“添加语言”和“默认语言”的区别在列表里乱翻。这些观察结果就是你后面调Prompt、调UI节点裁剪策略的依据。4.3 模型服务选型与替换官方仓库最初示例里绑定的模型能力确实在复杂页面和长链路上表现最好。但实际开发里很多人手里没有现成的云模型额度或者所在环境对调用有限制。对此我的建议是把模型层做成可插拔的接口只保留“输入截图UI节点输出动作JSON”这个契约然后根据手里资源选择实现。我自己试过用开源多模态模型跑简单任务在页面结构干净的场景下效果还能接受一旦屏幕元素拥挤、层级复杂动作准确性会明显下降。如果你打算在本地模型上跑ARTEMIS最好把期望值放低一点适合做预扫描、辅助分析不适合直接做关键业务全流程测试。5. 从Demo到生产我最关心的三个稳定和可信度问题把ARTEMIS从“能在模拟器上跑通”推进到“能在团队里当测试工具用”中间隔着一堆工程问题。这里挑三个我最在意的说每一个都是我在实际调试时真实踩过或者被同事问过的。5.1 误操作和业务数据污染怎么防AI Agent在真机上自由操作最让人害怕的就是“点错”。轻则点到设置项让手机状态改变重则发起一笔真实支付、删除一条数据、给用户发送一条垃圾消息。测试阶段如果跑在真实业务账号上这是绝对的安全事故。我的处理办法是做到三层隔离环境隔离优先使用可重置的模拟器或专用测试机不用同事的日常手机账号隔离用测试专用账号充值余额、商品库存、联系人数据都要有备份行为隔离在Prompt护栏里明确禁止点击支付、删除、退出等危险控件动作白名单之外的操作需要二次确认。真机池方案的话还要有镜像恢复机制。每台测试机跑完任务后自动清理数据和重置状态这样就算Agent把手机设置改得乱七八糟下一轮任务开始时又是一台干净的设备。5.2 AI说“测试通过”到底能不能信这是整个AI Agent测试里最有争议的一块。模型跑完一个用例在报告里写“验证通过”你拿着报告去上线结果用户反馈注册流程根本走不通。问题出在模型把自己“看到步骤都执行完”当成了“业务验证通过”。要让断言可信就不能只有一个AI裁判。我在方案里喜欢用“三条腿”验证结构化校验用UI Hierarchy确认关键页面元素存在比如注册成功页出现了“欢迎”文案数据层校验调用后端接口或数据库确认数据真的变了比如新账号真的入库了日志异常扫描抓取logcat中的crash、ANR、SecurityException等异常。只有这三条都过了报告里才允许出现“通过”。模型视觉确认最多算补充证据不能当唯一标准。ARTEMIS这类框架未来如果能在报告里把每一步的截图、动作和系统状态都记录成可回放的证据链那AI测试的可信度才真正站得住。5.3 跑一轮回归的时间和成本估算AI Agent测试目前还不是“免费午餐”。我把一个30步用例的成本拆开看每步平均需要一次视觉推理加一次文本推理按主流商业模型API的价格估算单用例的推理成本在几毛到几块钱之间。如果每个版本回归跑500条用例模型费用会是一笔肉眼可见的开支。时间成本也要算。单步决策1到3秒30步用例加上页面加载和设备响应一条跑下来基本要3到5分钟。如果重试两三次直接翻倍。所以生产落地时要做用例分级核心主流程用AI Agent跑非核心页面用传统脚本或抽样人测而不是一股脑全交给Agent。成本优化上可以先找出高重复度的公共页面对稳定页面建立截图缓存不重复请求模型另外把失败重试上限设成2次杜绝模型在同一个页面上反复横跳。这些细节看着不起眼跑一个月的回归能省下不少钱和等待时间。6. AI Agent会抢走测试工程师的工作吗聊到AI Agent接管真机测试很多人第一反应是“那做测试的人是不是要失业了”。我在实际用了一段时间之后反而觉得问题问反了。它不会让测试岗位消失但会改变测试工作的重心。6.1 岗位技能正在从“录脚本”变成“训Agent”传统移动测试的核心技能是写脚本、维护定位符、搭自动化框架。在ARTEMIS这种AI Agent模式下这些工作占比会下降取而代之的是Prompt场景设计、Agent结果审计、失败案例标注和模型输出校准。比如你要让Agent测“下单流程”核心工作不是写点击坐标而是把业务规则翻译成模型能理解的验收条件——哪些按钮不能点、为什么不能点、订单状态怎么算成功、遇到异常弹窗怎么处理。这更像是在训练一个半懂业务的新员工而不是在写一段死板的命令序列。另外一个隐形需求是“数据标注”。Agent跑错的时候你要能判断是模型看不懂屏幕、Prompt目标不清晰、还是UI Hierarchy裁剪丢了关键信息然后把这个案例沉淀下来回灌到测试集里。这种能力传统脚本工程师不一定要有但AI Agent测试一定需要。6.2 现阶段哪些场景还不建议完全交给Agent虽然ARTEMIS很漂亮但我不建议所有场景立刻全量替换掉现有自动化。下面几类场景我的经验是AI Agent还不能完全独当一面场景原因涉及真实支付误触成本太高必须有强数据层校验和人工确认强时间敏感性操作直播秒杀、倒计时活动Agent决策延迟容易错过时机深度手势交互复杂多点触控、缩放手势模型理解和执行精度不够需要外设配合NFC、扫码枪、蓝牙外设Agent很难感知和模拟在这些场景里AI Agent更适合扮演“辅助探索”的角色比如先让Agent在测试包上把崩溃和异常路径探出来再由人工或传统脚本验证关键业务而不是全自动接管。6.3 我从ARTEMIS里带走的实际经验最后说点个人体会。我在这套东西上折腾了半个多月最深的感受是要让AI Agent在真机上稳定跑70%的功夫不在那个最显眼的“模型决策”而在设备状态管理、UI数据质量、断言可信度和成本控制这些看起来不性感的问题上。如果你也想上手我给的建议是别一上来就追求全自动、大规模、取代现有框架。先搭一台模拟器、跑通一个简单用例、把操作日志和截图证据链做好再逐步加复杂任务。把“AI Agent接管真机测试”从Demo变成生产力核心不是模型有多聪明而是你的测试场景能不能稳定地喂给Agent并且让每一次判断都有据可查。ARTEMIS最让我服气的不是某一个算法多强而是它把“让AI自己操作手机”这件事做成了开源、可审计、可复现的工具。这个方向一旦跑顺移动端测试的效率模型会彻底变一次。 
长河君 · 2026/11/2 17:16:42 · 阅读 1.2k AI Agent接管Android真机测试：ARTEMIS实战拆解
上周我在给一个电商App做版本回归同一套流程用两台真机跑了三遍每一次都卡在“填写收货地址”这个页面上——不是输入框定位不到就是软键盘把提交按钮挡住。中途我停下手想如果这套操作逻辑能被一个AI Agent看明白并自己执行我干嘛还要一遍遍亲手点恰好那几天看到Google开源的ARTEMIS项目我就围着它研究了大半个月把AI Agent接管Android真机测试的完整链路摸了个遍。这篇文章不打算念官方文档而是想从一个移动端测试从业者的角度把ARTEMIS解决什么问题、模型怎么“看”屏幕、怎么做决策、怎么真正操作真机、多设备并发怎么扛、以及落地时踩过的坑一层层拆开讲清楚。适合正在做移动质量保障、想引入AI Agent做自动化测试的朋友哪怕你之前没怎么碰过Android自动化顺着思路也能跟下来。1. 先盘痛点为什么自动化搞了这么多年真机测试还是靠人肉聊ARTEMIS之前得先明白一个现实移动端自动化测试并不是没有工具恰恰是工具太多但大多数团队最后还是选择人肉回归。这不是懒而是脚本自动化有它的结构性天花板。1.1 录制回放和UI脚本为什么容易碎常见的自动化方案是录制回放或者基于UI定位符的脚本。录制回放看起来很美录一遍审计流程后面就能重复播放。但它本质上是把“操作路径”固化成坐标或控件路径只要页面结构稍微变化脚本就崩。举个很典型的例子Debug包和Release包构建方式不同某个控件的resource-id直接变了或者产品把原来用LinearLayout排布的按钮改成了ConstraintLayout层级深度一变原来依赖的xpath就失效了。这时候测试人员要做的不是“改一个参数”而是重新录制、重新维护定位符。一个App一个月迭代两版脚本维护成本几乎等于重写自然没有精力。更麻烦的是Android的UI hierarchy在动态页面里并不总是可信。列表快速滑动时节点来不及刷新WebView内部的内容往往只有一个节点弹窗、Toast、权限对话框在截图里很显眼但在UI树里处理得很别扭。脚本自动化在静态、稳定、结构简单的页面上很能打一到真实业务场景就力不从心。1.2 真机环境的碎片化不是段子另一个让人肉无法被替代的原因是环境矩阵。Android真机测试面对的变量实在太多维度常见问题ROM定制不同厂商对权限管理、后台策略、通知行为改得五花八门屏幕适配刘海屏、折叠屏、平板的分辨率和安全区差异会导致页面布局变化权限弹窗首次启动的权限弹窗出现时机和文案在不同版本上不同网络状态弱网、断网重连、网关校验对用例结果影响很大账号状态登录态、风控验证、多端互踢每个账号能跑的路径有限这些环境问题让“写死步骤”的脚本变得极其脆弱。自动化跑100条用例可能有20条不是业务bug而是环境干扰。维护人员需要花大量时间判断“这次失败是脚本问题还是环境问题”效率反而更低。1.3 ARTEMIS的赌注把操作路径交给模型实时决策ARTEMIS选择换一条路不再预先固化操作路径而是让AI Agent实时“看”当前屏幕状态自己决定下一步点哪里、输入什么、怎么校验结果。这相当于把测试执行从“按剧本演戏”变成了“带目标的探索式驾驶”。这种方式天然对页面结构变化不敏感。按钮从LinearLayout挪到ConstraintLayout截图里它的位置和文字还在模型就能找到页面新增了一个弹窗模型能根据当前屏幕调整策略权限对话框突然冒出来模型能认出它是干扰项然后点掉。它维护的不是控件定位符而是业务目标和implicit的界面常识。当然这种自由度也带来新的问题模型会不会点错、会不会在页面上乱逛、断言到底可不可信。这些都是后面要重点聊的但至少ARTEMIS给出了一个方向——让Agent像人一样测试而不是让脚本像机器一样死磕。2. 核心工作流一个Agent从“看屏幕”到“点按钮”的完整过程ARTEMIS这类框架在工程上一般抽象成四个层观测、决策、执行、校验。这四个层循环跑起来就是AI Agent在真机上的工作节奏。2.1 观测层截图和UI Hierarchy必须一起用AI Agent要接管真机第一步是理解屏幕。当前主流做法是双通道输入一张是设备截图另一份是UI结构数据。截图负责提供视觉语义。模型能通过图像理解看到一个页面大概是什么业务场景哪里有大按钮哪里是列表哪里有弹窗。但纯靠截图有一个问题LLM对元素的像素坐标定位经常不准。模型知道“登录按钮在屏幕中下方”但具体是x540、y880这个像素点光靠看图像容易偏。所以需要UI Hierarchy兜底。Android里可以通过UIAutomator或Accessibility服务拿到当前界面的控件树里面包含了每个可见控件的bounds、text、content-desc、resource-id。ARTEMIS会把控件树里的有效节点和截图里识别到的视觉区域做映射让模型既能“看懂”页面又能拿到精确的点击坐标。这里有一个实操上的细节UI Hierarchy在复杂页面上可能非常大一个商品详情页有几百个节点。直接把原始XML全丢给LLMToken消耗大而且干扰信息多。实际做的时候要先做裁剪只保留可见节点、去掉重复的父节点分组、把坐标归一化到屏幕宽高百分比。这一步处理得好不好直接影响模型决策的准确率。2.2 决策层ReAct模式在手机点屏上的变形决策层是Agent的大脑。它拿到“当前截图裁剪后的UI节点任务目标历史操作记录”然后决定下一步动作。ARTEMIS在决策上采取的思路和ReAct类似推理一小段行动一小步观察结果再推理。模型输出的是一个结构化的动作指令而不是自然语言。常见动作类型大概是这样{ thought: 当前页面是登录页目标需要进入个人中心先点击手机号输入框, action: tap, target: { text: 请输入手机号, coordinates: [540, 760] }, args: {} }其他常用动作还包括input输入文本、swipe滑动、back返回、wait等待、launch_app打开App等。把动作收敛成固定枚举而不是让模型自由输出是为了后续能安全执行和自动重试。Prompt也很关键。不能只给模型一句“完成这个任务”然后让它自由发挥。好的做法是给它一个类似业务验收标准的描述比如“进入设置页打开Wi-Fi连接名为TestLab的网络如果弹出密码框输入12345678最后确认已连接”。同时指定护栏规则比如“不点击涉及支付、删除、退出的按钮”“遇到系统权限弹窗时统一点击允许”。2.3 执行层和校验层adb桥接动作日志兜底断言模型输出JSON动作之后执行层负责把它变成真机上的真实操作。大多数框架在这一层还是靠adb打底也有用Appium、Android Instrumentation做中间层的。adb的tap/swipe/input text命令稳定可靠再加上对系统级弹窗、通知栏、应用切换的处理能力控制真机非常方便。校验层是我觉得最容易被人低估的部分。Agent执行完一系列操作后怎么判断任务有没有真的完成很多骗人的Demo是模型自己说“已完成”但这不靠谱属于自我幻觉。标准做法是多层校验模型视觉确认让模型看最后一张截图判断目标页面特征是否出现UI树断言检查关键控件是否存在、文本是否符合预期系统日志检测抓logcat里的FATAL EXCEPTION、ANR、无响应窗口等异常屏幕录像抽帧保留完整操作过程方便回放审计。ARTEMIS的设计里判别阶段应该和操作阶段做一定程度的剥离最好由独立的模型实例来验证结果避免同一个模型既当运动员又当裁判。如果验证不通过Agent要能回到上一个关键节点重新尝试而不是傻乎乎地在错误页面继续点。3. 真机接入与并发一台AI Agent是玩具一批设备才是生产力单台设备上跑通Agent只是第一步。真正在团队里用起来要面对的是“一批设备同时跑”的并发问题。热词里有人问“AI Agent怎么扛并发”在Android真机测试场景下这个问题的答案牵扯到设备状态隔离和模型服务限流。3.1 设备池和任务队列怎么设计真机测试天然需要设备池。常见做法是用STFSmartphone Test Farm这类设备管理平台统一接入真机Agent框架通过平台API拿设备。ARTEMIS执行任务时每台设备必须是一个独立Agent SessionSession里保存了这台设备当前的任务目标、操作历史、截图缓存和状态标志。“独立”两个字很关键。如果多个任务共享同一个Agent状态或者设备之间的操作历史串了AI Agent会把这台设备上看到的页面当成另一台设备的结果错误会非常隐蔽。实际做并发的时候每个Agent Session的上下文要完全隔离最好以设备ID为维度做Session key。任务调度可以采用队列加Worker的模式。用户提交一批测试任务队列服务按设备空闲状态分发一台设备同一时间只跑一个任务。简单的生产部署可以是Node.js或者Python进程监听Redis队列每台真机由单独Worker进程控制。3.2 并发瓶颈往往在模型服务不在设备很多人以为真机池数量决定并发上限真跑起来才发现瓶颈往往在模型推理这一环。每个Agent操作一步就要调用一次多模态模型一次推理少则一两秒复杂页面可能要七八秒。假设一个用例需要30步操作单条用例就要几十次模型调用。如果同时有10台设备在跑模型服务的TPS会瞬间被打满。面对这个瓶颈有几个实际可用的优化手段手段说明适用场景共享缓存对相同或相似的屏幕截图做缓存命中后跳过模型调用回归测试中重复页面多控制并发数给每台设备设置最大操作频率避免同时请求模型真机池规模小的时候最实用批量推理多设备截图拼成一张图一起推理省Token和请求数页面结构高度统一的任务失败重试上限单步操作失败重试超过3次就放弃避免死循环打爆模型所有场景都应该设置还有一个小技巧决策层的模型和校验层的模型可以用不同规格。决策层需要更强的视觉理解能力校验层可以用便宜快速的模型最终只有在模型判断存疑时才升级到大模型复核。这样成本能砍掉不少。3.3 设备侧的特殊干扰处理并发环境下更考验对Android设备特性的处理能力。权限弹窗、账号登录、软键盘、系统更新提示这些在单机跑的时候可以人工干预批量跑的时候必须让Agent自己搞定。以权限弹窗为例一个App首次启动可能会连续弹三四个权限请求。如果不做处理Agent可能在“允许/拒绝”的选择上纠结甚至误点。我在实践里会把系统弹窗规则写进Prompt护栏并做一个权限决策配置文件比如“测试机所有运行时权限一律允许”“GPS弹窗出现时点击OK”。这样做不是不尊重用户隐私而是测试环境本来就要保证操作路径不被弹窗阻断。软键盘也是一个容易被忽视的干扰源。输入框聚焦之后软键盘会遮挡屏幕下方内容AI Agent如果只看截图可能找不到被挡住的按钮。处理方式要么在输入完成后主动收起键盘要么在截图前等待键盘动画结束。这个小问题在并发跑APP时能让成功率差出十几个点。4. 本地跑ARTEMIS的第一步环境准备、依赖和一个能跑通的演示用例我知道很多朋友看前面章节会觉得很抽象。这一节直接说落地。ARTEMIS开源项目刚出的时候官方仓库的README比较偏工程向新手第一次跑容易卡在环境上。我按自己折腾的经验整理一个最小可用路径。4.1 环境与依赖我自己常用的环境组合是这样的组件版本建议用途Android SDK最新稳定版提供adb、aapt等工具Android Studio当前稳定版管理AVD模拟器、查看UI层级真机/模拟器Android 10及以上Agent执行对象Python3.10写控制脚本、调用模型APINode.js18跑管理台、任务队列Redis6.x任务队列、缓存模型API支持视觉的多模态模型屏幕理解和动作决策如果你本地实在没有Android设备可以先创建AVD模拟器跑通流程。模拟器在并发、镜像恢复、重置数据上比真机还方便唯一的问题是部分交互和真机有差异比如需要手势完成的隐私引导页、某些系统版本弹窗。另外要注意adb版本和设备的匹配。很多老设备用新版adb会连接不稳定用Android Studio自带的platform-tools最省心。连接好之后先用adb devices确认设备状态再跑一遍adb shell wm size确认分辨率避免Agent把坐标归一化做错。4.2 一个最简单的演示任务打开设置修改语言第一次跑ARTEMIS或者自己写的Agent循环我建议选一个业务风险低的短任务。比如“打开设置页进入语言与输入法把系统语言从中文切成英文”。这个任务步骤短、页面结构稳定、结果容易验证非常适合用来检查Agent管线的每一环是否正常。一个大致可控循环的代码骨架可以参考这种形式def run_agent_loop(device, task_prompt, max_steps30): history [] for step in range(max_steps): screenshot take_screenshot(device) ui_nodes get_ui_hierarchy(device, filteredTrue) action model_decide(screenshot, ui_nodes, task_prompt, history) execute_action(device, action) history.append(action) if is_task_done(device, task_prompt): return generate_test_report(device, history) return {status: timeout, history: history}这不是ARTEMIS的全部源码只是一个最朴素的示意。真实框架里会在决策前后加入很多状态管理比如记录当前Activity名、处理异常弹窗、对同一步操作去重。跑这个演示任务的时候我强烈建议人盯着屏幕看。不是为了监视而是要记录模型在哪个环节犯了傻。比如有些模型会在“语言与输入法”页面分辨不出“添加语言”和“默认语言”的区别在列表里乱翻。这些观察结果就是你后面调Prompt、调UI节点裁剪策略的依据。4.3 模型服务选型与替换官方仓库最初示例里绑定的模型能力确实在复杂页面和长链路上表现最好。但实际开发里很多人手里没有现成的云模型额度或者所在环境对调用有限制。对此我的建议是把模型层做成可插拔的接口只保留“输入截图UI节点输出动作JSON”这个契约然后根据手里资源选择实现。我自己试过用开源多模态模型跑简单任务在页面结构干净的场景下效果还能接受一旦屏幕元素拥挤、层级复杂动作准确性会明显下降。如果你打算在本地模型上跑ARTEMIS最好把期望值放低一点适合做预扫描、辅助分析不适合直接做关键业务全流程测试。5. 从Demo到生产我最关心的三个稳定和可信度问题把ARTEMIS从“能在模拟器上跑通”推进到“能在团队里当测试工具用”中间隔着一堆工程问题。这里挑三个我最在意的说每一个都是我在实际调试时真实踩过或者被同事问过的。5.1 误操作和业务数据污染怎么防AI Agent在真机上自由操作最让人害怕的就是“点错”。轻则点到设置项让手机状态改变重则发起一笔真实支付、删除一条数据、给用户发送一条垃圾消息。测试阶段如果跑在真实业务账号上这是绝对的安全事故。我的处理办法是做到三层隔离环境隔离优先使用可重置的模拟器或专用测试机不用同事的日常手机账号隔离用测试专用账号充值余额、商品库存、联系人数据都要有备份行为隔离在Prompt护栏里明确禁止点击支付、删除、退出等危险控件动作白名单之外的操作需要二次确认。真机池方案的话还要有镜像恢复机制。每台测试机跑完任务后自动清理数据和重置状态这样就算Agent把手机设置改得乱七八糟下一轮任务开始时又是一台干净的设备。5.2 AI说“测试通过”到底能不能信这是整个AI Agent测试里最有争议的一块。模型跑完一个用例在报告里写“验证通过”你拿着报告去上线结果用户反馈注册流程根本走不通。问题出在模型把自己“看到步骤都执行完”当成了“业务验证通过”。要让断言可信就不能只有一个AI裁判。我在方案里喜欢用“三条腿”验证结构化校验用UI Hierarchy确认关键页面元素存在比如注册成功页出现了“欢迎”文案数据层校验调用后端接口或数据库确认数据真的变了比如新账号真的入库了日志异常扫描抓取logcat中的crash、ANR、SecurityException等异常。只有这三条都过了报告里才允许出现“通过”。模型视觉确认最多算补充证据不能当唯一标准。ARTEMIS这类框架未来如果能在报告里把每一步的截图、动作和系统状态都记录成可回放的证据链那AI测试的可信度才真正站得住。5.3 跑一轮回归的时间和成本估算AI Agent测试目前还不是“免费午餐”。我把一个30步用例的成本拆开看每步平均需要一次视觉推理加一次文本推理按主流商业模型API的价格估算单用例的推理成本在几毛到几块钱之间。如果每个版本回归跑500条用例模型费用会是一笔肉眼可见的开支。时间成本也要算。单步决策1到3秒30步用例加上页面加载和设备响应一条跑下来基本要3到5分钟。如果重试两三次直接翻倍。所以生产落地时要做用例分级核心主流程用AI Agent跑非核心页面用传统脚本或抽样人测而不是一股脑全交给Agent。成本优化上可以先找出高重复度的公共页面对稳定页面建立截图缓存不重复请求模型另外把失败重试上限设成2次杜绝模型在同一个页面上反复横跳。这些细节看着不起眼跑一个月的回归能省下不少钱和等待时间。6. AI Agent会抢走测试工程师的工作吗聊到AI Agent接管真机测试很多人第一反应是“那做测试的人是不是要失业了”。我在实际用了一段时间之后反而觉得问题问反了。它不会让测试岗位消失但会改变测试工作的重心。6.1 岗位技能正在从“录脚本”变成“训Agent”传统移动测试的核心技能是写脚本、维护定位符、搭自动化框架。在ARTEMIS这种AI Agent模式下这些工作占比会下降取而代之的是Prompt场景设计、Agent结果审计、失败案例标注和模型输出校准。比如你要让Agent测“下单流程”核心工作不是写点击坐标而是把业务规则翻译成模型能理解的验收条件——哪些按钮不能点、为什么不能点、订单状态怎么算成功、遇到异常弹窗怎么处理。这更像是在训练一个半懂业务的新员工而不是在写一段死板的命令序列。另外一个隐形需求是“数据标注”。Agent跑错的时候你要能判断是模型看不懂屏幕、Prompt目标不清晰、还是UI Hierarchy裁剪丢了关键信息然后把这个案例沉淀下来回灌到测试集里。这种能力传统脚本工程师不一定要有但AI Agent测试一定需要。6.2 现阶段哪些场景还不建议完全交给Agent虽然ARTEMIS很漂亮但我不建议所有场景立刻全量替换掉现有自动化。下面几类场景我的经验是AI Agent还不能完全独当一面场景原因涉及真实支付误触成本太高必须有强数据层校验和人工确认强时间敏感性操作直播秒杀、倒计时活动Agent决策延迟容易错过时机深度手势交互复杂多点触控、缩放手势模型理解和执行精度不够需要外设配合NFC、扫码枪、蓝牙外设Agent很难感知和模拟在这些场景里AI Agent更适合扮演“辅助探索”的角色比如先让Agent在测试包上把崩溃和异常路径探出来再由人工或传统脚本验证关键业务而不是全自动接管。6.3 我从ARTEMIS里带走的实际经验最后说点个人体会。我在这套东西上折腾了半个多月最深的感受是要让AI Agent在真机上稳定跑70%的功夫不在那个最显眼的“模型决策”而在设备状态管理、UI数据质量、断言可信度和成本控制这些看起来不性感的问题上。如果你也想上手我给的建议是别一上来就追求全自动、大规模、取代现有框架。先搭一台模拟器、跑通一个简单用例、把操作日志和截图证据链做好再逐步加复杂任务。把“AI Agent接管真机测试”从Demo变成生产力核心不是模型有多聪明而是你的测试场景能不能稳定地喂给Agent并且让每一次判断都有据可查。ARTEMIS最让我服气的不是某一个算法多强而是它把“让AI自己操作手机”这件事做成了开源、可审计、可复现的工具。这个方向一旦跑顺移动端测试的效率模型会彻底变一次。