ClawGUI: A Unified Framework for Training, Evaluating, and Deploying GUI Agents

1 · 动机:GUI agent 领域的碎片化危机

1.1 历史脉络

过去两年 GUI agent 这一线进展极快,但每一步都只解决了 stack 上的一个孤立环节:

• 2023–24 grounding 起步: SeeClick、UI-TARS、Aguvis、UGround 等证明 vision-language model 能直接定位 UI 元素,坐标准确率随 data/scale 涨。
• 2024–25 navigation: 模型从单步 grounding 升级到 multi-step navigation;agent 开始能"打开微信 → 点联系人 → 发消息"。
• 2025 online RL 爆发: MobileGUI-RL、ComputerRL、MAI-UI、UI-Venus-1.5、UI-TARS-2 都证明 sandbox 里跑 online RL 比 pure SFT 涨点显著。
• 2025–26 部署期初: Anthropic Computer Use、OpenClaw、Hermes Agent 把 agent 推向真实终端用户,但形态是 CLI-based harness 居多。

每一段的论文都把自己环节做到了 SOTA,但没有一篇负责让上一环和下一环对得上。结果是:

• 训练 paper (UI-TARS-2 / UI-Venus-1.5) 报 RL 结果时不发训练 infra,你想复现要自己写 emulator pool、rollout manager、reward server。
• 评测 paper (ScreenSpot-Pro / OSWorld / AndroidWorld) 提供 dataset 和 script,但不发 inference 输出 — 想 re-judge 必须重跑昂贵 inference。
• 部署系统 (Anthropic Computer Use, Claude.ai 桌面版) 闭源,研究者完全看不到 production loop 长什么样。

论文用一句话概括这种困境:"none of these works open-source their training infrastructure, and all are validated solely in virtual sandboxes" — 也就是说目前所有 RL 训练的 GUI agent 都没在真实手机上验证过。

1.2 别的方案为什么不够 — 三个 gap × 三类对手

把现存所有 GUI agent 相关工作按"覆盖了哪一段 stack"对齐到下表,空缺即 ClawGUI 要补的位置:

三个具体 gap 论文写得很清楚 (按 §1 的小标题原文翻译):

1. 训练生态封闭。 所有 online-RL GUI agent paper (UI-TARS-2 / UI-Venus / MAI-UI / ComputerRL) 都不开源 infra;开源的那部分又只能跑 emulator,real device 训练在 open literature 里"essentially unexplored"。
2. 评测严重错位。 Prompt 顺序、坐标归一化、图片分辨率、sampling temperature 任何一个变都让结果飘几个点 — ScreenSpot-Pro 上一个 2% 提升可能是真进展,可能只是换了 prompt。社区没有共享 baseline。
3. 部署回路断裂。 Train 出来的 model 几乎不会出现在真实用户的手机上。现有部署线上要么是 CLI-only (覆盖窄),要么是封闭产品 (黑盒)。

1.3 为什么这事不平凡

表面看 ClawGUI 只是"把三个轮子装到一起",听起来工程为主。但具体到 GUI 这个 domain 上,把它们捏到一起的复杂度比想象大很多:

• Environment 稳定性是核心难点,不是 RL 算法。 Android emulator 跑几小时后必然崩 (内存泄漏、ANR、容器 stale state),如果不写 spare server rotation + health check + crash recovery,RL trainer 走两个 epoch 就死。
• 真实设备没有 root,完全拿不到 system-level signal。 在 emulator 里你可以读 SQLite database 判断"消息是否发送成功",真机做不到 — 必须依赖 MLLM-as-judge 看屏幕。但 MLLM judge 不稳,需要和 system judge 一起加权才能给出可靠 reward。
• Reward 稀疏 + multi-step credit assignment. GUI 任务平均 10–30 步,一个 misclick 早期发生,episode-level GRPO 给所有步分配同样的 advantage,优化器无从分辨"哪一步坏了"。GiGPO 的 anchor-state grouping 是直接为这个 domain 设计的,但把 GiGPO 装进 production trainer + emulator + real device 同时跑,这才是 ClawGUI-RL 工程上的真正难点。
• Eval 复现率 95.8% 不是因为算法对齐,而是因为 pin 死了 prompt/resolution/temperature 等几十个开关并发布所有 inference 中间结果。 任何想 re-judge 别人结果的人,不需要重跑 inference (省 GPU),只需要重新跑 judge 阶段 — 这是 infrastructure 上的关键设计。
• Hybrid CLI-GUI 不是简单"二选一",而是 agent 在每一步动态决定走哪条。 这要求 model 既能输出 shell command 也能输出 GUI action,且要在 prompt 里同时暴露两种 capabilities。

非平凡之处是:这五条难点彼此互锁 — 你要 real-device training 必须有 MLLM judge,要 MLLM judge 必须有 dense PRM 弥补 sparsity,要 dense PRM 必须有 step-level RL (GiGPO) 才能吃下信号,而要 RL 跑得稳又必须有 spare server rotation 兜底。任何一环缺失,整个 stack 就跑不通。

2 · 背景速查

3 · 方法 · ClawGUI-RL: 训练基础设施

ClawGUI-RL 由两层构成:上层是 RL Infrastructure (Environment Manager + RL Trainer + Reward Manager),下层是 Real & Virtual Environment。两层之间是统一接口 — virtual emulator 和 real phone 在 trainer 眼里看起来完全一样。基于 verl + verl-agent 改造,支持 PPO / GRPO / GiGPO / GSPO / Reinforce++ 一族算法。

3.1 Environment Manager — 并行环境 + 真实设备

Virtual environment. 借助 MobileWorld,在单机或多机上拉起几十个 Docker-based Android emulator。论文实验配置是 64 parallel virtual environments on 8×A6000 (48GB) — 也就是平均每张 A6000 上 8 个 Android 容器。每个容器走四阶段 lifecycle:

