企业官网建设流程全解析

做移动端测试的朋友，应该都体会过这种循环：写脚本、跑脚本、改脚本。几百行的 UI 自动化用例，产品改个按钮位置就全红；模拟器上点点点都没问题，一接真机就开始迷之卡顿；版本迭代一多，回归测试的重复劳动基本可以把人钉在工位上。Google 开源的 ARTEMIS，核心就是干这件事——用 AI Agent 去接管 Android 真机测试，让测试人员从维护脚本的泥潭里抽身出来。

这个项目解决的是“测试脚本扛不住变化”的痛点。传统自动化把操作步骤写死，UI 一改，步骤就失效了；ARTEMIS 的思路是让大模型直接理解测试目标，自己看屏幕、自己决定点哪里、自己判断结果对不对。对测试从业者、移动开发、以及正在了解 AI Agent 应用落地的人来说，它把“Agent 规划”和“真机设备控制”这两个原本割裂的技术栈连在一起，算是一个非常典型的实操范本。

下面我会从项目思路、架构拆解、实操流程、问题排查、经验心得几个方面展开聊，内容以常见实践为补充，希望能给你一个可以直接参考的落地路径。

1. ARTEMIS 到底在解决什么问题

1.1 传统自动化测试的尴尬

先聊一个很现实的场景。你现在要给一个购物 App 写一条测试用例：登录、搜索商品、加购、下单。用传统的 UI 自动化框架，你需要定位登录按钮的 id，输入框的 resource-id，搜索框的坐标，下单页的控件树节点。要是开发顺手改了布局，把 LinearLayout 换成了 Compose 实现，id 全变了，你的脚本注定要重写。

这种模式的问题在于：测试脚本本质上是在“跟 UI 结构的实现细节绑定”。你维护的不是业务逻辑，而是一堆控件的物理位置。移动端版本迭代又快，两周一个版本，每次改版都是一轮“找新控件、改定位符、修等待条件”的循环。如果你的项目里自动化用例超过几百条，维护成本是很恐怖的。

还有一个痛点：模拟器和真机的差异。模拟器里 CPU 架构、系统版本、屏幕尺寸相对可控，但真机有厂商深度定制的 ROM，有各种诡异的权限弹窗，有弱网、有通知栏干扰。同一套脚本，模拟器上跑得好好的，真机上可能第一步就被一个“允许获取设备信息”的弹窗卡住了。传统自动化框架处理这种不确定情况，只能靠“如果出现弹窗，点击允许”这种笨办法，弹窗一变就又失效了。

所以测试圈一直在找一条新路：能不能让测试工具自己理解“当前屏幕上发生了什么”，然后根据任务目标去做决策。这正好撞上了大模型的风口。

1.2 AI Agent 相比脚本的核心价值

ARTEMIS 的出发点，就是把“测试任务”抽象成一段自然语言描述，而不是一段代码。你告诉 Agent：“帮我把商品加入购物车并截图返回”，Agent 自己会拆解步骤：先找搜索入口、输入关键词、点击第一个商品、找到加购按钮、点击、截图。

这个“拆解步骤-执行-验证-调整”的过程，在 AI Agent 领域叫“任务规划（Planning）”和“工具调用（Tool Use）”。ARTEMIS 让 Agent 拥有的工具，就是 Android 真机上的各种操作能力：点击、滑动、输入文本、截图、返回按键、读取界面元素树。大模型负责思考，工具负责动手。

它的核心价值在于适应性。因为 Agent 不是靠固定坐标操作，而是靠“看”屏幕：截一张图，读一下界面结构，再决定往哪点。UI 改了，按钮位置变了，它重新看一眼就知道新按钮在哪。这打破了过去“脚本必须跟着 UI 结构走”的死结。

当然这里要说得直白点：AI Agent 不是魔法，它不可能 100% 替代人工测试，但它能把“重复的、确定性的、需要视觉理解的”那部分工作自动化掉。比如版本回归、多机型兼容性验证、冒烟测试，这几个场景非常适合。

1.3 为什么必须用真机

有的朋友可能会问：既然 Agent 能看屏幕，那用 Android 模拟器不行吗？行，但不够。ARTEMIS 强调真机测试，背后有几层原因。

