世界模型评测新范式：从Long-Horizon任务到Agent玩家-育师

去年开始做 Agent 项目时，我经常遇到一个很尴尬的场景：模型在离线评测、短任务和单步工具调用测试里表现都挺好，一旦把它丢进需要连续执行十几步甚至几十步的长时程任务，效果就会出现断崖式下跌。研究社区把希望寄托在世界模型（World Models）身上，认为它能让智能体在内部模拟中提前推演、降低长时程决策的误差累积。可真正想评估一个世界模型“到底行不行”的时候，却很难找到一套足够有说服力、能统一执行的评测方法。

这正是 PlayWorld 这类工作试图回答的问题。从论文标题PlayWorld: Benchmarking World Models with Agent Players over Long-Horizon Objectives来看，它关注的不是简单粗暴地给世界模型打分，而是把世界模型当作一个 Agent Player，放进带有长期目标的交互环境中要求它自己探索、规划并完成任务。这是一种评价思路的转变：不再仅仅考查模型记住或预测了多少帧画面，而在于它能不能在复杂的长期目标驱动场景下，真正做出高质量的行为决策。

这篇文章会围绕这个主题展开。我会先拆解世界模型、Agent Players 和 Long-Horizon Objectives 这几个概念，再结合评测系统设计的通用方法，给出一套可以落地的评测 Runner 代码模板，最后补充常见的问题排查与工程化建议。适合正在做 Agent、强化学习、具身智能、仿真评测的开发者阅读。

1. 背景：世界模型评测正在成为智能体落地的关键瓶颈

1.1 从“预测视频”到“执行长期目标”

世界模型近两年的热度很高，很多视频生成模型也被冠上“世界模型”的称号。原因是视频预测任务迫使模型去学习物体运动、遮挡关系、物理常识等隐含规律，这使得模型具备了一定的“世界知识”。但从智能体应用角度看，仅仅预测视频并不等于能够完成任务。一个模型可以生成流畅的下一个画面，却不知道下一步该按哪个按钮、该往哪个方向走。

PlayWorld 这类 Benchmark 的共同点，是把评测场从“静态观察”搬到“动态交互”。它会构造一个可以让 Agent 自由行动的环境，并给定长期目标，让世界模型驱动的智能体玩家去完成。整个任务的评价取决于目标是否达成，而不只是预测误差有多低。这样的评价方式更接近真实应用，也更能暴露模型的决策短板。

1.2 World Models 并不是一个单一概念

很多读者容易把“世界模型”理解成一个统一定义的组件，但实际阅读文献时，会发现它至少横跨了两大类：

一类偏决策规划，代表作包括 Dreamer、MuZero 等。它们学习环境的动态转移模型、奖励模型等，内部通过“想象轨迹”来改进策略。
另一类偏生成预测，代表作包括各类视频生成大模型。它们倾向于从海量视频中学习下一帧或未来片段，强调物理规律和视觉一致性。

这两类模型要评测的维度很不一样。前者必须评估决策收益、目标达成率、样本效率；后者更侧重视频质量、连贯性、物理一致性。如果你把“能预测视频”等同于“会做决策”，很容易得到错误的结论。而 PlayWorld 的标题中出现的 Agent Players，明显采用了第一类视角，也就是把 World Model 放到交互闭环里接受检验。

这里说明一下：Agent Players 并不是某个固定专有名词，而是在评测研究中描述“被测试策略实体”的习惯说法。可以通俗理解成一个有目标、能感知、会行动的智能体角色。在 Benchmarks 中引入 Agent Players，相当于让模型从后台走到前台去实际“执行任务”。

1.3 PlayWorld 的评测视角：让模型接受长时程目标的考验

为什么静态测试不够，还得让模型当玩家？因为现实世界里的任务往往没有标准答案，需要模型自己去试错。当你要求智能体完成“从客厅找到钥匙，再去车库启动汽车”这种多阶段任务的时候，它必须连续做出一系列决策。此时模型不仅需要理解当前画面，还需要记住之前去过哪里、推理下一步去哪里，并且在没有即时奖励时也不会提早放弃。

