两阶段鲁棒微网调度优化：关键场景辨别算法加速CCG求解

做微网调度优化，最让人头疼的不是建模本身，而是“不确定性”。光伏出力随着云层飘过就能掉一大截，风电更是时大时小，负荷预测也不可能做到百分之百准确。这些不确定性直接冲击的，是“优化调度”四个字的含金量——你辛辛苦苦算出来的机组出力计划，往往在第二天一早的功率波动面前变得一文不值。

我之前在做微网能量管理系统时，最开始用的是确定性优化，后来发现调度方案在真实运行中经常需要大幅修正，甚至出现切负荷。于是转向鲁棒优化，最终落地方案是“两阶段鲁棒微网优化调度”，其中用来加速求解的“关键场景辨别算法”起了大作用。这篇文章把整套思路、模型构造、Matlab实现细节和调试心得完整捋一遍，适合正在做微网优化、新能源并网调度研究的研究生，也适合需要把鲁棒调度落地到代码里的工程师。

1. 核心模型结构与两阶段鲁棒优化框架

1.1 为什么微网调度必须上“两阶段”

先想清楚一件事：调度决策里，并不是所有动作都发生在同一个时间尺度上。

有些决策需要提前定下来，比如燃气轮机的启停状态、是否从主网购电的合同量。这些决策一旦定下来，在当天是不能随便变的，属于“看到不确定量之前就做好的承诺”。而另一些决策，比如储能充放电功率、灵活负荷的调节、紧急情况下的切负荷量，是可以在不确定性暴露之后根据实际光伏出力、实际负荷水平再调整的。两阶段鲁棒优化的核心，就是把这两类决策拆开：第一阶段做“事前决策”，第二阶段做“事后调整”。

这种结构与微网实际运行逻辑完全吻合。举个例子：第一天下午要做第二天的日前调度计划，光伏出力预测值只是一个区间，比如100MW到140MW之间。第一阶段先决定燃气轮机开几台、主网购电上限是多少；第二天早上光伏实际出力出来了，再根据真实情况调整储能充电策略、决定要不要弃一部分光。这就是典型的两阶段决策结构。

单阶段鲁棒优化不是不能做，但它把所有决策都压在“最恶劣场景”上，结果就是悲观到极点：可能为了应对一个发生概率极低的极端场景，让整个系统全天都在高成本运行。两阶段的好处在于，只有“必须提前定”的决策才对最恶劣场景负责，而“可以事后调”的决策只需要保证在最恶劣场景下有可行解即可，整体经济性会好很多。用生活类比来说，这就像出差前只订好机票和酒店这类“不可轻易改”的大项，到了当地再根据天气决定是去爬山还是逛博物馆，而不是提前把所有行程精确到小时。

1.2 不确定性集合怎么建

鲁棒优化里，不确定性通常不是用概率分布描述的，而是用一个“集合”来框定。微网里最主要的不确定性来源就是光伏出力、风电出力和负荷水平。

最常用的构造方式是盒式集合加预算约束。以光伏为例，预测出力是P_pv，实际可能的波动范围是[P_pv - ΔP, P_pv + ΔP]，ΔP一般取预测值的15%~25%。同理，风电和负荷也各自有一个波动区间。但如果三个不确定性源都同时取最极端值，在很多情况下过于保守，所以引入预算参数Γ，用来限制“一个时间段内最多有几个不确定性同时取极端值”，或者“所有不确定源偏离预测值的总幅度上限”。

Γ这个参数特别关键。Γ越大，系统应对不确定性就越保守，运行成本通常也越高；Γ越小，模型越“乐观”，成本低但风险大。实际操作时可以把Γ当作一个旋钮，扫描几组值对比成本曲线，再结合历史数据的波动幅度来选。有些文献管这种方法叫“预算不确定集”，它最大的优势是保持模型线性结构不变，不会引入非线性求解器，这对Matlab加YALMIP这套工具链非常友好。

1.3 两阶段鲁棒模型的整体数学描述

用公式化的语言来描述整个问题，大概是下面这个结构：

第一层是min，目标是第一阶段成本（机组启停、购电合同量）加上第二阶段运行成本的最大值。第二阶段内部是一个max-min结构：max是在不确定性集合中找一个最恶劣场景，min是在这个场景下找最经济的调整策略，调整包括储能充放电、切负荷、弃光、燃气轮机出力变化等。

这个max-min结构，是两阶段鲁棒调度最大的难点，也是后面要讲的关键场景辨别算法的用武之地。直接用商业求解器是解不了这种嵌套结构的，必须靠分解算法，最常见的就是CCG（列与约束生成）和Benders分解。CCG的思路是不断“找最恶劣场景→把对应约束加进主问题→重新求解主问题→再找更新更恶劣的场景”，一步步逼近最优解。关键场景辨别算法，本质上是给CCG这个循环加了一层“场景筛选与去重”的预处理逻辑。