1. Task Reset: Episode 开始,初始化设备状态 + 加载新任务
2. Task Evaluation: System-level 读 DB / app state + MLLM-as-judge 看最终屏
3. Spare Server Rotation: 主容器不健康 → 自动从空闲 queue 拉替换,resume 任务
4. Teardown: 周期性 restart,防止 state 累积

Real device training. 同一接口对接物理 Android / cloud phone。两个独有的难点:

• Task source. 真机不能 procedurally generate task — 必须人工 author 一批 representative scenario,且要保证物理设备上可执行可验证。
• Task evaluation. 真机无 root,系统级 verification 不可行 — 完全依赖 MLLM-as-judge 看最终截屏。

3.2 Reward Design — Binary + Dense

论文采用两级 reward 叠加:

• R_outcome:episode 结束时 0/1,task 成功就给 1。简单但极稀疏 — 几十步只一个非零信号。
• R_step:PRM 在每步后接收 (st-1, st, [a1...at]),输出"此步是否朝目标推进"的分数。论文用 Qwen3.5-72B 作 judge。

具体例: Task = "在微信里给妈妈发'晚饭别等我了'"。Trajectory 走 12 步,只有第 12 步发送后任务完成 → R_outcome = 1 出现在 step 12;但 step 3 (打开通讯录)、step 5 (点击妈妈头像) 也是关键正向步,GRPO 会把所有 12 步赋同一个 advantage。PRM 给 step 3 / 5 高分,给 step 7 (误点表情面板) 负分,GiGPO 借此对 step 7 单独打负 advantage,policy 学会避免这种 misclick。

3.3 RL Trainer — 为什么选 GiGPO 而非 GRPO

论文用一个非常清晰的反例论证 GRPO 不够用:同一 task 上,rollout A 4 步完成,rollout B 8 步完成。两者都成功,GRPO 给两条轨迹相同的 reward,优化器拿不到"哪条更高效"的信号。

GiGPO 的两级 advantage:

• Episode level (macro): 沿用 GRPO 的 group relative — 同一 task 的 N=8 个 rollout reward 归一化作为轨迹级 advantage,捕捉这条轨迹整体好不好。
• Step level (micro): 引入 anchor-state grouping — 跨 rollout 把"碰到相同 intermediate state (例如都停在 WhatsApp 联系人页)"的 step 聚为 sub-group,在 sub-group 内用 discounted return normalize,得到这一步在这个 state 下相对其他选择好不好的 micro advantage。

关键优点:不需要额外 value network,也不需要多跑 rollout — 用已有数据再聚一次类即可。论文报告 GiGPO 把 SR 从 14.5% 拉到 17.1%,绝对 +2.6%,相对 +17.9%。

4 · 方法 · ClawGUI-Eval: 标准化评测

4.1 三段 pipeline 解耦

ClawGUI-Eval 的核心设计哲学是"把任何配置选择 pin 死,任何中间产物开源"。具体落地为三阶段解耦:

Coverage: 6 个 benchmark — ScreenSpot-Pro、ScreenSpot-V2、UI-Vision、MMBench-GUI、OSWorld-G、AndroidControl;11+ 模型 — Qwen3-VL/2.5-VL、UI-TARS、MAI-UI、GUI-G2、UI-Venus、GUI-Owl、StepGUI、Gemini、Seed 1.8。

4.2 "95.8% reproduction" 到底意味着什么

这是论文最容易被误读的数字。看 Table 3 后定义清楚:

• 分母 = 48 cells (每个 model × benchmark 一格,只算有 official baseline 的格子)
• 分子 = 46 cells 满足"|repro − official| ≤ 2% 或 repro ≥ official"
• 失败的 2 例都是 Qwen3-VL-2B 和 UI-TARS-1.5-7B 在 SS-Pro 上 — 论文指出这两个模型的官方 eval config 没公开,所以失败基本归因于"undisclosed prompt/resolution choices"。

注意: 这个数字只针对 grounding benchmark (SS-Pro / SS-V2 / UIV / MMB / OSW-G),并不包含 navigation / interactive 任务 (如 AndroidControl、MobileWorld)。也就是说"95.8% reproduction"覆盖的是静态视觉 grounding 这件事,而 ClawGUI-2B 自己拼的 MobileWorld 17.1% 不在 reproduction 统计内。

4.3 闭源模型的 Zoom 策略

对 Gemini 3.0 Pro / Seed 1.8 这种 API-only 闭源模型,标准 inference 不可行 (无法控分辨率)。论文采用 Zoom paradigm — 一种两阶段 crop-then-ground 策略:Gemini 用 25% crop tiles,Seed 用 50% crop tiles。结果在 SS-Pro 上 Gemini 3.0 Pro 拿到 75.08 (官方 72.70),Seed 1.8 拿到 72.80 (官方 73.10),均 ≤2% 误差,reproduction 100%。

5 · 方法 · ClawGUI-Agent: 部署栈

5.1 Hybrid CLI-GUI 控制

论文最有意思的设计点:同一 agent 既能输出 shell command 也能输出 GUI 动作,每一步由 model 自主选择走哪条。设计哲学:

• CLI 优势: 一条结构化命令完成多步 UI 操作 (例如 adb shell am start -a android.intent.action.SENDTO -d "sms:..."),速度快、精确。
• CLI 劣势: 不是所有 App 暴露 programmatic interface;对用户不可见 (无法 supervise);丢失视觉 grounding 的 interpretability。
• GUI 优势: 覆盖任意 App;每步可视化、可干预。
• GUI 劣势: 一条 CLI 能完的事,GUI 可能要 5–10 步连续点击。

论文的明确立场是 "neither paradigm alone is sufficient" — agent 必须能在两种 action space 间动态路由。

5.2 Personalized Memory

