RLHEV：游戏引擎当裁判，世界模型拿到 RL 能用的分数

如果有人问，怎么让世界模型变得更强？标准答案大概是两件事：更多视频，更多算力。从 Sora、Genie 到 Genie 3，论文把它们归为同一条路线，把互联网上能爬到的视频倒进越来越大的算力池，画面一年比一年像真的。但 RLHEV 这篇 2026 年 8 月的 arXiv 预印本注意到，这个配方里藏着一个没人管的空位：生成一个场景之后，谁来告诉模型，这个场景到底对不对？

对视频生成来说，这个空位尤其刺眼。给模型灌海量"猫在跳桌子"的视频帧，它能学会像素级别的猫，却学不会物理级别的猫，因为它从来没有收到过一条反馈，说"这只猫落地时腿穿过了地板"。人类能判断，但论文算过这笔账：人的审美判断太贵、带宽太低，撑不起迭代式的后训练。于是自动化的打分只能交给 CLIP 相似度、FVD 这类代理指标，或者干脆让多模态大模型当评委。论文把这一整类信号叫作 fuzzy proxy（模糊代理奖励），并给它们下了三个字的判语：噪、偏、可被游戏化。这就是它命名的「可验证性瓶颈」（verifiability bottleneck）：规模上去了，但没人能给生成结果打一张可信、可复现的分数。RLHEV

更多视频、更多算力，为什么喂不出更强的世界模型？

模糊代理为什么撑不起强化学习？这不是一句抽象的抱怨，而是有机制证据的。MARVL 这篇工作把 CLIP 分数当稠密奖励接到机器人操作任务上，系统地诊断出三种结构性失败：CLIP 的图像表征被相机视角主导，同一个任务换个视角就变成另一个簇，奖励跟着相机跑而不跟着任务跑；沿着正确轨迹打分，分数剧烈抖动，越靠近目标反而不升反降；文本与图像的语义对齐只有弱对角，噪声弥漫。这些不是某个模型的 bug，而是 embedding 几何决定的：奖励在追踪视觉变化，而不是追踪任务进度。RL 拿到的梯度方向本身就是错的，越练越歪。MARVL

论文把这套诊断展开到三个具体领域，算的就是一笔「不可验证税」。视频生成没有便宜的 ground-truth 判卷器，只能靠 FVD 加人工评分；3D 生成被数据饿着肚子，可公开的资产集只有千万级规模，图像侧却是十亿到万亿量级，而且没有一个验证器能把物理合理性、语义、任务有用性合在一起判；学到一半的世界模拟器需要深度、几何、动力学、接触关系这些天生昂贵的标注。每个领域都在为"没有可验证反馈"额外付税：数据更贵、判分更糊、RL 使不上劲。这篇论文选择在 2026 年夏天发声，正赶上世界模型从"生成什么都行"转向"生成要能被用起来"的关口。RLHEV

论文的开篇图把两种世界观直接摆在一起，这正是文章最想让你先看到的东西。

图注：论文 Fig.1 的概念图。上方是传统空间数据 pipeline，稀疏的人或模型标注被压成嘈杂的最终输出奖励，反馈通道只有一个。下方是游戏开发循环，人的意图与反馈、引擎执行、开发轨迹、渲染证据、局部验证失败连成一圈，每个环节都在产生信号。RLHEV

注意上下两行的差别不是精度，而是反馈的颗粒度。传统 pipeline 只在"最终输出"这一个点上有奖励，中间过程全是黑箱；游戏开发循环则把每一步都变成了可检查的脚印。换个角度看同一件事，2026 年 2 月最前沿的世界模型 RL 后训练 WorldCompass，把序列级奖励细化到逐片段，方向是对的，但它的信号来源仍然是 3D 轨迹估计加 HPSv3 这类机器学习代理，不是结构化检查。WorldCompass

所以结论是：世界模型的扩张卡在奖励信号上，而不是卡在数据量上。堆更多视频，只会让模型更像视频，不会让模型更懂世界。问题是，可验证、低成本、能复现的判分，究竟要从哪里来？下一章有一个现成的参考答案，它在代码领域已经跑通了。

代码智能体凭什么越练越强？因为奖励是「可验证」的

答案藏在 LLM 后训练这两年最陡峭的一条增长曲线上。DeepSeek 团队先训了一个纯 RL 版本 R1-Zero，没有一句人工标注的思维链冷启动，只在数学和代码题上做强化学习，AIME 数学竞赛的 pass@1 从 15.6% 涨到 77.9%。让这个奇迹成立的东西只有一个：规则化奖励。数学题判最终答案对不对就行了，代码题让编译器跑测试集。奖励函数的全部内容就是 accuracy 加 format，没有任何神经网络评委。DeepSeek-R1

