合作型Stackelberg博弈微网能量管理：建模、代码与工程实现

做微网能量管理的人，迟早会碰到一个问题：当园区里不仅有运营商在统筹调度，还有一批各自算账的光伏用户、储能用户时，集中式优化那套“一个目标函数管到底”的思路就开始失灵了。我们课题组去年就是在这个背景下，用合作型Stackelberg博弈把整套微网能量管理重做了一遍，代码已经整理成可复用的工程。这篇博文就当作一份详细的功能说明来写，从模型落到代码的映射关系、目录结构和核心函数，到复现实验要改哪些参数、实际调试会遇到哪些坑，尽量一次讲透。如果你正在复现主从博弈相关的论文，或者想给自己的微网优化项目加一个多主体的对比基线，这篇文章应该能帮你省下不少时间。

1. 为什么微网能量管理场景里要用博弈而不是单纯集中优化

1.1 集中式优化在多主体共存的微网里为什么推不动

传统微网能量管理系统（EMS）的典型做法，是把整个微网的所有可调资源丢进同一个优化模型，目标函数通常是“全系统运行成本最小”或者“碳排放最小”，约束涵盖功率平衡、储能SOC、机组爬坡、联络线功率限制等等。只要微网的所有设备产权归属同一个运营主体，这套做法是没问题的，Gurobi一把梭，几分钟出结果，调度指令下发执行即可。

但分布式光伏和储能大规模铺开之后，场景变了。现在一个园区微网里，运营商和用户不再是“上下级”关系，而更像“平台和租户”的关系。用户装了光伏，白天想自用，余电想卖个好价钱；用户装了储能，更希望低充高放套利。运营商关心的则是峰时少从电网买高价电、尽量通过内部调度降低整体购电成本。这两个目标方向并不天然一致——你让用户在晚高峰多放电，用户会想“我凭什么牺牲自己的套利机会听你调度”。集中式优化缺少一个关键机制：激励相容性。它只能假设用户服从指令，却无法回答“用户为什么要服从”。

这个问题的本质是：能量管理从“单主体决策问题”变成了“多主体交互问题”。单主体优化只要找全局最优解，多主体交互则必须考虑每个主体的理性行为。一个很自然的建模工具就是博弈论，而Stackelberg博弈恰好对应“运营商先出价格、用户后做响应”的真实市场逻辑。

1.2 Stackelberg主从结构恰好匹配“运营商定价格、用户做响应”

Stackelberg博弈又叫主从博弈，核心结构是：领导者先行动，跟随者观察到领导者的行动后再做最优反应，领导者做决策时要把跟随者的反应函数考虑进去。放到微网里，领导者就是微网运营商或售电公司，它公布未来24小时的内部分时售电价/购电价；跟随者是各个用户，它们拿到电价之后，各自求解自己的用能优化问题，决定购电曲线、储能充放电曲线、可平移负荷的安排。

这种结构跟真实世界的价格引导机制是同构的：运营商不直接命令用户“你必须几点充几点放”，而是通过价格信号引导用户改变用电行为。用户有自主权，运营商有定价权，双方在均衡点达成一致。相比集中式优化，这套机制天然具备可落地性——因为每个用户确实是在自己的目标函数下做选择，不存在“指令不执行”的问题。

代码层面，这种结构也很清晰：上层循环由运营商的价格迭代驱动，下层循环是一组彼此独立的用户优化子问题，天然适合并行求解。这也是我选择用Stackelberg而不是单纯集中式做微网能量管理的原因之一：模型逻辑和代码结构能够严格对应，调试时非常直观。

1.3 “合作型”到底改了什么：从纳什均衡走向帕累托改进

但纯Stackelberg有一个短板：它假设跟随者之间各自独立、互不合作。这在用户数量少、彼此用电行为差异大的场景下问题不大，可一旦用户同质化程度高，就会出现集体次优。举个例子，运营商把凌晨低谷电价定得很低，结果10个用户全把储能安排在凌晨同一时段充电，形成一个新的负荷尖峰，运营商不仅没削峰，反而造了峰。

