LLM驱动的移动端测试Agent实战：轻量级、可解释、可嵌入CI-平芜编程栈

1. 项目概述：当通用 Agent 框架真正“踩进”移动端测试泥地里

我做过三年多的移动应用质量保障，从纯手工点按、Appium 脚本维护，到基于图像识别的无代码测试平台搭建，再到后来参与某跨平台系统测试中台的迭代。但直到去年底接手一个需要覆盖 iOS/Android/鸿蒙三端、且 UI 变动频率高达每周 2~3 次的电商类 App 时，我才真正意识到：传统自动化测试框架的“脚本即资产”逻辑，在真实业务节奏下正在快速失效——不是写不出来，而是写出来三天就废，改脚本的时间比找 bug 还长。

这时候，“LLM 驱动的自动化测试”不再是个概念词，而成了我们团队在凌晨两点还在 Slack 上激烈讨论的救命稻草。但很快发现，市面上多数所谓“AI 测试工具”，本质只是把自然语言翻译成 Selenium/Appium 命令，背后仍是强依赖元素 ID/XPath 的脆弱链路；而另一些号称“Agent”的方案，又过度强调自主规划、多步推理，把一个“点击购物车→结算→输入优惠码→提交订单”的简单路径，硬拆成 7 步子任务+3 轮反思循环，执行耗时翻倍，失败归因却更模糊。

本篇讲的，就是我们如何把通用 Agent 框架（以 LangChain + Llama3-70B 本地部署为基线）真正“下沉”到移动端测试一线：不追求炫技式自主探索，而是让 Agent 成为一个可解释、可干预、可复用、可嵌入 CI 流程的测试协作者。它不替代测试工程师，但能自动完成 68% 的回归用例生成、82% 的异常路径覆盖补全、以及 100% 的失败日志语义归因。关键词落在三个实打实的落点上：移动端上下文建模、轻量级动作空间约束、测试意图到操作链的确定性映射。适合正在被频繁发版压得喘不过气的 QA 团队、想把 LLM 引入测试流程但卡在“不好控、不好调、不好信”的技术负责人，以及对 Agent 架构有基础了解、正寻找垂直场景落地切口的开发者。

这不是一篇讲“LLM 多么强大”的布道文，而是一份我们踩坑 47 次、重写 5 版核心调度器、最终在生产环境稳定运行 112 天的实战手记。下面所有内容，你都能直接抄作业，也能立刻判断它是否适配你的项目现状。

2. 整体设计思路：为什么必须放弃“通用 Agent”的完整形态？

2.1 通用 Agent 框架的三大“水土不服”

先说清楚我们为什么不能直接套用 LangGraph 或 AutoGen 的标准模板。这不是能力问题，而是移动端测试这个场景本身，对 Agent 的“自由度”提出了反向约束：

第一不服：动作空间必须极度受限
通用 Agent 典型动作集包括search_web,run_python,call_api,read_file……但在测试机上，它唯一合法动作只有tap(x,y),swipe(start_x,start_y,end_x,end_y),input(text),press_back()这四类。多一个open_browser()动作，就多一分不可控风险。我们曾试过保留execute_shell动作用于抓取 logcat，结果 Agent 在一次异常恢复中误执行了adb shell pm clear com.xxx.app，清空了被测 App 数据，导致整个测试流水线中断 40 分钟。教训很痛：移动端 Agent 的动作层，必须是白名单制，且每条动作指令需带设备 ID、超时阈值、重试次数三重校验。
第二不服：状态感知不能依赖“截图+OCR”单模态
很多方案把手机屏幕截图喂给多模态模型（如 Qwen-VL），再让模型识别按钮文字并决策。这在 Demo 场景很酷，但实测下来问题极多：iOS 系统弹窗阴影干扰 OCR、深色模式下文字对比度不足、鸿蒙系统自定义字体导致识别率暴跌至 53%。我们最终放弃纯视觉路径，转而构建“三层状态感知”：
1. 底层：ADB 获取当前 Activity 名 + View 层级树（uiautomator dump输出 XML）；
2. 中层：基于 AccessibilityNodeInfo 提取可交互节点的 text/content-desc/bounds；
3. 顶层：人工标注的“业务语义标签”（如<button id="pay_btn" label="立即支付" page="order_confirm"/>）。
  三层数据融合后输入 LLM，准确率从 53% 提升至 91.7%，且推理耗时下降 64%（XML 解析比高分辨率截图快得多）。
