多智能体交通信号控制仿真实战：从路口建模到Q-learning协调优化

简介：一份基于多智能体算法的城市交通信号控制仿真系统源码包，面向交通工程、人工智能及智能交通系统的研究者与开发者，用于构建虚拟交通环境、模拟不同车流状况，并验证信号灯智能体之间的协同控制策略。压缩包共173个文件、约49.64MB，核心由C++源码构成，涵盖交通流模拟、路网解析、DSA智能体及协调中心等模块，辅以Python脚本、JSON配置、CMake构建文件和说明文档，便于研究者在真实代码层面理解多智能体交互与决策机制。目前已有241人学习下载，适合作为课题研究、毕业设计或工程项目的基础框架。源码结构完整且模块化较强，既能直接编译运行，也支持针对路口延误、排队长度、通行效率等指标修改评价函数与信号相位策略，从而开展对比实验与参数优化，是探索城市交通信号智能控制的有效工具。

1. 多智能体交通信号控制仿真系统：这个项目到底在做什么

下班高峰期，一个路口单独优化得再好，车流涌到下一个路口照样堵成一锅粥。单点信号灯的困局在于它看不到下游的压力，绿灯放行反而把拥堵往下游推。这个标题里的多智能体交通信号控制仿真系统，把每个路口封装成一个能感知、能决策、能协商的智能体，让相邻路口共享排队信息、协调放行节奏，目标是降低整个路网的平均等待时间。它是一个能在本地跑通、能出对比数据、能把算法讲清楚的高质量实战项目，附带的源码可以帮你少走弯路。适合正在做毕业设计、课程设计，或者想往智能交通方向转型的开发者。

做这类项目，最容易犯的错是一上来就写代码。多智能体算法本身不难，难的是你把状态、动作、奖励定义歪了，后面所有训练曲线都会给你脸色看。所以这一章先把模型立住，再谈实现。

2. 多智能体信号控制的设计基础：单路口智能体与区域协调的建模

2.1 每个路口一个智能体：状态、动作、奖励怎么定义

交通信号控制本质上是一个持续决策问题：每过几秒，控制器要决定是继续保持当前相位，还是切到下一个相位。引入多智能体后，决策者变成一组分布式Agent，每个Agent负责一个路口。定义一个智能体三件套：状态（State）是它对环境的感知，动作（Action）是它能做的决策，奖励（Reward）是环境对决策的反馈。

为什么每个路口要抽象成独立Agent，而不是一个中央控制器统管全局？中央控制器理论上有全局信息，但路网一扩大，联合状态空间指数爆炸，任何单点故障都可能拖垮整个区域。多智能体的价值在于每个路口保留自治能力，只交换有限信息就能实现区域协调，这更接近真实城市路网的运维预期。因此这个仿真系统的核心是“自治 + 协作”，不是“中央 + 指令”。

状态设计最常见的做法是包含三类信息：本路口各车道的排队长度、当前相位编号、相邻路口的压力。排队长度是核心，因为它直接反映拥堵程度；相位编号让智能体知道切换的成本；邻居压力信息是后面做区域协调的地基，先记着。动作空间有两个候选：离散动作（保持/切换）或者连续动作（绿灯延长秒数）。实战里我一般先选离散动作，因为Q-learning的表格更新直观，训练也稳定，后续论文或答辩也好解释。

奖励函数用“负的平均排队长度”或“负的车均等待时间”最直接。注意奖励要尽可能反映长期后果，不能让智能体只贪图当前一步。信号控制的博弈周期长，来回切换相位会在几分钟后才体现到下游排队上，所以奖励设计天然有延迟属性，这一点在第四章训练闭环里要重点处理。

2.2 多智能体协调的三种协作粒度

多智能体不是多个单路口Agent的简单叠加，关键在Agent之间有没有信息往来。我把协作粒度分成三档，这个分层在你写文档做对比实验时非常有用。

