开源｜移动端Jev —— SoloPi真机实战，干货满满

SoloPi 是一套面向移动端研发的开源自动化与 AI Harness 工程。它保留了 SoloPi 在 Android 真机上的录制、回放、断言和性能诊断能力，并增加 Agent 接入、动态页面安全执行、独立结果 判定、无人值守托管和同次运行证据，让一次设备操作可以交付为可进入研发与 CI 流程的结论。本文为该项目相关同学分享在TesterHome社区网站的文章，以下为作者观点：

SoloPi 开源仓库：https://github.com/alipay/SoloPi

打开支付宝，进入蚂蚁森林，点开菜单，再进入提醒设置。这条看起来很简单的流程，放到自动化测试里，需要处理页面动画、弹窗、节点定位、跳转等待，还要证明最后真的到了预期页面。

我们借鉴 Jev 生态的快速决策与执行思路，对 SoloPi 的真机执行链路进行了改造，并把本地 Laya 和社区 Laya Vision 放到同一套真实页面上评测。

实际测到的结果是：菜单往返的完整会话耗时从 13.214 秒降到 10.004 秒，下降 24.3%；提醒设置往返从 17.130 秒降到 15.013 秒，下降 12.4%。这两个时间都包含独立复验、截图和会话释放。

这篇文章会讲清楚改了什么、怎么使用，以及哪些收益已经得到验证。执行链路的提速已经成立；Laya 的模型增益仍需要更多证据，两者分别评估。

一、背景与痛点

1. Agent 的 “快”，取决于整条执行链路

Jev 和 Laya 引起关注的一个原因，是把许多小决策变成有限选项的选择。例如，给定 “打开提醒设置” 这个目标，让模型在 “攻略、分享、帮助、设置” 中选一个。Laya 支持这类结构化选择，可以在本地运行。Laya 项目说明

但模型选出 “设置”，离测试完成还有一段距离：手机当前还是刚才的页面吗？按钮被遮住了吗？点击是否发出？页面有没有加载完？打开的究竟是不是提醒设置？

SoloPi 是 Android 真机自动化工具，已有页面采集、执行、回放与结果验证能力。我们的目标是让这些能力更适合 Agent：局部选择可以灵活，执行要受约束，验收条件要固定。

本文借鉴的是 Jev 生态的设计思路。本地实际运行的文字模型是开放权重 Laya，视觉实验使用社区 Laya Vision；没有在手机或电脑上部署官方 Jev 权重。

2. 支付宝真机暴露了三个很具体的问题

这些问题会消耗秒级时间。即使本地模型只需十几毫秒，也不能直接消除采树、通信、页面加载和验收的成本。

jev-ultrafast的公开对照也体现了这一点：固定模型后，优化运行时，任务中位数从 9.450 秒降到 7.092 秒。它采用交替配对实验，并明确初始导航、额外独立复验不在任务计时内。我们参考这个实验方法，另外统计包含验证和收尾的完整会话时间。上游性能报告

二、技术方案

1. 选择、执行、验收，各自承担明确职责

比如 “打开提醒设置”，决策层只能选择观察到的候选。SoloPi 将候选绑定到当前节点，执行前再次检查。执行后的检查点是 “设置标题＋能量相关提醒＋接收能量可收取提醒”，不能因为模型说完成就判定通过。

本轮真机性能实验使用同一套确定性规则，不调用模型；文字和图片模型使用冻结输入另行评测。这样能看清执行器优化与模型能力各自的贡献。

2. 把浏览器的局部校验思路，落到 Android 原生控件

最关键的改造是：对适用的固定原生按钮，判断目标及其相关上下文是否变化。

以森林右上角的 “更多” 为例，能量球的动画不一定影响这个按钮。执行器检查目标身份、位置、子树、祖先、相邻及重叠节点和窗口，执行前再刷新目标，条件满足后调用一次原生点击。目标替换、移动或相关上下文改变，仍然拒绝执行。

列表、滚动容器、WebView 等结构继续使用整页校验。缺少校验证据或已经被拒绝的动作，也不能通过降级绕过去。

另外两项改造解决 “看不到” 和 “等不到”：

