568个网页游戏喂出9B玩家：环境先修好，模型再把进度翻倍

Game2Player 放出了项目页、代码和模型链接。它想解决一个很具体的问题：视觉 agent 缺足够多、足够多样、还能自动判分的游戏环境。视觉 agent 可以理解成能看屏幕、操作界面的模型。

常见做法是找一小批游戏，或者收人类游玩数据。前者规模有限，后者成本高。Game2Player 把网页游戏改造成可验证环境，让 coding agent 和 VLM 一起参与环境维护和数据生产。

流程不复杂。Scout 先按来源、引擎、能否拿到游戏状态筛游戏。Builder 把游戏适配成离线可玩，通过 game_api.js 暴露状态，再定义任务。任务有开始条件、进度和成功检查，进度从游戏状态计算。Coding Player 写 Python 策略，读状态并在实时环境里执行动作。VLM Player 只看截图，靠推理选动作，推理时游戏暂停。玩家遇到按键没反应，或者策略需要某个没暴露的状态变量，就把问题作为 Reports 交回 Builder。Builder 看轨迹，修环境或修任务检查，玩家再重试。按键没反应，返工的是环境，不是让模型硬猜。

这个循环产出两类东西。一类是验证过的环境，另一类是轨迹数据。轨迹记录观察、动作和任务进度。游戏集合覆盖 568 个网页游戏，转成 3,436 个可验证任务。已收集数据来自 396 个游戏、2,251 个任务，共 15,707 条轨迹、1,563,640 步、307 小时。Coding Player 贡献 12,856 条轨迹，VLM Player 贡献 2,851 条。数据还在增长。

训练用 progress-weighted SFT，给推进任务的步骤更高权重。模型基于 Qwen3.5-4B 和 Qwen3.5-9B。9B 版本只从像素玩，在 GameWorld 上进度从 30.0 升到 53.1，项目方称超过 Qwen3.8-Flash-Next；在 PlayerBench 上从 14.3 升到 31.2。4B 版本在 GameWorld 上从 26.9 升到 49.5，在 PlayerBench 上从 15.9 升到 31.1。两个规模都接近翻倍。

PlayerBench 是留出集，50 个游戏、287 个任务，比 GameWorld 的 34 个游戏、170 个任务更难。项目方给出的对比里，GPT-6.1 Sol 在 PlayerBench 上的进度也只有 62.6%。一个细节能看出模型学到了操作：Qwen3.5-4B 几乎不设置按键持续时间，只有 1% 的按键带 hold time；Game2Player-4B 把这个比例提到 47%。

怎么用。项目页有演示、排行榜和轨迹示例，GitHub 仓库有完整流程。安装需要 Python 3.12，以及 Codex CLI 或 Claude Code。填好 examples/campaign.yaml 里的游戏 ID、标题和来源 URL，跑 tools.game_pipeline 可以生成环境、任务、策略和轨迹。想直接试玩用 play.py，想评估用 rollout 配置。模型放在 HuggingFace。PlayerBench 也给了重建说明，第三方游戏构建和素材不随仓库分发。

代码、模型权重和基准任务说明用 Apache-2.0 许可。游玩数据还在版权和再分发审查中，第三方游戏环境因授权限制不直接分发。这类工作真正留下的东西，可能是一套能持续修环境、产数据的流程。模型会换，环境修得动，数据才能继续长。

链接：项目页 代码 模型