计及风光不确定性的两阶段鲁棒优化与C&CG算法实现-代码聚汇网

计及风光不确定性的两阶段鲁棒优化与C&CG算法实现

两阶段鲁棒优化C&CG算法电力系统调度

|难度：普通|阅读约 31 分钟

两阶段鲁棒优化这几年在电力系统调度里几乎成了绕不开的"标准动作"。只要一提到风电、光伏、负荷的不确定性，随口能说出来的方法基本就是两阶段鲁棒加C&CG算法。我最初接触这个问题时也犯过嘀咕：明明确定性优化简单得多，随机规划看起来也更"精确"，为什么大家偏偏喜欢鲁棒优化？后来在微电网日前调度项目里把方法真正跑通后，才算理解了这套组合拳的价值所在。

这篇文章就用"计及风、光、负荷不确定性两阶段鲁棒优化"这个题目为引子，把从建模、大M法处理、C&CG算法求解，到Matlab+YALMIP代码实现的全链路拆一遍。适合正在做电力系统优化调度、微电网能量管理、综合能源系统研究的硕博研究生，以及刚入门鲁棒优化的工程技术人员。文章不会只贴公式，我会把每一步设计的逻辑、迭代过程中容易踩的坑、代码骨架和调试技巧都讲清楚。

1. 为什么两阶段鲁棒优化成了调度问题的标配

1.1 风光负荷不确定性的三个来源

风电出力和光照强度本身是随机过程，负荷侧也有大量预测误差。我们做调度时，常规做法是拿一组预测曲线去做确定性优化，但预测曲线只是实际曲线的"期望"，一旦第二天实际风光出力偏离预测值较大，之前排好的机组出力和联络线计划就可能不可行，严重的还会导致切负荷或弃风弃光。

这类不确定性有三个典型来源：

风电出力：受风速随机性影响，分钟级到小时级的波动都很大，尤其早晚时段风向风速切换频繁，功率曲线偏离预测值十几个百分点是很常见的事。
光伏出力：受云层遮挡影响，辐照度短时骤降可以带来光伏出力断崖式下跌，这是最考验系统应对能力的场景之一。
负荷需求：用户行为变化、温度波动、节假日效应，都让负荷预测带有误差，尤其高峰时段的负荷预测偏差影响更大。

三类不确定性叠加后，确定性优化方案的鲁棒性短板就更明显了。鲁棒优化的基本思路就是：我不去猜这些不确定量的具体概率分布，我只要求它们落在一个合理的波动区间内，然后在这个区间里找"即使在最坏情况下也能保证安全运行"的决策。

1.2 两阶段决策逻辑：先把能定的定了，剩下的留给实时

两阶段体现在决策时间尺度的分离。"两阶段"其实对应的是两类决策变量：

第一阶段变量（here-and-now决策）：在不确定性实现前就要确定的量。典型代表是机组启停状态、储能是否参与充放电、外网购电/售电计划等。这些是0-1变量或整数变量，一旦定了当天很难改。
第二阶段变量（wait-and-see决策）：不确定性实现后，系统运行人员做出的调整量。典型代表是各机组实际出力、储能充放电功率、弃风弃光量、切负荷量等。这些是在知晓实际风光出力后，通过经济调度实时确定的。

这样分解之后，优化问题天然形成"主从递阶"结构：第一阶段定方案，第二阶段在方案基础上做最坏情况下的最优响应。这正是两阶段鲁棒优化模型的决策框架。

1.3 确定性优化、随机优化与鲁棒优化怎么选

很多新手一上来就在纠结：用确定性优化加个旋转备用不就够了吗？为什么要上两阶段鲁棒优化？这个问题我觉得得从问题本身的容忍度去看。

确定性优化的缺陷在于，旋转备用容量是人为定的，定多了浪费，定少了又扛不住极端场景。随机规划（比如场景法）虽然考虑了概率分布，但需要精准的分布信息和大量场景采样，计算量大，而且分布估计错了，结果反而不稳定。

