视频和物理模拟之间，一直存在一道很深的鸿沟。视频是像素的流动，物理程序是刚体、关节、力矩和约束的数学世界。过去要把一段真实视频变成可执行的仿真程序，需要人工观察轨迹、提取状态、写运动学公式、调控制器参数，过程又长又脆。MirroS 发布 Code-as-World 的消息，把“从视频到可执行 MuJoCo 物理程序”这件事摆到了前台：它想做的不是生成一段看起来像的动画，而是把视频重写成真正能在物理引擎里跑起来的程序。
这个方向值得关注，不是因为“AI 又进步了”，而是因为它改变了仿真内容的生产方式。以前我们写仿真，是先有目标、再有模型、后有控制；现在这条路变成从真实世界视频出发，自动得到模型、控制逻辑和仿真场景。这种范式变化对机器人仿真、具身智能训练、数字孪生和自动驾驶场景生成都有直接影响。
这篇文章会先讲清楚 Code-as-World、MuJoCo 和物理程序这三个概念到底是什么，再给出可落地的 MuJoCo 环境配置方法（包含 Windows 11 和 WSL 的常见坑），最后用一个最小物理程序示例，说明“视频重写后的程序”在本地应该怎么运行、怎么验证、怎么排错。文章末尾会补充我们在实际工程中总结的最佳实践。
1. 这篇文章真正要解决的问题
先聊一个真实的开发痛点。在机器人仿真中，很多人卡住的第一步不是算法，而是“怎么把一个真实场景搬到仿真里”。
传统流程大致是这样：先录一段真实机械臂抓取视频，然后人工观看视频，把机械臂的关节角度、末端轨迹、抓取时序一步一步记下来，再在 MuJoCo 或其它仿真器里手动建模。这个流程里有三个瓶颈：
- 视频是 2D 像素序列，物理仿真需要 3D 状态和约束，转换过程没有通用工具。
- 手工提取的运动轨迹往往不光滑，放进物理引擎后会因为速度突变导致抖动甚至发散。
- 真实环境的摩擦力、接触参数、关节限位和仿真环境不一致，程序难以直接复用。
Code-as-World 这个项目思路，是把“视频理解”和“程序生成”之间用代码连接起来。它不是单纯做动作识别，而是输出一段可执行的程序。用户拿到的不只是“发生了什么”，而是“如何在仿真中让这件事再次发生”。
从公开信息看，这个项目至少传递出两个信号：第一，多模态模型已经开始把视频信号编码为结构化程序，而不是停留在“文字描述视频”的层面；第二，MuJoCo 作为可微、高速、物理精度高的仿真器，非常适合充当这些程序的执行载体。
什么样的读者最应该关注这件事？我的判断很明确：正在做机器人仿真、强化学习环境构建、具身智能数据生产的人，值得认真跟进；如果是刚接触 MuJoCo 的同学，也不用急着追新概念，先把物理引擎跑通，再理解 Code-as-World 的思路会容易得多。
2. 三个核心概念：Code-as-World、MuJoCo、物理程序
2.1 Code-as-World 是什么
Code-as-World 的直接含义是“代码即世界”。这里的“世界”不是指宏大世界观，而是指仿真环境本身。传统仿真环境由人来写，模型结构、物理参数、控制逻辑都是人工编码；Code-as-World 想做的事情，是从真实视频中自动生成这些编码。
它的核心价值在于把“视觉理解”提升为“程序生成”。比如给出一段小球滚下斜坡的视频，传统的视频理解模型会输出“一个球从斜坡上滚下来”；而 Code-as-World 尝试输出的，是一段包含小球质量、斜坡角度、摩擦系数、初始速度、重力方向等信息的 MuJoCo 程序。这段程序放进仿真器之后，可以重新生成相似甚至更可控的运动。
这个思路如果跑通，意味着仿真环境的生产成本会大幅下降。目前很多机器人团队造仿真环境，80% 时间花在场景建模和调参上；真实视频一旦能直接变成可执行程序，仿真场景的生成效率会显著提升。当然，这个目标非常难，如何保证视频状态和物理参数的一致性、如何避免生成的程序在长时间仿真中不稳定，都是后续需要解决的问题。
2.2 MuJoCo 是什么
MuJoCo 的全称是 Multi-Joint dynamics with Contact，是一个基于广义坐标和软接触模型的物理引擎。它在机器人领域经常被用来做强化学习训练，OpenAI 早期的机器手灵巧操作实验、大量 Sim-to-Real 研究，都以它作为底层仿真器。
MuJoCo 有几个特点让它在“视频重写为程序”这件事上特别合适：
- 用 MJCF 模型文件描述世界，模型是文本格式，方便程序生成。
- 支持前进动力学和逆动力学计算，能够快速推导关节受力。
- 接触模型稳定，默认求解器对带有碰撞的场景有较好的收敛性。
- 支持可微分仿真，这是近年很多端到端方法选择它的重要原因。
通俗一点理解，MuJoCo 是一个“物理世界的解释器”，你给它一段描述物体和关节的程序，它就能一步一步算出每个物体下一秒在哪、受力多少。Code-as-World 输出的“物理程序”，最终就是要交给 MuJoCo 这样的引擎去执行。
需要注意，MuJoCo 现在有两个常见的使用入口：
- 新版官方 Python 绑定，包名是
mujoco，直接导入import mujoco。 - 早期由 OpenAI 维护的
mujoco_py，导入方式为import mujoco_py。
两个入口的 API 差异很大，排查问题前一定先确认你安装的是哪个包。
2.3 可执行物理程序应该长什么样
“可执行物理程序”听起来玄，其实落到代码上并不复杂。它至少包含三部分：
- 场景描述：有哪些物体、连接关系、几何形状、质量、摩擦系数、关节限位。
- 初始状态：物体初始位置、速度、关节角度。
- 控制逻辑：每一步给哪些关节或执行器施加多少力、力矩或位置指令。
下面是最简化的伪代码视角：
# 物理程序的关键构成 model # 描述世界的模型 data # 记录每一帧状态的容器 # 初始化 data.qpos = 初始关节角度 data.qvel = 初始关节速度 # 控制循环 for t in range(仿真步数): data.ctrl = 控制器计算出的控制指令 让引擎前进一步 读取并记录当前状态Code-as-World 如果成功，它生成的“物理程序”本质上就是这段逻辑的自动化版本。你不需要手写 MJCF，不需要人工调碰撞参数，它会把视频里观察到的状态转成模型定义和控制策略。
3. 环境准备：安装 MuJoCo 与基础配置
不管你是想运行 Code-as-World 生成的程序，还是只想先学会 MuJoCo，环境安装都是第一步。这一节我会同时覆盖 Linux、Windows 11 和 WSL 三种常见情况。
3.1 本机安装 MuJoCo 的基础操作
新版 MuJoCo Python 包的安装非常简单，核心依赖是mujoco包和对应的渲染库。大多数场景下只需要一行命令：
pip install mujoco安装完成后，可以检查是否能正常导入：
python -c "import mujoco; print(mujoco.__version__)"如果能看到版本号，说明 Python 绑定已经安装成功。接下来还要确认渲染后端。MuJoCo 的渲染库依赖系统 OpenGL 环境，常见后端有三种：egl、osmesa、glfw。开发调试时我最推荐egl，因为它在服务器和无桌面环境下也能工作。
设置渲染后端的方式是配置环境变量：
export MUJOCO_GL=egl在 Linux 服务器上，如果缺少 OpenGL 相关库，可能需要安装：
sudo apt update sudo apt install -y libgl1 libgl1-mesa-dev libegl1 libegl1-mesa libosmesa63.2 Windows 11 和 WSL 的安装注意事项
在 Windows 11 上，推荐优先考虑 WSL 2。原因很简单：大量机器人仿真、强化学习工具链在 Linux 生态中支持最好，装完 WSL 后可以直接复用 Linux 的安装流程，避免很多 dll 问题和 OpenGL 兼容问题。
WSL 里安装流程与 Linux 基本一致：
# 进入 WSL 后执行 sudo apt update sudo apt install -y libgl1 libgl1-mesa-dev libegl1 libosmesa6 pip install mujoco export MUJOCO_GL=egl如果你坚持在 Windows 原生环境跑 mujoco，可以安装包之后试一下glfw后端；但这需要系统有可用的 OpenGL 驱动，很多 Windows 机器上会遇到上下文初始化失败。从社区反馈看，WSL 里用egl后端的成功率高很多。
这里真正容易踩坑的一点是：很多人把mujoco和mujoco_py混在一起装。先安装旧版 mujoco_py 再安装新版 mujoco，两个包互相抢占libmujoco，最终运行时报RuntimeError: Could not load library。建议在一个新的虚拟环境中只安装一个包，避免版本冲突。
3.3 验证 MuJoCo 是否可用
安装完成后，用一个小脚本确认基本仿真链路正常。新建文件check_mujoco.py：
import mujoco xml = """ <mujoco> <worldbody> <light name="top" pos="0 0 1"/> <geom name="ground" type="plane" pos="0 0 0" size="1 1 0.1"/> <body name="ball" pos="0 0 1"> <freejoint/> <geom name="sphere" type="sphere" size="0.05" mass="0.1"/> </body> </worldbody> </mujoco> """ model = mujoco.MjModel.from_xml_string(xml) data = mujoco.MjData(model) for i in range(100): mujoco.mj_step(model, data) print("最终位置:", data.qpos) print("仿真完成")如果脚本能打印出小球位置且在 y 方向出现明显下落，说明 MuJoCo 核心链路已经跑通。这一步非常重要，因为后续所有 Code-as-World 生成的程序，最终都要依赖这套基础仿真环境。
4. 核心流程拆解：从真实视频到 MuJoCo 物理程序
Code-as-World 的完整链路大体可以分为四个阶段：视频解析、状态结构化、程序生成、程序可执行化。这里我用一个偏工程的视角拆解，这样即使项目本身尚未开源，你也能理解它背后的技术组件和难点。
4.1 视频解析：从像素到目标
第一阶段要解决的是从像素序列中识别出“什么物体在哪里”。这个阶段通常依赖视频分割、目标检测、姿态估计等视觉模型。输出通常是一个时间序列的结构化对象，例如：
- 物体类别与 ID。
- 每个时刻的二维或三维位置。
- 关节目标的角度（如果视频里是机械臂）。
- 物体之间的遮挡关系。
这个阶段决定了后面所有内容的准确性。如果视觉模型把两个小球识别成了同一个物体，后面生成的物理程序就会丢失一个对象。所以，Code-as-World 这类项目的第一道质量关卡其实在视觉层。
4.2 状态结构化：补全物理状态
视频能直接提供的往往是位置和外观，但物理仿真还需要质量、摩擦系数、速度、角速度、关节约束。速度通常可以通过位置序列差分得到，质量、摩擦等物理属性则很难直接观测，需要模型基于物体的外观和运动模式做合理推理。
这里有一个工程上常见的假设：先预设常见物体的默认物理属性，再通过运动轨迹反推调整。比如视频中看到木块下落，模型先给木块一个常见密度，再根据实际加速度调整最终质量。用这种策略，即使视觉估计有一些噪声，也能生成可用的物理状态。
4.3 程序生成：构造 MJCF 和控制逻辑
当状态被结构化之后，下一步就是生成 MuJoCo 可加载的模型文件和控制脚本。这个阶段的核心工作是“表达转换”：把视觉识别出的物体层级关系，转成 MJCF 的 body、joint、geom 层级结构；把检测到的运动趋势，转成控制器的目标函数或控制参数。
MJCF 的层级结构本质上对应物理世界的父子关系。比如机械臂的基座固定在世界坐标系，arm 连接到基座，前臂连接到 arm，这种树形结构与视频中机械臂的铰接关系是直接对应的。Code-as-World 要处理的，就是怎么从视频的关节运动信息中反推出这棵树的正确结构。
4.4 程序可执行化：验证物理一致性
生成程序之后，最关键的步骤是执行验证。把生成的 MJCF 载入 MuJoCo，运行控制脚本，观察仿真结果是否与输入视频的运动模式一致。如果不一致，需要回到前几个阶段修正参数。这个过程类似“虚拟试跑”：在生成代码和发布代码之间，加一道自动验证工序。
从这些流程可以看到，Code-as-World 不是单一模型能完成的任务，它是一个多阶段系统：视觉模型负责感知，推理模型负责生成程序，MuJoCo 负责验证。对我们开发者来说，即使不直接使用它的开源成果，也可以参考这套流水线设计自己的仿真数据生成流程。
5. 完整示例：手写一个最小可执行的 MuJoCo 物理程序
为了让你理解 Code-as-World 输出的“物理程序”到底怎么运行，这里我准备一个最小示例。它不来自项目本身的输出，而是一个可本地运行的演示程序，结构与“视频重写程序”的目标形态一致。
5.1 定义 MJCF 模型
新建文件demo_scene.xml：
<mujoco model="simple_pendulum"> <option gravity="0 0 -9.81"/> <worldbody> <light name="light" pos="-1 -1 3"/> <geom name="ground" type="plane" size="2 2 0.1"/> <body name="mount" pos="0 0 1"> <joint name="hinge" type="hinge" axis="0 1 0"/> <geom name="rod" type="capsule" fromto="0 0 0 0.5 0 0" size="0.02" mass="0.1"/> </body> </worldbody> <actuator> <motor name="motor" joint="hinge" gear="1"/> </actuator> </mujoco>这个模型描述了一根可以绕 hinge 关节旋转的杆，并且关节上安装了一个电动机执行器。它的结构非常简洁：worldbody 是世界的根节点，mount 是一个挂在 hinge 关节上的刚体，actuator 模拟了关节电机。Code-as-World 如果从一个“杆绕轴摆动”的视频生成程序，输出的模型结构会很接近这个形式。
5.2 编写 Python 控制脚本
新建文件run_demo.py：
import mujoco xml_path = "demo_scene.xml" model = mujoco.MjModel.from_xml_path(xml_path) data = mujoco.MjData(model) # 初始状态：给一个角速度，让杆开始摆动 data.qpos[0] = 0.0 data.qvel[0] = 2.0 # 控制策略：保持恒定力矩 ctrl_value = 0.05 steps = 600 print("step, qpos, qvel, ctrl") for i in range(steps): data.ctrl[0] = ctrl_value mujoco.mj_step(model, data) if i % 60 == 0: print(f"{i}, {data.qpos[0]:.4f}, {data.qvel[0]:.4f}, {data.ctrl[0]:.2f}")这个脚本完成的事情很简单：加载模型，给初始角速度，每个仿真步设置控制量，然后调用mj_step推进仿真，并周期性打印状态。它的核心循环是所有物理程序都要具备的骨架，区别只在于控制器是从简单常数变成 PID、MPC 或者神经网络策略。
5.3 运行命令
python run_demo.py预期输出类似：
step, qpos, qvel, ctrl 0, 0.0000, 2.0000, 0.05 60, 0.9516, -0.8721, 0.05 120, 0.5883, 0.1288, 0.05 ...注意，qpos是关节角度，qvel是关节角速度。在恒定力矩作用下，摆杆会经历加速、减速、反向摆回的过程。如果输出里qpos一直线性增长，说明关节没有被重力带回，大概率是控制力过大或者初始角速度过大，可以适当调小ctrl_value再试。
当你把视角放回 Code-as-World，这个最小示例其实就是它生成的程序的执行侧视图：给定一段“物理程序”，MuJoCo 按时间推进，输出可观测的状态。真实项目生成的程序会复杂很多，多物体、多关节、接触感知，但底层结构不会脱离这个框架。
6. 运行结果与效果验证
物理程序运行起来之后，最重要的问题不是“有没有报错”，而是“仿真结果是否符合预期”。对于视频重写场景，这一步尤其关键，因为程序是自动生成的，必须有一套验证闭环。
建议从三个维度验证：
第一个维度是物理合理性。检查物体是否出现穿墙、飞出世界、速度异常等明显物理错误。最简单的方式是打印每个物体位置和速度的最小值、最大值、均值，如果数值超出常识范围，说明模型参数或者控制器有问题。
第二个维度是运动模式一致性。如果输入视频是小球从坡顶滚到坡底，那么生成的程序运行后，小球也应当大致沿着坡面滚下，而不是反向运动或原地抖动。这一点可以通过轨迹对比来实现。
第三个维度是可重复性。物理仿真如果输入相同，输出应当完全一致。连续两次运行同一条命令，得到的状态轨迹应当完全相同。如果两次运行结果不同，需要怀疑代码中是否有随机初值、随机策略或者浮点环境不一致。
下面是一个简单的脚本，可以用于计算两次运行的轨迹差异：
python run_demo.py > run1.log python run_demo.py > run2.log diff run1.log run2.log如果diff没有输出，说明两次运行结果一致，可重复性通过。如果一个自动生成的物理程序在三个维度上都表现稳定，那它才算达到了“可执行”的标准。这一节真正的价值在于提醒开发者：拿到 Code-as-World 生成的程序后，不要直接相信生成器的输出，一定要建立自己的验证流程，这比调通 API 重要得多。
7. 常见问题与排查方法
MuJoCo 相关的问题在网上被问得特别多，尤其是围绕“安装 mujoco”“mujoco 环境配置”“wsl 安装 mujoco”这几类关键词。我整理了实际开发中最常遇到的问题和排查路径。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 安装 mujoco 后 import 报错 | 同时安装了 mujoco 和 mujoco_py，动态库冲突 | 查看完整异常栈，检查 pip list 中是否同时存在两个包 | 在新虚拟环境中只安装新版mujoco，卸载mujoco_py |
| WSL 中运行报 OpenGL 相关错误 | 缺少 EGL/OSMesa 库 | 运行ldd检查渲染库依赖是否完整 | 安装libegl1 libosmesa6 libgl1-mesa-dev，设置export MUJOCO_GL=egl |
| 仿真场景中物体穿透地面 | 接触参数设置不当或仿真步长过大 | 检查 XML 中geom的 contact 参数，尝试减小timestep | 将option timestep从 0.01 调整为 0.002，检查接触类型 |
| 机械臂关节角度超出预期 | 关节限位未设置或控制量过大 | 打印data.qpos与关节 range 对比 | 在<joint>中设置合适的range属性，减小ctrl |
| 仿真速度很慢 | 场景物体数量多，默认渲染后端开销大 | 观察 CPU 占用和 GPU 占用 | 关闭实时渲染，使用离屏渲染，或者增大mj_step批量推进步数 |
| MJCF 加载失败 | XML 层级写错或引用了未定义的 geom | 查看MjModel.from_xml_path的具体报错行 | 按报错定位到 XML 行号，检查 body/joint/geom 层级关系 |
再补充一个特别容易被新用户忽视的问题：MuJoCo 的 XML 不支持随意缩进和注释格式错误。XML 中fromto属性必须写 6 个数，分别表示起点和终点的三维坐标；少一个数会直接报 parse error。遇到这类问题，建议先把模型复杂度降到单 geom 单 body，逐步恢复。
如果运行的是 Code-as-World 生成的程序，还可能出现一类特殊问题：生成的 MJCF 结构合法，但控制器逻辑与模型不匹配。典型表现是data.ctrl索引越界，或者控制量完全无效。这种问题通常出在生成器没有准确识别 actuator 数量，排查时需要逐个检查 XML 中 actuator 数量和脚本中ctrl数组长度是否一致。
8. 最佳实践与工程建议
8.1 环境与版本管理
MuJoCo 的环境问题大多数源于版本混用。建议每个项目使用独立的虚拟环境，并在requirements.txt中固定mujoco版本。如果要同时使用强化学习库，优先选择已经适配新版mujoco的版本，不要自己混装旧版绑定。
Windows 用户尽量用 WSL 2 跑仿真，避免在 Windows 原生环境纠结 OpenGL 渲染问题。WSL 中记得使用egl后端，这对服务器和本地调试都更友好。
8.2 MJCF 模型设计建议
写模型文件时，建议遵循“先世界后关节”的顺序：先定义场景中固定物体和地面，再定义关节树。每个带关节的 body 都要明确指定 inertia 或 mass，否则 MuJoCo 会自动用几何体估算，可能导致动力学行为与预期偏差很大。
对于由视频生成的模型，最好在模型文件里记录来源信息。Code-as-World 这样的系统如果开口闭口只丢给你一个 XML，后续调参会非常痛苦。可以在 XML 的<compiler>或自定义注释中保留视频来源、生成时间、关键参数，方便回溯。
8.3 控制器与仿真步长
控制器的目标要跟物理引擎的步长匹配。MuJoCo 的默认timestep是 0.002 秒，也就是 500Hz。如果你的控制频率是 50Hz，需要每 10 个物理步才更新一次控制指令，而不是每一步都更新。否则控制频率超过物理模型的实际响应能力，容易产生震荡。
建议把“物理步”和“控制步”分成两个循环层级，控制层每个周期计算一次期望输出，物理层按固定步长推进。这种解耦方式在机器人仿真里是标准做法，对 Code-as-World 生成的程序尤其重要，因为生成的控制器一般比人工手调控制器更容易出现高频抖动。
8.4 数据采集与回放
仿真运行产生的轨迹数据要尽量保存为结构化格式。推荐保存为 CSV 或 NumPy 数组，记录qpos、qvel、ctrl和外部观测状态。回放数据时不要重新跑仿真，直接读取记录文件绘图，可以快速定位问题。
如果进一步做 Sim-to-Real，建议同时保存场景中关键物体的位置和速度，而不只是机器人自身状态。这样调物理参数时可以直观对比真实轨迹和仿真轨迹。
8.5 与上游视频模型的边界
使用 Code-as-World 这类工具时，心里要清楚一个边界：视频生成模型的输出是“程序”，不是“最终结果”。程序是否可用，必须经过 MuJoCo 执行验证。如果你拿到的模型生成结果不稳定，优先怀疑视觉阶段的物体识别错误，而不是物理引擎计算错误。
把“生成”和“验证”拆开，是工程上降低复杂度最好的方式。生成器负责提出一个候选方案，验证器负责判断是否通过；两者解耦之后，每个阶段都可以单独优化。这也是我很看好 Code-as-World 方向的原因：它一旦形成“生成-执行-验证-反馈”的闭环，后续迭代空间非常大。
9. 总结与后续学习方向
Code-as-World 把真实视频重写为可执行的 MuJoCo 物理程序，这个方向的核心意义在于：它让仿真内容的生产从“人工建模”走向“自动生成”。对开发者来说，不需要一开始就盯着整个项目的大目标，而是可以先掌握两件确定的事：把 MuJoCo 环境跑通，把“物理程序”的最小结构理解清楚。
建议下一步这样实践：先把文章第 5 节的示例代码保存下来，在本地跑通；然后尝试修改模型中的质量、摩擦系数和初始角速度，观察仿真结果的变化；等熟悉了 MuJoCo 的模型和脚本结构，再回头去研究视频解析和程序生成的知识，会容易很多。
这个领域后续值得深入的方向包括：MJCF 结构的自动生成、视频中物理参数的反推、Sim-to-Real 迁移、基于可微分仿真的控制器优化。无论 Code-as-World 最终以什么形式开源或商业化，它指向的“视频到仿真程序”方向，都值得机器人、自动驾驶和具身智能从业者长期关注。