第一档是独立学习：每个路口只看自己的状态做决策，训练最简单，但区域层面没有协同，很容易出现“上游放水、下游接不住”的情况。第二档是信息共享：每个路口把相邻路口的排队长度作为额外状态输入。它是性价比最高的一档，代码改动也不大，正好适合这个标题项目的核心实现。第三档是动作协商：多个Agent联合决策，例如两个路口同时决定切换方向，这需要对联合动作空间建模，训练成本高，仿真里容易出现组合爆炸，不建议新手一上来就碰。

做这个标题下的仿真项目，我的建议是先从第一档起步，把它作为基线跑通，然后升级到第二档，用结果对比体现多智能体的价值。也就是说，这个项目的核心多智能体机制通常落在第二档量级：状态里能看到邻居信息，但每个路口仍然保留自己的Q表。这个方案能让你在有限算力下跑出区域协调的效果，又不会因为联合动作空间太大导致训练发散。

这两档的差异在代码层面就几句话：独立学习的get_state_key只组装own_queues，信息共享版本多拼一个neighbor_queues。但正是这几句话，决定了整个系统是“多个单路口”还是“真正多智能体”。

2.3 相位结构与仿真时间粒度：先定标尺再写代码

在写信号控制逻辑前，先把相位止环结构定清楚。一个标准十字路口最少四个相位：东西直行、东西左转、南北直行、南北左转。每个相位要有最小绿灯时间，防止频繁切换导致的绿灯损失；切换时需要黄灯过渡，一般设3到5秒。很多新手会把黄灯省掉，结果智能体学会了每秒钟都切换相位来刷奖励，这是后面章节要展开的翻车点。

这张表是后面所有代码的配置基准。仿真时间粒度我一般选1秒一个步长，而决策周期单独设置，比如每5秒让智能体做一次动作决策。这里有个容易被忽略的点：决策周期不等于仿真步长。如果智能体每个仿真秒都决策，动作空间再小也容易抖；如果决策周期太长，车辆放行又不够灵活。5秒决策、1秒推进，是我自己试下来比较稳的组合，既能捕捉车流变化，又给Q-learning足够的收敛空间。

这个“双层时间”的设计需要你提前定好，否则第四章写训练循环时会在时序上反复返工。固定配时信号机用30秒周期，多智能体用5秒决策周期，两者对比才公平——多智能体的优势不来自它能更频繁地切换，而来自它切得准。

3. 仿真环境搭建：写一个能跑通的路口群仿真器

3.1 选型：为什么自建轻量仿真器而不是直接上大型平台

仿真平台的选择直接决定后续调试体验。功能完整的大型开源交通仿真平台路网精细、模型丰富，但状态暴露得不够自由：你想让智能体读取某个车道的排队长度，往往要绕一层接口；想修改信号控制逻辑，还得摸清内部事件模型。这些都是一层一层的黑匣子，对做算法验证的人来说，调试成本远比想象的高。我一般会先自建一个轻量仿真器，路网简单但状态完全可控，把多智能体算法跑出趋势，再考虑迁移到更精细的平台。

这个方案适合标题里的仿真项目吗？合适。多智能体信号控制的本质是验证“协调机制能否降低路网延误”，并不需要验证车辆跟驰模型有多精细。轻量仿真器把微观车辆运动简化为排队与服务模型：绿灯放行时车辆按饱和流率离开，红灯时排队累积，这个精度对评估信号策略完全够用。反过来说，把仿真做得越复杂，越难解释每一个排队变化的原凶，反而会让算法对比的结论模糊。

自建仿真器的另一个好处是训练速度。多智能体训练动不动跑几百个回合，每回合1800仿真秒，如果每个步长都做跟驰碰撞检测，训练时间会拖到不可接受。轻量仿真器一个回合只需要零点几秒，你才有耐心做参数扫描和消融实验。我见过太多人把时间耗在等待大型仿真平台的训练上，最后论文结论却很单薄。

3.2 路网与车辆生成：一个双路口串行路网的最小实现

下面开始搭建可复现的仿真器。先定义一个双路口串行路网：路口A在西侧，路口B在东侧，中间由一条主干道连接。每个路口有四条进口道，每条进口道区分直行和左转两个流向（右转不受控）。车辆按泊松过程近似生成，以一定概率选择转向。

