一、信号控制只有一个决策

绿灯给哪个方向、给多久。所有算法，从最早的定时控制到现在的强化学习，都是在回答这一个问题。 两种最基础的做法：① 固定配时——周期固定（比如 90 秒），两个方向各给 41 秒绿灯， 中间 8 秒黄灯加全红。简单、可靠、不需要任何检测器。 ② 感应控制——靠检测器看排队长度， 排队短就缩短周期，排队长的方向多给绿灯。周期在 42 到 100 秒之间浮动。 直觉上感应控制一定更好，因为它「按需分配」。 但这个直觉只在「有闲置绿灯可回收」的时候成立。下一节的数就是来划这条界的。

二、平峰省 32%，高峰只剩 3%

Demo 逐秒仿真 3 小时，饱和流率每秒 0.5 辆，对比两种策略在三个流量下的平均等待：

三、过饱和为什么反而更差

因为每次切换相位都要付损失时间。黄灯加全红、车辆启动的反应时间，Demo 里低流量时算 6 秒、 高流量时算 8 秒。 周期越短，损失时间占比越高。90 秒周期里损失 8 秒，是 9%；42 秒周期里损失 6 秒，是 14%。 感应控制在低流量时缩短周期，等于把损失时间的比例抬上去了。 平峰时这个代价被「回收的闲置绿灯」盖过去了，但过饱和时没有闲置绿灯可回收，只剩损失时间的净亏。 所以「感应控制一定更好」是个误解。它的收益来自「有闲置绿灯可回收」， 流量一满就没有闲置，只剩切换开销。 顺带说一句：过饱和那行 1256 秒的等待本身没有实际意义——ρ 已经大于 1，队伍只会一直变长， 这个数只说明「这个路口已经废了」，该做的是渠化改造或者分流，不是调配时。

四、感应控制的前提是检测器

感应控制要靠检测器知道排队长度。地感线圈、视频检测、雷达——任一种坏了， 这套策略就退化成瞎猜，而且退化时不报警。 所以它省下的等待，是拿运维成本换来的。很多城市装了感应控制却没开， 原因不是算法不好，是检测器不准、没人维护。 这一条对所有「智能交通」项目都成立：算法效果的上限，由传感和运维决定。 先问「数据从哪来、坏了怎么办」，再谈模型。 还有一种更隐蔽的失效：检测器偏移。摄像头角度一变（被撞、被风吹）， 看到的排队长度就系统性偏大或偏小，控制策略会一直按错的数执行，而且指标上看不出异常。

五、落地：分时段，不要一刀切

第一步，按流量分档。平峰、高峰、过饱和三档，每档用不同策略：平峰感应、 高峰固定（或半感应）、过饱和长周期干线协调（绿波）。 第二步，按天按周定档。工作日早高峰、晚高峰、周末、 节假日 —— 同一时段不同日子的流量差很多，配时表要分开。 第三步，留手动接管。大型活动、事故、施工，任何自动策略都会被打破。 必须有指挥中心一键切方案的能力，否则「智能」就是添乱。 第四步，量效果。不是量「平均等待」，是量「平均等待的 95 分位」和「排队溢出次数」。 排队溢出（队尾堵到上一个路口）是最该盯的指标，它一旦出现，整条干线就锁死了。

六、动手 Demo：信号配时：平峰感应控制等 13.4 秒，固定配时要 19.8 秒

逐秒仿真 3 小时：每个相位每秒按泊松分布到达车辆，绿灯期间每秒最多放行 0.5 辆， 黄灯加全红期间不放行。固定配时用 90 秒周期（绿 41 + 损失 8 + 绿 41）； 感应配时按排队长度在 42／58／100 秒三档之间切换。统计每辆车的等待时间和最大排队长度。

while t < T:
    for ph in (0, 1):
        for _ in range(rg.poisson(lam)):   # 这一秒到达
            q[ph].append(t)
    c = t - cs
    ph = 0 if c < g0 else (-1 if c < g0 + lost else
                            (1 if c < g0 + lost + g1 else -1))
    if ph >= 0 and q[ph] and rg.random() < sat:
        waits.append(t - q[ph].pop(0))     # 放行一辆，记等待
    t += 1.0

