简介：基于多智能体深度强化学习实现的车联网通信资源分配优化，是一份面向计算机专业学习者的高分毕设源码包，覆盖多种主流算法框架，包括深度确定性策略梯度、深度Q网络及多智能体深度确定性策略梯度等，同时具备车联网环境模拟与经验回放模块，可直接运行或二次开发，适用于毕业设计、课程设计及期末大作业。压缩包内共20个文件，含13个Python源代码、6个编译缓存文件与1个使用说明文档，整体大小仅84KB，便于快速部署与阅读。项目源码经过严格调试，评审分达97分，模块按算法和环境清晰划分，能够帮助读者深入理解多智能体强化学习在通信资源分配中的应用逻辑与关键实现。目前已有188人学习下载，对于希望系统完成相关选题或提升工程实践能力的同学具有很高参考价值。
1. 车联网资源分配为什么卡在“非凸”这道坎上
跑过车联网仿真的同学大概都碰到过这种场景：车辆在交叉路口密集穿梭，每个时隙都要决定V2V链路用哪个子信道、发多大功率，而V2I链路的容量又必须被保障。这个问题本质上是个混合整数非线性规划，信道增益随位置快速变化，传统优化方法要么把问题松弛成凸问题丢精度，要么用拉格朗日对偶迭代到超时。近两年大家开始转向多智能体深度强化学习（MADRL），核心原因在于它能把“每个车辆当作独立决策智能体”这件事直接变成分布式策略，训练时用全局信息，执行时只靠局部观测，恰好匹配车联网低时延、高动态的需求。这份基于Python的毕业设计源码，把环境搭建、MADDPG训练和结果可视化都串起来了，适合想快速复现一个完整资源分配基线、又不想从零写环境的人。
2. 把资源分配建模成多智能体马尔可夫决策过程
2.1 为什么不是单智能体RL
传统深度强化学习（比如单智能体DQN）在车联网资源分配里最大的问题，是它把整个系统的状态压成一个高维向量，动作维度随着车辆数线性膨胀。假设系统里有12辆车，每辆车要选择4个子信道和5档功率，联合动作空间就是(4*5)^12量级，单智能体策略网络根本扫不完。多智能体方法的优势是把动作空间拆成每个智能体独立的策略，每个智能体只负责自己的子信道选择和功率级别，复杂度从指数级降到线性级。
但拆开之后立刻遇到非平稳性问题——一辆车改动作，另一辆车看到的收益函数就变了。这就是为什么这份源码选择了集中训练、分布式执行（CTDE)的MADDPG框架：训练时Critic能看到所有智能体的观测和动作，让Q值估计相对平稳；执行时Actor只依赖自己的局部观测，符合车联网的通信约束。对一个毕业设计来说，CTDE是比独立DDPG更稳妥的选择，独立训练那种“每个人都觉得自己在最优，但整体效果崩盘”的情况太常见了。
2.2 状态、动作和奖励函数怎么设计
把车联网资源分配塞进强化学习框架，先要定义清楚三元组。这里给出一个可复现的设计，也是这份源码环境部分的核心逻辑：
- 状态：本车的信道增益、接收到的干扰功率、剩余数据队列长度、车速和位置；如果有V2V直连，还要包含目的车辆的相对距离。
- 动作：离散化的子信道索引加连续/离散功率档位。注意MADDPG原生支持连续动作，源码里通常会把子信道选择做成Gumbel-Softmax采样，功率直接输出归一化值再映射到实际发射功率。
- 奖励：
r = α * V2I容量 - β * V2V时延惩罚 - γ * 功率惩罚。V2I容量用香农公式，V2V时延超过阈值直接给负数奖励，这样智能体才能学会“保底V2V通信用途，再追求系统吞吐量”。
# 一个简化的奖励计算范例（截取自训练环境核心逻辑） def compute_reward(self, agent_index, action_info): # action_info: 包含该智能体选择的子信道和发射功率 # V2I链路吞吐量（Mbps） v2i_rate = self.calculate_v2i_capacity(agent_index) # V2V链路时延惩罚，超出阈值给-5 v2v_delay = self.estimate_v2v_delay(agent_index, action_info['power']) delay_penalty = -5.0 if v2v_delay > self.delay_threshold else 0.0 # 功率越大，惩罚越大，鼓励节能 power_penalty = -0.5 * action_info['power'] / self.max_power return 0.6 * v2i_rate + delay_penalty + power_penalty这里的奖励系数α=0.6, β=5, γ=0.5是源码在默认信道环境下调出来的经验值。注意，如果使用MADDPG算法，Critic在训练时会把所有智能体的奖励拼成一个矩阵，但每个智能体的奖励依然是个体奖励，而不是共享全局奖励——这两个概念很容易混。共享奖励会让智能体失去分化能力，推导不出“谁在拖后腿”这个信息，导致收敛速度极度变慢。
2.3 集中训练与分布式执行的网络结构
源码里的Actor网络通常是一个三层的MLP，输入维度等于状态空间大小，输出维度等于动作空间大小，中间层用ReLU激活。Critic网络则要拼接所有智能体的观测和动作，所以它的输入维度是(状态维度 + 动作维度) * 智能体数量。在MADDPG里，每个智能体都有一对自己的Actor和Critic，各自维护Target网络用于稳定训练。
有一个容易被忽略的细节：因为Actor输入是智能体的局部观测，所以训练时即使使用全局信息，执行阶段依然可以完全分布式部署。这就意味着在仿真里可以方便地测试不同车辆数量下的扩展性。如果只有源码没有文档，建议先在config.py里找n_vehicles和subchannel_num这两个参数，改完之后观察训练曲线是否依然能收敛，这是快速验证代码结构正确性最直接的方式。
3. 源码结构拆解与关键实现代码导读
3.1 文件目录里到底装了什么
拿到压缩包之后，第一件事不是急着pip install，而是看清代码的组织方式。这套源码的典型目录结构如下：
project_root/ ├── config.py # 全局参数配置：车辆数、信道数、学习率、训练轮数 ├── env/ │ ├── v2x_env.py # 车联网通信环境，实现 step / reset / observation │ └── channel_model.py # 信道增益计算，包含大尺度衰落和小尺度衰落 ├── agents/ │ ├── maddpg.py # MADDPG核心算法，包括Actor-Critic网络定义 │ ├── ddpg_agent.py # 单个智能体的DDPG实现，含经验回放 │ └── buffer.py # 经验回放缓冲区 ├── train.py # 训练入口，创建环境、智能体，循环训练 ├── evaluate.py # 加载训练好的模型，输出吞吐量和时延指标 └── docs/ └── 设计文档.md # 算法推导、参数说明、结果截图channel_model.py是容易被忽略的底层模块。它通常会实现大尺度衰落（距离路径损耗）和小尺度衰落（瑞利或莱斯衰落）的组合，换句话说，信噪比的计算正确性完全依赖这个文件。建议先跑一遍里头的单测或示例脚本，确认信道增益是随机生成且符合对数正态分布，否则后续所有奖励曲线的波动都可能来自错误的信道实现，而不是算法问题。
3.2 经验回放缓冲区为什么要存“所有人”
多智能体训练最常见的一个坑是每个智能体各存各的记忆，这种做法会破坏CTDE前提。既然训练时Critic需要所有智能体的联合动作，那么经验元组必须包含每个智能体的(obs_i, act_i, rew_i, next_obs_i)，外加可以重建联合状态的信息。源码里的buffer.py一般会设计成：
class ReplayBuffer: def __init__(self, capacity, n_agents): self.capacity = capacity self.n_agents = n_agents # 每个智能体独立存储观测向量，但要一起存入一条经验 self.buffer = collections.deque(maxlen=capacity) def add(self, obs_list, act_list, rew_list, next_obs_list, done): # obs_list 是长度为 n_agents 的列表，每个元素形状为 (obs_dim,) self.buffer.append((obs_list, act_list, rew_list, next_obs_list, done)) def sample(self, batch_size): batch = random.sample(self.buffer, batch_size) obs = torch.stack([torch.stack([b[0][i] for b in batch]) for i in range(self.n_agents)]) # 返回按智能体维度切分好的张量，方便后面单个Critic拼接 return obs这个设计里，每个经验元组保存所有智能体的信息，采样时按智能体索引切分。注意容量capacity不能设得太小，多智能体环境下经验分布本身就有滞后性，建议不低于5万条；如果内存压力大，可以适当降低n_vehicles，而不是缩小回放池。每次采样时，随机抽一个batch，然后Critic更新要用的是联合观测和联合动作，所以了要拿所有智能体的样本。
3.3 训练主循环的三大关键点
MADDPG训练主循环的骨架通常长这样：
for episode in range(max_episodes): obs = env.reset() # obs 是长度为 n_agents 的列表 episode_reward = np.zeros(n_agents) while True: actions = [] for i in range(n_agents): action = agents[i].select_action(obs[i], noise_scale=0.1) actions.append(action) next_obs, rewards, done, info = env.step(actions) buffer.add(obs, actions, rewards, next_obs, done) obs = next_obs episode_reward += rewards if done: break # 每轮结束后，随机采样更新每个智能体 for i in range(n_agents): batch = buffer.sample(batch_size) agents[i].update(batch) # 内部会更新 critic actor targetselect_action里在训练初期要加探索噪声，一般用服从N(0, 0.1)的高斯噪声加到动作输出上，然后裁剪到动作边界内。有经验的工程师会把noise_scale从0.2线性衰减到0.02，否则末期噪声持续过高会让策略永远震荡。
update里有两个容易出错的细节。第一，Critic的target值计算时，要使用目标网络中所有智能体的Actor输出，而不是直接用当前网络选出的动作——这个错位是导致调参不收敛的大敌。第二，每个智能体的Critic更新必须避免梯度回传到其他智能体的Actor上，所以Pytorch里要用detach()切断连接。源码里如果没做这一步，训练过程中loss会异常跳动。
4. 训练过程中的调参实战与排错记录
4.1 训练曲线不收敛的检查顺序
在实际跑这份源码时，最可能遇到的四个问题如下表，按从简单到复杂的顺序排查：
| 现象 | 根因 | 修复方向 |
|---|---|---|
loss 直接爆炸，到nan | 学习率过大或奖励没有归一化 | 把Actor/Critic学习率降到1e-4以下，检查奖励计算里有没有明显溢出 |
| 训练曲线一路下滑，没有任何回升 | 奖励里delay_penalty权重过大，导致所有智能体学到“别发数据” | 减小β值，先只优化V2I容量 |
| 前期正常，中期崩溃 | 经验回放池覆盖过快，旧经验被冲掉 | 增大回放池容量到10^6量级，或者降低更新频率 |
| 有的智能体收益高，有的永远学不好 | 智能体之间的奖励存在竞争关系，Critic对劣势智能体梯度不敏感 | 把个体奖励改成“个体奖励 + 小比例团队奖励” |
4.2 超参数设置的基线参考
这份源码的配置文档里给的默认超参，我对照自己的复现经验看，是偏保守但靠谱的：
- 车辆数
n_vehicles=8，子信道数n_subchannels=4，功率档位power_levels=5 - Actor学习率
1e-4，Critic学习率1e-3，Critic比Actor学得快是刻意设计，因为Q值要先稳定下来才能指导策略 - 折扣因子
gamma=0.95，车联网场景决策时域短，不需要设到0.99 - 软更新系数
tau=0.01，Target网络更新太慢会导致Q值滞后，太快则Q值波动 - 每轮最大步数
max_steps=200，一个episode模拟一个车辆进入通信范围的过程
建议第一次跑通时不要直接改大车辆数，而是先把n_vehicles=6跑300个episode，观察奖励曲线的方差。如果曲线像毛毛虫一样波动，说明信道随机性太大，可以把每个episode里的信道状态固定生成（设置随机种子），先验证算法在确定性环境里学不学得动，再去想办法解决泛化问题。
4.3 如何利用文档里的设计说明定位问题
很多同学拿到源码后只看代码不看docs/设计文档.md，这是亏的。文档里通常包含MADDPG的公式推导、目标网络更新公式、以及实验环境参数表格。当训练曲线出现异常时，建议杀掉训练进程，去文档里找“Q值更新”章节，确认一下Critic的target计算方式。我遇到过一份代码，文档里写的target计算是r + gamma * Q_target(next_obs, next_actions)，但实现时少拼接了next_actions，这会让Q值一直偏低，最终学出来策略是所有车辆都抢占同一个信道。
另一个技巧是给训练脚本加一个--log_interval参数，每10个episode输出一次每个智能体的平均奖励、平均时延和平均功率。如果把这三个指标分开看，比只盯总奖励更容易定位问题。比如平均时延一直下不去，说明奖励函数里时延惩罚权重太小或者是信道分配策略和时延目标冲突；平均功率持续走低说明功率惩罚压过一切，智能体选择不发数据。
# 推荐的训练启动方式，开启tensorboard 可以实时观察各智能体指标 python train.py --n_vehicles 8 --max_episodes 500 --log_interval 10 --tensorboard True训练结束后会生成models/目录，里面每个智能体的actor和critic权重分别存为agent_i_actor.pth与agent_i_critic.pth。注意：加载模型权重时，必须和保存时的维度一致，否则torch.load不会报错，但前向传播会得到一堆随机张量。
5. 从训练到上车的验证技巧与可视化复盘
5.1 加载模型后，先看这三个指标
跑完训练别急着看吞吐量曲线，先检查策略是否具备最基础的常识。加载模型对同一个场景跑10次，记录三种指标：V2I链路平均频谱效率、V2V链路时延超过阈值的比例、发射功率平均值。这三个指标能直接告诉你策略是不是在“作弊”。比如V2V时延达标率很高，但V2I频谱效率低得离谱，说明智能体学会的方法是压低发射功率而不是做有效的信道隔离，这种策略在真实信道波动下会瞬间失效。
更细一点的做法是打印每个动作的分布。把每个子信道被选中的概率画成直方图，如果两个相邻车辆的子信道选择概率完全一致，说明智能体没有学到差异化分配策略，这在MADDPG里可能是Critic的输入拼接顺序错了——所有智能体共享了同一份观测向量。
# 评估脚本片段：加载模型并统计资源选择分布 model = torch.load('models/agent_0_actor.pth', map_location='cpu') channel_choices = [] for i in range(100): obs = env.get_obs(0) action = model(torch.FloatTensor(obs)).detach().numpy() channel_choices.append(np.argmax(action[:n_subchannels])) print('Agent 0 的子信道选择分布:', np.bincount(channel_choices) / len(channel_choices))如果希望某个智能体始终使用特定信道，可以通过在奖励里加“信道占用冲突惩罚”来实现，比如当两辆相邻车辆选用同一子信道时，额外扣掉一个固定值。这是MADDPG相对传统调度算法的一个优势——所有约束都可以写进奖励函数，不需要改算法框架。
5.2 把训练日志变成论文里的对比图
毕业设计答辩时需要的对比图，实际上在训练过程中就应该留好原始数据。建议每20个episode保存一次所有智能体的奖励、每个子信道平均占用率、平均时延，用CSV格式存储。之后做三张图：第一张是总奖励曲线（和深度Q-network基线对比）；第二张是V2I容量CDF图；第三张是V2V时延CDF图。三张图放在一起，才能证明多智能体联合训练比独立训练明显更好的结论。注意，对比实验的基线最好是单智能体DQN或者独立DDPG，不要拿随机策略当基线，说服力不足。
5.3 把通信参数抽出来做敏感性分析
源码训练完之后，最高价值的进阶工作不是改网络层数，而是做参数敏感性分析。保持算法不变，分别调整车辆密度、子信道数量、车辆速度，观察性能曲线的变化。比如把车辆数从8增加到14，如果总奖励掉的幅度超过30%，说明当前Critic的输入维度已经无法容纳这样程度的联合状态，需要增加中间层宽度；如果子信道数从4变成8，奖励反而下降，往往是因为动作空间变稀疏，探索难度增加，需要调大噪声初始值。
一个实用的收尾技巧：把训练时的随机种子固定下来，在config.py里加一行random.seed(42); np.random.seed(42); torch.manual_seed(42)。多智能体训练的过程波动很大，固定种子既能保证自己复现，也能在答辩现场演示时避免偶然失败。如果还想在固定场景下深挖，可以在env/v2x_env.py里增加一个固定车辆轨迹的开关，这样信道状态完全由位置决定，整个系统变成一个确定性的调度问题，方便分析每个智能体的策略和动作因果。这部分修改量不大，但能让你的工作量比原源码多出明显的一块。
本文还有配套的精品资源，点击获取