import random from dataclasses import dataclass # 车辆：记录进入路网时间、途经路口与转向意图 @dataclass class Vehicle: enter_time: float # 进入路网的时间（秒） route: list # 途经路口ID，如 ['A', 'B'] turn: str # 转向意图：'through' / 'left' entry_lane: str = '' # 进入路网的车道ID # 路网：双路口串行结构，车道命名规则：路口_进口方向_流向 class RoadNetwork: def __init__(self): self.intersections = ['A', 'B'] # 只列出主要受控车道，右转不参与信号控制 self.lanes = [ 'A_W_through', 'A_W_left', 'A_E_through', 'A_E_left', 'A_N_through', 'A_N_left', 'A_S_through', 'A_S_left', 'B_W_through', 'B_W_left', 'B_E_through', 'B_E_left', ] def generate_vehicle(self, cur_time, rate=0.4): # 以固定概率近似泊松到达，rate 控制车流强度 if random.random() < rate: entry = random.choice(['A_W', 'A_E', 'A_N', 'A_S']) if entry == 'A_W': # 西侧进入的车流穿越 A，再到达 B，用于制造上下游接力拥堵 route = ['A', 'B'] else: route = ['A'] turn = 'through' if random.random() < 0.7 else 'left' lane = f'{entry}_{turn}' return Vehicle(enter_time=cur_time, route=route, turn=turn, entry_lane=lane) return None

逻辑说明：这里用固定概率近似泊松到达，每个仿真秒以rate概率生成一辆车，比严格控制到达间隔简单，也足够支撑后续算法对比。车辆路由故意简化：只有从西侧进入的车辆需要依次通过A和B两个路口，这样“上游放水、下游排队”的现象容易复现。entry_lane把进入方向和转向意图拼成车道ID，存入车辆对象，供仿真主循环入队使用。

参数说明：rate=0.4表示平均每秒约0.4辆车进入路网，双路口下已经能让B路口出现周期性排队。压力不足时把rate调到0.6到0.8，排队会快速累积，多智能体的协调价值更明显。turn的转向概率默认0.3，左转车比例会显著影响左转相位的压力，初跑保持默认即可。

3.3 信号灯控制器：相位切换与车辆放行的最小实现

信号灯控制器要处理三件事：维护当前相位、执行相位切换（含黄灯过渡）、根据相位放行排队车辆。放行逻辑采用简化饱和流率模型：绿灯相位下，每条放行车道每秒最多通过一辆车，排队不足则按实际排队数放行。

class SignalPhase: def __init__(self, name, lanes, green_min=10, yellow=3): self.name = name # 相位名，如 'EW_THROUGH' self.lanes = lanes # 该相位放行的车道ID列表 self.green_min = green_min # 最小绿灯时间，防止频繁切换 self.yellow = yellow # 黄灯过渡时间，秒 self.green_timer = 0 # 当前相位已运行时间 self.state = 'red' # 'green' / 'yellow' / 'red' class SignalController: def __init__(self, phases): self.phases = phases # 相位列表，按环顺序排列 self.current_idx = 0 self.phase = self.phases[0] # 供智能体调用：请求切换相位 def request_switch(self): if self.phase.green_timer < self.phase.green_min: return False # 绿灯时间不足，拒绝切换 self.phase.state = 'yellow' self.phase.green_timer = 0 return True def step(self): # 每个仿真秒推进一次 if self.phase.state == 'yellow': self.phase.yellow -= 1 if self.phase.yellow <= 0: self.phase.state = 'red' self.current_idx = (self.current_idx + 1) % len(self.phases) self.phase = self.phases[self.current_idx] self.phase.state = 'green' self.phase.green_timer = 0 elif self.phase.state == 'green': self.phase.green_timer += 1 def release_vehicles(self, queues): # 按当前相位放行对应车道的排队车辆，返回释放数量 released = [] for lane in self.phase.lanes: if lane in queues and queues[lane]: v = queues[lane].pop(0) released.append((lane, v)) return released

