基于PyBullet与Stable-Baselines3的机械臂抓取强化学习实战

简介：强化学习在机器人控制领域的应用日益广泛，但直接在真实机械臂上训练成本高、风险大，仿真训练成为降低试错成本的关键手段。PyBullet作为轻量级物理仿真引擎，凭借其Python友好接口和与Gym环境的无缝集成，成为快速搭建机器人强化学习场景的理想选择。Stable-Baselines3提供了工业级PPO等算法实现，使研究者能专注于任务建模。本文围绕机械臂抓取任务，详细介绍了从环境搭建、状态与动作空间设计、分阶段奖励函数到PPO训练调参的完整流程，并探讨了仿真到真机迁移的边界问题，为机器人抓取方向的强化学习实践提供了一套可复现的工程方案。

1. 为什么这套源码选型落在 pybullet 和 stable-baselines3 上

先交代一下背景。去年我手里接到一个任务：要让一台法奥六轴协作机械臂学会“看见目标物体、伸过去、夹住、抬起来”这个完整抓取动作。领导的第一反应是直接上真机跑，但真机调试一次的成本摆在那里——线束、安全围栏、机械臂磨损、每次失败都要人工复位，更别提强化学习早期那种“完全不知道在干嘛”的探索阶段，真机根本扛不住。所以第一个决策就变成了：先在仿真里把策略训练到有模有样，再往真机迁移。

我对比过好几套仿真方案，最终定下的组合是 pybullet + stable-baselines3（以下简称 SB3），配套法奥机械臂的 URDF 模型，封装成一个标准的 Gym 环境。这套源码和文档说明，就是从那次项目里抽出来的完整可复现版本，核心目标是让一个有一定 Python 基础、但没怎么碰过强化学习的开发者，能在半天内跑通“仿真训练-模型保存-抓取评估”的完整流程。

1.1 我对比过的几套方案到底差在哪

在做选型的时候，我把当时主流的机器人仿真训练方案都过了一遍。这里直接给结论：

我最终选择 pybullet 的原因有两层。第一层是工程效率：pybullet 是纯 pip 安装，不需要 ROS 那一整套环境，也不需要注册账号或折腾图形界面，对做算法的人来说友好度拉满。第二层是环境接口：pybullet 的 API 可以直接拿到关节角度、末端位置、接触力、相机图像等信息，封装成 Gym 环境时基本不用做太多适配，而 SB3 官方就是基于 Gym 接口设计的，两者天生契合。

至于算法库为什么选 SB3 而不是自己写 PPO，理由很简单：SB3 的 PPO、SAC、TD3 实现经过大量项目验证，稳定性远胜于自己手撸的版本，而且支持 TensorBoard 日志、模型保存与恢复、回调函数这些工程细节。自己做强化学习算法研究的时候可以手写网络和 loss，但做“机械臂抓取”这种偏应用的任务，没必要在算法实现上重复造轮子。

1.2 这对组合的真实边界在哪里

选型归选型，也得说明白 pybullet + SB3 的边界，不然容易踩坑。

pybullet 的物理引擎毕竟不是专门做精细接触模拟的。它算刚体动力学、碰撞检测、摩擦、关节约束，精度在“够用”的水平，但如果你要做精密装配、软体抓取、高动态操作，它会力不从心。换句话说，pybullet 适合验证“这个任务能不能用 RL 学会”，不适合做“这个操作在真实物理环境下能否无缝复现”的最终保障。

SB3 这边也有一个需要理解的点：它提供的 PPO 是 on-policy 算法，样本效率偏低，意味着训练步数往往需要百万级。DDPG、TD3、SAC 这类 off-policy 算法样本效率更高，但对超参数更敏感，训练也更容易发散。在那个抓取项目里，我用 PPO 起步，等环境稳定后再切到 SAC 做对比，最终效果是 PPO 比较省心，SAC 在特定任务上能更快收敛。源码里两种算法的入口都留了，你可以在配置文件中切换。

再有一个容易被忽略的边界：仿真训练收敛不等于任务解决。机械臂抓取涉及感知、规划、控制三个层次，pybullet 里物体模型、摩擦系数、动力学参数都是理想值，换到真机之后会有 sim2real gap。这部分的处理我在第 5 章会详细展开。

2. 仿真环境搭建：从 pybullet 安装到机械臂模型导入

这节进入实操。我们一步一步来，先建环境，再把法奥机械臂的 URDF 模型导入 pybullet，最后把环境和物体摆好。