2. 关键场景辨别算法到底在解决什么问题

2.1 传统CCG的迭代逻辑和痛点

先把传统CCG的运行机制拆开看。算法维护一个“关键场景集合”，初始时可能是空集或者包含一个最基准的场景。主问题是在当前场景集合下，求第一阶段决策和第二阶段调整的联合最优解。子问题则是固定第一阶段决策，在完整不确定性集合中寻找能让第二阶段目标函数最大的场景，这个场景就是“新发现的恶劣场景”。

找到新场景后，把它对应的第二阶段变量和约束一起加入主问题，进入下一轮。当主问题目标值不再明显上升，或者子问题找到的最恶劣场景已经无法让目标继续增大时，算法收敛。

这个流程在实际运行中有两个痛点。第一，每个子问题都要做一次max-min计算，即使做了对偶转换，内部还带着双线性项，求解运算量不小。第二，如果新场景与之前加入的场景高度相似，它对提升解的质量几乎没有帮助，纯粹是白算。很多时候CCG要迭代十几轮甚至二十几轮，不少轮次加进来的场景都是“换汤不换药”，主问题规模却越来越大，求解时间越来越长。

2.2 关键场景辨别策略的思路

关键场景辨别算法想做的事情很明确：在CCG每一轮迭代结束后，不去盲目追求“找到全局最恶劣场景”，而是从大规模候选场景池中筛选出一批“威胁度最高”的场景，一次性交给主问题处理，同时剔除那些与已有场景高度重叠、无法带来新信息量的场景。

具体实现思路分三步。

第一步是构建场景候选池。在不确定性集合中按一定的抽样策略生成大量候选场景。抽样方式可以是蒙特卡洛随机抽样，也可以是拉丁超立方抽样以保证覆盖均匀性。候选池规模一般在几百到几千个场景之间，视问题规模而定。

第二步是计算场景威胁度。固定当前主问题解出的第一阶段决策，对候选池里的每一个场景，快速评估该场景下第二阶段调整成本与第一阶段成本的合计值。这个评估不需要严格求解，可以先做一个LP松弛，或者只求解一个快速启动的线性子问题，把所有场景按目标值从高到低排序，取前K个作为这一轮的“关键场景”，K一般取3到8。

第三步是合并相似场景。对于选出来的候选关键场景，计算两两之间的欧氏距离，如果距离小于设定阈值，则只保留目标值更高的那个。这样能有效防止主问题被几乎重复的约束撑大。

这个流程跑完，相当于每一轮CCG迭代都同时加入多个“有代表性”的恶劣场景，而不是只加一个最优场景。收敛速度通常会有明显提升。我在实现里，还额外加了动态K值策略：迭代前期K取大一点，快速压缩不确定空间；迭代后期K缩小，避免主问题规模过度膨胀。实测下来，这个策略对求解时间的影响比我想象中还大。

2.3 算法的适用边界

关键场景辨别算法不神奇的，它本质上属于“CCG加速器”。如果原来的CCG每次迭代只需要两三轮就收敛，那这个算法收益不大；如果迭代次数经常在十轮以上，尤其是不确定性集合维度高、场景之间差异小、最恶劣场景频换的情况，效果就非常明显。

另外要注意，由于关键场景辨别算法是用抽样加启发式筛选代替了“全局最恶劣场景”的严格搜索，理论上它有可能漏掉真正的最恶劣场景。解决方法是保留校验环节：算法收敛后，用完整的子问题做一次严格验证，如果发现未覆盖的更恶劣场景，再补一轮CCG。这样既保证了鲁棒解的可靠性，又大幅减少了无效迭代。

3. Matlab实现：从数学模型到可运行代码

3.1 环境与工具链

我的实现环境是MATLAB R2022b，建模用YALMIP，求解器用Cplex 12.10。Gurobi也能跑，两者的YALMIP接口都很成熟，差别不大。如果是学生或没有商业求解器授权，可以考虑用SCIP或开源的HiGHS，但对于混合整数规划为主的微网调度问题，Cplex和Gurobi的求解速度优势还是很明显的。

安装上没什么好说的，YALMIP需要放到MATLAB路径下，然后运行sdpvar、optimize这些函数不报错就说明装好了。有个小坑：YALMIP对求解器版本有一定要求，如果出现“No suitable solver”报错，先检查求解器接口有没有装全，Cplex的Matlab接口需要在Cplex安装目录下手动执行install_matlab脚本。

3.2 主问题的YALMIP建模

主问题包含了第一阶段决策以及所有已知恶劣场景下的第二阶段决策和约束。代码结构大致如下：

matlab复制% 第一阶段变量
z_g = binvar(n_gen, 1);          % 机组启停
P_import = sdpvar(1, 1);         % 主网购电合同量

