GameWorld: Towards Standardized and Verifiable Evaluation of Multimodal Game Agents

Paper: arXiv:2604.07429 Project: gameworld-project.github.io（paper 中的 gameworld-bench.github.io 目前跳转到该页面） Code: gameworld-project/gameworld; game assets/snapshots: gameworld-dev/gameworld-games Code reference: main @ e236a397 (2026-05-13); game library main @ 4753449e (2026-04-19)

1. Motivation (研究动机)

现有 MLLM / GUI agent 评测大多停留在静态 VQA、网页任务或少量游戏环境，难以同时覆盖视觉感知、实时反应、长程计划、动作约束和可复现实验。游戏特别适合作为中间形态的 embodied benchmark：环境视觉丰富、状态随动作闭环演化、错误不可随意撤销；但已有 game benchmarks 往往存在游戏数少、动作接口异构、评估依赖视觉启发式或 VLM-as-judge、任务初始化和并行实例不标准等问题。

Figure 1 解读：这张 teaser 展示 GameWorld 覆盖的 34 个 browser games。作者选择 browser 环境而不是重型引擎/模拟器，是为了让每个游戏可以被快速 reset、可并行启动，并通过统一的 gameAPI 暴露可验证状态。

本文要解决的核心问题是：如何在同一个可执行 runtime 中，公平评测“直接发键鼠动作”的 Computer-Use Agent（CUA）和“发语义动作”的 generalist multimodal agent，并且让成功/进度指标来自 game state，而不是来自模型回复文本或视觉判断。这个问题值得做，因为如果 benchmark 不能隔离动作接口、推理延迟、状态验证和长程 memory，就很难判断 agent 失败到底来自感知、规划、控制 grounding，还是评测噪声。

从 paper 的 problem statement 看，GameWorld 的动机不是“再做一个游戏排行榜”，而是补齐交互式多模态 agent 评测中几个长期混在一起的问题： Latency：真实游戏在模型思考时仍会演化，慢模型即使决策正确，也可能错过动作窗口。Sparse feedback：很多游戏只有阶段性奖励或终局成功，单步视觉判断无法稳定反映 progress。Irreversible mistakes：跳错、碰撞、掉落、误点 UI 后，后续 trajectory 会被改变，不能像静态 VQA 那样独立重答。

Heterogeneous action interfaces：CUA API、browser automation API、game-specific command API 的动作粒度不同，直接比较会混淆模型能力和接口设计。Heuristic verification：如果靠 screenshot 相似度、OCR、VLM-as-judge 或模型自评，评测噪声会和 agent 失败混在一起。Repeated evaluation 缺口：一个 interactive benchmark 若没有重复跑的稳定性证据，就很难判断 leaderboard 差异是否可复现。

作者选择 browser games 有几个工程和科研上的折中： Browser 环境比重型 simulator 更容易 reset、并行启动和跨平台复现。游戏画面足够视觉化，能覆盖 object tracking、spatial navigation、timing、planning、resource management。游戏逻辑可以通过 JavaScript 暴露 window.gameAPI，从内部 state 读取目标变量。同一套 browser runtime 可以同时服务 CUA 和 Generalist agents，只在 action adapter 上分叉。

34 个 games 分布在 Arcade、Platformer、Puzzle、Runner、Simulation 五类，避免只测一种反应模式。因此，GameWorld 的研究目标可以概括为三层：

第一层是 standardization：统一 task catalog、prompt assembly、action budget、runtime、logging 和 evaluator。第二层是 verifiability：所有 success/progress 都来自 serialized game state，而不是人工/模型主观判断。第三层是 diagnostics：不仅给 overall score，还分析 real-time、memory、invalid action、capability level 和 case trajectory。这也解释了 paper 的立场：GameWorld 更像一个 measurement platform，而不只是一个 “agents 玩游戏” demo；它关心的是可比性、可验证性和失败归因。

2. Idea (核心思想)

核心 insight：GameWorld 把游戏 agent 评测拆成四个可复用部件——模型接口、browser sandbox、游戏/任务 catalog、state-verifiable evaluator。这样 CUA 和 generalist agents 可以共享同一套任务与状态评估，只在 action interface 处不同：CUA 输出低层键鼠事件；generalist agent 输出注册过的语义 control，再由 deterministic Semantic Action Parsing 映射到低层动作。

Figure 2 解读：图中闭环是“observation → action → browser execution → state-verifiable evaluation”。与 LMGame-Bench 等更偏文本或少量游戏的 benchmark 相比，GameWorld 的差异不是只增加游戏数量，而是把每一步执行和评估都落在统一 runtime 上：模型看到 screenshot 和结构化 prompt，动作被解析/验证后由浏览器执行，评估器读取 gameAPI.getState() 计算 task outcome。