Agent 在执行任务过程中自动抽取结构化事实:contact name & relationship、frequently used App、user habit/preference,以 vector embedding 存进持久库。后续任务在 system context 注入 top-k 最相似 memory。重复 memory 会被 merge 而非累积,保持库 lean。这块论文写得很简,本质上是 RAG-style external memory + dedup,设计上接近 MemoryBank/Mem0 的工程化版本。

5.3 Remote 和 Local 部署

• Remote mode: 用户从一台设备 (电脑 / 另一手机) 通过 Feishu / DingTalk / Telegram / Discord / Slack / QQ 等 12+ chat 平台发指令,server 中转到目标手机。
• Local mode: 指令直接从手机本地 chat App 发出,agent 接管同一设备 — 无需 cloud relay。

5.4 ClawGUI-Eval 作为 Skill

有意思的小设计:用户可直接发自然语言 "benchmark Qwen3-VL on ScreenSpot-Pro",agent 自动完成环境验证 → 多 GPU 并行 inference → judging → metric → 返回结构化报告。把 eval pipeline 包成 agent tool 是产品化思路,普通用户也能跑 benchmark。

6 · 完整任务跟踪 · 给 John 发 WhatsApp '明天见'

把上面三个模块串起来跟踪一个具体任务在 ClawGUI 体系下的完整生命周期:

训练时 (ClawGUI-RL 视角): 这条 6-step trajectory 会被 PRM 给每步打分 — step 3 (打开 John 对话) 因为减少了 plus 一层菜单导航而获得正分;step 4 (点输入框) 分数中性;step 6 (发送) 因接近 success 获得高分。GiGPO 在跨 N=8 个 rollout 内,把"也都进入了 John 对话窗口"的 step 3 聚为 sub-group,在 sub-group 内比较"接下来 5 步走什么 path 最高效"。

反向论证: 如果是给老板发邮件,Agent 第一步决策可能选 CLI — 因为 Android 有公开的 android.intent.action.SENDTO mailto URL,一条 adb shell am start 加 send 即可完成,无需 GUI 序列。Hybrid 路由的价值正在这种 case 体现。

7 · 实验关键结果

7.1 MobileWorld GUI-Only (Table 1) — 主结果

三个 takeaway:

1. Infra 驱动 policy 质量。 同 base weights 下,过一遍 ClawGUI-RL 涨 6.0 个绝对点 — 增益完全来自 environment management + reward 设计。
2. Small trained > Large untrained. 2B trained 打败 32B / 72B / 235B 的 untrained,RL infra 价值 > model scale。
3. Agentic frameworks 是 separate regime。 Gemini-3-Pro + grounding 助手在 55.6% — 这是闭源 + planner 的体系,不和 e2e trained 直接比。

7.2 GiGPO vs GRPO Ablation (Table 2)

+2.6% 绝对,+17.9% 相对。这是论文最干净的 ablation,验证 dense step-level credit 在 long-horizon GUI 任务上是必要的。

7.3 ClawGUI-Eval Reproduction (Table 3 节选)

选几个有代表性的格子:

两个失败 case 都集中在"官方未公开 eval config"的模型上 — 这恰好印证作者主张:差异不是算法问题,是 infrastructure 问题。

8 · 开源到底放了什么 — repo 实地清点

纸面声明"three components 全部 open-source"很容易,实际验证要看 repo。我去 github.com/ZJU-REAL/ClawGUI(注意是浙大 REAL 组,不是 Kilo)拉了完整目录结构。

8.0 仓库基本信息

8.1 顶层结构 — 实际是 4 个模块,不是 3 个

Paper 说"three modules",但 repo 实际有 4 个。第 4 个 clawgui-app(Android 应用)是 paper 之后新加的。

ClawGUI/
├── clawgui-rl/       # 训练 — 我精读 §3 讲的就是这个
├── clawgui-eval/     # 评测 — §4
├── clawgui-agent/    # 部署 — §5
├── clawgui-app/      # 📱 Android on-device 应用(NEW,paper 没提)
├── assets/           # 图、logo
├── LICENSE           # Apache 2.0
├── CONTRIBUTING.md   # 8 KB
├── README.md / README_zh.md
└── .github/

8.2 模块 1:clawgui-rl/ — 训练 infra

关键事实(从 README 读出):

• 基于 verl (Ray single-controller + FSDP) + vLLM hybrid engine(rollout / training 共享显存)
• 支持的策略模型: MAI-UI 和 GUI-Owl 开箱即用,Qwen3-VL 系列要自己接
• DAPO 风格 dynamic sampling — 过滤掉全对/全错的 group,只对有梯度信号的 group 反传
• 支持 parallel Docker 模拟器 或 real Android 设备(同一 API)
• Spare server rotation + 自动 retry → 长训练不崩
• 所有 episode 存 episode/,可视化回放

8.3 模块 2:clawgui-eval/ — 评测 pipeline

数据集(开源):

• HuggingFace: johnzqlu/clawgui-eval
• ModelScope: Matrix0602/clawgui-eval
• 包含 6 个 benchmark: ScreenSpot-Pro / ScreenSpot-V2 / UIVision / MMBench-GUI / OSWorld-G / AndroidControl
• 支持 12+ 模型: Qwen3-VL · Qwen2.5-VL · UI-TARS · MAI-UI · GUI-G2 · UI-Venus · Gemini · Seed 1.8 · Kimi K2.5 ...

关键发现:支持 local GPU (transformers) 和 remote OpenAI-compatible API 两种推理后端 — 这意味着自托管 vLLM/SGLang 服务可以直接接入跑 eval,跟 PinchBench 思路一致。多 GPU 多进程并行,每进程 pin 一个 GPU。

Zoom paradigm 是 paper 没明说但代码里的细节:

• Gemini 3.0 Pro: 25% crop tiles,2-stage crop-then-ground
• Seed 1.8: 50% crop tiles
• 这是为了在 ScreenSpot-Pro 这种高分辨率(4K+)task 上让闭源模型也能复现官方数字