逻辑说明：request_switch是智能体和信号灯之间的唯一接口，只有当前绿灯运行时间超过green_min才接受切换请求，这是防止智能体刷奖励的第一道防线。step负责黄灯倒计时和相位轮转，黄灯结束后才切到下一绿灯相位。release_vehicles按当前相位映射放行车道，每条车道每秒放行一辆，模拟饱和流率，返回被释放车辆及其车道，供主循环处理车辆移动。

参数说明：green_min=10是最小绿灯秒数，太小会让主干道车辆频繁被打断，太大又会让智能体动作空间失去意义。yellow=3是黄灯过渡时间，直接关系相位切换的安全性与绿灯损失，一定不能省略。实际跑的时候可以把green_min调成5和15各跑一轮，观察平均等待时间的差异，这个敏感度分析放进实验报告会很有说服力。

3.4 仿真主循环：时间步进、车辆移动与数据采集

仿真主循环负责推进时间、生成车辆、更新信号灯、移动车辆并采集排队数据。每条进口道用一个列表保存排队车辆，绿灯释放时从队首弹出，若有后续路口则进入下游对应车道排队，否则离开路网。

class Simulation: def __init__(self, network, controllers, duration=1800): self.network = network self.controllers = controllers # 路口ID -> SignalController self.duration = duration self.queues = {} # 车道ID -> 车辆列表 self.vehicles = [] # 已生成车辆 self.completed_vehicles = [] # 已离开路网的车辆 self.wait_times = [] # 每个仿真秒的排队总数 self.t = 0 def step(self): self.t += 1 # 1. 生成新车辆并入队 v = self.network.generate_vehicle(self.t) if v: self.vehicles.append(v) self.queues.setdefault(v.entry_lane, []).append(v) # 2. 信号灯推进并放行车辆 for iid, ctrl in self.controllers.items(): ctrl.step() released = ctrl.release_vehicles(self.queues) for lane, rv in released: rv.current_link = lane if len(rv.route) <= 1: # 已通过最后一个路口，离开路网 self.completed_vehicles.append(rv) else: # 沿路由进入下一路口对应车道 next_iid = rv.route[1] next_lane = f'{next_iid}_W_{rv.turn}' self.queues.setdefault(next_lane, []).append(rv) # 3. 统计当前仿真秒的排队总数 self.wait_times.append(sum(len(q) for q in self.queues.values()))

逻辑说明：主循环拆成三步：生成车辆、信号灯放行与车辆移动、排队统计。被释放的车辆如果路由只剩一个路口，就直接进入completed_vehicles；如果还要经过下一个路口（比如从A到B），则放入下游对应车道的队列。这样“A放行、B排队”的接力关系就建立起来了，多智能体协调才有意义。wait_times记录每个仿真秒的路网总排队数，它是计算平均等待时间和训练奖励的数据源。

数据采集这一步看起来简单，但它是整个实验的命根子。建议除了全局排队总数，还要按路口分别记录排队长度快照，每10秒采一次。后面做多智能体协调时，你只有看到“A路口平均排队下降、B路口平均排队上升”才能判断算法是在上游放水还是整体优化，只看全局平均会掩盖掉这类问题。

提示：轻量仿真器的目的是验证控制策略的相对优劣，而不是拟合真实交通流。当你把仿真做复杂到无法解释每一个排队变化时，它就失去了作为算法验证工具的价值。

4. 多智能体算法实现：从单路口Q-learning到双路口协同

4.1 Q-learning智能体：状态离散化与动作选择

多智能体算法这块，我选择Q-learning作为主算法，原因只有一个：表格型Q-learning的每一步决策都能回溯，训练过程完全可见，适合做教学、竞赛和毕业设计答辩。神经网络版本（DQN）可以放在扩展阶段，但先把表格逻辑跑通更重要。

状态设计是Q-learning落地最关键的环节。连续值（排队长度、等待时间）不能直接作为状态索引，必须离散化。我常用的离散化方法是把排队长度除以量化单位后取整：0到2辆编码为0，3到5辆编码为1，6到8辆编码为2，以此类推。状态维度包括本路口各进口道排队桶、当前相位编号，以及在协调版本里的邻居路口排队桶。

