最近 Google 开源了 ARTEMIS，它把 AI Agent 从对话窗口拉到了 Android 真机测试现场。与其说这是个框架，不如说是一套让大模型在真实手机上自己看、自己想、自己点的评估体系。你可能早就见过 Appium 那种按脚本执行 UI 自动化的玩法，ARTEMIS 不一样：你扔给它一句“打开设置，把蓝牙关掉”，它会自己分析屏幕、规划步骤、操作系统，最后把结果反馈给你。我花了一周时间把它跑在自己手边的 Pixel 上，这篇文章就是完整记录和踩坑总结，适合正在做智能体、App 测试，或者想在真机上验收 Agent 效果的朋友。
1. ARTEMIS 是什么：一个给移动 Agent 的“考试系统”
1.1 它解决的核心问题
先聊一个很实际的痛点：拿一个通用的聊天机器人出来，它可能很会说话，但如果你让它“帮我在手机上打开支付宝，交一笔电费”，它立刻就没招了。因为手机界面上有几十个按钮、上千条文本、各种弹窗和动画，模型既看不到屏幕，也不能把手伸进去点按。ARTEMIS 就是用来解决这类问题的：它把真实 Android 设备变成一个可观察、可操作的环境，再让 AI Agent 在环境里完成任务，同时记录每一步的动作、屏幕截图和结果。
我第一次在官方仓库里看到这个框架时，第一反应是“这不就是给手机装了个带视觉的大模型外壳吗”。但真正把文档读完，发现它的核心价值不是那层外壳，而是一套严谨的评估协议。它要求任务必须可量化：成功率是多少，中途卡在哪个步骤，模型是不是绕了远路，这些都会汇总成结构化数据。对于做 Agent 应用的人来说，这种评估数据比“看起来跑通了”重要得多，因为你要向团队证明你的 Agent 到底行还是不行。
1.2 为什么绕不开真机
很多人问：“模拟器不是也能跑吗？为什么非要真机？”答案很简单：模拟器和真机之间隔着一整条真实世界的鸿沟。模拟器里没有厂商的定制系统，没有诡异的刘海屏和手势条，没有 NFC 支付，没有应用商店的真实签名校验，更没有弱网、通知轰炸和系统弹窗。
我实测下来的感受是，Agent 在模拟器上跑得顺顺利利，一旦切到真机，经常遇到“界面元素错位”“权限弹窗抢焦点”“输入法遮挡按钮”这些教科书里没有的场景。ARTEMIS 之所以强调真机测试，就是因为它想让 Agent 在真实状态分布下工作，而不是在理想沙箱里自嗨。这个思路其实和自动驾驶要路测一个道理：仿真环境再逼真，也不如真刀真枪跑一圈。
1.3 它与传统 Android 测试工具的区别
传统 UI 自动化通常是“脚本驱动”：你需要把定位器写好，比如resource-id、text、xpath，然后告诉框架按什么顺序点击、滑动、输入。ARTEMIS 把重心从“脚本”移到了“指令”：任务描述是自然语言，执行过程由 Agent 自行决策。两者对比可以参考下面这个表格。
| 维度 | Appium / UIAutomator 脚本 | ARTEMIS 智能体测试 |
|---|---|---|
| 测试来源 | 工程师手写代码 | 自然语言任务描述，可自动生成 |
| 对界面变化的鲁棒性 | 差，id/坐标一变就挂 | 相对好，模型看语义理解界面 |
| 信息输入 | 控件树、坐标、属性 | 截图、UI 层级、系统状态、日志 |
| 执行逻辑 | 线性步骤，分支有限 | 动态推理，可回退、可修正 |
| 输出结果 | 通过/失败，截图 | 轨迹、原因分析、成功率、失败分类 |
| 维护成本 | 高，脚本需要持续维护 | 中等，Prompt/任务描述需要调优 |
当然，ARTEMIS 并不打算干掉 Appium。相反，脚本可以继续做 CI 里面最稳定的回归，而 ARTEMIS 更适合用来验证那些“无法被脚本穷举”的复杂交互，尤其是涉及多 App 协作和真实用户场景的任务。
2. ARTEMIS 的核心设计拆解
2.1 环境、任务和 Agent 三个角色
ARTEMIS 的架构可以抽象成三个角色：环境（Environment）、任务（Task）、智能体（Agent）。
环境负责提供设备状态和动作接口。它把 Android 设备包裹成一个会话：你给它一个动作，它执行并返回新的屏幕状态。这种设计很像强化学习里的 Gym 环境，只不过动作不是用矩阵和奖励函数描述，而是用“点击坐标”“输入文本”这类可解释操作。任务则是一段自然语言目标，比如“在系统设置里开启飞行模式”“在地图 App 中搜索最近的加油站”，同时还会附带初始条件，需要从哪个 App 开始、有没有登录态、可以成功结束的条件是什么。Agent 是真正做决策的组件，它接收环境返回的截图和控件信息，思考下一步动作，然后调用动作接口。
把这三个角色拆开以后，整个系统变得非常好替换。你想换一个模型做 Agent，不需要动环境层；你想增加一组新任务，不需要改设备管理逻辑；你想在另一家厂商的 Android 手机上跑，也不需要重写推理代码。模块化是这套框架能落地的关键。
2.2 观察空间：Agent 如何“看”手机
Agent 要接管真机，首先要解决“看”的问题。ARTEMIS 的思路是双通道观察：截图 + 控件树。
截图是最直观的图像信息，模型可以通过视觉理解屏幕上有哪些内容、按钮颜色、图标位置、卡片布局。但光看截图有两个问题：一是分辨率太高，直接丢给大模型会消耗大量 Token；二是很多关键信息不在像素里，比如一个文本的准确字符串、一个控件的 accessibility label、某个隐藏的扩展区域。所以 ARTEMIS 同时会从 Android 的 AccessibilityService 或uiautomator dump拿到控件树，把界面转成结构化的 XML/text。
这里有一个很实用的处理技巧：不要把整个 XML 原封不动塞给模型，而要过滤掉无用节点，只保留text、content-desc、class、bounds、clickable这些关键字段。一个复杂的购物首页控件树可能有上千个节点，压缩之后可能只有两三百行文本，这样既保留语义，又把 Token 开销压下来。我在实际调试中还会把“全屏截图”和“压缩后的控件树”拼在一起给多模态模型：图像负责把握视觉布局，文本负责抓准确细节，两者互为补充。
2.3 动作空间：Agent 如何“动”手机
光能看还不够，Agent 必须能执行真实操作。ARTEMIS 把动作空间设计成一组有限的原语，基本覆盖 Android 常用交互：
tap(x, y)：点击屏幕坐标long_press(x, y)：长按swipe(x1, y1, x2, y2, duration)：滑动input_text(text)：输入文本press_key(code)：按实体键，比如 Home、Back、音量键open_app(package_name)：启动指定 Appwait(ms)：等待一段时间，让页面加载稳定
动作空间收敛到这几个原语非常关键。如果允许 Agent 自由调用 Android 系统 API，虽然灵活但给测试带来了巨大的不确定性，也无法统一评估，出现 Bug 了你根本不知道是 Agent 的问题还是动作执行的问题。原语化之后，Agent 的所有行为都变成“可记录、可重放、可审计”的操作序列，这正好满足了回归测试和合规审计的需求。
还有一个容易被忽视的细节是设备状态恢复。真机测试中，Agent 操作到一半，可能会因为输入法弹窗、通知栏下拉导致界面发生变化，所以每次动作执行后，环境可以自动把一些干扰状态复位，或者至少把变化记录在日志里。否则 Agent 会在同一个界面上反复打转。
2.4 多尺度任务与评估指标
ARTEMIS 的难点不在“能跑通”，而在“怎么算对”。如果任务目标是“把系统语言改成英文”，那么 Agent 是否成功好判断，检查当前语言即可。但如果任务是“帮用户订一杯咖啡”，那完成标准就可能很模糊：可选哪家店、哪种杯型、要不要糖，不同选择都算完成。所以 ARTEMIS 设计了多尺度任务，从最简单的“点击某个图标”，到中等难度的“完成一个多步骤设置”，再到复杂的“跨 App 完成一个工作流”，每个任务都定义了明确的成功条件，并支持部分成功和加权评分。
我建议你在自己的项目里也做类似的事：把任务拆成 Level 1、Level 2、Level 3 三级。Level 1 用来验证 Agent 能不能感知和点击；Level 2 用来验证多步规划；Level 3 用来验证长期上下文和繁琐的权限处理。只测高级任务，你很难定位问题是出在“看不懂屏幕”还是“规划能力弱”，分级之后定位会精准很多。
另外，ARTEMIS 还非常关注“代价”：也就是完成任务的步数是多还是少。两个 Agent 都完成了任务，A 用了 5 步，B 用了 20 步。20 步听起来也不算错，但用户体验天差地别。通过把“步数”纳入评估指标，可以倒逼 Agent 优化路径，而不是靠瞎试碰运气。
3. 真机实操：把 Agent 真的接到 Android 设备上
3.1 硬件和系统准备
动手之前，先确认手头设备。别拿一个古董安卓机，屏幕分辨率太低、系统太老，很多界面框架跑不动。我测试用的是 Pixel 7，Android 14 官方系统，原因很简单：ARTEMIS 这类框架通常优先适配 AOSP，厂商定制系统容易出现不同开发者选项、工具栏、权限弹窗不一致的问题。如果只有国产定制机，也不是不行，但建议先把系统更新到较新版本，并关闭所有可能干扰的开关。
设备准备好之后，打开开发者选项，把 USB 调试打开，同时插入数据线连到电脑。为了减少不确定性，我强烈建议把系统动画全部关掉：
adb shell settings put global window_animation_scale 0 adb shell settings put global transition_animation_scale 0 adb shell settings put global animator_duration_scale 0这三条命令会把过渡动画、窗口动画、控件动画关闭。原因很简单：动画时间不确定，Agent 看截图时可能捕捉到“动画中间帧”，导致误判。关掉之后，每个界面都是静止的，截图识别成功率会明显上升。
3.2 搭建 ARTEMIS 环境
官方仓库一般会提供 Python 虚拟环境推荐，这里以我基于源码运行的方式举例。先把仓库拉到本地，然后创建并激活虚拟环境：
git clone https://github.com/google-research/artemis.git cd artemis python -m venv .venv source .venv/bin/activate pip install -r requirements.txt如果你的机器配置了 GPU，并且想跑本地低成本模型，那还需要额外安装torch对应的 CUDA 版本。不过我不建议在一开始就折腾本地模型，先用云端的多模态 API 跑通流程，再考虑本地推理，否则环境问题会挤占调试时间。ARTEMIS 这类项目迭代很快，不同 commit 的依赖差异很大，最好在官方文档标明的 Python 版本下运行。
3.3 连接真机并校准状态
虚拟环境配好之后，先用adb devices确认设备被正确识别：
adb devices # 输出类似： # List of devices attached # 1234567890ABCDEF device如果你看到的是unauthorized，说明手机上的 USB 调试授权弹窗还没点允许。重新插拔数据线，在手机上勾选并确认。这个步骤我踩过好几次坑：有些设备即使点了“允许”，但如果你用的是劣质线或者前置 USB 口供电不稳，一会儿就会跳成 offline。遇到这种情况，先重启 adb server：
adb kill-server adb start-server adb devices设备在线之后，还需要确认屏幕分辨率、系统语言和锁屏状态。锁屏是 Agent 测试的大敌，最好把自动锁屏设置为“从不”，或者至少设置超时时间超过测试时长。系统语言应尽量设为英语，因为很多控件树里的资源名、按钮文本在英文环境下更稳定，Agent 识别起来更准确。如果你的任务本身就要测中文本地化，那就按需调整。
3.4 运行第一个真实任务
我先从一个非常简单的任务开始：让 Agent 打开系统设置里的“深色模式”。这个任务只有几步，且不依赖第三方 App，非常适合验证环境是否连通。ARTEMIS 的 CLI 形式取决于具体版本，但整体思路是：传入任务文件、设备序列号、模型配置，然后开始跑评估。大致命令长这样：
python run_eval.py \ --task tasks/toggle_dark_mode.yaml \ --device SERIAL_ID \ --agent_config configs/gemini_agent.yamltasks/toggle_dark_mode.yaml里一般会写明任务的初始条件、成功判定和关键约束。例如“从桌面开始”“打开设置”“找到深色模式开关并打开”“成功后读取当前界面状态确认”。运行之后，你会看到 Agent 在终端里打印每一步的推理日志：它先看一眼桌面，然后open_app设置，再扫描控件树，找到“Display”或“深色模式”入口，最后点击开关。
我那次跑的时候，Agent 除了第一次点击位置偏了之外，后面几步都很稳。它识别“深色模式”靠的是控件树中的text字段和截图图像，两种信息一交叉验证，基本不会认错。过程中我还开了scrcpy实时看手机屏幕，Agent 的每一个动作都像有人在远程操作一样，那种“AI 接管了你的手机”的真实感非常强。
3.5 把 Agent 跑得更接近实战
简单任务跑通之后，别急着欢呼。接下来我建议直接挑战一个跨 App 任务：比如“打开 Chrome，访问一个本地测试网页，把页面标题复制到备忘录里”。这类任务会逼迫 Agent 处理以下复杂情况：需要从桌面切换 App、地址栏输入 URL、等待页面加载、选择文本并复制、再切换至备忘录并粘贴。每一步都可能引发权限弹窗或输入法遮挡。
我个人的经验是，先手动把这个任务走一遍，记录每一步涉及的新界面。然后给任务文件中加上更完整的前置状态，比如“从备忘录开始”“确保 Chrome 已经登录”“网络连接正常”。如果你不设置这些，Agent 很可能被通知栏的某个推送带偏，或者起始界面不对导致一连串错误。任务越接近真实，越需要定义好边界，否则所有实验都像在“碰运气”。
4. 接管真机测试的关键技术细节
4.1 模型选型：多模态是“下限”，推理能力是“上限”
ARTEMIS 对 Agent 的观察很依赖截图，所以能力强的多模态大模型通常表现更好。但不是所有任务都需要开着视觉，比如一些界面结构固定、文本齐全的工具类 App，只要你把控件树压缩好，纯文本模型也能做得不错。
我做过一组简单的对比：同一个任务，使用多模态模型时，它能通过图标位置和颜色判断“这个按钮可能是打开方式”，成功率更高。纯文本模型如果只能看到控件树，遇到content-desc为空或者两个相似文本的按钮时就会犯迷糊。所以预算足够的情况下，优先选择视觉理解能力强的模型。
但模型强不等于效果一定好。Agent 还需要严格的动作策略：每轮只做一步，先观察再动作。在 ARTEMIS 的配置里，我通常会设置temperature=0，让推理结果确定性更强。如果模型在思考时输出了一堆废话，你还需要在 Prompt 里规定输出格式必须是 JSON，包含reason、action、action_args几个字段，方便后续解析和执行。
4.2 把上下文塞进窗口的省钱妙招
真机截图通常分辨率很高，如果每一帧都传给模型，显存和 API 账单都会爆炸。ARTEMIS 的做法不是把整个原始截图直接丢给模型，而是先做缩放。我常用 720p 分辨率截图，宽度控制在 720，高度按比例缩放，因此截图文件只有几百 KB，传给多模态模型也能减少网络传输延迟。
控件树更需要压缩。Android 自带的 dump 文件里有很多冗余节点：FrameLayout、LinearLayout、各种不可见的 View。写一个过滤函数，只保留clickable=true或包含有效text/content-desc的节点，再把bounds坐标合并到同一行文本里，例如clickable text=确定 bounds=[120,800][300,950]。这样一份 5000 行的原始 XML 可以压到 300 行以内，Token 消耗直接下降一个数量级。
再补充一个经验：截图和控件树描述的是同一个时刻，但如果 Agent 上一步刚点击完，UI 还在加载中，你采到的状态可能已经过期。所以每次抓取状态前，先执行一次短 wait，比如wait(800)，然后重新查看。保护设备脚本里用adb shell查看当前前台应用是否已变为目标 App，再决定是否继续，这比硬 sleep 更靠谱。
4.3 动作执行的可靠性：坐标、滑动和输入法
Agent 通过tap(x, y)操作屏幕，坐标来源通常是控件树里的bounds。但这里有个大坑：如果手机屏幕发生了旋转，或者应用进入全屏模式，坐标系统会变，Agent 拿到的旧坐标就会失效。我处理的方法是每次动作前都重新读取最新屏幕尺寸和控件树，不能让 Agent 缓存上一次的坐标。
滑动操作要多加参数：往回滑动还是向上滑动，时长是 0.2 秒还是 1 秒，都需要在动作原语中明确。不少应用使用了复杂的嵌套滚动，短而快的滑动可能只触发惯性滚动，没有停在目标位置。我把默认滑动时长设为 0.5 秒，稍微平缓一点，识别效果更稳定。
输入文本同样麻烦。Android 的系统输入法可能吞掉首字母，或者自动弹起键盘遮蔽提交按钮。ARTEMIS 的input_text原语如果直接走 adb，就绕过了输入法，可以有效避开这些问题。但如果是真正需要测试搜索框建议，那就得保留输入法场景。你可以通过配置切换两种模式，我测试时优先使用adb shell input text方式，除非任务明确要求验证输入法。
4.4 权限弹窗和系统级干扰的应对策略
Agent 在真机测试中遇到最多的是权限弹窗：存储权限、定位权限、通知权限。这些弹窗有时会驱逐当前 App 的界面，阻断 Agent 原本的路径。ARTEMIS 的成熟做法是：在任务开始前，通过系统命令预授权或拒绝常见权限，让 Agent 专注在核心任务上。
adb shell pm grant com.example.app android.permission.ACCESS_FINE_LOCATION adb shell pm revoke com.example.app android.permission.CAMERA不过预授权也不完全真实。如果你的目标是测试 Agent 在“面对权限申请时如何决策”，那就要故意保留弹窗。这时候你必须确保 Prompt 里有一条原则：当权限弹窗出现时，先阅读弹窗按钮，再执行授权或拒绝；如果看不清，就获取最新截图，不允许盲猜。否则 Agent 会很蠢地反复点击同一位置。
系统级干扰还包括通知面板下滑、低电量弹窗、系统更新提醒。测试前建议开启勿扰模式，并关闭自动更新。我用一个脚本把设备常用干扰源一次性关掉：锁屏关闭、蓝牙关闭、位置开关按任务需求设置。只要做到这一步，很多莫名其妙的失败率就能降下来。
5. 常见问题与排查技巧实录
5.1 设备总是掉线，跑到一半device offline
这是我在长任务里最头疼的问题。大概率是 USB 线接触不良、电脑 USB 口供电不稳，或者 adb 服务被系统重置。我的排查顺序如下。
先说线材。数据线必须支持数据传输，市面上很多充电线只能充电。换线之后，建议直接用adb devices验证连续 10 分钟不掉线。然后再说 adb 服务。如果设备还经常掉，可以考虑把手机视频输出切换到无线调试，但无线调试对网络环境要求较高，局域网不稳定时反而更糟。我的最终稳定方案是：换一台 USB 口供电好的电脑，关闭屏幕休眠，把开发者选项中的“USB 配置”锁定为“RNDIS + 充电”，省得系统自动切换模式。
5.2 Agent 看到的界面和实际真机不一致
出现这种问题，多半是缓存没清理。ARTEMIS 在执行任务前通常会重启 App 或清空后台任务，但没有万能逻辑。我实际操作中已经养成了“先强制停止目标 App，再重新打开”的习惯：
adb shell am force-stop com.example.app adb shell monkey -p com.example.app 1第二条命令启动 app 比较自然，有时比am start更接近用户点击。另外别忘了如果 App 启动了引导页、广告页，Agent 可能误以为任务页面已经加载。你可以把“等待某个关键控件出现”作为动作前置条件，而不是单纯等几秒。
5.3 点击坐标明明对，界面却没有任何反应
这种情况通常是因为控件不在当前窗口，或者被其他 View 遮挡。检查方式：先用adb shell uiautomator dump截图 + 控件树，手动查看目标bounds是否在当前屏幕可见。如果控件在屏幕外，需要滑动后重新定位。还有一种是系统手势条覆盖了底部按钮，点击被系统拦截。我建议把测试手机的导航模式改为“三键导航”，不要用全面屏手势，否则底部区域经常会触发上滑返回。
再一个隐蔽原因：屏幕上存在半透明蒙层，比如“正在加载”遮罩，虽然视觉上不明显，但 Touch 事件被它吃掉。碰到这种情况，最好规避掉所有测试不需要的浮窗，或在等待逻辑里轮询“目标控件可点击”状态。
5.4 Agent 陷入循环，反复点击同一个地方
循环是 Agent 测试里最常见也最头疼的问题。原因一般是环境状态没有变化，但 Agent 不知道。一个有效手段是历史动作去重：如果 Agent 最近 3 步的动作和参数完全一样，系统就可以插入一个wait并强制刷新截图，逼迫 Agent 重新观察。如果重新观察后它还要点同一个位置，那很可能是界面有 Bug 或 Agent 对任务理解有误。
我还会分析失败日志里 Agent 的reason字段。很多时候它一直点同一个按钮，是因为它认为“任务应该在这里完成”，但截图状态并没有满足成功条件。这时候问题不在动作，而在任务定义不明确，需要补充更清晰的终止条件。比如“打开深色模式”不是点击按钮就完了，还要检查“当前界面深浅色是否已变化”。把终止条件写清楚，循环就会少很多。
5.5 并发跑多个真机时，模型请求被限流
如果你不只跑一台设备，而是想在 CI 里同时跑 5 台，就一定会碰到并发问题。底层模型的 API 有每分钟请求数限制，多任务同时打请求，必然有部分请求返回 429 或被降速。我建议在 Agent 请求层加一个简单的令牌桶限流，控制全局每秒最大请求数，同时在遇到限流时做指数退避。不要把并发压到模型 API 的极限，真机测试的瓶颈往往不在手机，而在模型推理。稳妥的策略是 5 台设备共享 3 QPS，每个调度间隔设置 500ms 以上，观察模型响应延迟，再逐步增加设备数。这样才能保证评估数据的稳定性，而不是三天两头因为限流中断。
6. 这套思路给 AI Agent 开发带来的改变
6.1 测试从“写脚本”变成“写需求”
ARTEMIS 给我最大的冲击是“考核目标变了”。以前测试开发要写一堆精细到控件 id 的脚本，现在我可以直接用自然语言描述需求，Agent 自己负责执行。这也带来一个岗位技能变化：你不需要背熟每个控件的定位方式，但你要能把任务的目标、边界、成功标准写清楚。
比如“去设置里看看声音频道”这个描述太模糊。我会改成“打开设置，进入声音设置，打开媒体音量并调整到 50%”，同时注明“如果当前音量是 50%，可以直接结束”。任务描述得越精确，Agent 的表现越稳定。学会写“任务说明书”，是智能体测试时代的上游核心竞争力。
6.2 把 ARTEMIS 当成 Agent 训练的反馈回路
很多做 Agent 的人只盯着 Prompt 调优，忽略了真实环境反馈。ARTEMIS 提供了一个绝佳的闭环：你改动模型权重或 Prompt 之后，直接在真机上自动跑一批任务，得到成功率、步数、失败原因，然后根据反馈再修改。整个过程比人工“试一下感觉像不像人话”要科学得多。
我自己的实践是把 ARTEMIS 接到 CI 流水线，每次提交代码后都在三台真机上跑一套小型回归集。虽然一开始非常慢，几十分钟才能出结果，但正因为慢，它逼着我反复压缩任务集、优化截图压缩，最后速度降到了 8 分钟以内。这个速度已经足够支撑日常迭代。
6.3 可复现性依然是硬骨头
前面说了很多 ARTEMIS 的好处，但真机测试的可复现性仍然难搞，这是所有智能体测试绕不开的问题。设备状态、App 版本、账号登录态、后端开关、网络情况，任何一个变了都可能让 Agent 表现大幅波动。ARTEMIS 框架只能保证“测试任务固定”，不能保证“环境绝对固定”。
所以我必须花额外精力维护一套环境重置方案：每轮任务结束后，强制关闭所有 App，清除目标任务数据，重置系统设置到基线，必要时使用adb shell pm clear。复杂一点的任务还需要拍摄初始屏幕截图，作为“起点钥匙”存到日志里。否则你今天跑 90% 成功率，明天只有 60%，你都不知道是模型退化了还是设备状态漂移了。这个工作很碎，但没它，评测结果就是不可信的。
6.4 最后再分享一个小技巧
跑 ARTEMIS 这类真机测试，最容易被忽略的是“设备上的网络环境”。如果你要测试的是需要登录的电商、外卖、社交 App，网络代理或抓包工具会让 Agent 的行动轨迹完全不同。我通常会在测试前把设备连接到独立的移动热点或专用 Wi-Fi，确保没有任何后台自动更新、推送墙。然后利用任务预热阶段先打开一次目标 App，让它把必要的登录态和用户协议弹窗都稳定下来，再进入正式任务。这个技巧并不复杂，但能把初次启动导致的失败率降掉一大截。
说回 ARTEMIS 本身，它把原本停留在论文里的“AI Agent 操作手机”变成了可审查、可评估的工程系统。哪怕你的业务不使用它的代码，单是它的任务设计、动作空间划分、评估指标和状态恢复机制，也足够当作移动智能体测试的入门教材。如果有一天你的 Agent 能在好几台真机上稳定完成不同任务，你会发现，真正的门槛从来不是“模型会不会操作手机”，而是“你有没有一套方法，让它在每次操作之前看得足够清楚，想得足够明白，然后又能在出错时再站起来继续”。这一步，ARTEMIS 先帮大家踩出来了。