2.1 pybullet 环境配置的几个关键步骤

安装没什么好说的，两行命令：

pip install pybullet pip install stable-baselines3

如果你要用 TensorBoard 看训练曲线，SB3 会自动拉起 TensorBoard，也可以另装 tensorboard 包。

环境配置部分，最容易踩坑的是 pybullet 的连接模式。我用到的模式有两种：

• pybullet.GUI：带可视化窗口，方便调试，但会降低训练速度。
• pybullet.DIRECT：无图形界面，纯后台计算，训练速度快得多。

建议开发阶段用 GUI 模式看机械臂的动作是否合理，训练阶段切到 DIRECT 模式。源代码中我在启动参数里留了一个--gui开关，默认关闭，方便在服务器上直接跑。

初始化物理世界的基础代码长这样：

import pybullet as p import pybullet_data # 连接模式 mode = p.GUI if args.gui else p.DIRECT physics_client = p.connect(mode) # 加载地面 p.setAdditionalSearchPath(pybullet_data.getDataPath()) p.loadURDF("plane.urdf") # 设置重力和物理步长 p.setGravity(0, 0, -9.8) p.setTimeStep(1.0 / 240.0) # 240Hz

这里的setTimeStep(1.0 / 240.0)值得解释一下。pybullet 的默认物理步长是 1/240 秒，这个值越高，物理模拟越精细，但计算开销越大。对 RL 训练来说，如果你设置的动作控制频率是 30Hz，那每个控制周期内会执行 8 次物理步进。这个比例是合理的，既能保证接触计算的稳定性，又不会让训练慢到无法接受。

2.2 URDF 导入与末端执行器控制

法奥机械臂的 URDF 模型是整个环境的核心。如果你没有现成的 URDF，可以从法奥官方仓库找，也可以自己在 CAD 模型上用工具导出。我这里用的是简化版 URDF：保留了机械臂本体的 6 个关节，末端挂了一个二指夹爪。

加载代码：

# 加载机械臂 URDF robot_id = p.loadURDF( "franka_description/robots/franka_panda.urdf", # 以 Franka 为例，法奥模型同理 [0, 0, 0], [0, 0, 0, 1], useFixedBase=True, )

useFixedBase=True表示机械臂基座固定在工作台上，这符合真实场景。如果你要仿真移动机械臂或者 AGV 上的机械臂，这里改成 False，但那个场景复杂得多，不在本文讨论范围。

导入之后，需要拿到关节信息。pybullet 提供了getNumJoints和getJointInfo两个 API。这里有个非常关键的经验：不要凭关节名字猜索引，一定要遍历打印出来确认。实际项目中，我遇到过好几次 URDF 里关节顺序和预期不一致的情况，导致明明是控制“肩部”关节，结果机械臂乱动。下面是调试用的打印代码：

for i in range(p.getNumJoints(robot_id)): info = p.getJointInfo(robot_id, i) print(i, info[1].decode("utf-8")) # info[1] 是关节名称

确定了关节索引之后，控制方式有两种选择：位置控制和力矩控制。对于 RL 抓取任务，我建议用位置控制，因为动作空间更直观、训练更容易收敛。具体实现是用setJointMotorControlArray设置目标位置、速度增益和力增益：

p.setJointMotorControlArray( robot_id, joint_indices, p.POSITION_CONTROL, targetPositions=joint_angles, positionGains=0.05, velocityGains=1.0, forces=max_forces, )

夹爪部分，如果你的 URDF 自带两片夹爪，可以同样用位置控制控制其开合。如果不想引入夹爪的动力学细节，也可以用最简单的方式：在末端直接加一个“吸附”逻辑——当末端与物体距离小于阈值时，把物体固连到末端。这个方法物理上不真实，但训练效果很直观，适合快速验证抓取策略。

2.3 目标物体和视觉传感器的仿真

目标物体我这里用的是几个不同形状的方块，随机放置在工作台上。为了让训练有泛化性，每次 reset 时物体的位置和朝向都会随机变化。

def _reset_object(self): x = np.random.uniform(-0.2, 0.2) y = np.random.uniform(-0.2, 0.2) z = 0.05 # 桌面高度以上 init_orientation = p.getQuaternionFromEuler([0, 0, np.random.uniform(-np.pi, np.pi)]) p.resetBasePositionAndOrientation(self.object_id, [x, y, z], init_orientation)