合作型Stackelberg的关键变化在于：在保持“运营商做领导者、用户做跟随者”这一主从结构的同时，允许跟随者群体内部形成合作联盟，共享部分资源（比如共享储能、P2P电量交易），并且把合作产生的额外收益按照一定规则分配给各用户。这样既保留了价格引导的主从机制，又让用户之间通过合作实现帕累托改进——整体成本下降的同时，每个用户的成本都不比独立时更差。

代码实现上，“合作”不是重新写一套博弈，而是在原Stackelberg迭代收敛后，增加一个收益分配模块：先算出“合作前各用户独立最优总成本”，再算出“合作后联盟最优总成本”，差值就是合作剩余，然后用Shapley值或Nash谈判把它分掉。下面两章就分别讲模型怎么映射到代码，以及这些模块具体长什么样。

2. 合作型Stackelberg模型从数学公式到代码映射

2.1 上层领导者模型与下层跟随者模型的变量和约束

先看上层。运营商的决策变量是24个时段的内部售电价 $\lambda_t^{sell}$ 和内部购电价 $\lambda_t^{buy}$，如果简化一点就只定一个净电价 $\lambda_t$。目标函数是运营商收益最大化：收益等于用户购电费收入，减去运营商从上级电网买电的成本，再减去向用户买电的支出。约束条件包括：电价不能超过政府目录电价上下限，避免运营商乱定价；如果运营商还运营共享储能，那还要加上储能的充放电约束和SOC递推约束。

代码里对应的是一个 MarketOperator 类的核心逻辑。它内部保存电价上下限、购电成本曲线、共享储能参数这些字段，核心方法就是 update_price() 和 compute_revenue()。这里有个很多人容易忽略的细节：上层模型的目标函数里会出现“电价乘以用户购电量”这种双线性项，如果直接套数学公式写进Gurobi，会得到一个非凸二次约束，求解很痛苦。迭代法之所以好实现，就是因为每一轮电价是固定值，用户购电量是求解回来的常数，相乘之后只是普通算术，不存在非线性求解问题。

下层就是每个用户的用能优化问题。给定24h电价序列，用户决策购电功率、光伏上网功率、私有储能充放电功率、可平移负荷的启停时间。目标是最小化自己的用电总成本，也就是购电费用减掉卖电收入。约束包括功率平衡、设备功率限幅、储能SOC、可平移负荷只能在指定时间窗内启动等。如果用户没有储能和可平移负荷，下层就是一个线性规划（LP）；一旦有整数变量参与，就变成混合整数线性规划（MILP）。

2.2 上下层耦合与两种求解路径的取舍

把上下层放一起看，耦合关系就一目了然：上层电价 $\lambda$ 进入每个用户的目标函数，用户的购电总量 $Q$ 反过来决定运营商的收益。这个循环就是Stackelberg均衡的求解过程。

代码实现上有两条主流路径：

这套代码默认采用迭代求解法，原因很实际：我们场景里的用户层往往带可平移负荷和储能启停，整数变量不少，下层很难保证严格凸；迭代法不需要额外推导，还能用多进程并行求解所有用户的子问题，实测下来N=20个用户、24小时模型，单次迭代只需要跑10个左右的MILP，整体速度完全够用。

2.3 收益分配模块：Shapley值与Nash谈判的代码表达

合作收益分配是整个模型里最需要讲清楚的部分，因为很多论文里提“合作”只是一句话，但代码落地时分配规则直接影响每个用户的最终成本。

Shapley值的思路非常朴素：把每个用户在所有可能的合作子集中带来的边际贡献取平均。两个用户的简单场景，A的Shapley值就是“A单独合作时的贡献”和“AB组成联盟时A新增的贡献”两者的平均。代码实现上，最直接的做法就是枚举所有用户子集，对每个子集调用一次联盟成本函数，算出边际贡献再除以子集数量的阶乘。