• 识别真实小窗口森林菜单的根节点只有 508 像素高。现在结合包名、边界、窗口类型以及 active/focused 状态确认它是应用窗口，让菜单进入正常的观察与执行流程。
• 等待已有动作的结果3 秒内页面仍未稳定时，再给予至多 5 秒观察时间，期间不重发动作。持续不稳定则失败，并保留回执。

节点同时绑定到观察时的确切树路径，减少重复文案导致的模糊重定位。执行回执记录 UI_CHANGED 或 NO_VISIBLE_CHANGE，帮助后续决策了解动作效果；业务成功仍由固定检查点判断。该反馈接口已实现，本轮没有单独量化它对模型的收益。

这项工作的创新主要在工程结合：Android 原生窗口和目标校验、候选动作约束、固定验收与完整证据链被接到同一条流程里。局部校验参考了 jev-ultrafast 的执行实现，本次完成的是面向 Android 真机回归的适配。

三、实现与使用

1. 五个场景分别验证什么

这五个场景不是一条连续用例，而是分别回答 “能否进入页面”“真机执行能否更快”“模型选得是否可靠” 三个问题：

1. 进入蚂蚁森林（真机诊断）：找到首页入口，并等到森林页面真正出现。这一步检查 “能否到达目标页”，不计入正式提速对照。
2. 打开菜单并返回（真机正式对照）：测试小弹窗和页面动画出现时，执行器能否安全完成两步操作，并在返回后通过验收。
3. 查看提醒设置并返回（真机正式对照）：连续进入设置、核对提醒内容、返回森林，用相同验收条件比较整条流程的耗时。
4. Laya 选择服务入口（电脑离线评测）：给文字模型多个真实入口，比较它与规则谁选得更准，以及没有合适入口时会不会拒答；不会点击手机。
5. 图片模型理解页面（电脑离线评测）：用真实截图测试模型能否看懂弹窗、能量球和倒计时；不会点击手机。

场景二、三测到的提速来自真机执行链路；场景四、五只评估模型能力，不能把前者的收益算到 Laya 上。

场景一：从支付宝首页进入蚂蚁森林。

首页有生活缴费、手机营业厅、蚂蚁森林等真实入口。执行器利用资源 ID、文字和可点击祖先定位森林入口，并等待跳转后的页面稳定。

图 1：支付宝首页的服务区同时有生活缴费、蚂蚁森林等入口。测试要从真实页面中找到蚂蚁森林入口。

图 2：进入蚂蚁森林后，可以看到页面标题、右上角 “更多” 和能量球。这些内容帮助确认跳转到了目标页面。

这一步验证了慢跳转处理：一次诊断的稳定观察耗时为 3.352 秒，超过原来的 3 秒预算；延长观察后得到了成功回执。它是一个修复案例，不作为成功率统计，也没有算进后面的森林往返计时。

场景二：打开菜单，再返回森林。

这条流程有两步：点击 “更多”，核对 “攻略、分享、帮助、设置” 四项；返回后确认森林标题存在、菜单消失。

图 3：点击 “更多” 后，页面弹出 “攻略、分享、帮助、设置” 菜单。执行器需要识别这个覆盖在森林上的小窗口，才能继续选择 “设置”。

这条流程同时覆盖小窗口识别、固定按钮校验和返回后的检查点。正式对照进行了 10 次，全部完成独立复验、截图和会话释放。

场景三：进入提醒设置，核对内容，再返回验收。

流程为 “更多 → 设置 → 返回森林”。检查设置标题及两项提醒文字，全程只查看，不修改开关。

图 4：提醒设置页显示 “接收能量可收取提醒” 等选项。测试核对页面标题和提醒文案；这里只查看，没有修改开关。

点击返回后还要重新采集页面，独立确认当前是森林，随后保存终态截图和结束回执。

图 5：从提醒设置返回后，再次看到蚂蚁森林首页。它是正式计时实验的一次终态截图，独立复验确认页面已返回。

场景四：让 Laya 从七类真实服务中选择。

使用图1对应的服务候选：生活缴费、余额宝、手机营业厅、蚂蚁森林、市民中心、转账、医疗健康，另提供 “没有合适选项”。问题既有直接名称，也有 “看看我的绿色能量” 这类改写，以及候选范围内无法完成的目标。