class QLAgent: def __init__(self, alpha=0.1, gamma=0.9, epsilon=0.2): self.q_table = {} # 状态元组 -> [保持相位Q值, 切换相位Q值] self.alpha = alpha # 学习率：新经验覆盖旧经验的程度 self.gamma = gamma # 折扣因子：未来奖励的权重 self.epsilon = epsilon # 探索率：随机动作的概率 def discretize_queue(self, queue_len): # 排队长度 -> 离散桶，每3辆一个档位，上限7 return min(queue_len // 3, 7) def get_state_key(self, queue_lengths, phase_idx, neighbor_lengths=None): # queue_lengths: dict，键为车道名，值为排队长度 state = [self.discretize_queue(queue_lengths[lane]) for lane in queue_lengths] state.append(phase_idx) if neighbor_lengths: # 邻居排队信息编码进状态，这是多智能体协调的关键 for lane in neighbor_lengths: state.append(self.discretize_queue(neighbor_lengths[lane])) return tuple(state) def choose_action(self, state_key): # epsilon-greedy：以epsilon概率随机探索，否则选Q值最大的动作 if random.random() < self.epsilon: return random.randint(0, 1) # 0=保持相位，1=请求切换 values = self.q_table.get(state_key, [0, 0]) return 0 if values[0] >= values[1] else 1 def update(self, state_key, action, reward, next_state_key): # 标准 Q-learning 更新公式 old_q = self.q_table.setdefault(state_key, [0, 0])[action] next_q = max(self.q_table.get(next_state_key, [0, 0])) new_q = old_q + self.alpha * (reward + self.gamma * next_q - old_q) self.q_table.setdefault(state_key, [0, 0])[action] = new_q

逻辑说明：get_state_key把原始排队数据编码成可哈希的状态元组，这是Q表索引的基础。choose_action在探索与利用之间平衡，epsilon=0.2意味着20%概率随机选动作，避免智能体过早收敛到局部最优。update就是标准Q-learning公式，alpha控制单次更新步长，gamma控制未来奖励的折算。加入neighbor_lengths后，状态里就带上了相邻路口的压力信息，这是第四种协调粒度的最小实现。

参数说明：状态桶上限设7是为了控制Q表规模：单路口4条进口道加相位编号，状态数约在几百量级，表格撑得住。加入邻居信息后状态维度翻倍，Q表会膨胀到几万量级，训练时间明显变长，这是多智能体协调必须付出的代价。alpha=0.1和gamma=0.9是经验默认值，前者太大会导致训练震荡，后者太小会让智能体只看眼前几步，把信号控制这种长周期问题做坏。

4.2 单路口训练闭环：把智能体接进仿真主循环

现在把Agent接进上一章的仿真器，跑一个单路口的训练闭环。每个决策周期（5秒），智能体读取当前状态，决定是否切换相位；每个仿真步，用当前排队总数取负作为即时奖励。

def setup_controller(iid): phases = [ SignalPhase('EW_THROUGH', [f'{iid}_W_through', f'{iid}_E_through']), SignalPhase('EW_LEFT', [f'{iid}_W_left', f'{iid}_E_left']), SignalPhase('NS_THROUGH', [f'{iid}_N_through', f'{iid}_S_through']), SignalPhase('NS_LEFT', [f'{iid}_N_left', f'{iid}_S_left']), ] return SignalController(phases) def train_single_intersection(episodes=300, steps_per_episode=1800): agent = QLAgent() metrics = [] # 每个回合的平均排队数 for ep in range(episodes): sim = Simulation(RoadNetwork(), {'A': setup_controller('A')}) last_decision = 0 while sim.t < steps_per_episode: if sim.t - last_decision >= 5: # 每5秒决策一次 state = agent.get_state_key( sim.get_queue_lengths('A'), sim.controllers['A'].current_idx ) action = agent.choose_action(state) if action == 1: sim.controllers['A'].request_switch() last_decision = sim.t sim.step() # 即时奖励：排队总数越小越好 reward = -sim.wait_times[-1] agent.update(state, action, reward, state) metrics.append(sum(sim.wait_times) / steps_per_episode) return agent, metrics