8.4 模块 3:clawgui-agent/ — 部署到手机

支撑栈(全部 third-party,ClawGUI 只做集成):

• 底层 agent harness: OpenClaw(Kilo 的)
• chat 平台桥: nanobot(港大 HKUDS)
• iOS 控制: 接 WebDriverAgent 之类的现成库
• Android 控制: 走 ADB / Shizuku
• 支持的聊天平台: Feishu / DingTalk / Telegram / Discord / Slack / QQ + 其他

8.5 模块 4:clawgui-app/ — 📱 on-device Android app(NEW)

这是 paper 没提的新模块,2026 年 4 月之后加的。一个完整的 Kotlin Android app(build.gradle.kts + app/ + Shizuku 集成),把 brain + GUI agent 整套塞进一部手机:

8.6 Docker 与模拟器 — 训练环境到底"全开"吗?

这是用户最关心的一块。下面把整条链路按"三仓库 / 五镜像 / 实际依赖"拆给清楚,所有内容都是从 GitHub Contents API 直接拉的原文。

📦 8.6.1 三个仓库的角色

🐳 8.6.2 五张 Docker 镜像各自是什么

⚙️ 8.6.3 评测镜像 clawgui-eval 原文(完整)

FROM pytorch/pytorch:2.6.0-cuda12.4-cudnn9-devel

# system packages
RUN apt-get update && apt-get install -y --no-install-recommends \
    git wget unzip build-essential ninja-build libgl1

WORKDIR /workspace
COPY . clawgui-eval/
WORKDIR /workspace/clawgui-eval

RUN pip install --no-cache-dir -r requirements.txt
RUN pip install --no-cache-dir --no-build-isolation flash-attn==2.8.1
RUN pip install --no-cache-dir -e .

CMD ["python", "main.py", "--help"]

requirements.txt 完整内容(只有 8 个核心包,极其干净):

torch>=2.8.0
transformers>=4.57.0
qwen-vl-utils>=0.0.14
openai>=2.9.0
pillow>=12.0.0
tqdm>=4.67.0
numpy>=2.2.0
accelerate>=1.12.0
# optional: flash-attn>=2.8.1, vllm>=0.11.0

docker-compose.yml 关键挂载:

volumes:
  - ${DATA_DIR:-./data}:/workspace/clawgui-eval/data       # benchmark 数据
  - ${IMAGE_DIR:-./image}:/workspace/clawgui-eval/image    # 截图素材
  - ${OUTPUT_DIR:-./output}:/workspace/clawgui-eval/output # 评测输出
  - ${MODEL_DIR:-/tmp/models}:/models                      # 本地模型权重
ipc: host          # torch multiprocessing spawn 需要
ulimits.memlock: -1
deploy.resources.reservations.devices: [{ driver: nvidia, count: all }]

这一块的开源度:

• ✅ base image 公开(pytorch/pytorch:*-devel)
• ✅ 依赖少且明确(8 个核心包,版本下限锁死,没有上限锁,易跨版本)
• ✅ 数据集公开:HuggingFace johnzqlu/clawgui-eval / ModelScope Matrix0602/clawgui-eval
• ✅ 可复现度 ≈ PinchBench 的 self-hosted 模式:一份 Dockerfile + 一份 compose 文件 + 一个 HuggingFace 数据集 ID,就够了

🔧 8.6.4 训练 Trainer 镜像 clawgui-rl/docker/ — 9 个变体

主力镜像 Dockerfile.vllm.sglang.megatron 的关键栈(原文摘录):

FROM nvcr.io/nvidia/pytorch:24.08-py3
ENV MAX_JOBS=32 VLLM_WORKER_MULTIPROC_METHOD=spawn HF_HUB_ENABLE_HF_TRANSFER=1

# 清掉 NV 自带 fork 版本
RUN pip uninstall -y torch torchvision torchaudio \
    pytorch-quantization pytorch-triton torch-tensorrt \
    xgboost transformer_engine flash_attn apex megatron-core grpcio

# 装公网版本
RUN pip install "sglang[all]==0.4.6.post5" --find-links https://flashinfer.ai/whl/cu124/torch2.6/flashinfer-python
RUN pip install "vllm==0.8.5.post1" "torch==2.6.0" "torchvision==0.21.0" "tensordict==0.6.2"
RUN pip install "transformers[hf_xet]>=4.51.0" accelerate datasets peft hf-transfer \
    ray[default] codetiming hydra-core qwen-vl-utils wandb dill liger-kernel ...
RUN wget .../flash_attn-2.7.4.post1+cu12torch2.6cxx11abiFALSE-...whl && pip install ...

对应 requirements.txt 列出 development 全集(全部 PyPI 公开包):

accelerate, codetiming, datasets, dill, flash-attn, hydra-core,
liger-kernel, numpy, pandas, peft, pyarrow>=19.0.0, pybind11,
pylatexenc, pre-commit, ray[default], tensordict<=0.6.2, torchdata,
transformers==4.51.1, wandb, packaging>=20.0, uvicorn, fastapi,
qwen-vl-utils[decord], openpyxl

注意:9 份 Dockerfile 都是从 verl 上游继承的原版(setup.py 头部还写着 Copyright 2024 Bytedance Ltd.),ClawGUI 没改 trainer 容器本身,所有改动都在 agent_system/ Python 代码层。

📱 8.6.5 Android 模拟器镜像 — 真正复杂的一块

训练时,clawgui-rl/agent_system/environments/env_package/mobileworld/envs.py 里 MobileWorldWorker(Ray Actor)走 HTTP 连到一组 backend URL,默认从 examples/env_server/mobileworld_server.txt 读:

# mobileworld_server.txt 长这样
http://127.0.0.1:7000
http://127.0.0.1:7001
http://127.0.0.1:7002
...