第三不服：目标设定不能是开放式提问
“请帮用户完成下单”这种模糊指令，在通用 Agent 中会触发复杂规划。但在测试中，我们要的是确定性：“验证优惠码‘SUMMER2024’在订单确认页输入后，页面显示‘已减免 ¥25.00’且‘提交订单’按钮变为高亮状态”。为此，我们彻底重构了 Prompt 结构，把测试用例拆解为：
- 前置条件（Precondition）：App 已登录，购物车含 1 件商品，网络正常；
- 操作序列（Action Chain）：tap("去结算") → wait("订单确认页加载完成") → input("SUMMER2024") → wait("优惠信息区域刷新")；
- 断言集合（Assertions）：text_exists("已减免 ¥25.00") AND button_state("提交订单", "enabled=True")。
  这种结构化输入，让 LLM 不再“思考怎么干”，而是专注“如何精准干”。

提示：不要试图让 LLM 学习“什么是支付流程”，而要让它学会“如何把一条结构化测试用例，编译成可在真机上稳定执行的动作链”。这是思维范式的根本切换。

2.2 我们的轻量化 Agent 架构：TestAgent v2.3

基于上述认知，我们设计了 TestAgent，它不是独立服务，而是嵌入现有测试中台的一个 Python 模块（约 1200 行核心代码）。整体分三层：

Orchestrator（调度器）：接收结构化测试用例 JSON，解析出 Action Chain，调用 LLM 生成动作指令；
Executor（执行器）：对接 ADB/uiautomator2，执行 tap/swipe 等原子动作，并实时捕获设备状态（Activity、XML 树、截图）；
Verifier（校验器）：根据 Assertions 定义，调用 XPath 查询或 OCR 辅助校验，返回布尔结果 + 失败详情。

关键创新点在于“双通道反馈机制”：

主通道：Executor 执行后，将实际状态（XML 树 + 当前 Activity）回传给 Orchestrator；
副通道：Verifier 同步运行，若断言失败，立即将失败描述（如 “text ‘已减免 ¥25.00’ 未找到”）注入下一轮 LLM 提示，强制其修正动作。
这避免了通用 Agent 中常见的“幻觉执行”——比如模型以为自己点了“立即支付”，其实点到了广告 Banner 上，然后继续往下走，直到最后一步才发现失败，归因成本极高。

我们放弃了一切“自主探索”“长期记忆”“多 Agent 协作”等 fancy 特性。TestAgent 每次只处理一个测试用例，生命周期不超过 90 秒，内存占用 <120MB，可并行启动 8 个实例跑在一台 32G 内存的测试服务器上。事实证明，在移动端测试这个场景里，“小而确定”远胜于“大而模糊”。

3. 核心细节解析：移动端上下文建模与动作空间约束

3.1 如何让 LLM 真正“看懂”手机屏幕？

很多团队卡在第一步：LLM 怎么理解当前界面？直接喂截图？太慢且不准。我们的解法是构建“可计算的界面语义图谱”，分三步走：

第一步：静态资源提取（离线完成）
在 App 每次构建后，自动运行以下脚本：

# 1. 启动 App 至首页，dump 当前 UI 树 adb shell uiautomator dump /sdcard/window_dump.xml adb pull /sdcard/window_dump.xml ./dumps/home.xml # 2. 解析 XML，提取所有可交互节点（clickable=true OR focusable=true） python parse_ui_tree.py --input ./dumps/home.xml --output ./semantic/home.json

