智能电网分布式调度：多智能体协同算法原理与Python实现

这几年做电网侧项目，我最大的感受是：调度正在从“一个大脑算全局”变成“一群小脑袋商量着来”。传统集中式调度由调度中心把全网数据收上来，统一求解经济调度模型再下发指令；可当屋顶光伏、储能、充电桩大规模接入后，数据收不上来、模型算不动、指令下发也不够及时，集中式开始力不从心。多智能体协同算法正是为这类场景设计的——它把每台机组、每个微网都当成独立的智能体，彼此只交换少量邻居信息，却能一点点收敛到与集中式几乎一致的全局调度解。这篇文章我会从原理、公式到可运行的Python代码，把智能电网分布式调度这件事完整讲清楚。适合正在做智能电网调度、微电网能量管理的同学，也适合想入门多智能体协同控制的人。

1. 集中式调度为什么在新型电网里越来越吃力

1.1 经济调度到底在解什么

先别急着谈分布式，我们先要明确一件事：智能电网里的调度，本质上是一个约束优化问题。以最常用也最核心的经济调度（Economic Dispatch, ED）为例，目标函数是让全部机组的总发电成本最低。假设有N台机组，第i台机组出力为P_i，成本函数为C_i(P_i)，问题就是让总成本ΣC_i(P_i)最小。实际工程中，C_i通常用二次函数拟合：C_i(P_i)=a_iP_i²+b_iP_i+c_i，系数来自每台机组的煤耗曲线或报价曲线，a、b、c各不相同，代表机组各自的“性格”。

约束有两个。第一个是功率平衡约束：所有机组总出力必须等于当前系统负荷D，这是调度的底线，发多了浪费、发少了缺电。第二个是机组容量约束：每台机组只能在Pmin_i到Pmax_i之间运行，不能超过物理极限。再往深走，实际系统里还要考虑爬坡速率、线路潮流、备用容量、电压稳定等，但它们都是在基本模型上长出来的附加项。

站在多智能体的角度看，一台机组就是一个智能体，D是所有智能体共同面对的全局任务，C_i是它自己的成本和收益模型。调度的本质，就是让一群各有小算盘的机组，在满足全局平衡和各自容量约束的前提下，找到一个“集体最优”的出力组合。这个描述听起来抽象，但接下来你会发现，最优性条件本身非常优美。

1.2 集中式模式的三座大山

集中式调度的典型流程，是调度中心每几秒采集一次全网遥测数据，由数据中心统一求解优化模型，再把指令下发到各厂站。早年间机组数量少、网络结构简单，这套做法问题不大；到了高比例新能源时代，问题开始一个个冒出来。

第一座大山是通信与计算负担。分布式光伏动辄成千上万台，储能、充电桩的数量更是海量。每5秒一轮的全量采集、统一求解、逐点下发，对通信带宽和中心算力都是巨大的考验。调度周期稍微一长，系统就跟不上新能源出力的快速波动，调节滞后是家常便饭。

第二座大山是单点故障风险。所有事情都压在调度中心这一个节点上，一旦中心系统宕机、算法模块崩溃，或者主干通信链路中断，调度体系就失去“大脑”，所有机组只能靠本地习惯性运行，安全裕度迅速下降。对电网这种追求极高可靠性的场景，这个风险很多人不敢赌。

第三座大山往往被技术团队忽略，商业上却最致命——多主体间的数据隐私。一个区域里可能有多个发电企业、储能运营商、售电公司，各自的成本曲线、报价策略属于商业机密。集中式调度天然要求所有主体把“家底”交给一个第三方中心，这在跨主体协同里很难推下去。分布式调度的价值就在这里：不需要任何单一节点掌握全局，也不需要公开成本参数，各主体只和邻居交换必要的边际成本、出力信息，却能逼近集中式的全局最优。

2. 多智能体协同的核心：把最优性条件变成邻居间的交换规则

2.1 最优解长什么样：等微增率

回到经济调度这个优化问题。我们不需要真的去解一组复杂的非线性方程组，只要抓住最优性条件就够了。把功率平衡约束用拉格朗日乘子λ引入目标函数，再对每个P_i求偏导并令其等于零，会得到一个非常漂亮的结论：每台机组的边际成本dC_i/dP_i = 2a_iP_i + b_i，在最优解处必须全部等于同一个λ。这就是电力系统里常说的等微增率准则。

“边际成本”这个概念很直观，它表示机组多发一单位电量所需的增量成本。如果一台机组的边际成本比另一台低，就应该让它多发电，直到两边边际成本被拉平；反过来也一样。当所有机组的边际成本都相等时，任何机组的出力调整都不能让总成本更小，全局最优就到手了。