每个 URL 对应一个独立的 emulator 容器。容器的 Dockerfile(ClawGUI-Server/docker/Dockerfile)摘要:

FROM cruizba/ubuntu-dind:latest    # Docker-in-Docker 基底
ENV ANDROID_SDK_ROOT=/opt/android-sdk

RUN apt-get install -y openjdk-17-jdk scrcpy python3 python3-pip \
    ffmpeg xvfb x11vnc openbox novnc websockify socat
RUN pip install uv

# 装 Android SDK + emulator + Pixel_8 API 34 系统镜像
RUN cd /opt/android-sdk/cmdline-tools && \
    wget commandlinetools-linux-13114758_latest.zip ... && \
    sdkmanager "platform-tools" "build-tools;34.0.0" \
               "platforms;android-34" "system-images;android-34;google_apis;x86_64"

# AVD 配置 + adb key + 启动脚本
COPY docker/Pixel_8_API_34_x86_64.avd /root/.android/avd/.../
COPY docker/adbkey docker/adbkey.pub /root/.android/
COPY docker/start_emulator.sh docker/start_novnc.sh /app/docker/

# 应用后端预打包
COPY docker/mattermost-docker /app/mattermost-docker-bk
COPY docker/mastodon-docker /app/mastodon-docker-bk
COPY docker/images /app/images        # 预打包应用镜像 tar

HEALTHCHECK CMD curl -f http://localhost:6800/health || exit 1
ENTRYPOINT ["entrypoint.sh"]

entrypoint.sh 启动顺序:

1. sysctl net.ipv6.conf.all.disable_ipv6=1(否则模拟器 SIM 卡禁用)
2. start-docker.sh 启 inner Docker daemon
3. docker load -i 把 Mattermost/Mastodon tar 包载入
4. start_emulator.sh 启动 Android 模拟器(emulator -avd Pixel_8_API_34_x86_64 -no-window -no-audio -no-snapshot -gpu swiftshader_indirect)
5. socat TCP-LISTEN:5556 ... TCP:127.0.0.1:5555 把 ADB 暴露到 0.0.0.0
6. uv run mobile-world server --port 6800 启 API server

每容器对外暴露的端口(用 ClawGUI-Server 的 mw env run 自动分配):

开源状态:

• ✅ Dockerfile 全开,基于公开 cruizba/ubuntu-dind,Android SDK 都是 dl.google.com 公网下载
• ✅ 镜像 ghcr.io/tongyi-mai/mobile_world:latest 公开可 docker pull(GHCR 不限速)
• ⚠ ClawGUI-Server 仓库本身没有 LICENSE 文件(4 stars,作者 sugarandgugu)— 严格说"公开但未明示授权",但上游 MobileWorld 是 Apache 2.0,所以镜像本身用法没法律问题
• ⚠ start_emulator.sh 里硬编了一个 内部代理 PROXY_HOST=10.130.138.46:7897 — 这是浙大 REAL 实验室内网地址,自托管时必须 export PROXY_HOST=none 把它关掉
• ⚠ .env.example 要求填 DASHSCOPE_API_KEY / MODELSCOPE_API_KEY / USER_AGENT_API_KEY(分别给 MCP task 和 user-agent 交互 task 用)— 没这些 key 跑不了完整 task 集

🚀 8.6.6 从 0 到训练跑起来 — 完整命令序列

# Step 1. 准备 emulator 池(在专门的物理机或带嵌套虚拟化的机器)
git clone https://github.com/sugarandgugu/ClawGUI-Server && cd ClawGUI-Server
uv sync
cp .env.example .env && vim .env    # 填 API key
sudo uv run mw env check            # 检查 Docker / KVM / .env
docker pull ghcr.io/tongyi-mai/mobile_world:latest

sudo uv run mw env run \
    --count 16 \                    # 起 16 个并行容器
    --backend-start-port 7000 \
    --viewer-start-port 8000 \
    --vnc-start-port 5900 \
    --adb-start-port 5600 \
    --launch-interval 3

# Step 2. 把 16 个 URL 写进 trainer 配置
cd /path/to/ClawGUI/clawgui-rl
cat > examples/env_server/mobileworld_server.txt <

训练脚本 run_mobileworld.sh 的核心参数(直接从仓库拉的):
model_path=/models/GUI-Owl-1.5-2B-Instruct
group_size=4
train_data_size=1
total_epochs=3
adv_estimator=grpo
server_file=../env_server/mobileworld_server.txt

# 用 verl 主程序跑
python3 -m verl.trainer.main_ppo \
    algorithm.adv_estimator=$adv_estimator \
    actor_rollout_ref.rollout.name=vllm \
    actor_rollout_ref.rollout.gpu_memory_utilization=0.65 \
    ...



容器数下限规则(README 明写):

容器数 ≥ train_batch_size × group_size;以上面默认 1 × 4 = 4 为最小,但作者强烈建议额外加 50%+ spare(虚拟容器常 OOM / 截图失败 / ADB 卡死,trainer 会自动 rotate 到备用 URL)。

论文实验用的是 train_batch_size=4 × group_size=4 = 16,加 spare 推荐 24 个容器。


📊 8.6.7 开源度总评 — 三个维度


维度
评分
说明

代码开源
★★★★★
所有 Dockerfile、训练脚本、eval pipeline、agent harness、模型权重(ClawGUI-2B)全部开源,Apache 2.0(主仓)
评测可复现
★★★★★
评测 Docker 一行 docker compose up,数据公开,12+ 模型 adapter 现成,本机一卡能跑;和 PinchBench self-hosted 模式同级
训练可复现
★★★☆☆
代码全开,但硬件门槛非常高:GPU 4-8 卡 + 同时要 16-24 个能开 KVM + privileged 的容器(每个吃 4-6 GB RAM,1 个 vCPU);普通云 GPU 实例(非 bare-metal)很多开不了嵌套虚拟化,所以训练可复现度被硬件卡住,不是被代码卡住
真机训练可复现
★★☆☆☆
代码全开 + 验证过两台 Android,但需要 USB 直连或云手机服务,scale 起来要解决登录验证 / 设备管理 / IP 池等工程问题,作者也承认是"notoriously challenging"