PlayWorld 这类基准测试的核心价值，就是给世界模型设置一条“困难赛道”。赛道上有明确的目标、边界条件、状态转移，也有长期的延迟反馈。只有在这种条件下，模型才会暴露出记忆能力、规划能力、探索能力和泛化能力之间的差距。单纯用“下一帧预测的 MSE”作为指标，很难体现这些复杂能力的差异。

最近业内也流行一个说法：World Action Models 是 Embodied AI 的下一个前沿。意思是，下一代模型不能只做到“看得懂世界”，还要能把理解转成动作。PlayWorld 用 Agent Players 来做评测，本质上也是这个方向的体现。模型是否具有行动价值，必须放到行动评价体系中去度量。

2. Long-Horizon 目标为什么难评：概念与难点拆解

2.1 Long-Horizon 意味着什么

Long-Horizon 通常翻译为“长时程”或“长期跨度”，但它不是简单指“步骤多”。一个优秀的长期目标评测任务，往往具备几个特征：

需要多个阶段的决策，后一步依赖前一步结果。
目标拆解后有明显的子目标结构。
最终目标反馈延迟，中间缺少密集奖励。
环境存在部分可观测性，Agent 必须维护历史信息。

我用实际场景举例：让智能体从起点出发，依次访问 A、B、C 三个地点，最后到达终点。每一步看起来都不难，但要让模型在几百步内规划出顺序、记住当前位置、判断是否访问过某个地点，难度会随目标数量指数上升。如果在评测时只给“最终是否完成”做 0/1 判断，得到的有效信息量很少，还需要配合轨迹、阶段成功率等指标一起评估。

2.2 部分可观测性与稀疏奖励问题

长时程任务经常与 POMDP（部分可观测马尔可夫决策过程）绑定。智能体通常只能看到局部视野或有限状态，不能直接拿到完整地图。这时候，拥有世界模型的 Agent 会尝试在内部构建对隐藏状态的估计，再基于估计规划。评测时若没有区分“完全可观测”和“部分可观测”两种设置，很难判断模型究竟是靠记忆还是靠取巧。

另一个难点是稀疏奖励。如果模型在一个长时程任务里走了一百步，全部奖励为 0，只在最后一步给出成功信号，那么即使模型具备潜力，也很难从梯度中学会正确行为。评测者要在任务中设计合理的中间奖励或里程碑定义，但也要小心不要因为奖励设计太密集，导致模型只学会了跟随局部指标，反而丢掉全局规划能力。

2.3 一套好的 Benchmark 至少应该满足四个要求

第一，任务边界清晰。每个场景必须有明确的初始状态、终止条件、可行动作空间和成功判定，否则模型训练和评测都会出现歧义。

第二，难度梯度可控。新手模型和老手模型如果都在同一水平线上打转，评测就失去了区分度。好的基准会提供从容易到困难的多档任务，让研究者看到能力随模型规模或算法变化如何增长。

第三，训练与评测隔离。评测任务不能来自训练分布内部，至少应该设置独立的任务族，否则只能测试记忆与过拟合，而不是测试泛化。

第四，可复现性好。同样的配置跑两次，结果波动应尽量小。这要求随机种子管理、环境版本、模型权重版本都纳入评测协议管理。

把这些要求放到工程里，就意味着我们必须把评测代码当作正经基础设施建设，而不是临时跑个脚本。

3. 一套评测系统该约束哪些变量

3.1 任务家族与动态生成策略

在 PlayWorld 式评测系统中，任务不是写死一张静态地图，而是需要支持“动态出题”。通常可以定义一个任务生成器，通过组合参数生成不同初始条件，比如地图尺寸、目标点数量、目标点位置、障碍物分布、天气条件等。

动态生成的好处是天然防止模型记住固定路径，同时可以检验模型在不同难度下的泛化能力。实际开发时，任务生成器要内置随机种子，并保存每个 seed 对应的任务描述。后续如果要排查某个模型的失败案例，可以直接从日志里恢复原场景，重新观察轨迹。

3.2 训练任务与评测任务隔离

这是对比实验中最容易被忽视的一环。很多团队训练 Agent 时，会把公开环境反复使用，导致评测集和训练集高度重叠。如果评测集中任务的障碍布局、目标点模式与训练时完全相同，测试出来的分数就会虚高。

正确的做法是把任务空间划分成多个区域。训练阶段只暴露一部分任务族，评测阶段才引入新任务族。这样得到的结果更能反映模型是否真正掌握了“基于世界模型的规划能力”，而不是对特定地图的过拟合记忆。