第一，真机上才能暴露真实交互问题。模拟器的触摸事件、传感器数据、网络环境都是虚拟的，无法模拟真实的物理设备和网络环境下的表现。真机上的 GPU 渲染性能、系统通知、不同品牌的 ROM 行为，才是用户实际遇到的体验。你用模拟器测出一堆绿色通过用例，不代表用户在真机上不出问题。

第二，很多业务功能在模拟器里根本没法完整跑通。比如扫码、NFC、蓝牙、电话状态、应用间跳转。这些操作依赖真实硬件和系统服务，模拟器只能给你一个残缺版本。你让 Agent 测试一个“微信授权登录”流程，模拟器上可能第一步就卡住，因为它跳不出真实的授权环境。

第三，真机测试的最终目标，是一套用例跑在几十台不同品牌、不同系统版本的设备上，验证兼容性。ARTEMIS 的架构天然适合多设备管理：每台设备是一个独立执行环境，Agent 可以像人一样逐台操作，也可以并行调度。这是模拟器体系很难做到的。

2. 架构拆解：ARTEMIS 是怎么“接管”真机的

2.1 感知层：让 Agent 看到手机屏幕

AI Agent 要接管一台真机，第一步是解决“感知”问题。它得知道当前屏幕上是什么、有哪些可操作区域、这些区域代表什么功能。ARTEMIS 在感知层面主要拉了两个数据通道：屏幕截图和 UI 层级树。

屏幕截图好理解，通过 adb 命令执行 screencap 就能拿到一张 PNG 图片，交给多模态大模型进行视觉理解。这种方式对视觉类问题非常直观：按钮重叠、图标错位、颜色异常，模型一眼就能看出来。但只有截图还不够，因为截图像素再高，对文字内容、控件边界、可点击区域的判断还是不如结构数据准确。

UI 层级树是从 Android 的 Accessibility 服务或者 uiautomator dump 获取的 XML 文件，里面记录了当前页面上每个控件的位置、大小、文本、resource-id 等信息。你可以把它理解为“给手机屏幕做了一份带坐标的说明书”。Agent 结合截图和 XML 两份数据，既能理解页面的视觉样式，又能精确知道“这个按钮的点击中心点在哪”。

这里有个实践细节：拿到 XML 后，建议做一次裁剪和清洗。原始 dump 文件往往包含大量重复的、无意义的布局节点，直接塞给大模型会浪费 token 还会干扰判断。ARTEMIS 的做法是把 XML 简化成“控件列表”，只保留关键字段：text、resource-id、bounds、enabled、clickable。这样模型看到的信息密度更高，决策准确率也会明显提升。

2.2 决策层：LLM 如何规划操作路径

有了屏幕信息，下一步就是“下一步做什么”。这一层是 ARTEMIS 的灵魂，也是它跟过去“规则自动化”最大的分水岭。

ARTEMIS 的 Agent 核心是一个大语言模型，但跟你在网页端聊天不一样的是，它运行在一个“循环”里。大致流程是：

1. 接收任务目标，比如“测试登录功能”。
2. 获取当前页面截图和控件列表。
3. 模型根据目标、当前页面状态，输出一个行动决策（点击某个按钮、输入文字、滑动、返回等）。
4. 执行这个行动。
5. 重新获取页面状态，验证上一步是否生效。
6. 如果页面状态符合预期，继续下一步；如果不符合，模型会重新思考并尝试别的操作。

这个循环在 AI Agent 领域叫“ReAct 范式”：推理（Reasoning）和行动（Action）交替进行。大模型在这次循环里同时扮演“大脑”和“眼睛”，把不完整的信息补进去，做出最合理的下一步动作。

关键点是：模型不应该被允许自由地“随便点”。ARTEMIS 会给模型设定一套约束规则。比如一次只能输出一个动作，动作必须从预定义的工具集中选择，如果同一个动作连续执行多次都没变化，就要停止并转交给人工处理。这就像你给实习生下任务：你可以自己想办法，但不可以乱来，遇到卡住超过三次就要上报。

2.3 执行层：从“想”到“做”的关键一跳