本质创新有三点：第一，任务被定义为自然语言指令 + 初始化/URL 配置 + target metric + evaluator config；第二，评估不看模型“是否说对”，而看状态字段是否达到目标；第三，提出 paused benchmark 与 GameWorld-RT 两种 protocol，前者隔离 decision quality，后者暴露真实部署时的 latency/control 代价。我理解这篇 paper 的核心 idea 是把“游戏 agent 能力”拆成两个正交维度： 模型决策能力：是否能从 screenshot、rules、task instruction 和 history 中选出合理下一步。

接口执行能力：模型输出的动作能否被 runtime 合法解析并映射到游戏中的真实控制。GameWorld 没有把这两个维度强行合并，而是显式比较两类 interface： CUA 保留低层 human-computer interaction：keyboard、mouse、click、scroll、wait。Generalist agent 使用 semantic action list：模型选 move_left、jump、wait 等 game-role-specific controls。

Semantic Action Parsing 把 semantic control deterministic 地翻译成同一个低层 runtime schema。因为映射是 deterministic，Generalist 的 score 主要反映 semantic planning 和 instruction following，而不是像素坐标精度。这个设计的关键好处是：

同一 task 可以被 CUA 和 Generalist 共同评测。同一 evaluator 可以读取同一份 game state。同一 action budget 可以约束两种 interface。同一失败 trajectory 可以被拆成 “看错/想错/动作不合法/动作太慢/长程目标丢失” 等原因。与只报告 success rate 的 benchmark 相比，GameWorld 增加了 progress metric： Success Rate 只回答是否完成终局目标。Progress 则回答在有限 step budget 内走到了目标的哪一段。对交互式任务来说，progress 很重要，因为很多 agent 不能通关但能推进局部子目标。

这也是 main results 中 “agents make meaningful partial progress but remain far from human performance” 的证据基础。Paused protocol 和 GameWorld-RT 的并置也很重要： Paused protocol 在模型推理时暂停游戏，主要测 decision quality。GameWorld-RT 不暂停游戏，模型响应时间会直接影响 timing 和生存窗口。两者不能直接横向比较，因为 RT setting 的 effective gameplay duration 包含 inference time。

但两者合在一起，可以区分“模型会不会做”和“模型能不能及时做”。所以，GameWorld 的 idea 不是提出一个新 agent，而是提出一套可复用的 benchmark abstraction：

runtime abstraction：browser sandbox + action executor + logger。 task abstraction：natural-language goal + initialization + target metric。 interface abstraction：CUA raw action vs Generalist semantic action。 verification abstraction：state-derived SR/PG/IAR，不依赖 judge model。

3. Method (方法)

3.1 Benchmark 结构与任务定义

