智能体游戏开发：面向世界模型规模化的可验证轨迹数据引擎

把游戏开发变成“引擎检查+人类验收”的可验证奖励环境，驱动世界模型自我改进

前置知识

世界模型（World Model）

指能对物理/三维世界的状态与动态进行建模的生成式模型，输入可以是文本、图像或视频，输出可以是视频帧、3D 场景或可交互环境。它既要“理解”世界（从观测推断隐藏状态、几何、物理），也要“生成”世界（按意图构造场景并预测演化），是空间智能的核心载体。

本文的核心主张就是“世界模型的扩展需要数据引擎而非更多爬取视频”，全文的 RLHEV、AWoMo 都是世界模型后训练的方案。

RLVR：可验证奖励强化学习

Reinforcement Learning from Verifiable Reward。当任务存在一个廉价的自动验证器 $V:\mathcal{X}\times\mathcal{Y}\to\mathbb{R}$（如编译器、单元测试、数学答案比对）时，可以用它的输出作为奖励对预训练模型做 RL 后训练。代码与数学推理模型的成功很大程度上归功于此：验证成本远低于生成成本。

本文把“可验证性”从代码/数学推广到空间生成，提出的 RLHEV 就是“人类+引擎”版的可验证奖励范式，理解 RLVR 才能理解其动机。

模糊代理奖励（Fuzzy Proxy Reward）

指用 CLIP 相似度、FVD、JSD、MLLM-as-judge 等间接指标近似评估生成质量的做法。论文将其误差分解为 $R_f(x,y)-Q^*(x,y)=\varepsilon(x,y)+b(x,y)$：零均值噪声 $\varepsilon$ 摊薄每个样本的收益，系统偏差 $b$ 更危险——沿着可利用方向优化代理分会推高分数却降低真实质量（reward hacking）。

作者认为视频/3D 生成正因为只有模糊代理奖励才无法像代码那样做 RL 后训练，这是全文论证的“不可验证性税”的技术核心。

Bitter Lesson（苦涩教训）

Sutton 提出的经验法则：能随算力扩展的通用方法最终胜过手工设计的先验。本文给出一个重读版本：游戏、代码、数学之所以能随算力规模化，不仅因为方法通用，更因为它们自带可执行的成功判据（游戏规则、程序执行、数值检查）；缺少反馈通道的领域只能获得“模仿上限”内的进步。

论文的中心论题就是空间智能正撞上“数据版的 Bitter Lesson”，标题中的数据引擎概念直接建立在这条重读之上。

游戏引擎的结构检查器

Unity/Unreal/Godot 等引擎在运行场景时会执行大量可自动判定的检查：碰撞体是否穿透、物理 rollout 是否稳定、NavMesh 导航网格是否连通（可达性）、脚本是否报错或死锁、以及给定智能体和随机种子下有界的可玩性探针（能否到达目标）。这些检查廉价、可复现、且难以被外观指标欺骗。

引擎检查是 RLHEV 中“稠密结构奖励”的来源，也是“游戏开发=可执行世界规约”这一关键类比的具体体现。

RLHF 与人类验收

RLHF 用人类对模型输出的偏好标注训练奖励模型再做强化学习。本文认为把人类判断只当作对最终输出的偏好标签，带宽太低、成本太高；更好的做法是把人类评审嵌入开发工作流，借引擎渲染证据做“接地”的最终验收（接受/拒绝），即 RLHEV 中稀疏但权威的那一半信号。

理解 RLHEV 与 RLHF 的差别（嵌入工作流的验收 vs 对最终产物的偏好）是读懂其奖励设计 $0.65\,\text{human}+0.35\,\text{engine}$ 的前提。

研究动机

