在将强化学习（RL）算法从仿真环境（如 Isaac Gym）部署到真实机器人（如 Unitree Go2）的过程中，我们经常会在项目的 checkpoints 或 logs 文件夹里看到一堆不同后缀的文件。

最典型的就是这三剑客：parameters.pkl、.pt (Checkpoint) 和 .jit (TorchScript)。

它们到底是什么？各有什么用？实机部署到底该加载哪一个？本文将结合经典的四足机器人 RL 代码库（如 walk-these-ways 变体）进行梳理。

太长不看版

如果你只需要一个最短结论，请看下表：

文件类型	本质	主要作用	核心应用场景
parameters.pkl	Python pickle 序列化的配置与元数据	还原训练时的环境配置、超参数、归一化信息等	评估、复现实验、部署前重建运行环境
Checkpoint (.pt)	训练状态快照（通常是 state_dict）	断点续训、继续训练、微调、回滚到某个迭代	训练环境 (Training)
TorchScript (.jit)	可序列化的 PyTorch 推理图/模块	脱离原训练类定义，进行高效推理和部署	推理/实机部署 (Inference/Deploy)

---

1. parameters.pkl：模型的“运行说明书”

它通常不是“模型本体”，而是 “模型运行所需上下文”。

在复杂的 RL 项目中，常见内容包括：

• 环境配置 Cfg
• 算法超参数
• 观测维度、动作维度
• 域随机化参数
• 归一化统计量、奖励配置、课程学习状态等

代码库实例解析：
在这个仓库中，parameters.pkl 是通过 ml_logger 记录实验参数生成的。在训练脚本 scripts/train.py 中，你可以看到这样的调用：

logger.log_params(AC_Args=vars(AC_Args), PPO_Args=vars(PPO_Args), RunnerArgs=vars(RunnerArgs), Cfg=vars(Cfg))

本质上，它是 “这次训练用了什么配置”的归档。

它的加载作用非常明确：

• 仿真评估 (scripts/play.py)：先读取 parameters.pkl，再把里面的 Cfg 写回环境配置，确保测试环境与训练环境一致。
• 实机部署 (go2_gym_deploy/scripts/deploy_policy.py)：同样会先读取它，用于构建硬件 Agent 实例。

结论： parameters.pkl 解决的是“模型该在什么世界里运行”这个问题，而不是“模型参数是多少”。

---

2. Checkpoint (.pt)：训练过程的“原材料”

Checkpoint 是训练过程中的 “存档点”。

最标准的 Checkpoint 往往会保存模型权重、Optimizer 状态、Scheduler 状态、AMP scaler、当前 epoch 以及随机数状态。但在很多实际的 RL 项目中（包括当前仓库），它往往只存储了模型权重。

代码库实例解析：
在 PPO 算法核心代码中 (go2_gym_learn/ppo/__init__.py)，保存逻辑如下：

logger.torch_save(self.alg.actor_critic.state_dict(), "checkpoints/ac_weights_xxxxxx.pt")

这意味着这里的 ac_weights_last.pt 是 actor_critic 的权重快照。它适合用来恢复模型参数，但不一定是包含优化器状态的“完整训练断点”。

典型用途：

• 训练中断后继续训
• 从某个已训好的策略继续微调 (Fine-tuning)
• 对比不同迭代 (Iteration) 的性能

恢复逻辑通常是先实例化原有的 ActorCritic 类，再执行 load_state_dict(...)。

结论： Checkpoint 解决的是“把训练好的权重重新灌回网络代码里”的问题。

---

3. TorchScript (.jit)：面向部署的“成品件”

TorchScript 是 PyTorch 模型的一种可序列化推理形式。它的出现是为了让模型能够脱离 Python 运行。常见的生成方式有 torch.jit.script(model) 和 torch.jit.trace(model, example_input)。

代码库实例解析：
在这个项目中，主要使用 script 方式，将策略拆分为两个独立的模块进行导出：

• adaptation_module_latest.jit
• body_latest.jit

在加载时，直接使用 torch.jit.load(...) 即可：

• 仿真推理： 见 scripts/play.py
• 实机部署： 见 go2_gym_deploy/scripts/deploy_policy.py

TorchScript 的核心价值：

1. 不需要原始 Python 模型类定义也能直接加载。
2. 更适合部署和推理，轻量且高效。
3. 可以在 Python 之外的环境（例如 C++ 端）里用 libtorch 直接跑。
4. 比原始 Checkpoint 更“便携”。

结论： TorchScript 解决的是“把模型带到训练代码之外去跑”的问题。

---

4. 总结：三者的协同工作流

我们可以把它们理解成生产线上的三个层级：

1. parameters.pkl (说明书)：告诉你训练时的环境和超参数是什么。
2. Checkpoint (原材料)：保存训练出来的原生权重，主要给训练代码自己恢复用。
3. TorchScript (成品件)：把模型打包成最适合机器推理与部署的形式。

一个典型的四足机器人 RL 工作流如下：

训练脚本启动
➔ 保存配置到 parameters.pkl
➔ 定期保存权重到 Checkpoint .pt
➔ 训练结束/验证时，从当前权重导出 TorchScript .jit
➔ 实机部署时，读取 parameters.pkl 重建控制环境，直接加载 .jit 执行动作推理。

“我想复现实验设置” ➔ 找 parameters.pkl
“我想接着训练/微调” ➔ 加载 Checkpoint (.pt)
“我只想把策略丢到机器狗上跑起来” ➔ 认准 TorchScript (.jit)