简介：面向电力系统控制科研人员与工程师，以及具备编程基础、希望掌握深度强化学习落地应用的读者，这里提供一份基于论文《Adaptive Power System Emergency Control using Deep Reinforcement Learning》的代码复现与解析资料。内容针对传统离线控制在现代电网高不确定场景下适应性不足的问题，重点讲解DQN智能体设计、发电机动态制动与低压减载两类紧急控制实验，并结合RLGC平台说明DRL算法的开发与基准测试方法。整套资源仅含1个PDF文档，约767KB，涵盖环境建模、DQN模型构建、训练流程、奖励函数设计及鲁棒性测试等可运行代码与逐段解释。示例以PyTorch和Gym为基础，从自定义PowerSystemEnv环境到DQN网络搭建，再到ε-greedy动作选择和TD误差计算均有完整实现，方便读者边读边练。目前已有108人学习下载，适合用于理解DRL在电力系统紧急控制中的实际应用思路，也可作为相关课题的代码参考与入门资料。

1. 电力系统紧急控制为什么必须走向自适应：查表预案的盲区与深度强化学习的切入点

电网紧急控制的决策窗口极短，故障发生后留给控制器的时间往往只有几百毫秒到两三秒。传统做法是离线枚举预想故障集，生成“跳哪台、切多少、先切谁”的控制序位表，在线按故障索引查表执行。这套方案在网架固定、负荷形态稳定的条件下够用，可新能源占比上来之后，运行方式每天大幅偏移，离线预想集覆盖不全，查表对没见过的组合就等于没有预案。深度强化学习解决的是这个适应性问题：控制策略从一张表变成一个与仿真环境持续交互的决策网络，输入电压、相角、频率状态，输出切负荷动作，能根据当前工况现场决策。下面按环境建模、PPO 训练、验证落地的顺序展开，代码可复现，坑也会挨个讲。

2. 把自适应紧急控制写成强化学习问题：状态空间、动作空间与仿真环境搭建

做紧急控制强化学习，第一步不是改算法，而是把电力系统控制场景翻译成智能体与环境的交互框架。紧急控制和稳态调频不同，它发生在故障清除后的暂态过程里，特征是时间短、状态变化剧烈、一次动作定生死。所以状态、动作、奖励这三者的建模质量，直接决定后续训练上限。这里我用 IEEE 39 节点系统作为说明对象，它包含 10 台发电机、39 条母线和多处负荷，规模适中，既能体现暂态控制的复杂度，又不至于让训练慢到没法调试；换成 14 节点或 118 节点时思路完全一样，只是维度与动作数量变化。

2.1 状态空间设计：母线上哪些电气量值得进入观测向量

不少项目一上来就把所有母线电压幅值塞进观测，能用，但不够。紧急控制的核心是判断系统处于稳定边界附近哪个区域最危险，因此观测向量至少要覆盖四类信息：母线电压幅值、相对相角差、频率偏差，以及当前故障标识。电压幅值是最直接的“健康度”指标，相角差对应发电机间同步能力，频率偏差刻画功率不平衡程度。漏掉任意一类，策略就容易在对应故障场景里变成盲人摸象。

我一般会坚持“相对测量”原则：相角不用绝对弧度，而是相对参考母线做差分，否则同一物理场景因为参考角度偏移会让观测向量大幅变化，策略网络会被这类伪差异带偏。电压幅值要转成标幺值再进网络，并做轻微中心化，把稳态 1.0 附近的量映射到 0 附近，神经网络初始梯度会更稳。故障标识建议用 one-hot 向量而不是直接丢编号，防止模型学到编号大小这种假关系。

一个 39 节点系统典型观测向量如下表所示：

这 121 维左右的数据就是每次决策时交给策略网络的输入。还需要留意一点：机电暂态仿真本身是确定性的，但真实系统运行方式在变，如果把负荷水平、新能源出力比例这些运行参数拼进观测向量，模型的自适应才有依据。我建议在 reset 时把生成场景的参数一并放进观测，或者至少存进 info，方便测试阶段区分分布内和分布外场景。

2.2 动作空间与奖励函数：切负荷不是切得越少越好