tot = len(q[0]) + len(q[1])                # 感应：按排队调周期
if tot < 6:
    g0 = g1 = 18.0
elif tot < 20:
    g0 = g1 = 26.0

实跑输出：

--------------------------------------------------------------------
信号配时：平峰感应控制等 13.4 秒，固定配时要 19.8 秒
--------------------------------------------------------------------
  饱和流率                 每秒 0.5 辆
  固定配时                 90 秒一周期（绿 41 + 损失 8 + 绿 41）
  感应配时                 低流量 42 秒、中流量 58 秒、高流量 100 秒
  仿真时长                 3 小时，逐秒推进

  流量                 固定等待(秒)   固定排队   感应等待(秒)   感应排队   变化
  ----------------------------------------------------------------------------
  平峰 0.12 辆／秒             19.8          8           13.4          6   -32%
  高峰 0.20 辆／秒             36.4         21           35.2         19    -3%
  过饱和 0.30 辆／秒         1256.6        776         1340.6        806    +7%

  平峰那一行最能说明问题：**固定配时平均等 19.8 秒，感应只要 13.4 秒。**
  **因为平峰时横向根本没车，固定配时还是老老实实给 41 秒绿灯——那 41 秒全浪费了。**
  高峰那行差距收窄到 -3%。**因为两个方向都排上了，怎么分配都差不多。**
  过饱和那行反过来：**感应配时 +7%。**
  **原因是感应配时会缩短周期，而每次切换都有损失时间**（低流量时 6 秒，高流量时 8 秒）。
  **周期越短，损失时间占比越高——过饱和时这是在白白浪费绿灯。**
  所以「感应控制一定更好」是个误解。**它的收益来自「有闲置绿灯可回收」，**
  **流量一满就没有闲置，只剩切换开销。**
  实务上的正确做法是**分时段切换策略**：平峰用感应、高峰用固定、过饱和用长周期干线协调（绿波）。
  还有一个隐含前提：**感应控制要靠检测器知道排队长度。**
  检测器坏一个，这套策略就退化成瞎猜。
  **所以它省下的等待，是拿运维成本换来的。**

表里三行的「变化」列就是这一节的结论：−32%、−3%、+7%。 同一种策略，在三种流量下结论完全相反。 平峰那 32% 是真的收益——回收了本来浪费的绿灯。 而且平峰占一天的大多数时段，所以年累计的收益主要来自这一档。 过饱和那 +7% 也是真的亏损，但要注意：那一档的等待已经上千秒， +7% 的绝对量是几百秒，比平峰省的 6.4 秒大得多。 所以「平均下来是赚的」这种算法会掩盖问题。 要说明：这是简化模型——每个相位一条队列、不考虑左右转、不考虑渠化、不考虑车辆之间的跟驰。 真实路口要比这复杂得多，但「周期短了损失时间占比高」这个机制是真的。

30 秒实验

1. 把感应配时的低流量档从 42 秒改成 60 秒，看平峰那一行。 等待会变长一点——周期太短，损失时间占比就上去了。
2. 把饱和流率从 0.5 降到 0.35（大车多、起步慢），重跑全部三档。 高峰会直接变成过饱和，那一行从 −3% 翻成一个大正数。
3. 把过饱和那一档的到达率从 0.30 降到 0.26，看重算的差值。 会回到 −5% 上下——ρ 一旦低于 1，感应控制又开始赚了。

常见误区

1. 「感应控制一定比固定配时好」。过饱和时它更差，因为缩短周期会抬高损失时间的占比。
2. 「平均等待降了就是成功」。过饱和那档绝对量增加最多，平均值会把这种局部恶化掩盖掉。
3. 「装了感应控制就智能了」。检测器坏了它不会报警，会一直按错的排队长度执行。

路口配时是「让车走得快」，下一个问题是「告诉人还要多久到」。这个数报错了，比不报更糟。

• ☐ （本节完，下一节 10.2.2 智慧出行服务）

相关笔记

• 实时性保障方案
• 智慧出行服务
• 公共服务优化
• 🧠 AI训练师手册2 · 索引