联盟成本函数的实现是这样的：给定一个用户子集S，把所有属于S的用户打包成一个“联合体”，共享光伏余电、共享储能容量，在固定电价下求解一个联合优化问题，得到联盟总成本。这个函数的计算次数是关键瓶颈——N个用户精确计算Shapley值需要调用 $N!$ 次联盟成本，10个用户还能忍，15个用户就是天文数字。代码里我做了一个开关：用户数小于等于10时走精确枚举，大于10时用蒙特卡洛采样，随机抽几千个排列做近似估计，误差在可接受范围内。

如果不想用Shapley值，代码里还保留了Nash谈判解的实现：把合作剩余的分配问题建模成一个最大化Nash乘积的优化问题，让每个用户分配到的收益不低于其独立时的保留效用。Shapley值适合用户之间相对“平等”的场景，Nash谈判则适合有强势用户、需要体现谈判力的场景，二选一即可，不用两个都跑。

3. 代码架构与核心函数功能说明

3.1 工程目录与模块职责

拿到代码之后第一件事，先别急着运行，花十分钟把目录过一遍。工程按照“模型、求解、工具”三层来组织，逻辑很清晰：

text复制coop-stackelberg_em/
├── main.py                        # 程序入口
├── config.yaml                    # 所有可调参数
├── data/
│   ├── load_curve.csv             # 各用户负荷曲线
│   ├── pv_curve.csv               # 各用户光伏出力曲线
│   ├── grid_tariff.csv            # 上级电网分时电价
│   └── example_24h/               # 示例算例数据
├── models/
│   ├── operator.py                # 上层：微网运营商
│   ├── prosumer.py                # 下层：单个产消者
│   ├── cooperative.py             # 合作联盟与成本函数
│   ├── allocation.py              # Shapley值 / Nash谈判分配
│   └── network.py                 # 网络与功率平衡约束
├── solvers/
│   ├── iterative.py               # 迭代求解主循环
│   ├── milp_builder.py            # 用户MILP模型构建
│   └── solver_options.py          # 求解器参数统一配置
├── utils/
│   ├── data_loader.py             # 数据读取与单位统一
│   ├── convergence.py             # 收敛判定与迭代记录
│   └── visualizer.py              # 结果绘图
└── results/                       # 输出目录

每个模块的职责单一，没有把模型和求解逻辑混在一起。我最开始写的第一版代码就是所有东西堆在一个 main.py 里，改一个参数要找半天，后来花了半天时间拆成模块，之后做实验的效率完全不一样。如果你打算在这个基础上二次开发，建议保持这个分层：不要在处理数据的函数里偷偷建模型，也不要在模型里直接改求解器参数。

3.2 主流程：从配置文件到博弈收敛

程序入口 main.py 做的事情就是读取配置、加载数据、跑迭代、做分配、出图，一共八个步骤：

1. 读 config.yaml，解析运营商参数、用户列表、算法参数；
2. 调用 data_loader 读取负荷、光伏、电价数据，统一单位；
3. 创建 MarketOperator 实例和各用户的 Prosumer 实例；
4. 初始化24h电价序列，通常是峰谷平三段式或者统一一个初始值；
5. 进入Stackelberg迭代：固定电价，逐个求解用户优化问题；
6. 汇总用户购电需求，调用 operator.update_price() 修正电价；
7. 检查收敛条件：相邻两轮电价的最大绝对差小于阈值，或者达到最大迭代次数；
8. 收敛后调用 allocation 模块做合作剩余分配，输出报表和图表。

核心循环用伪代码表示就是这样：

python复制# main.py 核心片段（简化版）
for k in range(cfg.max_iter):
    demands = []
    for u in users:
        result = u.solve_optimization(price)
        demands.append(result.purchase_power)

    new_price = operator.update_price(
        demands=demands,
        price_old=price,
        step_size=cfg.step_size
    )

    price_gap = float(np.max(np.abs(new_price - price)))
    price = new_price
    iter_log.append(price_gap)

    if price_gap < cfg.tol_price:
        break

这段代码看起来简单，但有一个性能细节：第5步里每个用户求解都是独立的MILP，用Python的 multiprocessing 或者 concurrent.futures 可以并行执行。我们在N=20的算例里测试过，8核并行后单次迭代时间从30多秒降到6秒左右，整个博弈收敛大约需要20次迭代，总时间从10分钟降到2分钟，收益非常明显。