动作空间有离散和连续两种主流写法。离散写法是枚举预想切负荷组合，比如“切母线 4 负荷 20%”作为一个动作编号，优点是实现简单，缺点是组合数爆炸，对没见过的故障严重程度适应很差。连续写法是把动作定义为每条可控母线的切负荷比例，取值 0 到 1，由策略网络连续输出，这正好对齐“自适应”目标：同样故障，轻载时可以少切，重载时必须多切。下面代码用连续动作空间。

奖励函数是最容易在方向上翻车的地方。早期我吃过亏：把奖励直接设成负切负荷量，希望模型用最小代价换稳定，结果训练出来的策略几乎不动——因为不动就不切，每步奖励都是 0，学成一个彻底躺平策略。正确逻辑是稳定为硬门槛，代价为第二目标。失稳惩罚必须远超任何切负荷代价，否则模型会拿稳定性去换省切量。

我常用的奖励形式：

reward = 稳定加分(+1.0) - w_shed * 平均切负荷比例 - w_change * 动作变化惩罚 若失稳，reward = -10.0

w_shed 一般取 1.0 到 2.0，w_change 取 0.5 到 1.0。动作变化惩罚是防止模型在两个决策步之间反复切、切了又合，这在连续输出动作里非常常见，不加惩罚训练出来的控制器落到实际设备上根本无法投运。另一个经验是把稳定判定做成连续量而不是 0/1：用电压或功角偏差的函数表达“稳定程度”，离稳定边界远给正奖励，靠近边界给小的负奖励，梯度信号更密，模型不用等仿真跑完才知道好坏。

2.3 用 gymnasium 封装 IEEE 39 节点紧急控制环境：最小可用代码

环境层是紧急控制强化学习代码里最值得认真写的部分，它决定你能否在算法间做横向对比、能否无缝替换底层仿真器。我用 gymnasium 接口封装，因为 PPO 等算法库都基于它实现；后续要接 Stable-Baselines3 也可以无痛迁移。看一个结构完整的最小版本：

import numpy as np import gymnasium as gym from gymnasium import spaces class EmergencyControlEnv(gym.Env): """把电力系统暂态仿真器封装成 gymnasium 环境。 工程里我会把 _step_sim 和 _snapshot_obs 替换成真实仿真程序 （Pandapower/PSASP/BPA）的调用，这里用占位逻辑先把接口定清楚。 """ def __init__(self, load_bus_ids=None, obs_dim=121, max_shed=0.3): super().__init__() if load_bus_ids is None: load_bus_ids = [4, 7, 8, 12, 15, 16, 18, 20] self.load_bus_ids = load_bus_ids self.max_shed = max_shed self.action_space = spaces.Box( low=0.0, high=1.0, shape=(len(load_bus_ids),), dtype=np.float32 ) self.observation_space = spaces.Box( low=-np.inf, high=np.inf, shape=(obs_dim,), dtype=np.float32 ) self._obs = None self._step_count = 0 def reset(self, *, seed=None, options=None): # 真实工程：在这里随机生成故障位置、负荷水平、新能源出力 self._step_count = 0 self._obs = np.zeros(self.observation_space.shape[0], dtype=np.float32) return self._obs, {} def step(self, action): # 动作映射：限制切负荷比例上限 shed = np.clip(action, 0.0, self.max_shed).astype(np.float32) # 执行仿真的一小段时间步，unstable 来自暂态稳定判断 unstable, next_obs = self._step_sim(shed) self._step_count += 1 done = bool(unstable) or self._step_count >= 200 reward = self._cal_reward(unstable, shed) return next_obs, reward, done, {"unstable": unstable} def _step_sim(self, shed): # 占位实现，替换为暂态仿真步进（典型步长 0.01s） unstable = np.random.rand() < 0.3 next_obs = self._obs.copy() return unstable, next_obs def _cal_reward(self, unstable, shed): if unstable: return -10.0 return 1.0 - 1.5 * float(np.mean(shed))

这段代码的要点有三个。动作空间定义为 8 条可控母线的连续切负荷比例，reward 按“先保稳定、再压代价”的顺序拆开，失稳给 -10 而不是默认的 0，目的是明确告诉策略某些动作会带来致命后果。替换真实仿真器时只需改 reset 和 _step_sim：reset 里初始化潮流与故障场景，_step_sim 里做同步电机、励磁、调压器等模型的时域积分，返回 unstable 和观测向量。