当前扩展世界模型的主流策略是“抓更多视频、训更大模型、烧更多算力”，作者认为这在数据层面是低效的，根源是空间生成缺少廉价可靠的验证器。视频生成质量主要靠 FVD、CLIP 相似度和 MLLM-as-judge 等模糊代理打分，这些信号噪声大、有系统偏差、可被过优化，无法提供 RL 后训练所需的确定性奖励，于是训练信号退化为对爬取视频的下一帧预测，学到渲染统计却学不到支撑 3D 编辑与交互的隐藏世界状态。3D 生成的问题在源头：最大的精选 3D 资产库只有约 $10^7$ 个物体，而 2D 视觉语言与语言模型背后是 $10^9$–$10^{12}$ 量级的图像与 token，且缺少能同时检查物理合理性、语义与任务有用性的廉价联合验证器，常常只能蒸馏 2D 先验。学习型世界模拟器最惨：监督它需要密度和精度都极昂贵的真实世界 3D 真值（深度、几何、动力学、接触）。作者把这一系统性代价称为“不可验证性税”（unverifiability tax）——没有可靠反馈通道，进步只能靠堆数据、算力、扫描和人工标注来购买。

本文的目标是本文的目标是为空间智能建立一条类似代码智能体“编译器+测试+人类评审”的反馈通道，具体做法是把游戏开发变成世界模型的递归数据引擎：游戏引擎自动提供稠密、可复现、难作弊的结构性检查（碰撞穿透、物理稳定性、NavMesh 可达性、脚本执行、有界可玩性探针），开发者提供稀疏但与真实目标高度对齐的最终验收判断。基于这个双重验证环境，论文提出 RLHEV（Reinforcement Learning with Human-Engine Verification）后训练范式与 AWoMo（Agentic World Model）智能体世界模型：AWoMo 在开发者工作流中提出场景编辑、渲染、观察引擎检查与人类评审、执行修复，并把每一条“提议—检查—修复—评审”的多模态轨迹转成训练数据，形成“更强模型→更好候选世界→更丰富轨迹→更强模型”的递归飞轮。作者还给出可证伪的验证路线图 P1/P2/P3（结构效率、人-引擎增益、泛化迁移），用受控实验回答“这个信号是否真的有效”而不是停留在立场主张。

与已有工作不同的是，本文的独特切入有三点。第一，对象不同：以往工作要么把游戏当智能体的游玩环境（ALE、MineDojo、BALROG），要么检查“通过的游戏”或最终资产（WorldCoder、GameGenVerifier、GameDevBench），本文把“游戏开发过程本身”当作数据——真正有训练价值的是带对象链接的 edit/check/fix 轨迹：创建者意图、状态应为何、改了什么、引擎检查是否通过、人类是否接受。第二，理论重构：作者重读 Bitter Lesson，主张决定领域进步的是反馈通道而非数据或算力本身，并指出代码可执行、游戏引擎可运行，因此“验证器早已存在，它的名字叫游戏引擎”。第三，权限分工：引擎只负责可形式化的稠密结构验证，人类保留最终验收权，引擎不许成为有偏 oracle，这让人类反馈因有引擎渲染证据接地而更客观、更高带宽。此外每个主张 P1/P2/P3 都配有明确 falsifier（例如“模糊奖励训练在等算力下持平或超过可验证奖励训练”即证伪 P1），使立场论文具备可检验性。

核心方法

直觉来自代码智能体：代码可执行，编译器、测试与运行时提供稠密低成本反馈，开发者再对通过测试的补丁做全局验收，这种“人-编译器双重验证”让 RL 后训练持续有效。AWoMo 把同一结构搬进空间生成：用引擎编码的场景是可执行的世界规约，引擎是它的解释器与部分验证器。AWoMo 围绕全模态世界模型定义四个接口：intent 接收任务简报与设计约束；action 输出场景程序、资产编辑、工具调用与修复动作；verification 记录引擎检查（加载、碰撞、物理稳定性、NavMesh 可达性、脚本执行、有界可玩性探针）；review 记录开发者接受、拒绝与批评。执行循环为 propose→render→verify→repair→review，每轮存为 UWDP 结构化轨迹，构建世界的同一工作流同时产出训练数据。RLHEV 的奖励是带硬约束的受限选择：$$\max_{y\in\mathcal{Y}}\;U_H(x,y,h)-\sum_{i=1}^{n}\lambda_i(h)\,\phi_i(C_i(x,y))\quad\text{s.t.}\;G_j(x,y)=1,$$其中 $U_H$ 是人类验收效用（接受 1、拒绝 0），$C_i$ 是引擎诊断检查，$\phi_i\ge 0$ 是单调罚函数，$G_j$ 是引擎硬性门槛。实验中人类与引擎信号按 0.65+0.35 加权组合。