规则基线使用 “服务网格的 resourceId 与父容器范围＋精确名称”。这七项复用同一个文字节点 ID，单靠 ID 不能区分服务。模型必须面对同一候选范围；比如 “扫一扫” 虽然在首页上方可见，但不在这七项中，本题就应拒答。

共冻结 14 个目标，两种候选顺序、两种提问方式，完成 56 次本地文字推理。这些是离线选择测试，没有点击转账等金融入口。

场景五：用真实弹窗、能量球和倒计时评测图片理解。

图片能力需要回答文字树难以完整表达的问题，例如弹窗覆盖关系、图标附近的文字、能量球和倒计时的对应关系。

图 6：活动弹窗盖住了蚂蚁森林页面，中间是 “立即抽奖”，下方是关闭按钮。这张图用来测试模型能否区分弹窗和背景。

图 7：弹窗关闭后的蚂蚁森林页面同时出现能量球、文字标签和倒计时。这张图用来测试模型能否正确对应它们。

图 1—4 是不同阶段的诊断截图，图 5 是正式计时运行的终态截图；图 6、图 7 用于视觉模型评测。这些画面来自不同测试，不是一条连续操作录像。

视觉评测共使用 7 张真实截图和 18 道题。其中 15 道看图题计入视觉成绩，另 3 道执行规则题不计入。每道题交换候选答案顺序再测一次，还比较了英文提问和不提供图片时的结果。这个实验只记录模型回答，没有让模型操作手机。

2. 在自己的手机上跑真机对照

准备本分支构建的 SoloPi APK、连接电脑的 Android 真机及已登录支付宝，手动打开蚂蚁森林。电脑控制采用 host 模式，需要 ADB 和无障碍就绪，不强制要求悬浮窗或电池优化白名单。

从仓库根目录运行：

# 将占位内容替换为 adb devices 显示的设备序列号。

SOLOPI_DEVICE="你的设备序列号"

./solopi-skill/scripts/solopi-ai --serial"$SOLOPI_DEVICE" doctor

./solopi-skill/scripts/solopi-ai --serial"$SOLOPI_DEVICE" capabilities

python3 solopi-skill/scripts/harness/examples/fastpath/benchmark_forest.py \

--serial"$SOLOPI_DEVICE"\

--comparison scoped \

--pairs 5 \

--output"$HOME/.cache/solopi-forest-comparison"

capabilities 应包含 event-stable-v1 和 target-context-v1；若 doctor 仅提示 SoloPi 内部 ADB 未连接，先运行同一 CLI 的 adb-connect 再检查。结束后 ADB 保持开启。

这条命令会对菜单往返和设置往返各运行五组配对，共 20 次。基线为 legacy + full-page，优化组为 event-stable-v1 + target-context-v1，两组使用同样的选择规则和验收条件。只想研究等待策略，可改成 --comparison wait，两组都会保留整页校验。

输出目录必须尚不存在。结果包含 protocol.json、逐轮 results.json，以及每轮的动作回执、独立观察、final.png 和结束回执。先检查通过情况，再比较耗时。旧观察被拒绝后，脚本最多重新采树选择三次，相关时间全部计入；执行结果不确定时不重发动作。

3. 单独复测本地 Laya

文字环境使用 Apple Silicon 上的 MLX，与真机计时脚本分开。依赖锁定在 solopi-skill/scripts/harness/examples/fastpath/requirements-mlx-lock.txt。评测脚本需要自行准备包含页面候选和预期答案的协议 JSON；本文实验使用的协议文件没有随公开仓库发布。在已安装依赖的环境中，指定协议和本地模型目录：

SOLOPI_LAYA_MODEL="/本地路径/laya-multilingual-mlx"

SOLOPI_LAYA_PROTOCOL="/本地路径/你的评测协议.json"

python solopi-skill/scripts/harness/examples/fastpath/evaluate_laya_choices.py \

--protocol"$SOLOPI_LAYA_PROTOCOL"\

--model-path"$SOLOPI_LAYA_MODEL"\

--output"$HOME/.cache/solopi-laya-choice-evaluation"

本次使用 aac6fef/laya-multilingual-mlx，固定 revision 为 f2b4faf51023039425946074e2cf1361d2db11d5。脚本不会自动下载模型，也不会操作手机。评测协议与环境记录保存在本地实验目录，未随公开仓库发布。

