企业官网建设流程全解析

移动端 AI 自动化这两年一直挂着“看着热闹、落地稀碎”的标签。手机上的日常操作，本质上就是“看屏幕、定计划、动手操作”，这跟 AI 智能体最擅长的“感知、决策、执行”几乎是一一对应的，可真的能让 AI 自己跑到手机里点按钮、滑页面、填表单的开源方案，少之又少。ARTEMIS 是谷歌开源出来的移动端 AI 自动化框架，它的核心目标非常直接：让 AI 助手像人一样操作手机——拿到当前界面之后自己拆解下一步，然后执行点击、滑动、输入这些真实操作。

这篇不是翻译官方 README，而是把 ARTEMIS 从原理到落地拆开讲清楚，再附上我本地跑通一个 Demo 的完整经历和踩坑记录。适合这几类人看：被移动端 UI 自动化脚本维护烦透了的测试开发、想自己搭一台手机助手的研究者、以及做 Agent 应用但执行端一直没找到好载体的产品团队。我先把结论放这儿：ARTEMIS 的入门曲线确实比想象中低，但“跑通”和“跑稳”之间隔着一堆工程细节，如果你正准备上手，这篇能帮你省掉不少弯路。

1. 传统移动端自动化框架，为什么卡在“像人操作”这件事上

1.1 脚本第一步是定位控件，这本身就限定了它的天花板

传统移动端自动化方案，Appium、UIAutomator、XCUITest 这些，核心工作对象是控件树，也就是 Android 里的 View Hierarchy 或者 iOS 里的 Accessibility 节点。测试代码里的核心语句永远是driver.findElement(By.id("xxx"))、findElementByXPath("//android.widget.Button[1]")这一类。这背后有一个隐含前提：必须先拿到页面结构，脚本才能做事。

问题就出在这个“先有结构”上。现代移动应用大量使用服务端下发配置、动态渲染、跨端框架，控件 ID 可能被混淆、结构可能随版本变化、甚至同一个按钮在不同 A/B 实验组里有着完全不同的标识，脚本的维护成本会迅速失控。我见过不少团队，自动化用例量看似庞大，实际每个迭代光“修定位”就要花掉一半的排期，这已经不是自动化，而是新形式的体力活。

1.2 跨端一致性，折腾掉无数团队的半条命

如果只做 Android 单端，控件树方案勉强能用；一旦要覆盖 iOS、鸿蒙或者小程序容器，跨端方案就开始乱套。不同端拿出来的 UI 描述格式完全不同：

跨端框架往往要自己再做一层抽象和原生桥接，每一端都要单独适配。这个抽象层的代价不小，而且一旦页面是 Canvas 绘制或者游戏渲染出来的，控件树直接拿不到可用信息，脚本立刻失效。

1.3 最核心的缺口：语义理解

传统自动化脚本最缺的，其实是对“屏幕在表达什么”的理解。举个真实例子：购物 App 的“结算”按钮，在控件树里可能叫tv_btn_pay，也可能叫button_right，也有可能因为动态布局压根没有稳定 ID。人看到页面，结合“下单”这个意图，能瞬间判断该点哪个位置；脚本没有这个能力，只能靠写脚本的人事先把所有可能性预测完。

这就是传统方案的上限：它们做的是“翻译已有结构”，而不是“理解当前画面”。ARTEMIS 敢于拿 AI 模型来做自动化，本质就是把“翻译结构”这一环替换成“理解意图”，从根上解决语义缺失问题。

2. ARTEMIS 的核心链路：UI 感知、意图理解、动作执行

2.1 一次完整操作循环，拆开看只有四步

ARTEMIS 的基本工作模式是一个智能体闭环。我把它拆成四个步骤：

1. 观察：获取当前屏幕截图，同时把页面 UI 描述信息一并采集出来。
2. 推理：把截图 + UI 描述 + 用户任务一起交给视觉语言模型，让模型输出下一步该执行什么动作。
3. 执行：将模型输出的动作解析成系统级指令，通过 ADB 通道模拟点击、滑动、输入。
4. 验证：再次获取屏幕状态，确认动作是否生效、任务是否完成，不满足则回到第一步。

这四步形成一个循环，直到任务完成或者触发终止条件。从架构上看，ARTEMIS 做的其实是把所有“脚本里写死”的东西全部外置给模型——定位逻辑外置、异常处理外置、任务拆解外置，本地代码只保留“观察和执行”这两件确定性的事情。

2.2 为什么“纯视觉”不够，还得配合 UI 描述信息

很多人做 AI 自动化的第一反应是“给模型截图就行”。但实际跑下来你会发现，纯截图有太多坑：坐标不精确，模型看到的图是经过缩放的，直接按像素坐标去点，误差会大到离谱；界面相似时容易误判，两个卡片长得差不多，模型根本分不清哪个是目标；动态列表的时候，截图上无法精确定位列表项的位置。

