企业官网建设流程全解析

1. 移动端自动化测试的现状与ARTEMIS的切入点

移动端自动化测试这件事，做过的人都懂，它跟Web端自动化完全是两个世界的玩法。Web端你有一套相对稳定的DOM结构可以依赖，元素定位、状态判断、断言逻辑都有一套成熟的体系。但到了移动端，尤其是Android生态，碎片化程度高得离谱——不同厂商的ROM、不同的分辨率、不同的系统版本、不同的输入法行为，甚至同一个应用在不同设备上的渲染结果都可能存在细微差异。这就导致一个很现实的问题：你写好的测试脚本，在A设备上跑得好好的，换到B设备上可能就各种超时、找不到元素、点击偏移。

传统方案是怎么应对的？主流做法无非两种：一种是基于UI控件树的定位方式，比如通过无障碍节点或者控件ID来查找元素；另一种是基于图像识别的方案，截屏后在画面上做模板匹配或者特征点匹配。这两种方案各有各的痛点。控件树方案依赖应用的可访问性支持，很多应用尤其是游戏或者自绘UI的应用，控件树信息非常稀疏甚至完全不可用。图像识别方案则对分辨率、主题、动效、弹窗极其敏感，维护成本随着用例数量增长呈指数级上升。

ARTEMIS这个项目要解决的核心问题，就是在移动端自动化测试中引入大语言模型的能力，让测试脚本具备一定的“理解”和“自适应”能力，而不是死板地依赖固定的定位器或者像素坐标。它的双模式架构，本质上是在回答一个问题：当LLM作为测试执行的核心决策者时，如何平衡执行效率和决策准确性？这个问题的答案，直接决定了这套方案能不能在真实的生产环境中跑起来，而不是停留在Demo阶段。

我接触过不少团队在尝试LLM+自动化的组合，大多数都卡在两个地方：一是LLM调用延迟太高，一个简单的点击操作要等好几秒；二是LLM的输出不稳定，同样的界面描述，两次调用可能给出不同的操作决策。ARTEMIS的双模式架构，恰恰是在这两个痛点上做了针对性的设计。接下来我会从架构设计、模式切换逻辑、核心实现细节、实操踩坑经验几个维度，把这套方案拆开来讲清楚。

2. 双模式架构的整体设计与选型逻辑

2.1 为什么需要两种模式

先说说ARTEMIS为什么不是单一模式。如果只用LLM来做所有决策，理论上最灵活，但实际上根本跑不动。我做过一个粗略的测算：在一个中等复杂度的移动应用上，完成一次完整的业务流程测试（比如登录→搜索→加购→下单→支付），大概需要执行30到50个操作步骤。如果每个步骤都调用一次LLM来做界面理解和决策，按照当前主流模型的响应速度，单次调用平均2到4秒，光LLM调用就要花掉60到200秒。再加上截图、图像预处理、结果解析的时间，一个用例跑下来可能要三五分钟。这还没算上LLM输出不稳定导致的重复尝试。

反过来，如果完全不用LLM，那就退回到了传统的控件树或者图像匹配方案，失去了引入LLM的意义。所以ARTEMIS的设计思路是：把操作分成两类，一类是“确定性操作”，一类是“不确定性操作”。确定性操作指的是那些目标明确、定位方式稳定的步骤，比如“点击屏幕底部导航栏的首页按钮”“在搜索框中输入关键词”“滑动列表直到出现某个文本”。这些操作完全可以用传统方式高效完成，不需要LLM介入。不确定性操作指的是那些需要理解界面语义、处理动态变化、或者应对异常情况的步骤，比如“判断当前页面是否加载完成”“识别弹窗类型并决定是否关闭”“在控件树信息缺失的情况下找到目标元素”。这些才是LLM真正能发挥价值的地方。

基于这个分类，ARTEMIS设计了两种模式：快速模式和智能模式。快速模式走传统自动化路径，执行速度快、资源消耗低，适合处理确定性操作。智能模式走LLM决策路径，灵活性强、适应面广，适合处理不确定性操作。两种模式共享同一套设备控制层和结果校验层，区别只在于“决策引擎”不同。