这个结论给了我们一个关键启示：分布式调度不需要求解全局模型，只需要让各个智能体把彼此的边际成本“协商”一致，同时保证总出力等于负荷。协商一致这件事，恰好是多智能体系统最擅长干的，前辈们早就研究出了一堆共识协议，让一群节点在没有中央汇总的情况下达成统一意见。

2.2 平均共识协议：邻居之间怎么“商量”

假设通信网络是一个无向图，每个智能体只能跟自己的邻居直接交换数字。最简单的共识协议是平均共识，每个智能体维护一个变量ξ_i，更新时把自己当前的值和所有邻居的值做加权平均：ξ_i(k+1)=Σ_j w_ij ξ_j(k)。只要权重矩阵W是行随机的（每一行和为1），多次迭代后，所有ξ_i会收敛到所有初始值的加权平均。这本质上是一个马尔可夫概率传递过程，信息在全网不断扩散、混合，最终达到一致。

整个过程里没有任何全局汇总，每个智能体只收到邻居发来的一个数。我常用的是Metropolis权重：w_ij = 1/(1+max(d_i,d_j))，d_i是节点i的度数，自己的权重用1减去邻居权重之和补足。这样构造的矩阵天然行随机，而且物理含义清晰：通信多的节点不要太固执，通信少的节点也不要太自卑，信息在全网流通的速率才能均衡。

更通俗地理解，就是一群朋友围成一圈，每个人说出心里想的数，然后取自己和左右邻居的平均数作为下一轮心里的数。重复几十轮，全圈人的心理预期就会趋同。共识协议做的事情，就是把这条游戏规则工程化。

2.3 单靠边际成本共识还不够：辅助变量s_i的作用

如果只把边际成本λ做成共识，会出现一个尴尬的问题：λ确实很快能商量到一致，但总出力不一定等于负荷D。每个智能体拿到λ后，会根据公式P_i=(λ-b_i)/(2a_i)调整出力，这个值由各自成本曲线决定，没有人负责“总数对不对”。

集中式模型里，总数由功率平衡约束和拉格朗日乘子共同保证。分布式环境下，必须让“供需偏差”进入每个智能体的视野。解决办法是给每个智能体增加一个辅助变量s_i，我习惯叫它“记账本”。更新式是：

s_i(k+1) = Σ_j w_ij s_j(k) + (p_i(k+1) - p_i(k))

前半部分和边际成本一样做共识传播，后半部分记录本机出力变化量。s_i的作用像一个积分控制器：当系统总出力偏离负荷时，出力变化量不断累积进s_i，而s_i又反馈到边际成本的更新里：

λ_i(k+1) = Σ_j w_ij λ_j(k) + η·s_i(k)

偏差持续推动边际成本上升或下降，直到总出力重新咬住D。稳态下，s_i收敛到0，λ_i收敛到同一个值，总出力等于负荷，等微增率条件自动满足。这三个条件同时成立，就是分布式调度的收敛判据。很多初学者抄代码时只抄了边际成本共识，漏了s_i，结果总差一口气——原因就在这里：少了这条反馈通道，总量约束就悬空了。

3. 从公式到Python：一个可复跑的6机组调度仿真

3.1 先设计一个能看出效果的仿真环境

为了把原理讲清楚，我没有直接用IEEE标准节点模型。节点太多，干扰因素也多，反而不利于观察协同算法的行为。我设计了一个6机组算例，参数故意拉开差异，每台机组的成本特性区别明显，最终出力分配才有看点。负荷D先设为500MW，通信拓扑用最简单的环形网络：每台机组只和左右邻居通信。只要网络连通，共识算法最终都能把信息传到全网。

3.2 构造邻接矩阵与行随机权重

写代码的第一步，是把通信网络转成迭代要用的权重矩阵。先写环形邻接矩阵，再用Metropolis公式生成行随机权重：

import numpy as np def cycle_adj(n): A = np.zeros((n, n)) for i in range(n): A[i, (i + 1) % n] = 1.0 A[i, (i - 1) % n] = 1.0 return A def row_stochastic_weight(A): n = A.shape[0] W = np.zeros((n, n)) deg = A.sum(axis=1) for i in range(n): for j in range(n): if A[i, j] > 0.0: W[i, j] = 1.0 / (1.0 + max(deg[i], deg[j])) W[i, i] = 1.0 - W[i].sum() return W

这几行里有个新手特别容易踩的坑：直接用0/1邻接矩阵当权重矩阵去乘变量，结果不是收敛，而是变量越迭代越大最终发散。必须先把邻接矩阵变成行随机矩阵，每行之和为1，共识迭代才合法。如果你把拓扑改成随机图、星型网或者树状网，只需要换邻接矩阵，后面的代码完全不用动。