核心创新有三层。第一，RLHEV 显式划分验证权限：引擎提供稠密、可复现、难作弊的结构奖励（碰撞查询不会被逼真纹理骗过），人类提供稀疏但权威的最终验收，这一“权限分工不变量”既防止引擎变成有偏 oracle，也防止模糊代理被过优化。第二，UWDP 把散落在编辑器存档、资产、截图、日志、QA 笔记中的开发过程统一为类型化的 state-action-check-review 多模态轨迹 $u_t=(b,\,o_t,\,s_t,\,a_t,\,g_t,\,v_t,\,h_t,\,\rho_t)$：$b$ 是设计意图，$o_t$ 是对象/关系/区域标识，$s_t$ 是状态字段，$a_t$ 是编辑动作，$g_t$ 是引擎输出，$v_t$ 是渲染证据，$h_t$ 是评审决定，$\rho_t$ 链接修复与残余风险——关键在于保留了“为何接受/拒绝”的理由。第三，奖励是可加档的阶梯：validity（能加载、流形完好）→物理合理性（稳定 rollout）→功能正确（可导航、目标可达）→可玩性，区别于静态 CLIP 分数，可随模型进步不断加入新的有界引擎探针与人类标准。

方法步骤详情

方法分数据采集与训练评测两段。UWDP 采集六步：第一步，解析任务简报与参考图为类型化对象、关系、证据标签和不确定性；第二步，在引擎中构建代理或执行资产编辑（输入动作 $a_t$，输出场景程序/资产变更）；第三步，记录引擎快照、渲染证据与 harness 检查（输出 $g_t$、$v_t$）；第四步，把每个失败转成类型化修复动作，如碰撞穿透→修 collider、NavMesh 断裂→修补连通；第五步，迭代“提议—渲染—检查—修复”直到引擎测试通过且评审者返回 accept，人类验收协议把引擎可查字段与人类专属字段（brief 对齐、视觉可读性、产品契合）分开标注；第六步，存储含监督的完整轨迹，用于 next-edit prediction、偏好建模、RL 的 state-action-reward 更新三类目标。评测侧：UnitySceneBench（200 例 Unity 资产编辑分类）上比较 Zero-shot CLIP、Fuzzy Proxies、SFT、Offline RLHF、Engine-based RLVR 与 Full RLHEV，学习方法用 720 个训练实例、每方法 8 种子；泛化侧做 Unity 分布内 OOD 与 Unity→Unreal/Godot 跨引擎迁移（scratch 对比 source 预训练+target 适配）；具身侧用 AWoMo 生成的环境数据增强 R2R、Gymnasium MuJoCo、D4RL Gym-MuJoCo 策略训练。

技术新颖性

概念层面，论文把 Bitter Lesson 重新表述为“反馈通道决定可扩展性”，并提出可证伪命题：若开发轨迹与人-引擎奖励不能改善 OOD 泛化，则游戏开发不构成数据引擎，这使立场文章具备实验可检验性；“不可验证性税”给视频/3D/模拟器三条路线的共同瓶颈一个统一名字。技术层面，UWDP 是首个覆盖游戏开发全流程（而非仅最终产物）的多模态轨迹协议，把接受/拒绝的理由显式保存在 $h_t$ 与 $\rho_t$ 中；RLHEV 的奖励形式化区分零均值噪声 $\varepsilon$ 与系统偏差 $b$（$R_f-Q^*=\varepsilon+b$），说明模糊代理为何在规模放大时被过优化，而“引擎保真度+人类权威性”恰好分别修复这两类误差。实验层面，作者诚实处理跨引擎无原生可比标量的问题：判分器遵循与人类评审相同的 accept/reject rubric、逐条经人工核验，仅作受审计的评估工具而非训练奖励。与 Game-RL、RLVR-World、WorldCoder、Agent2World 的本质差异：训练对象不是通过的游戏或分数，而是可培养“下一个 builder”的对象级 edit/check/fix 轨迹。

**Figure 3**: A shared executable scene-program representation for understanding and generation