2.2 模式切换的触发条件

模式切换不是随机的，ARTEMIS定义了一套触发规则。我把它归纳为三类触发条件：

第一类是定位失败触发。当快速模式尝试用控件树定位元素失败，或者图像匹配置信度低于阈值时，自动升级到智能模式。这个逻辑很直观：传统方式搞不定了，让LLM来试试。

第二类是语义判断触发。有些步骤本身就需要语义理解，比如“确认当前页面显示的是商品详情页而非列表页”。这种判断用传统方式很难做，因为页面结构可能千变万化，但用LLM来看截图或者控件树摘要，就能给出相对可靠的判断。这类步骤在用例编写时就会标记为“需要智能模式”。

第三类是异常处理触发。当测试执行过程中出现预期外的弹窗、广告、权限请求、网络异常提示时，快速模式的脚本通常没有预设处理逻辑，这时候切换到智能模式，让LLM根据当前界面内容决定如何处理。这个触发机制在实际跑用例时特别有用，因为移动端应用的弹窗行为实在太不可控了。

注意：模式切换的触发条件需要根据具体应用的稳定程度来调整。如果一个应用的UI非常稳定，控件树信息完整，那么智能模式的触发频率可以调低，以提升整体执行速度。反之，如果应用UI变动频繁，或者大量使用自绘控件，那么智能模式的触发频率就需要调高。

2.3 双模式架构的分层设计

ARTEMIS的整体架构分为四层，我从下往上依次说明：

设备控制层是最底层，负责与移动设备进行通信。这一层封装了ADB命令、截图获取、触摸事件注入、文本输入等基础能力。不管是快速模式还是智能模式，最终的操作执行都要落到这一层。这一层的设计要点是稳定性和响应速度，因为它是所有操作的基础通道。

感知层负责获取当前界面的状态信息。在快速模式下，感知层主要提取控件树信息，包括节点的类名、资源ID、文本内容、坐标范围、可点击属性等。在智能模式下，感知层除了控件树信息，还会获取屏幕截图，并对截图进行必要的预处理（比如缩放、压缩、格式转换），以便传给LLM做视觉理解。感知层的设计难点在于信息取舍：控件树信息太详细会消耗大量Token，太简略又可能导致LLM判断失误。ARTEMIS的做法是提取一个“精简控件树”，只保留可见的、可交互的、有文本内容的节点，并且对节点属性做裁剪，只保留对决策有用的字段。

决策层是双模式架构的核心。快速模式的决策层是一个基于规则的执行引擎，它按照预设的步骤序列，依次执行定位、操作、校验。智能模式的决策层是一个LLM调用模块，它把感知层获取的界面信息、当前测试目标、历史操作记录组装成Prompt，发送给LLM，解析LLM返回的操作指令，然后交给设备控制层执行。决策层还需要处理两种模式之间的切换逻辑，以及切换时的上下文传递。

编排层是最上层，负责测试用例的解析、步骤调度、结果记录、报告生成。编排层不关心具体用哪种模式执行，它只负责按照用例定义驱动整个测试流程。这种分层设计的好处是，模式切换对上层透明，用例编写者不需要关心底层用的是哪种决策方式，只需要定义好测试步骤和预期结果即可。

3. 快速模式的实现细节与优化要点

3.1 控件树定位的增强策略

快速模式的核心是控件树定位，但原生控件树定位有几个常见的坑：一是元素属性不稳定，比如某些应用每次启动时生成的资源ID会变化；二是元素层级过深，导致XPath表达式冗长且脆弱；三是存在多个匹配元素，无法确定应该操作哪一个。

ARTEMIS在原生定位基础上做了几层增强。第一层是多属性联合定位，不依赖单一属性，而是组合使用文本内容、类名、坐标范围、兄弟节点关系等多个维度来定位元素。比如一个按钮，如果它的资源ID不稳定，但它的文本内容是固定的，且它位于某个特定容器的右下角，那么就可以用“文本内容+相对位置”来定位。