parse_ui_tree.py的核心逻辑是：遍历 XML 中每个 node，若满足@clickable='true'或@focusable='true'，则提取其@resource-id,@content-desc,@text,@bounds，并生成唯一哈希 ID（如btn_pay_home_8a3f）。输出 JSON 示例：

{ "btn_pay_home_8a3f": { "resource_id": "com.xxx:id/btn_pay", "text": "去结算", "content_desc": "跳转到订单确认页", "bounds": "[420,1280][680,1360]", "page": "home" }, "img_ad_banner_c2e1": { "resource_id": "com.xxx:id/ad_banner", "text": "", "content_desc": "促销广告", "bounds": "[100,800][980,1020]", "page": "home" } }

第二步：动态状态绑定（运行时完成）
TestAgent 启动后，每执行一个动作，都会重新 dump UI 树，并与静态语义图谱匹配。匹配逻辑不是字符串比对，而是空间位置相似度 + 文本语义相似度：

空间相似度：计算新节点 bounds 与图谱中节点 bounds 的 IOU（交并比），>0.6 则视为同一元素；
文本语义相似度：对text和content-desc字段，用 Sentence-BERT 计算余弦相似度，>0.75 则加分。
这样即使 App 更新后 resource-id 改变（如btn_pay→btn_checkout），只要位置和文案没大变，仍能准确关联。

第三步：业务标签注入（人工维护）
静态图谱 JSON 中，我们预留label字段，由 QA 工程师填写业务语义，例如：

"btn_pay_home_8a3f": { "label": "立即进入结算流程", "category": "payment_flow", "criticality": "high" }

这个label字段，就是 LLM 理解“去结算”按钮业务含义的唯一依据。它不来自代码，而来自人对业务的理解。我们要求每个新页面上线，必须由 QA 提交至少 3 个关键按钮的 label，否则测试用例无法生成。

注意：不要让 LLM 自己总结 label！我们试过让模型基于 content-desc 生成“业务描述”，结果它把“跳转到订单确认页”总结成“用户意图完成购买行为”，过于抽象，导致后续动作选择偏差。业务语义必须由人定义，LLM 只负责匹配和执行。

3.2 动作空间的白名单设计与安全护栏

TestAgent 的动作空间严格限定为 4 个原子动作，全部通过uiautomator2封装，且每调用一次都经过三层校验：

动作	参数要求	安全校验点	超时/重试策略
`tap`	`(x, y)`或`element_id`	1. 坐标必须在屏幕范围内（0~1080×0~2340） 2. 若传 element_id，需在当前语义图谱中存在 3. 同一坐标 3 秒内禁止重复点击（防误触）	默认超时 5s，失败重试 1 次，重试间隔 1s
`swipe`	`(sx,sy,ex,ey,duration_ms)`	1. 起止坐标均在屏幕内 2. duration ∈ [100, 2000]ms（过短无效，过长易误判） 3. 禁止 swipe 到系统导航栏区域（y>2200）	默认超时 8s，失败重试 1 次
`input`	`(text, element_id)`	1. text 长度 ≤ 200 字符（防注入） 2. element_id 必须为`EditText`类型节点 3. 自动清除原内容（`clear()`）后再输入	默认超时 6s，失败重试 2 次
`press_back`	无参数	1. 检查当前 Activity 是否为栈顶 2. 禁止连续 3 次 press_back（防退出 App）	默认超时 3s，失败不重试

所有动作执行前，Executor 会先调用uiautomator2.info获取当前设备状态（屏幕尺寸、旋转角度、前台包名），确保环境一致。一旦任何校验失败，动作立即中止，并向 Orchestrator 返回结构化错误码（如ERR_COORD_OUT_OF_BOUND），而非抛出 Python 异常——因为 Orchestrator 需要据此决定是重试、跳过，还是触发人工介入。

我们还加了一道“熔断开关”：当单个测试用例内连续 3 次动作失败（非网络超时，而是校验失败），TestAgent 自动终止该用例，标记为FLAKY，并输出失败路径快照（含每步的 XML 和截图）。这避免了通用 Agent 中常见的“死循环尝试”，把不可控风险锁死在单个用例内。