**Figure 7**: UWDP trace recorded by our AWoMo（正文引用：Figure 7 illustrates a trace recorded by our UWDP）

实验结果

四组受控实验支撑核心主张。理解侧 UnitySceneBench（200 例资产分类）：主指标 $\text{Primary}=0.45\times$BA$+0.25\times$Acc$+0.20\times$F1$+0.10\times$AUC，Full RLHEV 在 8 种子取最好时达 Primary 0.681、accuracy 0.665、balanced accuracy 0.665、F1 0.733、AUC 0.690，超最强非完整基线 +0.098 Primary、+0.120 accuracy；奖励为 0.65 人类 + 0.35 引擎，验证 P2。扩展侧：预算 40–720 实例、每格 8 种子，720 实例时生成质量 0.8197 高于 Engine-based RLVR 的 0.7934，640 实例时已 0.8106。泛化侧：source 预训练+target 适配使 Unity 分布内 OOD 从 0.25 升至 0.75，跨引擎 Unity→Unreal 0.25→0.35、Unity→Godot 0.15→0.35，且损失更低、proxy 分更高，收益随分布差异增大而收窄但仍为正，支持 P3。具身诊断：AWoMo 生成环境数据增强训练，相对原始基线 R2R 成功率 +0.79%、Gymnasium MuJoCo 回报 +9.96%（naive augmentation 仅 +5.07%）、D4RL Gym-MuJoCo 归一化分数 +48.43%（naive aug +39.68%）。作者强调这些是诊断性 pilot 结果，递归自改进尚未闭环。

**Table 1**: A compact UWDP instance example（正文引用：Table 1 gives an example）

**Figure 4**: Unity asset classification evaluation on UnitySceneBench

**Figure 5**: Scaling with different numbers of training samples and tested on UnitySceneBench

**Figure 6**: Generalization and embodied diagnostic evaluations

查看结构化数据

任务	指标	本文	基线	提升
Unity 资产编辑分类（UnitySceneBench，200 例）	Primary（0.45 BA + 0.25 Acc + 0.20 F1 + 0.10 AUC，best-of-8 seeds）	Full RLHEV 0.681（Acc 0.665 / F1 0.733 / AUC 0.690）	最强非完整基线（如 Engine-based RLVR）	+0.098 Primary，+0.120 accuracy/balanced accuracy
Unity 资产生成质量（720 训练实例）	生成质量分数（0–1，8 seeds）	Full RLHEV 0.8197	Engine-based RLVR 0.7934	+0.0263
Unity 分布内 OOD 迁移	MLLM-as-judge 归一化分数（0–1，经人工核验）	Target-adapted 0.75	从零训练（scratch）0.25	+0.50
Unity→Unreal 跨引擎迁移	MLLM-as-judge 归一化分数（0–1）	Target-adapted 0.35	从零训练 0.25	+0.10
Unity→Godot 跨引擎迁移	MLLM-as-judge 归一化分数（0–1）	Target-adapted 0.35	从零训练 0.15	+0.20
R2R 具身导航（AWoMo 环境数据增强）	相对原始基线的成功率提升	+0.79%	原始基线（0%）	+0.79%
Gymnasium MuJoCo（AWoMo 环境数据增强）	相对原始基线的 rollout 回报提升	+9.96%	naive augmentation +5.07%	+4.89 个百分点
D4RL Gym-MuJoCo（AWoMo 环境数据增强）	相对原始基线的归一化分数提升	+48.43%	naive augmentation +39.68%	+8.75 个百分点

局限与改进