逻辑说明：setup_controller是环境初始化辅助函数，返回含四个相位的SignalController。训练循环里用了即时奖励更新：每个仿真步用当前排队总数取负作为奖励，让智能体能立刻感知动作效果。信号控制是连续决策问题，即时奖励比回合末延迟更新收敛更快，也更容易调试。state在决策时刻更新，但Q-table在每个仿真步都更新，这是我推荐的做法。

参数说明：episodes=300表示训练300个回合，每个回合1800仿真秒（模拟30分钟高峰）。如果发现Q表还没收敛，把episodes加到500。决策间隔固定5秒，reward = -sim.wait_times[-1]是每步排队总数，单位是“辆×秒”，数值越大代表越堵，取负号让智能体学会减少排队。这里没有对reward做归一化，训练前期数值波动大是正常的。

4.3 双路口协调：把邻居排队长度加入状态

多智能体协调的落地，在代码层面就是改状态组装：原来只看本路口的队列，现在把邻居路口的出口道队列也拼进状态。这样A路口的智能体在做放行决策前，能“看到”B路口是否已经堵满。如果下游排队过长，它会倾向保持黄灯或减少放行，把车流压在自己这边。

def train_cooperative(episodes=300): agents = {'A': QLAgent(), 'B': QLAgent()} sim_factory = lambda: Simulation( RoadNetwork(), {'A': setup_controller('A'), 'B': setup_controller('B')} ) metrics = [] for ep in range(episodes): sim = sim_factory() last_decision = 0 # 记录每个路口的累计排队惩罚 total_penalty = {'A': 0, 'B': 0} while sim.t < 1800: if sim.t - last_decision >= 5: for iid, agent in agents.items(): own = sim.get_queue_lengths(iid) # 邻居路口出口道排队长度，即邻居在主干道方向上的压力 neighbor = sim.get_queue_lengths(get_neighbor(iid)) state = agent.get_state_key( own, sim.controllers[iid].current_idx, neighbor ) action = agent.choose_action(state) if action == 1: sim.controllers[iid].request_switch() # 增量奖励：本路口排队 + 邻居排队的加权和 neighbor_penalty = sim.get_total_queue(get_neighbor(iid)) * 0.3 total_penalty[iid] += sim.get_total_queue(iid) + neighbor_penalty last_decision = sim.t sim.step() # 回合结束用累计奖励做一次整体更新 for iid, agent in agents.items(): agent.update(state, action, -total_penalty[iid], state) metrics.append(-sum(total_penalty.values())) return agents, metrics

逻辑说明：关键改动是get_state_key多了neighbor参数，状态从“本路口4条进口道+相位”扩展成“本路口4条进口道+邻居出口道+相位”。两个路口各自维护独立的Q表，但决策时能看到对方压力。奖励函数在本路口排队之外，额外加了邻居排队加权项，权重0.3是经验起点，目的是让智能体在“自己放行”与“让邻居堵车”之间找平衡。这就是第二档协作粒度“信息共享”的完整代码形态。

参数说明：neighbor_penalty的0.3是协调强度的关键参数，调大协调更激进但容易两边都不敢放行，调小则退回单路口效果。get_neighbor是辅助函数，对A返回B，对B返回A。如果你把这个权重设成1.0，会看到第四章避坑指南里的“踢皮球”现象，模型学到的最优策略是什么都不做。

4.4 基线对照与评估：怎么量化多智能体的收益

有了单路口和双路口的实现，最后一步是搭一个评估函数，把“固定配时”和“多智能体协调”放在同一组随机种子下对比。评估指标用平均等待时间、最大排队长度和吞吐量三个维度，缺一个结论都容易偏。

