移动端轻量级AI Agent自动化UI验证：sim-use

sweet丶
20 阅读6分钟

前言

传统AI Coding的过程一般是：

沟通 -》Agent理解并coding -》人工验证UI -》不达预期，再次沟通-》...

对于验证UI这一步无法闭环，制约了AI自动完成交付的闭环。目前现在市面上能看到的两类方案

  • 靠截图 + 多模态模型：贵、慢，对长尾控件识别能力有限，点坐标需要靠截图计算容易漂移，不稳定，而且多模态的调用成本爆炸。
  • dump UI tree 给 agent 看：UIAutomator / AccessibilityService / iOS 的 AX API，原始输出动不动几十甚至上百 KB JSON，使用不当 token 消耗惊人，还经常拿不到 UI 元素（这点后面细说）。

“让 agent 高效、准确、可靠、快速地拥有对 app 的视觉和操作能力” 是缺乏的，这正是本文要介绍的框架提供的能力。

flowchart LR
    A["产品需求"] --> B["可执行验收标准"]
    B --> C["Agent分析与实施"]
    C --> D["自动编译、测试、UI验证"]
    D --> E{"验收标准通过？"}
    E -->|"否"| F["日志、截图、失败断言"]
    F --> C
    E -->|"是"| G["人工体验与最终验收"]

一、sim-use 是什么

sim-use 是一个跨平台 CLI，让 agent 可以像人一样操作 iOS 模拟器和 Android 模拟器/真机。

sim-use 是 LY Corporation 开源的移动端 UI 操作命令行工具，主要面向 AI Agent。 它让 AI 能够：

  • 读取当前页面的无障碍树；
  • 找到按钮、文本、输入框、列表项；
  • 执行点击、滑动、输入、粘贴；
  • 截图、录屏；
  • 检查 App 进程是否消失；
  • 按“观察 → 操作 → 验证”完成 UI 冒烟测试。

它不是需要链接进 App 的 SDK，不应加入 Podfile 或 SPM。它运行在开发电脑上：

App 代码：不直接依赖 sim-use
开发电脑上：安装 sim-use CLI 和 AI Skill

当前平台支持情况：

平台支持情况
iOS Simulator支持
iPhone/iPad 真机不支持
Android Emulator支持
Android 真机支持，需要 Bridge APK

二、工作原理

flowchart LR
    A["AI Agent"] -->|"sim-use ui"| B["sim-use CLI"]
    B --> C["iOS Simulator 无障碍树"]
    C -->|"控件、文字、位置、标识"| B
    B -->|"压缩后的页面描述"| A

    A -->|"tap / type / swipe"| B
    B --> D["Simulator HID 输入管线"]
    D --> E["App UI"]
    E --> C

    E -->|"发起网络请求"| F["服务端"]
    F -->|"返回数据"| E
    E -->|"UI刷新"| C

2.1 页面读取

sim-use 从 iOS Accessibility Tree 获取页面元素，并转换成适合 AI 阅读的文本：

@6  Button      "Food Truck"
@7  Heading     "Orders"
@9  Button      "Order#1224"
@19 TextField   "Search"

其中：

  • @6：最近一次页面快照产生的临时别名；
  • #loginButton：来自 accessibilityIdentifier 的稳定标识；
  • "Orders"：来自控件文案或无障碍标签。

稳定性优先级建议：

accessibilityIdentifier
> 精确文案
> 临时 @N 别名
> 坐标

2.2 操作页面

AI读取页面后，可以执行：

sim-use tap '#loginButton'
sim-use type 'test@example.com'
sim-use gesture scroll-up

iOS 侧通过 Simulator 的 HID 输入管线模拟真实触摸和键盘事件。

2.3 验证页面

点击命令返回成功只代表触摸事件已经发送，不代表业务成功。正确流程必须再次读取页面：

读取 Orders 页面
→ 点击 Order #1224
→ 再次读取页面
→ 确认出现 Order #1224、Placed、Total Donuts

2.4 等待网络刷新

sim-use 不直接监听 HTTP 请求，也不知道请求是否返回 200。

它采用结果导向的判断：

点击刷新
→ 周期性读取页面
→ loadingIndicator 消失
→ requestSuccessView 出现
→ 校验刷新后的数据

适合配合：

loadingView.accessibilityIdentifier = "loadingIndicator"
successView.accessibilityIdentifier = "requestSuccessView"
errorView.accessibilityIdentifier = "requestErrorView"

它不能可靠处理：

  • 直接断言 HTTP 状态码；
  • 图片验证码识别；
  • 获取真实短信/邮件验证码；
  • 服务端请求成功但 UI 未体现的状态。

三、适合使用的场景

3.1 适合

场景适用度
AI修改页面后自动跑冒烟流程高
登录、设置、表单等重复操作高
验证按钮是否可点击、页面是否跳转高
验证网络请求后 UI 是否刷新高
检查关键文字和状态是否存在高
自动截图、录屏高
发现缺失的无障碍信息高
Simulator 兼容的纯 UI App高
独立 UI Harness高