Agent 想好了要点击某个坐标，怎么真正让手机“动”起来？这里靠的是 Android 生态里一套已经很成熟的自动化工具链：adb 和 Appium/uiautomator2。

ARTEMIS 在执行层把大模型输出的行动指令翻译成具体的 adb shell 命令，或者通过 uiautomator2 的 Python/RPC 接口下发操作。核心工具包括：

• input tap x y：模拟手指点击某个坐标点。
• input swipe x1 y1 x2 y2 duration：模拟滑动轨迹。
• input text "内容"：输入文本。
• adb shell am start：启动或唤醒应用。
• adb shell am force-stop：强制停止应用。
• adb shell wm size：获取屏幕分辨率，用于坐标换算。

一个很容易踩坑的地方是：大模型从 XML 里读到的 bounds 是“物理像素坐标”，但某些设备上还需要考虑屏幕密度和显示缩放。如果用 uiautomator2 定位控件，它内部会做坐标换算，问题不大；但如果让模型直接输出坐标并调 adb 执行，必须统一都换算成同一套坐标体系。建议在接入层做一次坐标归一化，而不是把这个问题抛给大模型。

执行层还要解决“操作可靠性”问题。比如输入文本时，如果输入框有前置焦点要求，必须先点击输入框，再等待键盘弹出，再输入。ARTEMIS 的做法是把这些常见的“前置条件”固化在工具定义里，大模型不需要知道 Android 输入框的焦点机制，它只要说“在输入框中输入用户名”，工具层自动处理点击焦点和输入动作。这样做的好处很明显：模型决策更稳定，工具执行更可靠，两端各做自己擅长的事。

2.4 验证层：怎么判断测试到底过没过

Agent 执行完一系列操作后，怎么判断测试是通过还是失败？这是 ARTEMIS 里容易被低估的一部分。

验证分两个层次。第一个层次是“过程验证”：步骤执行后，页面有没有发生预期变化。比如点击“搜索”后，界面应该出现搜索结果列表；点击“登录”后，应该跳转到主页或出现登录成功提示。ARTEMIS 在每一步执行后会重新截图和抓取控件列表，让模型对比前后差异，判断上一步操作是否真正生效。

第二个层次是“结果验证”：整个任务完成后，用一个明确的标准去判断测试是否通过。ARTEMIS 支持两种方式。一种是让大模型基于最终截图和业务逻辑做多维度判断，比如“登录后个人信息区域是否显示正确用户名”。另一种是写硬断言，用脚本检查某个关键控件是否存在、某个页面元素文本是否匹配。实际项目里两种方式都在用：关键路径用硬断言保底，视觉体验方面用大模型判断。

我个人强烈建议：不要把大模型判断当成唯一标准。模型有幻觉，有状态不稳定，它说“通过”不代表真的没问题。正确做法是把大模型判断作为“第一道筛选器”，把可疑用例标记出来，再交给人工复核。ARTEMIS 会把整个操作过程录屏、截图、记录操作日志，人工复核时基本不用复现一遍，看日志和截图就够了。

3. 从零开始跑一次 ARTEMIS 测试

3.1 环境准备与设备接入

先说环境。跑 ARTEMIS 需要准备的东西比较常规：一台能跑 Python 的开发机、一台 Android 真机（建议先拿一台容易调试的，比如 Pixel 或主流国产机）、开启开发者选项和 USB 调试模式、安装 adb 工具。如果要用 Android Studio 看资源文件或处理日志，也可以装上，但核心链路里严格来说不必须。

设备接入有个经常出问题的点：USB 调试授权弹窗。手机第一次连电脑时，屏幕上会弹出一个“允许USB调试吗”的对话框，必须手动点允许。命令行用 adb devices 看到设备状态是 device 才说明授权成功，如果显示 unauthorized 就是还没允许。这个弹窗很容易被自动化流程忽略，我的习惯是接入后先跑一遍 adb devices，确认状态再往下走。

第二步是准备环境依赖。ARTEMIS 通常用 Python 写，核心库包括 uiautomator2、Pillow、openai 或其他大模型 SDK。安装完成后，在 Python 里执行 device = u2.connect() 连接设备。如果设备列表里有多台，需要指定序列号，序列号用 adb devices 查看。