论文自己的训练 pipeline 把这一点画得很直白：三条路线从同一个 base 出发，最终汇聚到 DeepSeek-R1，途中标明的奖励类型全是硬规则或偏好信号。

图注：DeepSeek-R1 论文的多阶段训练 pipeline 图。从 DeepSeek-V3 Base 分出三条路线，一路走纯 RL 得到 R1-Zero，一路经冷启动 SFT 和带语言一致性约束的规则化 RL 得到 R1 Dev-1/Dev-2，一路混合 SFT 后做规则化加偏好奖励得到 R1 Dev-3，最终汇成 DeepSeek-R1。图中可见的奖励标签全部是 Accuracy & Format、Rule-based、Preference 这类规则化类型。DeepSeek-R1

RLVR（可验证奖励的强化学习，Reinforcement Learning with Verifiable Rewards）能 scale 的机制很简单：编译器加测试集是一台廉价的判卷机器，答案当场就能批改，批改结果稠密，每一道题、每一个回合都有分，而且它不会累、不会偏、不能被廉价贿赂。代码智能体把这个逻辑再推进一步。ReVeal 把长程编程任务拆成生成、验证交替的多回合循环，模型每轮写代码、自己合成测试用例、用 Python 解释器执行，把通过还是失败写进下一回合的条件，验证从配角变成了与生成并列的一等公民。在 LiveCodeBench 上，Pass@1 从第一回合的 34.8% 一路涨到第 25 回合的 38.7%。ReVeal

这条路的边界条件同样值得记一笔。DeepSeek-R1 刻意在推理任务上不用神经奖励模型，理由是它在大规模 RL 下太容易被 hack；论文自己也在 CodeForces 这类难以构造完整测试集的任务上观察到 reward hacking，奖励在涨，真实分数在跌。ReVeal 的回应是把验证做得更细，模型自己生成测试用例，自己拿解释器跑，测试判断的正确率从约 50% 练到约 88%，验证从"事后打分"变成了"下一回合的输入"。可验证奖励能 scale，前提是验证真的可靠。DeepSeek-R1

把这段历史读薄，就一句话：让 RL 后训练真正起飞的，不是更聪明的架构，而是可验证的奖励。代码领域之所以有今天，是因为代码可执行，编译器加测试集就是那个当场判分的判卷老师。可空间生成的下一个问题是：循环了一圈，它的判卷老师在哪里？

答案藏在游戏开发里：场景交给引擎，当场就能判对错

RLHEV 的回答是：判卷老师一直都在，就在游戏开发 pipeline 里。一个场景被编码进游戏引擎之后，就不再是一堆像素，而是一份可执行世界规范（executable world specification）。引擎拿到的不是图片，而是会被真实运行的规则，它会加载场景、跑物理模拟、检查导航网格，在毫秒到秒级的时间尺度上告诉你：墙能不能被穿过去，物体是不是飘在空中，角色能不能走到出口，脚本执行到第几步爆掉了。这就是论文说的引擎稠密信号，每一帧、每一步都能判。而开发者是这个流程里的全局验收者：这个场景要不要收下，他可以看渲染证据，也可以凭设计意图拍板。RLHEV

论文用一整张图来钉住这个对比：同样一件事，两种做法，差在奖励的质地。

图注：论文 Fig.2 的上下对照。上面是模糊代理 pipeline，模型当判官，叠加人的审美波动，产物是含糊的奖励和性能瓶颈。下面是人工-引擎 pipeline：资产变成可执行世界，引擎和内部测试套件暴露局部失败，渲染证据支撑评审，最后由开发者给出接受与否的验收信号。RLHEV

把引擎当 verifier，而不是让神经网络去抢引擎的活，这个选择本身就反着主流走了十年。GameNGen 用扩散模型以 20 FPS 实时模拟 DOOM，这是"神经引擎取代引擎"路线的巅峰。数字看起来惊人，但人类评委看 1.6 秒和 3.2 秒的短片段，猜中真实游戏的比率分别只有 58% 和 60%，只比抛硬币好一点点；自回归生成几分钟之后，这个比率掉回 50% 的随机水平。而且它没有碰撞、没有物理、没有导航这些结构化目标，造不出新游戏。RLHEV 的转折在于：让真实引擎当 verifier，让神经网络去生成场景程序，两者各干各擅长的活。GameNGen

还有人会问：这会不会只是 Unity 的独角戏？不是。三大商业引擎都内置了碰撞、物理、导航子系统，而且都有对接 RL 训练的成熟生态，引擎当 verifier 是工程现实，不是论文虚构的需求。

引擎生态

