基于主从博弈的电动汽车充电调度MATLAB实现与KKT求解

前一阵帮一个做小区微电网的朋友优化充电桩调度策略，他把一堆需求丢过来的时候，我第一反应就是：这典型是个主从博弈问题。为什么这么说？因为小区充电管理天然存在两层决策者——物业或者售电代理商定电价，车主根据电价决定什么时候充、充多少。两边利益不一致，但又互相影响，这种“你先出牌、我跟着响应”的结构，用主从博弈（Stackelberg Game）来建模再合适不过。这篇就把整套MATLAB实现思路和代码细节拆开讲清楚，从博弈模型搭建、KKT条件转化，到yalmip求解和结果分析，一条龙捋一遍，适合正在做电动汽车充电管理、需求响应、电价策略方向研究，或者毕业设计想找个完整案例参考的同学。

1. 整体设计与思路拆解：为什么是主从博弈

主从博弈又叫斯坦科尔伯格博弈，核心思想就是“领导者先动，跟随者后动”。放到智能小区充电场景里，代理商是领导者，电动汽车车主是跟随者。代理商先公布一个分时电价，车主看到电价之后，根据自己的充电需求和出行安排，决定最优充电计划。代理商再根据车主的响应结果，调整自己的定价策略，直到两边都达到各自的最优状态。

这个结构比单层优化更贴近现实。如果只用传统的经济调度模型，假设车主一定会按照调度指令充电，这在现实中根本不成立——车主不是电网的从属设备，人家有自己的出行刚需，你电价定得不合理，人家完全可以选择错峰、甚至去外面充。主从博弈的优势就在于，它把车主的自主决策行为显式建模进去了，代理商不能“直接命令”车主，只能通过“价格信号”间接引导。

换个更好理解的说法：这就跟打车平台调价一个逻辑。平台（领导者）先定一个动态加价比例，司机（跟随者）看到加价之后决定接不接单、跑不跑这个区域。平台不能强制司机去哪儿，只能用价格杠杆引导。小区充电博弈也是这么个味儿。

还有一点值得说，代理商的定价策略和车主的充电决策在时间尺度上也是不一样的。代理商定电价一般是提前一天或者提前几个小时公布，属于“日前决策”；车主看到电价后再规划充电时段，属于“日内响应”。这种决策时序本身就是天然的分层结构，用主从博弈建模，从模型结构上就和实际问题对齐了。

1.1 博弈模型的两个层级

上层是代理商，目标函数很直接：最大化自己卖电的净利润。收入来自卖给车主的电费，成本是从上级电网买电的花费。约束条件包括售电电价上下限、变压器容量限制、总供电量平衡等。

下层是每个电动汽车车主，目标是让自己的充电费用最小化，同时要保证“出发之前电池电量够用”。约束条件包括电池容量上下限、充电功率上限、充电时长约束、充电站数量限制等。

这里有一个很关键的技术点：上层和下层不是平等联立的，而是嵌套的。下层问题的最优解，是上层问题的约束条件。也就是说，代理商在做决策的时候，必须把车主的“最优反应函数”考虑进来——我定这个价，车主会怎么应对，我得提前算清楚。这就是主从博弈和一般多目标优化的本质区别。

1.2 为什么选MATLAB而不选其他工具

做这类双层优化，工具选择其实挺有讲究。Python也有成熟的生态，Gurobi的Python接口也很好用，但我个人在这个项目里还是选了MATLAB，理由有三：第一，MATLAB的yalmip工具箱把优化建模这件事简化了很多，尤其是涉及到双层问题的KKT转化时，yalmip可以直接操作约束条件；第二，电力系统领域很多数据预处理、负荷曲线分析、结果可视化，MATLAB一套全搞定，不用来回切换语言；第三，大部分做这个方向的研究生和工程师，手里最熟的仿真工具就是MATLAB，代码可读性和可复制性更强。

当然，底层求解器还是得外接。yalmip只是一个建模层，真正算优化问题的是Gurobi或者Cplex这类商业求解器。MATLAB负责建模和数据处理，求解器负责算，这个组合是当前学术界和工业界最稳定的搭配之一。