接着要确认两个信息：屏幕分辨率和 Android 版本。分辨率影响坐标换算，Android 版本影响部分 adb 命令的兼容性。把它们记下来，后面配置 Agent 参数时要用到。

3.2 定义测试任务

ARTEMIS 的测试任务，本质上就是一段“给 Agent 看的需求说明书”。任务描述写得越好，Agent 执行越顺。我在实操中总结了一个任务描述模板，大概是这样的结构：

• 任务目标：一句话说清楚要做什么，比如“测试从首页搜索商品到加购的完整流程”。
• 关键步骤提示：告诉 Agent 大概要经过哪些节点，比如“先搜索，再点击商品详情，再选择规格，再加购”。这一步不是强制流程，而是给 Agent 的导航，防止它跑偏。
• 验收标准：明确什么状态算成功，比如“加购按钮出现‘已加入购物车’提示，购物车角标数字增加”。
• 约束条件：比如“不要修改收货地址”“不要生成真实订单”“如果遇到需要登录的情况，使用测试账号登录”。

任务定义完，转换成 Agent 可以理解的指令格式，通常是 JSON 结构，包含 role、content、priority 等字段。ARTEMIS 会把任务描述和系统预设的工具说明一起喂给大模型，让它在给定的行动空间里做决策。

值得注意的是：首次测试千万不要上来就跑复杂流程。建议从“打开 App-点击某个按钮-截图返回”这种一分钟内能完成的小任务起步，确认整条链路通了，再逐步增加复杂度。这样排查问题方便，也能快速验证 API 调用、设备控制、模型输出这三个环节是否正常。

3.3 关键参数与配置

跑通一次测试，需要关注几个关键参数。第一个是超时时间。Agent 每一步操作后都会等待页面刷新，但如果页面卡死或者网络慢，模型会一直等不到新状态。ARTEMIS 里一般会设置单步操作超时（比如 10 秒）和任务总超时（比如 5 分钟）。超时后进入兜底逻辑——重新截图，如果页面没变化，就标记为“疑似卡死”并停止。

第二个是最大尝试次数。模型不是每次都运气好，点错按钮、输入错内容都可能发生。ARTEMIS 允许每个步骤最多重试 N 次，超过次数就报错退回人工。这个 N 我建议设成 3，太少模型没有纠错机会，太多会浪费时间。

第三个是模型温度参数。温度控制输出的随机性，测试场景需要可复现、稳定，所以温度要设低一点，比如 0 到 0.2。如果温度太高，同一个页面模型可能这次点这个按钮、下次点那个按钮，测试结果就不稳定了。

第四个是截图压缩和控件列表过滤的最大长度。真机截图分辨率往往很高，直接发给多模态模型不仅慢，还可能超出模型的输入 token 限制。实操中会把截图先缩放到宽度 720 像素左右再提交，控件列表只保留 text 非空的节点。这样既保证模型能看懂，又能显著降低接口延迟。

3.4 结果产物与人工复核

一次 ARTEMIS 测试跑完后，应该产出几样东西：操作录屏、关键步骤截图、完整操作日志、每个步骤的决策说明、测试结论。

实际操作中，操作日志的价值最大，也是最容易做好的。ARTEMIS 一般会把每次“模型输出动作-工具执行结果-页面状态变化”都记录成结构化的 JSON 日志。这个日志不仅能用来排查问题，还能用于后续调优：哪一步模型反复犹豫？哪个页面经常导致 Agent 卡住？看日志比看录屏效率高得多。

人工复核环节，我推荐抓三个重点。第一个看“Agent 是否做了预期之外的操作”。模型毕竟是模型，它可能为了达到目的去点了一些不该点的东西，比如退出登录、清缓存。这些操作在日志里必须暴露出来。第二个看“步骤时序是否合理”，有没有出现点击没生效、重复滑动等异常。第三个看最终的硬断言结果，比如关键控件是否出现，数据是否匹配。

如果任务失败，先把失败原因分类：是设备连接问题、控件识别问题、还是模型决策问题。分类之后再针对性修复，而不是盲目调 prompt。这部分直接决定 ARTEMIS 能不能从“demo 能跑”走向“真正可用”。