不少团队在这里先接好算法库再去补环境，结果时间尺度、动作映射做错，训练很久之后才发现策略学的是假环境里的本事。我的习惯是一开始就把环境层固定，先写一条硬编码基准策略跑通整条链路，再动网络结构，这个习惯后面帮我省掉了大量无效调参时间。

3. 用 PPO 训练紧急控制策略：主循环、关键超参与收敛判定

选 PPO 而不是 DQN 或 DDPG，主要基于三点：动作空间连续、奖励分布窄、仿真成本高。PPO 通过对同一批数据做多次 epoch 更新，样本利用率比 DDPG 更容易控制；DQN 处理离散动作尚可，但对连续切负荷比例只能靠动作离散化近似，精度损失明显。既然目标是自适应连续控制，PPO 一步到位。

3.1 PPO 训练主循环代码：从随机策略到有效决策

训练主循环是 On-Policy 思路：策略逐步探索、收集一批数据、做一次更新。先看策略网络和 ActorCritic 结构：

import torch import torch.nn as nn class PolicyNet(nn.Module): def __init__(self, obs_dim, action_dim, hidden=256): super().__init__() self.encoder = nn.Sequential( nn.Linear(obs_dim, hidden), nn.Tanh(), nn.Linear(hidden, hidden), nn.Tanh(), ) self.mu_head = nn.Linear(hidden, action_dim) def forward(self, obs): x = self.encoder(obs) mu = torch.sigmoid(self.mu_head(x)) # 输出映射到 (0,1) 区间 return mu class ActorCritic(nn.Module): def __init__(self, obs_dim, action_dim, hidden=256): super().__init__() self.policy = PolicyNet(obs_dim, action_dim, hidden) self.value_head = nn.Linear(hidden, 1) def forward(self, obs): x = self.policy.encoder(obs) mu = torch.sigmoid(self.policy.mu_head(x)) value = self.value_head(x) return mu, value

隐层用 Tanh 激活而不是 ReLU，因为紧急控制状态量有正有负，Tanh 输出中心化更稳。输出层用 Sigmoid 把动作夹到 0 到 1，正好对应切负荷比例；如果动作需要上下限之外的偏置，可以后续线性映射，但不要让网络裸输出 unclamped 值。价值头用来算优势函数，如果去掉价值头，PPO 会退化成更暴躁的策略梯度，紧急控制这种稀疏奖励场景很难稳定。

接下来是 PPO 更新函数：

def ppo_update(agent, optimizer, batch, clip_eps=0.2, entropy_coef=0.01): obs = torch.tensor(np.array(batch["obs"]), dtype=torch.float32) act = torch.tensor(np.array(batch["action"]), dtype=torch.float32) old_logp = torch.tensor(np.array(batch["logp"]), dtype=torch.float32) adv = torch.tensor(np.array(batch["adv"]), dtype=torch.float32) ret = torch.tensor(np.array(batch["return"]), dtype=torch.float32) # 优势归一化，避免某些场景的奖励量级主导梯度 adv = (adv - adv.mean()) / (adv.std() + 1e-8) for _ in range(5): # 每批数据复用 5 个 epoch mu, value = agent(obs) dist = torch.distributions.Normal(mu, 0.1) logp = dist.log_prob(act).sum(dim=-1) ratio = torch.exp(logp - old_logp) surr1 = ratio * adv surr2 = torch.clamp(ratio, 1 - clip_eps, 1 + clip_eps) * adv policy_loss = -torch.min(surr1, surr2).mean() value_loss = nn.functional.mse_loss(value.squeeze(), ret) entropy = dist.entropy().mean() loss = policy_loss + 0.8 * value_loss - entropy_coef * entropy optimizer.zero_grad() loss.backward() nn.utils.clip_grad_norm_(agent.parameters(), 0.5) optimizer.step()

这里的优势 adv 用 GAE 计算，代码里用 G 的递推近似也能跑，但正式训练时我会用 GAE(lambda) 配合 value_head 估计，能显著减少紧急控制轨迹末尾稀疏奖励带来的方差。clip 机制限制单次更新步长，防止一批异常的高奖励数据把策略甩飞；梯度裁剪 0.5 是 PPO 训练长尾奖励场景常备的保险丝。熵系数维持探索，太小会导致策略过早收敛到某个固定动作，太大则策略永远在随机游走。