如果你要对齐真实场景，可以用loadURDF加载物体的 urdf，也可以直接用createCollisionShape+createMultiBody创建原生几何体，后者更轻量。我代码里默认用了几个简单形状的 URDF，这样看起来更真实。

至于视觉传感器，pybullet 用getCameraImage可以拿到 RGB 和深度图。但不建议在 RL 训练一开始就上视觉输入，原因有二：一是图像输入维度大，SB3 需要切到 CNN 策略，训练速度会明显下降；二是如果只做位置抓取（物体位置已知或可以直接用状态量），视觉反而是多余的。我设计的源码里有视觉感知的开关，但默认关闭，用位置信息作为主要观察量，需要做视觉抓取项目的同学可以自己打开。

3. 抓取任务的强化学习建模：状态、动作、奖励怎么定

这一节是整个项目的灵魂。很多 RL 项目跑不出来，问题不在算法，而在环境建模。机械臂抓取任务尤其如此——状态空间少一个量、动作空间尺度不对、奖励函数有漏洞，都会导致训练失败。

3.1 状态空间：到底要让智能体看到什么

我的设计思路很简单：智能体需要知道的信息包括“自己在哪里”“目标在哪里”“自己现在动得多快”。于是状态向量按下面的方式组合：

• 机械臂 6 个关节的角度（用 sin 和 cos 编码，避免角度周期性导致的不连续）
• 机械臂 6 个关节的角速度
• 末端执行器当前位置与目标物体位置的三维差值
• 末端执行器的四元数（表示朝向）
• 夹爪开合度

如果你习惯用位置向量，关节角度可以用原始角度值，但要注意角度接近 ±π 边界时的不连续问题。我后来全部改成 sin/cos 编码，训练稳定了很多。

状态向量最终大概 20 多维度。这个维度对 MLP 策略来说非常友好，训练速度快，也不需要太深的网络。

还有一点：状态空间里的量纲不一致会导致训练困难。关节角速度的量级是每秒几弧度，位置差值的量级是几厘米到几十厘米，如果不做归一化，网络要花很多步去适应不同尺度的输入。我在环境代码里加了一步 MinMaxScaler，把每个维度的数值范围归一到 [-1, 1]，训练效果提升明显。

3.2 动作空间：关节空间还是笛卡尔空间

这个问题几乎出现在每个机械臂 RL 项目里。动作空间有两种主流选择：

• 关节空间：输出 6 个关节的目标角度。优点是控制简单，不需要求逆解，pybullet 直接支持关节空间位置控制；缺点是学习困难，因为用户很难凭直觉设定“把末端放到物体上方”对应的关节角度组合。
• 笛卡尔空间：输出末端执行器在三维空间中的目标位移（或者绝对位置），然后需要求解逆运动学，得到关节角度再执行。优点是任务语义清晰，策略只需要学会“向物体方向移动这段距离”就行；缺点是要在环境里做一次 IK 求解。

我的源码里两种模式都留了，默认用笛卡尔空间 +calculateInverseKinematics：

# 根据末端目标位置求逆解 joint_positions = p.calculateInverseKinematics( robot_id, end_effector_index, target_position, target_orientation, )

实际体验下来，笛卡尔空间的动作空间学习速度快很多，尤其是抓取这类任务，因为策略不需要去理解复杂的关节耦合关系。代价是每次 step 都要做 IK 计算，训练时间略微变长，但这点开销完全值得。

动作空间的具体形式我定义为：末端执行器在 x、y、z 方向上的增量位移 + 夹爪开合动作，共 4 维。增量位移的范围限制在 ±0.02m 左右，这样机械臂的运动轨迹不会是粗暴的折线，也更接近真实操控。

3.3 奖励函数：分阶段设计是你最重要的决策

奖励函数决定了智能体的学习方向，但也是最容易埋坑的地方。我最初的奖励做得很简单：“抓到物体 +10，没抓到给一个小惩罚”。结果训练了一百万步，成功率接近零。原因很直接：奖励太稀疏，智能体根本学不到中间的反馈。

后来我把任务拆成了四个阶段，每个阶段都有对应的奖励信号：

• 接近奖励：末端与目标物体的距离缩小，给予正向奖励；增大则给予惩罚。
• 接触奖励：末端与物体发生接触（通过getContactPoints检测）时，给予一次性奖励。
• 抓取奖励：物体被夹持（夹爪闭合且与物体保持接触），给予一次性奖励。
• 抬升奖励：物体离开桌面达到一定高度，给予一次性奖励。

