MuJoCo 木块自由落体这件事，卡人的地方往往不在物理引擎本身，而在最后一百米：环境全部装好了，01_mujoco_helloworld.py 还没影子，脚本生成出来也不敢确定是否真的跑通。这篇的做法是把「生成 + 执行」这一环交给已经配好的 Codex，让它走 TaoToken 的兼容通道产出脚本，再在 t800 环境里实跑。动手前先去 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 注册账号、创建一把 Key，Codex 的 base_url 填 https://taotoken.net/api，剩下的就是 Miniconda、mujoco==3.4 和那个从 1 米高落下来的木块。
原文的路径其实很清楚：建环境、装包、生成脚本、执行看输出。缺的只是「生成和执行到底由谁来做，有没有留下证据」。下面按原文的步骤顺序走一遍，把需要人工确认的地方全部标出来。
1. t800 环境装完 mujoco==3.4 之后，01_mujoco_helloworld.py 还缺一个人来写
1.1 Miniconda 建 t800 与三个包的真实顺序
先别急着让任何工具写代码。MuJoCo 这类仿真库对环境很挑，Python 小版本和 numpy 的 ABI 对不上，报错能绕很久。原始文章用的是 Miniconda，原因就是环境隔离干净，不会把 base 里的老包带进来。命令照抄即可，顺序不要改：
conda create --name t800 python==3.11 conda activate t800 pip install pinocchio mujoco==3.4 numpy==2.3.5这三行看起来简单，但有两个坑。第一，conda create之后必须重新conda activate t800，如果只是在旧终端里激活过一次，新开的窗口很可能还停在 base，后面pip install全部装错地方。第二，pinocchio 走的是 conda-forge 或 pip 的预编译轮子，它对 numpy 的版本有要求，跟 mujoco==3.4 需要的版本未必完全一致，所以三个包最好在同一条pip install里一次装完，让解析器统一选版本，而不是装一个跑一次。
装完之后建议再确认一下当前解释器是谁：
which python python -c "import sys; print(sys.executable)"输出路径里应该带envs/t800。这一步花十秒，能省掉后面「明明装了却 import 不到」的半小时。
1.2 装完先自检：三段 import 不报错再谈生成代码
环境装好后的第一件事不是让 Codex 写脚本，而是自己确认三个包都能导入。三条命令分开跑，哪一条炸了一眼就能看出是谁的问题：
python -c "import mujoco; print(mujoco.__version__)" python -c "import numpy; print(numpy.__version__)" python -c "import pinocchio; print(pinocchio.__version__)"mujoco 那条应该打印 3.4.x，numpy 那条应该打印 2.3.5 一类的版本号。如果 mujoco 报ModuleNotFoundError，八成是激活错了环境；如果 numpy 报的是ImportError: numpy.core.multiarray failed to import这类二进制层面的错，说明有包编译时用的是另一套 numpy，最省事的办法是回退 numpy 小版本或者重装一遍。
自检通过之后，才轮到「谁来写 01_mujoco_helloworld.py」。原文这里用的是 TRAE，把它换成你已经配好通道的 Codex，功能完全等价：生成文件、解释 API、根据报错改代码。TaoToken 在这条链路里只负责提供 Key 和 Base URL，不参与任何 MuJoCo 物理仿真，木块怎么掉、掉多快，全部由本机的 mujoco 决定。
2. 给 Codex 换一条兼容通道：base_url 填 https://taotoken.net/api
2.1 打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 注册并创建 YOUR_API_KEY
原文里「打开某网站注册、进控制台复制密钥」这一步，统一换成 TaoToken：打开页面注册账号，进控制台创建一把 API Key，复制下来备用。本文所有示例里都写成占位符YOUR_API_KEY，不要把自己的真 Key 贴进任何公开代码或者截图里。
同一时间顺手把模型 ID 记下来。每个账号能用的模型列表可能不同，所以别照抄别人博客里的字符串，直接以页面上模型广场当时的列表为准。把模型 ID 抄进配置文件，比事后猜「为什么报模型不存在」要省事得多。
2.2 ~/.codex/config.toml 里写自定义 provider，别把 ANTHROPIC_* 塞进来
Codex 读的是~/.codex/config.toml，结构跟 Claude Code 那套环境变量完全是两回事。常见错误是看到别人写ANTHROPIC_BASE_URL就照搬过来，结果 Codex 根本不认。正确写法是定义一个 model provider，把 base_url 指到https://taotoken.net/api，注意末尾不要加/v1：
# ~/.codex/config.toml model = "YOUR_MODEL_ID" # 以模型广场当时列表为准 model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY" wire_api = "chat"env_key写的是「去哪个环境变量里取 Key」，不是 Key 本身。所以还要在 shell 里导出一次，写进~/.bashrc或~/.zshrc更省心：
export TAOTOKEN_API_KEY=YOUR_API_KEY如果你的 Codex 版本平时用auth.json走登录态，就别去动那个文件，保持登录态不变，自定义 provider 靠env_key指定的变量取 Key 就够了。改完配置新开一个终端，让环境变量生效，再启动 Codex。
2.3 换 Key 或换模型时，改哪一行
后面调试时你大概率要换模型。换模型只动model = "..."这一行，provider 段落不用碰。换 Key 只动环境变量，配置文件也可以不碰。这种「一行一改」的分法，比把 Key 和地址混在命令行参数里清爽得多。
有个细节值得记住：base_url 只写https://taotoken.net/api。有人习惯性补成/api/v1，或者在末尾加个斜杠，结果请求打到不存在的路径上，返回 404，然后开始怀疑 Key 有问题。地址和 Key 是两件独立的事，出问题先分清是哪一件。
3. 让 Codex 生成 01_mujoco_helloworld.py：需求描述比提示词技巧更重要
3.1 把「1 米高、每 200 毫秒一行」写进需求
在 Codex 里描述需求时，把可验证的指标写清楚，比堆一堆「请你作为资深工程师」有用得多。可以直接这样交代：
在 t800 环境里生成 01_mujoco_helloworld.py，用 mujoco 3.4 的 Python API。场景是一个木块从 1 米高度自由落体，地面是 plane。仿真要做的是每 200 毫秒打印一次木块的高度，落地后停止。不要用 viewer，纯控制台输出。
关键信息有三个：起始高度 1 米、打印间隔 200 毫秒、落地停止。这三个写清楚，生成出来的脚本基本就不需要大改。反过来，如果只说「写一个 MuJoCo 自由落体」，Codex 很可能给你加可视化窗口、加渲染，而你在无显示环境里跑，第一句话就是 GLFW 报错。
3.2 生成结果逐段对照：freejoint、timestep、打印循环
生成的脚本大体应该长成下面这个样子，你可以逐段核对，不必逐字一致：
import mujoco import numpy as np XML = """ <mujoco model="free_fall"> <option timestep="0.002" gravity="0 0 -9.81"/> <worldbody> <geom name="floor" type="plane" size="2 2 0.1" rgba="0.35 0.35 0.4 1"/> <body name="block" pos="0 0 1.0"> <freejoint name="block_free"/> <geom name="block_geom" type="box" size="0.05 0.05 0.05" rgba="0.9 0.55 0.2 1"/> </body> </worldbody> </mujoco> """ model = mujoco.MjModel.from_xml_string(XML) data = mujoco.MjData(model) dt = model.opt.timestep print_interval = 0.2 next_print = 0.0 half = 0.05 # 木块半高，用来换算离地高度 while data.time < 3.0: if data.time >= next_print: z = data.qpos[2] h = max(z - half, 0.0) print(f"t={data.time:6.3f}s z={z:7.4f} m h={h:7.4f} m") next_print += print_interval mujoco.mj_step(model, data) if data.qpos[2] <= half + 1e-4 and data.time > 0.01: print(f"落地 t={data.time:6.3f}s") break第一段要看的是<freejoint/>有没有。这是最容易漏的地方：body 如果不带自由关节，就被焊死在 world 上，木块高度永远停在 1.0，看起来像「重力没生效」，其实是模型定义少了东西。
第二段看<option timestep="0.002">。mujoco 默认步长是 0.002 秒，也就是 2 毫秒，200 毫秒对应 100 步。步长越大跑得越快，但接触计算会变糙；这里保持默认就够用。
第三段看打印循环。判断条件写在mj_step之前还是之后，结果会差一个步长；打印间隔用累加而不是data.time % 0.2，避免浮点误差导致某一帧被跳过。这些都是小地方，但决定了输出能不能一眼看出规律。
3.3 Codex 写错 API 时，把报错原样贴回去
mujoco 的 Python API 版本之间有过改名，Codex 训练数据里混着好几个版本，偶尔会写出 3.4 里已经不存在的函数名。遇到AttributeError: module 'mujoco' has no attribute '...'这类报错，别自己瞎猜，把完整 traceback 连同你用的 mujoco 版本一起贴回对话，让 Codex 对照mujoco.__version__重新给方案。这比「帮我看看哪里错了」这种模糊提问有效得多。
还有一种情况是 Codex 用了from_xml_path但你没存文件。这里直接用from_xml_string把模型写在脚本里，就不用管路径问题，单个文件也方便版本管理。
4. python 01_mujoco_helloworld.py 跑起来，控制台该滚出什么
4.1 高度序列长什么样才算对
在 t800 环境里执行：
python 01_mujoco_helloworld.py控制台应该每 200 毫秒出一行，t从 0 开始按 0.2 递增，h从 1.0 附近开始往下掉。自由落体的位移是1/2 * g * t^2，g 取 9.81，那么大概 0.45 秒左右落地。换算到你的输出上，前两三行高度掉得慢，越往后每行之间差值越大，这就是平方关系在起作用。
如果每一行的高度差值几乎一样，说明你看到的不是自由落体，可能是把重力改小了或者加了阻尼。如果高度一直不变，回到 3.2 检查 freejoint。如果第一行就是 0.95 而不是 1.0，那是木块半高换算正确的结果，属于正常。
木块落地之后，脚本应该打印「落地」并退出。如果没有退出条件，它会一直贴着地面被接触力撑着，输出一串几乎相同的数字，那也没什么意义，直接Ctrl+C停掉即可。
4.2 不装渲染后端也能跑：headless 的注意点
这个脚本全程没有调用mujoco.viewer.launch_passive，也没有调用任何 renderer，所以不需要 GLFW、EGL 或者 OSMesa。这正好绕开了新手最常踩的一类坑：在没有图形界面的机器上跑一个带窗口的 demo，报一串glfwInit失败或者EGL not found。
如果你后面确实要加可视化，再单独装渲染后端，并且把MUJOCO_GL环境变量设成对应实现。当前这个 helloworld 阶段，纯控制台就够验证「环境通不通、代码对不对」这两件事了。
4.3 三类报错对照：找不到 mujoco、numpy ABI、模型 ID 不存在
排错时先把错误分成「本地环境的错」和「通道的错」，两类混在一起查会很痛苦。
| 报错现象 | 大概率原因 | 处理方式 |
|---|---|---|
ModuleNotFoundError: No module named 'mujoco' | 终端不在 t800 环境 | conda activate t800后重跑，确认sys.executable路径 |
ImportError: numpy.core.multiarray failed to import | numpy 与某个包的编译版本不匹配 | 重装三个包，或把 numpy 降到与 mujoco==3.4 匹配的版本 |
AttributeError: module 'mujoco' has no attribute ... | Codex 写的是别的版本 API | 贴 traceback 和mujoco.__version__回对话让它改 |
| 请求返回 404 或模型不存在 | base_url 多了/v1，或模型 ID 抄错 | 地址只留https://taotoken.net/api，模型 ID 重新核对 |
| 请求返回 401 | Key 没导出或写错 | 检查TAOTOKEN_API_KEY，必要时重新创建一把 |
前三条跟通道没关系，别急着去改配置；后两条跟物理仿真没关系，别去翻 mujoco 文档。分开判断，效率差好几倍。
5. 跑通之后回后台核对这次调用有没有记上
5.1 记录里该看到什么
代码跑出正确的高度序列，只能证明 mujoco 和你的 Python 逻辑没问题；它不能证明 Codex 那边真的通过通道把请求发出去了。所以还需要第二条证据：回 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 的用量页面看一眼，刚才那次生成请求有没有成功记录。
理想状态是两条同时成立：本地脚本能跑出从 1 米递减到落地的高度序列，后台能看到对应的成功调用。只要有一条不成立，就说明链路还有断点。Key 可以在 https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=verify_usage 创建或重新生成，换完记得同步更新环境变量并新开终端。
5.2 只有一边成立时怎么排查
如果脚本能跑但后台没有任何记录，先想想代码是不是你自己手写的。手写不会产生调用，这很正常。如果确实是让 Codex 生成的，却没有记录，检查 Codex 是不是还在用旧的 provider，或者环境变量没生效——env_key配置在文件里，变量没导出的话请求根本发不出去。
反过来，如果后台有记录但脚本跑不起来，问题就在本地：要么模型 ID 写错导致生成的内容不符合要求，要么生成过程被截断，脚本缺了后半段。这时候把当前脚本贴回对话，说明具体哪一行报错，让它基于你手上的 mujoco 版本重写那一段。
这两条证据合起来才叫「通道真的通了」。只看到代码能跑就往下写更复杂的场景，很可能在某个更大的脚本里才发现 Key 早就失效了，排查成本会高很多。
6. 下一步：把自由落体改成带参数的可控仿真
6.1 从硬编码到命令行参数
helloworld 跑完，最自然的延伸是把写死的数字变成参数。让 Codex 把起始高度、打印间隔、打印总时长抽成命令行参数，脚本结构基本不变，只是入口多几行：
python 01_mujoco_helloworld.py --height 1.5 --interval 0.1 --duration 2.0改完之后重点验证两件事：一是不同起始高度下落地时间符合sqrt(2h/g)的量级关系，二是打印间隔改了以后每行的时间戳确实跟着变。这两点都对了，说明参数是真的接进去了，而不是被函数里某个局部变量覆盖掉。
再往后可以加一个最简单的控制器：给木块一个初始水平速度，看它在落地的同时往前飘多远；或者把平面换成斜面，观察接触后的滑动。每一次加复杂度，都建议先让 Codex 只改一个变量，跑一遍确认输出符合直觉，再继续加下一个。
6.2 继续往下走
从空环境到跑出第一段高度序列，中间真正花时间的往往不是 mujoco 本身，而是「谁写脚本、有没有跑通、怎么证明跑通了」这三件事。把生成环节交给配好通道的 Codex，把验证拆成「控制台输出 + 后台用量记录」两条，剩下的就是纯粹的实验设计问题。
想先看模型和参数的话，去 TaoToken 模型对话 用同一把 Key 发一条消息，确认模型 ID 和地址没写错；打算长期用 Codex 写仿真代码，可以在 Coding Plan 看一下套餐是否够跑日常实验；Key 不够用或者要新建，直接进 控制台 API Keys。第一次配的时候容易把地址和 Key 混在一起，最稳的做法是每改一次配置就重跑一遍python 01_mujoco_helloworld.py，控制台有从 1 米递减的高度、后台有对应记录，两样都在，再动下一个场景。