1.3 与其他算法方案的对比

有的朋友可能会问：这种问题能不能用启发式算法，比如粒子群、遗传算法来解？当然能。实际上早期很多文献就是用粒子群解上层、用二次规划解下层，两层之间来回迭代。但这种方法的缺点也很明显：计算量大，收敛性没法保证，而且每次迭代都要重新求解下层问题，参数稍微调不好就陷入局部最优。

相比之下，我在这套代码里走的路线是“下层问题用KKT条件替换，把双层问题转化为单层数学规划，然后线性化处理”，最后直接扔给MILP求解器，一次求解搞定。这条路线的数学基础更扎实，求解效率高，结果也有全局最优性保证（至少是给定离散变量条件下的全局最优）。唯一的难点在于KKT条件的推导，以及互补松弛条件线性化时引入大M参数的设置——这块后面详细说。

2. 核心数学模型与参数设计

这一节是整套代码的理论基石，也是我当初最花时间啃的一块。先把数学模型完整摆出来，然后一步步讲清楚为什么要这么建。

2.1 上层代理商优化模型

代理商的决策变量是每个时段的售电电价 [ \lambda_t ]。目标函数是最大化总利润，表达式写作：

上层模型的决策变量：每个时段t向电动汽车用户售电的电价λ_t

目标函数：

[ \max \sum_{t=1}^{T} \left( \lambda_t \cdot P_{EV,t} - c_t^{grid} \cdot P_{buy,t} \right) ]

其中，( P_{EV,t} ) 是所有电动汽车在时段t的总充电功率，这个是下层问题的解，也就是车主的反应函数；( c_t^{grid} ) 是代理商从上级电网购电的分时电价；( P_{buy,t} ) 是代理商在时段t从电网购买的总电量。

约束条件：

[ \lambda_{\min} \le \lambda_t \le \lambda_{\max} ]

这是售电电价的上下限约束，也是监管方给的“价格天花板”。

[ P_{buy,t} = P_{base,t} + P_{EV,t} ]

其中 ( P_{base,t} ) 是小区基础负荷（非充电负荷），这保证供需平衡。

[ 0 \le P_{buy,t} \le P_{trans,max} ]

变压器容量约束，不能超载。

2.2 下层用户充电模型

每个车主 i 的决策变量是自己的充电功率 ( P_{i,t}^{EV} )。目标函数是充电费用最小化：

[ \min \sum_{t=1}^{T} \lambda_t \cdot P_{i,t}^{EV} \cdot \Delta t ]

约束条件：

电池电量状态（SOC）随时间递推：

[ SOC_{i,t+1} = SOC_{i,t} + \frac{P_{i,t}^{EV} \cdot \Delta t \cdot \eta_{ch}}{E_i^{cap}} ]

其中 ( \eta_{ch} ) 是充电效率，( E_i^{cap} ) 是电池容量。

充电功率上下限：

[ 0 \le P_{i,t}^{EV} \le P_{i,\max}^{EV} ]

电池SOC安全范围：

[ SOC_{i,\min} \le SOC_{i,t} \le SOC_{i,\max} ]

出行充电需求约束（走之前必须充到目标电量）：

[ SOC_{i,t_{dep}} \ge SOC_{i,target} ]

这个约束非常关键，它保证了车主不会因为贪图便宜电价而一直不充电。

2.3 从双层到单层：KKT条件的妙用

双层模型直接求解非常困难，因为上层要知道下层的最优反应，而下层的解又是上层决策的函数。标准的做法是：由于下层问题是凸优化问题（线性规划），我们直接写下它的KKT条件，把它替换成上层问题的约束。这样“下层最优”这个隐含要求，就变成了显式的数学约束，整个问题就变成了单层优化。

KKT条件包括四部分：

• 拉格朗日函数关于充电功率的梯度条件（一阶必要条件）
• 原始可行性条件
• 对偶可行性条件
• 互补松弛条件

前三个都是线性表达式，直接加进约束就行。麻烦的是第四个——互补松弛条件。它长这样：

[ \mu \cdot g(x) = 0 ]

