企业官网建设流程全解析

1. 从"ddpg_main"这个命名说起：一个深度强化学习入口文件的设计哲学

第一次看到ddpg_main这个文件名的时候，我脑子里蹦出来的第一个念头是：这大概率是一个深度确定性策略梯度（Deep Deterministic Policy Gradient，DDPG）算法的训练入口脚本。为什么这么说？因为在强化学习的工程实践里，main这个后缀几乎已经成了一个约定俗成的信号——它代表整个项目的启动点，负责把环境、智能体、经验回放池、训练循环这几块拼图组装到一起，然后跑起来。

但问题也恰恰出在这里。很多人写ddpg_main的时候，只是把它当成一个"能跑就行"的脚本，参数硬编码、日志随手print、模型保存路径写死，结果就是：换一个环境要改十几处代码，调一次超参要翻半天文件，复现一次实验全靠记忆。我自己早期也踩过这个坑，一个main文件写到八百多行，最后连自己都不敢动。

所以这篇内容我想聊的，不是"DDPG是什么"这种教科书问题——网上讲DDPG原理的文章一抓一大把，从Actor-Critic架构到目标网络软更新，从确定性策略到OU噪声，该讲的都讲透了。我想聊的是：一个合格的ddpg_main入口文件到底应该长什么样，它需要承担哪些职责，哪些东西该放在这里，哪些东西坚决不能放。这是从"能跑"到"可维护、可复现、可扩展"之间那道最容易被忽视的坎。

这篇文章适合两类人看：一类是刚接触强化学习、准备自己动手写第一个DDPG训练脚本的朋友；另一类是已经能跑通DDPG、但被自己那坨main文件折磨得够呛、想重构又不知道从哪下手的朋友。我会尽量把每个设计决策背后的"为什么"讲清楚，而不是甩一段代码让你抄。

2. 拆解ddpg_main的核心职责：它到底该管几件事

2.1 入口文件的边界：管组装，不管实现

在动手写之前，先想清楚一个原则：ddpg_main是装配车间，不是零件加工厂。它的职责是把各个模块拼起来、把流程串起来，而不是去实现具体的算法逻辑。

具体来说，一个干净的ddpg_main通常只做这几件事：

• 解析命令行参数或配置文件，拿到超参数
• 初始化随机种子，保证可复现
• 创建环境（训练环境和评估环境通常分开）
• 实例化Actor网络、Critic网络、以及它们各自的目标网络
• 实例化DDPG智能体，把网络、优化器、噪声过程都塞进去
• 创建经验回放缓冲区
• 跑训练主循环：采样、存经验、采样batch、更新、软更新目标网络
• 定期评估、记录日志、保存模型
• 训练结束，保存最终模型和训练曲线

你看，这里面没有一行是"计算Q值"或者"计算策略梯度"的——那些都属于智能体内部的事。main只负责调用agent.select_action()、agent.update()这样的接口。这个边界一旦划清楚，代码的可读性会立刻上一个台阶。

我见过太多反例：有人在main里直接写critic_loss = F.mse_loss(...)，把损失计算、反向传播、梯度裁剪全塞在训练循环里。结果就是智能体类变成了一个空壳，所有逻辑都在main里，想换个算法得把main重写一遍。这就是典型的职责错位。

2.2 训练循环的骨架：五步走的标准节奏

DDPG的训练循环其实有一个非常固定的节奏，我把它总结成"五步走"：

1. 选动作：把当前状态喂给Actor，得到确定性动作，再加上探索噪声
2. 交互：把动作丢给环境，拿到奖励、下一个状态、done标志
3. 存经验：把(state, action, reward, next_state, done)这个五元组存进回放池
4. 更新：从回放池采样一个batch，更新Critic和Actor
5. 软更新：用θ_target ← τθ + (1-τ)θ_target的方式缓慢更新目标网络

这五步里，第1步和第4步是DDPG区别于其他算法的关键。第1步的噪声是DDPG能在连续动作空间探索的核心——因为它的策略是确定性的，不加噪声就永远不会尝试新动作。第5步的软更新则是DDPG训练稳定性的命脉，τ通常取0.001到0.005之间，太大目标网络抖得厉害，太小学习信号传不过去。

在main里，这个循环通常长这样（伪代码层面）：