3.3 测试意图到动作链的确定性映射：Prompt 工程实战

LLM 不是万能翻译器。把“输入优惠码”翻译成input("SUMMER2024")很容易，但翻译成“先找到优惠码输入框，它可能在折叠面板里，需先点击‘展开更多’，再滑动到第 3 个 EditText，然后输入”就极难。我们的解法是：用结构化 Schema 强约束 LLM 的输出格式，并用 Few-shot 示例固化其行为。

Prompt 核心结构如下（已脱敏）：

你是一个移动端测试专用 Agent，只能执行 tap/swipe/input/press_back 四种动作。 请严格按以下 JSON Schema 输出动作指令，不得添加任何额外字段或解释： { "action": "tap|swipe|input|press_back", "params": { "x": 0, "y": 0, "element_id": "string", "text": "string", "sx": 0, "sy": 0, "ex": 0, "ey": 0, "duration_ms": 500 }, "reason": "一句话说明此动作如何推进测试目标（≤20字）" } 当前界面语义图谱（截取关键部分）： { "edt_coupon_code_7b2f": {"text": "", "content_desc": "请输入优惠码", "bounds": "[200,1500][800,1580]", "page": "order_confirm"}, "btn_expand_more_9c4a": {"text": "展开更多", "bounds": "[100,1400][300,1460]", "page": "order_confirm"} } 测试目标：在订单确认页输入优惠码 'SUMMER2024' Few-shot 示例1： 输入：点击“展开更多”按钮 输出：{"action":"tap","params":{"element_id":"btn_expand_more_9c4a"},"reason":"展开优惠码输入区域"} Few-shot 示例2： 输入：在优惠码输入框输入 'SUMMER2024' 输出：{"action":"input","params":{"element_id":"edt_coupon_code_7b2f","text":"SUMMER2024"},"reason":"填充优惠码字段"} 现在，请处理以下目标：

关键技巧有三：

Schema 优先：明确要求 JSON 输出，且字段名、类型、必选性全部定义，LLM 会本能遵循；
上下文精简：只提供当前页面相关节点，避免信息过载；
Few-shot 锚定：两个示例直击最常见动作（tap 和 input），且reason字段强制模型聚焦业务目标，而非技术细节。

实测表明，使用 Llama3-70B（4-bit 量化）在 24G 显存卡上，单次动作生成平均耗时 1.2 秒，准确率 94.3%。若用 8B 模型，准确率降至 86.1%，但耗时仅 0.3 秒——我们最终选择 13B 模型（准确率 91.8%，耗时 0.6 秒），在速度与精度间取得最佳平衡。

4. 实操过程：从零部署 TestAgent 并接入 CI 流程

4.1 环境准备与依赖安装（实测通过的最小配置）

我们不推荐在生产环境直接拉取 HuggingFace 大模型，而是采用“模型蒸馏 + 本地缓存”方案。以下是我们在 Ubuntu 22.04 服务器上的完整部署清单：

硬件要求：

CPU：Intel i7-11800H 或同级（8 核 16 线程）
GPU：NVIDIA RTX 3090（24G 显存）或 A10（24G）
内存：64G DDR4
存储：1TB NVMe SSD（模型缓存占约 350G）

软件依赖：

# 1. 基础环境 sudo apt update && sudo apt install -y adb android-tools-adb python3.10-venv # 2. Python 依赖（requirements.txt） torch==2.1.0+cu118 # CUDA 11.8 transformers==4.35.0 accelerate==0.24.1 uiautomator2==2.16.21 sentence-transformers==2.2.2 langchain==0.1.12

模型部署：
我们未使用原始 Llama3-70B，而是采用Phi-3-mini-4k-instruct（3.8B 参数）作为主力模型。原因很实在：