这四个阶段本质上是把稀疏的“抓取成功”信号拆成了靠近、接触、夹住、抬起四个子目标。整条奖励路径更平滑，智能体能从每一步中学到“这样做比那样做更好”。

实际实现的奖励函数权重我调过很多轮，最终用了一组比较稳的参数：

reward = ( - 0.5 * distance_change # 接近惩罚/奖励 + 1.0 * contact_reward # 接触 + 2.0 * grasp_reward # 抓住 + 3.0 * lift_reward # 抬起 - 0.01 * time_step # 时间惩罚，鼓励快 - 0.5 * out_of_bound_penalty # 越界惩罚 )

这里注意distance_change的符号：如果这一帧物体离末端更近，distance_change是负值，乘以 -0.5 就变成了正向奖励。所以奖励函数里第一项实际上鼓励的是“靠近”动作。这个设计对训练收敛非常关键。

4. PPO 训练实操：用 SB3 把环境跑起来

环境封装好之后，训练本身反而是最“模板化”的部分。SB3 的训练入口很简洁，但在跑起来之前，有一些细节需要处理。

4.1 用 SB3 搭建训练脚本

SB3 需要环境符合 Gym API，也就是实现reset、step、render等接口。这里我用gym.Env封装了一下：

import gym from gym import spaces class FrankaGraspEnv(gym.Env): def __init__(self, gui=False): super().__init__() self.robot_id = None self.object_id = None self.action_space = spaces.Box(low=-1, high=1, shape=(4,), dtype=np.float32) # state 维度约 26 维 obs_dim = 26 self.observation_space = spaces.Box(low=-np.inf, high=np.inf, shape=(obs_dim,), dtype=np.float32) def reset(self): # 重置物理世界、机械臂、物体到初始状态 pass def step(self, action): # 执行动作，计算奖励，判断是否终止 pass def render(self, mode="human"): pass

环境封装好之后，训练脚本非常简洁：

from stable_baselines3 import PPO from stable_baselines3.common.monitor import Monitor from stable_baselines3.common.callbacks import CheckpointCallback, EvalCallback env = Monitor(FrankaGraspEnv(gui=False)) model = PPO( "MlpPolicy", env, n_steps=2048, batch_size=256, n_epochs=10, gamma=0.99, gae_lambda=0.95, clip_range=0.2, ent_coef=0.0, learning_rate=3e-4, verbose=1, tensorboard_log="./tb_logs/", ) # 定期保存模型，训练过程评估 checkpoint_callback = CheckpointCallback(save_freq=10000, save_path="./models/") eval_callback = EvalCallback(env, eval_freq=5000, best_model_save_path="./models/best/") model.learn(total_timesteps=1_000_000, callback=[checkpoint_callback, eval_callback]) model.save("franka_grasp_ppo")

这段代码里MlpPolicy表示用全连接网络处理状态向量，因为是低维状态输入，不需要卷积网络。如果你开启了视觉观察，这里需要换成CnnPolicy。

4.2 超参调试经验：一组能用的初始参数和调参方向

超参数这个东西，网上几百篇教程各有说法，但实际项目里你需要的是一组能跑通的起点，然后针对自己的任务微调。基于那次项目的经验，我给出这组初始参数和理由：

调参的几个方向，我用实际经验总结一下：

第一，如果训练后期发现探索不够，成功率停在某个值上不去，提升ent_coef到 0.01~0.02，让智能体多一点随机性去尝试新动作。第二，如果训练曲线震荡得很厉害，尝试降低learning_rate到 1e-4，代价是收敛变慢。第三，n_steps和batch_size的比值不要太小，否则策略更新时样本相关性太强，导致训练不稳定。我试过一次把batch_size设成 64，训练过程极其不稳定，改成 256 之后明显好转。

4.3 训练曲线怎么看：别只盯着 mean reward

训练开始后，你会看到终端里不断刷新的日志，也会在 TensorBoard 里看到rollout/ep_rew_mean、rollout/ep_len_mean这些指标。这里有个非常重要的经验：ep_rew_mean 上升不代表策略在变好。

我在第一次训练时遇到过这样的情况：reward 一路走高，但实际观察机械臂的行为，它根本没有稳定地抓住物体，而是发现了一种“钻空子”的方式——比如快速摆动末端，碰巧把物体扫到地上，因为我的奖励里没有惩罚物体落地，所以这种行为反而获得了高分。这提醒我们，训练过程中要时不时打开 GUI 模式观察实际行为，不能只看曲线。

TensorBoard 里我最看重三个指标：

• rollout/ep_rew_mean：平均奖励，看整体趋势。
• rollout/ep_len_mean：平均回合长度，如果这个值持续下降，说明智能体在尝试用更少的步骤完成任务——这是好的信号。
• rollout/entropy：策略的熵，如果熵下降太快，说明策略过早变得确定性，可能卡在了局部最优。

看图的顺序建议是这样：先看 entropy 是否正常下降，再看 ep_len_mean 是否缩短，最后才看奖励曲线。如果 entropy 下降过快而 ep_len_mean 基本不动，优先调高熵系数，延长探索阶段。

5. 从仿真到真实：评估脚本和部署边界

训练结束不等于交付。模型在仿真里能抓 90% 的成功率，换到真机上可能连 20% 都不到。我在这部分会讲清楚评估脚本要测什么，以及部署到真机之前要做的心理准备。

5.1 评估脚本要测什么

SB3 的evaluate_policy可以快速给出平均回报，但对机械臂抓取任务来说，这个指标不够直观。我更推荐在评估时直接统计成功率：在固定数量的测试回合中，机械臂完整走完“到达-接触-夹住-抬升”的回合占比多少。

我写的评估脚本逻辑：

from stable_baselines3.common.evaluation import evaluate_policy # 自定义成功率统计函数 def success_rate(env, model, n_episodes=50): success_count = 0 for _ in range(n_episodes): obs = env.reset() done = False episode_success = False while not done: action, _ = model.predict(obs, deterministic=True) obs, reward, done, info = env.step(action) if info.get("is_success", False): episode_success = True break success_count += int(episode_success) return success_count / n_episodes rate = success_rate(env, model, n_episodes=50) print(f"成功率: {rate:.2f}")

评估环境尽量和训练环境保持一致的随机分布，但可以固定随机种子，确保测试结果可复现。种子固定之后，同一个模型跑十次评估，成功率基本稳定，方便对比不同 checkpoint 的效果。另外建议把评估时的物体大小、形状和训练时稍微错开一点，哪怕只换一两个物体，也能看出模型有没有过拟合到训练物体上。我做了一组对比实验：训练时用三个方块，评估时加入一个圆柱体和一个球体。结果发现模型在长方块上成功率 90%，在圆柱体上掉到 60%，在球体上只有 30%。这个结果说明了泛化能力还有待提升，也印证了“训练集和测试集要分开”的原则。

5.2 真机部署的边界：仿真到现实到底差在哪

这是整个项目里最容易被低估的部分。pybullet 里定义的质量、惯性、摩擦系数都是理想值，真实世界的接触动力学要复杂得多。我列一下我踩过的差异：

• 摩擦系数：真实夹爪和物体之间的摩擦力受表面材质、湿度、磨损程度影响，仿真里设一个固定值，真机上可能抓不住或者抓不稳。
• 控制延迟：pybullet 里动作执行和状态读取几乎零延迟，真机通过 TCP/IP 或 CAN 总线通信有数十毫秒级延迟。这会直接影响 RL 策略的表现，因为策略是在“假设状态即时更新”的前提下训练出来的。
• 关节加速度限制：仿真里你可以直接设置关节目标位置，电机瞬间到位；真机上电机有最大加速度和速度，轨迹跟踪会有滞后。
• 相机标定：如果你用了视觉输入，仿真里的相机内参精确已知，真机需要标定，标定误差会传递到抓取精度上。

所以我在源码文档里明确建议：仿真训练出来的模型，别指望一键部署到真机。更务实的路线有三种：

1. 把仿真模型当作初始策略，在真机上用安全护栏下做少量微调（这个成本依然不低）。
2. 用仿真阶段确定任务建模方式、奖励函数和超参数，真机上换用传统控制方法实现稳定抓取。
3. 做 sim-to-real 迁移，通过 domain randomization 在训练时随机化物体位置、质量、摩擦系数，让策略学到一个更鲁棒的策略。

6. 从失败到收敛：我把训练过程拆开看了几遍才明白

训练过程不会一帆风顺。这一节记录的是我在项目里遇到的最典型的几个问题，以及我如何定位和解决。这些问题在 RL 项目里几乎一定会碰到，希望你能少走弯路。

6.1 机械臂乱抖：可能不是模型的问题

第一次训练跑到 50 万步时，我发现机械臂在接近物体的过程中会高频抖动，动作看起来像得了帕金森。我开始以为是策略不够好，后来检查环境代码才发现，问题出在动作的平滑度上。

我的原始设计是：策略输出末端位移增量，然后在这个增量的基础上直接做 IK 并设置关节目标。问题在于，策略每个控制周期输出的增量波动较大，机械臂关节速度变化太剧烈，呈现出抖动。解决办法是在动作执行前加一个移动平均滤波，或者说，限制单步动作的变化幅度：

# 动作平滑：限制单步最大变化量 delta_pos = np.clip(action[:3] * max_step, -max_step, max_step) target_pos = current_pos + delta_pos

另一个可能的原因是控制频率太低。如果你每个控制周期内只执行一次 IK 计算，而机械臂需要 8 个物理步才能到达目标，中间过程会显得不连续。调试时把控制频率调高到 50Hz 以上，抖动问题基本能缓解。

6.2 奖励被“钻空子”：如何识别和修复

前面提到过，奖励曲线上升但行为不合理，那大概率是奖励设计有漏洞。我遇到的最典型的漏洞是“物体落地没有惩罚”。

由于初始版本我只奖励“靠近-接触-抓取-抬起”，没有明确惩罚“物体掉落”，智能体发现把物体扫下桌子也能触发接触奖励，而且不用完成后续的抬升动作，比老老实实抓取更省事。修复办法是在奖励函数里加上物体高度变化的惩罚项：如果物体 z 坐标低于桌面高度，扣 1 分并提前终止回合。

另一个常见漏洞是“夹爪没碰到物体也能通过状态作弊”。因为我的状态里包含了末端与物体的位置差，如果奖励只对“距离小于阈值”给予奖励，智能体可能在距离阈值附近反复试探，而不是真正执行抓取。解决办法是把抓取奖励与夹爪闭合状态绑定：必须夹爪闭合且与物体接触，才算有效抓取。

6.3 训练几乎不收敛：先检查环境再调算法

有一次我从头调一个新的奖励权重组合，跑了 20 万步，reward 几乎没有变化。我先怀疑是超参数问题，调了半天没效果，最后仔细检查环境代码才发现：在reset()里我恢复了机械臂关节目标位置，但忘记恢复关节速度，导致每回合初始状态不一致，策略学到的经验互相矛盾。

这类问题在 RL 环境里非常隐蔽。建议每次调奖励或者改动作空间之后，先写一个小脚本确认环境在不同随机种子下能正常生成初始状态，再跑长时间训练。另外，可以用 SB3 的env.check_env()做基本的环境一致性检查，会发现一些明显的 Api 问题，但像“忘记恢复速度”这种逻辑 bug 它检不出来。

6.4 仿真和真机差异的真实妥协：我给自己的两条规矩

在这个项目做完之后，我对“仿真训练”这件事有了更清醒的认识。仿真不是真机的替代品，它只是把成本前置了。我在源码文档的结尾写了两条规矩：

第一条，仿真里跑不出来的策略，真机基本不可能跑出来。所以仿真训练的最大价值是筛选出“有潜力”的动作策略，而不是直接产出成品。第二条，往真机迁移前，至少要把工作台的摩擦系数、物体重量、机械臂动态性能这些参数测量一遍，尽量在仿真里还原真实环境，即便没法完全一致，也能把差距缩小到一个数量级以内。

我在实际交付时还做了另一件事：把仿真训练出来的轨迹录下来，跑一遍离线轨迹跟踪对比。如果仿真里的策略轨迹在离线回放时就已经不满足加速度、速度限制，那真机调试时一定会更明显。这个“离线轨迹筛选”步骤帮我砍掉了很多不靠谱的模型，省下了大量真机调试时间。

再说一个关于源码和文档的小建议。项目里我写了两种算法入口（PPO 和 SAC）、三种奖励配置、两种动作空间模式，这些配置都放在了 config 文件里，而不是硬编码在训练脚本中。这样在跑对比实验时非常方便，只需要改配置重启训练就行。文档我用了标准的 README 结构，记录了环境安装、运行方式、算法对比、踩坑记录，其中踩坑记录那块儿后来被同事评为整个文档最值钱的部分。这个习惯，希望你也用得上。

本文还有配套的精品资源，点击获取