其中 ( \mu ) 是拉格朗日乘子，( g(x) ) 是不等式约束的左边表达式。这个条件是非线性的（两个变量的乘积等于零），没法直接扔给线性求解器。

常规解法是引入二进制变量和大M参数，把互补松弛条件线性化。逻辑是：

[ g(x) \le M \cdot z ] [ \mu \le M \cdot (1-z) ] [ z \in {0, 1} ]

当 ( z=1 ) 时，( g(x)=0 )，约束起作用；当 ( z=0 ) 时，( \mu=0 )，约束不起作用。M取值必须足够大，但又不能大到破坏数值稳定性，这个尺度的把握很需要经验。我在代码里对不同的约束取了不同的M值，比如功率约束的M取100 kW，SOC约束的M取100%，电量约束的M取100 kWh，这样能有效避免因M过小导致的约束丢失，或者M过大导致的病态数值。

2.4 双线性项的线性化：强对偶定理撑腰

把下层KKT条件代入上层之后，上层目标函数里又出现了一个新的非线性项：( \lambda_t \cdot P_{EV,t} )。这是两个变量相乘，属于双线性项，同样不是线性求解器能直接处理的。

我当时在这里卡了一段时间，后来查文献发现标准做法是用强对偶定理来消掉它。对下层问题来说，在最优解处，原始目标函数值等于对偶目标函数值。基于这一点，可以把 ( \lambda_t \cdot P_{EV,t} ) 这一项用下层问题的对偶变量和目标函数表达式替换掉。

具体来说，所有包含 ( \lambda_t \cdot P_{i,t}^{EV} ) 的双线性项，最终可以被替换为关于对偶变量、固定参数和目标函数值的线性表达式。这个替换在数学上是严格成立的，也是整个转化中让我觉得最精妙的一步。

做完这两步线性化之后，整个主从博弈问题就变成了一个标准的混合整数线性规划（MILP），直接用Gurobi或者Cplex求解即可。我当时第一次成功跑通模型的时候，看到Gurobi输出了“Optimal solution found”，说实话很有成就感——一个看起来很复杂的博弈问题，经过几步数学变换，最终落到了一个成熟求解器能轻松拿下的形式。

3. MATLAB代码实现与关键模块解析

理论讲完，来点实际的。这一节把整套代码的框架和关键模块逐段拆开，所有代码都基于MATLAB 2022b + yalmip + Gurobi 10.0环境测试通过，完整工程文件可以分享。

3.1 代码总体框架

整个工程按功能模块划分成以下几个文件：

文件名一看就懂，每个模块干一件事，方便复用和修改参数。

3.2 主程序框架

主程序的核心是设置参数、调用各模块、求解、展示结果。关键参数包括：

%% 清空环境 clear; clc; close all; %% 基础参数设置 T = 24; % 调度周期，24小时 dt = 1; % 时间步长，1小时 num_ev = 60; % 电动汽车数量 % 电动汽车参数 SOC_init = 0.2 * ones(num_ev, 1); % 初始电量 SOC_target = 0.9 * ones(num_ev, 1); % 目标电量 E_cap = 40 * ones(num_ev, 1); % 电池容量，kWh P_ev_max = 7 * ones(num_ev, 1); % 最大充电功率，kW eta_ch = 0.92; % 充电效率

这里我设置的是60辆电动汽车、每辆车40 kWh电池容量、最大充电功率7 kW（典型家用慢充水平）。之所以不做更复杂的异质参数，是因为初版代码保持整齐的参数矩阵更利于调试，验证逻辑没问题之后，再改成每个用户独立的随机参数也不迟。

3.3 下层问题的KKT条件推导与代码实现

下层问题是核心，也是最容易出错的地方。我先把每辆车的下层问题写成一个紧凑的线性规划，然后推导KKT条件。

首先定义优化变量：充电功率 ( P ) 和每个时段的SOC。注意，SOC是一个状态变量，由初始SOC和充电功率决定，所以在KKT推导时它和功率的递推关系也要一并处理。

KKT条件的一阶梯度条件如下：