ARTEMIS 的做法是“视觉 + 结构”双通道输入。截图负责表达视觉语义，UI 描述信息负责把控件位置、可点击区域、文本标签这些结构化信息同步给模型。模型在推理时结合两种信息，输出的动作坐标就会准确得多。打个比方：截图是“看照片认人”，UI 描述是“拿着通讯录对号入座”，两者一结合，准确率才有保障。

2.3 动作类型的设计，藏着一个很低调但很关键的细节

ARTEMIS 定义的基础动作其实不多：点击、长按、输入文字、滑动、返回、等待。各家 Agent 框架的动作集基本都长这样，ARTEMIS 真正讲究的是每个动作参数带回退语义。

举个例子，“点击”动作不只要带上 x、y 坐标，还带上了目标元素在 UI 描述中的索引或标识。这样一来，模型如果发现点击之后页面没有任何变化，就能立刻知道自己“点空了”，然后在下一轮换个策略，而不是傻傻地再点一次同样的坐标。这个“动作级自省”机制特别重要，它决定了多步任务在真实手机上的成功率，也是 ARTEMIS 和许多学生项目式 automator 拉开差距的地方。

3. 本地部署实录：从拉代码到跑通一个真实任务

3.1 环境准备，最容易被忽略的三个细节

ARTEMIS 整体定位偏框架和研究验证，本地跑起来依赖链并不复杂。我的环境是这样配的：

• Python 3.10+，虚拟环境建议用venv而不是 conda，后面装依赖省心。
• Android SDK platform-tools，必须把adb加到系统 PATH。
• 一台 Android 真机或者模拟器，模拟器建议选 Pixel 镜像，默认开了调试。
• 一个可用的 VLM 服务地址和 Key，ARTEMIS 默认对接的是兼容 OpenAI 接口的模型服务，可以接云端服务，也可以接本机部署的视觉模型。

这里有一个特别容易踩的坑：模拟器分辨率。ARTEMIS 最终的点击坐标需要从截图坐标映射到真实屏幕坐标，如果你模拟器开了 240 DPI，而模型服务拿到的是缩放到 512px 宽的截图，映射系数一旦没配对，点击位置会整体偏移。我建议第一步就把模拟器固定成一个常用分辨率，比如 1080x2400，后续调试省很多事情。

3.2 拉代码、装依赖、写配置

git clone https://github.com/google/artemis.git cd artemis python -m venv .venv source .venv/bin/activate pip install -e .

装完依赖之后，需要创建一个配置文件。ARTEMIS 的配置读取方式很常规，我用的是 YAML 风格：

device: adb_host: localhost adb_port: 5037 serial: emulator-5554 model: provider: openai-compatible api_base: http://127.0.0.1:8000/v1 api_key: sk-your-key model_name: your-vlm-model max_tokens: 1024 temperature: 0.1 execution: max_steps: 30 retry_times: 3 screenshot_delay: 0.8

temperature我强烈建议设成 0.1 或者更低。自动化任务里要的是确定性，不是创造性，温度一高模型就会开始给自己加戏，输出一些莫名其妙的动作组合。

3.3 第一次试跑：让它帮我填一个登录表单

我准备了一个最简单的测试任务：打开一个测试 App，输入账号密码，点击登录。启动方式大致长这样：

python -m artemis.cli \ --config config.yaml \ --task "打开登录页，在账号框输入 test_user，密码框输入 123456，然后点击登录按钮"

ARTEMIS 的循环开始跑之后，日志会实时打印每一轮的动作和坐标。我这次跑了 7 轮完成，中间有一轮“点击账号输入框”之后没有弹出键盘，模型在下一轮选择了“轻触输入框的稍上方区域”来自救成功。

这个第一次跑通的体验很微妙：你会直观感受到，跟传统脚本的“按行执行”完全不一样，ARTEMIS 真的会在每一步执行完停下来重新看一眼屏幕、再决定下一步。它很像一个实习生，做事会回头确认，虽然慢一点，但很少犯同样的错。

4. 真正决定 ARTEMIS 能否落地的工程细节

4.1 坐标映射：模型输出 512 宽坐标，手机要按 1080 宽执行

这是所有视觉类移动端自动化项目都躲不开的问题。模型看到的截图经过缩放，输出的是模型图像坐标系里的点，但 ADB 注入点击事件需要的是原始屏幕坐标。

ARTEMIS 在代码里做的是线性映射：real_x = model_x * (screen_width / image_width)。乍看很简单，实际坑在截图的“相对坐标”：有些界面有系统状态栏、底部手势条，截图区域和可点击区域不是一回事。要处理的办法是，在采集 UI 描述时一并将安全区域 inset 带出来，做坐标修正时先裁剪掉非内容区域。

我实测下来，如果直接用全屏截图而不考虑状态栏，页面上半部分的按钮点击准确率会出现明显下降，尤其是那些贴近状态栏的元素。跑自动化之前，先把截图裁剪规则理清楚，这个时间花得最值。

4.2 系统弹窗和应用内动效，是打断循环的两大杀手

自动化过程里最怕的不是模型理解错，而是手机环境的稳定性被破坏。ARTEMIS 在执行过程中如果突然冒出系统权限弹窗、应用更新弹窗、甚至只是键盘弹起把布局顶上去，整条链路就会从“预期路径”变成“随机路径”。