第二层是定位器优先级排序。对于同一个目标元素，ARTEMIS会生成多个候选定位器，并按照稳定性排序。资源ID最稳定，优先级最高；其次是文本内容；再次是相对位置；最后是绝对坐标。执行时从高优先级开始尝试，失败则降级到下一个。这个策略在实际使用中效果很明显，大部分元素都能在前两个优先级内定位成功。

第三层是定位结果缓存。对于在多个用例中重复出现的元素（比如底部导航栏的各个Tab），ARTEMIS会缓存成功的定位器，后续用例直接复用，减少重复查找的开销。缓存会设置过期时间，并且在连续失败时自动失效，避免因为UI改版导致缓存污染。

3.2 图像匹配的加速技巧

快速模式中也会用到图像匹配，主要用于处理那些控件树信息缺失的场景。但图像匹配的计算量不小，尤其是在高分辨率屏幕上做全屏模板匹配，单次耗时可能超过一秒。ARTEMIS用了几个技巧来加速：

第一个技巧是区域限定。不总是做全屏匹配，而是根据业务逻辑限定搜索区域。比如要点击“确认”按钮，通常它出现在屏幕底部或者弹窗的右下角，那么就可以只在屏幕下半部分做匹配。区域限定可以把搜索空间缩小到原来的四分之一甚至更小，匹配速度提升非常明显。

第二个技巧是多尺度模板。移动端设备分辨率差异大，同一个按钮在不同设备上的像素尺寸可能不同。ARTEMIS会预先对模板图片做多尺度缩放，生成一组不同尺寸的模板，匹配时并行使用这些模板，取最高置信度的结果。这样就不需要针对每种分辨率单独准备模板图片。

第三个技巧是特征点匹配兜底。当模板匹配置信度低于阈值时，切换到特征点匹配（比如ORB或者SIFT）。特征点匹配对缩放、旋转、亮度变化更鲁棒，但计算量更大。所以ARTEMIS把它作为兜底方案，只在模板匹配失败时启用。

3.3 快速模式的执行流程

快速模式执行一个测试步骤的完整流程是这样的：

1. 解析步骤定义，提取目标元素描述和操作类型（点击、输入、滑动等）。
2. 从定位器缓存中查找是否有可用的定位器，如果有则直接使用。
3. 如果没有缓存，则生成候选定位器列表，按优先级排序。
4. 依次尝试每个定位器，直到成功定位到元素。
5. 如果所有定位器都失败，尝试图像匹配。
6. 如果图像匹配也失败，触发模式切换，升级到智能模式。
7. 定位成功后，执行对应的操作。
8. 操作完成后，进行结果校验（比如检查页面是否跳转、元素是否存在）。
9. 如果校验通过，记录成功并继续下一步；如果校验失败，根据失败类型决定是重试、切换模式还是标记用例失败。

这个流程看起来步骤不少，但实际执行时大部分步骤都能在毫秒级完成，因为定位器缓存和优先级排序大大减少了查找时间。我实测下来，一个稳定的点击操作，从开始定位到操作完成，平均耗时在200到500毫秒之间，完全能满足大部分测试场景的效率要求。

实操心得：快速模式的定位器缓存一定要设置合理的失效策略。我遇到过一种情况，应用更新后某个按钮的资源ID变了，但缓存里还是旧ID，导致连续多个用例失败。后来加了“连续失败三次自动清空缓存”的机制，问题就解决了。另外，缓存最好按应用版本号隔离，应用更新后自动失效旧缓存。

4. 智能模式的LLM集成与决策逻辑

4.1 Prompt工程的核心设计

智能模式的效果好坏，很大程度上取决于Prompt的设计。ARTEMIS的Prompt结构包含四个部分：

角色定义部分告诉LLM它扮演的是什么角色，比如“你是一个移动端自动化测试执行引擎，负责根据当前界面状态决定下一步操作”。角色定义要简洁明确，不需要长篇大论，但必须让LLM理解它的任务边界。

界面描述部分是把感知层获取的信息转换成LLM能理解的格式。这里有个关键取舍：是传截图还是传控件树文本？ARTEMIS的做法是两者都传，但根据场景调整侧重。对于视觉信息重要的场景（比如判断页面布局、识别图标含义），以截图为主；对于文本信息重要的场景（比如读取列表内容、判断按钮文字），以控件树文本为主。截图会做压缩处理，通常缩放到宽度720像素左右，既能保留足够的视觉信息，又能控制Token消耗。