3.3 核心函数说明：价格更新、用户优化与收益分配

先看用户层。Prosumer.solve_optimization(price) 是整个程序中调用最频繁的函数，输入是一维电价序列，输出是一个包含购电功率、售电功率、SOC轨迹、总成本的结果对象。它的内部逻辑就是用Gurobi建一个MILP，目标函数和约束与2.1节描述的完全对应，典型代码结构如下：

python复制def solve_optimization(self, price):
    m = gp.Model(f"prosumer_{self.id}")
    p_buy = m.addVars(24, lb=0, name="p_buy")
    p_sell = m.addVars(24, lb=0, name="p_sell")
    soc = m.addVars(25, lb=self.soc_min, ub=self.soc_max, name="soc")

    m.setObjective(
        sum(price[t] * p_buy[t] - price[t] * p_sell[t] for t in range(24)),
        sense=gp.GRB.MINIMIZE
    )
    # 功率平衡、储能SOC递推、光伏约束、可平移负荷约束...
    m.optimize()
    return UserResult(purchase=p_buy, soc=soc, cost=m.ObjVal)

再看不收敛时最需要关注的函数 MarketOperator.update_price()。我这里用的是带阻尼的次梯度更新：

python复制def update_price(self, demands, price_old, step_size):
    agg_load = np.sum(demands, axis=0)          # 各时段总购电需求
    deviation = agg_load - self.target_load     # 与目标负荷曲线的偏差
    price_new = price_old + step_size * deviation / max(self.total_capacity, 1e-6)
    return np.clip(price_new, self.price_min, self.price_max)

看到这里你可能会问：target_load 哪来的？这是我在实际项目中加的一个人工设定，代表运营商希望用户呈现的“理想用电曲线”，比如削峰填谷后的目标。真实微网里这个目标曲线可以从日前负荷预测得到，也可以在迭代过程中动态更新。关键是这个偏差项让电价更新有了明确的物理方向：某时段总需求太高，就提高该时段电价；需求太低，就降电价，直到用户响应后的总负荷逼近目标。

收益分配函数的调用方式是这样的：shapley_allocate(users, coalition_cost_func, sampling=5000)，内部会按用户数自动选择精确枚举或蒙特卡洛近似。注意 coalition_cost_func 的签名是“给定一组用户ID集合，返回该联盟的总成本”，这跟 main.py 里已有的单用户求解逻辑复用了同一个底层模型，只不过约束条件里把多个用户的功率合并，储能容量共享。

4. 运行、调参与设计对照实验的完整流程

4.1 环境准备与数据文件格式

代码对环境的依赖不多：Python 3.9或3.10、Gurobi 10.x（或者换成pulp+CBC也能跑，只是大规模算例慢一些）、numpy、pandas、matplotlib、pyyaml。用conda建一个干净环境最省心，避免和项目环境互相污染。

数据文件格式要说清楚，因为这个环节最容易出低级错误。load_curve.csv 的每一列是不同用户的负荷曲线，每一行是不同时段；第一列是时间戳，格式推荐 YYYY-MM-DD HH:MM:SS，注意用本地时区，别存成UTC，否则后面画图会发现峰谷时刻全部偏移。pv_curve.csv 同样结构，列是各用户光伏出力，行是时段。grid_tariff.csv 是上级电网的分时购电价，两列：time 和 price。

我在 data_loader.py 里做了单位统一：外部CSV不管填的是kW还是MW，进去以后一律转成kW；电费不管填的是元/kWh还是分/kWh，一律统一成元/kWh。这个设计是从一次“灵异结果”中总结出来的——某次跑出来储能收益是负数，排查了半天发现是光伏数据单位是MW、负荷数据单位是kW，直接相加居然也能算出“结果”，只是结果完全错了。

4.2 关键参数表与调参建议

config.yaml 里暴露的参数不算多，但每个都很关键。下面这张表来自我自己的调参记录，照着这个范围设置可以省很多时间：