def evaluate_policy(policy, seeds=[42, 7, 2024]): avg_waits = [] for seed in seeds: random.seed(seed) # 固定种子，保证不同策略在同一车流下对比 sim = Simulation(RoadNetwork(), setup_by_policy(policy)) while sim.t < 1800: if policy == 'fixed': # 固定配时：每30秒自动切换相位，与车流状态无关 if sim.t % 30 == 0: for ctrl in sim.controllers.values(): ctrl.request_switch() else: # 多智能体：每5秒决策一次 if sim.t % 5 == 0: for iid, ctrl in sim.controllers.items(): state = build_state(sim, iid, agents) if agents[iid].choose_action(state) == 1: ctrl.request_switch() sim.step() completed = len(sim.completed_vehicles) avg_wait = sum(sim.wait_times) / max(completed, 1) avg_waits.append(avg_wait) return sum(avg_waits) / len(avg_waits)

逻辑说明：评估函数把三类策略装进同一个壳子里跑。固定配时用30秒周期模拟传统信号机，不依赖车流状态，作为人类直觉的基线；单路口智能体作为第一档，双路口协调作为第二档。多智能体每5秒读一次状态做决策，动作更频繁，所以评估结果对奖励和状态离散化非常敏感。

参数说明：seeds=[42, 7, 2024]是固定的一组随机种子。每轮评估换一个新种子，但所有策略都用同一组种子，这是对比实验能成立的前提。如果方差太大，把种子数加到10个取平均。记住一个原则：评估时用训练中没见过的车流序列，但同一组序列要在所有策略上重放，否则就是在偷看考卷答案。

注意：如果你的训练回合数只有100，而状态空间因为加入邻居信息翻倍了，Q表里大量状态从未被访问，评估结果会非常难看。多智能体协调需要更多训练回合来弥补状态空间的膨胀，这是第四章代码里最值得你花时间调的地方。

5. 多智能体信号控制避坑指南：训练不收敛、效果反差的常见原因

5.1 现象：Q表一直在更新，但平均等待时间不见下降

Q表数值确实在变，但平均等待时间没有下降趋势，甚至缓慢上涨。排查时先打印每个回合的总奖励和平均排队长度，你会发现奖励值剧烈震荡，说明智能体看到的奖励与实际路网状态脱节。

原因通常有两个：一是决策周期太短，每隔2秒就决策一次，相位还没放完几辆车就被切换，路网长期处于黄灯过渡状态；二是奖励函数里只有排队惩罚，没有给绿灯放行的车辆正反馈，模型学到的策略是尽量红灯，把车堵在源头不产生新排队。

解决：把决策周期从2秒加到10秒，给绿灯相位足够的放行时间；奖励改成排队惩罚加放行收益的组合，例如每释放一辆车给1分，每排队一秒扣0.1分。这样Q表学到的策略才会从“不做事”变成“有序放行”。

5.2 现象：加入邻居状态后性能反而比单路口差

单独训练时A路口平均等待时间降了20%，把邻居排队信息加进去重训，两个路口的总体表现反而比单路口还差。这是多智能体项目最常翻车的地方。

原因：邻居排队长度进入状态后，状态空间成倍膨胀，但训练回合数没有相应增加，Q表大量状态从未被访问，智能体在探索期被迫做大量随机动作。更常见的错误是堆信息：把邻居路口四条进口道全加进状态，状态维度翻四倍，Q表从几千冲到几万，训练自然跟不上。

解决：先只加邻居出口道（即主干道方向那条车道）的排队信息，不要加全部进口道；训练回合数从200加到400到500，必要时把探索率从0.2降到0.1。改完再看两路口各自的平均排队曲线，确认是“A降B升”还是“AB齐降”——前者说明协调起作用了，后者说明奖励还不够合理。

5.3 现象：智能体学会了频繁切相位，绿灯形同虚设

训练出的策略几乎每个决策周期都请求切换相位，黄灯频繁亮起，车流通行效率比固定配时还低。这个坑我在第一次做信号控制项目时也踩过：看训练曲线，等待时间确实在下降，但回放仿真过程，车根本没有连续通过几个绿灯周期。

原因：仿真器里黄灯的3秒过渡被智能体当成“清排队的空档”，切换相位能打乱排队累积节奏，让惩罚重新计算。如果信号灯控制器允许在绿灯运行不足最小绿灯时间时请求切换，智能体立刻钻这个空子。