任务描述部分是当前测试步骤的目标，比如“在当前页面找到搜索入口并点击”。任务描述要具体但不啰嗦，避免给LLM太多无关信息。

输出格式约束部分是最关键的。LLM的输出必须是结构化的，否则解析起来非常麻烦。ARTEMIS定义了一套JSON格式的输出规范，包含操作类型、目标元素描述、操作参数、置信度等字段。Prompt中会明确要求LLM按照这个格式输出，并且给出示例。实测下来，只要格式约束写得清楚，主流LLM都能稳定输出合规的JSON。

4.2 多模态输入的取舍策略

智能模式支持多模态输入，但并不是每次调用都传截图。ARTEMIS根据步骤类型来决定输入模态：

这个取舍策略的核心逻辑是：能用文本解决的就不用图像，必须用图像的才用图像。因为图像输入的Token消耗远高于文本，而且图像理解的计算延迟也更高。我做过对比测试，纯文本输入的LLM调用平均耗时1.5秒，带图像输入的调用平均耗时3.2秒，差距非常明显。

4.3 决策结果的解析与校验

LLM返回的JSON结果需要经过严格的解析和校验才能执行。ARTEMIS的解析流程包括：

第一步是格式校验。检查返回内容是否是合法JSON，字段是否完整，字段类型是否正确。如果格式不合法，会尝试从返回文本中提取JSON片段（因为有些LLM会在JSON前后加一些解释性文字）。

第二步是语义校验。检查操作类型是否在支持的操作列表中，目标元素描述是否为空，坐标是否在屏幕范围内。这一步能过滤掉大部分明显不合理的输出。

第三步是置信度过滤。LLM在输出中会给出一个置信度分数，ARTEMIS设置了一个阈值（默认0.7），低于阈值的决策会被拒绝，转而触发重试或者降级处理。

第四步是执行前预检。在实际执行操作之前，ARTEMIS会做一次快速预检，比如检查目标坐标位置是否确实存在可交互元素，检查输入文本是否包含非法字符。这一步能避免一些低级错误。

如果解析或校验失败，ARTEMIS会进行有限次数的重试。重试时会调整Prompt，比如增加更明确的格式要求，或者补充更多上下文信息。如果重试仍然失败，则标记该步骤为“智能模式执行失败”，并根据用例配置决定是跳过还是终止。

4.4 上下文管理与Token控制

智能模式的一个隐性成本是Token消耗。每次LLM调用都需要传入界面描述、任务描述、历史记录等信息，如果不加控制，Token数量会迅速膨胀。ARTEMIS用了几个策略来控制Token：

历史记录截断：只保留最近N步的操作记录（默认5步），更早的记录做摘要处理。摘要只保留关键信息，比如“已点击搜索按钮”“已输入关键词”，不保留完整的界面描述。

界面描述精简：控件树信息只保留可见节点，节点属性只保留类名、文本、坐标、可交互标志四个字段。截图做有损压缩，质量参数设为60%到70%，在视觉信息和文件大小之间取平衡。

Prompt模板复用：角色定义和输出格式约束部分是固定的，可以缓存复用，不需要每次重新生成。只有界面描述和任务描述部分是动态的。

按需调用：不是每个步骤都需要LLM介入，只有触发条件满足时才调用。这个前面已经说过，是控制成本的最关键策略。

我粗略算过一笔账：一个包含50个步骤的测试用例，如果全部走智能模式，大概需要调用LLM 50次，Token消耗在10万到15万之间。如果采用双模式架构，只有大约10到15个步骤需要智能模式，Token消耗降到2万到3万，成本降低了70%以上，而测试覆盖率基本不受影响。

5. 双模式协同的实操流程与配置方法

5.1 环境准备与依赖安装

在开始配置ARTEMIS之前，需要准备好基础环境。我按照实际搭建过程来梳理：