GameWorld 包含 34 个 browser games、170 个 tasks、5 类游戏：Arcade 7、Platformer 8、Puzzle 7、Runner 8、Simulation 4。每个 task 都有目标分数、最大步数和 evaluator 配置；released code 中 170 个 catalog/tasks/*/*.yaml 全部使用 evaluator_id: game_api_metric、max_steps: 100、pause_during_inference: true、continue_on_fail: true。

这说明论文主 benchmark 的默认结果主要衡量“同一 action budget 下的决策质量”，而不是模型的真实响应速度。任务定义由四类信息组成： game identity：具体游戏、入口 URL、角色数量、可用 controls、prompt blocks。task instruction：自然语言目标，例如收集若干 coin、到达出口、达到 score threshold。initialization/config：游戏启动参数、level、seed、role-specific rule 或 task-specific target field。

evaluator config：从 gameAPI.getState() 中读取哪个 metric，起点和目标阈值是什么，是否有 end-field rule。论文把 34 个 games 分成五类，目的是让 benchmark 覆盖不同 failure modes： Runner：强调高频 timing、连续前进、障碍规避。Arcade：强调动态目标追踪、反应控制、奖励收集。Platformer：强调空间移动、跳跃物理、局部路径规划。Puzzle：强调离散状态搜索、规则记忆、符号推理。Simulation：强调开放目标、资源管理、长程协调和错误恢复。这种分类不是只为了展示多样性，也影响后续结果解释：

Runner / Arcade 的 progress 往往更能体现 reactive control。Puzzle 的优势更可能来自 language reasoning 和 rule following。Simulation 的低分说明 current MLLM agents 对 long-horizon objective maintenance 仍不稳定。Platformer 的失败经常混合视觉 grounding、physics timing 和动作连续性。

Released code 的 catalog 设计也支持这种结构化评测： catalog/games/*.yaml 负责 game-level rules、roles、controls 和 prompt fragments。catalog/tasks/*/*.yaml 负责 task-level goal、target metric、budget 和 evaluator fields。catalog/models/*.yaml 负责模型接口、prompt template、memory setting 和 output format。build_runtime_config() 把三者合成 runtime config，避免每个实验脚本手写不同逻辑。

一个容易忽略的点是 continue_on_fail=true：单个 episode terminal failure 不一定结束整个 run。Runtime 可以 reset task 并继续使用同一个 global step budget。因此 score/progress 更接近“100 步内最好推进到哪里”，而不是第一次死亡就终止。这对 Flappy Bird、Mario、runner 类任务尤其重要，因为早期失误非常常见。

3.2 Agent interface：CUA vs. Semantic Action Parsing

CUA 直接输出低层控制，例如 mouse_move(x, y)、left_click(x, y)、press_key(key)；为了可比性，每个 model response 只能包含一个可执行 atomic action。Generalist agent 不直接发像素级鼠标/键盘，而是从当前 game role 注册的 semantic controls 中选择一个动作，例如 move_left、wait，runtime 再把它 deterministic 地映射到低层 action dict。

这个设计避免要求所有 MLLM 都具备原生 computer-use API，同时又不让 generalist agent 通过多步 macro 绕过动作预算。论文公式与 released code 实现差异：附录写道 Semantic Action Parsing 的 control identifier 可来自 action、tool_name 或 tool_id；但 agents/harness/semantic_controls.py 的 _extract_control_id() 当前只读取 tool_name。

因此以 action / tool_id 作为字段名的 released-code payload 会被 inspect_semantic_controls_output() 判为 missing_tool_name，这比论文描述更严格。接口层可以拆成三层理解： Conceptual unified control space：paper Table 1 中的 atomic events，如 key_down、key_up、mouse_move、left_click、scroll、wait。

Runtime normalized action layer：released code 中 ActionExecutor 接收的 click、click_hold、drag、mouse_move、press_key、press_keys、type、wait。Model-facing output layer：CUA 直接生成低层动作；Generalist 生成 semantic payload，再查 semantic_controls_map。CUA 的优势和风险：优势是表达力完整，可以在任何支持键鼠的游戏中直接操作。

风险是坐标、按键时长和时机都必须精确，invalid action 或微小 timing error 会放大。对 proprietary computer-use models 来说，API 本身还会限制可用工具和输出格式。对 open-weight VLM 来说，低层 action string 既要格式正确，也要坐标落在可操作区域。

Generalist interface 的优势和风险：优势是 action list 与 game role 对齐，降低坐标/按键细节负担。 Runtime 能保证每个 semantic control 对应合法低层动作，减少无意义 parser error。风险是 semantic action space 必须人工/配置预先设计，新增游戏需要定义 controls。 Semantic control 若过粗，会给 Generalist agent 不公平的 macro advantage；若过细，则又接近 CUA 的低层困难。

Paper 的设计选择是：semantic action 不允许绕过 action budget。

每个 model response 仍只产生一个 atomic executable action。 Semantic control 不是多步 macro policy，而是一个固定低层 interaction command。这样可以更公平地比较“语义规划”与“低层键鼠 grounding”。但也意味着长程策略仍必须通过多轮 observation-action loop 实现。

3.3 State-verifiable evaluation 与指标公式

每个游戏需要暴露 window.gameAPI，包含 init(config)、reset(options)、getState()。getState() 的顶层 contract 包含 gameId、timestampMs、gameTimeMs、status、terminal、game_state、metrics、raw；评估器只读取可序列化 state，不依赖 screenshot 上的视觉启发式。

对 run $i$ ，令 $q_{i, t}$ 是 step $t$ 从可验证 game state 读出的 task score， $q_{i}^{m a x} = max_{t} q_{i, t}$ ， $b_{i}$ 是起始分数， $τ_{i}$ 是目标阈值。论文定义 normalized progress： $progress_{i} = clip_{[0, 1]} (\frac{q _{i}^{m a x} - b _{i}}{τ _{i} - b _{i}}) .$ reset-on-fail 开启时，episode-local score 会在 reset 后清空，但 run-level best progress 保留，所以 $progress_{i}$ 表示整个 100-step budget 内达到过的最远归一化进度。整体成功率和平均进度为： $S R = \frac{1}{N} \sum_{i = 1}^{N} 1 [status_{i} = success], P G = \frac{1}{N} \sum_{i = 1}^{N} progress_{i} .$ 动作合法性用 Invalid Action Rate 衡量： $IAR = 1 - \frac{\sum _{r \in R} # valid_actions ( r )}{\sum _{r \in R} # proposed_actions ( r )} .$ State-verifiable evaluator 的关键在于它读的是 task-relevant variable： 2048 可以读最大 tile 或 score。Mario 类任务可以读 player position、coins、lives、level progress。Breakout / Flappy 类任务可以读 score、alive state、distance 或 frames survived。Minecraft Clone 类任务可以读 inventory、resource count、crafting/collection status。

Evaluator 每步大致执行以下判断：先从 state 中解析当前 score 和是否 terminal。更新 run-level best score / best progress。判断是否达到 target threshold。判断是否命中 task-specific end condition。判断是否耗尽 max_steps。若 continue_on_fail 且 terminal failure，reset game 但保留 run-level best。这套设计减少了三类评测噪声：不需要从 screenshot 猜测玩家位置或分数，避免 OCR/vision error。

不需要让 LLM judge trajectory 是否成功，避免 judge model bias。不需要用 final frame alone 判断任务，因为 progress 可以取 trajectory 中的 best state。

但它也引入一个 benchmark 维护成本：每个 game 必须实现稳定的 gameAPI schema。每个 task 必须指定正确 target score field。游戏 update 后 state field 不能 silently 改名。 Evaluator 的成功定义要和自然语言 task instruction 保持一致。

3.4 Released code 对照

Code source for this section: gameworld-project/gameworld main@e236a397 (2026-05-13); gameworld-dev/gameworld-games main@4753449e (2026-04-19).

Paper Concept	Source File	Key Class/Function
Registry preset `<game_id>+<task_id>+<model_spec>`	`catalog/builder.py`, `catalog/games/.yaml`, `catalog/tasks//.yaml`, `catalog/models/.yaml`	`build_runtime_config()`
Observation-action-evaluation loop	`main.py`, `runtime/coordinator.py`	`Coordinator._get_raw_action()`, `_run_agent_step()`, `_handle_eval_controls()`
Browser sandbox and pausing	`runtime/env.py`, `env/browser_manager.py`, `env/game_launcher.py`	`GameEnv.start()`, `pause_game()`, `resume_game()`, `capture_state()`
Semantic Action Parsing	`agents/harness/semantic_controls.py`	`map_semantic_controls_output()`, `inspect_semantic_controls_output()`
Low-level action validation	`env/action_executor.py`	`ActionExecutor.inspect_action()`, `_parse_press_key()`, `_parse_click_action()`
State-verifiable evaluator	`env/game_state_tracker.py`, `env/task_evaluator.py`	`GameAPIStateTracker.capture()`, `build_task_evaluator()`, `_update_progress_metrics()`, `_resolve_outcome()`
Full-suite repeated runs	`run_suite.py`, `tools/suite_runner/`, `benchmark/suites/.yaml`	`run_wave()`, `write_suite_outputs()`

代码阅读中的实现要点： catalog/builder.py 是 paper abstraction 落到运行时配置的入口。runtime/coordinator.py 负责每步 screenshot、pause/resume、model call、action resolve、execute、evaluate。runtime/env.py 把 pause_during_inference 变成 browser manager 的暂停/恢复调用。env/browser_manager.py 负责安装页面脚本、导航、截图、读取 state、reset、pause、resume。

env/action_executor.py 做低层 action normalization 和 legality check。agents/harness/semantic_controls.py 做 semantic control resolution、arguments merge、cell binding expansion。env/task_evaluator.py 做 progress、success、reset、stop reason 和 summary metrics。run_suite.py 支持把 suite cases 展开成 repeat waves；

默认并行度由 CLI 控制，当前 README/脚本侧常用 --max-parallel=5。代码与 paper 对齐良好的地方： 170/170 个 task YAML 都使用 game_api_metric evaluator。170/170 个 task YAML 都是 max_steps: 100。170/170 个 task YAML 都启用 pause_during_inference: true。170/170 个 task YAML 都启用 continue_on_fail: true。这与 paper 的 paused main benchmark protocol 一致。代码与 paper 需要读者注意的地方：

Paper appendix 说 semantic identifier 可来自 action、tool_name、tool_id。 Released code 当前 _CONTROL_ID_KEY = "tool_name"。因而 note 中的 pseudocode 以 released code 为准，不把 action/tool_id 当成可用输入键。如果未来 repo 修复该差异，github_ref 需要同步更新，否则本文档对应的是 e236a397 版本。

Implementation-based pseudocode（按 released code 抽象）：

def build_runtime_config_from_preset(preset: str) -> RuntimeConfig:
    game_id, task_id, model_ids = parse_game_task_models(preset)
    game = load_game(game_id)          # rules, roles, low-level controls, semantic controls
    task = load_task(game_id, task_id) # prompt, evaluator config, target score, max_steps
    models = [load_model(mid) for mid in resolve_model_ids(game, model_ids)]
 
    role_controls, semantic_maps, semantic_specs = [], [], []
    prompts, enable_memory = [], []
    for role, model in zip(game.game_roles, models):
        role_controls.append(role.controls.copy())
        semantic_map = build_semantic_controls_map(role.semantic_controls)
        semantic_maps.append(semantic_map)
        semantic_specs.append([a.to_runtime_spec() for a in role.semantic_controls])
 
        template = load_prompt_template(model.require_prompt_template_id())
        prompts.append(render_system_prompt(
            template_name=template.template_name,
            game_rules=game.game_rules,
            task_prompt=task.task_prompt,
            role_section=role.prompt.role_section,
            computer_use_controls_section=role.prompt.computer_use_controls_section,
            semantic_action_space=render_semantic_action_space(role.semantic_controls),
            output_format=model.output_format,
        ))
        enable_memory.append(model.enable_memory)
 
    return RuntimeConfig(
        game_id=game_id, task_id=task_id, max_steps=task.max_steps,
        evaluator_id=task.evaluator_id, evaluator_config=task.evaluator_config,
        pause_during_inference=task.pause_during_inference,
        continue_on_fail=task.continue_on_fail,
        role_controls_maps=role_controls,
        semantic_controls_maps=semantic_maps,
        system_prompts=prompts,
    )

async def run_one_agent_step(agent, env, evaluator):
    screenshot = await env.capture_screenshot(agent.agent_id)
    if env.pause_during_inference:
        await env.pause_game()
    try:
        raw_action = await to_thread(agent.client.get_action, screenshot)
    finally:
        if env.pause_during_inference:
            await env.resume_game()
 
    if agent.agent_type == "generalist":
        action = map_semantic_controls_output(raw_action, agent.semantic_controls_map)
    else:
        action = raw_action
 
    validity = inspect_semantic_or_low_level_action(agent, raw_action, action)
    await env.execute_action(agent, action)
    state = await env.capture_state()  # window.gameAPI.getState()
    result = await evaluator.evaluate(agent, state)
 
    if result.should_reset:
        await env.reset_game()
        agent.eval_metrics = evaluator.reset_metrics(agent.eval_metrics)
    if result.should_stop:
        stop_run()

def map_semantic_controls_output(raw: dict, semantic_controls_map: dict) -> dict:
    control_id = raw.get("tool_name")  # released code only accepts this key
    mapped = dict(semantic_controls_map[control_id])
    arguments = raw.get("arguments")
    if isinstance(arguments, str):
        arguments = json.loads(arguments)
    for k, v in arguments.items():
        if k not in ('tool_name', 'arguments') and k not in mapped and v is not None:
            mapped[k] = v
    if "cell_bindings" in mapped and "cell" in arguments:
        mapped["x"], mapped["y"] = lookup_cell_xy(mapped["cell_bindings"], arguments["cell"])
        del mapped["cell_bindings"]
    mapped.setdefault("semantic_controls", control_id)
    return mapped

def update_state_verifiable_metrics(metrics, state, target_score):
    should_reset = False
    score_current = resolve_score_from_state(state, config.score_field)
    metrics["score_best"] = max(metrics.get("score_best", start_score), score_current)
    progress = (metrics["score_best"] - start_score) / (target_score - start_score)
    metrics["progress"] = min(1.0, max(0.0, progress))
    target_reached = metrics["score_best"] >= target_score
 
    terminal_hit = state.get("terminal", {}).get("isTerminal")
    max_steps_hit = step_index >= max_steps
    end_match = get_nested(state, config.end_field) == config.end_value
 
    if target_reached:
        status, stop_reason, should_stop = "success", "target_reached", True
    elif continue_on_fail and terminal_hit and terminal_outcome_is_fail(state):
        status, stop_reason, should_stop = "fail", "terminal_fail_reset", False
        should_reset = True
    elif max_steps_hit:
        status, stop_reason, should_stop = "fail", "max_steps_exhausted", True
    else:
        status, stop_reason, should_stop = "unknown", None, False
    return TaskEvaluationResult(status, metrics, should_stop=should_stop, should_reset=should_reset)

3.5 关键可视化与 case studies

Figure 3 解读：每行是一个 model-interface pair，每列是游戏 task 的 progress heatmap。Runner 普遍更容易取得进度，而 Simulation 经常接近低进度；这支持作者的判断：当前 agent 能做局部 reactive/control，但在开放式资源管理和多目标协调中弱。

Figure 4 解读：四个 Qwen 设置在 10 次 repeated full-benchmark run 上的 per-game progress 分布。大多数游戏的误差带较窄，说明 benchmark 聚合指标较稳定；较大的方差集中在控制敏感或高随机性的游戏。

Figure 5 解读：作者把任务按能力划分为 Level-1 basic control/timing、Level-2 reactive control、Level-3 spatial navigation、Level-4 symbolic reasoning/strategy、Level-5 open-world coordination。雷达图显示两种 interface 都在 Level-4 相对更强，在 Level-5 明显退化，表明当前 MLLM agent 的长程协调和开放世界管理仍是短板。

Figure 6 解读：Mario case 把 CUA 轨迹和 Generalist 轨迹并排。两者面对相同任务时，差异主要来自 action grounding：CUA 直接操作键鼠但需要精确 timing；Generalist 的语义动作更稳定，但会损失细粒度控制。

Figure 7 解读：Minecraft Clone case 中 agent 可以执行局部合理动作、把 progress 推到 90%，但仍未完成目标。这里的失败不是单步动作非法，而是长程资源收集和目标维护不够稳。

Figure 8 解读：Flappy Bird case 展示 real-time control 的脆弱性：连续 frame 几乎相同，但早一点/晚一点 flap 就会决定 progress 是否增长。它解释了为什么 GameWorld-RT 需要单独报告，而不能只用 paused protocol 代替。

4. Experimental Setup (实验设置)

数据/环境规模：GameWorld 由 34 个 browser games 和 170 个 natural-language tasks 组成，游戏快照在 gameworld-dev/gameworld-games，benchmark catalog 在 gameworld-project/gameworld/catalog。每个任务绑定 target score、start score、evaluator_config、max_steps=100、pause_during_inference=true 和 continue_on_fail=true；

released code 的 catalog/tasks 中 170/170 个任务都使用这些设置。模型与接口：论文评测 13 个 base models，构成 18 个 model-interface pairs（8 个 CUA + 10 个 Generalist）。Proprietary/hosted 包括 Claude-Sonnet-4.6、Gemini-2.5-Computer-Use、Gemini-3-Flash-Preview、GLM-4.6V、GPT-5.2、Grok-4.1-Fast-Reasoning、Kimi-K2.5、OpenAI-Computer-Use、Qwen3-VL-Plus、Seed-1.8；

open-source/open-weight 包括 Qwen3-VL-235B-A22B、Qwen3-VL-30B-A3B、UI-TARS-1.5-7B。评测 protocol：默认 benchmark 在模型推理期间暂停游戏，确保 $S R$ / $P G$ 主要反映 decision quality；GameWorld-RT 则不暂停环境，用 sec/step、SR、PG 同时衡量延迟与实时交互能力。Human baseline 由两名 CS postgraduate students 完成：一个 novice，一个 expert。

成本与复现实验：附录估算对列出的 API models 完成 170 tasks 全量评测总成本为 815.19 USD，输入 token 统计包含 provider 支持的 cached input tokens；open-weight models 的推理成本未计入。released code 的 run_suite.py 默认 --max-parallel=5，suite runner 会把 YAML cases 展开成 repeat waves 并写出结果。具体 setup 还包含以下约束：每个 run 的基本 action budget 是 100 steps。每步模型输出一个 interaction command。

Paused benchmark 中，环境在 model inference 前暂停，模型返回后恢复。固定 per-action execution duration 通常在 200–500 ms 区间。Evaluation logger 记录 proposed actions、valid actions、state snapshots、progress metrics。Human baseline 与 agent baseline 使用同一 task set 和 outcome evaluator。

模型分组可以按 interface 读： CUA group：Claude-Sonnet-4.6、Gemini-2.5-Computer-Use、OpenAI-Computer-Use、Qwen3-VL-Plus、Seed-1.8、Qwen3-VL-235B-A22B、Qwen3-VL-30B-A3B、UI-TARS-1.5-7B。

Generalist group：Claude-Sonnet-4.6、Gemini-3-Flash-Preview、GLM-4.6V、GPT-5.2、Grok-4.1-Fast-Reasoning、Kimi-K2.5、Qwen3-VL-Plus、Seed-1.8、Qwen3-VL-235B-A22B、Qwen3-VL-30B-A3B。Open-weight repeated-run validation 只选择 Qwen3-VL-30B-A3B 和 Qwen3-VL-235B-A22B。这样 repeated evaluation 的成本可控，同时能覆盖小/大 backbones 与 CUA/Generalist 两种接口。

指标设置： $S R$ ：170 tasks 上的 success rate，按 evaluator 判断是否达到 task target。 $P G$ ：normalized progress，按 trajectory 中 best state 归一化到 $[0, 1]$ 后求平均。 $IAR$ ：invalid action rate，衡量 proposed actions 中没有通过 parser/legality check 的比例。 $NTC$ ：not-tool-call / format 类错误，占 invalid action 的重要子类。

$OOS$ ：out-of-space / out-of-scope 类错误，例如动作不在当前 control space。消融与诊断设置： Repeated evaluation：四个 Qwen model-interface pairs 各跑 10 次 full-benchmark rerun。Capability curriculum：按 Level-1 到 Level-5 分析 basic control、reactive control、spatial navigation、symbolic reasoning、open-world coordination。

GameWorld-RT：同样的 Qwen backbones，但游戏不在 inference 时暂停。Memory sensitivity：对 Qwen3-VL-235B-A22B 比较 memory rounds 0/1/2 的 tokens、sec/step、PG。Invalid action diagnostics：记录 invalid format、unregistered control、illegal low-level action 等类别。

复现时需要注意两点： Main benchmark 的数字不能直接和 GameWorld-RT 数字混排，因为前者去除了推理延迟 confound。 Memory ablation 不是简单“更多上下文更好”，因为更多 screenshot/history 会提高 token 数和 wall-clock latency。

5. Experimental Results (实验结果)

主结果：最佳 Generalist agent 是 Gemini-3-Flash-Preview，整体 $S R = 21.2$ 、 $P G = 41.9$ ；GPT-5.2 为 20.6 / 40.6，Claude-Sonnet-4.6 为 20.6 / 39.3，Seed-1.8 为 20.0 / 39.0。最佳 CUA 是 Seed-1.8，整体 20.0 / 39.8；Claude-Sonnet-4.6 CUA 为 19.4 / 38.3，Gemini-2.5-Computer-Use 为 16.5 / 36.1，OpenAI-Computer-Use 为 16.5 / 35.8。

人类差距：novice player 达到 55.3 $S R$ / 64.1 $P G$ ，expert player 达到 77.1 / 82.6。也就是说，最强 agent 的平均进度 41.9 明显低于 novice 的 64.1，成功率 21.2 也远低于 55.3；论文“当前 agent 能做 meaningful partial progress，但还不能可靠完成任务”的结论由这个 gap 支撑。

Benchmark robustness：Qwen repeated full-benchmark rerun 的整体 $P G$ 标准差都在低个位数以内：Qwen3-VL-30B-A3B CUA 为 30.9±1.1，Generalist 为 30.7±1.1；Qwen3-VL-235B-A22B CUA 为 30.4±0.7，Generalist 为 30.1±0.5。对应 $S R$ 分别为 12.7±1.2、12.5±1.3、13.8±0.7、13.6±1.4。

GameWorld-RT 与 memory ablation：real-time 设置下，Qwen3-VL-235B-A22B CUA 是 6.2 sec/step、17.1 SR、33.2 PG，30B CUA 是 2.4 sec/step、15.6 SR、33.0 PG；Generalist 235B 是 6.4 sec/step、16.8 SR、34.0 PG，30B 是 3.4 sec/step、15.6 SR、32.9 PG。

memory rounds 从 0→1→2 时，235B Generalist 的 input tokens / sec/step / PG 为 1278 / 5.5 / 30.0，2171 / 6.8 / 30.1，3052 / 8.6 / 30.6；CUA 则为 1891 / 7.2 / 30.3，3771 / 10.1 / 29.0，5627 / 12.8 / 28.7。结论是：semantic trajectory 对 Generalist 有轻微帮助，但 CUA 长上下文更容易增加延迟和噪声。Action validity 与 failure modes：整体 mean IAR 为 0.8%；

多数强模型接近 0，但 GLM-4.6V Generalist 的 IAR=8.3%（7.6 NTC + 0.7 OOS），Qwen3-VL-30B-A3B Generalist 为 2.7%，UI-TARS-1.5-7B CUA 为 0.4%。论文把失败归为 instruction-following、perception、fine-grained action、long-horizon memory 四类；从 case studies 看，当前 agent 的主要瓶颈不是单一“看不懂画面”，而是感知、动作 grounding、延迟和历史目标维护的组合误差。按主表的 overall $P G$ 排名读结果：

Generalist 第一名是 Gemini-3-Flash-Preview：21.2 SR / 41.9 PG。Generalist 第二名是 GPT-5.2：20.6 SR / 40.6 PG。Generalist 第三名是 Claude-Sonnet-4.6：20.6 SR / 39.3 PG。Generalist 第四名是 Seed-1.8：20.0 SR / 39.0 PG。CUA 第一名是 Seed-1.8：20.0 SR / 39.8 PG。CUA 第二名是 Claude-Sonnet-4.6：19.4 SR / 38.3 PG。CUA 第三名是 Gemini-2.5-Computer-Use：16.5 SR / 36.1 PG。

CUA 第四名是 OpenAI-Computer-Use：16.5 SR / 35.8 PG。按 genre 看，结果更能解释 failure modes： Runner 的 PG 通常较高，说明模型能在高频重复动作中获得局部进度。Puzzle 中强模型的 PG 也较高，说明规则推理和离散规划仍是 MLLM 相对擅长的部分。Simulation 的 SR/PG 明显更低，说明开放式资源收集和长程协调仍困难。Platformer 的表现受跳跃物理、空间 grounding 和 timing 共同影响。Arcade 在不同模型间差异大，反映动态目标 tracking 和反应速度的混合难度。

Human gap 的意义： Novice human 的 64.1 PG 已显著高于最强 agent 的 41.9 PG。Expert human 的 82.6 PG 与 77.1 SR 显示这些 games 对人类并非不可完成。因此低分不是任务定义过于抽象，而是 agent interaction 能力不足。Agent 的 PG 高于 SR，说明它们能推进部分目标，但缺乏稳定完成能力。Repeated evaluation 的证据：

Qwen3-VL-30B-A3B CUA：12.7±1.2 SR / 30.9±1.1 PG。Qwen3-VL-30B-A3B Generalist：12.5±1.3 SR / 30.7±1.1 PG。Qwen3-VL-235B-A22B CUA：13.8±0.7 SR / 30.4±0.7 PG。Qwen3-VL-235B-A22B Generalist：13.6±1.4 SR / 30.1±0.5 PG。10 次 full-benchmark rerun 下 overall PG 标准差只有 0.5–1.1，支持 benchmark aggregate 的稳定性。Figure 4 进一步显示 variance 主要集中在少数控制敏感或高难游戏，而不是全局随机漂移。

GameWorld-RT 的证据： Qwen3-VL-235B-A22B CUA：6.2 sec/step，17.1 SR，33.2 PG。Qwen3-VL-30B-A3B CUA：2.4 sec/step，15.6 SR，33.0 PG。Qwen3-VL-235B-A22B Generalist：6.4 sec/step，16.8 SR，34.0 PG。Qwen3-VL-30B-A3B Generalist：3.4 sec/step，15.6 SR，32.9 PG。30B 模型更快但 PG 没有决定性超过 235B，说明 real-time setting 同时受 reasoning quality 和 latency 制约。

RT SR 仍低，说明“快一点”不能自动解决动作窗口和长程目标维护问题。Memory ablation 的证据： Generalist 0 rounds：1278 input tokens，5.5 sec/step，30.0 PG。Generalist 1 round：2171 input tokens，6.8 sec/step，30.1 PG。Generalist 2 rounds：3052 input tokens，8.6 sec/step，30.6 PG。CUA 0 rounds：1891 input tokens，7.2 sec/step，30.3 PG。CUA 1 round：3771 input tokens，10.1 sec/step，29.0 PG。

CUA 2 rounds：5627 input tokens，12.8 sec/step，28.7 PG。结论是 Generalist 对少量 trajectory memory 有轻微收益，而 CUA 受到 latency 和视觉上下文噪声的负面影响更明显。Invalid action diagnostics 的证据：

Overall mean IAR 是 0.8%，说明 parser/action layer 整体没有把 benchmark 变成“格式测试”。GLM-4.6V Generalist 的 8.3% IAR 是异常高值，主要来自 NTC 7.6%。Qwen3-VL-30B-A3B Generalist 的 2.7% IAR 说明小模型更容易违反 semantic tool-call format。UI-TARS-1.5-7B CUA 的 0.4% IAR 虽低，但仍暴露低层 action schema mismatch。GPT-5.2、Kimi-K2.5、Seed-1.8 等模型接近 0，说明高分瓶颈更多是决策/控制，而非格式。

Case studies 的结论： Mario interface comparison 显示同一 backbone 在 CUA 和 Generalist 下的 trajectory 会因 grounding 粒度不同而分化。Minecraft Clone 显示 agent 能反复执行局部正确动作，但会在任务闭环上失败。Flappy Bird 显示连续 frame 的视觉差异很小，但 action timing 的可执行后果差异很大。这些 case 支撑 paper 的核心判断：游戏 agent 的失败来自 perception、planning、memory、latency、action execution 的耦合。

Limitations / caveats： Semantic action list 仍需要人工设计，新增游戏的 control alignment 成本没有消失。Browser games 的状态可验证性强，但不等同于所有真实 GUI/robotic tasks。Main benchmark 的 paused protocol 有助于隔离 decision quality，但低估了真实部署中的 latency 压力。API model 成本较高，附录成本估算只覆盖列出的 hosted models，不包含 open-weight inference 成本。

Released code 与 paper appendix 在 semantic identifier field 上有差异，阅读实现时应以 github_ref 对应版本为准。

Paper Notes

探索

GameWorld: Towards Standardized and Verifiable Evaluation of Multimodal Game Agents

GameWorld: Towards Standardized and Verifiable Evaluation of Multimodal Game Agents

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Benchmark 结构与任务定义

3.2 Agent interface：CUA vs. Semantic Action Parsing

3.3 State-verifiable evaluation 与指标公式

3.4 Released code 对照

3.5 关键可视化与 case studies

4. Experimental Setup (实验设置)

5. Experimental Results (实验结果)

目录