3.3 标准化模型接口

要让不同世界模型都能参与评测，接口必须尽量统一。最核心的接口就是“入参与出参”：输入当前观测、当前目标等信息，输出一个动作。如果某个模型内部使用了额外记忆器，也应该在 Agent 封装层统一管理。

此外，还要考虑动作空间的差异。离散动作和连续动作的评测环境通常要分开处理，否则一个只能输出离散动作的模型无法参与连续控制任务。设计接口时要注意协议稳定，避免每次新增模型都改动评测主循环。

3.4 评价指标的多尺度设计

多尺度指三个层面的指标：

任务层：最终目标是否达成、成功率是多少。
轨迹层：平均步骤数、子目标完成率、无效动作比例。
模型层：是否展现出记忆复用、规划前瞻、探索效率提升等可解释行为。

最终汇报时，不能只贴在某个任务上成功率最高的一张表，更合理的做法是列出不同难度任务族的成功率分布、均值和中位数，并配合若干条失败轨迹作为证据。这样读者才能判断模型变强是普遍现象，还是只对少数任务生效。

4. 手写一个 Long-Horizon 评测 Runner

理论讨论再充分，不如直接看代码。下面我会用一个最简单的多阶段目标网格环境，搭建一套可运行的评测 Runner。代码不依赖任何深度框架，只需 Python 标准库，方便读者完整理解评测协议的各个环节。

为了更贴近 Long-Horizon 的语义，这里没有采用“到达一个终点就算成功”的迷宫环境，而是让 Agent 必须依次访问多个目标点。访问完当前目标点后，下个目标点才会成为有效目标，这就有了一点任务拆解感。

4.1 准备一个最小的多阶段目标环境

先创建一个环境文件，路径为demo/multi_goal_grid.py。

# 文件路径：demo/multi_goal_grid.py from typing import List, Tuple class MultiGoalGridEnv: """ 极简多阶段目标环境： Agent 从 (0,0) 出发，需要按顺序经过 goals 列表中的全部点。 到达当前目标后进入下一阶段；完成最后一个目标时 episode 结束。 """ def __init__( self, size: int = 6, goals: List[Tuple[int, int]] = ((5, 0), (0, 5), (5, 5)), max_steps: int = 200, ): self.size = size self.goals = list(goals) self.max_steps = max_steps self.reset() def reset(self): self.agent_pos = [0, 0] self.goal_idx = 0 self.steps = 0 self.done = False return self._observe() def _observe(self): return { "agent_pos": tuple(self.agent_pos), "current_goal": self.goals[self.goal_idx], "remaining_goals": len(self.goals) - self.goal_idx, "steps": self.steps, } def step(self, action: int): if self.done: raise RuntimeError("Episode has already terminated.") # 动作映射：0 上，1 下，2 左，3 右 row, col = self.agent_pos if action == 0: row = max(0, row - 1) elif action == 1: row = min(self.size - 1, row + 1) elif action == 2: col = max(0, col - 1) elif action == 3: col = min(self.size - 1, col + 1) else: raise ValueError(f"Invalid action: {action}") self.agent_pos = [row, col] self.steps += 1 reward = 0.0 if tuple(self.agent_pos) == self.goals[self.goal_idx]: self.goal_idx += 1 if self.goal_idx >= len(self.goals): reward = 1.0 self.done = True else: reward = 0.5 if self.steps >= self.max_steps: self.done = True return self._observe(), reward, self.done, {"goal_idx": self.goal_idx}

环境设计比较简单，但仔细看能发现几个关键点：

每一步都会推进steps，超过max_steps后强制done=True。这模拟了真实场景中的时间预算限制。
只有当 Agent 到达当前目标位置后，goal_idx才会增加，表示进入下一阶段。
中间目标给予较小奖励 0.5，最终目标给予 1.0。由于中间奖励仍然稀疏，模型要完成任务，依旧依赖长期记忆和规划。

4.2 接入一个待评测的 Agent

接着我们写一个随机动作的 Agent。它的作用是作为“最低分数线”，让后续世界模型的结果有对比参照。

