早高峰的写字楼大堂，三台电梯前排起了长队。你按下按钮，看着楼层显示屏上的数字缓慢跳动。旁边的电梯明明停在14楼，却迟迟不动——它究竟在等什么？
这看似简单的问题，背后隐藏着一个困扰工程师百年的算法难题。电梯调度，这门融汇了排队论、组合优化和人工智能的技术，远比大多数人想象的复杂。
从操作员到继电器：1924年的自动化革命
1920年代之前的电梯，需要专门的"电梯操作员"。他们不仅要控制电梯的启停，还要判断该在哪些楼层停靠、如何响应不同乘客的请求。人力成本高昂不说，服务质量还参差不齐——操作员可能"偷懒"，可能"健忘"，甚至可能故意绕路。
1924年，Otis电梯公司的工程师David L. Lindquist、Edward L. Dunn和David C. Larson开始了一场静悄悄的革命。他们的目标是：让电梯自己"思考"。
1925年5月21日，团队提交了两份专利申请，定义了被称为"Collective Control"（集选控制）的系统。这是世界上第一个自动电梯交通控制系统。
集选控制的核心逻辑极其优雅：
- 电梯沿一个方向运行时，依次响应该方向上的所有呼叫
- 到达最远的呼叫楼层后，改变方向
- 没有呼叫时，电梯停靠在终端楼层（通常是底层）
这个算法后来被称为SCAN算法（扫描算法），或更通俗地——“电梯算法”。它如此简洁，以至于计算机科学课程至今仍用它来讲解磁盘调度原理。
但集选控制的价值远不止于"自动化"。它引入了一个关键概念：方向性服务。乘客按下的不再是一个简单的"呼叫"按钮，而是"上行"或"下行"两个按钮。电梯知道你想去哪个方向，才能更智能地规划路径。
经典算法的三重境界
理解电梯调度，需要从单电梯场景开始。假设一栋20层的建筑，只有一台电梯服务。不同的调度算法，会给出截然不同的响应策略。
FCFS：先来后到的公平陷阱
First Come First Serve（先来先服务）是最直观的方案：谁先呼叫，先服务谁。
假设电梯停在1楼，依次有乘客在5楼、15楼、3楼按下按钮。FCFS会让电梯按顺序跑：1→5→15→3。
问题显而易见：电梯频繁改变方向，来回奔波。从15楼返回3楼服务第三个乘客时，可能又会错过中途新出现的呼叫。FCFS的平均响应时间随着楼层数量线性增长，在高流量场景下几乎不可用。
SSTF：贪婪的效率陷阱
Shortest Seek Time First（最短寻道时间优先）采用贪婪策略：总是优先服务距离当前位置最近的呼叫。
电梯在1楼，5楼、15楼、3楼都有人等待。按距离排序：3楼最近，于是服务顺序变成1→3→5→15。
这看起来很高效——电梯始终朝一个方向移动，沿途"收集"所有乘客。但它有一个致命缺陷：饥饿。
如果8楼和9楼不断有新乘客呼叫，而20楼的乘客可能永远等不到电梯——因为电梯一直在服务"更近"的楼层。这就是计算机科学中经典的"饥饿问题"。
SCAN与LOOK：方向性的智慧
SCAN算法引入了"方向"的概念。电梯像一个不知疲倦的巡逻者：从底层扫到顶层，再从顶层扫回底层，沿途响应所有同方向的呼叫。
LOOK算法是SCAN的改进版。电梯不再机械地跑到顶层或底层，而是"看看"前方是否还有呼叫。如果没有，立即改变方向。
用一个例子对比：
假设电梯在10楼向上运行，当前呼叫分布在：5楼（下行）、12楼（上行）、18楼（上行）、20楼（上行）。
- SCAN会继续向上：10→12→18→20→顶层→返回→5
- LOOK会检测到18楼以上没有呼叫：10→12→18→立即返回→5
LOOK减少了空跑距离，是现代电梯系统的主流选择。
群控系统：从单机到协作的跨越
单电梯场景相对简单。但大多数办公楼至少有4-6台电梯组成一个"电梯群"。如何让它们协同工作？
这涉及到三个核心指标：
HC5%：五分钟处理能力
Handling Capacity（处理能力）是衡量电梯系统效率的硬指标。HC5%定义为：在5分钟内，电梯系统能够运输的建筑总人口的百分比。
根据ISO 8100-32标准，一个合格的办公楼电梯系统，HC5%应该达到11%-15%。换句话说，在早高峰的5分钟内，电梯系统要能运送全楼11%-15%的人。
计算HC5%需要知道两个关键参数：
- Round Trip Time（往返时间）：电梯从底层出发，服务所有呼叫，返回底层所需的时间
- Interval（间隔）：两台电梯到达底层的平均时间间隔，等于RTT除以电梯数量
假设一栋楼有6台电梯，平均往返时间180秒。间隔 = 180/6 = 30秒。这意味着每30秒就有一台电梯到达底层接客。
如果每趟电梯平均载客20人，5分钟内可以运送 300/30 × 20 = 200人。如果大楼有1500人，HC5% = 200/1500 ≈ 13.3%，达标。
等待时间 vs 行程时间：不可兼得的鱼和熊掌
乘客关心两个指标：等电梯的时间（Waiting Time）和坐电梯的时间（Transit Time）。
直觉上，这两个目标是一致的——电梯越快到达，旅途越短。但现实恰恰相反：这两个目标存在内在冲突。
考虑一个场景：电梯在1楼，里面已有5位乘客，分别要去5楼、8楼、12楼、15楼、18楼。现在3楼有新乘客按下按钮。
如果停下来接这位乘客：
- 新乘客的等待时间减少（好事）
- 但电梯里5位乘客的行程时间都增加了（坏事）
如果选择不停：
- 5位乘客更快到达（好事）
- 但新乘客要等下一趟电梯（坏事）
这就是电梯调度的核心困境：每次停靠都意味着延迟车上所有人。
交通模式：早高峰、午高峰、晚高峰
电梯系统面临的交通流量并非均匀分布。典型的办公楼有三种主要交通模式：
-
上行高峰（Up-Peak）：早8:00-8:30，员工陆续到达，从底层进入大楼。这是设计电梯系统的最苛刻场景。
-
下行高峰（Down-Peak）：傍晚时分，员工下班离开。流量比上行高峰更集中，但持续时间更短。
-
午餐高峰（Lunch-Peak）：中午12:00-1:00，员工外出就餐或返回办公室。双向流量混合，是最复杂的场景。
传统调度算法通常以上行高峰为设计基准。如果一个系统在上行高峰能够提供30秒以内的间隔，在其他时段表现也不会差。
目的楼层调度：1990年的革命
传统电梯系统有一个根本性的信息缺失：系统不知道乘客要去哪。
乘客按下"上行"按钮后，电梯只知道"有人想上行"。至于要去5楼还是25楼，电梯进入轿厢前无法得知。这导致调度决策充满了不确定性。
1990年，Schindler电梯公司推出了Miconic 10系统，彻底改变了这个局面。
Miconic 10：把目的楼层提前告知
Miconic 10的核心创新极其简单：让乘客在电梯厅外就输入目的楼层。
电梯厅安装了数字键盘或触摸屏。乘客输入"22"，系统立即响应：“请乘坐A号电梯”。此时，调度系统已经知道这位乘客要去22楼，可以提前规划。
这个看似简单的改变，带来了惊人的效果提升：
-
乘客分组：去相同楼层的乘客被分配到同一台电梯。电梯停靠次数减少，行程时间缩短。
-
负载预测：系统知道每台电梯将承载多少乘客，避免分配过多乘客到同一台电梯。
-
直通服务：当电梯满载且所有乘客去往相近楼层时，可以跳过中间楼层直达。
根据ThyssenKrupp的ETD（Estimated Time to Destination）系统测试数据，目的楼层调度在上行高峰场景下，可以将平均行程时间缩短20%-30%，处理能力提升25%-40%。
ETD算法：全局最优的代价
ThyssenKrupp的ETD算法代表了目的楼层调度的技术前沿。它的核心思想是：最小化所有乘客的总行程时间。
当新乘客输入目的楼层后，系统计算将其分配到每台电梯的"总代价"：
总代价 = 新乘客的行程时间 + 所有其他乘客的延迟
用一个具体例子说明：
电梯A正在运行，里面有8位乘客都要去1楼。电梯B里面只有1位乘客要去6楼。电梯C里面没人。
新乘客在7楼，想去2楼。
如果分配到电梯A：8位乘客每人都被延迟10秒，总延迟80秒；新乘客等待5秒，行程25秒。总代价 = 80 + 5 + 25 = 110秒。
如果分配到电梯B：1位乘客被延迟10秒；新乘客等待10秒，行程35秒。总代价 = 10 + 10 + 35 = 55秒。
如果分配到电梯C：没有乘客被延迟；新乘客等待15秒，行程25秒。总代价 = 15 + 25 = 40秒。
ETD算法会选择电梯C——虽然它的到达时间最晚，但全局代价最低。
这种"全局最优"的思路，需要在毫秒级别完成大量计算。Miconic 10的专利论文指出，调度问题实际上是NP-hard问题：在数学上不存在多项式时间的最优解算法。
工程上的解决方案是采用启发式搜索：在100毫秒内找到"足够好"的解，而不是追求理论最优。
AI时代：当电梯学会学习
目的楼层调度解决了"乘客要去哪"的问题，但还有一个问题没解决：预测乘客什么时候来。
2010年代，电梯公司开始将人工智能引入调度系统。
神经网络：预测响应时间
Otis公司开发了一种基于神经网络的方法来预测电梯的"剩余响应时间"（Remaining Response Time）。
传统方法通过距离和预计停靠次数来估算响应时间，但存在大量不确定因素：乘客进出电梯需要多长时间？会不会有人按住门？会不会有人临时改变目的？
神经网络通过大量模拟数据训练，学习这些不确定性。Otis的论文指出，这种方法可以将响应时间预测误差降低20%。
强化学习：让电梯自己摸索最优策略
强化学习（Reinforcement Learning）是一种更激进的尝试：让电梯系统通过"试错"自己学习最优策略。
1996年，Robert Crites和Andrew Barto发表了一篇开创性论文，将强化学习应用于10层建筑的电梯调度。神经网络经过6万小时的模拟训练后，在下行高峰场景下将平均等待时间从21秒降低到14秒。
但这种方法有明显的局限：训练成本极高，而且网络结构依赖于建筑规模——换了建筑就要重新训练。
多智能体系统：分布式的智慧
Schindler的Miconic 10后来采用了多智能体架构。每台电梯有自己独立的"调度智能体"，通过"拍卖"机制竞争乘客。
当新乘客出现时，所有电梯智能体同时计算"如果我接这位乘客，会产生多少额外代价"，然后"出价"。代价最低的智能体中标。
这种分布式架构有几个优势：
- 容错性：一台电梯故障，其他智能体自动接管
- 可扩展性：增加电梯就是增加智能体
- 实时响应：不需要中央控制器，决策更快
技术的边界与权衡
电梯调度技术的发展，揭示了一个深刻的工程真理：没有完美的方案，只有特定场景下的最优权衡。
目的楼层调度的代价
目的楼层调度在上行高峰表现出色，但在午餐高峰和随机交通场景下，优势并不明显。原因很简单：午餐时间的流量是双向混杂的，分组策略难以发挥作用。
更现实的问题是用户习惯。当乘客习惯了"先按按钮、后进电梯"的传统方式，面对"先输入目的楼层、再找指定电梯"的新系统，难免产生困惑。老年人、残障人士可能更需要帮助。
AI的实用性困境
AI技术在电梯调度中的落地，面临着数据获取的困境。训练神经网络需要大量真实数据，但电梯公司很少愿意分享运营数据。模拟数据又难以完全还原真实世界的复杂性——乘客行为的随机性、设备故障的不可预测性，都是难以建模的因素。
截至2026年，目的楼层调度仍是高端写字楼的主流选择，传统集选控制在普通住宅和商业建筑中依然广泛应用。AI调度更多停留在研究阶段，大规模商业化还有距离。
一个更根本的问题
回到开头的场景：为什么那台停在14楼的电梯迟迟不动？
可能的原因有很多：
- 它可能被分配了即将到来的乘客，正在"待命"
- 它可能在等待一台正在服务的电梯完成当前任务，以便接管新的呼叫
- 它可能刚刚服务完一个呼叫，系统判断当前没有需要立即响应的请求
更重要的是：电梯系统的设计目标，从来不是"让每个人立刻等到电梯"。
如果目标是零等待，需要多少电梯？答案是：无限多。
现实中，工程师要解决的问题是在"可接受的等待时间"和"可承受的设备成本"之间找到平衡。30秒的平均等待时间、15%的HC5%、2500-3500磅的载重——这些数字背后是建筑成本、能源消耗、维护费用的综合考量。
下一次，当你站在电梯前等待时，也许可以想象一下：那台停在远处的电梯正在执行一个精心计算的算法，它的"不动"可能是为了让另一台电梯更高效地运转。
参考资料
- Gray, L. (2023). The History of Operatorless Elevators: Traffic Control Systems. Elevator World.
- Barney, G. & Al-Sharif, L. (2016). Elevator Traffic Handbook: Theory and Practice. Routledge.
- Smith, R. & Peters, R. (2002). ETD Algorithm with Destination Dispatch and Booster Options. Elevator Technology 15.
- Koehler, J. & Ottiger, D. (2002). An AI-Based Approach to Destination Control in Elevators. AI Magazine, 23(3).
- Crites, R. & Barto, A. (1996). Improving Elevator Performance Using Reinforcement Learning. Advances in Neural Information Processing Systems, 8.
- Siikonen, M. (2021). On Traffic Planning Methodology. Lift Report, 27(3).
- ISO 8100-32:2019. Lifts for the Transportation of Persons and Goods - Part 32: Planning and Selection of Passenger Lifts.
- Peters Research. Elevate Traffic Analysis and Simulation Software Documentation.