做电网电压控制这个方向的朋友应该都有过这种体验配电网里光伏一多、风电一多电压越限就像家常便饭今天调这里、明天补那里调度员累得够呛传统方法越来越力不从心。我之前在一个分布式电源渗透率极高的模拟台区上跑了半年多的电压控制算法从经典的无功优化到集中式强化学习都试过最后真正跑通并且能上线做仿真的方案是多代理强化学习。这篇文章就把我整个项目从环境搭建、算法选型到训练调参的完整过程拆开来讲适合有一定Python基础、了解基本强化学习概念、正想往电力系统方向落地的开发者参考。项目本身其实不复杂用Python搭一个多代理强化学习框架让电网里的各台分布式逆变器学会自主调节无功功率配合有载调压变压器分接头把全网的电压维持在安全范围内。但真做起来你会发现问题根本不在算法本身而在于“怎么把电网这个物理系统优雅地塞进强化学习的范式里”以及“多个代理同时学习时怎么避免整个系统震荡”。1. 为什么电压控制需要多代理强化学习1.1 分布式电源并网带来的电压难题传统配电网的电压控制逻辑很简单电能从变电站单向流向用户电压沿着馈线逐渐降低末端低压就靠有载调压变压器和电容器组来补偿。这是几十年来被验证过的成熟套路但前提是电网里的功率流向是确定的、可预测的。分布式光伏逆变器大规模接入之后这个前提被打破了。白天光照强的时候光伏出力远大于本地负荷多余的电能会沿着馈线往回倒送末端电压不但不降低反而可能飙升。我调试的那个模拟台区接入20%光伏渗透率之后末端节点电压在正午时段从1.02 pu直接冲到1.07 pu超过国标上限1.07 pu就是越限事故。更麻烦的是光伏出力受云层影响波动剧烈五分钟内电压可能来回冲好几次。这时候单靠传统的集中式优化就有问题。最典型的是集中式最优潮流它可以求出全局最优的无功调节方案但求解速度慢、依赖全网精确模型而且通信链路长实时性无法保证。实际上在配电网里每个节点都有本地控制器它们只能观测到本地和邻近节点的信息这天然就是个分布式决策问题。1.2 单智能体强化学习为何力不从心有的朋友会问既然电网环境可以用强化学习建模那直接训练一个中央智能体输入全网状态、输出所有逆变器的动作不就行了我在初期就是这么试的。用单智能体算法去控制56个光伏逆变器的无功出力状态空间维度高达上百维动作空间是56维连续量训练收敛慢得要命。这背后有个很实际的痛点单智能体的策略网络要同时输出所有逆变器的动作等于是让一个策略网络去协调几十个执行器的协同操作。电网是一个强耦合系统一台逆变器动作会影响周围十几条母线的电压单智能体要把这种全部依赖关系都学到需要的数据量和训练时长在实验室环境里根本扛不住。更致命的是可扩展性问题。单智能体方案里的网络结构和训练逻辑是跟设备数量绑死的这个台区有56台逆变器那个台区有80台换一个场景就得重新训练。现实中配电网的拓扑天天在变这种方案在工程上没有任何复用价值。1.3 多代理强化学习的核心价值多代理强化学习MARL换个思路不训练一个中央大脑而是训练一群智能体。每个光伏逆变器或者每组相邻的逆变器都由一个独立的智能体控制它们各自观测局部状态、做出局部决策通过共享奖励信号来协调彼此行为。这个思路和配电网的物理结构天然契合。配电网本身就是分区自治的每条馈线上的电压主要受本地和邻近逆变器影响远程设备影响很小。让每个智能体负责一小片区域状态空间和动作空间都大幅缩减训练难度显著下降。更重要的是多代理框架天然支持迁移。我在某模拟台区上训练好的策略网络迁移到另一个拓扑类似但节点数更多的台区只需要略微微调就能用因为每个智能体学到的是“局部观测到局部动作”的映射规则不是全网耦合的全局映射。这个特性在工程落地里太能打了。2. 环境搭建把电网仿真器包装成强化学习环境2.1 网架仿真器选型做电网强化学习第一步是选一个能跑潮流计算的仿真器。我用的是pandapower这个Python库底层基于pypower可以在几毫秒内完成一个上百节点配电网的三相潮流计算。相比直接在Matlab里跑Matpowerpandapower的好处是原生Python API设计得非常好可以直接挂在OpenAI Gym接口里做环境。有人推荐用更专业的配电网仿真软件但我个人不建议在早期阶段上重工具。一是因为大部分商业仿真软件的环境接口是封闭的跟Python交互要绕层二是配电网仿真用连续潮流或者三相不平衡潮流就够了不需要那种能模拟电磁暂态的大家伙。pandapower完全能满足训练需要。装好之后需要把网架数据导进去。我的做法是用pandapower内置的IEEE 33节点标准测试系统做基础网架然后手动加上分布式光伏和负载波动曲线。如果你有自己的配电网数据也可以用pandapower的JSON格式或者Excel格式导入这个后面再提。2.2 自定义Gym环境的结构设计把潮流仿真器变成强化学习环境核心就是写一个继承gym.Env的类。我先说一下整体结构再逐个模块拆解。import gym from gym import spaces import numpy as np import pandapower as pp import pandapower.networks as nw class VoltVarControlEnv(gym.Env): def __init__(self, network, load_profiles, pv_profiles, agent_mapping): super().__init__() self.net network self.load_profiles load_profiles self.pv_profiles pv_profiles self.agent_mapping agent_mapping # 智能体与设备节点的映射 self.time_step 0 # 动作空间每个智能体输出连续无功调节量归一化到[-1, 1] n_agents len(agent_mapping) self.action_space spaces.Box(low-1.0, high1.0, shape(n_agents,), dtypenp.float32) # 观测空间每个智能体观测本地电压偏差和邻近智能体的部分信息 self.observation_space spaces.Box(low-np.inf, highnp.inf, shape(n_agents, obs_dim), dtypenp.float32)这个环境设计的核心难点在agent_mapping也就是智能体到电网设备的映射关系怎么定。我试验过两种划分方式按设备划分每台光伏逆变器一个智能体优点是粒度细缺点是智能体数量多训练协同难度大。按区域划分把电网按馈线分段每段内的所有逆变器归一个智能体控制智能体输出的是这组逆变器的无功指令向量。这种方式智能体数量少、训练稳定。我的经验是在节点数超过30的网架上按区域划分明显更稳。因为同一个区域内逆变器之间的电气距离近电压耦合强让同一个智能体统筹区域的逆变器契合物理特性。区域内部的动作协调由单个智能体自己学区域之间的协调靠共享奖励。2.3 状态、动作与奖励的编码细节状态空间的设计直接决定训练成败我在这方面踩过不少坑。最忌讳的是一股脑把全网状态都塞给每个智能体这会让每个智能体都变成“小中央大脑”丧失了多代理的意义。我给每个区域智能体设计的观测向量包括三类信息本区域内所有关键节点的电压幅值归一化到0.9~1.1 pu区间。本区域内所有逆变器的当前无功出力。相邻区域内节点的平均电压偏移量作为区域间协调的弱通信信号。第二个和第三个是重点。只给本区域状态智能体之间完全孤立容易各自为政给了全网状态训练复杂度爆炸。折中方案就是给一部分邻居的汇总信息信息量少但信号清晰。动作空间方面我让每个智能体输出一个连续向量表示区域内各逆变器的无功调节比例。比如区域内有5台逆变器智能体就输出5维向量每维在[-1, 1]映射到实际无功注入就是乘以该逆变器的额定容量。最后用正切函数做上下限约束防止越限指令。奖励函数我拆成四个部分加权求和[ R_t -w_1 \cdot \sum_i \max(0, |V_i - V_{ref}| - V_{dead}) - w_2 \cdot \sum_j \Delta Q_j^2 - w_3 \cdot P_{loss} w_4 \cdot S_{stab} ]其中第一项是电压越限的惩罚V_dead设为0.01 pu也就是电压在0.99~1.01之间波动时不惩罚这个死区非常关键否则智能体会被微小波动逼疯。第二项是动作幅度惩罚抑制无功指令来回震荡。第三项是网损惩罚。第四项是稳定性奖励衡量当前状态与上一状态的电压变化幅度。权重设置上电压惩罚项要占绝对主导我用的比例是10:1:0.5:2。电压安全是硬约束网损优化是软目标不能让智能体为了省网损而牺牲电压质量。3. 算法选型与核心实现3.1 多代理算法对比与选型搞清楚环境之后最纠结的就是算法选型。多代理强化学习的算法库不像单智能体那么成熟很多算法还要自己搭。我试过三个主流范式简单说说实测感受。算法范式代表实现优点缺点适用场景独立Q学习IQL、VDN、QMIX动作离散时稳定连续动作需要离散化精度损失无功补偿电容组投切集中训练分布执行MADDPG、MASAC训练稳定支持连续动作实现复杂度高需要中心化信息连续无功调节基于通信的MARLCommNet、TarMAC可学习通信协议训练时间长通信机制难调大规模异构智能体我在群里跟某研究者聊过这问题他的看法跟我一致对于光伏逆变器的连续无功调节MADDPG和MASAC基本是首选因为动作空间是连续向量离散化会让电压控制的精度大打折扣。MASAC比MADDPG多了一个熵正则项探索更充分训练也更稳。我最后用的是MASAC变体用中心化Critic来缓解多代理环境的非平稳问题。3.2 MASAC核心代码骨架MASAC的完整实现代码量不小这里只给出最关键的部分让读者理解整个架构的脉络。完整代码我给项目里的同学也维护过核心就是一套Actor-Critic框架加熵奖励。import torch import torch.nn as nn import torch.nn.functional as F class Actor(nn.Module): def __init__(self, obs_dim, action_dim): super().__init__() self.fc1 nn.Linear(obs_dim, 256) self.fc2 nn.Linear(256, 256) self.mu nn.Linear(256, action_dim) self.log_std nn.Linear(256, action_dim) def forward(self, obs): x F.relu(self.fc1(obs)) x F.relu(self.fc2(x)) mu self.mu(x) log_std torch.clamp(self.log_std(x), -20, 2) std torch.exp(log_std) dist torch.distributions.Normal(mu, std) return dist class CentralizedCritic(nn.Module): def __init__(self, n_agents, obs_dim, action_dim): super().__init__() # 中心化Critic需要接收所有智能体的状态和动作 total_input_dim n_agents * (obs_dim action_dim) self.fc1 nn.Linear(total_input_dim, 512) self.fc2 nn.Linear(512, 512) self.output nn.Linear(512, 1) def forward(self, obs_all, act_all): x torch.cat([obs_all, act_all], dim-1) x F.relu(self.fc1(x)) x F.relu(self.fc2(x)) return self.output(x)MASAC里有两个关键设计点。第一每个智能体有自己的Actor网络但共享一个中心化的Critic。这个Critic在训练时能看到所有智能体的状态和动作从而准确评估单个智能体的动作在全局环境下的好坏这在多代理场景下至关重要。因为在多个智能体同时行动时一个智能体动作的奖励受别人影响很大没有全局信息的Critic评估会严重失真。第二Actor的损失函数里加了熵奖励项等于鼓励智能体保持策略的随机性。这在多代理场景里尤其重要因为如果所有智能体都立刻贪心收敛到当前最优动作整个系统容易陷入一个“互相克制”的次优平衡点。适当保持探索反而能找到更好的联合策略。3.3 训练主循环与经验回放多代理经验回放和单智能体有个重要的不同点必须把所有智能体的经验打包存放和采样。我之前踩过这个坑一开始为每个智能体单独维护经验池、单独采样结果发现采样的状态转移概率不一致训练完全发散。from collections import deque import random class MARLReplayBuffer: def __init__(self, capacity, n_agents): self.buffer deque(maxlencapacity) self.n_agents n_agents def push(self, obs, act, rew, next_obs, done): # obs/act/next_obs的形状都是 (n_agents, obs_dim) self.buffer.append((obs, act, rew, next_obs, done)) def sample(self, batch_size): batch random.sample(self.buffer, batch_size) obs_batch torch.FloatTensor(np.array([x[0] for x in batch])) act_batch torch.FloatTensor(np.array([x[1] for x in batch])) rew_batch torch.FloatTensor(np.array([x[2] for x in batch])) next_obs_batch torch.FloatTensor(np.array([x[3] for x in batch])) done_batch torch.FloatTensor(np.array([x[4] for x in batch])) return obs_batch, act_batch, rew_batch, next_obs_batch, done_batch这个经验池设计保证了训练时每个批次里的状态都是“同一时刻、所有代理联合动作”产生的这让Critic能学到真实的联合状态-动作价值而不是被单个代理部分可观测性带偏。训练循环本身和单智能体SAC很相似核心区别在于损失函数要对所有智能体求和。Actor的更新不仅考虑当前智能体的策略梯度还要用中心化Critic对所有智能体的动作求和来算联合优势。这一段PyTorch代码写起来不到一百行但是逻辑要理清千万别把不同智能体的梯度混在一起做反向传播。4. 训练实战与调参记录4.1 训练过程中的不稳定现象训练多代理模型和单智能体最大的感受差异就是不稳定性。我遇到过几次典型的失败模式前期震荡崩盘训练刚跑5000步时奖励还行到了8000步突然崩溃。排查发现是某个智能体的策略变化幅度过大导致其他智能体的经验全部失效。解决办法是把每个智能体的Critic学习率从3e-4降到1e-4并且给策略更新加梯度裁剪。奖励震荡但逐步收敛初期所有智能体都在摸索系统整体表现时好时坏这是正常的不用慌。我通常用滑动平均窗口画出奖励曲线以5000步的滚动均值来判断收敛趋势而不是看单步奖励。动作剧烈抖动训练后期出现了逆变器无功指令在正负间疯狂切换的问题。根本原因是奖励函数里没有加动作平滑惩罚项。后来我在奖励里加入了前后两个时刻动作差的平方项也就是把公式里的第二项从 [ \sum_j \Delta Q_j^2 ] 改成对动作变化率也惩罚[ R_{act} -w_2 \cdot \sum_j (\Delta Q_j^2 \lambda (Q_j^t - Q_j^{t-1})^2) ]这个改动效果立竿见影动作抖动幅度下降了90%以上。4.2 核心超参数配置参考分享一下我最终用下来的超参数配置表都是经过多轮对比测试的经验值可以直接作为起点参数名称数值说明Actor学习率1e-4过大会导致训练不稳定Critic学习率2e-4中心化Critic可稍高熵奖励系数0.05探索与利用的平衡点批量大小256经验池采样批次经验池容量1e5多代理经验池目标网络软更新系数0.005目标策略平滑更新奖励折扣因子0.99长期收益权重梯度裁剪阈值10.0防止梯度爆炸一个容易被忽略的参数是状态归一化。电网仿真的电压越限值在实际运行中都是很小幅度的0.95到1.07 pu之间如果直接用这个范围内的数值作为神经网络的输入数值差异太小梯度信号微弱。我的做法是把每个观测值减去参考电压1.0再除以基准电压偏移量0.1把信号放大到-0.5到0.7的区间训练速度明显提升。4.3 训练结果与效果验证我在33节点系统上训练了大概20万步单机CPU跑了一天多模型就达到了稳定收敛。验证阶段我用了完全不参与训练的一组高波动光伏出力曲线持续3600秒模拟覆盖正午、傍晚、夜晚三个时段。最终结果全部节点电压都在0.97~1.03 pu的安全范围内最大越限电压从最初的1.07降到1.025网损相比不控制时降低了约8%。这个结果用传统方法也能做到但多代理方案的响应速度优势非常明显——从电压偏移发生到控制动作生效大约只要1秒而传统集中式最优潮流算一次至少要好几秒。5. 多代理实现中的常见问题与排查手册5.1 典型问题速查表多代理强化学习调试起来比单智能体痛苦得多因为一个异常表现可能有多个交叉原因。我整理了一张排查表按症状分类给了定位思路是踩了无数坑换来的。症状可能原因排查方法奖励曲线完全不上升奖励信号太稀疏、状态量纲不合适检查奖励各分项数值尺度电压值是否归一化训练前期还行、中后期崩盘某个智能体策略突变其他智能体经验失效降低学习率、加强熵奖励、增加梯度裁剪动作频繁振荡缺少动作平滑惩罚项加入动作变化率惩罚项每个智能体表现好、全局表现差智能体只顾局部利益缺乏协调信号增大相邻区域电压信息的权重、调整共享奖励结构测试时表现远差于训练训练环境过拟合、缺少随机化在训练时随机化负载和光伏曲线的初始相位梯度爆NAN奖励数值过大、网络初始化不当检查奖励各分项数值范围、添加奖励裁剪5.2 奖励工程是重中之重很多人问多代理RL怎么做才能效果好我的答案始终是把80%的精力花在环境设计和奖励函数上算法本身反而是其次。奖励函数设计有几个容易走火入魔的地方。一是给出太密集的奖励智能体会学会“洗奖励”——找到一种动作序列不求把电压控制好但能频繁收获小奖励而不触发大惩罚。二是奖励权重的平衡我举个例子如果网损惩罚权重太高智能体可能学到把无功功率调得很大导致电压反而偏离因为它发现省下的网损收益超过电压惩罚。三是奖励函数里的死区设置如果没有死区智能体会在电压正常范围内来回微调试图优化反而制造了不必要的动作。5.3 工程化落地的几条实用建议实验室跑通模型只是第一步真正把这个系统往真实台区推还需要解决不少工程问题。我的建议是通信延迟建模真实电网里智能体之间的通信不是即时的我在环境里加入了高斯随机延迟来模拟这种情况结果发现模型在延迟0.5秒以内性能几乎不掉这给我很大的工程信心。模型轻量化把Actor网络压缩成两层128维的小网络推理时延控制在10毫秒以内在普通边缘设备上就能跑得动。安全护栏必须保留底层保护机制比如逆变器自身的过压保护和低压保护不经过强化学习决策。RL输出的指令只能作为无功调节建议最终下发前要经过本地安全校验。我在实际项目里还有一个体会别把多代理RL当成一个黑盒很多操作习惯都应该经过多次实验确认。我试过让智能体直接控制有载调压变压器分接头效果反而不如控制逆变器。原因是分接头是离散动作多代理下的离散-连续混合动作空间会让训练复杂度骤增。如果可以的话先用纯连续动作跑通基础版本再考虑扩展离散动作。如果你也要做这个方向建议从IEEE 33节点系统开始先把环境、算法、评估链路整通再加入真实的历史负荷曲线和光伏数据。这个方向现在学术界和工程界都火的点在于电网设备多且分散、数据质量参差不齐正好是多代理RL发挥价值的场景而Python生态的成熟程度已经可以支撑一整套可复现的研究和工程闭环。