3.2 五个必调参数：学习率、clip epsilon、GAE lambda、熵系数、batch size

紧急控制训练里，参数耐受力很强但方向敏感。下面这五个参数是我每次动手前先定下来的起始值：

Batch size 这栏容易理解偏差。紧急控制一次 episode 通常只有几十到几百步，一条轨迹就是一个完整故障场景；如果 batch_size 太小，一次更新里混合的故障场景太少，策略容易被当前场景带偏。我一般把 batch 设成“至少覆盖 10 到 20 个完整故障场景”，而不是按随机采样的数量拍脑袋。

3.3 训练不收敛的三类根因：奖励稀疏、动作抖动、仿真步长不匹配

训练曲线不收敛，先别怀疑 PPO 实现，绝大多数问题出在环境侧。第一类根因是奖励稀疏：随机策略探索阶段大概率直接失稳，失稳惩罚为 -10，成功奖励为 +1，平均值很长一段时间贴近负值，价值网络学不到梯度。解决办法是先加一条“最小切负荷保底”规则，比如任何失稳之前至少切 10%，让探索初期能撞出几个稳定样本；或者把稳定判断从仿真终点改成窗口内电压偏差积分，奖励密度立刻上来。

第二类根因是动作抖动。PPO 从高斯分布中采样动作，相邻决策步之间输出可能在 0.1 和 0.7 之间乱跳，这在连续动作空间非常常见。训练时仿真器直接把负荷替换成动作值，不会惩罚高频投切，于是策略学到的是物理上无法执行的抖动策略。解法前面讲过：奖励里加动作变化惩罚项，并在一阶惯性环节输出到仿真器。

第三类根因是仿真步长与决策步长不匹配。有些项目把决策周期设成和机电暂态积分步长一样（比如 0.01s），导致 2 秒窗口里有 200 个决策点，奖励信号被切得极碎，策略根本不知道哪一步该负责。我一般把决策周期设成 0.5 到 1 秒，也就是故障后 2 秒窗口里只做 3 到 5 次决策；如果担心响应不及时，可以在特定事件（如电压跌破门限）触发额外决策。决策周期越少，每个动作的因果链路越清晰，训练收敛越快。

4. 自适应紧急控制避坑指南：训练翻车、评估冒进、部署滞后

4.1 训练 loss 不降反升，但平均奖励在爬升，到底看哪个指标

现象：每次 ppo_update 打印的 policy_loss 波动很大，有时一次更新后就翻倍，很容易让人以为训练崩了。停止训练查看 checkpoint，发现失稳率其实在下降。

原因：PPO 的 loss 数值本身没有归一化单位，它受优势归一化和 clip 影响，数值大小和收敛方向没有直接对应；紧急控制场景一次 batch 里可能只有少数几个成功轨迹，权重更新后 loss 出现较大波动完全正常。

解决：不要用 loss 判断收敛。每 10 个 epoch 记录三个指标：平均奖励、失稳率、平均切负荷比例。失稳率下降且平均奖励上升才是真收敛；并把每 50 个 epoch 的模型保存一次，在固定测试集上跑一遍，挑测试集表现最好的 checkpoint，而不是最后一个。

4.2 训练时故障位置固定，验证时 N-1 全挂

现象：训练曲线很漂亮，收敛后的模型在训练故障集里稳定率接近 100%。换一条没见过的线路做 N-1 故障，策略立刻失效，稳定率降到 40% 以下。

原因：reset 里故障集合被写死成一条线路或少数场景，模型学到的是识别某类断面特征，然后输出记忆好的动作。这不是自适应控制，是模式匹配。

解决：把故障位置、故障类型、清除时间、负荷水平全部作为 reset 时的随机变量。训练集用一部分故障组合，测试集留出完全没有见过的组合，这样评估结果才配叫“自适应”。我习惯在环境里加一个 scenario_id 参数，测试时按 ID 区分训练分布内与分布外，比随机抽样更有可控性。

4.3 仿真里动作很理想，一到实时控制就慢半拍