解决：把green_min从10秒提高到15秒，并把“当前相位已运行秒数”的离散桶加进状态，让智能体学到切换是有成本的动作。同时检查request_switch实现，确保绿灯计时不足时直接拒绝请求——这正是3.3节里green_min防线的作用。这个参数值得单独做一轮敏感性实验。

5.4 现象：多轮实验波动极大，无法判断算法优劣

同一套代码连着跑五遍，平均等待时间一会儿700一会儿1100，误差带把两组实验的差异盖得严严实实，结论完全站不住脚。

原因：仿真器里到处都是随机源：车辆生成随机、转向选择随机、Agent探索动作随机。只要有一个随机源的种子没固定，整个实验序列就不可复现。排查方法是把代码里所有random.random()调用列出来，逐一代入统一种子。

解决：在训练和评估入口统一调用random.seed(seed)，每组对比实验用同一组seed，如[42, 7, 2024]。另外，把等待时间从每回合一个数值改成每10秒采一次样，先画单回合平滑曲线，再画多回合平均，视觉上的波动感会大幅降低。随机种子固定是实验结果可信的前提，答辩时老师第一个问的就是这个。

5.5 现象：奖励加邻居惩罚后，两个路口都开始不放车

为了强化协调，把邻居排队直接加权放进奖励，例如reward = -own_queue - 0.8 * neighbor_queue，结果两个路口都倾向长期红灯，车流被压在路段中间，吞吐量跌到谷底。

原因：邻居惩罚权重太大，智能体把“让邻居排队变小”当成第一目标，但它唯一能控制的是自己的绿灯——放行只会让邻居排队变长，于是干脆不放行。这是多智能体奖励设计里的典型“踢皮球”问题，每个路口都在等对方先动。

解决：邻居惩罚权重先设0.3，并且只在邻居排队超过阈值时生效，例如penalty = 0.3 * max(0, neighbor_queue - 6)。让智能体只有在邻居真正拥堵时才克制放行，平时保持独立决策。这样既体现协调，又不会让模型学到消极怠工。改完这一条，你会在指标里看到吞吐量重新回升。

6. 让仿真结果更可信：参数调优与指标验证的实战技巧

做到前五章，双路口多智能体信号控制的仿真已经能跑通，但实验报告和项目答辩更看重的是“你的算法为什么更优”。这个结论要在评估阶段站稳，我习惯再加三个验证技巧。

第一个技巧是加P90尾部指标。平均等待时间会把偶发长时排队抹平，两个算法平均值一样，但一个每天有几次几百秒的极端拥堵、另一个稳定输出，结论完全不同。把每回合所有车辆的等待时间按升序排列，取第90百分位数，能直观看出哪套策略更稳。我在项目里加了这个指标后，发现单路口算法平均值不差，但P90比固定配时高出近一倍，答辩时拿这张图出来，比单说平均值有力得多。

第二个技巧是固定配时基线要设计得公平。把固定配时的绿灯时长从30秒改成25秒和35秒各跑一遍，配合低流量（rate=0.3）和高流量（rate=0.7）两组车流强度，做2乘3的消融网格。你会发现在低流量下固定配时接近最优，多智能体的优势集中体现在高流量且车流不均匀的场景——这个结论本身就是项目的研究价值所在。

第三个技巧是参数敏感性扫描。挑决策周期、最小绿灯时间、邻居惩罚权重这三个参数，每个取三档，做小规模网格搜索。三参数三档是27组，每组跑3个随机种子，总共81次实验，轻量仿真器几分钟就能跑完。把结果画成热力图，你能直观看到哪些参数对平均等待时间影响最大，这份图在项目文档和答辩里都很有说服力。

最后说一个我自己的教训：最早做类似项目时，我把精力全花在调Q-learning参数上，忽略先搭固定配时的基线。后来导师问了一句“你的算法比传统信号机好多少”，我把基线补上，跑出来的差异让我重新改了两版奖励函数。所以现在做信号控制仿真，第一件事永远是先把基线跑稳，再谈算法优化。希望帮到你。

本文还有配套的精品资源，点击获取