设备端准备：一台Android设备或者模拟器，开启开发者选项和USB调试。建议使用Android 8.0以上版本，因为部分控件树API在低版本上行为不一致。设备分辨率建议在1080x1920以上，过低的分辨率会影响图像匹配的准确性。

主机端准备：Python 3.9以上版本，安装ADB工具并确保设备能正常连接。ADB的版本建议用较新的，老版本在某些设备上会有兼容性问题。可以通过adb devices命令确认设备连接状态。

Python依赖安装：ARTEMIS的核心依赖包括UI自动化库、图像处理库、HTTP客户端库等。安装命令如下：

pip install uiautomator2 opencv-python pillow requests numpy

如果要用到更高级的图像匹配功能，还可以安装scikit-image：

pip install scikit-image

LLM服务配置：智能模式需要调用LLM服务，需要配置API地址和密钥。ARTEMIS支持多种LLM后端，配置方式是在配置文件中指定服务类型和认证信息。建议将密钥放在环境变量中，不要硬编码在代码里。

5.2 用例定义与模式标记

ARTEMIS的测试用例用YAML格式定义，每个步骤可以标记执行模式。下面是一个示例：

test_case: 商品搜索流程 steps: - action: launch_app package: com.example.shop mode: fast - action: click target: 搜索框 locator: - type: resource_id value: com.example.shop:id/search_box - type: text value: 搜索 mode: fast - action: input target: 搜索框 text: 无线耳机 mode: fast - action: click target: 搜索按钮 locator: - type: text value: 搜索 mode: fast - action: verify target: 搜索结果页面 description: 确认当前页面显示的是搜索结果列表，且包含至少一个商品条目 mode: smart - action: click target: 第一个商品 mode: smart fallback: fast

这个用例中，前四步都是确定性操作，标记为fast模式。第五步需要判断页面类型，标记为smart模式。第六步点击第一个商品，这个操作在控件树中可能没有稳定的定位器（因为商品列表是动态渲染的），所以也标记为smart模式，但设置了fallback: fast，意思是如果智能模式失败，尝试用快速模式的图像匹配兜底。

5.3 模式切换的配置参数

ARTEMIS提供了一组配置参数来控制模式切换行为，这些参数可以在全局配置文件中设置，也可以在每个用例中覆盖：

这些参数的调整需要根据实际应用的特点来定。比如一个UI非常稳定的应用，可以把smart_trigger_on_failure设为false，完全依赖快速模式，只在明确标记为smart的步骤才调用LLM。反之，一个UI变动频繁的应用，可以把smart_trigger_on_failure设为true，并且降低smart_confidence_threshold，让更多步骤有机会走智能模式。

5.4 执行监控与日志记录

ARTEMIS在执行过程中会记录详细的日志，包括每一步使用的模式、定位耗时、操作耗时、LLM调用耗时、Token消耗、决策结果等。这些日志对于后续优化非常重要。

我通常会把日志分成三个级别：INFO级别记录每一步的执行摘要，包括步骤序号、模式、结果、耗时；DEBUG级别记录详细的定位过程、LLM输入输出、图像匹配得分等；ERROR级别只记录失败步骤和异常信息。

在实际使用中，我建议默认开启INFO级别，在排查问题时临时开启DEBUG级别。DEBUG级别的日志量非常大，一个50步的用例可能产生几万行日志，长期开启会影响性能。

日志中有一个关键指标需要特别关注：智能模式触发率。这个指标反映了快速模式的稳定性。如果触发率持续偏高（比如超过30%），说明快速模式的定位器需要优化，或者应用的UI变动太频繁，需要考虑调整测试策略。如果触发率过低（比如低于5%），可能说明智能模式的触发条件设置得太保守，有些本该由LLM处理的场景被快速模式勉强处理了，虽然当时没报错，但可能存在隐患。

6. 常见问题排查与避坑经验实录

6.1 快速模式定位失败的典型原因

快速模式定位失败是最常见的问题，我整理了几种典型情况和对应的排查思路：

情况一：资源ID变化。有些应用在每次启动时会重新生成资源ID，导致基于资源ID的定位器完全失效。排查方法是连续启动应用多次，对比同一元素的资源ID是否一致。如果确实变化，需要改用文本内容或者相对位置定位。