for episode in range(max_episodes): state = env.reset() episode_reward = 0 for step in range(max_steps): action = agent.select_action(state, add_noise=True) next_state, reward, done, _ = env.step(action) agent.replay_buffer.push(state, action, reward, next_state, done) if len(agent.replay_buffer) > batch_size: agent.update() state = next_state episode_reward += reward if done: break # 评估、日志、保存

注意这里有个细节：if len(replay_buffer) > batch_size这个判断非常关键。回放池没攒够一个batch的时候去采样会报错，或者采样出重复样本导致过拟合。很多新手跑DDPG发现loss不降，排查半天，最后发现是回放池预热没做够。

2.3 那些容易被塞进main但其实不该塞的东西

有几个东西特别容易被顺手写进main，但我建议你克制一下：

第一，超参数。别在main里写lr=0.001这种魔法数字。要么用argparse从命令行传，要么用YAML配置文件读。我个人的习惯是配置文件为主、命令行为辅——配置文件管那些不常改的（网络结构、回放池大小），命令行管那些要扫参的（学习率、τ、噪声参数）。

第二，环境包装逻辑。比如状态归一化、奖励缩放、帧堆叠这些，应该封装成env wrapper，而不是在main里对state做一堆np.clip和除法。这样换环境的时候，wrapper可以复用。

第三，评估逻辑。评估和训练是两套流程：评估不加噪声、不更新网络、通常跑固定的几个episode取平均。把评估逻辑单独抽成一个函数，main里只调用evaluate(agent, eval_env, num_episodes=10)，清爽得多。

3. 超参数配置：DDPG调参的深水区

3.1 网络结构与学习率：Actor和Critic不该用同一个学习率

这是我在实际项目里踩过的一个大坑。刚开始写DDPG的时候，图省事，Actor和Critic共用一个优化器、一个学习率，结果训练要么不收敛，要么收敛到一个很差的局部最优。

后来才想明白：Actor和Critic的学习目标完全不同，学习率理应分开设。Critic是在拟合Q值，本质上是个回归问题，学习率可以稍大一点，常见的是1e-3；Actor是在做策略提升，它依赖Critic给出的梯度信号，学习率通常要小一个量级，1e-4是比较稳的起点。

网络结构上，DDPG原文用的是两层隐藏层、每层400和300个神经元。这个配置在MuJoCo系列任务上表现不错，但也不是金科玉律。我的经验是：

激活函数这块，隐藏层用ReLU是标配，但输出层要特别注意：Actor的输出层通常用tanh，把动作压到[-1, 1]，然后再乘以动作空间的缩放系数。Critic的输出层是线性的，因为它要输出Q值，不能有非线性压缩。这个细节如果搞错，训练直接崩。

3.2 噪声过程：OU噪声不是唯一选择

DDPG原文用的是Ornstein-Uhlenbeck（OU）噪声，这是一种均值回归的随机过程，适合惯性系统。但我在实践中发现，高斯噪声在很多任务上表现并不比OU差，而且实现简单得多。

OU噪声的公式是：

dx = θ(μ - x)dt + σdW

其中θ控制回归速度，μ是均值，σ是波动率。参数一多，调起来就麻烦。而高斯噪声就是简单的action + N(0, σ)，σ随时间衰减。

我的建议是：先从高斯噪声开始，如果发现探索不充分再换OU。判断探索是否充分，看训练早期的动作分布——如果动作几乎不变，说明噪声太小；如果动作乱跳导致奖励一直是负的，说明噪声太大。

噪声的衰减策略也很关键。常见做法是线性衰减：从σ=0.2衰减到σ=0.02，衰减周期占总训练步数的30%到50%。衰减太快，后期探索不足；衰减太慢，收敛慢。

3.3 回放池大小与batch size：内存和稳定性的权衡

回放池大小这个参数，很多人随手设个100000就不管了。但实际上它和任务复杂度强相关。

回放池太小（比如10000），样本多样性不够，网络容易过拟合到最近的几百步经验上，表现为奖励曲线剧烈震荡。回放池太大（比如1000000），内存占用高不说，早期存进去的"差经验"会长期污染采样分布，拖慢收敛。

我的经验值：回放池大小设为batch size的100到1000倍。如果batch size是128，回放池设100000左右比较合适。对于简单任务（比如倒立摆），50000就够；对于复杂任务（比如机械臂操作），可以上到1000000。

batch size本身，64到256是常见范围。太小梯度噪声大，太大更新次数少、样本效率低。我一般从128起步。

4. 训练循环里的那些坑：从能跑到跑好

4.1 回放池预热：为什么你的loss一开始不降