视觉评测脚本是 evaluate_laya_vision.py，需要独立的社区 laya-vision PyTorch 环境、本地权重，以及含原始截图路径和哈希的协议。参数为 --protocol、--model-path、--output、--device mps；Linux GPU 可选 cuda。原始协议和逐题结果未随公开仓库发布，因此仅凭本文不能复算成绩；自行换图应建立新的协议和结果。

社区 Laya Vision 使用图片与文字做有限选项判断。本次实际加载了 thaitea/laya-vision 的约 201M 权重，并未集成进 APK。该权重标注 CC BY-NC-SA 4.0，采用前需核对使用范围。权重说明

四、收益

1. 完整真机流程确实更快，验证与截图仍然保留

实验设备为 Pixel 8 / Android 16，电脑为 Apple M3 Pro / 36 GiB。每条流程五组交替配对，共 20 次，全部通过独立复验。

交互时间包含选择、动作、通信、等待、旧观察拒绝和重新观察；完整会话额外包含初始化、独立复验、截图及释放会话。两者都从已经打开森林开始，不含启动支付宝和首次进入森林。流程检查点也不同于浏览器 Agent 的 DONE，因此不直接用绝对秒数与上游比快慢。

收益能对应到具体行为：旧观察拒绝从 6 次降到 1 次；优化组十次 “更多” 点击使用局部校验，其中 3 次整页发生变化仍完成点击并通过后续验收。菜单流程的宿主机 CLI 调用中位数从 8 次降到 6 次，设置流程从 9 次降到 7 次。这是 CLI 调用数，不是底层 ADB 或 HTTP 包数。逐轮结果和分阶段耗时保存在本地实验目录。

每条流程五对中，完整会话均为五对更快，交互时间均为四对更快、一对更慢。另一次只改变等待策略的 12 次对照全部通过，但设置交互反而慢了 11.4%。所以当前结论限定为这两条流程上的组合改造收益。等待策略的独立对照记录保存在本地实验目录。

2. Laya 推理很快，但还没有增加可放心采用的覆盖

窄问题的推理中位数为 11.67 ms，通用问题为 15.71 ms，不含模型加载和手机操作。窄问题让 Laya 答得更好，但固定门槛下仍与规则覆盖相同。这里采用最高候选概率至少 0.65、领先差至少 0.15；概率尚未经过领域校准，不能理解成对应正确率。

原始首选里有一个有价值的信号：对于 “看看我的绿色能量”“打开种树公益页面”，Laya 能选到森林，两种顺序共比规则新增 4 次正确选择；但 “收集绿色出行能量” 两次误选市民中心。门槛同时拦住了这 6 次。后续工作应是积累领域样本、改善拒答与校准，再用未见页面验证。原始输出保存在本地实验目录。

这些结果来自一个页面的重复顺序测试。本轮没有远端大模型对照，也没有测出云端费用或脚本维护工时的下降。真机表中的 24.3% 和 12.4% 来自执行器改造，不能归到 Laya 上。

3. 图片版已经实际评测，当前权重还不适合接管点击

中文配置的热推理中位数为 130.29 ms，首次推理 2.821 秒，模型加载 5.047 秒。推理耗时已经测得，但这套数据没有证明图片让回答更可靠。逐题结果与对照记录保存在本地实验目录。

这是固定社区权重在 MPS float32、默认单张 512 像素图块预处理下的探索性实验，没有微调。输入均通过不截断检查；加载器出现 pad_token_id 配置警告，预测过程没有抛错，日志与版本已保留。结论仅限于这套配置，不能推广为所有视觉模型的能力结论。

4. 可以落地的成果与后续方向

目前值得采用的是 Android 观察与执行链路改造。它解决了真实小窗口识别、无关变化引起的重复观察，以及动作发出后慢跳转的等待问题，并在两条支付宝流程上测到了包含验收的提速。

模型侧保留文字与图片评测入口，暂不默认接管回归，也暂不投入自研图片版 Laya。下一阶段的采用条件是：在更多未见页面中，增加规则无法覆盖的正确选择，同时控制错误放行。满足这个条件后，再考虑领域微调和手机部署，投入才有可验证的依据。

实现验证还包括 184 项 Android 单测、253 项 Python 定向测试。三种真实页面的固定验收器交叉检查中，三个正例通过、六个不匹配页面拒绝；它不代表已经验证金额错误或能量到账错误，本次没有执行支付或收取能量。测试记录保存在本地实验目录。

