HER算法实战：从原理到PyTorch实现，破解强化学习稀疏奖励难题

别小看“hindsight”这个词。它字面意思是“后见之明”，往深了说，是一套改变了我做强化学习（RL）项目思路的方法论。我今年大半年都在跟机器人抓取和机械臂控制死磕，最大的收获不是跑通了多少个demo，而是把Hindsight Experience Replay（后见经验回放，简称HER）真正用到了工程里。先说结论：如果你正在做多步决策、稀疏奖励或者机器人操作类任务，HER几乎是目前让智能体从“完全学不动”到“勉强能收敛”的最实用技巧之一，没有花哨的网络结构，纯粹是对样本的重新理解。这篇博客我打算从原理、数学细节、PyTorch实现到训练踩坑，完整还原我自己的实操过程，你会看到我是怎么一步步把HER从论文搬到代码里的。

我一开始看到HER论文的时候，第一反应也是“这玩意儿不就是换了个奖励函数吗”，后来自己搭环境、调参、看loss曲线，才意识到它的核心并不在奖励本身，而在于重新定义“什么算完成”。这篇内容适合三类人：正在做机械臂/抓取控制但模型死活不收敛的RL工程师；刚入门强化学习想找一份能直接参考的复现教程的研究生；以及所有对“智能体如何从失败中学习”这件事感兴趣的技术爱好者。接下来我不会讲太多分布式训练、大规模并行那些花活，全部内容都聚焦在单机、单环境、能跑通的朴素实践上。

1. 为什么一个“事后诸葛”能让强化学习起死回生

1.1 认知心理学里的“后见之明”和RL里的HER有什么关系

先聊一个生活中的场景。你开车去一个陌生的商场，导航把你导到一个死胡同，你只能倒出来换条路。事后你回想起来，其实在第一个路口就应该左转，当时怎么就跟着导航走了呢。这种“事后我才知道正确做法”的体验，就是hindsight bias——后见之明偏差。

HER算法的起名灵感正是来自于此。在强化学习里，一个机械臂的任务是“把方块推到目标位置”。很多时候它推了半天，方块没到目标点，于是每一步的奖励都是-1。在纯粹的稀疏奖励设定下，这个智能体学不到任何梯度信号，策略完全随机游走。HER的核心想法特别朴素：虽然这次没推到目标位置，但至少方块到达了另一个位置，那我把“另一个位置”重新认定为这次尝试的目标，这不就有了一条“成功”的经验吗？

这听起来有点像自己骗自己，但背后是有严谨逻辑的。智能体在探索过程中产生的状态转移，本身包含了大量关于“如何操控物体”的动态信息。这些信息和“是否达成既定目标”是解耦的。HER把“目标”这个变量从固定值变成了可重标注的变量，从而把大量原本被判死刑的失败轨迹救活了。从损失函数的角度看，相当于在训练数据分布里主动增加了更多高价值、非稀疏的样本，让Q函数或策略函数有梯度可循。

1.2 稀疏奖励任务为什么是强化学习的“癌症”

你要理解HER的价值，必须先理解稀疏奖励为什么难搞。我举个最直观的例子：用一个6自由度的机械臂去推一个桌面上的小方块，目标位置是（0.5, 0.2, 0.1）。如果方块最终位置和目标位置的欧氏距离小于5厘米，奖励为0，否则奖励为-1。