一句话总结:评测环境是真正"开箱即用"级别的开源,Apache 2.0 + 公开数据 + 一行启动;训练环境代码也全开,但 Android 模拟器要走另一个 repo(sugarandgugu/ClawGUI-Server)拉公开 GHCR 镜像,而且要凑 16-24 个 privileged + KVM 容器,这是工程门槛,不是开源门槛。

8.7 模型 — ClawGUI-2B

训练好的 2B 模型权重开源:

  
HuggingFace: SugarVapeur/OpenGUI-2B(注意 repo 名是 "OpenGUI",不是 "ClawGUI" — README 里叫 ClawGUI-2B,这是早期项目改名的痕迹)
  
ModelScope: SugarFree/OpenGUI-2B
  
BF16 / safetensors / Apache 2.0 / 基于 Qwen3-VL 架构
  
结果: MobileWorld GUI-Only Success Rate = 17.1%(同尺寸 MAI-UI-2B baseline 11.1%,+6.0)



⚠ 没开源的: 训练用的数据集(只 release 了 eval 数据集);PRM judger (Qwen3.5-72B) 的具体 prompt / fine-tune 数据;训练 ClawGUI-2B 用的 reward 设计完整 yaml(部分见 recipe/ 但不完整);72B PRM 跑了多少 token 量 / GPU 时长。


8.8 ClawGUI = "原创 + 工程集成"占比拆解

整个 stack 大致 30% 原创 + 70% 集成上游开源工作。诚实拆解:


组件
来源
原创度

RL trainer 底座
verl (字节 HybridFlow)
0% — 直接用
GiGPO 算法
langfengq/verl-agent
0% — 直接用
vLLM hybrid engine
vLLM 项目
0%
Agent harness
OpenClaw (Kilo)
0%
Chat 平台桥
nanobot (HKUDS)
0%
Android 控制
Shizuku (RikkaApps)
0%
Eval 6 benchmark
各自社区
0% — 数据来自原 benchmark
Android 模拟器 Docker pool 编排
ClawGUI
~80%
Eval 三段 pipeline + 12+ 模型 adapter
ClawGUI
~90%
Zoom paradigm(Gemini/Seed 大模型评测)
ClawGUI
100%
ClawGUI-2B model weights
ClawGUI(用上面 infra 训出来)
100%
clawgui-app 双 agent Android
ClawGUI
~90%



这不是贬义。**ClawGUI 的真实贡献是"做对了胶水层"** — 把碎片化的 verl / OpenClaw / Shizuku / 6 benchmark 整合成一个可复现的全栈方案,这件事比单独训个 SOTA 模型还有用,因为它降低了整个 GUI agent 社区的入门门槛。

8.9 平台覆盖 — ClawGUI 到底支持什么 OS?

从主仓 README 逐字核对的事实表(很多人会以为是"全平台",其实训练只覆盖 Android):


模块
Android
HarmonyOS
iOS
Windows
macOS
Linux
Web

ClawGUI-RL(训练)
✅
❌
❌
❌
❌
❌
❌
ClawGUI-Eval(评测)
✅
❌
❌
间接*
间接*
间接*
❌
ClawGUI-Agent(部署 harness)
✅ ADB
✅ HDC
✅ XCTest
❌
❌
❌
❌
ClawGUI-APP(on-device)
✅ Shizuku
❌
❌
❌
❌
❌
❌


* "间接"指 OSWorld-G 是 OSWorld(Ubuntu/Win/macOS)的 grounding 子集,但只用静态截图,不涉及真实 OS 操作。

主 README 自己列的 Roadmap 也承认:
- [x] ClawGUI-RL  (Android 移动训练)
- [x] ClawGUI-2B  (训练好的模型权重)
- [x] On-device ClawGUI-APP
- [ ] Desktop Online RL — 扩展到桌面 OS,还没做
- [ ] Web Online RL — 扩展到浏览器,还没做


关键澄清:iOS 只在 部署 harness 里出现 — 你能让一个已经训好的 GUI agent 通过 XCTest 控制 iPhone,但仓库里没有任何 iOS 训练代码、iOS benchmark、iOS reward 设计。这是因为 iOS 不允许批量启 emulator 容器,生态封闭。


8.10 缺口对应的相关 paper 与开源 repo

下面把 ClawGUI 暂时不覆盖的几块 — 桌面 / Web / iOS — 各自的当前 SOTA 列清楚。

🖥️ 桌面 GUI Agent(Windows / macOS / Linux)


名字
平台
能力
开源
定位

OSWorld 
NeurIPS 2024 · 2404.07972 · xlang-ai/OSWorld
Ubuntu / Win / macOS
369 个真实 task,docker-based VM,可执行评测
✅
桌面 benchmark 事实标准。OSWorld-Verified(2025)修正后 SOTA 已 ~84% of human(原版只有 12.24% vs human 72.36%)
Windows Agent Arena
2024 · 2409.08264 · microsoft/WindowsAgentArena
Windows-only
154 task(浏览器/文档/视频/代码/Notepad/Paint/Settings),Azure 并行
✅
Microsoft 官方,SOTA 19.5% vs human 74.5%,云上一次跑完几分钟
UI-TARS-2
2025-09 · 2509.02544 · bytedance/UI-TARS + UI-TARS-desktop
桌面 + Web + 移动 + 游戏 + Code
多轮 RL (RLVR) + data flywheel + hybrid 沙箱,文件系统 + 终端集成
✅ 权重 + harness
最接近 ClawGUI 但全平台的全栈方案,字节跳动,SOTA。一句话:"ClawGUI 想做但还没做的桌面 RL 版,UI-TARS-2 已经做完了"
Agent-S2
2025 · simular-ai/Agent-S
macOS + Win + Linux
Mixture of Grounding + Proactive Hierarchical Planning(模块化框架,非 RL)
✅
OSWorld 上超 OpenAI CUA/Operator 和 Claude 3.7 Computer Use
Hermes Agent
2026-02 · Nous Research
Linux / macOS / WSL2
自改进 agent,持久记忆,一行 curl 安装
✅
偏部署而非训练,补 macOS 桌面助手生态
Claude / Gemini Computer Use
桌面
商业 API
闭源
对比 baseline,不能自训