3.2 不适合

场景原因
iPhone/iPad 真机iOS 真机不受支持
BLE真实连接Simulator 不具备真实蓝牙环境
UWB精确查找必须依赖支持 UWB 的 iPhone 和配件
USB设备通信必须使用真机和真实设备
OTA完整链路涉及真实连接、传输和固件升级
Find My真实流程涉及系统能力、账号和硬件
像素级视觉验收截图不等于自动设计稿对比
图片验证码无障碍树通常只能识别为一张图片
网络接口断言sim-use 不截获网络请求

四、iOS 真机验证替代方案

4.1 XCUITest——当前首选

XCUITest 是 Apple 官方 UI 自动化方案，支持 Simulator 和签名后的 iOS 真机。

优势：

  • Apple 官方维护；
  • 与 Xcode、XCTest、Test Plan 集成；
  • 支持真实 iPhone；
  • 可以按 accessibilityIdentifier 查找控件；
  • 支持等待元素出现；
  • 支持截图、附件、日志和性能指标；
  • 当前项目已有 iotUITests Target，可直接扩展。

不足：

  • 测试代码需要编译；
  • 对探索性、临时操作不如 sim-use 灵活；
  • 真机需要签名、Developer Mode、证书和设备管理；
  • BLE外设、验证码、登录状态仍需测试环境配合。

但真实 BLE/UWB/USB 仍需要准备配套硬件和可重复的设备状态。

4.2 Appium + XCUITest Driver + WebDriverAgent

Appium 的 iOS 真机驱动底层使用 WebDriverAgent，可以通过 WebDriver API 操作真机。

优势：

  • 支持 iOS 真机；
  • 跨平台；
  • 可以用多种语言编写测试；
  • HTTP/WebDriver 接口适合外部系统或 AI 调用；
  • 比 XCUITest 更适合远程交互控制。

不足：

  • 环境复杂；
  • iOS 16+ 需要开启 Developer Mode 和 UI Automation；
  • WebDriverAgent 必须使用有效 Provisioning Profile 签名；
  • Xcode、iOS版本和 WDA 之间存在兼容维护成本；
  • 执行速度和稳定性通常不如原生 XCUITest。

适合：

  • 公司已有 Appium 测试体系；
  • 需要 Android/iOS 共用测试框架；
  • 需要 AI 直接通过远程接口操作真机；
  • 愿意维护设备和 WDA 签名环境。

建议优先级：中，先做小规模 POC。

4.3 直接使用 WebDriverAgent

绕过 Appium，直接通过 WebDriverAgent 的 HTTP 接口操作 iPhone。

优势：

  • 支持真机；
  • 比完整 Appium 栈更轻；
  • 适合自研 AI 真机控制平台。

不足：

  • 接口更底层；
  • 需要自行处理 WDA 启动、签名、会话、兼容性；
  • 需要自己补充等待、截图、错误恢复和报告；
  • 自研维护成本高。

建议优先级：低，除非公司计划建设统一的 AI 设备实验室。

4.4 云真机平台

例如：

  • AWS Device Farm；
  • BrowserStack App Automate；
  • Sauce Labs；
  • Firebase Test Lab。

优势：

  • 不需要自己维护大量 iPhone；
  • 支持多机型、多系统版本；
  • 可运行 XCUITest 或 Appium；
  • 适合常规 UI 兼容性回归。

不足：

  • App 包和测试数据需要上传第三方平台；
  • 内网、VPN和隐私合规需要评审；
  • 有持续费用；
  • 无法方便连接公司的 BLE、UWB、USB 外设；
  • 不适合核心硬件场景。

建议优先级：常规 UI 兼容性测试为中；硬件业务为低。

4.5 内部真机测试台

采用：

Mac mini
+ 多台固定iPhone
+ USB连接
+ XCUITest或Appium
+ 固定测试账号
+ 固定BLE/UWB/USB硬件

优势：

  • 数据不出公司；
  • 可以连接真实配件；
  • 能覆盖 BLE、OTA 和部分硬件流程；
  • 可由 Jenkins 调度。

不足：

  • 设备状态恢复困难；
  • 蓝牙配对、固件状态和账号状态容易导致测试不稳定；
  • 需要管理充电、USB Hub、系统升级、签名和设备占用；
  • UWB方向和距离测试可能还需要物理装置或人工配合。

建议优先级：中长期最高，尤其适合硬件产品回归。

3.6、真机验证推荐顺序

  1. XCUITest + 本地连接真机；
  2. 人工验证 BLE/UWB/USB/OTA 等真实硬件流程；
  3. 中期建设内部真机测试台；
  4. 有跨平台或远程控制需求时评估 Appium + WebDriverAgent；
  5. 云真机仅用于不依赖外围硬件的通用 UI 兼容性测试。

参考资料：

avatar
文章
阅读
粉丝