鲁棒优化走的是"保底路线"：我不管你实际落在哪里，只要不越出事先定义的不确定集，我的决策就能保证系统安全运行。它给出的解往往偏保守，但计算复杂度远低于带概率分布的场景法，而且对分布信息的要求低很多。对电力系统这种安全性要求极高的场合，"保底"比"期望最优"更有吸引力。实际工程里，调度人员的核心诉求永远是"无论如何不能出事"，这也解释了两阶段鲁棒优化在微电网和配电系统调度中成为主流的根本原因。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 两阶段鲁棒优化模型怎么搭

2.1 不确定集：盒式区间就是最常用的"鲁棒边界"

不确定集是鲁棒优化模型的灵魂。工程上最常用也最好处理的是盒式不确定集，也就是把每个不确定参数限制在一个区间内：

code复制P_w^t ∈ [ P_w_pre^t - ΔP_w^t , P_w_pre^t + ΔP_w^t ]
P_pv^t ∈ [ P_pv_pre^t - ΔP_pv^t , P_pv_pre^t + ΔP_pv^t ]
P_load^t ∈ [ P_load_pre^t - ΔP_load^t , P_load_pre^t + ΔP_load^t ]

其中 P_w_pre、P_pv_pre、P_load_pre 是预测值，Δ 是允许的最大偏差。盒式不确定集的好处是表达简单、对偶变换容易，且工程上"功率落在预测值加减一定百分比内"这个假设很直观，容易跟调度人员沟通。

如果想控制保守程度，还可以用预算不确定集（Budget-based uncertainty set），限制所有时段的总偏差不超过某个预算值，避免24个时段同时取到最坏值——这在实际系统中几乎不发生。但从代码实现角度看，盒式集是最容易起步的，等盒式集跑通了，再扩展预算约束也不难。

2.2 第一阶段模型：机组组合与日前计划

第一阶段要确定的是日前设备状态和外购电计划。以微电网为背景，典型的第一阶段约束包括：

机组最小启停时间约束：机组不能频繁启停，一旦开机就必须连续运行若干小时，停机同理。
机组启停状态与出力上限耦合：只有开机状态的机组才允许出力大于0。
外网购电上限约束：与上级电网的交换功率不能超过联络线容量。
储能状态初始条件：第一天开始时的储能SOC。

第一阶段的成本主要包括机组启动成本、空载成本、外购电基础费用等。这些都是"先决策后观察"的成本，在目标函数的第一个min里体现。第一阶段变量的0-1特性，也让该问题成为一个MILP（混合整数线性规划）问题，这为后续使用C&CG算法埋下了伏笔。

2.3 第二阶段模型：最坏场景下的经济调整

第二阶段是给定第一阶段决策后，在具体不确定性场景下，系统通过调整机组出力、储能充放电功率、弃风和切负荷等手段，实现该场景下的运行成本最小化。典型约束包括：

功率平衡约束：发电机出力+光伏出力+风电出力+储能放电+外购电 = 负荷+储能充电+弃风弃光。
机组出力上下限约束：不能超过装机容量。
储能SOC动态约束：充放电功率受SOC上下限和充放电倍率约束。
弃风弃光约束：弃风弃光量非负，且不超过当前可用风/光出力。
切负荷量约束：切负荷量不超过当前负荷需求。

第二阶段成本通常是该场景下的运行费用：机组增量燃料成本、储能充放电损耗、弃风弃光惩罚成本、切负荷惩罚成本。其中弃风弃光和切负荷的惩罚系数往往设得很大，因为正常运行状态下系统尽量不弃、不切，只有当不确定性非常极端时才允许发生。

2.4 完整目标函数：min-max-min结构的直观理解

把两阶段合并起来，模型可以写成这样一个紧凑形式：

code复制min  F1(x) + max_{u∈U} min_{y∈Ω(x,u)} F2(y)
s.t. A x ≤ b
     Ω(x,u) = { y | D y ≥ E u + F x + g, y ≥ 0 }

这个目标函数看着吓人，拆开理解其实很简单：

外层min对应第一阶段的日前计划成本。
中间max是"大自然"在不确定集里挑最坏场景。
内层min是系统在最坏场景下做最优调度。