我在跑表单任务时，键盘弹起把输入框挤到屏幕上方，点击验证码按钮时坐标偏移，直接点到了旁边区域。之后我在配置里把每一步之间的等待时间加长到 0.8 秒，并且在任务描述里增加了“如果出现系统弹窗，先关闭弹窗”的前置约束，成功率明显提升。

这里给个我自己的经验清单：

• 系统内置测试机不要乱装工具类 App，比如全局悬浮球、屏保、输入法增强，都会干扰界面稳定性。
• 关闭“动画缩放”，开发者选项里的三个动画缩放全设为关闭，能减少很多时序错乱。
• 允许 ARTEMIS 用“跳过引导页”这类预动作，避免首次启动进入欢迎流导致坐标全偏。

4.3 终止条件：无限循环比执行失败更可怕

Agent 类框架最常见的翻车方式就是“死循环”。任务没法完成时，模型会在几个动作之间反复横跳，看起来像是真的在尝试，实则一直在原地打转。ARTEMIS 本身有最大步数限制，但这只是兜底，不够。

我建议在任务描述里额外强调“如果发现动作重复三次以上，就停下来报告无法完成”，然后通过配置文件里的max_steps再兜一层。把终止条件看成产品的边界而不是异常，这对落地体验很重要——一次得体的失败，比无限重试更能赢得用户信任。

4.4 权限边界：ADB 能做的事，比你以为的多得多

ARTEMIS 的本质是 ADB 通道的设备控制，这意味它对手机的掌控能力非常强，能安装应用、授予权限、读取日志、模拟各类触摸事件。框架本身没有恶意，但一旦被滥用，风险非常高。

所以我在本地部署时坚持三条红线：

1. 只用专门的测试机或模拟器，不碰主力机。
2. ADB 端口只对localhost开发，不映射到局域网。
3. 不在生产环境开放 ARTEMIS 的接口，就算团队内部要用，也必须套一层任务白名单和审批流。

移动端 AI 自动化的价值建立在“被信任”的基础上，守住权限边界，这个方向才走得长远。

5. 基于 ARTEMIS 的落地场景：从测试到个人助手

5.1 移动端回归测试：先拿“冒烟用例”试水

ARTEMIS 最稳的落地场景就是回归测试里的冒烟用例，特点是任务链路短、页面相对固定、结果容易判断。以前冒烟测试要写大量脚本，现在只需要把验收动作写成自然语言就够了：

启动 App，进入首页，点击“我的”，确认用户头像可见。

这种任务对视觉模型来说非常简单，稳定性很高。它不能完全替代传统自动化测试，但能把测试团队从繁重的脚本维护里解放出来，去处理那些真正需要深度场景覆盖的用例。

5.2 个人手机助手：让 Agent 模型拥有“手”和“眼睛”

如果你在搭建个人的 AI Agent 类应用，ARTEMIS 可以直接作为移动端的执行终端。很多项目卡在“模型思考得很好，但没有手”，ARTEMIS 正好把“手”补齐了。

比如你给本地知识库助手下指令“帮我把今天新闻 App 的头条转发到便签”，模型可以在语义层拆解任务，然后在 ARTEMIS 的循环里一步步点击、跳转、复制粘贴。我用这个思路搭过一个原型，虽然每一步都比人工操作慢，但“无人值守地完成跨应用任务”这件事本身就是价值。

5.3 企业级移动端 RPA：效果好，但要有“人机协同”心态

企业场景里，移动端 RPA 的需求一直存在，比如供应链的验收流程、仓管系统的订单处理。ARTEMIS 在这些场景里表现非常亮眼，因为企业移动应用往往结构老旧，有些还是套壳 H5，传统脚本反而难做。

但企业环境有它自己的复杂度：多账号切换、网络差导致的超时、多因素认证、数据安全要求。我合作过的几个项目最终都放弃了“全自动无人值守”的幻想，改成“AI 负责常规操作，人负责异常审批”，这个混合模式反而最稳定，团队接受度也最高。

6. 关于选型和调优的个人经验总结

ARTEMIS 不是一个“装上就能全自动”的银弹，它更准确地说，是给移动端 AI 自动化补齐了一块关键拼图。我经历过跑几十步任务一次成功的高光时刻，也经历过模型在同一张弹窗图上来回转圈的尴尬场面。我的体会是：

在模型能力足够强的今天，限制自动化上限的往往不是“模型会不会想”，而是“工程能不能稳”。坐标映射对不对、UI 描述拿得全不全、终止条件有没有兜住、权限边界控制得紧不紧——这些不起眼的细节，决定了 ARTEMIS 在生产环境是工具还是玩具。

最后分享一个我自己的调试技巧：给模型的任务描述，不要把话说得太死，比如“点击登录按钮”就比“点击坐标为 (720, 1200) 的按钮”稳健得多。ARTEMIS 的价值本来就在于模型自己会看、会判断，你只需要把意图边界画清楚，剩下的交给循环就好。