这里重点提醒两个参数：step_size 和 shapley_sampling。step_size 设太大，电价序列会来回震荡，呈现一种“始终不收敛但每轮结果都在变”的假象；设太小，收敛倒是稳了，但迭代次数可能翻倍。我从实验数据里看到的经验是，0.1是一个在大多数场景下表现均衡的起点，遇到震荡就减半，遇到太慢就适当加大。shapley_sampling 则要在计算时间和精度之间取平衡，5000次采样在N=20时大概多花一分钟，精度已经够写论文了，没必要贪多。

4.3 三组对照实验：不博弈、非合作、合作型

这套代码的一个核心价值是能快速构造三组对照实验，用来回答“合作到底带来了多少收益”。具体做法是：

第一组，无博弈基线。完全不用迭代求解，直接用电网给定的分时电价，每个用户独立求解自己的优化问题，最后把结果汇总。这模拟的是“没有运营商干预、大家各自为战”的场景。

第二组，非合作Stackelberg。跑完整的运营商—用户迭代，但最后不做合作收益分配，用户之间的共享储能、P2P交易等机制全部关闭。这对应的是“运营商有定价能力，但用户之间不合作”的场景。

第三组，合作型Stackelberg。在第二组基础上，打开合作联盟开关，运行结束后用Shapley值或Nash谈判做分配。这对应的是“既有主从定价，又有用户合作”的完整模型。

我最常用的对比指标是四个：系统总运行成本、用户平均成本、运营商净收益、负荷曲线峰谷差。三个场景跑完，把结果导成表格，合作型相比非合作型通常能降低5%~15%的用户成本，同时运营商收益不下降——这就是论文里常说的帕累托改进。如果你要写项目报告或论文，这组对比几乎是标配，因为审稿人一定想知道“合作机制到底是不是空架子”。

4.4 复现检查清单

跑代码之前，把这份清单过一遍，能免掉90%的低级报错：

• [ ] config.yaml 里 data_dir 指向的目录存在，且CSV文件列名与 data_loader 中约定一致
• [ ] 用户数量与 load_curve.csv、pv_curve.csv 的列数一致，用户ID能对上
• [ ] 所有CSV的时间戳长度等于 time_steps，且为连续间隔
• [ ] Gurobi许可正常，gurobipy 能正常导入
• [ ] 初始电价在 price_min 和 price_max 之间
• [ ] 储能初始SOC不为空，且落在 soc_min 和 soc_max 范围内

控制台输出中如果出现 Converged after XX iterations，说明博弈收敛，结果文件会生成在 results/ 下；如果打满 max_iter 还没收敛，优先调 step_size，而不是去改 tol_price。

5. 实测阶段最常踩的六个坑与对应的根因解法

5.1 价格震荡不收敛

这是我在迭代法里遇到的第一个大坑。现象很典型：前5轮电价还算正常，第6轮开始波动幅度越来越大，最后在高低价之间反复横跳，永远达不到收敛阈值。当时我先怀疑是模型写错了，查了很久才发现根本原因是用户响应太“刚性”：所有用户的储能策略在电价跨过某个阈值时会同时跳变，导致下一轮电价被过度修正，形成正反馈震荡。

解法就是上一章说的阻尼步长，但还有另一个更稳的做法：对电价更新做平滑处理，也就是本轮新电价取“上一轮电价0.7 + 修正量0.3”的组合。这相当于给迭代过程加了惯性，能有效抑制周期性震荡。还有一个辅助手段是限制每轮电价的单次最大变化幅度，比如单次调整不超过0.05元/kWh，防止单轮过度修正。

5.2 整数变量把求解器拖到超时

用户层一旦加入可平移负荷，模型里就有二进制变量，MILP的求解时间会显著上升。我们在N=20、24时段模型里测过，如果每个用户有3个可平移负荷，最坏情况下单用户求解时间可能超过10秒，Gurobi默认参数下某些节点甚至会出现“gap卡住不动”的情况。