🌐 Web GUI Agent


名字
类型
开源
说明

WebArena / VisualWebArena
web-arena-x/webarena
Benchmark + 自托管站点
✅
5 个自托管站点(电商/论坛/CMS/...),事实 web benchmark
BrowserGym + AgentLab
servicenow/BrowserGym
Gym-style 包装
✅
ServiceNow 维护,把 MiniWoB / WorkArena / WebArena / VisualWebArena 统一到一个 API,带并行实验
WebAgent-R1
2505.16421
端到端多轮 RL trainer
✅
WebArena-Lite,二值 reward;Qwen-2.5-3B 6.1 → 33.9%,Llama-3.1-8B 8.5 → 44.8%。这是 web 上的 GiGPO 等价物
WEBLICA
2605.06761
scalable web env 合成
✅
HTTP cache + LLM 自动合成 web 站点,几千个并行 env
Go-Browse
2506.03533
结构化探索训练
✅
训 web agent 的探索策略



📱 iOS 训练 — 一个明显的空白领域

iOS 因为生态封闭(没有像 Android emulator 那样的 KVM 镜像可以批量起几十个),到 2026 年 5 月没有公开的 iOS RL 训练 repo。能找到的相关工作:


ClawGUI-Agent 通过 XCTest 接 iPhone — 只能 deploy 不能 train
Apple ML Research 发了 Reinforcement Learning for Long-Horizon Interactive LLM Agents(machinelearning.apple.com),但不针对 iOS UI,是通用长程 agent RL
UINavBench(ICCV 2025)— 主要 Android,iOS 子集小
实际生产:研究界用 iOS 一般走 云手机服务(BrowserStack / Sauce Labs / Appium)+ XCUITest,没有专门 iOS RL trainer
潜在原因:Apple 限制 IPA 注入和 emulator 镜像分发,做 100 容器并行训练在法律和工程上都难


🎯 跨平台一锅端 — 真正的 "all-OS" RL 方案


方案
覆盖
方法