作者承认的局限：实验是诊断性/试点规模——UnitySceneBench 仅 200 例、训练实例上限 720，跨引擎与具身实验均为小样本；跨引擎资产质量没有引擎原生可比标量，只能依赖受审计的 MLLM-as-judge，虽然每条分数经人工核验，但与全文“批判模糊奖励”的立场存在内在张力；“递归自我改进”飞轮只是路线图，尚未真正闭环演示；泛化结论需更大规模研究确认。我自己的观察：其一，0.65/0.35 的人-机奖励配比没有消融或敏感性分析，读者无法判断结论对该超参的依赖程度；其二，best-of-eight 的报告方式偏向乐观，图 5 的均值±std 才是稳健证据，两者结论强度不同；其三，分布迁移 0.25→0.75 的巨大跳变可能受目标域训练集规模、判分器偏差或预训练数据重叠影响，缺少更细的控制实验；其四，R2R 上 +0.79% 的提升幅度很小且无显著性检验；其五，人类验收的实际吞吐成本（每条轨迹需多少开发者分钟）未量化，“标签成为开发副产品”的经济性主张仍停留在论证层面；其六，实验生态高度绑定 Unity，Unreal/Godot 仅作迁移目标，跨引擎检查器的工程差异被弱化。

独立分析的弱点

弱点一：规模与统计功效不足。200 例基准、720 训练实例、best-of-eight 报告，8 种子下方差仍显著（图 5a 中 Offline RLHF 与 Full RLHEV 误差带部分重叠）。改进：扩至 $10^4$–$10^5$ 轨迹并主表只报 seed 均值与显著性检验。弱点二：对 MLLM-as-judge 的依赖，rubric 一致性与可复现性弱于引擎指标，存在“用模糊信号验证反模糊主张”的悖论。改进：把 Unreal/Godot 产物统一导入单一引擎跑同一套碰撞/NavMesh/物理检查。弱点三：超参透明度不足，0.65/0.35 人-机权重、罚函数 $\phi_i$ 与权重 $\lambda_i(h)$ 均未消融。改进：权重扫描与 engine-only/human-only 细粒度消融。弱点四：人类验收吞吐未量化，真实开发评审每条需数分钟，规模化时成本可能回升，威胁“低成本标签”卖点。改进：主动学习与置信度过滤，只 escalate 边界样本。弱点五：具身提升不均衡，R2R 仅 +0.79% 可能落入噪声。改进：增加环境多样性并报告置信区间。弱点六：UWDP 依赖开发者如实标注验收理由，标注噪声对训练的影响未评估。

未来方向

作者提出的方向：下一个里程碑是递归自我改进闭环——AWoMo 构建可执行世界，游戏智能体探索、测试并评估可玩性，playtest 结果成为下一代世界模型的训练信号；把可玩产物、held-out 引擎检查、held-out 人类验收与游戏智能体 playtesting 连成更紧的循环；并向更自主的 builder/explorer 双智能体循环演进（类似围棋自博弈的复合改进），减少人工介入。基于成果可延伸：把 UWDP 开放为社区标准，从 Unity Asset Store、modding 生态、工作室遥测采集真实开发轨迹，检验“标签是开发副产品”的经济性主张；把奖励阶梯升级为 learned verifier，用模型预测哪些检查会失败并优先修复；迁移到机器人仿真（Isaac Sim）与工业数字孪生等有执行器真值的领域；研究跨引擎通用中间场景表示（神经+符号混合的场景程序）以压缩跨引擎迁移损失；在 AWoMo 增强的环境数据上绘制更系统的具身 scaling 曲线。

复现评估

开源情况：论文声明 agentic artifacts 已发布于 https://github.com/LanceZPF/cardinal-preview。数据条件较好：UnitySceneBench 200 例基于公开 Unity 资产构建，训练集 720 实例、8 种子，泛化与具身基准（R2R、Gymnasium MuJoCo、D4RL）均为公开环境。复现难点有三：一是需搭建 Unity/Unreal/Godot 三套引擎检查 harness（碰撞、NavMesh、物理 rollout、可玩性探针），工程量集中在引擎侧；二是人类验收通道只在附录 B.1 描述，复现 0.65 权重的人类信号需自建 accept/reject 评审流程；三是 MLLM-as-judge 需对齐论文所用模型与 rubric 并复刻“逐条人工核验”流程才能公平对比。算力上，被训练的是资产分类/编辑规模模型而非基础模型，单机多卡即可完成主体实验，全方法×预算×种子网格约几十次训练。综合：代码与基准复现度高，人机混合与跨引擎部分需额外工程，总体难度中等。

智能体游戏开发：面向世界模型规模化的可验证轨迹数据引擎 Agentic Game Development as a Verifiable Trajectory Data Engine for Scaling World Models