情况二：元素不可见但存在于控件树中。有些元素虽然在控件树中存在，但实际被遮挡或者透明度为0，点击操作会失败。排查方法是检查元素的visible属性和bounds坐标，确认元素确实在屏幕可见区域内。ARTEMIS在定位成功后会做一次可见性检查，如果元素不可见，会尝试滚动屏幕或者等待元素出现。

情况三：WebView内元素定位不到。如果应用使用了WebView，WebView内部的元素在原生控件树中可能只显示为一个整体节点，无法定位到内部的具体元素。这种情况下需要开启WebView调试，或者切换到智能模式，让LLM通过截图来定位。

情况四：动态加载内容。列表类页面通常采用懒加载，初始时只渲染可见区域的元素，滚动后才加载更多。如果定位器查找的元素在初始视口之外，会定位失败。ARTEMIS的处理方式是先尝试滚动查找，如果滚动到底部仍未找到，则触发模式切换。

6.2 智能模式决策异常的排查方法

智能模式的问题通常更隐蔽，因为LLM的输出看起来可能“有道理”，但实际上不符合测试预期。我遇到过几种典型情况：

情况一：LLM理解偏差。比如任务描述是“点击搜索按钮”，但界面上有两个搜索相关的按钮（一个是搜索框旁边的放大镜图标，一个是底部的搜索Tab），LLM可能选错了目标。排查方法是检查Prompt中的任务描述是否足够明确，必要时增加目标元素的特征描述，比如“点击搜索框右侧的放大镜图标”。

情况二：截图信息不足。如果截图压缩得太厉害，LLM可能看不清界面细节，导致决策错误。排查方法是临时提高截图质量参数，对比决策结果是否改善。如果确实是截图质量问题，需要调整压缩参数，在Token消耗和决策准确性之间找平衡。

情况三：LLM输出格式不合规。虽然Prompt中明确了JSON格式要求，但LLM偶尔还是会输出带额外文字的内容。ARTEMIS的解析器做了容错处理，会尝试从返回文本中提取JSON片段。如果提取失败，会触发重试。如果重试多次仍然失败，建议检查Prompt中的格式约束是否足够清晰，或者考虑换一个对格式遵循更好的LLM。

情况四：决策置信度普遍偏低。如果LLM返回的置信度经常低于阈值，说明LLM对当前场景的判断不够确定。可能的原因是界面信息太复杂，或者任务描述太模糊。解决方法是精简界面描述，突出关键信息，同时把任务描述写得更具体。

6.3 模式切换时的上下文丢失问题

模式切换时，快速模式和智能模式之间的上下文传递是一个容易被忽视的问题。快速模式执行到一半切换到智能模式，智能模式需要知道之前执行了哪些步骤、当前处于什么状态，否则可能做出错误的决策。

ARTEMIS的解决方案是维护一个共享的执行上下文对象，包含当前用例信息、已执行步骤列表、当前页面状态摘要、设备信息等。快速模式和智能模式都从这个上下文读取信息，也都向这个上下文写入执行结果。切换模式时，上下文对象保持不变，只是决策引擎换了。

这里有一个实操中的坑：快速模式记录的页面状态摘要可能不够详细，智能模式接手后需要重新感知界面。如果重新感知的耗时太长，会影响整体执行效率。ARTEMIS的做法是，快速模式在每次操作后都会缓存一份最新的界面快照（控件树+截图），切换模式时直接复用这份快照，避免重复感知。

6.4 常见问题速查表

避坑技巧：在正式跑大批量用例之前，先用少量用例做一轮“模式触发率”测试。具体做法是：把所有步骤都标记为fast模式，跑一遍完整用例，统计有多少步骤触发了智能模式切换。如果触发率超过20%，说明快速模式的定位器需要优化，不要急着跑全量用例，否则会浪费大量时间和Token。

7. 性能调优与扩展思路

7.1 执行速度的优化空间

双模式架构的执行速度优化，核心思路是“让快速模式处理更多步骤，让智能模式处理更准”。具体来说有几个方向：