在这种设定下，机械臂一开始是完全随机的动作。假设动作空间连续，每个动作的精度要求很高，那么随机策略下能撞到5厘米误差范围内的概率可能连万分之一都不到。智能体跑完一整条episode，收到的所有reward全是-1。这会导致什么？所有(s, a, r, s')样本的回报几乎一样，价值函数无法区分哪个状态更好，策略梯度方差巨大，训练loss直接横盘。

用生活类比就是：你让一个完全没学过英语的人去做高考完形填空，他每道题都蒙，对答案的时候发现自己全错，没有任何一道题能告诉他“哪个选项更接近正确答案”。他做完一百套卷子，水平还是零。RL智能体也一样，稀疏奖励下它根本得不到“部分正确”的反馈。

这时候有两个救援方向：一个是设计距离奖励、势函数奖励之类的稠密奖励，把“离目标近一点”这个信息纳入reward；另一个就是HER，不修改reward，而是修改目标本身。稠密奖励的问题是容易引入局部最优，比如机械臂学会了往目标方向伸，但忽略了绕开障碍物，因为撞到障碍物在距离度量上可能也是“进步”。HER相比之下更干净，它不诱导策略走捷径，而是纯粹增加有效样本量。

2. 核心原理拆解：目标重标注是怎么把失败样本变成金矿的

2.1 一个清晰的目标重标注流程

HER的核心操作发生在经验回放阶段。假设一个episode的轨迹是(s0, g, a0, r0, s1, a1, r1, s2, ..., sT, aT, rT)，其中g是原始目标，r_t是根据g计算的奖励。正常情况下，这一整段轨迹会作为一条经验存入replay buffer。

HER的做法是：在存储经验时，除了保留原始目标，再额外生成k个“虚拟目标”。最常见的选择是取episode最后几步里智能体实际到达过的状态s_t'，把它作为新的目标g'。然后重新计算一整条轨迹的奖励序列，也就是把每一步的奖励变成“智能体是否到达了s_t'”而不是“是否到达了原始g”。这些重标注后的轨迹也存进buffer里。

我拿我实际跑的推方块任务举例。原始目标g是（0.65, 0.40, 0.03），结果episode跑完，方块掉到桌子边上，最终位置是（0.20, 0.70, 0.03）。如果我不做HER，这条轨迹就是一个纯失败样本。做了HER之后，我取出最终状态s_T，把目标改成（0.20, 0.70, 0.03），重新沿着时间步计算奖励——注意，这时候在轨迹的最后一步，智能体确实“到达”了新目标，所以奖励是0，前面步骤因为没到达，奖励是-1。这条轨迹不再是“全失败”，它变成了一个包含“最终成功”信息的样本。

这里有一个值得注意的细节：一个episode往往不止只重标注一个目标。论文里最常见的做法是取episode中随机k个状态作为额外目标，一般k取4或8。这样做的好处是，一条50步的轨迹可以一次性生成多条不同目标的成功/失败混合样本，极大提升样本利用率。对我自己的项目来说，k=4已经能让FetchReach环境的成功率在十万步内从0爬到90%以上，没必要盲目加大k导致buffer爆炸。

2.2 重标注后样本到底给网络带来了什么信息

很多人会问，重标注之后的样本，和原来的样本在梯度上到底有什么区别？我拆开来说。对于DDPG这类基于Q函数的算法，原本的loss是让Q(s, a)去拟合r + gamma * max_a' Q(s', a')。在原始稀疏奖励下，几乎所有样本的r都是-1，Q函数学出来在整个状态空间里都差不多“这个动作不好那个动作也不好”，没有任何区分度。

经过HER重标注后，一部分样本变为了“最终会成功”的样本。这些样本在轨迹最后一步的r=0，而且时序差分误差是非零的，Q函数会学到“在某些状态下，某些动作会导向成功”。更重要的一层是，HER通过重标注让同一个状态转移(s_t, a_t, s_{t+1})同时出现在多条不同目标的经验中。这意味着Q函数不再只针对一个固定的目标学习，而是针对大量不同的目标学习。用工程的话说，就是目标空间被充分采样了，Q函数变得平滑，泛化性大幅提升。

如果你用的是PPO这类on-policy算法，HER同样能插进去，因为它本质上是改replay buffer里的数据分布，而PPO要配合经验回放的话，需要注意重要性采样权重，避免分布偏移太厉害。我个人建议，HER最舒服的搭配还是off-policy算法，DDPG、TD3、SAC都不错，后面我会给出一套我实际大量使用的组合。

2.3 损失函数层面，HER改了什么

这里我用一个公式帮大家把HER的改动看清楚。原始DDPG的Q函数loss是：

L = E[(Q(s, a|g) - (r(g) + gamma * max_a' Q(s', a'|g)))^2]

注意，这里的g是固定的原始目标。加入HER后，对于重标注样本来讲，g变成了g'，r(g)也变成了r(g')。所以loss变成了：

L = E[(Q(s, a|g') - (r(g') + gamma * max_a' Q(s', a'|g')))^2]

换句话说，网络结构、优化器、超参都不用动，唯一的变化就是输入给Q函数的目标从g变成了g'。而g'来自每个episode实际到达的状态，数量远远大于原始成功样本。这个改动虽然表象简单，但对梯度质量的影响是质的。

为什么不直接修改reward函数，让“离哪个目标近就给正奖励”呢？因为那样做，策略很容易钻奖励函数的空子。比如距离奖励如果采用L2范数，机械臂可能会找到一条“先把方块推到桌子边缘，让距离快速下降”的路径，但这和真正的“推到目标位置”完全不是一回事。HER不修改真实环境的奖励，它只是改变了经验样本的“目标标签”，因此不会引入这种奖励黑客问题。

3. 实操过程：从零搭建一个HER训练系统

3.1 我的开发环境和代码结构

我在这个项目里用的是Python 3.9、PyTorch 2.0.1、mujoco-py 2.1，环境是gymnasium-robotics的FetchReach-v1。如果读者用的是老版本的gym，注意接口差异，FetchReach的observation_keys在部分版本里命名不太一样。

代码目录结构我推荐这样组织，简单清晰，适合自己研究和扩展到新任务：

her_project/ ├── envs.py # 环境封装，兼容gym接口 ├── her_buffer.py # HER重标注缓冲区的核心实现 ├── networks.py # Actor/Critic网络定义 ├── ddpg_agent.py # DDPG算法主体，集成HER ├── train.py # 训练入口 ├── evaluate.py # 评估脚本，跑成功率 └── config.py # 超参数集中管理

我强烈不建议把强化学习算法写成一个几百行的巨型脚本。因为调参的时候，你很快就会需要改buffer策略、改奖励函数、改目标采样方式，混合在一起的代码会让你改一行崩三处。我自己早期就是这么干的，后来花了一个下午把所有逻辑拆开，发现调试效率直线上升。

3.2 HER缓冲区核心代码实现

这是整个项目里最值得仔细看的部分，我直接贴出我精简后仍能完整运行的核心代码，并逐段解释为什么这么写。

import numpy as np import random class HerBuffer: def __init__(self, capacity, k_future=4, reward_func=None): """ capacity: 缓冲区最大容量 k_future: 每个episode额外使用的未来状态作为目标的数量 reward_func: 奖励函数，计算(state, goal, next_state) -> reward """ self.capacity = capacity self.k_future = k_future self.reward_func = reward_func self.buffer = [] self.pos = 0 def store_episode(self, episode): """ episode: dict，包含 obs, actions, next_obs, goals，每个都是list 这里假设goals是每个时间步的目标（Fetch环境里goal通常不随时间变化） """ obs = episode['obs'] next_obs = episode['next_obs'] actions = episode['actions'] goals = episode['goals'] # 原始目标：通常整条episode的目标都一样，取第一个 original_goal = goals[0] # 额外目标：随机选择k_future个未来时间步的next_obs # 注意，这里选的是next_obs，因为下一个状态才是“实际到达的位置” future_states = [next_obs[t] for t in range(len(next_obs))] future_indices = random.sample(range(len(next_obs)), min(self.k_future, len(next_obs))) extra_goals = [future_states[i] for i in future_indices] # 把所有目标合并：原始目标 + 额外重标注目标 all_goals = [original_goal] + extra_goals for goal in all_goals: for t in range(len(obs)): reward = self.reward_func(obs[t], goal, next_obs[t]) done = (t == len(obs) - 1) self._store_transition(obs[t], actions[t], reward, next_obs[t], goal, done) def _store_transition(self, obs, action, reward, next_obs, goal, done): transition = (obs, action, reward, next_obs, goal, done) if len(self.buffer) < self.capacity: self.buffer.append(transition) else: # 环形缓冲区，覆盖最旧的数据 self.buffer[self.pos] = transition self.pos = (self.pos + 1) % self.capacity def sample(self, batch_size): batch = random.sample(self.buffer, batch_size) obs = np.array([t[0] for t in batch]) actions = np.array([t[1] for t in batch]) rewards = np.array([t[2] for t in batch], dtype=np.float32) next_obs = np.array([t[3] for t in batch]) goals = np.array([t[4] for t in batch]) dones = np.array([t[5] for t in batch], dtype=np.float32) return obs, actions, rewards, next_obs, goals, dones

这段代码里最关键的设计是store_episode。我在实际项目里并不是一次性把episode里的所有transition都拆开存储，而是先收集整个episode，然后在episode层面做目标重标注，之后再把每个目标对应的整条轨迹拆成单独transition存进去。为什么先收集episode再重标注？因为HER是在完整轨迹层面操作的，你必须知道这局最后走到了哪里，才能决定虚拟目标是什么。如果实时逐transition地存储，就无法做future goal的重标注了。

另外，我选择只随机取k_future个未来状态作为额外目标，而不是取全部未来状态。论文里有一个future strategy，就是从之后的时间步里随机取一些状态作为目标。我刚开始用的时候也纠结过“多取点不是信息更丰富吗”，后来一跑发现，取全部会占用巨大内存，而且很多重复的状态（比如机械臂停在某个位置不动的时候，连续几步的next_obs几乎一样）会让目标分布失真。k_future=4是我的够用值，如果你想压榨性能，可以先从8试起，观察buffer的多样性和训练速度。

3.3 DDPG网络和训练主循环的完整适配

有了HER缓冲区之后，DDPG本身的改动其实很小。我这里给出一个关键点的解释，而不是贴全部千行代码。

首先是网络输入的变化。原始DDPG的Actor输入是state，输出是action。在面向目标的版本里，Actor输入必须加上goal，即actor(state, goal)。Critic输入是state、action、goal。我用的网络结构是：

class Actor(nn.Module): def __init__(self, state_dim, goal_dim, action_dim): super().__init__() self.fc1 = nn.Linear(state_dim + goal_dim, 256) self.fc2 = nn.Linear(256, 256) self.fc3 = nn.Linear(256, action_dim) def forward(self, state, goal): x = torch.cat([state, goal], dim=-1) x = F.relu(self.fc1(x)) x = F.relu(self.fc2(x)) return torch.tanh(self.fc3(x)) class Critic(nn.Module): def __init__(self, state_dim, goal_dim, action_dim): super().__init__() self.fc1 = nn.Linear(state_dim + goal_dim + action_dim, 256) self.fc2 = nn.Linear(256, 256) self.fc3 = nn.Linear(256, 1) def forward(self, state, action, goal): x = torch.cat([state, goal, action], dim=-1) x = F.relu(self.fc1(x)) x = F.relu(self.fc2(x)) return self.fc3(x)

这里有个容易踩的坑：如果把goal拼在state后面，要保证state和goal的维度比例不要差太大。FetchReach里state是10维（机械臂关节角、末端位置、物体位置），goal是3维（目标位置），拼接后13维，比值还算合理。如果state是100维，goal是3维，那goal信息很容易被淹没，建议在进入网络前对goal做特征增强或者单独过一层MLP再拼接。我当时在另一个高维状态任务上就遇到过这个问题，加了独立的goal encoder才解决。

训练主循环里，我每跑完一个episode就触发一次her_buffer.store_episode(episode)。注意，是按episode触发，不是按step触发。然后每步都从buffer里sample一个batch做一次梯度更新。这里有一个细节：HER特别吃buffer容量，因为重标注后的样本数量是原始样本的好几倍，buffer很快就满了。我把capacity设成了10万条transition，大约能存800个episode的样本。太小的buffer会丢旧经验，导致训练不稳定。

3.4 超参数配置和训练结果分析

我最终稳定使用的超参如下，这个配置在FetchReach-v1上大概16万步就能到90%以上的成功率，一张RTX 3060训练不到一小时：

关于gamma的选择，我多说一句。Fetch类任务每个episode只有50步，且奖励以-1和0为主。gamma取0.98和0.99的区别真的不大，因为50步之后就是terminated，远期奖励的折现影响很小。但在长horizon任务比如机械臂连续搬运，或者移动机器人导航这类几百步甚至上千步的任务里，gamma必须往0.99以上调，否则智能体很难学到长期规划。

训练的时候，我同时开了一个evaluate线程，每500步对当前策略做20次评测，记录成功率。我自己跑出来的成功率曲线大概是这样的：前2万步成功率几乎为0，loss曲线抖动；3万步到5万步之间开始有零星成功；8万步之后曲线陡增，一度跳到85%；12万步之后缓慢爬升到92%，之后基本持平。如果你看到自己的曲线在5万步之前完全不涨，不要慌，这是正常的。HER的威力往往在中后期才体现，因为一开始buffer里有效的重标注样本还不够多。

4. 常见问题与排查技巧实录

4.1 k_future设多大才算合适

k_future这个参数真的见过很多人乱调。我一开始把它设成1，发现学得很慢；后来设成10，训练是快了一点，但buffer的存储压力陡增，相同容量下只能存更少的episode，导致覆盖面反而变差。

从直观上讲，k_future决定了每个episode能产生多少条“带有目标多样性”的新轨迹。它和episode长度是正相关的。episode有50步，k_future=4意味着一个episode被扩成了5条轨迹，也就是原本5倍的样本。如果k_future太大，比如10，扩成11条轨迹，但很多轨迹之间因为目标相近，梯度信号高度冗余，收益会边际递减。

我的建议是：先照搬论文用的4，跑一个基准；如果样本利用率偏低、曲线长尾严重，再调到8；如果发现训练速度下降，优先减少k_future而不是增加buffer容量，因为大buffer会拖慢随机采样的速度。

4.2 重标注目标应该选观测状态还是任务目标

这里有个容易混淆的地方。FetchReach环境里，obs包含achieved_goal（实际到达的位置）和desired_goal（期望位置）。HER重标注时，新目标g'应该用achieved_goal，而不是obs里的机械臂关节状态之类的东西。

我在实现里用next_obs[t]作为未来状态，具体取的是环境返回的achieved_goal字段。有的环境封装会把achieved_goal单独拆出来，有的直接塞在observation里。务必搞清楚你的环境返回里哪些维度代表“实际完成度”。我用过一个自建环境，把物体坐标和关节角全拼一起，结果重标注的目标把关节角也算进去了，训练出来的策略疯狂乱动，最后排查半天发现是目标维度取错了。

一个稳妥的经验是：重标注目标只取实际任务相关的空间位置、姿态等信息，不要把跟任务完成度无关的维度塞进去。如果拿捏不准，直接打印几个样本的obs和achieved_goal，肉眼对比一下是最快的。

4.3 HER可以和SAC或TD3搭配使用吗

当然可以。我自己的项目里，把HER和DDPG搭配是最稳定的，因为DDPG的网络更新简单、超参敏感度低。但如果你想用SAC，需要额外注意熵系数alpha的调节。SAC本身倾向于探索，和HER的“重标注给更多成功样本”叠加后，容易导致策略过于激进，表现为前期探索过头、后期成功率震荡。我的做法是给alpha设一个小一点的初始值，比如0.05，并且开启自动调节后每1000步clip一下上限，防止熵权重过大。

TD3和HER的搭配我个人也很推荐。TD3比DDPG多了一个target policy smoothing和延迟更新，能显著减少Q值过高估计。在推开门、旋转阀门这类需要精准控制的任务里，TD3+HER的成功率比DDPG+HER高出10%以上。缺点是TD3的训练更慢，因为每次更新要做两次Critic前向。对于实验性质的快速验证，我还是先用DDPG，确认环境没问题再切换到TD3。

4.4 训练不稳定的几个典型症状和对策

排错这块，我整理了一个速查表，基本覆盖了我在实践中遇到的高频问题：

尤其要提醒的是，HER不是万能药。如果你的环境本身就是稠密奖励，比如每一步都有精确的距离反馈，那HER带来的收益非常有限，甚至可能因为重标注目标的引入，让策略学到一些“奇奇怪怪”的捷径。我自己就见过一个倒水任务，加了HER之后策略学会了先把杯子里的水洒掉一半，因为“未来状态”重标注降低了完成难度。这种时候，建议把HER的额外目标比例调低，或者只在特定阶段开启。

写在最后的几句唠叨

玩HER这段时间，我最大的感悟是：强化学习里很多看似神奇的效果，拆开看都只是一些朴素想法在工程上的极致放大。HER的内核就是“失败里也有可学的部分，只是你换了一双眼睛去看它”。不要把它当成一个需要复杂推导的算法，把它当成一种数据增强手段，你会更好理解它为什么能work。

最后再分享一个小技巧。如果你在调试自己的环境，可以先用一个纯随机策略跑几十个episode，然后用HER buffer去训练一个价值函数，看看Q值是否有区分度。如果连随机数据重标注后Q值都学不出任何规律，说明你的状态表征和目标定义之间可能有断档，这时候先别急着调算法，先回去检查observation和goal的空间是否对齐。我就是靠这个办法，避免了很多次“训练一晚上，第二天发现是环境bug”的惨剧。

这个项目后续我打算把HER扩展到多智能体协作的场景去，让两个机械臂互相作为“未来状态生成器”，理论上应该能缓解多智能体稀疏奖励的问题。如果你也在玩HER或者类似的样本回放策略，欢迎在评论区聊聊你踩过的坑。