现象：策略网络单次推理 30 到 60ms，在仿真里不影响；部署时控制周期只有 100ms，一次推理加通信就把周期吃满，真实系统里动作晚执行一个周期。

原因：Python 推理、CPU 运行、模型宽度偏大，多层 MLP 叠加起来时延不可控。紧急控制典型决策时间窗是 0.5 到 2 秒，但动作落到断路器或切负荷装置要走通信链路和远方执行时间，留给算法的时间远小于直觉。

解决：先把模型压缩到两隐层 256 或 128，一般足够；然后用 ONNX Runtime 导出再做量化，能把单次推理压到 5ms 以内；最后加“保持上次动作”机制：网络只在事件触发或每 N 个周期重算，其余时间沿用上一拍输出。这个兜底逻辑在工程验收时非常加分。

4.4 切负荷动作来回抖：同一母线反复投切

现象：连续决策点上的动作序列是 0.3、0.05、0.4、0.1，同一母线的切负荷量来回大幅跳动。训练时仿真按动作替换负荷值，看不出问题；但实际切负荷装置有机械寿命，而且一次切除通常不可逆。

原因：PPO 从高斯分布采样动作，相邻步之间没有时间一致性约束；奖励函数没惩罚动作变化量，等于告诉模型抖动不需要付出代价。

解决：第一，奖励里加动作变化惩罚项，-w_change * |action_t - action_prev|，我一般取 w_change=0.5；第二，部署层对输出做一阶平滑，action_final = 0.5 * action_new + 0.5 * action_prev。两个措施同时进，测试时才能看到动作序列变得可接受。

4.5 DRL 比规则表切得多，但代价指标排名反过来

现象：对比测试里 DRL 切了 25% 负荷，传统规则表切 20%，两边都稳住了。于是项目论证时被质疑：深度强化学习控制优势到底在哪。

原因：奖励函数里稳定加成和切负荷代价的量级关系摆得不对。失稳惩罚 -10，稳定加 +1，但平均切负荷惩罚是 -1.5 乘 0.25 等于 -0.375，模型觉得保守多切一点无妨，自然选择安全优先。传统规则表是离线优化算出来的 20%，当然更省。

解决：把失稳惩罚提到 -20 或更高，并强调一条规则：失稳整条轨迹给 -50 并立即终止，稳定后再去最小化切负荷代价；同时把规则表策略跑进同一套评估指标作为基线，分开报告稳定率和平均切负荷量，不要算成一个综合分。DRL 的价值在极端场景的泛化能力，不在标准场景里的那 5% 经济性。

5. 验证与落地：对比规则基线的测试矩阵与批量评估脚本

算法训练完只是起点，验证才是决定要不要投运的关键环节。紧急控制项目被拍死，很少因为训练代码有 bug，多数因为验证矩阵不完整：拿训练过的场景自卖自夸，或者只报平均切负荷量，没有区分场景难度。下面这套测试矩阵我每次都会用。

5.1 测试矩阵设计：负荷、故障位置、故障类型、新能源出力

表格里各维度不是均匀抽样，而是有意让分布偏离训练分布，才能看出“自适应”的真实成色：

负荷水平从 60% 到 120% 拉满，是因为轻载和重载下同样的切负荷动作效果完全不同；故障位置换成训练集没见过的线路，是测试模型是否依赖“背诵”；故障清除时间越长，系统积累的暂态能量越大，对控制器要求越高；新能源出力改变系统惯量水平，策略必须及时调整。动作执行延迟则模拟通信链路，这一维度最容易暴露训练环境过度理想化的问题。

5.2 批量评估脚本：加载模型、跑 N 个场景、统计指标

我一般把评估脚本单独写，不和训练脚本混在一起。评估时固定随机种子，让每个 scenario_id 在规则基线和 DRL 策略下跑同一组初值，避免“这次恰好运气好”的误判。核心代码如下：

