去年接了一个园区微网优化调度的项目甲方需求很直接运营方要能盈利但电价不能定得太离谱用户不能被赶跑同时在光伏出力不确定的情况下还要避免极端亏损。翻了一圈文献和内部参考方案真正把这几件事放在同一个框架里做的就是“基于合作型Stackelberg博弈与条件风险价值的微网动态定价优化调度策略”这一套思路。这个策略的核心并不复杂微网运营商作为博弈领导者先给出动态电价用户作为跟随者根据电价调整用电计划两边不是纯对抗关系而是把社会福利这个总蛋糕做大并且分得相对公平再用条件风险价值CVaR给不确定性上保险。这篇文章主要讲清楚几个问题主从递阶模型怎么搭、CVaR怎么嵌进去、双层问题怎么求解、动态定价和调度怎么联动以及我在实际项目里踩过的坑。适合正在做微网、园区综合能源、虚拟电厂方向的人参考也适合要写论文或者做方案设计的研究生借鉴。1. 先把标题“翻译”成大白话1.1 微网动态定价与优化调度到底在解决什么问题微网规模不大但五脏俱全光伏、储能、微型燃气轮机、各类负荷、与上级电网的交换功率运行约束条件和大电网完全不同量级。传统做法里定价和调度经常分开做运营方先根据负荷预测制定分时电价再在固定电价下安排机组出力和储能充放电。但这两个环节相互影响很深电价一变用户负荷就变负荷一变最优调度方案就变调度一变边际成本和网络约束又反过来影响电价该怎么定。把它们割裂开做出来的方案往往“看起来每步都合理整体上却互相打架”。这个标题把动态定价和优化调度并列本质上要求两者联合决策。微网运营商在决策时不仅要回答“储能几点充几点放、燃气轮机发多少电”还要回答“每个时段电费定多少才能让用户的响应结果正好配合我这边的运行计划”。这是一个典型的“先定价、再调度但调度结果反作用于定价”的耦合问题单靠人工经验和简单时序仿真很难处理必须建模成优化问题整体求解。1.2 Stackelberg博弈谁先报价谁跟着调整可以用下棋来理解Stackelberg博弈微网运营商是先手先把电价报出去用户是后手看到电价之后再调整用电计划。这个模型也被称为主从递阶博弈。标题里的关键词是“合作型”这一点非常关键。很多文献用的是非合作型博弈各方各自最大化自己的利益最后在市场均衡点达到一个勉强稳定的结果。但实操中问题很明显如果运营商只盯着自己的利润把电价定得非常高用户短期没得选只能忍着长期一定会选择退出、自建屋顶光伏或者转向其他供应商微网的运营基础就没了。所以合作型的处理方式是在上层目标里把用户效用或者社会福利部分放进去运营商在定价时主动兼顾用户剩余双方都在一个可持续的合作区间里寻求解。我在项目里具体是把用户侧的综合满意度、转移负荷的补偿成本都打包进上层模型相当于给定价加了一个约束框架而不是单纯“价格宰客”。1.3 CVaR条件风险价值给不确定性买一份保险光伏出力的随机性、负荷的波动以及现货市场电价的变化这些不确定性如果只取期望值做出来的调度方案往往在极端场景下非常脆弱。CVaR衡量的是收益分布里最差的那一部分的平均值它不是预测而是对风险的一种量化方式。举例来说某个方案在100个场景里可能有5个场景会亏损。VaR只看这5个场景对应的分位点数字而CVaR会把这5个场景的平均亏损算出来代表“真的发生小概率事件时平均亏多少”。放在微网调度里用CVaR做目标函数中的风险项就相当于在利润最大化的同时给极端亏损加了一个明确惩罚。它的好处不止是概念清晰更重要的是它满足一致性风险度量的公理体系数学上可以通过引入辅助变量转成线性约束这直接决定后续能不能用商用求解器高效求解。这一点在第三章会详细展开。2. 模型搭建的全过程从目标函数到约束条件2.1 主从递阶模型的总体架构建模第一步先明确谁是领导者、谁是跟随者以及双方通过哪个变量交互。我采用了两层结构。上层是微网运营商的决策包括零售电价、与上级电网的交互功率、储能充放电功率以及微型燃气轮机的出力。下层是多个用户聚合体每个聚合体接收电价信号后在用电效用与电费支出之间做权衡得到最优负荷曲线再把结果反馈到上层。交互变量就是一天96个时段的电价p_t和对应时段的负荷P_L,t。整个模型写成数学形式就是上层求解自身目标函数的最优值同时要求下层的负荷响应结果也包含在上层问题的可行解里。这就是一个典型的双层优化问题不能直接丢进求解器必须做等价转换。很多初学者在这第一步就容易遗漏一个关键点下层问题本身也是一个完整的优化问题有自己的目标函数和约束条件而不是一个简单的函数关系。所以在建模时下层用户的优化行为必须被完整地描述出来。2.2 上层目标函数利润、社会福利与风险成本的平衡我用的上层目标函数分三块运营利润、社会福利加权项、CVaR风险成本。运营利润等于售电收入加上向上级电网卖电的收入减去购电成本、燃气成本和储能运维成本。这块是运营方最关心的财务指标。社会福利加权项用用户效用减去用户购电支出来表示再乘一个权重系数ω这个ω可以理解为运营方对用户满意度的重视程度也对应标题里的“合作型”特征。风险成本就是CVaR项它对所有场景下的利润损失做尾部平均。最终上层目标写成简化形式max (1 - ω) * Π ω * SW - ρ * CVaR其中Π是运营利润SW是社会福利项ρ是风险厌恶系数。这里有个明显的权衡关系ω调大价格会更温和用户满意度高但运营方利润空间变小ρ调大策略更保守极端场景下的损失更小但正常场景下的利润也会略降。这两个参数都不是技术参数而是业务偏好的数学化表达后面做方案对比时很有用。2.3 下层用户模型效用函数与价格响应下层模型别做得太复杂否则上层求解难度会成倍上升。我的做法是把用户看作一个理性聚合体用一个二次凹效用函数U(P_L,t)描述用电带来的满意度常见表达是U(P) a * P - b * P²。给定电价p_t后用户求解max U(P_L,t) - p_t * P_L,t约束条件是P_L,t的可调范围和爬坡限制。由于目标函数是凹的一阶最优性条件可以直接给出P_L,t关于p_t的线性表达式这就是所谓的价格响应曲线。比较实用的是把可转移负荷和可中断负荷分开建模可转移负荷允许在时间轴上平移总用电量守恒可中断负荷直接削减但要带补偿成本。这两类负荷的价格弹性差异很大分开建模能让动态定价策略更贴合实际情况。2.4 CVaR的数学嵌入方式这一步要小心。运行场景集从历史数据抽样生成比如取200个光伏出力场景和负荷场景的组合然后对每个场景i计算运营利润R_i定义损失L_i -R_i。CVaR的计算可以写成CVaR ξ (1 / (N * (1 - β))) * Σ_i max(0, L_i - ξ)其中ξ对应VaR阈值β是置信水平N是场景数量。这个式子里有max函数直接放进目标函数是非光滑的。解决办法是引入辅助变量z_i ≥ L_i - ξ、z_i ≥ 0把max项线性化。这样一来ξ本身也是决策变量求解器会自动找到合适的分位点。推荐用辅助变量法而不是先排序再截取尾部均值原因是后者需要额外的排序逻辑和场景索引在优化模型里极难实现而辅助变量法可以直接嵌进线性规划框架里。这一步是整个模型能否用商用求解器高效求解的关键技术细节。3. 从双层到单层求解路径与工具选型3.1 为什么“双层迭代”不能直接交差很多初学者拿到这类问题的第一个想法是“上层定电价、下层算响应、再迭代循环直到收敛”。这个思路听起来合理但有两个致命问题。第一下层响应是上层的函数这种迭代本质上是逐次博弈。如果你不能证明映射是压缩映射迭代可能发散或者在两个解之间来回震荡根本停不下来。第二即便侥幸收敛了得到的往往也不是真正的Stackelberg均衡因为上层在迭代过程中只利用了下层当前的响应点而没有利用下层的完整理性行为信息。从工程稳定性和可证明性角度考虑我更推荐的做法是把下层问题用KKT条件完整替换转成单层的带均衡约束的数学规划问题MPEC再通过线性化处理成MILP交给商用求解器一次性求解。虽然模型规模会变大但求解的确定性、全局收敛性都更可靠。这里补充说明一下也有一些基于学习或启发式的方法能在特定条件下收敛但在项目交付的场景下我倾向于选择可解释性强、稳定性高的数学规划路线。3.2 KKT条件与互补松弛的线性化下层问题是凸二次规划时KKT条件是最优性的充要条件。具体写出来包含三组目标梯度条件、约束可行性条件、互补松弛条件。梯度条件给出p_t与P_L,t之间的关系这是上下层之间的桥梁。互补松弛条件形如λ * (P_max - P_L,t) 0其中λ是对偶变量。这里存在非线性乘积项需要用Big-M法做离散化对每一对互补变量引入布尔变量b写成λ ≤ M1 * (1 - b) P_max - P_L,t ≤ M2 * bM1、M2的取值需要斟酌。取太小会强行截断可行解导致求不出来最优解取太大则会让数值问题变多求解器容易在高斯消元过程中损失精度。我一般按模型中相关变量的上限的2到5倍来取先跑出来再渐进缩小这是排错的经验。完成后双层问题就变成带均衡约束的数学规划问题。如果再引入辅助变量处理双线性项整个问题可以转成混合整数线性规划MILP交由商用求解器处理。3.3 商用求解器与工具链选择我在这类问题上的选型很固定Python Pyomo Gurobi。少数大规模场景会换CPLEX。原因是Pyomo建模灵活度高写模型和跑场景比MATLAB YALMIP更容易维护Gurobi在MIQP/MILP上的求解速度和数值稳定性实测下来比开源求解器好太多。规模方面数万变量的双层转化模型商用求解器基本可以做到分钟内级别的求解完全满足项目迭代需求。开源求解器可以做小规模模型上的教学验证但项目交付我是不会用的稳定性不够时不时会出现数值警告碰上复杂约束很容易直接提示不可行排查起来非常头疼。代码框架可以按下面的思路写import pyomo.environ as pyo # 定义时间集合 T、场景集合 S model pyo.ConcreteModel() model.T pyo.Set(initializerange(96)) model.S pyo.Set(initializerange(200)) # 电价变量、负荷变量、储能SOC变量、辅助风险变量 model.price pyo.Var(model.T, bounds(price_min, price_max)) model.load pyo.Var(model.T) model.soc pyo.Var(model.T, bounds(0, ess_capacity)) model.xi pyo.Var() # VaR阈值 model.z pyo.Var(model.S, bounds(0, None)) # 尾部损失辅助变量 # 目标函数利润 社会福利 - 风险系数 * CVaR model.obj pyo.Objective( exprprofit_expr omega * welfare_expr - rho * (model.xi 1/(len(model.S)*(1-beta))) * sum(model.z[s] for s in model.S), sensepyo.maximize ) # CVaR约束 下层KKT近似约束 model.cvar_con pyo.Constraint(model.S, rulecvar_constraint_rule) model.kkt_con pyo.Constraint(model.T, rulekkt_condition_rule) # 调用Gurobi求解 solver pyo.SolverFactory(gurobi) results solver.solve(model, teeTrue)这个框架只是一个骨架实际项目里还需要加上互补松弛的Big-M约束、SOC递推约束、与上级电网交互功率约束等。先跑通这个骨架再逐步往下加细节排错会顺畅很多。4. 动态定价与调度策略的联动实操4.1 时段划分与初始电价生成别急着调参数先把典型日算清楚。我用的是96点建模也就是一天按15分钟一个时段。用历史负荷曲线做K-means聚类选出夏季典型日、冬季典型日、过渡季典型日在每个典型日里再按负荷水平和光伏净出力划分峰平台谷时段。初始电价以电网购电成本为基准峰时段乘2.0平时段乘1.2谷时段乘0.7作为博弈的初始策略。注意动态定价不是每个时段孤立定的还要考虑用户的价格弹性不能一步拉太大否则下层响应会剧烈波动。我在实际项目里对相邻时段电价变化率加了限幅约束要求不能超过15%这个约束能让电价曲线更平滑也避免用户看到跳崖式电价产生抵触心理。4.2 储能充放电如何与电价联动动态电价定下来之后储能就是最大的套利工具。正常情况下系统会在谷时段充电、峰时段放电充放电功率要与SOC约束、功率爬坡约束一起放进上层。实际操作中要特别注意SOC的初始值设定和日末SOC约束。我采用日末SOC与日初SOC一致的循环约束这样仿真结果才能跨天复用。如果只从利润角度出发储能会在峰时放电放到上限、在谷时充电充到上限形成“两充两放”的运行曲线这是正常现象。但加入CVaR之后储能策略会出现明显变化在不确定性高的时段预留电量。比如光伏大发的上午场景储能不会把电量完全放空会留一部分应对午后的云层遮挡导致光伏出力骤降。这种“预留”从单日利润角度看是次优选择从整个场景集的风险表现看却非常合理这正是风险度量嵌入优化目标的价值所在。4.3 仿真参数与结果维度给出一套参考配置光伏装机1.5MW储能容量2MWh充放电功率上限500kW充放电效率0.95微型燃气轮机额定容量800kW天然气成本按单位热量折算峰值负荷约1.2MW用户聚合为居民和商业两类。场景抽样方面取200个场景置信度取0.95风险厌恶系数从0到0.8变化。典型结果大致如下风险厌恶系数ρ正常运行日利润相对值5%最差场景平均利润相对值用户平均电费变化社会福利综合指数0100%-40%基准较低0.394%-25%略增中等0.587%-15%小幅增长较高0.879%-8%明显增长高可以清楚看到ρ从0调到0.5正常运行日利润只下降约13%但5%极端场景损失从正常利润的40%以内压到了15%以内。这就是拿CVaR做尾部风险管理的直观收益。如果只看期望利润会觉得ρ越大越亏但把尾部风险纳入评估后风险厌恶策略的价值就非常明显了。4.4 动态定价结果的具体呈现做完仿真后电价曲线通常呈现三个特征。第一峰时段电价被推高但不会高于用户自建光伏的平准化成本否则用户会流失这是合作型博弈模型的自然约束效果。第二谷时段电价贴近甚至低于购电成本运营商靠峰谷价差套利来补贴整体收益。第三当光伏出力波动大的时段电价会出现小幅上调目的是抑制需求、减少购电风险敞口。这些电价曲线的细节往往比总利润数字更有说服力。给甲方汇报时把不同ρ值对应的电价曲线放在一起对比对方马上能理解“风险偏好如何影响电价策略”这个抽象概念比讲一堆数学公式有效得多。5. 常见报错、坑点与排查实录5.1 求解器报“不可行”怎么办这个问题几乎每个人都会遇到。先不要急着改代码先用求解器自带的不可行性分析功能找出冲突约束集合。Gurobi支持IIS不可行性分析会列出导致冲突的最小约束集合。我遇到最多的是SOC约束和充放电功率约束同时松弛不够导致的问题。SOC上下限设为0到2MWh没有问题但初值1MWh加上最大充电功率再除以效率、日末又要回到1MWh在峰谷价差很大的电价场景下可能根本无法满足。解决办法是给SOC添加合理的运行范围先不放日末SOC等于初始值的硬约束跑出一版结果看SOC自然走向再把日末约束放宽为“日末SOC与初始SOC偏差不超过0.2MWh”。另一个常见原因是互补松弛中的Big-M取太小导致有效可行域被错误截断。这种不可行问题通过IIS很难直接看出来因为涉及的是3个以上约束的联合效应。排查思路是把Big-M统一放大5倍测试如果从不可行变成可行就是M值问题需要重新标定。5.2 风险系数和置信度怎么配置信度β一般取0.95这是学术和金融领域很常用的值但工程上不能盲目套用。如果实际光伏出力的极端场景特别明显比如多云天气下出力从额定值骤降到20%β取0.95意味着只看5%的最差场景可能刚好覆盖这几次极端情况。如果数据里正常波动较多、极端尾部不厚β取得过高会让模型对“罕见但影响不大”的场景过度反应白白牺牲正常场景利润。我的建议是项目初期用0.90看到尾部风险度量结果稳定后再调到0.95。风险厌恶系数ρ则不是调参问题而是业务偏好的数学化表达可以在方案评审时给出几个系数的对比结果让甲方选一个可接受的运行策略。这里不要替决策者做判断要提供选择空间。5.3 场景生成与数据泄漏问题很多人做场景抽样只对光伏出力做随机抽样忽略了负荷场景与光伏场景之间的相关性。光伏出力低时往往伴随负荷高如果场景抽样是独立的会合成出“光伏高且负荷低”的不真实场景导致CVaR低估实际风险。我处理方式是保留历史数据的联合分布按小时从真实历史记录里取组合作为样本或者用场景缩减算法把原始500个场景缩减到200个有代表性的场景。场景缩减可以使用同步回代算法具体细节不展开重点是要在缩减后对比一下缩减前后的分布差异而不能只看样本数量。这部分在项目里如果省略仿真报告会非常漂亮但实际部署的时候就容易出问题。我遇到过仿真结果很好、现场运行却出现意料之外亏损的情况后来复盘发现就是场景生成环节忽略了相关性导致的。5.4 双层模型的一种常见错误把下层目标当成上层约束看过几次别人写的代码把下层的一阶条件简化成“用户一定按最大效用点运行”然后把下层效用最大化直接设成上层约束。这种做法等于强行规定用户行为不给用户任何自主优化空间博弈结构就名存实亡了。正确做法是把下层优化问题完整写出来通过KKT条件或者强对偶理论把下层响应嵌入上层。如果下层模型规模太大导致求解困难可以考虑把用户按类别聚合成少量聚合体而不是逐个用户建模这样能保留博弈结构同时控制计算规模。针对这个错误我自己总结了一个检查清单看模型里是否存在“负荷变量既由上层决策又由下层决策直接设定”的情况如果存在说明博弈结构被破坏了。正常的处理应该是上层设定电价下层响应负荷上下层之间只有一个电价变量和一个负荷变量作为接口。5.5 数值稳定性Big-M取值与求解器精度最后一类坑来自数值稳定性。MILP求解器在求解大规模问题时如果约束系数跨度太大容易出现数值病态。比如变量范围从0.001到100000跨越了8个数量级求解器在做单纯形迭代时精度会崩溃。解决方案有两个方向。一个是对变量做归一化把功率、电量、价格等不同量纲的变量缩放到相近的数值范围。另一个是给Big-M和惩罚参数设置合理的边界不要为了确保可行性把M值设成一个非常大的数。我常用的做法是用变量的物理上限乘以一个2到5的系数作为M值。这样既能保证约束有效性又能最大程度减小数值问题。如果求解器给出“Numerical trouble”警告基本可以确定是M值过大或者约束系数跨度过大需要回头检查建模方式。6. 个人体会与后续扩展建议这套策略在实际项目里给我最深的感受是CVaR在初期阶段可能被当成“锦上添花”的数学技巧但真正遇到一次光伏大波动引发亏损事件后就知道这个尾部保险价值有多高。把它跟Stackelberg博弈放在一起两件工具互相补位博弈结构解决了“多方利益如何协调”的机制问题CVaR解决了“未来不确定时怎么做不后悔的决策”的风险问题。再分享一个小技巧不要一上来直接写带风险项的完整模型。先把风险权重置零、只留单场景把主从结构跑通再一层一层加场景和风险项排错会快很多。很多时候问题不是模型本身而是场景数据、约束条件、离散化参数混在一起出了错也定位不到源头。这个策略后续的扩展方向很多。可以加入储能寿命衰减模型让充放电策略更精细可以把多微网之间通过共享储能进行交易谈判纳入博弈框架也可以把电动车充电站作为一类特殊可调负荷接入通过动态定价引导充电行为。这些都是同一套建模框架上可以延伸的方向如果你正在做类似的微网项目建议先把这篇文章里的基础框架吃透再根据业务场景做扩展。