整个问题翻译成人话就是：我先做一个日前决策，然后假设明天天气和我对着干，专门把风光负荷调到一个对系统最不利的状态，在这个状态下我再以最低成本进行实时调整。这样一个三段结构，就是两阶段鲁棒优化的标准形态。

需要强调的是，第二阶段变量的存在让系统具备"应激能力"，所以鲁棒优化不会给出一个完全死板的方案，而是"提前布局+事后调整"的组合策略。这也是两阶段模型相对单阶段鲁棒优化更贴近实际的原因。

3. C&CG算法与大M法：把双层问题打回单层

3.1 C&CG的核心思想：主问题不断吃进"最坏场景"

两阶段鲁棒优化是典型的NP-hard问题，直接求解非常困难。工程上主流的解法是C&CG（列与约束生成，Column-and-Constraint Generation）算法。它的核心思路是"先猜后验证"：

先在一个只有有限场景的松弛主问题（MP）里求解第一阶段决策；
固定这个决策，去子问题（SP）里找最坏场景；
如果最坏场景对应的成本让松弛问题界不收敛，就把这个场景的约束和变量一股脑加入主问题；
反复迭代直到上下界差满足容忍度。

C&CG和经典的Benders分解思路很像，但有一个本质区别：Benders分解往主问题里加的是割平面约束，是"对偶信息"；C&CG往主问题里加的是完整场景的原始约束和变量，相当于把最坏场景整段"复制"进主问题。这带来的直接好处是，C&CG的割平面更紧，收敛速度通常远快于Benders，尤其对包含0-1变量的问题，优势更明显。

3.2 子问题对偶化：max-min变max-max

子问题SP是给定第一阶段解后的max-min问题：

code复制SP:  max_{u∈U} min_{y∈Ω(x,u)} F2(y)

这个形式里max和min套在一起，求解器没法直接处理。把内层的min对偶成max，问题就变成了max-max，两个max合并后就是一个普通的单层优化问题：

code复制SP对偶形：max_{u∈U, λ≥0}  λ^T ( E u + F x + g )
s.t. 对偶可行域约束： λ^T D 与成本向量满足对偶可行性

这样SP就变成了一个单层max问题，可以直接丢给求解器。对偶变换是整个C&CG求解链中最容易出错的一步，因为原始约束矩阵D要逐项搬运，符号方向、变量类型都要仔细核对。我的习惯是对偶完成后先用一个小规模算例验证SP对偶前后的目标值是否一致，确认无误再做迭代求解。

3.3 大M法到底用在哪两个地方

大M法在这个求解流程里出现频率很高，新手经常搞混。我梳理下来，典型场景有两个：

第一个场景：在采用KKT条件把SP转成单层问题时，互补松弛条件是非线性约束，需要引入0-1变量和大M常数，把"λ_i ≥ 0，且某条不等式松弛量为0"这种逻辑关系线性化。常见做法是：设某条原始约束为 h ≥ 0，引入0-1变量 z，写为：

code复制λ ≤ M * z
h ≤ M * (1 - z)
λ ≥ 0, h ≥ 0

这样当 z=0 时，λ被压成0；当 z=1 时，h被压成0。M的取值必须大于λ和h可能达到的上限，否则会排除可行解。

第二个场景：第二阶段模型中如果继续包含0-1变量（比如储能充放电状态、可中断负荷削减状态），那么对偶就不能直接进行，需要先把整个SP看成混合整数规划的内层，用KKT条件整体替换内层min，而KKT中逻辑约束的线性化同样离不开大M法。

另外一个常见误区是：有些教程把大M法说成"线性化双线性项uy"的手段。没错，如果离散的0-1变量和连续变量相乘，确实要用大M线性化；但两阶段SP对偶后一般不会出现uy这种双线性项，所以别一上来就找双线性项在哪，而应该先问自己：内层min能不能直接对偶？如果不能，是因为什么变量类型卡住了？这样定位大M用武之地的思路才是对的。

3.4 C&CG迭代流程与收敛判据

完整C&CG迭代流程可以总结为下面几步：

