简介一份基于多智能体算法的城市交通信号控制仿真系统项目源码包面向交通仿真研究者、算法开发者及高校相关专业学生用于解决传统信号控制难以适应复杂动态车流的问题。文件总数173个以C与Python源码、JSON配置数据为主配有CMake构建、Markdown说明、YAML环境及PDF文档涵盖核心多智能体协同模块便于直接编译与二次开发。包体约49.64MB已有241人学习。系统将信号灯视为独立智能体进行通信协商提供交通流建模、信号策略、评价指标与实时仿真等完整链路可灵活调整控制策略并输出多维度结果是理解分布式人工智能与控制理论在智能交通中落地的实战项目。仿真环境支持重复实验与控制变量可安全且高效地评估不同信号方案的效果。1. 多智能体交通信号控制用协作决策解决城市路口的连锁拥堵当车流进入晚高峰固定配时的最直观问题不是某一个路口堵死而是“堵完这个路口把车流推到下一个路口”整条路网像被打了死结。多智能体算法这个方向是让每个交叉口成为一个独立决策的智能体各自能观测本路口和相邻路口的排队、车流信息再通过协作式动作选择来动态调整信号相位而不是靠一个中央调度器统一下发配时方案。这个思路在交通信号控制仿真系统里尤其合适因为路口的分布天然就是去中心化的路口与路口的耦合又是局部的和多智能体系统的建模假设高度吻合。这类实战项目适合两类人一是做智慧交通相关方案验证的开发者需要在仿真环境里证明算法比固定配时有效二是想系统掌握多智能体强化学习完整落地流程的从业者需要一套能跑通、能改参数、能观察效果的最小闭环。2. 核心设计状态、动作与奖励怎么定义才能让多智能体协作成立2.1 为什么单路口优化在城市路网里会失效很多第一次接触交通信号控制的开发者第一反应是“直接用一个强化学习智能体去学某个路口的配时”跑出来的结果往往不差换到相邻两个路口一起调的时候就崩了。原因是单路口策略的优化目标没有考虑下游承受能力。绿灯延长意味着上游放行的车会在下游排队甚至是更长的排队。多智能体算法的本质差异在于每个智能体的奖励里要加入邻居路口的反馈让“自己通畅但让邻居堵死”的局部最优变成负奖励。这个设计直接决定了多智能体方案和单路口方案的优劣边界。我在实际搭建这类仿真系统时最常被问的问题是“为什么不用集中式强化学习把所有路口的联合状态扔进一个网络”。理论上可行但在真实城市路网里联合状态空间的规模会随路口数量指数膨胀收敛速度和训练成本都不可控。多智能体的思路是把决策权下放给每个路口通过局部信息交换来逼近全局最优。代价是非平稳性问题每个智能体的环境包含了其他智能体正在变化的策略。这也是后面第 5 章要重点展开的调试点。2.2 智能体画像与信号相位建模每个路口智能体需要明确四个部分观测空间、动作空间、状态转移方式和奖励函数。对照项目里常见的交叉口模型一个典型智能体配置如下表格所示。设计项常见配置说明智能体数量路网中的信号控制交叉口数每个信号控制路口独立一个 Agent不控制的人行横道与匝道不建智能体观测空间当前相位、本路口各方向排队长度、相邻路口排队长度、当前相位已持续时间排队长度是交通仿真里最容易获取且最稳定的特征动作空间保持当前相位 / 切换到下一相位动作空间越少越容易收敛按相位顺序切换避免出现跳变冲突状态转移由 SUMO 仿真引擎推进每 5 秒做一次决策决策周期太短会让信号频繁切换太长会对突发车流反应迟钝相位建模要格外注意相位顺序。四相位交叉口在 SUMO 里的典型顺序是南北直行、南北左转、东西直行、东西左转。如果代码里把相位 index 和真实路口的相位顺序搞错智能体看似在学策略实际学的是一个错误的信号切换时序最后发散是必然的。我在做这类项目时第一步永远是打开 SUMO GUI把所有相位截图核对一遍再进代码。2.3 奖励函数设计从排队长度到通行效率奖励函数是多智能体交通控制项目里“玄学”最多的地方也是最容易翻车的模块。如果只给队长度负奖励智能体很快会发现延长绿灯能清空当前排队但它不管这个绿灯放行方向的下游路口是不是已经饱和。常见的做法是奖励里同时包含三个部分本路口排队长度变化本周期结束时排队长度比上周期减少给正奖励通过车辆数在决策周期内实际通过交叉口的车辆数作为通行效率的度量表达式为 throughput 进口道通过的车辆数邻居路口排队长度惩罚以相邻路口排队长度均值的一定权重计入负奖励权重系数通常取 0.3 到 0.5让智能体“做决策时考虑到邻居”。用公式可以写成reward waiting_diff * w1 throughput * w2 - neighbor_queue * w3代码里的w1、w2、w3是三个权重参数典型取法是0.4、0.3、0.3表示排队缓解和通行效率是主要目标邻居协作是次要约束项。如果奖励里没有neighbor_queue系统退化成多个独立单路口强化学习智能体效果常常比固定配时还差。这里的经验是权重不要一次定死先用均匀权重跑一版观察是哪个路口先出现拥堵转移再针对性调权。奖励的设计决定了整个多智能体系统是“表面热闹”还是真正能落地到城市路网上。3. 仿真环境搭建SUMO 与 Python 联动的最小闭环3.1 仿真工具选型与场景建模选仿真环境时要考虑三点能不能提供微观车辆轨迹能不能实时控制信号灯有没有 Python 接口。常见的做法是选开源交通微观仿真工具 SUMO配合其 Python 接口traci来动态控制每个交叉口的信号相位。SUMO 的优势在于每个车辆的跟车模型、换道模型都内置且支持多路口路网不是那种只能画单条道路的简易仿真器。路网建模有两种常见路径最简单的是用 SUMO 自带工具生成一个矩形网格路网足够验证多智能体算法的核心效果更贴近真实情况的是导入 OpenStreetMap 的路网数据再人工检查交叉口拓扑。项目实战中第一次跑通建议用两到四个交叉口的网格路网起步因为多智能体协作的最小可验证场景就是两个相邻路口之间的拥堵传递问题。3.2 用 traci 启动 SUMO 并循环推进仿真跑通整个系统的最小闭环在于三件事启动仿真、在每一仿真步读取车辆与信号灯状态、决策后写回信号灯相位。下面这段代码是骨架也是多智能体实战项目通常的入口逻辑。import traci import sumolib SUMOCFG grid.sumocfg # 仿真配置文件内含路网和车流定义 traci.start([sumo, -c, SUMOCFG, --no-warnings, true]) step 0 while step 3600: # 仿真 3600 步对应 1 小时步长 1 秒 traci.simulationStep() # 读取两个关键观测量各路口排队长度与当前信号相位 for tls_id in traci.trafficlight.getIDList(): lane_ids traci.trafficlight.getControlledLanes(tls_id) queue sum(traci.lane.getLastStepVehicleNumber(lane_id) for lane_id in lane_ids) phase traci.trafficlight.getPhase(tls_id) # 这里把 queue 和 phase 交给智能体决策 # 决策结果通过 setPhase 写回信号灯 # traci.trafficlight.setPhase(tls_id, next_phase) step 1 traci.close()这段代码的关键在于先读后写每步先拿信号灯控制的 lane 集合汇总各车道车辆数作为排队长度再对每个交叉口执行决策。--no-warnings不是必须的但在训练阶段能避免 SU MO 的详细警告刷屏traci.simulationStep()默认推进一个仿真秒如果需要更细的步长可以传入参数如 0.1。3.3 路网与车流配置的最小文件用 SUMO 做多智能体仿真最容易被卡住的是.net.xml和.rou.xml两个文件。.net.xml描述路网拓扑.rou.xml描述车辆从哪里出发、往哪里去、什么时候出发。一个最小两路口路网通常由netedit手工绘制生成也可以直接用命令行工具生成网格路网# 生成 3x3 网格路网每段路 200 米含信号灯 # 这是 sumo 工具链里的命令通常放在 shell 里执行 netgenerate --grid --grid.number3 --grid.length200 --grid.attach-length50 \ --tls.default-typeactuated --output-filegrid.net.xml--grid.number3是 3x3 网格即九个交叉口能满足多智能体场景的协作验证--grid.length200控制路网尺寸--tls.default-typeactuated表示给交叉口配信号灯这一步很重要否则生成的 net 文件里没有 traffic light后面 traci 的trafficlight.getIDList()会拿到空列表。很多新手在这里翻车现象是代码没有报错但没有任何信号灯 ID 被读取到。车流文件.rou.xml的常见做法是用随机车流生成器批量生成避免手写每个车辆的出发时间。例如让两条主路的车流量明显高于支路形成潮汐车流才更容易看出多智能体算法的调节效果。仿真配置.sumocfg指向 net 和 rou 文件然后在代码里通过-c参数启动整个最小闭环就能跑通。4. 多智能体强化学习实现基于 Q-learning 的协作控制4.1 离散状态与动作空间设计用 Q-learning 做多智能体信号控制状态设计直接决定训练能否收敛。如果直接把每个车道的车辆数拼成一个高维向量Q 表会稀疏到完全学不出来。常见做法是对每个观测做离散化当前相位例如相位编号 0、1、2、3相位已持续时间按 5 秒一个档位分成三个级别短、中、长本路口各方向排队长度总和超过阈值记为 1否则为 0阈值取 10 辆车是个不错的起点邻居路口压力邻居排队总长度是否超过本路口排队总长度。这个设计的含义是每个路口智能体不需要知道精确到个位数的排队车辆数只需要知道排队大致处于“拥堵”或“通畅”的哪一档。交通控制的容错度很高档位离散化反而能提升泛化能力让学到策略从“特定车流”泛化到“一类车流模式”。动作空间保持二值保持当前相位或者切换到相位顺序中的下一个相位。很多项目把动作设计成“延长 5 秒 / 延长 10 秒 / 切换”但 Q-learning 对这种多选项组合的收敛速度很慢训练前期全是无意义的探索。先收敛再加连续动作是更稳的路径。4.2 Q-learning 更新与训练主循环核心更新公式是标准 Q-learningQ(s,a) lr * (r gamma * max(Q(s,a)) - Q(s,a))。代码里的关键不在公式本身而在训练循环的整合方式。下面给出一个智能体类的最小实现import numpy as np from collections import defaultdict class TrafficAgent: def __init__(self, alpha0.1, gamma0.9, epsilon0.3): self.alpha alpha # 学习率决定新信息覆盖旧经验的程度 self.gamma gamma # 折扣因子越大越看重未来收益 self.epsilon epsilon # 探索率前期多随机探索后期渐减 self.q_table defaultdict(lambda: np.zeros(2)) # 2 表示两个动作 def act(self, state): if np.random.random() self.epsilon: return np.random.choice([0, 1]) # 随机探索动作 return int(np.argmax(self.q_table[state])) # 利用当前最优动作 def update(self, state, action, reward, next_state): best_next np.max(self.q_table[next_state]) td_target reward self.gamma * best_next td_error td_target - self.q_table[state][action] self.q_table[state][action] self.alpha * td_errorTrafficAgent类对应一个交叉口多个交叉口就是多个该类的实例。这里的state是前面离散化后的元组例如(phase_id, duration_level, queue_level, neighbor_pressure)。defaultdict(lambda: np.zeros(2))的好处是不需要事先设定状态空间大小遇到没见过的状态自动初始化 Q 值。主循环需要把 SUMO 的状态读出来转换成离散状态调用act获取动作把动作写回 SUMO最后在下一个决策周期用真实奖励更新 Q 表。决策周期通常取 5 到 10 秒不要在每一个仿真步做一次决策否则相位切换频率太高既不真实也难收敛。整体训练回合设置为 100 到 200 轮每轮仿真时长 15 到 30 分钟真实车流时间。4.3 网络级协作机制邻居信息如何进入决策要真正体现多智能体算法的价值需要把邻居路口的压力显式写进状态和奖励。做法是在状态中加入neighbor_pressure字段统计相邻路口的总排队长度与当前路口排队长度做比较如果邻居更拥堵记为 1否则为 0。这个 0/1 特征让智能体知道“我应该少放车过去还是可以继续放”。在训练循环里奖励计算需要额外读取邻居数据。这里有一个容易被忽略的细节每次决策后到下一次决策前仿真已经推进了若干秒奖励计算必须使用累计的观测值而不是只取最后一步的瞬时排队长度。更稳健的做法是在决策周期内记录每一步的排队长度取平均值作为该周期内的排队指标。瞬时排队长度受上一周期遗留信号相位影响太大智能体学到的是周期末的假象不是真实控制效果。协作机制的常见实现是所有智能体共享同一套 Q-table 逻辑但各自拥有独立的 Q 表。共享逻辑意味着状态特征的定义完全一致互相可以交换经验独立的表意味着每个路口针对自己的拓扑和车流模式做个性化调优。这个“共享逻辑、独立参数”的做法在工程上最好落地效果也稳定适合绝大多数城市路网场景。5. 实战避坑多智能体交通仿真的 5 个高频翻车点5.1 训练发散的元凶是仿真步长与配时相位错位现象智能体学了几十轮之后不仅没有收敛反而越学越差某个路口的绿灯时间越学越长排队却越来越严重。原因决策周期和 SUMO 的相位持续时间没有对齐。例如决策周期是 5 秒但 SUMO 里相位最短持续时间是 6 秒实际的信号切换时刻和代码预期的切换时刻差了 1 秒多次累积后Q 表学到的奖励和真实状态之间出现系统性偏差。解决在决策里记录phase_remaining也就是当前相位剩余时间把它作为一个离散特征放进状态里同时保证决策周期大于等于 SUMO 中phase的最小持续时间让每个决策都发生在一个完整相位周期之后。5.2 Q 表过大导致收敛太慢现象训练几百轮 Q 表仍然大面积是初始值智能体的动作看起来是随机乱选。原因状态维度设计太细例如把每个车道的车辆数精确到个位数四个进口道加四个邻居组合出来的状态数量瞬间突破十万级Q 表完全稀疏。解决把精确车辆数降级为三档排队级别即畅通、一般、拥堵邻居信息降级为 0/1 压力标记。交通信号控制决策不需要毫米级精度档位划分越粗泛化能力越强。如果项目要求更精细的连续控制可以考虑用线性函数逼近或者浅层网络替代 Q 表不要硬撑纯表格方法。5.3 奖励函数只压排队长度会导致绿灯空放现象智能体学会长时间保持某个方向的绿灯哪怕这个方向已经没有车通过导致另一个方向的车排队剧增。原因奖励函数只对排队长度做负反馈智能体发现延长绿灯能持续降低当前排队即使绿灯后期没有车通过只要排队没有增长奖励就不会下降。解决把“决策周期内的通过车辆数”加入奖励空放相位不会产生通过车辆自然会被惩罚。这是交通信号强化学习里面最典型的局部最优陷阱。5.4 多智能体同步学习的非平稳问题现象多个路口同时训练时奖励曲线剧烈震荡单独把一个路口拿出来固定其他路口策略却表现稳定。原因每个智能体的环境包含了其他智能体的探索行为大家同时在随机探索状态转移概率就不是平稳的。解决工程上最有效的手段是让邻居智能体先冻结为固定配时策略或纯利用策略只训练当前目标智能体训练好后冻住再训练下一个。等到每个智能体都完成一轮单独训练再放开联合训练做微调。这种分阶段训练能大幅降低非平稳性带来的震荡。5.5 仿真结果比固定配时还差时的排查思路现象所有训练完成后平均排队时间比固定配时融化配时还高看起来算法完全失败。原因最常见的是相位切换没有包含过渡相位例如从南北直行跳到东西左转时缺了一个黄灯或全红间隔导致交叉口内冲突实际通行效率大大降低。另一个常见原因是车流生成里高峰期和训练数据分布不一致模型没见过测试时的高峰流量。解决先跑一遍固定配时的仿真确认不换策略时的基线指标再打开 SUMO GUI 目视检查智能体控制的信号灯是否存在惊变切换最后逐步把训练车流量从单一模式过渡到多模式让智能体在训练期见过高低峰两种流量分布。6. 进阶验证用固定配时基线评估你的多智能体算法是否真的有效多智能体项目的验收不能停留在“训练曲线奖励上升了”要从路网指标层面证明算法优于基线。我会准备两套仿真配置一套是原始固定配时另一套是智能体控制。两套使用完全相同的.net.xml和.rou.xml只切换信号灯控制方式。跑完后对比三个指标平均等待时间、平均排队长度、总通过车辆数。# 评价脚本核心部分计算平均等待时间 total_wait 0.0 vehicle_count 0 for veh_id in traci.vehicle.getIDList(): total_wait traci.vehicle.getWaitingTime(veh_id) vehicle_count 1 avg_wait total_wait / max(vehicle_count, 1)getWaitingTime返回的是截止当前时刻的累计等待秒数需要在每个决策周期内多次采样取均值避免只采样一次带来的偶然性。平均排队长度用第 3 章的排队统计代码在每 10 个仿真步记录一次最后取平均。总通过车辆数直接用traci.simulation.getEndTime()后统计所有已完成车辆。运行实验时最好固定随机种子。SUMO 的随机种子在.sumocfg的random字段设置固定成同一个值能保证车流生成完全一致这样智能体和基线的差异完全来自控制策略。每个方案跑 5 次不同随机种子取均值和方差比单次结果要可靠得多。我在调参时养成的习惯是每次改动奖励权重或状态离散方式都先跑基线再跑算法两组对比指标放在同一张表里看。另外一个值得花时间的技巧是观察单路口行为和路网整体行为的偏差。如果总吞吐量提高了但平均等待时间也提高了说明部分路口的控制策略过于激进用绿灯时间换车流吞吐、牺牲了一部分等待体验。此时应该调整奖励里吞吐量项的权重让它小一些等到两个方向同时变好再继续加码。城市交通控制的真正目标是波动最小的顺畅通行不是单点指标最大化。最后说一个我踩过的坑早期做多智能体信号控制时我只盯着总排队长度看连续两轮实验结果都显示算法优于固定配时一度以为项目完成。后来把平均等待时间加进指标体系发现智能体确实让车流更快通过了但部分车辆在红灯前等了三倍于基线的时间。这个偏差正是多目标优化的经典陷阱单一指标的自欺。做这类仿真项目指标选得比算法调参更影响结论。希望这些思路能帮你在自己的多智能体交通控制系统里少走一段弯路。本文还有配套的精品资源点击获取