定位器自动修复：当快速模式定位失败并切换到智能模式后，智能模式成功定位到元素，ARTEMIS会把智能模式的定位结果反向生成一个快速模式定位器，加入定位器缓存。这样下次遇到同样的元素，快速模式就能直接处理，不需要再调用LLM。这个机制在实际使用中效果很好，随着用例执行次数增加，快速模式的覆盖率会逐步提升。

并行执行：对于不依赖同一设备状态的用例，可以并行执行。ARTEMIS支持多设备并行，每个设备独立运行用例，共享LLM调用配额。并行执行时需要注意设备间的资源竞争，比如ADB连接数限制、LLM服务的并发限制等。

预热机制：在正式执行用例之前，先做一轮预热，包括启动应用、加载基础页面、初始化定位器缓存等。预热可以减少正式执行时的冷启动开销。

7.2 准确率的提升策略

准确率提升的关键在于减少误判和漏判。ARTEMIS从几个方面入手：

多模型投票：对于关键决策步骤，可以同时调用两个不同的LLM，对比它们的输出。如果一致，则直接执行；如果不一致，则取置信度更高的结果，或者触发人工确认。这个策略会增加成本，但能显著提升关键步骤的准确率。

规则兜底：在智能模式之上再加一层规则校验。比如LLM决定点击某个坐标，规则层会检查这个坐标是否在屏幕范围内、是否在可点击区域内、是否与当前任务相关。如果规则校验不通过，则拒绝执行并触发重试。

反馈学习：记录每次智能模式决策的结果，包括执行成功与否、是否达到预期效果。这些数据可以用来微调Prompt，或者训练一个轻量级的分类器来预判LLM决策的可靠性。

7.3 扩展到其他平台的可行性

ARTEMIS目前主要针对Android平台，但双模式架构的设计思路是可以扩展到其他平台的。扩展到iOS平台的主要挑战在于设备控制层的差异，iOS的自动化控制需要通过WebDriverAgent或者类似的桥接方案，控件树的结构和属性也与Android不同。但决策层和编排层的逻辑基本可以复用，只需要替换感知层和设备控制层的实现。

扩展到Web平台相对容易，因为Web端的控件树（DOM）信息更丰富，快速模式的定位能力更强。智能模式在Web端主要用于处理动态内容、验证码、复杂交互等场景。扩展到桌面应用（Windows/macOS）的难度较大，因为桌面应用的控件树信息通常不如移动端和Web端规范，可能需要更多依赖图像识别和LLM的视觉理解能力。

7.4 成本控制的长期策略

LLM调用成本是智能模式的主要开销。长期来看，成本控制有几个方向：

模型分级：不是所有智能模式步骤都需要用最强的模型。简单的页面判断可以用轻量级模型，复杂的异常处理再用重量级模型。ARTEMIS支持按步骤配置模型等级，在准确率和成本之间做精细化平衡。

缓存复用：对于重复出现的界面状态和决策场景，可以缓存LLM的决策结果。比如“关闭弹窗”这个操作，如果弹窗的样式和内容相似，可以直接复用之前的决策，不需要每次都调用LLM。缓存需要设置合理的失效策略，避免因为界面变化导致缓存失效。

本地化部署：如果测试频率很高，可以考虑在本地部署轻量级LLM，减少对云端服务的依赖。本地部署的一次性投入较高，但长期来看单位成本更低，而且没有网络延迟问题。不过本地模型的决策能力通常不如云端大模型，需要根据实际需求权衡。

我个人在实际项目中的体会是，双模式架构的价值不在于“用了LLM”，而在于“知道什么时候该用LLM，什么时候不该用”。很多团队一上来就追求全智能模式，结果发现成本高、速度慢、稳定性差，最后又退回到传统方案。ARTEMIS的思路更务实：把LLM当作一个“专家系统”来用，只在传统方法搞不定的场景下请它出马，这样既能享受LLM的灵活性，又能保持传统方案的高效和稳定。这个平衡点需要根据具体应用的特点来调整，没有一刀切的标准，但双模式架构提供了一个很好的起点。