初始化：令下界LB=-∞，上界UB=+∞，迭代次数k=1，初始最坏场景集S为空。
求解主问题MP，得到最优解(x_k, η_k)，更新下界LB = max(LB, 主问题最优值)。
固定x_k，求解子问题SP，得到最坏场景u_k和SP最优值R(x_k)，更新上界UB = min(UB, F1(x_k) + R(x_k))。
如果(UB - LB) / UB ≤ ε（比如1e-3），停止迭代，输出最优方案。
否则，把新场景u_k对应的第二阶段变量y_k和约束加入主问题，k=k+1，回到步骤2。

这里有个细节：每次加入主问题的不仅仅是约束，还要新建一套第二阶段变量y_k。也就是说主问题里会出现多组y变量，每组对应一个场景。随着迭代次数增加，主问题规模会线性增大，所以C&CG的收敛速度直接决定了可求解问题规模的上限。实测下来，一般10节点以下的小系统，3到8次迭代就能收敛到1e-3的gap，性能是相当可观的。

4. Matlab代码实现与调试全过程

4.1 工具箱与求解器配置

Matlab下面做这个，最稳妥的组合是YALMIP+Gurobi，或者YALMIP+CPLEX。YALMIP负责建模，求解器负责算MILP。用YALMIP而不是手写对偶矩阵，是因为两阶段鲁棒优化里MP和SP都要反复重构，YALMIP的符号建模能省掉大量矩阵维度的低级错误。

先说求解器。Gurobi在学术圈和工业界都很好用，许可证申请方便，CPLEX是老牌求解器，稳定性极佳。如果都没装，直接跑YALMIP命令会报"no solver found"之类的错误。建议装完后在Matlab里执行 yalmiptest 检查工具箱与求解器是否识别成功。

代码结构上，我建议分为四个文件组织：

main_TSRO.m：主程序，设置参数、调用迭代流程、输出结果。
build_MP.m：构建主问题模型，输入场景集，输出求解结果。
build_SP.m：构建子问题模型，输入第一阶段解，输出最坏场景和目标值。
data_input.m：所有系统参数，包括机组参数、负荷/风光预测曲线、不确定度、惩罚系数。

这样组织的好处是：迭代循环改起来很方便，主问题和子问题各自独立，后续想换成Benders分解或者加预算不确定集，改动范围都控制在单个文件内。

4.2 主问题构建的代码骨架

主问题MP在第一次迭代时只包含初始约束，后续每轮迭代追加一个场景的约束。用YALMIP写代码骨架大致是这个风格：

matlab复制% 第一阶段变量
x_start = binvar(n_gen, 1);      % 机组启动状态
x_on    = binvar(n_gen, T);      % 机组运行状态
P_g     = sdpvar(n_gen, T);      % 机组计划出力
eta     = sdpvar(1, 1);          % 第二阶段最坏成本辅助变量

% 初始约束
Constraints = [];
Constraints = [Constraints, x_start == 0]; % 示例：初始状态约束
for t = 1:T
    for g = 1:n_gen
        % 出力上下限与机组状态耦合
        Constraints = [Constraints, P_g(g,t) <= P_g_max(g) * x_on(g,t)];
        Constraints = [Constraints, P_g(g,t) >= P_g_min(g) * x_on(g,t)];
    end
end

% 每次迭代追加的场景约束
for k = 1:num_scenarios
    y{k} = sdpvar(n_var_y, T);   % 第k个场景的第二阶段变量
    % 追加该场景下第二阶段可行性约束
    Constraints = [Constraints, A_y * y{k} >= E_u * U_scn{k} + F_x * [x_start; x_on(:); P_g(:)] + g_const];
    Constraints = [Constraints, y{k} >= 0];
end

% 目标函数
Objective = f1_cost + eta;

% 求解
ops = sdpsettings('solver', 'gurobi', 'verbose', 0);
optimize(Constraints, Objective, ops);

% 提取结果
x_start_val = value(x_start);
P_g_val = value(P_g);
LB = value(Objective);

核心就是每个场景k都新建一组y变量，然后在目标函数里把第二阶段最坏成本用eta这个辅助变量去逼近。这个eta就对应两阶段鲁棒模型里的 max_{u∈U} min_{y∈Ω} F2(y) 的值。