% 构建下层问题的拉格朗日函数并对P求导 % 得到梯度条件约束导入上层模型 for i = 1:num_ev for t = 1:T if is_charging_allowed(i, t) % 该时段允许充电 Constraints = [Constraints, lambda(t) - mu_Pmax(i,t) + mu_Pmin(i,t) - mu_SOCmax(i,t+1)*eta_ch/E_cap(i) + mu_SOCmin(i,t+1)*eta_ch/E_cap(i) - mu_env(i)*eta_ch/E_cap(i) == 0]; end end end

这里每个拉格朗日乘子对应底层的一个约束：mu_Pmax对应功率上限，mu_Pmin对应功率下限，mu_SOCmax和mu_SOCmin对应SOC上下限，mu_env对应出行需求约束。这个梯度的推导过程，需要把SOC递推表达式代入约束，再对充电功率求偏导，整个过程复杂度是比较高的，稍有不慎符号就反了。

3.4 互补松弛条件的大M线性化

拿功率上限约束来举例。原始互补松弛条件是这样：

% 互补松弛条件：mu_Pmax * (P_max - P) == 0 % 用大M法线性化 for i = 1:num_ev for t = 1:T if is_charging_allowed(i, t) z_Pmax = binvar(1, 1); % 引入二元变量 Constraints = [Constraints, P_ev(i,t) >= P_ev_max(i) - M_P * (1 - z_Pmax), % 当z=1时，P等于上限 0 <= mu_Pmax(i,t) <= M_mu * z_Pmax]; % 当z=0时，乘子为0 end end end

注意，这里我把原始约束 ( P \le P_{max} ) 改写成了 ( P \ge P_{max} - M_P(1-z) ) 的形式，和标准KKT推导里的互补松弛条件严格对应。这个细节我在初版代码里写反过一次，结果求解出的充电方案在边界处出现了微小违约，肉眼几乎看不出来，但SOC曲线在个别时段会出现不连续跳变，后来检查约束矩阵才发现这个问题。

M参数的取值要经验丰富。取小了，可能直接把可行域切掉一块，导致求不出最优解；取大了，求解器数值容易出现精度警告。实际操作中我的做法是：先用一个小M跑一次，观察求解器警告日志，再逐步加大，找到一个“刚刚好”的临界值，通常比实际物理量的最大可能值大2~3个数量级就够。

3.5 求解器配置与调用

yalmip建模完，求解这一步很关键。完整的求解设置如下：

%% 设置求解器 ops = sdpsettings('solver', 'gurobi', ... % 指定求解器 'verbose', 2, ... % 显示求解过程 'debug', 1); % 调试模式打开 %% 求解 result = optimize(Constraints, Objective, ops); %% 检查求解结果 if result.problem == 0 disp('求解成功，找到最优解'); elseif result.problem == 1 disp('求解器返回无界或不可行，请检查约束'); else disp(['求解出错: ', result.info]); end

debug参数在调模型阶段务必要打开。有一次我花了三个小时查一个无解问题，最后发现是某个时段充电功率上限设成了0，导致一辆车在规定时间内无论如何也充不到目标电量，问题不可行。如果不开debug，这种逻辑错误很难发现。

4. 仿真结果分析与参数敏感性

模型跑通之后，结果分析才是真正检验模型合理性的环节。我这里挑几个典型结果进行详细解读，帮助大家判断自己的代码是否也跑出了合理的效果。

4.1 电价与充电功率的联动关系

仿真输出的分时电价曲线，和基础负荷曲线呈现明显的正相关关系。峰值时段（晚上19:00-22:00）电价被抬高，谷值时段（凌晨1:00-5:00）电价被压低。这符合代理商最大化利润的逻辑——“负荷越拥挤，充电服务费越贵”。

电动汽车充电功率响应的效果也很明显：大部分车辆的充电时段集中在凌晨低谷时段，这正是电价信号的引导结果。但值得注意的是，并非所有车辆都转移到低谷充电，因为有些车第二天一早要出门，SOC目标约束锁死了它们的充电时段窗口，哪怕电价高，也得在晚间充一部分。

这个结果在模型验证上很有价值：如果所有车辆都集中到低谷充电，那反而说明模型没有正确刻画车主的差异化出行约束。真实场景一定是“大部分人响应电价，小部分人因为刚性需求不得不高价充电”。