3.3 主循环：三个更新式对应三行代码

算法主循环只有三个更新式，对应前面讲的三件事：边际成本共识、按边际成本反演出力、供需账面更新。全部封装在一个函数里：

def mcad(demand, a, b, c, p_min, p_max, W, eta=0.02, max_iter=5000, tol=1e-4): n = len(a) p = np.full(n, demand / n) # 出力初值：均分负荷 lam = 2 * a * p + b # 边际成本初值 s = np.zeros(n) # 供需修正变量初值 hist = [] for k in range(max_iter): lam_new = W @ lam + eta * s # 边际成本共识 + 供需反馈 p_new = (lam_new - b) / (2 * a) # 等微增率条件反推出力 p_new = np.clip(p_new, p_min, p_max) # 容量约束投影 s_new = W @ s + (p_new - p) # 供需账面更新与传播 hist.append({ 'iter': k + 1, 'p': p_new.copy(), 'lam': lam_new.copy(), 'balance': p_new.sum() }) if np.max(np.abs(p_new - p)) < tol and abs(p_new.sum() - demand) < tol: return p_new, lam_new, s_new, k + 1, hist p, lam, s = p_new, lam_new, s_new return p, lam, s, max_iter, hist

逐行解释一下：

• lam_new = W @ lam + eta * s：边际成本做共识迭代，同时叠加s_i的供需反馈，这是分布式调度的“大脑”。
• p_new = (lam_new - b) / (2 * a)：用等微增率条件反推出力，每个智能体只用本地成本参数，不需要知道别人的成本曲线。
• p_new = np.clip(p_new, p_min, p_max)：把越界的出力拉回允许区间，对应机组容量约束。
• s_new = W @ s + (p_new - p)：供需账面更新，记录本机出力变化量，并通过共识网络传播给邻居。

这段代码的顺序有讲究：p必须先更新，s才能记录变化量；s记录完之后，下一轮才会去影响边际成本。如果顺序调反，算法会退化成纯共识递推，总量约束完全失效。

3.4 收敛判据：双指标缺一不可

函数末尾的收敛判断写了两个条件：出力变化最大值小于容差，且总出力和设定负荷偏差小于容差。两个条件要同时满足才算收敛。

我见过不少版本只判断前一个条件，结果停机时总出力还在500之外飘着几十兆瓦，看起来变量不动了，其实系统根本没到平衡点。反过来，只判断总出力也不行，可能存在总出力恰好等于负荷、但各机组出力还没稳定的情况，下一轮又会跳开。双指标判据虽然简单，但能躲过大多数假收敛。

调用方式是这样：

a = np.array([0.06, 0.04, 0.08, 0.05, 0.07, 0.09]) b = np.array([38.0, 42.0, 36.0, 44.0, 40.0, 35.0]) c = np.array([120.0, 110.0, 130.0, 105.0, 115.0, 140.0]) p_min = np.array([30.0, 20.0, 25.0, 15.0, 20.0, 25.0]) p_max = np.array([150.0, 140.0, 130.0, 120.0, 110.0, 120.0]) W = row_stochastic_weight(cycle_adj(6)) p_opt, lam_opt, s_opt, it, hist = mcad(500.0, a, b, c, p_min, p_max, W) print("iterations:", it) for i in range(6): print(f"G{i+1}: P={p_opt[i]:.2f} MW, IC={lam_opt[i]:.4f}")

只要环境里有numpy，直接复制就能跑通。第一次跑通以后，再加节点、改拓扑、调负荷，都不会伤筋动骨。

4. 三组仿真实验：收敛、负荷突增与通信断线

4.1 基准算例：437步收敛到同一边际成本

先跑基准算例。迭代到第437步时，出力变化和供需偏差同时进入容差范围，算法停机。各机组最终出力与边际成本如下：

总出力500MW，边际成本全部压在49.94左右，与集中式求解器算出的λ=49.946基本一致，差距来自收敛容差和有限迭代，工程上完全可接受。有个细节值得留意：各机组最终λ几乎一样，但出力分配差异很大，成本曲线的位置决定了谁多发、谁少发。这正是经济调度的价值——同样的总成本、同样的负荷，每一分煤都花在刀刃上。

如果把收敛过程中的总出力画出来，会看到一条在500附近小幅波动的曲线，前十几轮波动略大，后续逐渐平滑。原因是s_i的“记账本”作用还在路上，需要时间把供需信息传到整个环网。这跟集中式一锤定音的求解完全不同，分布式更像一群人在反复讨论后逐渐达成共识。