4.3 子问题对偶后的代码骨架

子问题SP固定了第一阶段决策。直接把内层min对偶后，写成单层max问题，代码骨架如下：

matlab复制% 固定第一阶段决策
x_fixed = value(x_on);
P_g_fixed = value(P_g);

% 不确定变量（盒式不确定集）
u_w  = sdpvar(n_wind, T);
u_pv = sdpvar(n_pv, T);
u_L  = sdpvar(n_load, T);
for t = 1:T
    Constraints_SP = [Constraints_SP, P_w_pre(t) - delta_w(t) <= u_w(t) <= P_w_pre(t) + delta_w(t)];
    Constraints_SP = [Constraints_SP, P_pv_pre(t) - delta_pv(t) <= u_pv(t) <= P_pv_pre(t) + delta_pv(t)];
    Constraints_SP = [Constraints_SP, P_L_pre(t) - delta_L(t) <= u_L(t) <= P_L_pre(t) + delta_L(t)];
end

% 对偶变量
lambda = sdpvar(n_dual, 1);   % 对偶变量，维度与第二阶段不等式约束数一致

% 对偶目标函数
Objective_SP = lambda' * (E_u * [u_w(:); u_pv(:); u_L(:)] + F_x * [x_fixed(:); P_g_fixed(:)] + g_const);

% 对偶可行域约束
Constraints_SP = [Constraints_SP, D_dual * lambda <= F2_cost_vector];
Constraints_SP = [Constraints_SP, lambda >= 0];

% 求解
optimize(Constraints_SP, -Objective_SP, ops);   % 注意：max问题要取负号
R_value = value(Objective_SP);
u_worst = [value(u_w), value(u_pv), value(u_L)];

对偶目标函数里的E_u矩阵会作用于全部时段的不确定变量，所以维度要提前算清楚，最好用矩阵拼装而不是手写每个时段的对偶约束。我最初写的时候就是矩阵维度没对齐，导致SP值忽大忽小，非常难排查。

4.4 迭代循环与结果收敛

主循环的写法很简单，关键在收敛判断和场景追加：

matlab复制UB = 1e9;
LB = -1e9;
gap = (UB - LB) / abs(UB);
scenario_set = [];
k = 0;

while gap > 1e-3 && k < 20
    k = k + 1;
    % 1) 求解主问题
    [x_val, P_g_val, LB] = solve_MP(scenario_set);
    
    % 2) 固定x求解子问题
    [R_k, u_worst] = solve_SP(x_val, P_g_val);
    
    % 3) 更新上界
    UB = min(UB, F1_val + R_k);
    
    % 4) 更新gap
    gap = (UB - LB) / abs(UB);
    
    % 5) 将最坏场景加入场景集
    scenario_set{end+1} = u_worst;
    
    fprintf('Iter=%d, LB=%.2f, UB=%.2f, Gap=%.4f\n', k, LB, UB, gap);
end

这里有一个容易踩的坑：LB不能只取当前主问题目标值，而要和历史LB做max比较，因为主问题每次追加场景后可行域变紧，目标值只增不减。UB同理，要和历史UB做min比较。如果把这个逻辑写错，gap会变成负数，迭代就直接乱套。

收敛速度方面，以6节点微电网系统为例，10台风电机组、2个光伏电站、3台柴油机组加1台储能，我实测几乎都能在5次迭代内收敛到gap小于1e-3。如果超过10次还没收敛，大概率是SP对偶有bug，或者是M取值不当导致可行域被错误收缩。

5. 常见问题与工程化避坑

5.1 子问题对偶出错：你怎么知道是对的还是错的

对偶出错是两阶段鲁棒优化实现中最常见的bug来源之一。症状表现为：迭代过程中UB和LB交替上涨，gap长时间不收敛，或者干脆SP出现infeasible。

我强烈建议在正式起C&CG迭代之前，先做一个"对偶正确性校验"：随机取一个第一阶段可行解，用暴力枚举一百组不确定场景，一组组对第二阶段做min优化，取最大值；再把固定该第一阶段解后的SP对偶问题求解，比较两个值。如果误差在1e-4以内，说明对偶式子写对了；如果对不上，按模块逐个核对约束系数、变量符号和常数项。