在 24G 显存上，Phi-3 可以 4-bit 量化后全加载，batch_size=4，推理速度 18 tokens/s；
经过 2000 条测试用例微调（LoRA），其在“动作生成”任务上的准确率反超 Llama3-70B 2.1 个百分点（93.9% vs 91.8%）；
模型体积仅 2.1GB，下载和加载速度快 5 倍。

微调数据构造方法：

从历史 12 个月的 Appium 脚本中，提取 1500 条“自然语言描述 → 动作指令”对（如 “点击右上角头像” →tap(920,120)）；
人工编写 500 条边界 case（如 “当‘立即支付’按钮被遮挡时，应先 swipe 向上”）；
使用 QLoRA 微调，学习率 2e-4，训练 3 个 epoch，loss 从 1.82 降至 0.33。

模型文件存放于/opt/models/phi3-test-v1/，启动时通过AutoModelForCausalLM.from_pretrained()加载。整个过程无需 Docker，纯 Python 进程管理，便于 CI 集成。

4.2 TestAgent 核心模块代码详解

以下是 Orchestrator 的核心调度逻辑（已简化，保留关键注释）：

# orchestrator.py from transformers import AutoModelForCausalLM, AutoTokenizer import json import re class TestAgentOrchestrator: def __init__(self, model_path="/opt/models/phi3-test-v1"): self.tokenizer = AutoTokenizer.from_pretrained(model_path) self.model = AutoModelForCausalLM.from_pretrained( model_path, device_map="auto", load_in_4bit=True ) def generate_action(self, test_case: dict, current_state: dict) -> dict: """ test_case: { "target": "在订单确认页输入优惠码 'SUMMER2024'", "preconditions": ["App 已登录", "购物车非空"], "assertions": ["text_exists('已减免 ¥25.00')"] } current_state: { "page": "order_confirm", "semantic_nodes": {"edt_coupon_code_7b2f": {...}, ...} } """ # Step 1: 构建 Prompt（省略模板拼接，见 3.3 节） prompt = self._build_prompt(test_case, current_state) # Step 2: 模型推理 inputs = self.tokenizer(prompt, return_tensors="pt").to("cuda") outputs = self.model.generate( **inputs, max_new_tokens=128, do_sample=False, # 关键！禁用采样，保证确定性 temperature=0.01, # 极低温度，抑制随机性 pad_token_id=self.tokenizer.eos_token_id ) response = self.tokenizer.decode(outputs[0], skip_special_tokens=True) # Step 3: 解析 JSON（正则提取，防格式错误） try: json_str = re.search(r'\{.*\}', response, re.DOTALL).group() action = json.loads(json_str) # 校验 action 字段合法性 if not self._validate_action(action): raise ValueError("Invalid action schema") return action except Exception as e: # 解析失败时，返回默认 fallback 动作 return {"action": "press_back", "params": {}, "reason": "Parse failed, fallback to back"} def _validate_action(self, action: dict) -> bool: required_keys = ["action", "params", "reason"] if not all(k in action for k in required_keys): return False if action["action"] not in ["tap", "swipe", "input", "press_back"]: return False # 更多字段校验... return True

Executor 模块则完全封装 uiautomator2，关键点在于“状态快照”机制：每次动作后，自动执行：

# executor.py def take_snapshot(self, step_name: str): # 1. 截图 self.d.screenshot(f"/tmp/{step_name}_screen.png") # 2. Dump UI 树 self.d.dump_hierarchy(f"/tmp/{step_name}_dump.xml") # 3. 获取 Activity activity = self.d.info.get("currentPackageName", "") + "/" + self.d.info.get("currentActivity", "") # 4. 合并为结构化快照 return { "screenshot": f"/tmp/{step_name}_screen.png", "xml_dump": f"/tmp/{step_name}_dump.xml", "activity": activity, "timestamp": time.time() }

这些快照全部上传至内部 MinIO 存储，供 Verifier 读取和人工复盘。一个 10 步的测试用例，会产生 10 组快照，总大小约 15MB，但这是故障归因的黄金数据。