4. 常见问题与排查实录

4.1 设备连不上与授权异常

真机测试第一步就是设备连接，这块的问题出现频率超高。最常见的三种情况：adb devices 列表为空、设备状态显示 unauthorized、设备状态显示 offline。

列表为空通常有三种原因。数据线只支持充电不支持数据传输，换一根数据线是最高效的解决方式。没装设备厂商的 USB 驱动，Windows 上尤其常见，去设备管理器看有没有带感叹号的设备。手机的 USB 模式选成了“仅充电”，需要改成“文件传输（MTP）”模式。

unauthorized 状态表示你没点手机上的授权弹窗，或者弹窗已经被误设置为“一律拒绝”。去手机开发者选项里找到“撤销 USB 调试授权”，全部撤销后再重新插线，会重新弹出授权框。offline 状态一般是 adb 服务问题，先执行 adb kill-server 再执行 adb start-server，然后重插数据线。

还有一个容易忽略的点：手机锁屏会导致执行一些可交互操作时失败。建议测试期间把屏幕常亮设置为“超过 30 分钟”，或者用 adb shell svc power stayon true 保持屏幕常亮，防止黑屏导致截图全是黑色。

4.2 不规则 URI 与系统弹窗处理

实际测试中经常会碰到系统弹窗和应用内弹窗，比如权限请求、更新提示、手机管家拦截。ARTEMIS 的 Agent 虽然能看到弹窗，但能不能正确处理是另一回事。

以“跳转到文件管理选择文件”为例，Android 系统的文件选择器在不同厂商 ROM 上长得完全不一样。有的弹窗会给出类似 content://com.tencent.wework.fileprovider/external_path/android/data/com.xxx 这样的非标准 URI，普通文件访问根本拿不到路径。这种情况 Agent 就算看到了也不知道怎么选到目标文件。

我的做法分两步。第一步是在 Agent 的工具集中预置“通用弹窗处理”能力：识别常见的权限弹窗文案，比如“允许”“拒绝”“始终允许”，自动做匹配并点击预期按钮。第二步是遇到涉及系统文件选择的场景，尽量不用真实文件管理器，而是在测试环境中预置一个固定的 UI 元素可点击，或者用更深度的工具直接模拟文件选择结果。如果实在绕不过，把这一步也交给 Agent 去读，提示词里明确告诉它“当前处于系统文件选择页，只允许点击带有目标文件名的项”。

核心教训是：不要把问题抛给 Agent 去自由发挥。它不认识各个 ROM 的文件选择器差异。提前在工具层做兼容处理，比堆 prompt 有效得多。

4.3 页面加载慢与等待策略

AI Agent 测试经常遇到“页面还在加载，但 Agent 已经认为操作成功了”的假象。点击一个按钮后，页面上先出现加载中的菊花，随后才显示内容。如果模型在一个瞬间截了图，看到的是中间态，可能做出错误判断。

ARETMIS 处理这个问题靠的是一套“状态稳定检测”。每执行完一个操作，不要立刻截图，而是让设备空闲几百毫秒，连续截两张图对比。如果两张图一致，说明页面结构稳定了，再交给模型分析。如果两张图不一致，就继续等。这个策略能过滤掉大部分加载动画、过渡动效带来的误判。

还有一种常见情况是网络慢导致页面部分加载：顶部内容出来了，底部还在转圈。模型可能只看到了页面的一部分，就误以为流程可用。我的建议是在验收标准里写清楚“需要检查的完整条件”，比如“列表页显示至少 3 个商品卡片且没有加载提示”，让模型不能拿半成品页面作为通过依据。

如果页面加载经常超过 10 秒，就要从网络环境和设备性能上找原因了，不要单纯拉高超时时间。超时设太高，失败用例会拖很久才报错，整个测试资源都耗在等待上。

4.4 Agent 误操作与模型幻觉约束

最后聊一个 AI Agent 项目的“原生问题”：模型幻觉。模型可能“觉得”自己点过某个按钮，但看日志发现它根本没有执行；也可能执行了但点错了坐标，它还坚称自己点了正确的地方。

