把游戏开发做成世界模型的可验证数据引擎,RLHEV主分0.681

Agentic Game Development as a Verifiable Trajectory Data Engine for Scaling World Models

Pengfei Zhou, Hexin Wang, Zhengfeiyang Zhang, Yixing Ma, Zhenglin Wan, Kaipeng Zhang, Wangbo Zhao, Yang You

cs.AI

2026-08-26

新国大等人主张用游戏引擎检查加开发者验收做世界模型的后训练奖励。UnitySceneBench上完整RLHEV主分0.681,比最强非完整基线高0.098。

这篇在解决什么

世界模型常见扩法是再爬一批视频、再堆算力。代码智能体能后训练,是因为编译器和测试给出便宜、可复现的奖励。空间生成还在用 CLIP、FVD、MLLM-as-judge 这类模糊代理,噪声大、有偏、可被钻。人的终态偏好又贵又窄,撑不起代码那种迭代环。

作者把这叫可验证性瓶颈:缺的不是数据量,是能给结构对错打分的反馈通道。游戏引擎已经在做这件事:碰撞、物理稳定、导航网格可达、脚本是否报错、有界试玩能否摸到目标。开发者再决定这关该不该收。双通道对齐代码里的「测试通过 + 人审意图」。

方法

RLHEV 把奖励拆开。引擎检查是密的、可复现的结构项,人的接受/拒绝是稀的、管是否合格。完整模型按 0.65 人 + 0.35 引擎混合。硬门必须过,软诊断以惩罚项进目标。

AWoMo 是套在开发工作流里的智能体世界模型:提议场景编辑,引擎渲染并局部化失败,智能体修复,人审终止。全程写入 Unified World-Development Protocol,一条轨迹记下意图、对象、状态、动作、引擎输出、渲染证据、人审和残留风险。同一表示既可做理解(资产分类)也可做生成(场景程序)。

奖励按梯子往上爬:能加载,物理说得通,可导航且目标可达,再到可玩。论文把这当成可证伪议程,列了三条预言:可验证奖励应优于模糊代理;加人审应优于纯引擎;源域轨迹应能迁到分布外和跨引擎。

结果

UnitySceneBench 是 200 条 Unity 资产编辑评测,学习方法用 720 条训练、8 个随机种子。完整 RLHEV 的八种最佳主分为 0.681,准确率 0.665,平衡准确率 0.665,F1 0.733,AUC 0.690,比最强非完整基线高 0.098 主分、高 0.120 准确率。生成侧,640 条预算到 0.8106,满 720 条到 0.8197,引擎-only 的 RLVR 是 0.7934。主分定义是 0.45 平衡准确率 + 0.25 准确率 + 0.20 F1 + 0.10 AUC。

分布外,源域预训练再在目标上适配,评委分从 0.25 到 0.75。跨引擎更小:Unity→Unreal 0.25→0.35,Unity→Godot 0.15→0.35。跨引擎没有可直接比的引擎标量,用人工复核过的 MLLM 量规。

具身侧,AWoMo 不是独立策略,是给环境数据做增强。相对原基线:R2R 成功率 +0.79%,Gymnasium MuJoCo 回报 +9.96%,D4RL Gym-MuJoCo 标准化分数 +48.43%。

为什么重要

把「多爬视频」换成「给空间智能找编译器」,这个判断值得跟。游戏开发轨迹记录的是意图、失败、修复和验收,成品资源本身没有这些过程监督。如果后训练真能吃上双通道奖励,世界模型才有机会像代码模型那样递归改进。

当前数字是试点,不是已经转起来的数据引擎。Unity 分类和生成上,人机双验证最强;跨引擎和 R2R 的增益很小。贡献首先是议程和协议,系统还没有 demonstrably 自举。

局限与存疑

作者自己列了几条反对意见。游戏不是现实,文中没有真机扫描、真机器人或 sim-to-real 闭环。引擎是部分验证器,松的碰撞或导航检查一样能被优化绕开。源引擎轨迹可能过拟合一种运行时。实验还证明不了完整游戏质量、人因有效或具身部署。

读数还要再打折。主结果是八种子里的最佳,均值和方差另见图。OOD 跨引擎用 MLLM-as-judge,正文刚批评过这种代理当训练奖励,评测又请回来,虽说有人工复核。R2R +0.79% 接近噪声。D4RL +48.43% 幅度大,但是诊断设置。200 条小基准,720 条训练。递归自改进(一个模型建关、另一个模型去玩)仍是下一步,不是已有结果。

术语

原文与代码

相关论文

全部论文解读