4.3 接入 Jenkins CI 的完整流水线配置

我们没有新建一套 CI 系统，而是将 TestAgent 无缝嵌入现有 Jenkins 流水线。关键在于“测试用例即代码”——所有测试用例以 YAML 文件形式存于 Git 仓库/tests/mobile/下，例如checkout_with_coupon.yaml：

# tests/mobile/checkout_with_coupon.yaml test_case_id: TC-2024-087 description: 验证优惠码在订单确认页生效 preconditions: - app_state: "logged_in" - cart_items: 1 - network: "wifi" actions: - target: "点击‘去结算’按钮" - target: "等待订单确认页加载完成" - target: "点击‘展开更多’按钮" - target: "在优惠码输入框输入 'SUMMER2024'" - target: "等待优惠信息刷新" assertions: - type: "text_exists" value: "已减免 ¥25.00" - type: "button_state" element_id: "btn_submit_order" state: "enabled=True"

Jenkinsfile 中的关键 stage：

stage('Run Mobile Tests') { steps { script { // 1. 拉取最新测试用例 sh "git clone https://git.internal/tests.git /tmp/tests" // 2. 启动 TestAgent 服务（后台进程） sh "nohup python3 -m testagent.server --port 8000 > /tmp/testagent.log 2>&1 &" sleep(5) // 等待服务启动 // 3. 遍历所有 YAML 用例，调用 API 执行 def testFiles = sh(script: "ls /tmp/tests/mobile/*.yaml", returnStdout: true).trim().split("\n") for (file in testFiles) { sh "curl -X POST http://localhost:8000/run -H 'Content-Type: application/json' -d @${file}" } } } }

TestAgent 提供的/run接口，接收 YAML 文件路径，自动解析、执行、生成报告（HTML + JUnit XML），并上传至 Nexus 作为构建产物。CI 控制台直接显示测试通过率、失败用例列表、以及每个失败用例的快照链接。QA 工程师点击链接，即可看到完整的执行路径、每步截图和 XML 树，归因时间从平均 22 分钟缩短至 3 分钟以内。

5. 常见问题与排查技巧实录：那些没写在文档里的坑

5.1 典型问题速查表

问题现象	可能原因	排查步骤	解决方案
动作生成准确率骤降（<70%）	模型缓存损坏或显存不足导致推理异常	1.`nvidia-smi`查看 GPU 内存占用 2. 删除`/tmp/hf_cache`重建缓存 3. 检查`dmesg`是否有 OOM killer 日志	重启 TestAgent 进程；增加`--max_memory`参数限制显存使用
tap 动作总是点偏（坐标误差 >50px）	设备屏幕分辨率与 ADB 识别不一致（如开启“字体缩放”）	1.`adb shell wm size`查看 reported size 2.`adb shell wm density`查看 density 3. 对比设备实际物理分辨率	在 Executor 初始化时，动态校准坐标映射：`real_x = reported_x * (physical_width / reported_width)`
input 动作后文本未生效，或输入乱码	输入法冲突（系统输入法拦截了 uiautomator2 的 input 事件）	1.`adb shell ime list -s`查看当前输入法 2.`adb shell ime set com.android.inputmethod.latin/.LatinIME`切换为 AOSP 输入法	在测试开始前，统一设置`adb shell settings put secure default_input_method com.android.inputmethod.latin/.LatinIME`
swipe 动作无响应，或滑动距离过短	uiautomator2 的 swipe 方法在某些 Android 版本上存在兼容性问题	1. 检查`uiautomator2`版本（必须 ≥2.16.20） 2.`adb shell getprop ro.build.version.release`查看 Android 版本	替换为底层 ADB 命令：`adb shell input swipe {sx} {sy} {ex} {ey} {duration}`，Executor 内部自动降级
Verifier 报告 text_exists 失败，但截图中文字清晰可见	OCR 引擎（PaddleOCR）在深色模式/抗锯齿字体下识别率低	1. 截图保存为 PNG（非 JPG，保真度高） 2. 对截图做二值化预处理（OpenCV）	在 Verifier 中加入预处理 pipeline： `cv2.cvtColor() → cv2.threshold() → PaddleOCR`，识别率提升至 96.2%

5.2 我们踩过的 5 个血泪坑

坑1：盲目信任 LLM 的“自我修正”能力
初期我们设计了一个 loop：若断言失败，让 LLM 读取失败描述，自行生成修正动作。结果模型在 3 次失败后，开始胡乱press_back，最后退出 App。教训：LLM 不擅长“调试”，只擅长“执行”。失败归因必须由 Verifier 完成，修正动作必须由人工预设规则库触发。我们现在有 12 条“失败修复规则”，如text_not_found → swipe_down_then_search，由 QA 维护，LLM 只负责调用。

坑2：忽略设备状态漂移
某次测试中，Agent 在第 7 步突然press_back，原因是设备在后台被系统杀死了 App，前台 Activity 变为 Launcher。但 Executor 未检测到此变化，仍按原计划执行。解决方案：每次动作前，强制检查adb shell dumpsys activity activities \| grep mResumedActivity，若为空或非目标包名，立即重启 App 并标记为RESTARTED。

坑3：XML 树 dump 的时机陷阱
uiautomator dump并非原子操作，有时在 dump 过程中界面已刷新，导致 XML 树与截图不一致。我们曾因此误判元素位置。解决：在 dump 前插入adb shell input keyevent 120（模拟空格键，强制 UI 刷新），并增加 300ms 延迟。

坑4：优惠码输入的“软键盘”盲区
input()动作无法触发软键盘弹出，导致部分 EditText 无法聚焦。我们试过d.click()+d.send_keys()组合，但不稳定。最终方案：在 input 前，先tap()一次 EditText 的中心坐标，再input()，并监听adb logcat \| grep InputMethod确认键盘已起。

坑5：CI 环境的“静默失败”
Jenkins slave 节点默认无图形界面，uiautomator2初始化时会报错java.awt.HeadlessException。很多人搜到的方案是加-Djava.awt.headless=true，但这会让 uiautomator2 无法工作。正确解法：在 slave 节点安装 xvfb（虚拟帧缓冲）：sudo apt install xvfb，然后xvfb-run -a -s "-screen 0 1080x2340x24" python3 test_script.py。

5.3 性能优化的 3 个关键参数

TestAgent 的吞吐量，不取决于模型多大，而在于I/O 瓶颈的突破。我们通过监控pidstat -d发现，90% 时间花在 XML 解析和截图 I/O 上。优化后，单用例平均执行时间从 42 秒降至 18.3 秒：

XML 解析加速：弃用xml.etree.ElementTree，改用lxml（C 实现），解析 5MB XML 从 1.2s 降至 0.18s；
截图存储优化：不保存全屏 PNG，而是用uiautomator2的screenshot(format='raw')获取 raw bytes，再用PIL.Image.frombytes()构建 PIL Image，内存占用降低 60%；
ADB 连接复用：不每次动作都adb connect，而是用uiautomator2.connect(serial)建立长连接，避免 TCP 握手开销。

这些优化没有一行涉及 LLM，却让整体效率提升 129%。再次印证：在工程落地中，80% 的性能瓶颈，永远在模型之外。

6. 效果验证与团队协作模式升级

6.1 量化效果：不是“能用”，而是“值得用”

我们用 3 个月时间，在 2 个核心业务线（电商主 App、会员小程序）上全量替换原有 Appium 脚本。效果不是靠“演示视频”，而是靠每天自动生成的报表：

指标	替换前（Appium 脚本）	替换后（TestAgent）	提升
新增用例开发耗时（平均）	42 分钟/条	8.3 分钟/条	↓ 80.2%
用例维护成本（周均）	17.5 小时	2.1 小时	↓ 88.0%
UI 变更导致的用例失效率	63.4%	9.2%	↓ 85.5%
CI 流水线中移动端测试耗时