本文列出了设备条件、实验口径、汇总数据和真实截图；原始协议、逐轮数据及截图来源记录未公开，读者暂时无法独立复核这些数值。复做实验可以使用上面的公开脚本，在自己的设备上生成新的协议、逐轮结果和截图。

五、如何上手

目前 Laya 是 Apple Silicon 电脑上的可选本地决策器，不在 SoloPi APK 中运行，也不是安装 APK 后自动启用的功能。电脑上的 Harness 采集页面并生成有限的合法动作，Laya 选择候选，手机上的 SoloPi 复核并执行；测试是否通过仍由固定验收条件决定。以下命令均在 SoloPi 仓库根目录执行。

1. 准备手机和配套 APK

本地需要 JDK 11、Android SDK/adb、Python 3.12 和 Apple Silicon Mac。手机连接 USB 后，在手机上确认调试授权，安装从当前仓库构建的 SoloPi，并开启辅助功能：

./solopi-app/gradlew -p solopi-app :portal:assembleDebug

adb install-r solopi-app/portal/build/outputs/apk/debug/portal-debug.apk

adb devices

SOLOPI_DEVICE="请替换为 adb devices 显示的序列号"

./solopi-skill/scripts/solopi-ai --serial"$SOLOPI_DEVICE"--pretty doctor

doctor 会报告尚缺的设备条件；电脑端执行不强制要求悬浮窗或电池优化白名单。不要用协议版本未知的旧 APK 搭配新 Harness。若 SoloPi 内部 ADB 是唯一缺项，按 Skill 故障处理执行 adb-connect 后重新检查。

2. 安装本地 Laya

使用独立 Python 环境，下载固定版本的公开 MLX 权重。依赖和权重需要联网下载一次，运行时使用本地目录；权重不随仓库或 Skill 分发：

python3.12 -m venv "$HOME/.cache/solopi-fastpath/venv"

source"$HOME/.cache/solopi-fastpath/venv/bin/activate"

python -m pip install-r solopi-skill/scripts/harness/examples/fastpath/requirements-mlx-lock.txt

export FASTPATH_MODEL_DIR="$HOME/.cache/solopi-fastpath/laya-multilingual-mlx-f2b4faf"

hf download aac6fef/laya-multilingual-mlx \

--revision f2b4faf51023039425946074e2cf1361d2db11d5 \

--local-dir"$FASTPATH_MODEL_DIR"

test-f"$FASTPATH_MODEL_DIR/model.safetensors"

详细依赖、模型来源和实验边界见 FastPath 示例说明。非 Apple Silicon 主机目前可使用默认规则模式；不要把这套 MLX 命令当成通用 Android 端部署步骤。

3. 跑一条支付宝真机流程

先把已登录的支付宝停在首页，关闭弹窗和键盘。列出可用模板，选择 Laya 模式执行，再用命令返回的 artifacts 目录核对报告：

./solopi-skill/scripts/solopi-ai --pretty workflow-list

./solopi-skill/scripts/solopi-ai --serial"$SOLOPI_DEVICE"--pretty workflow-run \

--template alipay-more-services \

--mode laya \

--model"$FASTPATH_MODEL_DIR"

SOLOPI_ARTIFACTS="请替换为 workflow-run 返回的 artifacts 目录"

./solopi-skill/scripts/solopi-ai --pretty workflow-report \

--artifacts"$SOLOPI_ARTIFACTS"

还可选择 alipay-education（更多服务与教育公益分类）或 alipay-settings（我的与设置）。这些内置流程只浏览并返回，不支付、不提交表单、不修改设置。REPORT.md 包含整屏截图；只有工作流完成、固定验收通过且证据齐全，才应报告成功。省略 --mode laya --model ... 即使用默认规则模式，适合在同一手机与页面条件下做对照。

完整的模板说明见 内置工作流。这三条模板不能直接测试任意 App；要接入自己的业务，需编写需求和策略，使用 verify-compile → verify-validate → verify-run，入口与约束见 验证工程。当前实测只证明了执行链路在文中两条流程上的收益，没有证明启用 Laya 一定比规则更快或更准。

文章来自于"TesterHome社区"，作者 "太玄"。