% 第二阶段变量（针对已识别的场景）
P_ess = sdpvar(n_ess, K, 'full');       % 储能充放电
P_g = sdpvar(n_gen, K, 'full');          % 机组出力
P_curtail = sdpvar(n_pv, K, 'full');     % 弃光量
P_load_cut = sdpvar(n_load, K, 'full');  % 切负荷量

% 目标：第一阶段成本 + 不同场景下第二阶段成本
objective = f_daily(z_g, P_import);
for k = 1:K
    objective = objective + scenario_cost_k(P_g(:,k), P_ess(:,k), ...
                                            P_curtail(:,k), P_load_cut(:,k));
end

% 约束：每个场景独立满足功率平衡、储能约束、机组爬坡约束等
Constraints = [];
for k = 1:K
    Constraints = [Constraints, power_balance(..., scenario_set(:,k))];
    Constraints = [Constraints, ess_constraints(P_ess(:,k), ...)];
    Constraints = [Constraints, gen_constraints(P_g(:,k), z_g, ...)];
end

optimize(Constraints, objective, sdpsettings('solver','cplex','verbose',1));

关键点在于，每个已知场景对应一套独立的第二阶段变量，它们通过同一个第一阶段变量z_g和P_import串联起来，这也是“两阶段”在代码层面的具体形态：第一阶段变量是所有场景共享的，第二阶段变量是各个场景私有的。

3.3 子问题求解与对偶处理

子问题要处理的是max-min嵌套结构。YALMIP对这样的嵌套结构没有直接的求解接口，通常需要先对内部的min问题做KKT条件或强对偶转换。

我最开始用的是强对偶转换的思路：固定第一阶段决策后，内部min问题本质上是一个LP，LP满足强对偶条件，可以转化为其对偶问题。这样max-min结构就变成max-max结构，即一个单层的最大化问题。但转换后目标函数里会出现对偶乘子乘以不确定变量的双线性项，这是最棘手的部分。处理方式一般是引入Big-M进行线性化：假设不确定性变量u有界，对偶乘子λ也有界，引入辅助变量z替换λ·u，并用λ的上下界、u的上下界构造M的约束。

Big-M的选取要格外小心。M取得太大，数值稳定性会变差，求解器容易出现“数值病态”；M取得太小，解空间会被错误裁剪，得到的结果不可靠。我通常先用一个较大的初始M，求解后检查辅助变量与λ·u之间的差值，如果不满足容差再调整M。

如果不想处理对偶和Big-M，还有一种更工程化的替代做法：只枚举不确定性集合的顶点。对盒式集合加预算约束的情况，顶点数量是有限的，虽然组合数可能不小，但配合剪枝和控制枚举规模，在微网这种中小规模问题上完全可行。枚举顶点后，每个顶点都能单独计算第二阶段最优目标值，取最大的那个就是最恶劣场景。这种做法牺牲了一点数学上的华丽，但胜在稳妥、调试方便。我在最终落地的代码里，默认方案就是“顶点枚举 + 快速剪枝”，只有当顶点数量爆炸时才切回对偶加大M。

3.4 外层CCG加关键场景辨别的迭代流程

整体迭代流程的伪代码如下：

matlab复制% 初始化
scenario_pool = generate_pool();       % 生成候选场景池
critical_set = initial_scenarios();    % 初始关键场景集合
LB = -inf; UB = inf;
gap = 1;

while gap > tol
    % 1. 求解主问题
    [x_first, obj_mp] = solve_MP(critical_set);
    LB = obj_mp;
    
    % 2. 计算当前解在各候选场景下的目标值
    threat_list = zeros(length(scenario_pool), 1);
    for i = 1:length(scenario_pool)
        threat_list(i) = evaluate_scenario(x_first, scenario_pool(i));
    end
    
    % 3. 排序并筛选关键场景
    [sorted_val, idx] = sort(threat_list, 'descend');
    K_select = adaptive_K(iter);
    selected_idx = deduplicate_scenarios(idx(1:K_select));
    
    % 4. 检查收敛
    if sorted_val(1) - obj_mp < tol
        UB = sorted_val(1) + obj_mp;
        break;
    end
    
    % 5. 将筛选出的场景加入主问题
    critical_set = [critical_set, scenario_pool(selected_idx)];
end

这里有几个小细节值得提一下。evaluate_scenario这一步，为了省时间，内部可以做LP松弛，而不是完整求解MILP，威胁度排序的准确性得到一定保证就够用了。deduplicate_scenarios里我用的是简单阈值判定，阈值取各维度不确定量标准差的0.2倍，实测中能把相似场景合并掉20%~30%，别小看这一步，它让主问题的场景数量增长速度慢了不少，每一轮迭代的求解时间都因此受益。

4. 算例验证与结果分析

4.1 测试系统与参数设置