UI-TARS-2(ByteDance)
桌面 + Web + 移动 + 游戏 + Code(无 iOS)
多轮 RLVR + hybrid 沙箱 + data flywheel — 目前最完整的开源跨平台 RL trainer
RLAnything / Open-AgentRL(Gen-Verse, ICML 2026,见 #13 精读)
Terminal + GUI + SWE + Tool-call(GUI 部分主要是 OSWorld)
"闭环优化"框架,env / policy / reward 三件套都用 RL 协同训
AgentGym-RL(见 #06 精读)
WebArena / BabyAI / SciWorld / TextCraft / SearchQA / TextWorld(没有移动 / 桌面 GUI)
ScalingInter-RL,通用 agent RL framework,GUI 只占 Web 一块




结论:如果你想做的是移动端 + 真机 + 在线 RL,ClawGUI 是当前最完整的开源方案;如果你想做桌面 / Web 的 RL 训练,首选 UI-TARS-2(桌面+Web+移动一锅端)和 WebAgent-R1(纯 Web RL);如果你想做评测 only,桌面用 OSWorld,Windows-only 用 WAA;iOS 训练目前没有开源方案,只能走云手机 + deploy harness 这条路。


8.11 Roadmap (paper / repo 上标 coming soon)


  
Desktop Online RL — 扩展到桌面 OS,不只是手机
  
Web Online RL — 浏览器 task
  
Real-time RL — 当前是 offline batch,目标 on-the-fly 更新
  
Learned routing for hybrid CLI-GUI — paper §5 Discussion 明示当前是 prompt-driven,未来要用 RL 学




9 · 与同类工作对比


系统
定位
train
eval
deploy
开源
real device

AgentGym-RL (2509.08755)
通用 agent RL trainer
✓
×
×
✓
无 GUI 专项
verl / verl-agent
RL backend 库
✓
×
×
✓
无
OSWorld / AndroidWorld
交互式 benchmark
×
✓
×
✓
—
ScreenSpot-Pro / MMBench-GUI
静态 grounding benchmark
×
✓
×
✓
—
UI-TARS-2 / UI-Venus-1.5
RL-trained GUI 模型
报数字
×
×
weights
×
MAI-UI / MobileGUI-RL
RL-trained GUI 模型
报数字
×
×
weights
×
Anthropic Computer Use / Claude.ai
商业部署产品
× (闭)
× (闭)
✓
闭源
不公开
OpenClaw / Hermes Agent
CLI agent harness
×
×
✓ (CLI only)
✓
×
Agent S / MobileAgent
研究 demo 部署
×
limited
demo
✓
×
ClawGUI
full-stack
✓ + real device
✓ 95.8%
✓ Android/HarmonyOS/iOS
✓
✓



从这张表能清楚看到 — 在它之前,三列同时打勾的开源系统就是没有过。这是 ClawGUI 的核心 contribution。



10 · 局限 / 个人 take / 待验证

9.1 局限和注意点


  
+6.0% 是 framework 的功劳还是 recipe 的功劳? 这是最重要的疑问。MAI-UI-2B (baseline) → ClawGUI-2B (本文) 走的不只是同一份 RL infra,还有不同的 data、PRM judger、reward 设计组合。论文没分离"infra 自身贡献"和"具体训练 recipe (Qwen3.5-72B PRM + GiGPO + 64-env scale) 贡献"。Table 2 那 +2.6% 是 GiGPO vs GRPO 的纯算法 ablation,但还有其他变量没做 ablation。
  
"95.8% reproduction" 只覆盖 grounding,navigation 没统计。 6 个 benchmark 里 5 个是 grounding (SS-Pro / SS-V2 / UIV / MMB / OSW-G),AndroidControl 这个 navigation 的 reproduction 数字没单独报。MobileWorld 也不在统计内。
  
Hybrid CLI-GUI 的路由策略是怎么学的? 论文说"learns the routing policy itself from interaction data"是未来方向,意味着当前版本的路由还是 prompt-driven 或规则化。这部分细节论文交代得比较粗,需要看 GitHub 实际实现。
  
Real device training 的 scale 没说清。 论文反复强调"first open-source with real device support",但训练 ClawGUI-2B 实际用的是 64 parallel virtual environments,真机训练具体跑了多少 task / step / 性能多少没单独 ablate。论文似乎主要是"basic infra works on real device",而不是"用 real device 拿到比 virtual 更好的 policy"。
  
PRM 用 Qwen3.5-72B 是巨大开销。 训练一个 2B agent 时,judge 用 72B model — 这意味 PRM 推理 cost 远大于 policy 训练 cost。在更大规模 training 时 PRM 是否能换成更小的专用 judger 是个工程问题。
  
Personalized memory 是工程化 RAG,不是论文级贡献。 这块论文写得简,基本对齐 Mem0 的工程实践,没新方法。


9.2 个人 take

这是一篇典型的 infrastructure paper。它的价值不在于发明了新算法 (GiGPO 是引用 Feng et al. 2025b 的现成算法,PRM 是 prevalent),而在于把领域里至少 3 条孤立 line 的工作拧成一条流水线并开源。这种 paper 的影响力短期看不出来,长期看是否成为 community standard 取决于:


  
会不会有第二批 paper 真的用 ClawGUI-RL 训 model (而不是各家重新写自己的 trainer)?
  
ClawGUI-Eval 会不会成为 GUI agent paper 的事实评测 baseline?例如以后 paper 在 SS-Pro 上报数字必须附上"由 ClawGUI-Eval 评测"作为可比性 anchor。
  
Hybrid CLI-GUI 这条路由是否会被后续 RL 训出来 — 这才是真正"new science",当前版本只是 prompt-driven。


给类比的话,ClawGUI 之于 GUI agent ≈ vLLM 之于 LLM serving — 单看不出 algorithmic 突破,但如果它真的成为默认 stack,那整个研究范式都会受益。

9.3 待验证问题清单


  
把同样 GiGPO + Qwen3.5-72B PRM 接到别人的 trainer (verl 原版) 上,能不能复现 17.1%?如果能 → infra 价值有限,真正是 recipe;如果不能 → infra 价值大,论文成立。
  
Real-device-only training vs virtual-only training,在 holdout real device tasks 上的 generalization gap 多大?这是论文标榜 real device support 的核心 motivation,但没正面 ablate。
  
PRM (Qwen3.5-72B) 替换成 7B / 2B model,SR 会掉多少?PRM 是不是 free lunch,还是要在 judge 质量上付出 huge cost?
  
ClawGUI-Eval 的 95.8% 是否会随着 community 提交新模型而漂移?有没有 leaderboard CI/CD 机制?
  
Hybrid 路由当前是怎么实现的?Prompt 给两个 action space,model 自由选?有没有 reward shaping 偏向 CLI?
  
12+ chat 平台 + 3 OS 部署,真实用户量级有多大?有没有 production usage statistics 验证 personalized memory 的实际收益?




11 · 记忆点 (cold recall)

立场 Full-stack open-source GUI agent harness:第一个把"RL 训练 + 标准化评测 + 真实设备部署"开源捏在一起,且 RL trainer 支持真实手机训练。

关键数字 ClawGUI-2B 在 MobileWorld GUI-Only 17.1%,比同尺寸 MAI-UI-2B baseline +6.0 绝对点,超过 UI-Venus-72B (16.4%) 和 Qwen3-VL-235B (12.8%)。

算法核心 GiGPO + PRM 双层 reward: macro 沿用 GRPO 的轨迹级 group relative,micro 用 anchor-state grouping 对相同 intermediate state 的 step 聚类算局部 advantage;PRM (Qwen3.5-72B) 给每步打分弥补 outcome 的稀疏。Ablation: GiGPO 比 GRPO +2.6%。

Eval 95.8% reproduction = 46/48 cells (5 个 grounding benchmark × 11+ 模型) 误差 ≤2% 或超过 official。失败 2 例都因官方未公开 eval config。闭源模型走 Zoom paradigm (crop-then-ground)。

Infra 64 parallel Docker Android emulator on 8×A6000;Environment Manager 实现 spare server rotation + health check + crash recovery;同一接口支持真机/ADB/cloud phone。Trainer 基于 verl + verl-agent。

Deploy Hybrid CLI-GUI 决策: 能 CLI 就 CLI (快),否则 GUI fallback (覆盖广)。12+ chat platform (Feishu/DingTalk/Telegram/Slack/...) 接入 Android/HarmonyOS/iOS。Personalized memory 持久化 contact/preference,vector store + top-k retrieval + dedup。

Eval 也是 skill 用户直接发"benchmark Qwen3-VL on ScreenSpot-Pro",agent 自动跑完 infer→judge→metric 返回报告。

主要风险 +6.0% 没分离 "framework 自身价值" vs "具体 recipe (PRM + GiGPO + scale) 价值";real-device training 的 ablation 不充分;PRM 用 72B judge,cost 不平凡。

类比 之于 GUI agent ≈ vLLM 之于 LLM serving:不是算法 paper,但若成为 community default 则范式级影响。