所以游戏开发恰好是空间生成缺失的那块拼图：引擎负责稠密的结构检查，每个动作都有反馈；开发者负责稀疏但权威的全局验收，这个场景到底行不行。两种信号形状完全不同，一个密一个疏。怎么把它们合成一个 RL 能吃的奖励？这是下一章的事。

引擎查细节、人拍板，两种信号怎么合成一个奖励？

论文把这条开发者工作流做成了两件套：一个 agent 框架，一个数据协议。框架叫 AWoMo，围绕一个多模态骨干挂四个接口。intent 接口接收任务简报和设计约束；action 接口吐出场景程序、资产编辑、工具调用和修复动作；verification 接口记录引擎检查的结果，从加载、碰撞、物理稳定性到 navmesh 可达性和可玩性探测；review 接口记录开发者的接受、拒绝或批评。四个接口串成一个循环：propose（提议）→ render（渲染）→ verify（验证）→ repair（修复）→ review（评审）。这个循环的地基，是生成和理解共用同一个场景程序对象。

图注：论文 Fig.3。生成方向把文本意图、设计目标、任务规格映射成场景程序；理解方向反向读取同一个对象。引擎通过渲染、物理 rollout 和时间一致性检查它，人类判断最终世界是否保留了意图与工作流价值。上下两层正好对应四个接口里 verification 与 review 的分工。RLHEV

循环里跑出来的每一步，都被录成结构化轨迹存下来，这就是统一世界-开发协议（UWDP）。一个时间步的轨迹是一个八元组：

$$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 是评审结论，ρ_t 是修复、置信度与成本信息。翻译成人话：这是一条能完整复盘的开发日志。论文里给了个具体例子，任务简报是"布置一间可玩的储物间，留出通往出口的清晰路径"。对象 crate_07，关系是"挨着 chair_03"，模型给出的动作是把箱子移到 (2.4, 0, 2.6)。引擎检查说：移动前碰撞失败，移动后 navmesh 通过。开发者评审从"需要修改"翻转为"接受"。这一条日志，就是隐式人工验收变成训练字段的完整经过。RLHEV

训练奖励就把两个字段加权合成。论文的 RLHEV 奖励显式写成：

$$r_{\alpha,\beta} = \alpha \cdot h + \beta \cdot e,\quad (\alpha,\beta) = (0.65, 0.35)$$

h 是人工评审，e 是引擎验证，默认权重 0.65 对 0.35，除非引擎硬门限拒绝。两个消融端点摆在这：只用人的离线 RLHF 是 (1,0)，只用引擎的 Engine-based RLVR 是 (0,1)。论文的立场很清楚：合起来用，不二选一。奖励之上还有一道阶梯，合法性、物理合理性、功能正确性、可玩性，越往上越接近"像个真游戏"。同类思路在视频世界模型侧也有回声，WorldCompass 的逐片段 rollout 就是把序列级奖励细化到中间信号，但它的信号仍是感知代理，不是结构化检查。到这里机制全齐了：一条开发者真实工作流被录成可训练轨迹，引擎验证给稠密奖励，人工验收给稀疏权威奖励。问题是，这套信号真的有用吗？

两百个场景、八颗种子：实验证明了什么，又留下了什么？

论文在 UnitySceneBench 上做了一组受控实验：判断编辑后的 Unity 资产候选中哪些该被接受，720 条训练实例、200 条测试集、100 条该收 100 条该拒，每个方法在每个预算下跑 8 颗种子。全套 RLHEV 信号拿到的 best-of-eight 主分是 0.681，accuracy 和 balanced accuracy 都是 0.665，F1 是 0.733，AUC 是 0.690，比最强的非全套基线高 0.098 个主分。注意"best-of-eight"这四个字：这是八颗种子里最好的那颗，不是八颗的平均。下面的数字全部以论文自报为准，引用时只能当"论文报道"，不能当"已确立的结论"。

RLHEV

最有信息量的其实是 generation-side scaling 那一行：不管训练预算给到 40 条还是 720 条实例，Full RLHEV 的生成质量都压过只吃引擎信号的 Engine-based RLVR。720 实例时 0.8197 对 0.7934，优势贯穿整个预算区间，不是某个幸运点上的偶然。注意两种方法的绝对分数都在 0.74 到 0.82 之间，说明基础能力来自同一个底座，差距是信号质量带来的。

跨引擎迁移是最容易被误读成"免费午餐"的一组数。0.25→0.75、0.25→0.35、0.15→0.35，这些全是 target-adapted 之后的结果，也就是先在目标引擎上做过适配训练。零样本直接往别的引擎搬，分数会掉到 0.15–0.25 之间。而且跨引擎评测本身没有统一的原生分数，论文只好用受限制角色的 MLLM 判官打分，每个分数都经过人工复核。这不是一举跨过鸿沟，而是在证明：只要肯适配，结构共享确实能迁移。