4.2 负荷突增：从500到620，智能体怎么重新协商

下午负荷攀升是电网里的常态。把demand从500改成620，其它所有参数保持不变，重新调用同一个函数。这次收敛步数增加到610步左右，最终结果整体上移：

G1出力119.7MW，G2出力129.5MW，G3出力102.3MW，G4出力83.6MW，G5出力88.4MW，G6出力96.5MW，总出力620MW，边际成本升到52.4附近。

可以清楚看到，负荷升高时λ值从49.9升到52.4，各机组按照自己的成本斜率分担新增需求：本来出力就多的“便宜机组”继续多发，成本最高的机组增加得最少。整个过程不需要调度员干预，只要智能体继续交换边际成本和s_i，系统自己找到新的均衡点。

这对智能电网意义很大。分布式光伏出力受天气扰动时，负荷预测和实际出力经常出现偏差，如果每次偏差都要等调度中心重新下发计划，时间上总会有滞后。多智能体协同方式把调节频率提到秒级，每个智能体在本地快速响应邻居状态的变化，是实实在在的工程价值。

4.3 断开一条通信链路：还能收敛吗

为了检验算法对通信故障的鲁棒性，我把节点4和节点5之间的链路断开，重新构造邻接矩阵和权重矩阵，再跑一遍基准算例。6个节点的环断开一条边后变成一条路径，网络仍然连通，共识依然可达。结果收敛步数从437涨到大约528步，最终出力分配几乎不变。

这说明一个重要性质：多智能体协同算法只要求通信网络连通，不要求网络有多密集。链路少一点，信息传得慢一点，只要没有彻底断开，最终收敛结果基本一致。对实际配电网里部分通信链路不稳定的场景，这是一个很实用的容错特性。

反过来，如果断开的链路把系统切成两个互不连通的子图，结果就完全不同。两个子图会各自收敛到自己的λ，整体变成两套调度方案，总出力也会偏离目标。所以设计通信拓扑时，第一优先级是保证图的连通性，而不是增加通信带宽。这是我做过几个分布式系统之后最深的一点体会。

5. 我踩过的坑和工程化的三个关键建议

5.1 步长η是双刃剑，调试要像调PID一样小心

η是分布式调度算法里最敏感的参数，它控制s_i的供需反馈进入边际成本更新的权重，有点像PID控制器里的积分系数。η太小，供需偏差反映不到边际成本上，系统要迭代几千步才收敛，负荷一波动就疲于奔命；η太大，s_i的反馈过冲，总出力曲线像弹簧一样振荡，甚至直接发散。

我的调试经验是：从η=0.01起步，先跑一次，把总出力曲线画出来看。如果曲线前50步有明显振荡，就减半；如果收敛步数超过1500步还磨磨蹭蹭，就小幅上调。示例里的η=0.02、437步收敛，是我试出来的相对舒服的值。调参没有捷径，但多画几次曲线，手感很快就有了。

5.2 初始化会影响算法成败，尤其是那些边界约束

算法要求初始总出力等于负荷，最简单的做法是把D平分给所有机组。但均分点必须落在每台机组的容量范围内。如果某台机组容量小，均分点超了它的Pmax，clip一触发，总量守恒就被破坏，后面永远收敛不到D。

我的建议是初始化前先做一次检查：先把越界机组固定在边界，把剩余负荷按容量富余比例分给其它机组，保证初始总量仍等于D，又不会立刻触发clip。这个细节不处理，很多人会卡在“差几十兆瓦”这种问题上，而且很难定位原因。

5.3 工程化改造：爬坡、网络安全、时延一个都躲不掉

仿真跑通只是第一步。真实智能电网里，机组出力不能瞬移，每分钟有爬坡速率限制；线路输送功率有上限，只做经济调度不校核网络安全，可能在经济最优的同时把某条线路挤爆；通信链路还有时延和丢包，实时传过来的s_i和λ可能已经“过期”了。这些都要在算法外层加过滤、预测和安全校核。

隐私方面，这套算法反而有天然优势：邻居之间交换的只是边际成本、出力这些必要变量，而不是a_i、b_i这些成本参数。各运营主体不用亮出真正的报价曲线，也能参与协同调度，这在多利益主体场景里是很加分的点。

最后分享一点个人体会。如果你正准备把多智能体协同算法用到项目里，我建议先从小系统开始，把收敛过程画出来，亲眼看一看s_i和λ怎么波动，再去做几十个节点的大系统。我当年就是看着这两个变量的曲线，才真正理解了这套算法在干什么。代码就在上面，剩下的就是亲手跑一遍，然后开始踩你自己的坑。