# 文件路径：demo/agents.py import random from typing import Dict class RandomWalker: """随机动作 Agent，作为最基础的对比基线。""" def __init__(self, seed: int = 0): self.rng = random.Random(seed) def act(self, obs: Dict) -> int: return self.rng.choice([0, 1, 2, 3])

实际项目中，你只需要把世界模型的推理逻辑封装成一个同样有act方法的类即可。例如某个基于视频预测的世界模型，可以在act内部接收当前观测，生成多个假设的未来轨迹，然后选择最优动作序列中的第一个动作返回。评测侧完全不关心模型内部使用了什么算法，只要接口稳定即可。

4.3 评测主循环与指标计算

下面是评测主循环。为了让不同 episode 之间的随机性可控，我让env_factory和agent_factory接收 episode 编号作为参数。这样外部可以方便地实现“每个 episode 使用不同 seed”的策略。

# 文件路径：demo/demo_runner.py from typing import Callable, Dict, List from agents import RandomWalker from multi_goal_grid import MultiGoalGridEnv def evaluate_agent( env_factory: Callable[[int], MultiGoalGridEnv], agent_factory: Callable[[int], RandomWalker], episodes: int = 20, max_steps: int = 200, ) -> List[Dict]: results = [] for ep in range(episodes): env = env_factory(ep) agent = agent_factory(ep) obs = env.reset() total_reward = 0.0 step_used = 0 success = False for step in range(max_steps): action = agent.act(obs) obs, reward, done, info = env.step(action) total_reward += reward step_used = step + 1 if done: # 只有当 goal_idx 等于目标数量时，才算真正完成全部目标 success = info["goal_idx"] == len(env.goals) break results.append( { "episode": ep, "success": success, "total_reward": total_reward, "steps_used": step_used, } ) return results def summarize(results: List[Dict]) -> Dict[str, float]: n = len(results) success_cnt = sum(1 for r in results if r["success"]) return { "episodes": n, "success_rate": success_cnt / n, "avg_total_reward": sum(r["total_reward"] for r in results) / n, "avg_steps_used": sum(r["steps_used"] for r in results) / n, }

这个主循环没有包含训练逻辑，它只是不断让 Agent 与环境交互，直到完成目标或耗尽步数。不管模型内部如何复杂，评测协议都必须像这样简单、确定、可审计。

我特别在代码中强调了一点：判断任务是否成功，不能只看done，还要看goal_idx是否等于目标总数。因为done也可能是步数超限导致的强制终止。如果你把“步数耗尽”也当作成功，评测数据就会出现污染。

再看一个主函数示例。

def main(): goals = [(5, 0), (0, 5), (5, 5)] # 每个 episode 使用不同 seed，避免所有轨迹完全相同 results = evaluate_agent( env_factory=lambda ep: MultiGoalGridEnv( size=6, goals=goals, max_steps=200 ), agent_factory=lambda ep: RandomWalker(seed=ep + 100), episodes=20, max_steps=200, ) print(summarize(results)) if __name__ == "__main__": main()

运行方式很简单。

cd demo python demo_runner.py

因为随机动作的模型几乎不可能在 200 步内顺序到达三个目标点，输出结果应该会比较“惨淡”。

{'episodes': 20, 'success_rate': 0.0, 'avg_total_reward': 0.35, 'avg_steps_used': 200.0}

这是一个很正常的基准值。以后不管你提出什么样的世界模型 Agent，都要先跑一遍 RandomWalker 得到这条底线，再去看你的模型能否显著超越随机水平。如果某个复杂模型在这类任务上连 RandomWalker 都没超过，就要怀疑模型是否真的在利用环境结构。

4.4 配置文件与快速启动

实际工程中建议把任务参数外置到 YAML 文件，方便后续批量调整难度而不改代码。这里是一个常见配置示例。

# 文件路径：configs/demo_benchmark.yaml benchmark: name: multi_goal_grid_demo episodes: 20 max_steps: 200 env: size: 6 goals: - [5, 0] - [0, 5] - [5, 5] agent: type: random_walker

Python 侧读取后，可以动态构造环境与 Agent。如果团队内部使用 Hydra，也可以直接利用 Hydra 的配置覆盖能力做多组实验，例如扫描不同max_steps或不同goals数量下的模型表现。把配置外置的收益是显而易见的：你不必修改评测代码，就能批量生成不同难度的 benchmark。