ScaleWoB：通过大规模环境合成引导 GUI 智能体的代码智能体框架 SimuWoB: Simulating Real-World Mobile Apps for Fast and Faithful GUI Agent Benchmarking
用代码智能体从自然语言生成可验证的 GUI 评测环境。
前置知识
GUI 智能体 (GUI Agent)
基于大语言模型或视觉语言模型的自主系统，给定任务后能观察当前屏幕、推理任务状态、逐步执行动作（如点击、滑动、输入），并借助环境反馈直到任务完成。本文评测的就是这类系统，包括 UI-TARS-1.5、Gemini 3 Pro、seed-1.8 等。
ScaleWoB 的整个目标是评测和训练 GUI 智能体，不理解其「观察-推理-动作-反馈」循环就无法理解作者为什么要构造可重置、可验证的合成环境。
可验证奖励 (Verifiable Reward)
在强化学习或评测语境中指可通过确定性检查判定任务完成度的信号。ScaleWoB 把 reward 写成一个 JS 函数 $R(s, a, \text{json}) \to \{0,1\}$，能直接读取环境状态 $s$ 判断是否达成任务目标，比 LLM-as-Judge 更稳定也更便宜。
本文反复强调真实环境「难以构造可验证奖励」，这是合成环境的根本动机之一；理解 reward 的可执行性才能体会为何把 reward 也作为代码一起生成是关键技术。
代码智能体 / 代码生成 LLM (Coding Agent)
能够根据自然语言指令生成、修改、调试可执行代码的大语言模型，本文使用 Gemini 和 Claude 作为 PRD 生成、页面结构搭建、自审反思循环的核心。代码智能体在本文里既是工头也是工人，负责把应用需求转化为可运行的网页。
ScaleWoB 的方法本质是把环境构造转化为代码生成问题。理解「用 LLM 写代码、再自审、再迭代」这一闭环是看懂整个两阶段 pipeline 的前提。
人机交互循环 (Human-in-the-Loop Verification)
指在自动生成流水线中加入人工审核环节，对失败样例做根因诊断并把修复信号反馈回生成器。ScaleWoB 让验证智能体跑一遍任务，失败的轨迹交给人类专家判定是智能体行为问题还是环境缺陷，后者才回流修复。
代码生成 LLM 不可能 100% 可靠，作者为此专门设计了一整套 issue inspection and correction workflow，是论文方法里非常关键、但常被忽视的工程保障。
长时序任务 (Long-Horizon Task)
指需要 20 步以上交互、涉及多页面跳转、中间信息需要主动记忆与跨步复用的任务。在 ScaleWoB 中这类任务的平均步数约 24.73，最长超过 50 步，是对当前 GUI 智能体最大的能力考验维度。
论文把任务分成 simple / long-horizon / math-related 三类，并发现所有模型在 long-horizon 子集上 SR 平均仅 17.82%，这是论文最重要的失败模式分析之一。
研究动机
基于 LLM/VLM 的 GUI 智能体近年来进展迅速，但它们的评测与训练仍严重受制于真实环境的两个根本难题。其一是可验证奖励难以构造：真实 App 内部状态常常不可见，业界普遍依赖 LLM-as-Judge（[14, 30-32]），既引入不稳定性和额外 API 成本，又只能给近似分；或者只挑开源 App、文件操作类任务、模式匹配任务（[18-20, 23, 25, 33]），导致评测覆盖面远小于真实使用场景。其二是状态管理与重置几乎不可能：真实应用状态随时变化（如支付、删除、信息流刷新），必须靠 emulator/VM/Docker 快照才能重置（[19, 20, 23, 34]），系统复杂度高、并发能力差、慢得无法支撑大规模评测与在线 RL 训练。叠加之后，现有移动 GUI 基准存在两条明显短板：要么任务过短、覆盖面窄（多数基准只覆盖 30% 左右的 Google Play 类目），要么奖励设计粗糙、对真实工作流的还原度低，而真实用户体验到的恰恰是几十步、跨页面、要记忆、要算账的复杂任务。
本文的目标是本文目标是把环境构造本身当成代码生成问题来解决，提出 ScaleWoB 框架：用代码智能体从自然语言任务描述（含可选截图）出发，自动合成可执行的、URL 可访问的、零后端的网页版应用环境，并为每个任务自动构造可执行 reward validator。在该框架基础上，作者希望同时达成三个具体目标：（1）覆盖足够多样——发布 63 个模拟移动 App、120 个任务、跨 20 个 Google Play 类目，覆盖率超 60%；（2）足够挑战——半数任务超过 20 步，最长 50+ 步，并显式区分 simple / long-horizon / math-related 三档难度；（3）真实泛化——评测 5 个 SOTA GUI 智能体，平均 SR 仅 27.92%，与 20 道真实应用样本的排序一致，从而证明合成环境的评测结论能迁移到现实世界。
与已有工作不同的是，现有 GUI 基准绝大多数要么是手工搭环境（AppWorld、$\tau$-bench），要么是在固定环境里合成任务/轨迹（web 教程回放、exploration rollout、反向任务合成、AgentGen），前者只能覆盖几个领域，后者主要服务训练数据生成而非逼真评测。ScaleWoB 的独特切入角度是把环境、奖励、任务三者作为耦合对象交给代码智能体一次性生成，并刻意做成无后端、URL 直接可访问的网页，从而把环境搭建成本和评测并发度同时压到接近零；同时利用 reset 几乎免费、reward 完美可验这两点，把评测和未来在线 RL 训练统一在同一个 substrate 上，这与所有依赖容器、VM、手工规则的现有基准形成本质区别。
核心方法
ScaleWoB 的整体思路是「把 App 模拟出来，再把任务和判分器塞进去」，具体由两阶段流水线 + 人机协同修复回路组成。Stage 1（最小可运行环境构建）以应用名、视觉风格、功能描述、可选截图作为输入，让代码智能体迭代做三件事：先写一份 PRD（产品需求文档，规定页面、特性、设计风格），再据此生成页面结构、数据 schema 与交互逻辑，最后做一轮 self-reflection，把缺失/不一致反馈回 PRD，循环多轮得到一个功能完整的 MWE。Stage 2（任务注入与奖励合成）在 MWE 上扩充 mock 数据，再由任务注入智能体扫描代码、修补任务相关逻辑，并为每个任务生成可执行 reward validator。每个 bundle 由验证智能体实跑一遍，成功的暂存，失败连同工件送人类专家 triage，判为环境缺陷的回流修复并重新验证；最终所有任务都经人工复核。生成出的环境都是无后端网页，可通过 window.getTasks / window.evaluateTask / window.reset 三个 DOM API 标准化评测，并天然支持 8–16 路并发。
ScaleWoB 相对已有方法的核心区别是「环境构造 = 代码生成」，并显式做成两阶段以同时获得应用保真度和任务可验性。与 AppWorld、$\tau$-bench 等手工控制型模拟器相比，ScaleWoB 的环境是平台无关的网页，pipeline 一份就能同时产出 mobile / desktop / automotive 三个 profile；与在已有环境里合成任务的方案相比，它把环境本体也作为生成对象，因此 reward 能在对环境内部状态的精确观察上做完美校验，而不是依赖轨迹匹配或 LLM-as-Judge；与所有依赖 emulator/Docker 的真实环境评测相比，它把环境做成零后端、可 URL 访问、可一键 reset 的网页，并发度和重置成本都接近零，由此把评测吞吐与未来在线 RL 训练统一在同一个 substrate 上。
方法步骤详情
完整方法分六步。Step 1（元数据收集）：抓取 App 名称、视觉风格、功能摘要、核心交互逻辑，并附真实截图。Step 2（Stage 1 迭代构建）：代码智能体（Gemini/Claude）每轮迭代完成 (i) 起草/更新 PRD，(ii) 实现/修改页面结构与 schema，(iii) self-review 检查一致性；review 反馈回 PRD 驱动下一轮，$k$ 轮后得到 MWE。Step 3（Stage 2 任务注入）：在同一 schema 下扩充 mock 数据并注入任务规格，任务注入智能体扫描代码、自动合成可执行 reward validator。Step 4（自动验证）：验证智能体多步执行，由合成 validator 判定成败。Step 5（人机 triage）：失败轨迹与工件交人类专家根因诊断；环境缺陷回流修复并重验证，通过者入候选池并接受随机抽检。Step 6（接口封装）：每个环境暴露 window.getTasks/evaluateTask/reset 三 API 屏蔽内部实现，使评测与未来 RL 训练共享同一合约，单轨迹上限 100 步。
技术新颖性
技术新颖性可以归纳为四点。第一，把环境构造问题形式化为两阶段代码生成（先把 App 做真、再把任务塞进去），既保证应用保真度又降低任务路径过拟合，因为 Stage 1 完成的应用逻辑不会被单一任务诱导偏置。第二，把 reward 也作为代码一起合成：validator 直接读取环境内部状态做精确判断，而不是用执行轨迹匹配或 LLM 打分，从而把奖励可靠性从工程瓶颈转化为生成器输出的一部分。第三，用人机 triage + 自动修复回路处理 LLM 生成环境的固有不完美，并在最终发布前对所有 120 个任务做人工复核，把生成式方法的失败代价压到可接受范围。第四，平台无关性体现在同一份 pipeline 仅靠调整 viewport 和交互约定就能产出 mobile/desktop/automotive 三类环境，三者共享同一 reward/reset 合约，使桌面与车载评测成为框架的零成本扩展而非新系统。
实验结果
评测 5 个 SOTA 移动 GUI 智能体（UI-TARS-1.5、doubao-seed-1.8、Gemini 3 Pro、MAI-UI、Mobile-Agent-v3.5），8 路并发。在 ScaleWoB 上平均 SR 仅 27.92%，最高 seed-1.8 也只有 42.50%，最低 GUI-Owl-1.5 仅 9.17%；同一批模型在 AndroidWorld 上 SR 普遍 64.2%–71.6%，best-worst spread 33.33 分。无 return-value 子集 seed-1.8 达 50.00%，有 return-value 子集骤降至 30.43%；long-horizon 子集平均仅 17.82%，是 simple 子集（56.48%）的一半；人类在 simple / long-horizon / math 三类上分别为 97.22%、89.09%、81.82%。20 道真实 App 样本上模型相对排序与 ScaleWoB 一致；11 道 fine-grained control 任务人类满分，Gemini 3 Pro 仅 5/11。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| ScaleWoB 总体评测 | Success Rate (SR, 越高越好) | 平均 27.92%；最优 seed-1.8 42.50%，最差 GUI-Owl-1.5 9.17% | AndroidWorld 上同批模型 64.2%–71.6%；人类 92.08% | 反向证据：ScaleWoB 比 AndroidWorld 低约 40 分，best-worst spread 达 33.33 分，区分度显著 |
| w/o return-value 子集 | Success Rate | seed-1.8 50.00%，Gemini 3 Pro 45.27%，UI-TARS-1.5 39.86% | 人类 95.95% | 最强模型仍落后人类 45.95 分，凸显评测难度 |
| w/ return-value 子集 | Success Rate | seed-1.8 30.43%，Gemini 3 Pro 28.26%，UI-TARS-1.5 13.04% | 人类 85.87% | 与无 return 子集相比，seed-1.8 下降 19.57 分，UI-TARS-1.5 下降 26.82 分，说明结构化输出是普遍短板 |
| Long-horizon 子集 | Success Rate | 平均 17.82%；最优 seed-1.8 29.09% | Simple 子集平均 56.48%；人类 long-horizon 89.09% | 比 simple 子集平均低约 38.66 分，揭示长程记忆是核心瓶颈 |
| Math-related 子集 | Success Rate | 平均仅小幅领先 long-horizon；最优 seed-1.8 表现远低于 simple | 人类 81.82% | 模型在需要信息聚合与计算的任务上同样缺乏跨步记忆能力 |
| Fine-grained control（11 道定制任务） | 完成数 / 11 | Gemini 3 Pro 5/11；其余模型平均 0.5–1.5/11 | 人类 11/11（满分） | 即便最强模型也只有约 45% 完成率，提示坐标精度与交互语义知识严重不足 |
局限与改进
作者在第 5 节列出四点局限。第一，观测空间受限：环境是网页栈，只能提供视觉观测与网页交互语义，没有原生平台 AccessibilityTree 等结构化信号，因此只评测能纯视觉驱动的智能体，依赖 a11y 的模型被排除。第二，不支持跨 App 任务：当前都是单 App 内工作流，无法评测需要协调多 App 的真实场景。第三，平台覆盖不均：虽然 pipeline 平台无关，本次发布的 120 道定量评测只覆盖移动端，桌面与车载仅以 demo 提供。第四，训练侧尚未验证：reset+verifiable reward 设计本意是同时支撑评测与在线 RL，但本文只验证了评测设定。独立观察还有几点：评测只跑 5 个智能体未做显著性检验；fine-grained control 仅 11 道样本量有限；人类评测与真实泛化样本均较小；框架对底层闭源 LLM 依赖使其可复现性受模型迭代影响较大。
独立分析的弱点
从方法、评测和数据三个角度可独立指出若干弱点。其一，方法上依赖大模型一次性生成完整 App+reward，幻觉风险高，虽有人机 triage 但修复代价仍线性增长于 App 数量，扩展到 1000+ 环境时人力成本难以忽视；改进方向是引入生成、测试、修复全自动化的更稳健 agentic loop。其二，评测只覆盖视觉驱动智能体，把依赖结构化 a11y 信号的模型排除在外，存在选择偏差；改进方向是为网页环境合成可导出的 a11y 树或 DOM 元数据。其三，跨 App 任务空白：当前 pipeline 严格单 App 设计，无法覆盖现实用户在 A 看到信息、在 B 完成操作的需求；改进方向是把多 App 编排建模为多环境间状态消息传递。其四，fine-grained control 子集与真实泛化样本均偏小，统计显著性不足，应扩充到数十/数百级并配 bootstrap 置信区间。其五，框架仅在网页栈上验证，迁移到需底层权限/硬件调用（蓝牙、NFC、相机、传感器）的真实场景仍有 gap。
未来方向
作者明确指出的未来方向包括四块：把 desktop 和 automotive profile 也做成完整定量基准、扩展到跨 App 工作流、在该合成环境上实证在线 RL 训练增益、丰富观测空间使其支持 a11y 类智能体。基于本文成果还可以合理延伸出几条方向：第一，把环境合成扩展到 Agentic Web、Agentic OS 等更广义的智能体生态，构造自动化 benchmark factory；第二，把两阶段设计（先构造应用、再注入任务）推广到训练数据合成领域，用类似流水线为 SFT/RLHF 生成高质量 GUI 轨迹；第三，结合 foundation GUI model（如 UI-TARS、GUI-Owl 系列）做 self-play 训练，把合成环境从评测工具升级为训练场地；第四，引入 reward shaping 与 process supervision，把 success-only 反馈升级为逐步骤可监督的 dense reward，缓解长时序任务中的信用分配问题。
复现评估
作者承诺开源项目页（scalewob.github.io）与代码仓库（github.com/ScaleWoB/ScaleWoB），并公开 120 个移动任务、63 个 App 环境、评估接口（window.getTasks/evaluateTask/reset）和 prompt 设计细节，复现门槛相对较低。但完全复现仍有几处障碍：（1）环境生成依赖 Gemini/Claude 等闭源 LLM，模型版本迭代会显著影响生成质量，建议固定 snapshot；（2）API 模型具体 checkpoint（doubao-seed-1.8-251228、doubao-ui-tars-250428、gemini-3-pro-preview、GUI-Owl-1.5-8B-Instruct、MAI-UI-8B）需明确版本号与采样超参；（3）评测 8 路并行、单轨迹 100 步上限，算力属单卡 8 卡小时量级，普通研究组 1–2 天可复现主要数字；（4）真实泛化实验的 20 道真实 App 样本需自行在真人评测者上手动复测，可能引入主观偏差。整体完整复现需中等工程投入。
论文图表
左侧展示一个 Walmart 真实 App 任务示例（用户有 30 美元预算，要挑 5 双某品牌最佳球鞋），右侧展示 ScaleWoB 的合成框架流程：PRD 生成 → Page Structure → Resource → Data Entity → Tasks → Reward Validator，最终通过 Deploy 输出 Synthetic App；下方展示 Mobile GUI Agent 与环境的 Action/Observation/Reward 闭环。
这张图用真实任务→合成框架→评测闭环三栏式呈现，是论文核心 idea 的最直观表达，决定读者能否第一时间抓住用代码智能体造环境这一主线。