前面提过回放池预热，这里展开说。DDPG的更新依赖从回放池采样batch，如果池子里只有几条经验，采样出来的batch全是高度相关的样本，Critic学到的Q值会严重偏差，Actor跟着这个错误的Critic走，直接跑偏。

正确的做法是：在回放池里的样本数达到warmup_size之前，只采样存经验，不更新网络。warmup_size一般设成batch_size的5到10倍，比如1000到2000。

这个细节在论文里通常一笔带过，但在工程实现里是必须的。我见过有人跑DDPG，前100个episode奖励一直是-1000，以为算法有问题，其实就是预热没做，网络在垃圾数据上训练崩了。

4.2 目标网络的软更新：τ值的选择与实现细节

软更新的公式很简单：

for target_param, param in zip(target_net.parameters(), net.parameters()): target_param.data.copy_(tau * param.data + (1 - tau) * target_param.data)

但这里有个实现细节容易出错：软更新必须在每次网络更新之后执行，而不是每个episode执行一次。因为网络更新是每步都做的，目标网络也应该每步都跟着动。如果按episode更新，目标网络会滞后太多，训练不稳定。

τ值的选择，0.001是原文推荐值，0.005是很多实现里的默认值。我的经验是：任务越复杂，τ越小。简单任务0.005够用，复杂任务可以降到0.001甚至更低。判断标准是看Critic loss的曲线——如果loss震荡厉害，说明目标网络更新太快，调小τ；如果loss下降极慢，说明目标网络太"死"，调大τ。

4.3 梯度裁剪：一个被低估的稳定性技巧

DDPG的Critic loss偶尔会突然爆炸，尤其是在训练早期或者遇到极端奖励的时候。这时候梯度裁剪就是救命稻草。

torch.nn.utils.clip_grad_norm_(critic.parameters(), max_norm=1.0) torch.nn.utils.clip_grad_norm_(actor.parameters(), max_norm=1.0)

max_norm设1.0或0.5都行。这个操作几乎不增加计算开销，但能显著提升训练稳定性。我现在的习惯是：只要用DDPG，就默认加梯度裁剪，不管任务简单还是复杂。

还有一个相关的技巧是奖励缩放。如果环境的奖励范围是[-1000, 1000]这种量级，直接喂给网络会让Q值爆炸。做法是除以一个缩放系数，把奖励压到[-1, 1]或者[-10, 10]。这个系数不用太精确，量级对了就行。

5. 日志、评估与模型保存：让实验可复现

5.1 日志该记什么：不只是reward

很多人记日志只记一个episode reward，然后画条曲线就完事了。但当你发现训练不收敛的时候，光看reward曲线根本排查不出问题。

我建议至少记录这几项：

• episode reward：最直观的指标
• episode length：任务是否提前终止
• critic loss：Q值拟合得好不好
• actor loss：策略提升是否正常
• 平均Q值：判断Q值是否发散
• 噪声σ：确认噪声衰减是否按预期进行
• 动作的均值和标准差：判断策略是否在探索

这些指标用TensorBoard或者Weights & Biases记录，训练完一看就知道哪里出了问题。比如critic loss一直涨，说明Q值发散，可能是学习率太大或者τ太大；actor loss不降，说明Critic给的梯度信号没用，可能是Critic没学好。

5.2 评估策略：训练环境和评估环境要分开

这是一个容易被忽视但很重要的点：评估时要用一个独立的环境实例，并且不加噪声。

为什么？因为训练环境里可能有随机性（比如初始状态随机），如果评估复用训练环境，评估结果会受训练过程影响。而且评估时如果加噪声，测出来的性能会偏低，无法反映策略的真实水平。

评估的频率一般是每N个episode一次，N取10到50。评估跑5到10个episode取平均，减少方差。评估结果单独记录，和训练reward区分开。

5.3 模型保存：别只存最终模型

只保存最终模型是个坏习惯。因为DDPG训练过程中性能会波动，最终模型不一定是最好的。而且如果训练中途崩了，前面全白跑。

我的做法是：

• 定期保存：每100个episode存一次checkpoint，包含网络参数、优化器状态、当前episode数
• 保存最佳模型：评估reward创新高时，单独存一份best_model.pt
• 保存最终模型：训练结束存一份final_model.pt
• 保存配置文件：把这次训练用的超参数一起存下来，方便复现

checkpoint里一定要包含优化器状态，否则断点续训的时候优化器的动量信息丢了，训练会抖一下。

