简介基于多智能体深度强化学习的车联网通信资源分配优化Python源代码与文档说明面向车联网通信、强化学习算法研究者及高年级本科生/研究生。针对高速移动车辆场景下V2V链路与V2I链路频谱共享难题提供以MADDPG为核心的多智能体分布式训练实现涵盖DDPG、MADQN等对比算法并包含环境模拟、经验回放、评论家网络集中训练等完整模块可帮助读者理解连续动作空间下的功率控制与资源分配机制。压缩包为zip格式共20个文件包括13个Python源码文件、6个编译生成的pyc缓存文件及1个使用说明文本包体仅82KB轻量易部署。目前已有199人学习下载适合作为车联网资源分配方向论文复现、课程设计及算法对比实验的基础代码库。文档说明与目录结构便于快速上手读者可获得可直接运行的算法框架和调参思路。1. 基于多智能体深度强化学习的车联网通信资源分配训练跑通前先把问题定义写对做车联网通信资源分配最气人的往往不是算法跑不起来而是跑起来了你也不知道它学到的到底是资源分配策略还是环境里哪个没被消除的偏置。基于多智能体深度强化学习的车联网通信资源分配就是把路侧单元或者车辆当成独立学习的智能体让它们在同一个信道环境里各自决策、互相干扰最后收敛出一套吞吐量更高、冲突更少的分配方案。这类代码包自带一套简化到能在一张普通显卡上训练的车联网环境、几十个可调参数和一份说明文档适合正在做车联网方向毕设、论文复现或想在无线资源分配里试多智能体算法的读者。它的价值不是直接产出能商用的空口协议而是给你一套把问题建模成多智能体深度强化学习并完成验证的完整框架。2. 把车联网资源分配写成多智能体问题状态、动作、奖励与算法选型2.1 车联网资源分配在分配什么为什么传统方法会失灵车联网通信资源分配落到物理层就三样东西子信道、发射功率、时隙。V2X 场景里通常分两类链路V2V车到车和 V2I车到路侧单元。V2V 主要承载基本安全消息 BSMBasic Safety Message广播周期 10Hz包很小但不能丢V2I 承载感知数据、协同驾驶消息对吞吐量和时延都有要求。资源分配要回答的问题是哪辆车在哪个子信道上、用多大功率发才能让整体 SINR 不被相互干扰拖垮。在一个密集路口场景里同时可能有几十辆车在发 BSM而可用的子信道往往只有几个到十几个。按 N 辆车、C 个子信道、P 个功率档位计算解空间是 (C×P) 的 N 次方N 到 10 以上时穷举已经不可行。图着色、博弈论这类传统方法能处理静态拓扑可车联网的拓扑每个时隙都在变车辆高速移动导致信道增益持续变化每次重算一次全局优化的代价太高。这也是深度强化学习被引入的原因它把在线决策变成离线训练策略网络在训练阶段见过大量拓扑变化执行阶段只需要一次前向计算就能输出动作。2.2 为什么单智能体深度强化学习不够用单智能体深度强化学习的常规做法是把全局状态摊平成一个超长向量动作也由一个大网络一次性输出。智能体数量少时勉强能用但车联网场景一旦有 6 个以上发射端状态维度成倍增长样本效率暴跌。更麻烦的是 credit assignment 问题全局奖励里混着多个发射端的相互干扰单个智能体无法判断“这次吞吐量下降是因为我功率太大还是邻居换了个信道”。多智能体框架用 CTDECentralized Training with Decentralized Execution中心化训练、分布式执行来绕开这个矛盾。训练时 critic 能看到全局状态和所有智能体的动作方便评估联合动作的好坏执行时 actor 只看自己的局部观测不依赖实时全局通信符合车联网里信道状态信息不完整、反馈有延迟的实际情况。换句话说多智能体深度强化学习不是把“一个大网络拆成几个小网络”而是把训练目标和执行条件分开设计。2.3 深度强化学习算法列表对比IQL、VDN、QMIX、MADDPG 怎么选拿到一个车联网资源分配代码包先别急着训练看清楚里面用的是哪类算法直接决定你后面调参的方向。下面这四类算法在车联网论文里出现频率最高它们的核心差异在训练框架和动作类型上。算法训练框架动作类型典型场景主要缺点IQLIndependent Q-Learning每个智能体独立跑 DQN离散智能体耦合弱的小规模场景环境非平稳训练容易振荡VDN中心化值分解Q 值简单加和离散智能体目标一致的合作任务只假设线性加和表达能力有限QMIX中心化值分解单调混合网络离散智能体数量较多、动作离散单调性约束在强竞争场景下受限MADDPG中心化 Critic 加分布式 Actor连续或离散连续功率控制、竞争合作混合Critic 输入维度大训练不稳定我的选型逻辑很简单如果动作空间是“子信道编号 × 功率档位”这种离散组合优先 QMIX它在多智能体离散控制上的稳定性明显好于 IQL如果代码包里功率是连续值比如发射功率从 -10dBm 到 23dBm 直接输出连续量那就用 MADDPG。IQL 最容易实现也能出结果但复现性差同样一组超参数换个随机种子可能就发散不推荐作为主力方案。2.4 状态、动作与奖励设计环境代码里的三个关键定义多智能体深度强化学习的建模质量九成取决于状态和奖励怎么写。车联网场景里单个智能体的局部观测通常包含四类信息自己的位置、到目标接收机的距离、当前子信道的干扰电平、上一时隙自己选择的动作。奖励则要同时反映三件事V2I 链路的吞吐量、V2V 链路的成功率、以及整体时延代价。# v2x_env.py —— 环境的最小可运行骨架 import numpy as np class V2XResourceEnv: def __init__(self, n_agents6, n_channels4, n_power_levels3): self.n_agents n_agents # 智能体数量通常对应活跃的V2V/V2I发射端 self.n_channels n_channels # 可复用子信道数远小于智能体数时冲突概率高 self.n_power_levels n_power_levels self.obs_dim 12 # 局部观测向量维度 # 动作 子信道序号 * n_power_levels 功率档位 self.n_actions n_channels * n_power_levels self.positions None self.channel_gain None self.last_action np.zeros(n_agents, dtypenp.int32) self.interference_level np.zeros(n_agents, dtypenp.float32) def reset(self): # 每个episode随机撒车辆位置模拟不同拓扑 self.positions np.random.uniform(-500, 500, (self.n_agents, 2)) # 大尺度衰落 小尺度阴影简化成log-normal增益 self.channel_gain np.random.lognormal( mean0.0, sigma1.0, size(self.n_agents, self.n_agents) ) self.last_action np.zeros(self.n_agents, dtypenp.int32) self.interference_level np.zeros(self.n_agents, dtypenp.float32) return self._get_obs() def _get_obs(self): obs np.zeros((self.n_agents, self.obs_dim), dtypenp.float32) for i in range(self.n_agents): # 局部观测归一化位置、平均信道增益、上一时刻动作、干扰电平 obs[i] np.concatenate([ self.positions[i] / 500.0, [self.channel_gain[i].mean()], [self.last_action[i] / self.n_actions], [self.interference_level[i]] ]) return obs def step(self, actions): # actions: (n_agents,) 每个元素是0~n_actions-1的整数 channel actions // self.n_power_levels # 拆出子信道编号 power actions % self.n_power_levels # 拆出功率档位 sinr self._compute_sinr(channel, power) reward self._compute_reward(sinr) self.last_action actions.copy() return self._get_obs(), reward上面代码有三个必须注意的细节。第一位置除以 500 做归一化避免坐标值直接进网络导致数值不稳定动作也除以 n_actions让上一时刻动作的取值范和位置在同一量级。第二动作是单整数编码用整除和取余拆成信道与功率两部分这样网络输出层只需要 softmax 一个 n_actions 维的动作分布比输出两个独立头更简单。第三_compute_reward里一般会把 SINR 先取对数再乘系数“log1p”经验在无线通信场景很管用它能把干扰变化压缩到模型能分辨的区间避免奖励值量级波动太大。3. 训练主循环拆解MADDPG 最小实现与多智能体如何配置3.1 Actor-Critic 结构里每个智能体的网络到底负责什么MADDPG 是车联网连续功率控制场景里最常见的多智能体深度强化学习算法之一它的网络结构值得拆开讲。每个智能体有两组网络actor 和 critic。actor 输入自己的局部观测输出动作分布训练目标是让 critic 打出的 Q 值更大critic 输入全局观测和所有智能体的动作输出一个 Q 值目标是准确评估“当前全局状态下联合动作有多好”。关键点在于actor 永远只看局部观测这保证执行阶段不依赖全局信息critic 只在训练阶段使用全局信息测试阶段直接丢弃。这就是 CTDE 的全部含义。车联网场景里全局信息包括所有车辆的位置、所有链路的信道增益和所有发射端的功率设置这些数据在真实系统里没法实时汇集到每个节点但集中训练时它们都在仿真器里可以在离线训练阶段随便用。如果用 QMIX 这类值分解算法结构会略有不同每个智能体有一个独立的 Q 网络输出自己的 Q 值然后由一个混合网络把所有 Q 值合并成全局 Q 值。混合网络保证全局 Q 值对每个智能体的 Q 值都是单调递增的从而让每个智能体只要追求“自己的 Q 最大”就能间接优化全局目标。QMIX 的好处是训练更稳定代价是单调性约束在强竞争场景下会限制表达能力。具体选哪个取决于你代码包里的动作是离散还是连续以及你希望训练曲线有多平滑。3.2 训练主循环探索退火、经验回放与联合更新多智能体深度强化学习的训练循环和单智能体 DQN 很相似但有两个关键差异每个时间步要为每个智能体分别选动作更新阶段则按联合动作和联合奖励计算。下面这段代码结构可以直接套进大多数车联网资源分配代码包。# train.py —— MADDPG 主循环结构 import numpy as np from agents.maddpg import MADDPG from env.v2x_env import V2XResourceEnv from utils.replay_buffer import ReplayBuffer def run_training(cfg): env V2XResourceEnv( n_agentscfg[n_agents], n_channelscfg[n_channels], n_power_levelscfg[n_power_levels], ) maddpg MADDPG( n_agentscfg[n_agents], obs_dimenv.obs_dim, action_dimenv.n_actions, lr_actorcfg[lr_actor], # 3e-4 是常见起点 lr_criticcfg[lr_critic], # 1e-3critic可以稍激进 gammacfg[gamma], # 0.99 ) buffer ReplayBuffer(capacitycfg[buffer_size]) # 1e5起步 eps 1.0 # 探索率先大后小 for episode in range(cfg[max_episodes]): obs env.reset() ep_reward 0.0 for t in range(cfg[max_steps]): actions {} for i in range(env.n_agents): # 每个智能体只看自己的obs分布式执行 a maddpg.select_action(i, obs[i], eps) actions[i] a next_obs, reward, done env.step(actions) # 经验回放里存的是所有智能体的联合观测和联合动作 buffer.add(obs, actions, reward, next_obs, done) if len(buffer) cfg[batch_size]: batch buffer.sample(cfg[batch_size]) maddpg.update_all(batch) # 中心化critic在这里更新 obs next_obs ep_reward sum(reward.values()) # 探索退火前70%的episode线性下降之后保持小概率探索 eps max( cfg[eps_min], eps - (1.0 - cfg[eps_min]) / (cfg[max_episodes] * 0.7) ) if episode % 50 0: print(fepisode {episode} reward {ep_reward:.2f} eps {eps:.2f})这段代码的逻辑说明分三层。第一层是动作选择每个智能体的 actor 独立前向计算输出动作分布后按 eps 概率随机采样eps 从 1.0 线性降到 0.05保证训练早期充分探索、后期稳定利用。第二层是经验回放存储的每条经验包含所有智能体的 obs 和 action这是与单智能体代码最大的区别缓冲区里的一条记录描述的是“全局联合状态转移”而不是某个智能体的独立轨迹。第三层是联合更新update_all内部对每个智能体分别计算 critic 的 TD 误差再更新对应 actor注意这里的 batch 是所有智能体在同一时步的联合数据不是把每个智能体打散后独立采样。3.3 超参数怎么设一组可复现的起点配置多智能体深度强化学习的超参数比单智能体更敏感因为多个网络同时更新任何一个学习率不合理都会放大为全局振荡。下表这组参数是我在车联网资源分配场景里比较稳妥的起点适合大多数简化仿真环境。参数建议起点说明lr_actor3e-4actor 步长太大会震荡太小收敛慢lr_critic1e-3critic 可以比 actor 略激进但过估计风险更高gamma0.99车联网指标是长期累积不宜低于 0.95batch_size128过小方差大过大更新频率低buffer_size1e5至少能装几十个 episode 的转移数据max_steps200一个 episode 内车辆移动范围对应场景尺度eps_min0.05探索率下限测试时直接置 0tau0.01target 网络软更新系数MADDPG 常用范围 0.005~0.023.4 多智能体如何配置参数共享、邻居半径与动作边界代码包里的“多智能体配置”往往不是算法层面的问题而是工程配置问题。最常见的开关有三个参数共享、邻居半径、动作边界。参数共享意味着所有智能体复用同一套 actor 网络参数只是输入各自的 obs。它在智能体同构时能极大提升样本效率缺点是牺牲了每个智能体的个性化策略。车联网里如果所有发射端是同型号设备我一般会开启参数共享让所有智能体共享 actor但保留独立的 critic。邻居半径决定一个智能体能观测到哪些其他智能体。通信半径设得越大观测信息越完整但 obs 维度越高、训练越慢。常见的做法是设一个 150 到 300 米的半径只把半径内的智能体占用状态拼进 obs而不是把全图信息塞进去。动作边界则要检查代码里有没有做功率档位的映射限制比如最大发射功率 23dBm档位数量 3 到 5 个动作空间大小直接由这些边界决定改场景时记得同步改。# config/train.yaml —— 多智能体配置关键字段 n_agents: 6 share_parameters: true # true: 所有agent共用actor网络样本效率高 comm_radius: 150.0 # 只有半径内的agent才算邻居进入observation topology_update_interval: 10 # 每10个step重新计算一次邻居关系 max_power_dbm: 23.0 # 最大发射功率对应功率档位上限4. 从源代码压缩包到第一次收敛目录解读、环境搭建与最小训练命令4.1 拿到 python 源代码包先看什么典型目录结构与文档说明的阅读顺序一个车联网多智能体深度强化学习的 python 源代码包无论作者怎么组织目录结构基本逃不出这几类环境代码、智能体代码、配置、工具脚本和训练入口。拿到压缩包后不要急着跑 train.py第一件事是看 README 和文档说明找到“运行环境要求”和“最小示例”两节。文档说明里通常包含环境版本信息、依赖安装命令、训练启动命令和已知问题这些信息比代码本身更值钱。# 一个典型的车联网MADRL代码包目录结构命名可能不同 v2x_madrl/ ├── README.md ├── requirements.txt ├── config/ │ ├── env.yaml │ └── train.yaml ├── env/ │ ├── v2x_env.py # 仿真环境车辆移动、信道、SINR、奖励 │ └── channel_model.py # 信道建模大尺度衰落、阴影、干扰计算 ├── agents/ │ ├── maddpg.py # MADDPG: actor/critic网络与更新逻辑 │ └── networks.py # 网络结构定义 ├── utils/ │ ├── replay_buffer.py # 多智能体经验回放 │ └── logger.py # 训练日志与指标记录 ├── train.py # 训练入口 └── evaluate.py # 测试入口加载模型并评估4.2 Python 环境搭建用 venv 隔离依赖别污染系统环境环境搭建的坑主要集中在 Python 版本和依赖冲突上。车联网仿真代码通常用到 numpy、torch、gym 这类基础库多智能体强化学习代码对 torch 版本敏感建议用 Python 3.8 到 3.10 之间的版本太新的 Python 版本反而容易遇到个别依赖没有预编译包的问题。最稳妥的方式是创建独立虚拟环境不要直接往系统 Python 里装。# 创建并激活虚拟环境Windows 下激活命令不同 python -m venv .venv source .venv/bin/activate # Windows: .venv\Scripts\activate # 安装依赖先装requirements再装可编辑模式 pip install --upgrade pip pip install -r requirements.txt pip install -e . # 如果包里有setup.py/pyproject.toml这里解释一下最后两条命令的差别。pip install -r requirements.txt装的是固定版本依赖通常直接对应作者跑通的版本组合pip install -e .是以可编辑模式安装当前项目本身让import env、import agents这类相对导入能在项目根目录下直接生效。如果你运行python train.py时报 ModuleNotFoundError八成是这一步没做或者没有先激活虚拟环境。4.3 最小训练命令与第一次评估从 train.py 到 checkpoint环境配好后先不要改任何配置用默认参数直接启动训练目的是验证代码能完整跑完一个 episode并且日志系统、模型保存都正常工作。如果你的代码包使用的仿真器是 OMNeT 或 ns-3 这类外部工具train.py 通常会先启动仿真进程再加载 Python 接口第一次运行要留出额外时间确认仿真器和 Python 环境能正常通信OMNeT samples 里能直接找到很多 V2X 案例结构可以对照看代码包里信道模型是怎么写的。# 启动训练指定配置文件固定随机种子 python train.py --config config/train.yaml --seed 2024 # 训练完成后评估加载最优模型关闭探索 python evaluate.py --checkpoint logs/best_model.pt --episodes 20--seed 2024的作用是固定随机种子确保结果可复现。评估时记得把探索率置为 0用贪婪策略选动作否则评估结果里混着随机探索的噪声指标会明显偏低。第一次训练建议只跑 200 到 500 个 episode观察 loss 和 reward 是否在一个合理的量级不用等它完全收敛。4.4 训练日志里看什么reward、collision rate 和 throughput大多数代码包的 logger 会同时记录三种数据每 episode 的平均奖励、碰撞率或丢包率、以及链路吞吐量。奖励是算法优化的目标碰撞率反映资源冲突程度吞吐量反映实际通信质量。三者要一起看如果奖励在涨但碰撞率没降说明奖励函数里干扰惩罚项权重太小策略在“钻奖励函数的空子”如果吞吐量正常但奖励震荡说明奖励和物理指标之间的换算关系有 bug。看训练曲线有个工程习惯先看原始曲线再用滑动平均看趋势。原始曲线包含探索噪声直接判断收敛很容易被带偏滑动窗口取 50 到 100 个 episode 做平均趋势会清晰很多。我一般会在训练跑到一半时停下来用evaluate.py做一次完全无探索的评估这个数字比训练日志里的曲线更能反映实际效果。5. 多智能体强化学习在车联网场景的 5 个必踩坑与排查方案5.1 训练不收敛reward 曲线长期为零或直接发散现象训练几百个 episode奖励始终在一个极小的值附近波动或者突然变成一个巨大的负数然后一路向下。原因最常见的是奖励函数写得太稀疏加上动作空间过大随机探索几乎碰不到“好动作”。车联网场景里如果干扰计算直接返回原始 SINR 而不是取对数奖励值的量级可能横跨几个数量级网络更新时梯度震荡剧烈。另一个隐蔽原因是环境的 episode 太长比如 max_steps 设成 1000 而奖励只在 episode 结束时给出学习信号过于稀疏。解决先把场景缩小n_agents 降到 3、n_channels 设 4跑通一个玩具版本奖励里给每个时步都加一个小的即时奖励比如当前 V2I 吞吐量的 log 值确认_compute_reward返回值范围在 [-1, 1] 附近如果太大就对奖励做归一化或剪裁。跑通小场景后再逐步扩大规模不要一开始就挑战 10 个智能体的大场景。5.2 多智能体比单智能体效果还差甚至不如固定分配现象单智能体 DQN 跑出不错的结果换成多智能体算法后反而全面退化连 TDMA 轮询都不如。原因这是典型的环境非平稳问题。如果代码用的是 IQL 这类独立学习框架每个智能体在训练时都把其他智能体当成环境的一部分但其他智能体同时也在更新策略导致每个智能体面对的环境每时每刻都在变Q 值永远追不上真实情况。另一个常见原因是经验回放里没有保存“联合动作”更新时把不同智能体的数据错位拼接train 和 evaluate 时观测分布对不上。解决确认代码用的是 CTDE 框架critic 能看到全局观测和联合动作如果只有 IQL先把参数共享打开再把经验回放改成按“全局转移”存储最后检查update_all里每个智能体的 batch 数据是否来自同一个时间步的同一批经验。错位拼接这个问题在代码包改写过最容易出现肉眼看不出来只能在更新函数里打日志核对 batch 的时间步索引。5.3 Q 值过估计critic 预测的 Q 和实际 reward 差几个数量级现象训练日志里 critic loss 还在下降但实际评估时累积奖励远低于 critic 预测的 Q 值甚至差出一个量级。原因MADDPG 本质上是 DDPG 的多智能体版本DDPG 家族天然存在 Q 值过估计问题过估计会随着多个智能体的联合动作空间增大而进一步放大。target 网络软更新系数 tau 设得太大比如 0.1也会让 target 网络追着当前网络跑失去冻结作用。解决先确认 tau 在 0.005 到 0.02 之间这是 DDPG 类算法比较通用的区间如果代码里有双 critic 结构两个 critic 取最小值优先保留它能显著抑制过估计也可以在奖励计算里加入对异常 SINR 的惩罚减小环境层面的奖励噪声。这些措施叠加后critic 预测 Q 值和实际评估的差距应该能压到 20% 以内。5.4 换台机器、换个随机种子结果完全不一样复现性很差现象同一套代码、同一组配置在本地跑和远程服务器跑或者只改一个 seed收敛速度、最终性能都差很多。原因随机源没有完全固定。多智能体环境里随机源至少有五个环境初始化的车辆位置、信道增益采样、动作选择的探索噪声、神经网络权重初始化、经验回放的采样顺序。只要有一个没固定结果就无法复现。解决写一个set_seed函数同时固定三个库的随机源# utils/seed.py —— 固定所有随机源 import random import numpy as np import torch def set_seed(seed: int): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) # CUDA额外固定一行保证GPU上有确定性 torch.cuda.manual_seed_all(seed)在 train.py 里第一时间调用并把环境初始化时的np.random.uniform也放到该函数之后。血泪经验有次我连续调了三天超参数奖励曲线一直忽高忽低最后发现是环境里channel_gain的采样没有吃 seed每次启动训练的信道模型都不一样等于在拿三天的数据训练一个随机环境。5.5 训练特别慢GPU 利用率低一个 episode 要跑几十秒现象显存占用不大但 GPU 利用率只有百分之十几训练速度完全被 CPU 卡住。原因多智能体代码最常见的性能瓶颈是 obs 拼接方式。如果每个智能体的观测是全图信息拼接经验回放时被反复复制搬运CPU 到 GPU 的拷贝占了大量时间另一个原因是网络结构太深小场景里没必要用 256 层的 MLP单层 128 个神经元足够。解决先用top -H或任务管理器确认是不是 CPU 跑满如果是检查 obs 是否包含重复信息把全图 obs 改成邻居半径内的局部 obs把 batch_size 加到 256减少单位时间内的拷贝次数开启参数共享让所有智能体共用一个 actor前向计算从 N 次变成 1 次。还有一个常见的性能玄学把torch.no_grad()包在动作选择的推理部分能省下 20% 到 30% 的训练时间。6. 从复现到改写最小改动迁移、基线对比与结果验证技巧复现跑通只是第一步把代码包迁移到自己的场景才是真正的工作量所在。最小改动原则是先在配置文件里改配置文件不够用再动代码。车辆数量、子信道数、邻居半径、功率档位这四个参数几乎都集中在 config 文件里改完直接训练不需要碰环境代码。只有当你需要改通信模型本身时才动 env 里的代码比如把简化的 log-normal 信道换成都市峡谷路径损耗模型或者把固定车辆拓扑换成 SUMO 导出的轨迹文件。节点数增加一倍训练步数通常要翻两到三倍才能收敛这个预期要提前建立。验证阶段最容易被忽视的就是基线对比。只画 MADDDPG 的奖励曲线不足以说明方法有效至少要拉上三个基线固定分配比如 TDMA 轮询、随机分配、单智能体 DQN。固定分配代表传统方案的性能下限随机分配用于验证奖励函数有没有明显偏好单智能体 DQN 则用来证明多智能体框架确实带来了增益。记录指标时不要只看平均奖励碰撞率、V2V 成功率、V2I 吞吐量这三个物理指标也要单独记录它们才是判断算法是否真实有效的依据。# evaluate.py —— 对比实验的记录结构 results { algorithm: [MADDPG, QMIX, IQL, TDMA, Random], avg_reward: [0.0] * 5, v2v_success_rate: [0.0] * 5, # V2V链路成功率 v2i_throughput_kbps: [0.0] * 5, # V2I吞吐量 }消融实验的优先级比超参数调优更高。最常见的消融是关闭中心化 critic退化成 IQL看性能掉多少。如果退化不明显说明你的场景里智能体之间的耦合本来就不强或者奖励函数的干扰惩罚设置得不够敏感这时候优先调整奖励权重而不是继续堆算法复杂度。另一个值得做的改动是尝试连续功率控制把功率档位从离散变成连续动作从分类改成回归MADDPG 在这类场景里的表现通常比 QMIX 更平滑。最后说一个我自己的习惯拿到任何多智能体强化学习代码包第一件事不是看网络结构、不是调超参数而是把 seed 固定、把评估脚本写好、把三个基线跑出来再开始改自己的东西。没有这套框架后面所有的调参都建立在随机性之上调参就成了赌博。希望帮到你。本文还有配套的精品资源点击获取