约束手段有几层。第一层是“行动前确认”：模型的输出必须是一个结构化的工具调用 JSON，包含 tool 和 arguments 字段。系统代码只认结构化的工具调用，不接受纯文本回复。这样从格式上就把“模型随便说话”的路径堵住了。第二层是“权限最小化”：Agent 的工具集不要给全，只给当前任务可能用到的工具。比如这个测试任务只需要点击、滑动、截图，就不要让它能打开系统设置。第三层是“进度校验”：每完成一个关键里程碑，比如成功进入购物车页面，就用一次独立的截图比对做确认，如果页面状态与预期不符，立即暂停并说明原因。

实操中还有一个很有用的技巧：在系统提示词里加一句“如果你不确定当前页面状态，请重新截图并检查控件列表后再行动。禁止猜测点击位置。”这看起来简单，实际能明显减少模型在奇怪位置乱点的概率，尤其是很多模型在首次尝试失败后容易开始“猜坐标”，越猜越偏，最后把 App 点到了后台。

5. 我的使用心得与后续扩展

5.1 什么场景真正适合 AI Agent 测试

用了一段时间之后，我的感受是：AI Agent 测试不是银弹，它适合的场景非常清晰。第一类是冒烟测试和核心流程回归，这些用例数量少但业务价值高，UI 改动频繁导致脚本维护成本太高，用 Agent 可以省掉大量维护时间。第二类是弱视觉校验，比如主题换成深色模式后按钮是否还清晰、多语言切换后是否出现文字截断，这类问题用传统断言写起来麻烦，但让大模型看图判断很自然。第三类是弹窗和异常状态测试，Agent 可以灵活响应意外弹窗，而传统脚本遇到弹窗经常直接挂掉。

不适合的场景也有：大型数据精确校验、涉及大量序列化输入的任务、需要毫秒级 UI 响应的性能测试。这些还是用老办法更靠谱。ARTEMIS 的价值在于补位，不是取代。

5.2 如何在这个架构上做二次开发

开源项目的意义在于你可以把它改成自己的工具。ARTEMIS 架构上留了几个很好的扩展点。

第一个扩展点是接入自己的大模型中间层。你可以把决策层替换成私有化部署的模型，也可以接入市面上主流的商业大模型 API。关键是要把工具定义部分保持通用，这样换模型不影响设备控制链路。

第二个扩展点是自定义工具。你可以往工具集里加“读取已安装应用列表”“动态修改系统权限”“注入间接定位”这类定制操作。加工具时记得给模型写清楚工具的适用场景和参数含义，模型才能正确调用。

第三个扩展点是多设备调度。ARTEMIS 的架构可以扩展成一个简单的设备池：一台控制机管理多台真机，每台设备跑一个独立的 Agent 实例，任务队列统一分发，执行结果统一回收。跑兼容性测试的时候，这个能力非常实用。

5.3 给入坑者的几条实在建议

最后分享几条我做过之后觉得最有价值的经验。

第一，从最小的闭环开始。第一周不要想着做复杂业务流，只做“打开 App-截图-返回”这一件事，把设备接入、模型调用、结果回收全部跑通。第二周再加一个点击操作。第三周再加输入。这样每个阶段的需求都很清晰，出了问题也容易定位。

第二，日志是绕不开的投入。整个 Agent 执行过程中间产生的决策数据和观察结果，一定要保存下来。它们不仅是排查问题的依据，也是以后做提示词调优和模型选型的数据基础。没有数据，你连“模型这周比上周差”都判断不出来。

第三，始终保留一个人工确认环节。Agent 可以跑，但最终发布之前的确认权，暂时还是保留给人类比较稳妥。等你在真实项目里积累足够多的通过率和失败率数据之后，再决定哪些步骤可以完全自动化。

我在实际使用中的体会是，AI Agent 测试目前处于一个很微妙的状态：它已经能帮你扛下很多过去要加班去干的回归验证，但你仍然需要把它当成一个需要调教的工具，而不是一个可以直接信任的测试员。上手之前，尽量想清楚你要解决的具体问题是什么，不要为了 AI 而 AI。如果你的场景恰好是“UI 频繁变化、真机覆盖多、回归压力大”，那么 ARTEMIS 这套思路，很可能就是现阶段最值得投入的方向。