企业官网建设流程全解析

做电网电压控制这个方向的朋友，应该都有过这种体验：配电网里光伏一多、风电一多，电压越限就像家常便饭，今天调这里、明天补那里，调度员累得够呛，传统方法越来越力不从心。我之前在一个分布式电源渗透率极高的模拟台区上跑了半年多的电压控制算法，从经典的无功优化到集中式强化学习都试过，最后真正跑通并且能上线做仿真的方案，是多代理强化学习。这篇文章就把我整个项目从环境搭建、算法选型到训练调参的完整过程拆开来讲，适合有一定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里跑Matpower，pandapower的好处是原生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, high=1.0, shape=(n_agents,), dtype=np.float32) # 观测空间：每个智能体观测本地电压偏差和邻近智能体的部分信息 self.observation_space = spaces.Box(low=-np.inf, high=np.inf, shape=(n_agents, obs_dim), dtype=np.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 多代理算法对比与选型

搞清楚环境之后，最纠结的就是算法选型。多代理强化学习的算法库不像单智能体那么成熟，很多算法还要自己搭。我试过三个主流范式，简单说说实测感受。

我在群里跟某研究者聊过这问题，他的看法跟我一致：对于光伏逆变器的连续无功调节，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(maxlen=capacity) 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 核心超参数配置参考

分享一下我最终用下来的超参数配置表，都是经过多轮对比测试的经验值，可以直接作为起点：

一个容易被忽略的参数是状态归一化。电网仿真的电压越限值在实际运行中都是很小幅度的，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 典型问题速查表

多代理强化学习调试起来比单智能体痛苦得多，因为一个异常表现可能有多个交叉原因。我整理了一张排查表，按症状分类，给了定位思路，是踩了无数坑换来的。

5.2 奖励工程是重中之重

很多人问多代理RL怎么做才能效果好，我的答案始终是：把80%的精力花在环境设计和奖励函数上，算法本身反而是其次。

奖励函数设计有几个容易走火入魔的地方。一是给出太密集的奖励，智能体会学会“洗奖励”——找到一种动作序列，不求把电压控制好，但能频繁收获小奖励而不触发大惩罚。二是奖励权重的平衡，我举个例子，如果网损惩罚权重太高，智能体可能学到把无功功率调得很大，导致电压反而偏离，因为它发现省下的网损收益超过电压惩罚。三是奖励函数里的死区设置，如果没有死区，智能体会在电压正常范围内来回微调试图优化，反而制造了不必要的动作。

5.3 工程化落地的几条实用建议

实验室跑通模型只是第一步，真正把这个系统往真实台区推还需要解决不少工程问题。我的建议是：

• 通信延迟建模：真实电网里智能体之间的通信不是即时的，我在环境里加入了高斯随机延迟来模拟这种情况，结果发现模型在延迟0.5秒以内性能几乎不掉，这给我很大的工程信心。
• 模型轻量化：把Actor网络压缩成两层128维的小网络，推理时延控制在10毫秒以内，在普通边缘设备上就能跑得动。
• 安全护栏：必须保留底层保护机制，比如逆变器自身的过压保护和低压保护不经过强化学习决策。RL输出的指令只能作为无功调节建议，最终下发前要经过本地安全校验。

我在实际项目里还有一个体会：别把多代理RL当成一个黑盒，很多操作习惯都应该经过多次实验确认。我试过让智能体直接控制有载调压变压器分接头，效果反而不如控制逆变器。原因是分接头是离散动作，多代理下的离散-连续混合动作空间会让训练复杂度骤增。如果可以的话，先用纯连续动作跑通基础版本，再考虑扩展离散动作。

如果你也要做这个方向，建议从IEEE 33节点系统开始，先把环境、算法、评估链路整通，再加入真实的历史负荷曲线和光伏数据。这个方向现在学术界和工程界都火的点在于：电网设备多且分散、数据质量参差不齐，正好是多代理RL发挥价值的场景，而Python生态的成熟程度，已经可以支撑一整套可复现的研究和工程闭环。