为了验证算法效果，我搭了一个典型的微网测试系统：光伏装机100MW，风电装机50MW，负荷峰值80MW，储能容量30MWh、最大充放电功率10MW，燃气轮机单机容量20MW、共2台，与主网的交换功率上限40MW。不确定性只考虑光伏、风电和负荷，波动范围分别取预测值的±20%、±30%、±10%，预算参数Γ取4。

调度周期为24小时，时间间隔1小时，这意味着一共有24个时段。候选场景池用拉丁超立方抽样生成200个场景，初始关键场景取预测场景本身。

4.2 结果对比

在相同参数下，我用三种方式做了对比：纯确定性调度、传统CCG两阶段鲁棒调度、关键场景辨别算法加速的两阶段鲁棒调度。结果如下表：

确定性调度成本最低，这是意料之中的，但它对负荷削减没有任何防御能力，一旦实际场景偏移较大就会出现失负荷。两阶段鲁棒的运行成本比确定性高13%左右，这就是“鲁棒性代价”。关键场景辨别算法算出的总成本与传统CCG基本持平，差别只有0.2%不到，说明它没有因为筛选场景而明显牺牲解的质量。

真正让我惊喜的是求解时间。传统CCG要迭代14轮，花费186秒才收敛；关键场景辨别算法4轮就稳定了，总耗时61秒。原因很直观：传统CCG每一轮只加入一个最恶劣场景，遇到场景彼此贴近的情况，后面几轮基本在“原地打转”；而关键场景辨别算法每一轮主动加入多个差异化的关键场景，相当于把三轮叠成一轮跑，收敛自然快得多。

4.3 灵敏度分析

我又扫描了预算参数Γ和关键场景选择数量K的影响。Γ从0逐渐增加到8时，系统运行成本从50.1万元上升到58.7万元，基本呈单调递增，但递增速度在Γ大于4之后变缓，说明系统的不确定性风险已经主要被前几个维度的极端场景覆盖了。

K的影响更值得关注：K从1增加到4时，迭代轮数和总时间都明显下降；K继续增加到8后，单轮主问题求解时间增加，总时间反而开始反弹。这说明K不是越大越好，关键场景数量超过某个阈值后，主问题规模的负面效应会盖过迭代轮数减少的收益。结合测试结果，我把自适应K策略设置为K = min(4 + floor(iter / 2), 8)，前两轮用较小的K，后续根据收敛情况缓慢增加，效果最稳定。

5. 常见问题与调试实录

5.1 子问题求解太慢

我在第一版实现里，对每个候选场景都做一次完整LP求解，200个候选场景跑一轮要两分多钟，整个算法被拖得很慢。后来改成先做LP松弛评估威胁度，只对威胁度排名前15的场景做完整求解，时间立刻降了一个量级。排序阶段不需要精确解，这是很重要的一个工程思维：粗筛用便宜的方法，细评才用贵的方法。

5.2 Big-M数值问题

对偶转换加Big-M线性化时，初期使用M=10000导致求解器警告numerical trouble，检查发现辅助变量出现了不合理的取值。后来把M缩到500，并开启Cplex的数值清洗选项，问题消失。经验是：Big-M能取多小就取多小，最好根据物理量纲估算上限，比如电压、功率、价格的合理范围就是M的自然上界。

5.3 场景去重把好场景删了

在某种边界情况下，去重阈值设得过大，导致两个目标值接近但物理位置不同的场景被合并，后续迭代又绕回来，浪费了两轮。解决方式是去重时优先保留“与已有关键场景距离最远”的场景，而不是目标值最高的场景，这样能更好地维护场景集的多样性。这个小改动让我少踩了很多坑。

5.4 收敛间隙设多少合适

我最初用0.01作为收敛间隙，结果迭代速度快但解质量不够，子问题校验时发现还有2%的改进空间。后来改成0.001，迭代多了一轮但解稳定了。工程化建议是：先用1e-3跑通流程，最后做输出校验时再用1e-4精算一次。别上来就设1e-6，不然光等迭代就够受的。

6. 一些实操总结

两阶段鲁棒微网调度的难点从来不在建模，而在于把模型“算得快、算得稳”。关键场景辨别算法给我的最大启发是：与其每次都卯足劲找全局最恶劣场景，不如让一堆“差不多恶劣”但彼此有差异的场景早日进场，用更少的迭代次数逼近同一个答案。这和项目管理很像——关键不是找到最坏的那天，而是保证任何一个“坏日子”来了，方案都还有调整的余地。

如果后续想扩展，可以在这个框架里加入数据驱动的模糊集，用历史数据修正不确定性边界；也可以把关键场景辨别算法换成学习类方法，用强化学习直接生成初始关键场景集，给主问题一个更好的起点。这些方向都能在现有Matlab代码的基础上继续演进。至少从我目前的项目情况看，这套实现已经完全够用。