RecreationWorld 把“照着一个正在运行的软件，重做一个行为相同的版本”变成训练环境和 benchmark。Agent 既要操作 reference GUI，找出菜单、状态变化和计算结果，又要写代码、构建并启动自己的版本，再回到 GUI 检查哪里不像。它真正测试的是 GUI 探索与软件实现能否在同一条长轨迹里反复配合。
Q1. 为什么要用“复刻软件”研究 hybrid CUA？
因为 recreation 同时逼着 Agent 看懂一个可运行系统、实现它，并用执行结果检查自己的实现；reference 又天然提供可复验的 ground truth。
现有 computer-use benchmark 通常给 Agent 一个现成应用，让它完成“发邮件、改表格、下单”一类操作；coding benchmark 则给 issue、仓库和 tests，让它在终端里改代码。两者都只覆盖循环的一半。RecreationWorld 反过来让 Agent 从一个运行中的 reference 开始：规格不在文档里，而在窗口、控件、菜单、输入输出和状态变化里。Agent 的交付物则必须是可构建、可启动的代码。
这个设计同时解决三个问题：
- 任务必须 hybrid。 只点 GUI 交不出源代码，只在终端写代码又无法发现 reference 的真实行为。
- 结果可以自动验证。 同一组隐藏 actions 和 assertions 可以先跑 reference，再原样跑 candidate；评分不要求 candidate 使用相同语言或架构。
- 训练数据可以扩展。 公开软件持续提供新的 reference；高分 rollout 可以被筛选成训练轨迹。
Q2. 它和相邻工作到底差在哪里？
它的边界不是“又一个 GUI benchmark”，而是把 task environment、GUI+code harness、reference-grounded judge 与 trajectory generation 放在同一个五平台框架里。
| 路线 | Agent 接触什么 | 主要交付或评测 | 与 RecreationWorld 的关键差别 |
|---|---|---|---|
| OSWorld / AndroidWorld / WebArena | 现成应用或网站 | 完成指定操作，检查环境状态 | 侧重“使用软件”；一般不要求 Agent 同时重建软件并验证自己的产物。 |
| SWE-bench / ProgramBench | 仓库、issue、terminal | 代码 patch 或程序行为 | 侧重“修改软件”；缺少通过 GUI 主动发现规格和检查 render 的循环。 |
| Design2Code / Interaction2Code / WebGen-Bench | 截图、说明或网页交互 | 前端或网站实现 | 最接近 visual coding，但通常集中于 Web，reference exploration 的深度和平台范围更窄。 |
| APPFORGE / RealDevWorld / GameCraft-Bench | 移动应用、桌面软件或游戏目标 | 可执行 artifact，功能与视觉评测 | 也强调完整软件与可执行 judge；RecreationWorld 进一步统一五个平台，并研究 GUI↔code 的轨迹和训练迁移。 |
| Gym-Anything / CUA-Gym / GUI-GENESIS | 自动构造的环境、任务与 reward | 规模化训练环境或可验证轨迹 | 同属 scalable environment 路线；本文用运行中的 reference 同时产生规格、测试依据和训练经验。 |
| WeaveBench / PhoneHarness / StateAct | GUI 与 terminal、API 或 program state | 混合工具工作流 | 直接研究 hybrid action；本文把重点放在 explore→implement→verify 的软件复刻闭环。 |
这里不应把“首个”当作结论。APPFORGE、RealDevWorld、GUI-GENESIS 等已经覆盖 reference-driven application generation 或功能+视觉评测。RecreationWorld 更有说服力的贡献是：同一个 task contract 横跨 Ubuntu、macOS、Windows、Android 与 Web，并且把 benchmark 和训练轨迹生产连接起来。
Q3. 250 个任务从哪里来，Agent 能看见什么？
任务不是由自然语言描述凭空写出来的。作者从可固定版本、可在隔离环境运行的软件或网站中选 reference，再为它准备可复现的启动方式、fixture 与隐藏 tests。
RecreationBench 每个平台 50 个 task。三个桌面平台的 release inventory 记录 upstream repository 与 revision；Android 选择不声明 Internet permission、核心状态保存在本机的应用；Web 包含 44 个 synthetic site 和 6 个来自 public website 的站点。作者按功能域、UI framework、语言、规模和可测性筛选，并排除无法稳定构建、启动后被 update dialog 挡住或依赖在线服务的候选。公开仓库提供 250 个 task manifest、五平台 runner、统一 result schema 与评测代码；完整 frozen task bundles 由项目链接到 Hugging Face / ModelScope 分发。
Benchmark 构造和提交评测是两条流程
先说构造阶段。作者分析 reference 的页面或源码来发现功能，实际操作 reference 获取 expected outcome，生成能重放的 case，再把每个 case 放到干净 reference 上执行。没有稳定通过 reference 的 case 会被丢弃；保留下来的 fixture、actions 和 expected observations 还要经过人工复核，然后才冻结。论文没有报告 reviewer 数量、inter-annotator agreement 或复核驳回率，所以可以确认“有人审”，不能推断标注一致性有多高。
再说评测阶段。Agent 只能看到 task prompt、运行中的 reference、开发工具和自己的 workspace。Desktop 与 Android 尽量做到 source-blind：reference source、test suite、ground-truth screenshots 和 credentials 都放在受保护位置。Web 是明确例外，因为浏览器运行静态站点时必然收到 HTML、CSS、JavaScript 与 assets；因此 Web 只能隐藏 captured ground truth 和 generated tests，并禁止 candidate 在评测时直接加载 reference。
- 1 · EXPLOREAgent 操作 reference，自己决定看哪些状态。
- 2 · IMPLEMENT在 workspace 写 source、build 与 launch 入口。
- 3 · CHECK启动 candidate，操作并检查画面或行为。
- 4 · FREEZE20 小时结束后终止 Agent process，冻结提交树。
- 5 · EVALUATE隐藏 suite 在隔离环境重放，不让 Agent 看 judge。
各平台的 programmatic 接口分别是 AT-SPI、AXUIElement、UI Automation、UiAutomator 和 DOM/ARIA。它们读到的是控件文字、状态、层级和 action outcome，不是 candidate 的内部变量。这样，同一个功能可以用 GTK、SwiftUI、WPF、React 或别的结构实现，只要外部行为一致即可。
Q4. 一个真实 case 怎样从 fixture 走到 PASS / FAIL？
Logbert case 展示了完整 judge 链：固定输入制造确定状态，隐藏 actions 把应用推进到 Statistic 页面，Prog 检查精确值，VLM 检查结构化接口看不到的图形与布局。
把这个 case 按发生顺序读一遍
- 来源与作者。这是论文作者为 Windows task `couchcoding-logbert` 生成并复核的隐藏 case。公开 task manifest 能确认该 task 存在；Figure 8 展示了 case 名、fixture、actions 和 assertions。
- 准备状态。evaluator 提供固定日志 `sample_log4net_mixed.log`，共 10 条：5 条 Info、3 条 Error、2 条 Debug。81 个 task 共打包 393 个 fixture file，避免依赖用户机器上的偶然内容。
- 执行动作。runner 打开 New Logger，选择 fixture，等待 Number 列出现，再点击 Statistic。交互深度从初始状态一路推进到 depth 3。
- Programmatic evidence。Windows UI Automation 必须读到且只读到 `20%`、`30%`、`50%` 三个 label，并确认旧值 `17%` 不存在。
- Visual evidence。Qwen3.7-Plus 在 temperature 0 下判断 50% slice 是否显著最大、20% 是否最小，legend 是否为 Debug:2 / Info:5 / Error:3，以及 tab、grid 和 status 是否仍正确。
- 判定边界。缺少 expected evidence 就失败；judge 的 transport 或 parsing error 会重跑，不会直接记作模型失败。Build 或 launch 失败则整个 task 为 0。
下面是根据 Figure 8 公开断言写的 Python 3 说明代码，用来说明“精确状态”如何判定；它不是作者未公开 test bundle 的逐字副本。
def check_statistic_labels(labels):
observed = sorted(v.strip() for v in labels if v and v.strip())
assert observed == ["20%", "30%", "50%"]
assert len(labels) == 3
assert "17%" not in labels
# PASS: ["50%", "30%", "20%"]
# FAIL: ["50%", "30%", "20%", "17%"] # stale UI state remains
分数到底怎样汇总
每个 assertion 先得到 pass/fail。Prog 与 VLM 分别在一个 application 内汇总；再在每个平台内对 50 个 application 做 macro average；最后让五个平台等权。Headline overall 是两条通道的算术平均：
官方 MIT 仓库中的 RunResult 还专门区分“确实评为 0”和“根本没有完成评分”：task_score = None 表示 not graded，不应偷偷当作 0；EvalCounts.rate 优先用 passed / total，避免历史文件里的缓存比例与原始计数不一致。这是一个看似小、实际很关键的结果协议。
# Adapted from src/recreation_bench/result.py in the official MIT repository
@property
def graded(self) -> bool:
return self.task_score is not None
@property
def prog_pass_rate(self):
if self.eval_prog_n:
return self.eval_prog / self.eval_prog_n
return self.programmatic.rate if self.programmatic else None
Q5. 模型表现、harness 实验和训练迁移说明了什么？
最强模型仍远未复刻完整行为；但 programmable harness 显著降低交互开销，recreation trajectories 也显示出跨 benchmark 迁移。两组结果都值得继续做，但目前还不是严格因果结论。
十个模型中，GPT-6 Astra 以 Prog 58.19、VLM 57.92、overall 58.06 排第一；Claude Opus 5 是 45.99 / 42.34 / 44.16；GPT-5.6 Sol 是 40.63 / 43.49 / 42.06。论文的错误分析显示：模型更容易复制静态 interface structure，interaction 与 computed output 更难；生成的应用通常比 reference 小得多，也更集中在少数大文件里。
Programmable SDK：少把每个 click 都送回模型
主榜使用 direct MCP：每个 click、keypress、observation 都单独返回模型。作者另做了一项 Windows 配对实验，让 Claude Opus 4.8 通过 persistent Node.js REPL 调用 typed JavaScript SDK，从而在一次执行里写循环、保存状态并只返回需要的观察。
| 比较项 | Direct MCP | Programmable SDK | 变化 |
|---|---|---|---|
| Prog score | 35.05 | 35.60 | +0.55 pp |
| VLM score | 31.00 | 32.29 | +1.29 pp |
| computer-use calls | baseline | — | −39.9% |
| input tokens | baseline | — | −40.7% |
| tool-result text | baseline | — | −65.5% |
| wall-clock / task | 4.12 h | 3.04 h | −26.1% |
| estimated model cost / task | $90.50 | $41.58 | −54.1% |
| output tokens | baseline | — | +15.7% |
效率统计只覆盖两种配置都没有 terminal error 且 usage 完整的 39 对；质量分覆盖所有 evaluator-valid pair。每个 task/configuration 只有一次 rollout，而且 REPL、SDK、context 返回方式一起变化，所以证据只支持“这一整套配置观察到更低开销”，不能把全部差值归因于 persistent runtime。
35,000 条轨迹是否真的教会了通用能力？
作者用 Qwen3.8-Max 生成 trajectories，每个平台选 7,000 条，组成 35,000 条 SFT mixture，再训练两个 initialization。两个 run 在五项 OOD coding / hybrid computer-use benchmark 的最后 checkpoint 都高于各自第一个被评测 checkpoint，单项最大提升 17.9 个百分点；后期 checkpoint 也更常运行自己的产物并读取 render。
这说明 recreation data 与更强的跨任务表现相关，但还缺少三个关键控制：没有 multiple seeds；没有 equal-data 的普通 coding trajectory 对照；没有发布被选中的 35,000 条 trajectory、训练 checkpoint 与完整 hyperparameters。因而论文证明了“这条训练路线值得做”，还没有隔离出究竟是 hybrid loop、数据规模、筛选策略还是 teacher model 带来的增益。
Q6. 这篇论文应该怎样评价？
这是目前把 Claude Code / Codex 式 coding harness 与 GUI 操作结合得最完整的 benchmark-and-environment 工作之一；最大的价值是任务和 judge 的可执行闭环，最大的缺口是校准与训练复现。
如果沿这条线继续研究，最值得补的不是更多装饰性任务，而是三件可证伪的事：第一，给 VLM assertions 做人工校准并公开 disagreement；第二，让同一模型、同一 task 重复运行，报告 task-level uncertainty；第三，在相同数据量与 teacher 下比较 recreation trajectory、普通 coding trajectory 和 GUI-only trajectory，真正隔离 hybrid supervision 的作用。
留言