6. 从单文件到工程化：ddpg_main的演进方向

6.1 什么时候该把main拆开

当你的ddpg_main超过300行，或者你开始往里面加第二个算法的时候，就该考虑拆分了。

拆分的思路很简单：按职责分模块。典型的结构是：

project/ ├── main.py # 入口，只负责组装和启动 ├── configs/ │ └── ddpg_default.yaml ├── agents/ │ └── ddpg_agent.py # 智能体实现 ├── networks/ │ └── actor_critic.py # 网络定义 ├── buffers/ │ └── replay_buffer.py # 回放池 ├── utils/ │ ├── logger.py # 日志 │ └── noise.py # 噪声过程 └── envs/ └── wrappers.py # 环境包装

这样拆完之后，main.py通常只有100行左右，读起来一目了然。想换算法，加一个agents/sac_agent.py就行，main里改一行实例化代码。

6.2 配置管理：YAML比argparse更适合管超参

argparse适合管少量、常变的参数，但DDPG的超参数有几十个，全用命令行传会疯掉。YAML配置文件是更好的选择。

一个典型的DDPG配置长这样：

agent: actor_lr: 1e-4 critic_lr: 1e-3 gamma: 0.99 tau: 0.005 hidden_sizes: [400, 300] buffer: capacity: 100000 batch_size: 128 warmup_size: 1000 noise: type: gaussian sigma_start: 0.2 sigma_end: 0.02 decay_steps: 50000 training: max_episodes: 1000 max_steps: 500 eval_interval: 20 save_interval: 100

这样一份配置，配合argparse只传配置文件路径，既灵活又清晰。想扫参的时候，写个脚本生成多份YAML，批量跑就行。

6.3 随机种子：复现性的最后一道防线

强化学习的复现性是个老大难问题。同样的代码、同样的超参，跑两次结果可能差很多。原因通常是随机种子没固定。

需要固定的随机源包括：

• Python内置的random
• NumPy的np.random
• PyTorch的torch.manual_seed
• 环境的随机种子env.seed()
• CUDA的随机性（如果用了GPU）

def set_seed(seed): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) if torch.cuda.is_available(): torch.cuda.manual_seed_all(seed) env.seed(seed) env.action_space.seed(seed)

即便如此，GPU上的某些操作仍然是非确定性的。如果对复现性要求极高，可以设置torch.backends.cudnn.deterministic = True，但会牺牲一些速度。我的建议是：至少固定CPU侧的种子，GPU的非确定性在大多数场景下可以接受。

7. 一些实战中的零碎经验

聊了这么多结构性的东西，最后分享几个我在实际写ddpg_main过程中攒下的小经验，都是那种"文档里不会写、但踩过一次就忘不掉"的。

关于动作缩放。Actor输出的是tanh后的[-1, 1]，但环境的动作空间可能是[-2, 2]或者[0, 1]。这个缩放一定要做对，而且缩放系数要从env.action_space里动态读，别硬编码。我见过有人把[-1, 1]的动作直接喂给[-2, 2]的环境，结果策略永远探索不到边界，性能上不去。

关于done标志。存经验的时候，done标志要存对。如果是超时导致的done（达到max_steps），和真正终止（比如摔倒）的done，在计算Q值时处理方式不同。标准做法是：超时的done在计算目标Q值时不应该截断，只有真正终止才截断。这个细节如果搞错，Critic会学到错误的Q值。

关于训练步数。DDPG是样本效率比较低的算法，通常需要几十万到上百万步才能收敛。如果你的max_episodes设成100，大概率看不到收敛。建议至少设500到1000个episode，每个episode200到1000步。

关于硬件。DDPG的网络不大，CPU训练也能跑，但GPU能快好几倍。如果回放池很大（比如1000000），内存占用会比较高，采样的时候要注意别把整个池子搬到GPU上，只搬采样出来的batch就行。

关于调试。如果训练不收敛，按这个顺序排查：先看回放池预热够不够，再看噪声衰减是否正常，然后看Critic loss是否发散，最后看学习率和τ。这个顺序能解决80%的问题。

写ddpg_main这件事，说到底是一个从"能跑"到"跑得好"再到"可维护"的渐进过程。第一版能跑通就行，别追求完美；跑通之后，把超参数抽出来、把日志加上、把模型保存做好；等到要复现实验或者换算法的时候，再考虑模块化拆分。每一步都解决当下的痛点，比一上来就设计一个"完美架构"要务实得多。