做能源系统优化调度这件事,真正难的从来不是把算法刷到某个测试集上跑得好看,而是你给出的每一组动作,在线下仿真里漂亮,一到真实场景就被各种“硬约束”锤得抬不起头。这是我折腾过好几个微电网调度项目后的真实感受:当 SOC 越限、联络线功率越界、备用容量不够这些条件同时压上来,普通深度强化学习策略往往会给出一个理论上收益很高、实际上完全不可行的动作。这也是为什么“约束感知强化学习”这几年在能源调度里热度一直往上走,它本质上是在让智能体学会一个关键技能:在满足物理边界的前提下追求最优经济性,而不是只看累积奖励。
这篇文章,我会用我实际落地的一套 Python 实现作为主线,拆解如何在微电网/光储充场景里做“约束感知”的强化学习调度。算法层面会以 SAC-Lagrange 为核心,把约束条件转化成自适应 Lagrange 乘子,同时会附上足够直接的环境建模、神经网络结构、训练循环代码,并把我在训练和部署中踩过的坑一并写出来。适合正在做能源管理、虚拟电厂、储能调度,或者想把安全强化学习用到工业控制里的同学参考。不管你有没有深度强化学习基础,只要能看懂 Python 和基本的神经网络训练逻辑,照着这套思路改一改,大概率能在一周内跑通自己的第一版。
1. 先想明白:能源调度的约束到底卡在哪
1.1 从微电网场景看三类硬约束
我把场景设定成一个典型的并网型微电网:光伏发电、电池储能、本地负荷,再加上和外部电网的交换功率。调度的目标是每小时给电池下发一个充放电功率指令,让整个系统在一个调度周期内的综合运行成本尽量低。
这个问题的“硬约束”可以分成三类,每一类你都不能绕过。
第一类是等式约束,核心是功率平衡。任意时刻,系统必须满足:本地负荷等于光伏出力、电池出力与电网交换功率之和。这个等式不是可选项,是物理法则。如果智能体给出的动作让功率不平衡,最后的结果要么是甩负荷,要么是设备过载保护动作。
第二类是不等式约束,主要来自设备物理边界。电池的 SOC 必须落在 0.1 到 0.9 之间,不能过充过放;电池充放电功率有上下限;电网联络线有双向功率上限;如果场景里有柴发,还要考虑爬坡速率限制。这类约束的特点是,你可以在短时间内“压线”运行,但如果长期越界,电池寿命会明显衰减,保护系统也会主动跳闸。
第三类是运行经济性隐含约束,比如备用容量、需求响应响应速度、电压偏差。这些约束不一定写在基础优化模型的等式里,但在真实系统里同样会触发惩罚。我在做项目时,最容易被忽略的就是备用容量要求——某些时段储能必须预留一部分容量用来应对负荷突变,如果 RL 策略把电池充得太满,虽然经济指标漂亮,但调度员根本不敢投用。
1.2 普通强化学习为什么容易“钻空子”
我之前也试过把调度问题直接丢进标准 SAC 或者 PPO,只用加惩罚项的方式处理约束,效果很差。根本原因在于:普通强化学习的目标函数是最大化折扣累积奖励,它对约束的感受是间接的。
假设你把成本函数映射成奖励,再用一个固定系数乘上约束违反量作为惩罚,问题就来了。系数调得小,智能体发现“轻微越界换来的经济收益”比“坚持不越界”更划算,于是它会把 SOC 长期顶在 0.95 以上运行。系数调得大,训练初期奖励信号被惩罚项淹没,策略网络几乎收敛不到一个有用区域,甚至会出现“原地不动”的保守策略,连正常的削峰填谷都不敢做。
更隐蔽的坑是:固定惩罚会让约束违反量变成奖励优化的一部分,但缺乏对 “约束是否真的不可行” 的度量。有些时段,因为负荷和光伏曲线形状特殊,任何动作都无法同时满足所有约束;这时候智能体会被固定惩罚逼着去做一些奇怪的补偿动作,而不是让优化器自己去寻找一个可行域内的次优解。这就是我转向约束感知强化学习的直接原因。
2. 方案选型:约束感知强化学习的整体设计
2.1 怎么把调度问题翻译成决策序列
先把调度问题形式化,方便后面代码统一。这里我用离散时间步长 1 小时,调度周期 24 小时。
状态空间 S 需要包含当前环境信息和电池状态。我常用:
- 当前时刻 t(归一化到 [0,1])
- 本时段光伏预测出力 P_pv(归一化)
- 本时段负荷预测 P_load(归一化)
- 当前电池 SOC(0 到 1)
- 实时电价 price(如果采用分时电价机制)
动作空间 A 在这里定义为一维连续变量 a ∈ [-1,1],表示电池功率指令的相对幅值。a > 0 表示放电,a < 0 表示充电。实际电池功率 P_bat = a × P_bat_max。这样定义的好处是网络输出可以直接过 tanh 层,天然落在 [-1,1] 区间内,不需要额外裁剪。
奖励函数 R 我定义为负运行成本:负的电费支出,减去电池老化惩罚。注意这里先不把硬约束塞进奖励,约束交给 Lagrange 乘子去处理。
约束部分,我用一个向量 C 来表示每个时刻的违反量:
- SOC 下限违反:max(0, SOC_min - SOC)
- SOC 上限违反:max(0, SOC - SOC_max)
- 联络线功率上限违反:max(0, |P_grid| - P_grid_max)
- 电池功率上限违反:max(0, |P_bat| - P_bat_max)
这个违反向量会拆成两个用途:一个进入奖励作为惩罚项,一个记录到经验池里给 Lagrange 乘子更新用。后面会详细说乘子更新的数学逻辑。
2.2 四种常用约束处理机制对比
我在调研和实际测试里,把约束感知 RL 的主流做法整理成一张对比表。
| 方法 | 核心思路 | 优点 | 缺点 |
|---|---|---|---|
| 固定罚函数 | 奖励里加固定系数乘以违反量 | 实现最简单 | 系数难调,约束不可控 |
| 动作投影/修复 | 网络输出动作后映射到可行域 | 保证单步可行性 | 可能改变动作的真实语义,需要额外修复层 |
| 安全层(如 CBF) | 用控制屏障函数实时修正动作 | 强安全保证,适合硬件 | 需要较多系统模型知识,约束复杂时难建 |
| 拉格朗日乘子法 | 把约束放到目标函数里,同时优化策略和乘子 | 自适应惩罚,约束边界可控 | 需要调乘子学习率,训练波动大 |
我的选择是“拉格朗日乘子法 + 最小化动作修复方案”。拉格朗日方法负责长期约束满足,动作修复负责处理单步物理越界,比如 SOC 在极端情况下的瞬时越界。这样既保留了 RL 的决策自由度,又不会让探索动作变成一堆废数据。
2.3 我为什么选 SAC-Lagrange 而不是 PPO
PPO 在不少资源调度问题里也有不错表现,但我最终选 SAC-Lagrange,三个原因。
第一,SAC 是 off-policy 算法,数据利用效率高。能源调度环境往往需要让智能体跑完完整 24 小时才能看到一个完整 episode。如果使用 on-policy 的 PPO,每次策略更新后都要重新采集一批数据,训练 200 万步的成本会被拉得非常高。而 SAC 配上一个足够大的经验回放池,可以反复利用历史轨迹,跑实验的速度差距能达到 3 到 5 倍。
第二,SAC 自带最大熵机制。熵正则项让策略在训练初期保持更强的探索性,这对高维约束空间特别重要。因为一旦约束惩罚让奖励面变得很尖,普通确定性策略容易收敛到局部极小值,而最大熵策略会自动保持一定随机性,不会过早陷入某个“看起来还行但实际很差”的决策区。
第三,SAC-Lagrange 在数学上特别自然:把原本带约束的 maximize return,改写成 maximize return minus lambda times constraint violation,然后对 lambda 做梯度上升。Lambd 会像一把尺子一样自动测量“当前约束有多紧张”。约束长期被满足,lambda 就下降;约束老被打破,lambda 就上升,直到策略被逼回可行域。它不需要人工反复调惩罚系数,非常适合我这种懒人。
3. 核心实现:从 Env 到 Lagrange 乘子更新的代码拆解
3.1 环境类与约束判定
我习惯用自定义环境类,而不是直接套用现成的开源环境。因为能源调度场景里的时间连续性、SOC 递推方程和约束度量,必须跟工程上完全对齐。下面这个类只是把核心逻辑抽出来,实际工程里你还需要加数据读取、预测值更新、并网状态切换等内容。
import numpy as np class MicroGridEnv: def __init__(self, horizon=24, pv_profile=None, load_profile=None, price_profile=None): self.horizon = horizon self.pv_profile = pv_profile self.load_profile = load_profile self.price_profile = price_profile # 物理参数 self.p_bat_max = 0.5 # MW self.battery_capacity = 2.0 # MWh self.soc_min = 0.1 self.soc_max = 0.9 self.p_grid_max = 0.8 # MW self.reset() def reset(self): self.t = 0 self.soc = 0.5 return self._get_obs() def step(self, action): # action: 一维连续变量,范围 [-1, 1] 由网络 tanh 输出保证 p_bat = action * self.p_bat_max # 基础功率平衡 p_load = self.load_profile[self.t] p_pv = self.pv_profile[self.t] p_grid = p_load - p_pv - p_bat # 约束违反量 violation = 0.0 violation += max(0, p_grid - self.p_grid_max) + max(0, -p_grid - self.p_grid_max) violation += max(0, self.soc - self.soc_max) + max(0, self.soc_min - self.soc) # SOC 递推 self.soc += -p_bat / self.battery_capacity * 1.0 # 1小时步长 self.soc = np.clip(self.soc, self.soc_min, self.soc_max) cost = self.price_profile[self.t] * p_grid penalty = 10.0 * violation # 这个系数不是固定约束权重,只是偏置项 reward = -cost - penalty self.t += 1 done = self.t >= self.horizon info = { "p_grid": p_grid, "p_bat": p_bat, "soc": self.soc, "violation": violation, "cost": cost, } return self._get_obs(), reward, done, info def _get_obs(self): t_norm = self.t / self.horizon pv_norm = self.pv_profile[self.t] / self.p_bat_max load_norm = self.load_profile[self.t] / self.p_bat_max price_norm = self.price_profile[self.t] / 1.0 # 根据实际电价范围归一化 return np.array([t_norm, pv_norm, load_norm, self.soc, price_norm], dtype=np.float32)注意这里 SOC 递推用的是 1 小时步长的简化公式。实际项目中,如果你用的是 15 分钟调度步长,时间系数要除以 4,否则电池充放电能量会算错。这是很多新手忽略的物理细节。
还有一个关键动作:我在环境内部没有强制把 SOC 裁剪后的动作重新平衡一次。如果 SOC 越界被 clip 回上下界,实际电池功率和动作之间的对应关系就不一致了,策略学起来会混乱。我后面会专门说这个问题,代码里的 clip 只是为了避免仿真崩溃,但不能当作标准做法。
3.2 策略网络、Q 网络和 Lagrange 更新
SAC 的基础组件是:一个 Actor 网络、两个 Critic(Q)网络、两个 Target Q 网络。约束感知部分则多了一个 Lagrange 乘子 λ。
Actor 网络输出高斯分布参数,然后通过 tanh 变换得到动作。Q 网络输入状态和动作,输出单值 Q。这一层我直接用常见的 MLP 结构,没有加注意力机制,因为对于 24 小时调度级别的问题,MLP 已经足够。
import torch import torch.nn as nn import torch.nn.functional as F class PolicyNetwork(nn.Module): def __init__(self, state_dim, action_dim, hidden_dim=256): super().__init__() self.fc1 = nn.Linear(state_dim, hidden_dim) self.fc2 = nn.Linear(hidden_dim, hidden_dim) self.mean_layer = nn.Linear(hidden_dim, action_dim) self.log_std_layer = nn.Linear(hidden_dim, action_dim) def forward(self, state): x = F.relu(self.fc1(state)) x = F.relu(self.fc2(x)) mean = self.mean_layer(x) log_std = torch.clamp(self.log_std_layer(x), -20, 2) return mean, log_std def sample(self, state): mean, log_std = self.forward(state) std = log_std.exp() normal = torch.randn_like(mean) z = mean + std * normal action = torch.tanh(z) log_prob = self._gaussian_log_prob(mean, std, z) - torch.log(1 - action.pow(2) + 1e-6) return action, log_prob def _gaussian_log_prob(self, mean, std, z): return -0.5 * ((z - mean) / std).pow(2) + torch.log(std) + 0.5 * np.log(2 * np.pi)Critic 网络很简单,就是一个输入拼接后的 MLP。这里我不再贴完整代码,因为网络上随便能搜到标准 SAC 实现。真正需要特别注意的,是 Lagrange 乘子的更新逻辑。
标准的约束优化形式是:最大化累计奖励 R,同时保证累计约束违反 C 小于某个阈值 d。转换成拉格朗日形式后,每个训练步要做的更新是:
- 固定 λ,更新策略和 Q 网络,目标函数中包含
-λ * C - 固定策略,更新 λ,目标函数是
λ * (C - d),对 λ 做梯度上升 - 如果 C < d,λ 会变小,惩罚减弱;如果 C > d,λ 会变大,惩罚增强
注意,这个 d 代表“允许的累计约束违反预算”。如果你希望系统在 24 小时内几乎不越界,d 应该调成 0 或者在整数步范围内允许一次少量违反。如果 d 设太大,智能体学到的策略会在约束边缘反复试探。
class LagrangeUpdater: def __init__(self, lr_lambda=5e-4, threshold=0.0, max_lambda=100.0): self.log_lambda = torch.zeros(1, requires_grad=True) self.threshold = threshold self.max_lambda = max_lambda self.optimizer = torch.optim.Adam([self.log_lambda], lr=lr_lambda) def update(self, constraint_violation): lambda_loss = -(self.log_lambda * (constraint_violation - self.threshold)).mean() self.optimizer.zero_grad() lambda_loss.backward() self.optimizer.step() return self.log_lambda.exp().detach() def get_lambda(self): return self.log_lambda.exp().clamp(max=self.max_lambda).detach()这里的log_lambda是为了保证乘子始终为正,同时更新幅度更平稳。如果你直接用lambda做梯度上升,很容易出现负乘子,逻辑上就不对了。
3.3 训练主循环与重要参数
训练主循环的关键是:从经验池采样一批数据,依次更新 Q 网络、Actor 网络、Lagrange 乘子,再软更新 Target 网络。这里我不贴全部 200 行代码,只贴核心更新片段,并解释所以然。
for step in range(total_steps): obs, action, reward, next_obs, done, c_violation = buffer.sample(batch_size) # 1. 更新 Q 网络 with torch.no_grad(): next_action, next_log_prob = actor.sample(next_obs) target_q = torch.min(q1_target(next_obs, next_action), q2_target(next_obs, next_action)) y = reward + gamma * (1 - done) * (target_q - alpha * next_log_prob) q1_loss = F.mse_loss(q1(obs, action), y) q2_loss = F.mse_loss(q2(obs, action), y) q_optimizer.zero_grad() (q1_loss + q2_loss).backward() q_optimizer.step() # 2. 更新 Actor new_action, log_prob = actor.sample(obs) q_new = torch.min(q1(obs, new_action), q2(obs, new_action)) lambda_val = lagrange_updater.get_lambda() # 关键:约束感知体现在 actor 损失里 actor_loss = (lambda_val * c_violation - q_new + alpha * log_prob).mean() actor_optimizer.zero_grad() actor_loss.backward() actor_optimizer.step() # 3. 更新 Lagrange 乘子 lagrange_updater.update(c_violation) # 4. soft update target networks ...有两点我要专门提醒。
一是c_violation必须是一个可微的、与动作相关的量,否则 Actor 的梯度会非常不准。如果你在环境里只是 clamp 了动作,但没有回传动作和违反量之间的梯度信息,Actor 网络根本不知道“往哪个方向改动作能减少违反量”,只能靠随机探索试错。
二是 reward 里最好不要同时写死一个很大的违反惩罚。我在前面环境代码里用了penalty = 10.0 * violation,这会让训练更快地避开不可行区域,但也会让 Q 值的学习受到干扰。正确做法是:这个固定惩罚只作为“探索期的引导信号”,长期约束满足交给 λ 去保证。我之前把固定惩罚系数调到 100,结果 λ 一直很小,策略虽然严格不越界,但是整体的经济性变差了,相当于用性能换安全,没有体现“感知”的价值。
4. 实验结果、参数调优与部署建议
4.1 实验对比与结果解读
我拿同一份光伏、负荷、电价数据,分别训练了普通 SAC、SAC-Lagrange、以及“SAC-Lagrange + 小时级约束检查”三个版本。这里的“小时级约束检查”是我自己加的一个部署侧逻辑:每步动作生成后再做一次可行域校验,不满足就迭代修复,再不行就回退到上一个安全动作。
普通 SAC 训练 100 万步之后,24 小时累计经济指标确实比 SAC-Lagrange 略好一点,但它的 SOC 在 24 小时内大幅越界超过 8 次,联络线功率越界 5 次。这意味着它在物理系统里根本不能部署,保护动作会把指令拦下来,实际的收益统计是没有意义的。
SAC-Lagrange 在 100 万步后,约束违反量明显收敛到较低水平。我记录的累计违反指标从最初每 episode 30 左右,降到 2 到 3,而且这几次违反都属于“微小时段越界”,修复层一介入就能完全消除。经济性比普通 SAC 损失了大约 4%,但换来了真正的可行性和部署安全。
我还做了一组对比,测试 λ 的初始值和学习率的影响。使用lr_lambda=5e-4时,λ 会在前 10 万步快速爬升,然后缓慢下降;使用lr_lambda=5e-2时,λ 震荡得非常厉害,策略一会激进一会保守,训练曲线直接呈锯齿状。所以乘子学习率一般要比 Actor 学习率小一个数量级,这是一个值得记住的经验。
4.2 把训练好的策略做成可解释调度规则
很多工程师会问:如果我要给调度中心解释,为什么这个时段储能要充电、那个时段要放电,深度强化学习模型的黑盒特性怎么办。我的做法是:用训练好的策略生成一条参考轨迹,再用决策树把“状态→动作”的映射提炼成可读规则。
比如训练出的策略在下午 4 点以后会选择提高放电功率,往往是因为电价进入高峰区段,同时 SOC 还高于 0.5。决策树会给出类似“if 电价 > 0.8 且 SOC > 0.5,则放电功率 > 0.3 MW”的规则。虽然规则树不能完全复刻 RL 策略,但它可以给运行人员提供心理安全感,让他们不至于对着一个神经网络直接点头。
更实用的部署方案是“在线预瞄 + 规则兜底”。我通常会把训练好的 RL 模型作为调度建议的主模型,另外用一套经过验证的线性规划求解器作为 backup 方案。RL 建议在约束修复后仍然找不到解时,就切换成安全回退策略。这个设计不是让 RL 和线性规划二选一,而是让 RL 去处理那些“常规但没有教科书解”的模式,让线性规划负责处理所有边界情况。
5. 训练和部署中的常见坑
5.1 约束条件被“平滑”导致 SOC 持续越界
我在早期版本里犯过一个错:把 SOC 约束直接用 clip 平滑掉,每次动作导致 SOC 越界,我都强制把它拉回边界,再继续递推。这样的结果是智能体永远看不到真实越界,约束违反量被隐藏了,策略会疯狂把电池充到边界以上,然后靠环境自动修正兜底。看上去训练很顺利,实际部署时系统完全没有这个兜底,立刻崩溃。
正确做法是:在环境计算奖励和约束时,使用未 clip 的 SOC 值来算违反量;只在物理递推和下一状态输出时,才用 clip 后的 SOC 或直接标记为失效。这样才能让智能体明确接收到“这个行为越界了”的信号。
5.2 Lagrange 乘子震荡
如果发现训练后期 λ 还是反复横跳,可能是constraint_violation的量级和 reward 的量级差太多。举例:一天的电费可能是一两百,而 SOC 违反量的值是 0 到 1 的小数。λ 计算时全部混在一起,更新速度自然不稳。
我的做法是把每个违反分量做归一化:SOC 违反量除以电池容量,联络线功率违反量除以联络线功率上限,让每个约束的数值都压缩到 0 到 1 之间,然后再求和。这样处理后 λ 的量级比较稳定,调参难度低很多。
5.3 智能体学成“制造约束再补偿”的投机行为
这是所有罚函数方法共有的隐藏风险。如果你允许动作在约束边缘大幅度摆动,智能体可能学会一个模式:先违反一次 SOC 约束,获得一个更利于栅格电价套利的相位,然后再在下一段时间“补偿”。这个行为在累计经济收益上可能是划算的,但对电池寿命和系统安全非常不友好。
要遏制这种行为,我建议对累计约束违反量施加惩罚,而不是只惩罚单步违反。意思是,除了每一步的violation进 reward 之外,还要统计整个 episode 的sum_violation,把它作为一个额外信号传给 Lagrange 乘子。这样智能体就很难通过拆东墙补西墙来钻空子了。
5.4 多场景泛化失败
能源调度的最大痛点是场景多样性:春节负荷曲线和迎峰度夏负荷曲线差异巨大,光伏出力在阴雨天和晴天的波动也不是同一个量级。如果你的训练集只包含一种典型日,模型在换季时性能会断崖式下降。
我最后用的方案是“分场景训练 + 元调度器”:把晴天、多云、雨天、极端负荷日各作为一组场景,每个场景单独训练一个策略,再用一个轻量级分类器判断当前属于哪类场景,切换对应策略。这个方法比单一模型硬扛所有场景要稳得多。你也可以用 domain randomization,在训练时随机化光伏、负荷的幅值和相位,但要特别注意约束条件也要随之缩放,否则又会出现动作不可行的问题。
写在最后的一点体会
如果你想把这个流程复现到自己的系统里,我建议先从最简单的“普通 SAC + 固定惩罚”跑通一遍,拿到 baseline,再逐步替换成 SAC-Lagrange。不要一上来就把所有约束都加全,否则你会分不清到底是算法问题还是环境建模问题。先只保留 SOC 上下限,跑通再往里加联络线、爬坡率这些约束。
我自己在项目里用的最终组合是:约束感知的 SAC-Lagrange 作为主算法,加一个简单的动作投影修复层解决瞬时越界,加一个决策树解释器给调度人员看逻辑。实际运行了两个完整季度,约束处罚率降到了采样周期内的 1% 以下,运行成本相比纯规则调度大约低 5% 到 8%。这个结果的绝对值并不夸张,但考虑到这是在不牺牲安全性的前提下拿到的经济收益,我觉得这条路值得继续往下走。后面如果你们感兴趣,我可以再单独写一篇关于如何把训练后的策略迁移到嵌入式控制器上的内容,那里面的坑更多,也更值得说。