4.2 SOC曲线的合理性检验

看SOC曲线是一个快速验证模型逻辑是否正确的办法。合理的SOC曲线应该满足：

• 所有车辆的SOC始终在设定上下限之间（不越界）
• 每辆车的SOC在离家时刻之前增长到目标值（需求满足）
• SOC曲线没有异常的跳变或突变（递推关系正确）

如果在结果图里看到某辆车的SOC曲线出现了“先上升、再下降、然后又上升”的情况，大概率是充电功率约束和SOC递推关系之间存在逻辑问题，回头去检查is_charging_allowed这个判断条件的逻辑。

4.3 代理商利润与车主意愿度的平衡

一个值得关注的输出指标是代理商的净利润和车主的平均充电费用。这两个指标是矛盾的：代理商想赚更多，车主想花更少。主从博弈找出的均衡点，恰恰在这两者之间取了一个数学上的“折中”。

调试时可以看到一个很直观的现象：如果把电价上限 ( \lambda_{max} ) 从1.2元/kWh提高到2.0元/kWh，代理商利润会上升，但车主的充电费用也跟着涨，更关键的是，部分车主会选择“不充电”或“少充电”，导致总充电量下降，代理商的总利润反而可能下滑。这个“一价端的提高不一定带来利润上升”的反直觉现象，正是主从博弈模型中“跟随者反应函数”的直观体现——这就是为什么你没法简单地“拍脑袋定高价”。

4.4 重要参数的敏感性分析

我做了一组对照实验，记录不同参数下的关键指标变化：

车数增加时，充电需求总量变大，代理商可调度的“资源池”变大了，利润随之上升，同时因为调度弹性更大，车主平均费用反而略降——这个结果说明规模效应对代理商是友好的。电池容量增大时，车辆的充电时间窗口变宽，车主不必着急在某个时段猛充，响应价格信号的自由度更大，代理商反而失去了“垄断加价”的能力。充电功率上限减半时，每辆车充满电所需时段变长，部分车辆因为充电时间不够，无法参与谷时电价响应，只能被迫接受更高的电价，代理商利润因此下降。

这些敏感性分析不仅在学术上验证了模型的合理性，在实际工程中也是做定价策略方案时非常有价值的参考——比如物业公司在决定是否扩容变压器之前，就可以用这个模型预判扩容带来的充电需求变化和利润变化。

5. 实操经验：常见问题与调试技巧

从模型搭好到最终跑通，我踩了不少坑，这一节把最常见的问题和排查思路整理出来，这些都是文档里不会写的实操经验。

5.1 求解器报“Infeasible”（不可行）时的排查思路

这是yalmip + Gurobi组合最常遇到的问题。当你看到gurobi: Infeasible problem时，按以下顺序排查：

第一步，检查每辆车的SOC初值和目标值之间的可行性。如果SOC_init为20%，目标90%，电池容量40 kWh，那么需要充28 kWh电。如果充电功率上限7 kW，充电效率0.92，那么需要的最短充电时间是28/(7*0.92)约等于4.35小时。如果在允许充电的时段里凑不出4.35小时的窗口，模型必然无解。

第二步，检查变压器容量约束。所有电动汽车同时充电的功率总和加上基础负荷，必须小于变压器上限。60辆车同时7 kW充电就是420 kW，如果变压器上限只有250 kW，不可行是必然的。

第三步，检查allow charging的状态矩阵。初期做代码时，很容易因为时间窗口设置不合理，导致某辆车在允许充电的时段内根本充不满。

5.2 求解时间过长怎么办

MILP的求解时间和二元变量个数强相关。每个互补松弛条件都需要一个二元变量，下层约束越详细，二元变量就越多，求解时间指数上升。

如果求解时间超过10分钟，优先考虑这几种优化手段：

第一，将对称的同类型车辆聚合成一组，用一个代表性车辆的决策代替一组相同参数的车辆。10辆完全相同的车可以做等效聚合，决策变量直接缩减为1/10。

第二，合理排除“绝对不可能起作用”的互补松弛条件。比如在某个时段，某辆车的SOC离上限还很远，那么这个时段的SOC上限约束对应的互补松弛条件就可以直接去掉，节约二元变量。