embodied 诊断那组数要带原始值看。R2R 成功率从 76.006 提到 76.607，相对 +0.79%；Gym MuJoCo 的 rollout 回报从 1568.44 提到 1724.73，相对 +9.96%；D4RL 从 18.295 提到 27.155，相对涨幅吓人的 +48.43%，但它的起点只有 18.3，绝对水平依然很低。而且这套增强是 AWoMo 的数据增强流程，不是新的策略架构。三组实验摆在一起，结论只能是一句话：方向正确，规模待定。RLHEV

同期对照更能说明论文赌注的分量。World-R1 走了另一条路，用深度模型把生成视频重建为 3D 高斯泼溅（3DGS）表示，再让 Qwen3-VL 从新视角打分，构造 3D 一致性奖励，在 Wan 2.1 上把 PSNR 抬高了 7.9 到 10.2 dB，但它的判官仍然是 VLM，跟引擎的可执行检查是两个 fidelity 层级。World-R1

2026 年 8 月同月提交的 VibeWorlding 给出了更精确的证据：同样的 agent 框架，用规则可检查的 verified reward，训练曲线平滑地从 0.14 爬到 0.64；用 MLLM 判官的 unverified reward，虽然也从 0.04 爬到 0.37，曲线却明显不稳定。论文自己的结论就是：RL 的提升上限最终由奖励保真度决定。VibeWorlding

图注：VibeWorlding 论文的 overview 图。用户 query 进入后，agent 经过多轮推理和五种 3D 工具调用，在沙盒里反复编辑出 3D 世界，再交给 dual-constraint verifier 打分，分数回灌 GRPO 训练回路。注意这个判官的物理可行性与意图满足检查走的是 rubric 加模型判断，不是引擎执行。VibeWorlding

这三组证据，加上同期路线的对照，弹药都是正面的，但口径都是诊断性的：规模小、报 best-of-eight、跨引擎要适配。那这篇论文的价值到底在哪里？

一份研究议程，不是一套产品：它为什么仍然值得关注

价值不在数字，而在问题定义。论文把三条核心论断写成了可证伪预言，每条都交代清楚什么证据能推翻它。P1：同等算力下，对引擎可验证奖励做 RL 胜过对模糊代理训练，如果在同等算力下模糊代理追平或反超，P1 就死了。P2：经过提议、渲染、验证、评审、修复、再训练的循环，生成器会变强，如果给引擎轨迹加上人工验收不能提升任务有用性，P2 就死了。P3：在共享可执行结构的源域学到的能力能迁移到目标域，如果跨域迁移没有正向收益，P3 就死了。把话说死到可以被推翻的地步，这种写法在预印本里不多见。RLHEV

论文还替反对者把话说了，五个反方论点全部自报：

RLHEV

C3 的判官质量问题还有同期佐证：VibeWorlding 自己的判官和人工标签比对，aspect 级 Cohen's κ 只有约 0.53 到 0.54，也就是说连最聪明的 MLLM 判官在单条 query 上都不稳定，判官质量本身就是一个开放问题。但这个 κ 只能回答判官稳不稳，回答不了 C4 的数据成本论点：数据便宜不便宜是供给问题，判官能不能检查新的合成输出是保真度问题，便宜这一条不会自动带来后者。VibeWorlding

如果这条路线成立，它通向的终点是一个递归的数据引擎：AI 造游戏，游戏反哺 AI。

图注：论文设想的递归世界构建循环。AWoMo 生成可执行游戏，游戏 agent 去试玩，试玩暴露坏规则、不可达目标、物理失败和节奏问题，这些失败被编码成训练信号喂给下一个世界模型，模型再建新的游戏。信任度是最大的难点：规范必须可执行，试玩 agent 必须难以被骗，设计意图仍需人工把关。

这份愿景目前是一个 pilot，一个诊断式研究，不是交付物。v1 预印本，没有同行评审，AWoMo 用的训练数据 manifest 来自内部产品，没有公开，无法复现。论文自己引述的 Bitter Lesson 也值得再读一遍：最有效的增益往往来自反馈通道，而不是模型架构本身。如果这句话成立，RLHEV 的贡献就一句话：世界模型缺的不是数据和算力，而是一台能给生成结果当场判分的机器。它把「可验证瓶颈」指认为扩张的真正卡点，然后给出了一个值得检验的答案，游戏引擎。这个答案对不对，论文用三组可证伪的预言把话放在了能被检验的位置上。

想深入可以读原文：Agentic Game Development as a Verifiable Trajectory Data Engine for Scaling World Models，arXiv:2608.25518

参考文献