这种方法看似笨重，但对鲁棒优化这种动辄几千行约束的代码来说，是最快定位问题的手段。

5.2 大M取值玄学：取小了错，取大了病

大M法里的M取值不当，是最折磨人的工程问题。M取太小，会错误地砍掉可行区域，导致最优解被排除；M取太大，求解器数值稳定性会崩溃，出现荒谬的决策结果。

我的建议是分两步：先给M一个理论估计，再逐步缩小。理论估计的思路是：对每个互补约束，预估对偶变量可能的上界，以及原始约束松弛变量可能的上界，取更大的值。实际操作时，我通常从1000、5000、10000这几个档位各跑一次，对比最优成本和迭代次数，如果结果对M的取值不敏感，说明取值合适。

对于盒式不确定集且系统规模不大的问题，M取1000到5000是常见的经验区间。如果系统里有储能或长时间跨度的约束，M适当调大，但尽量不要超过1e6，超过后Gurobi容易出现numerical issues的警告，这时候宁可换约束写法，也不要继续上调M。

5.3 迭代慢、发散的问题定位

C&CG迭代发散，首先要检查是不是场景集重复添加了同样的约束。如果SP求出的最坏场景和之前某轮完全相同，而SP目标值却比之前小，说明SP的构建依赖了不可靠的数值状态，比如某个变量没有被正确固定，还是自由变量；或者对偶变量维度不对，导致SP目标函数漏掉了一部分成本项。

另一个常见原因是：主问题里第一阶段变量和第二阶段变量耦合太松，导致MP给的方案非常"乐观"，而SP又总能找到很高的最坏成本，上下界来回跳动。这时可以在MP的第一阶段约束里追加一些逻辑性更强的限制，比如把机组最小出力约束和启动状态绑定起来，能明显改善收敛。

5.4 数值问题与约束缩放

电力系统模型天然存在量级差异：机组出力可能是MW级（几百到几千），惩罚成本可能是元/MWh（几十到几千），而SOC约束里可能出现0.001这种小数。这些差异累积下来，会让求解器陷入数值困难。

我处理数值问题的心得是：统一量纲，把功率全部转换为标幺值或p.u.，没有条件的话，至少把目标函数里的成本和功率系数缩放到同一数量级。另一个技巧是在求解器设置里打开数值稳定选项，例如Gurobi的 NumericalFocus 设为2或3，尽管会稍微拖慢求解速度，但能避免很多莫名奇妙的不可行解。

还要补充一个细节：C&CG的收敛阈值不要设得太苛刻。1e-3相对工业应用已经足够，硬要追求1e-6反而可能在敏感性极强的问题里难以收敛，白白消耗时间。我自己在项目中通常用5e-4到1e-3的gap值。

5.5 快速参考：问题-原因-对策速查表

现象	可能原因	排查与解决
SP求解报infeasible	对偶约束写错、M取值过小	先做随机场景对偶校验；逐步调大M
LB和UB差距持续波动	第一阶段变量未正确固定	检查SP里固定x的value值传递
迭代超过10次不收敛	SP目标函数漏项	核对E_u矩阵维度和系数
求解器报数值警告	量级差太大	统一量纲，开启数值稳定选项
主问题规模爆炸	场景集重复增长	增加去重判断，避免添加相同场景

我个人在实际调试中的体会是，两阶段鲁棒优化的代码实现，60%的时间花在模型构建和矩阵维度对齐上，只有30%的时间花在迭代算法本身，剩下10%是调参和数值优化。把每一个矩阵的维度都写清楚、每一处对偶关系都验证过，即使第一次跑出来的结果不理想，也能很快定位到问题出在哪个模块，而不是像无头苍蝇一样到处改代码。

最后再分享一个小技巧：如果C&CG初次跑通后，你想跟Benders分解做对比，不需要重写大框架，只要把主问题追加场景约束的部分改成追加Benders割，并修改UB更新逻辑即可。两套算法共用了90%的代码，对比实验很容易实现。这也是一开始就把主问题、子问题模块化设计带来的最大好处。