第三，调大Gurobi的MIPGap参数。ops.gurobi.MIPGap = 0.01;让求解器在1%的差距内提前返回次优解，工程应用中完全够用，但求解时间可能缩短一个数量级。

5.3 yalmip版本和求解器连接问题

我遇到过很多人拿旧版yalmip，求解器装上了也一直报找不到Gurobi。yalmip不是MATLAB自带的，需要从官网下载并将文件夹添加到路径。Gurobi也要在MATLAB里执行gurobi_setup来配置环境。有两个细节：

Gurobi的版本和MATLAB版本有兼容矩阵，不要盲目装最新版。MATLAB 2022b配Gurobi 10.0左右最稳。装好之后，在命令行窗口输入yalmiptest，看到gurobi: Found那一栏，才算真正配置成功。

5.4 一个容易忽略的细节：时间步长的设置

这套模型的调度周期是24小时、时间步长1小时。但如果你要研究的是“中午午休时段临时充电”这类场景，1小时的步长就不够精细了。调成15分钟的话，每个时段的最大充电功率要做相应折算，电池SOC递推公式里的dt参数也要同步修改。我自己在扩展实验中发现，时间步长从1小时改为15分钟后，模型求解时间翻了约3倍，但电价曲线和充电方案会更精细——尤其是对峰谷交替频繁的时段，效果改善明显。

5.5 双层问题的调试技巧：先解下层，再解上层

整套模型跑通之前，先单独验证下层的正确性。方法是：固定一组任意的电价参数，单独求解每辆车的充电优化问题，检查结果是否满足所有约束、SOC曲线是否合理。这一步通过后再加入上层，构建完整的博弈模型。分层调试能帮你快速定位问题出在哪一层，而不至于在两层耦合的复杂错误里迷失方向。

我当时调试时就是这么干的：第一步，只跑一辆车、固定电价、两个时段，手算验证结果是否正确；第二步，扩展到一辆车、24时段；第三步，多辆车、固定电价；第四步，完整博弈。每一步都用简单的参数手算验证，确保逻辑无误再进入下一步。这套方法论不仅适用于这个项目，我后来做其他双层优化问题时也在沿用。

6. 后续扩展：从理论研究到工程落地

模型能跑通只是一个起点，这套代码的框架扩展性很强，几个方向我认为特别值得延伸。

6.1 考虑电动汽车入网放电（V2G）

把车主从“只充电”的受端扩展为“可充可放”的双向参与者，下层模型中加入放电决策变量，目标函数变成最小化充电成本减去放电收益。主从博弈的结构不变，但下层问题的可行域会扩大，KKT条件的推导也会更复杂。V2G模式下，车主在电价峰值时段卖电给代理商，代理商再把峰时段的电卖给其他用户——这个模式能同时提高代理商利润和降低车主费用，但需要支付给车主的放电补偿，用当前模型框架就能很自然地扩展出来。

6.2 多代理商竞争模型

把单一代理商扩展为多个代理商，分别服务不同的小区或不同区域的充电桩。代理商之间形成纳什博弈，代理商与车主之间仍是主从博弈。从单领导者单跟随者扩展为多领导者多跟随者，需要引入均衡约束优化框架，求解难度会明显上升，但模型更贴近真实市场竞争环境。

6.3 考虑风光不确定性

如果小区里装了光伏和风电，其出力天然具有随机性。可以用场景法或者鲁棒优化来描述不确定性：在不同风光出力场景下分别求解博弈模型，再通过期望值或者最坏情况的鲁棒目标函数决策最终电价。这个方向对于降低弃风弃光率、提高新能源消纳能力有实际意义。

我为什么说这套代码框架“值得留好”？因为只要你把底层模型、KKT转化、线性化套路吃透了，无论未来怎么加约束、换场景，核心逻辑都不需要大改。做研究也好，做工程也好，这都是一个基础工具。

如果你正在跑类似的模型，遇到问题欢迎一起交流。我自己是在不断调试和踩坑中把每一步都想明白的，这种问题确实需要耐心，但只要结构清晰、步骤规范，最终一定能跑出合理的结果。