我的处理办法分两步。第一步，把可平移负荷的约束写成“时间窗内最多启动一次”而不是“恰好一次”，给求解器更多松弛空间；第二步，设置一个合理的MIP Gap上限（比如1%），让求解器在工程可接受的精度下提前停止，而不是追求强最优解。大部分能量管理场景，1%的次优性换来90%的时间缩减，这笔账非常划算。

5.3 Shapley值枚举爆炸与空核

用户数超过12个之后，精确Shapley值基本不可用。枚举所有排列组合需要调用联盟成本函数 $N!$ 次，哪怕每次只算0.3秒，12个用户也要跑几个月。所以代码里默认超过10个用户就自动切到蒙特卡洛采样，这个设计是必须的，不是可选项。

另一个容易被忽略的问题是“空核”：某些场景下合作剩余是负的，也就是说“大家一起干”反而不如“各自单干”。这种情况听起来反直觉，实际中却会出现在用户负荷曲线高度相似、共享储能容量又不足的时候——合作没有带来实质的资源互补，反而因为约束增加抬高了成本。代码里对这种情况做了兜底：如果合作剩余小于等于0，直接跳过分配模块，输出提示“cooperation surplus is non-positive”，并自动退回非合作结果。这个逻辑你要保留，不要删，否则程序会因为在Shapley值计算里除以零或分配负数而报错。

5.4 Big-M数值病态

这个坑只有在你尝试把代码改成KKT单层重构法时才会遇到，但值得提前说。KKT条件中的互补松弛约束通常用Big-M法线性化，M值要是取得太大（比如1e6以上），求解器会陷入严重的数值问题，出现“收敛到明显错误的整数解”或者“不可行但约束单独检查都成立”的怪象。

我踩过最深的一次，是M取1e5时模型可解但结果完全不合理，调小到M=1000后问题消失。这不是运气问题，而是Big-M的取值应当与问题中实际出现的量级匹配——电价乘以功率的量级通常在几百到几千，M取1000左右就够用。如果读者确实要往KKT方向改，建议把M设置成与目标函数系数同量级的变量，而不是随意取一个很大的保守值。

5.5 单位与时区不一致造成的“灵异结果”

这个坑在4.1节已经提过，但我要再强调一次，因为它太隐蔽了。有一次跑完实验，发现某用户的储能策略竟然是“全天放电、从不充电”，储能SOC一路跌到下限，成本反而比不装储能的用户还低。查到最后，发现原因是光伏出力数据和负荷数据一个用MW一个用kW，程序在单位统一前的数据上直接做了功率平衡，等于凭空多出来好几倍的“免费电源”。

现在的代码里我加了单元测试，专门检查 data_loader 输出的最大值是否在合理范围（比如单户负荷不可能超过1000kW，光伏不可能超过装机容量的一倍），一旦超出阈值就抛出警告。这个习惯强烈建议保留：数据问题往往不会让程序崩溃，只会让你得到一份“看起来很合理的错误结果”，这种错误比报错更可怕。

5.6 可视化与结果输出的一些实用习惯

最后说点可视化经验。博弈迭代类代码的输出，最有价值的图是电价收敛过程图和用户响应曲线随迭代变化的对比图。前者用折线图展示每轮电价的24小时曲线，你会发现曲线从杂乱到平滑的过程非常直观；后者可以画成一个堆叠面积图，看每个用户的购电需求如何随着电价修正而改变。

这些图不仅是给自己调试用的，也是向不懂博弈论的人解释代码逻辑的最好工具。我给甲方做项目汇报时，从不先讲Shapley值公式，而是先放一张“没有合作VS有合作”的用户成本对比柱状图，再放一张电价迭代收敛曲线上来说明“这个结果不是拍脑袋定的，是市场博弈出来的”，对方一下就理解了。

另外建议在 results/ 目录里把每次实验的配置文件和结果CSV存成同一个批次号，命名格式类似 exp_20250124_N10_step01/，方便事后回溯。我吃过不归档配置的亏，一个跑了三天的实验，因为没有记录当时的参数，最后根本无法复现，只能重跑。代码本身再严谨，不配合好的实验记录习惯，照样出不了可靠的成果。