import torch import numpy as np def batch_evaluate(env, agent, num_episodes=50, randomize=True): """批量评估 DRL 紧急控制策略。 返回失稳率和稳定样本上的平均切负荷比例。 """ agent.eval() unstable_total = 0 shed_records = [] for _ in range(num_episodes): if randomize: obs, _ = env.reset(options={"scenario_id": np.random.randint(0, 1000)}) else: obs, _ = env.reset() done = False last_shed = None episode_unstable = False while not done: obs_t = torch.tensor(obs, dtype=torch.float32).unsqueeze(0) with torch.no_grad(): mu, _ = agent(obs_t) action = mu.detach().cpu().numpy().squeeze() last_shed = np.clip(action, 0.0, 1.0) obs, reward, done, info = env.step(action) if info["unstable"]: episode_unstable = True if episode_unstable: unstable_total += 1 elif last_shed is not None: shed_records.append(np.mean(last_shed)) return { "unstable_rate": unstable_total / num_episodes, "avg_shed_stable": float(np.mean(shed_records)) if shed_records else 0.0, }

这个脚本要注意三个细节。评估过程用 env.step 推进整个故障窗口，记录的是最后一次动作的最终切负荷比例，因为一次紧急控制只有故障后最初几次决策有用，末尾动作对结果没有实际意义。失稳样本不计入平均切负荷，因为失稳本身就是严重失败，把大量失败样本混进平均切负荷会把指标算虚低。info["unstable"] 是环境仿真器给出的硬判定，不能用奖励值来代替，否则你的评估结论和训练奖励设计耦得太紧。

5.3 结果怎么读：只看平均切负荷率会坑死你

评估输出出一张表之后，最容易犯的错误是只读平均指标。平均切负荷率会被轻载场景拉得很低，1% 的平均值听起来很漂亮，但极端重载场景里可能切了 40% 还失稳。正确做法是分桶统计：轻载、额定、重载各一桶，N-1 线路按传输功率大小再分桶；每桶里算稳定率，稳定样本里再算切负荷量。稳定率永远是第一指标，切负荷量只在稳定率相同的组之间比较。

我还会在评估报告里加一列“最坏场景稳定率”，也就是全部测试场景里最差的 5% 场景的稳定率。这个指标比平均值更能说明策略在极端工况下的兜底能力；如果最坏场景稳定率低于 90%，我会直接把模型退回训练端，而不是通过调测试集尺寸把它洗回来。

6. 一个收敛快、落地稳的技巧组合：积分奖励窗口与延迟动作校验

训练收敛和落地评估之间，有两个技巧我认为价值最高：积分奖励窗口和延迟动作校验。

积分奖励窗口解决的是“终点判断失真”问题。很多临时稳定判断只看故障后 2 秒那个瞬间是否失稳，但有些轨迹在终点看起来稳定，3 秒后电压开始缓慢滑坡，最终仍然崩溃。如果把奖励直接绑在终点失稳标志上，模型会学到“卡着终点线不崩”的钻空子策略。我的做法是把稳定度定义为一个积分量，比如故障后 1 到 3 秒窗口内所有母线电压与额定值偏差的累计积分，偏差越小奖励越高；这样模型必须让整个暂态过程都处于可接受的范围内，而不是只修终点。积分窗口加进奖励函数之后，训练初期的失稳率不一定下降更快，但最终学出来的策略在延长仿真时间后仍然稳定，这是真实项目验收时最在意的点。

延迟动作校验是针对部署场景的一味后悔药。训练时假设动作立即执行，但真实链路从决策到执行要经历通信、装置出口、触点闭合，存在几十到上百毫秒延迟。我在评估环境里加一个 delay_steps 参数，让动作在 1 到 2 个决策周期后才真正生效；如果策略在这种延迟下保持稳定率不下滑，说明控制决策依赖的是实时状态而不是侥幸的时序窗口。不少模型就卡在这关，训练时很猛，加 100ms 延迟后立刻失灵，原因就是策略过度依赖故障后第 1 步就切到位。

最后说一个伴随我很久的习惯：每次训练开始前，我都会先写一条硬编码基准策略——比如无论什么故障都切 20% 最重负荷母线——用同一套评估脚本跑一遍，把它的稳定率和切负荷量存起来。这样训练过程中任意一次曲线异常，我都能立刻回答“这个 checkpoint 比基准好还是差”。深度学习调参有时候很玄学，没有这个基线对照，很难判断当前模型是进步了还是过拟合了。我的经验是：如果训了五六个小时还打不过基准策略，先别怀疑算法库，回头检查环境里的动作映射和奖励量级，八成问题在那里。希望帮到你。

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