你一定经历过这样的场景：早高峰的写字楼大厅里，你按下了上行按钮，然后开始漫长的等待。电梯的楼层指示灯在跳动——8、9、10……它还在往上走。你叹了口气，看了一眼手表。身边的人越聚越多，有人开始反复按按钮，仿佛多按几下电梯就能跑得更快。
终于，”叮”的一声，门开了。里面挤满了人，根本上不去。门关上，电梯扬长而去。你站在原地，像是被生活抛弃了一样。
我相信每个在高层建筑里生活或工作过的人，都曾在心里默默骂过电梯。但你有没有想过，那个小小的铁盒子背后，其实藏着一套相当精巧的调度算法？今天我们就来聊聊这件事——电梯到底是怎么决定先去哪一层的。
最原始的方案：排队，谁先来谁先走
最容易想到的方案，也是最朴素的方案，叫 FCFS（First Come First Served），就是先来先服务。你按了按钮，系统把你的请求排在队尾，然后电梯老老实实地按顺序一个一个去接人。
听起来很公平对吧？但问题在于效率极差。设想一下：电梯现在在 5 楼，队列里的请求依次是 2 楼、15 楼、3 楼。电梯要先跑到 2 楼，再爬到 15 楼，再回到 3 楼，来来回回跑了一大圈。这种毫无规划的来回跑动，在计算机科学里有个专门的术语叫”抖动”（thrashing），本质上就是在做大量无意义的位移。
在大楼流量不大的时候这还勉强能用，但一旦人流量上来，等待时间就会变得非常夸张。
贪心策略：先去最近的那一层
既然按顺序来不靠谱，那换一个思路：每次都去离当前位置最近的那个请求。这就是 SSTF（Shortest Seek Time First），最短寻道时间优先。
比如电梯在 5 楼，有 3 楼、7 楼和 15 楼三个请求，它会先去 3 楼（距离 2 层），然后去 7 楼（距离 4 层），最后去 15 楼（距离 8 层）。总位移比 FCFS 小了不少，效率确实提升了。
但 SSTF 有一个致命缺陷——饥饿（starvation）。如果低楼层不断有新请求涌入，住在高楼层的那个倒霉蛋可能永远等不到电梯。因为每次算距离，总是低楼层的请求更近。高楼层的请求就像餐厅里一直被插队的客人，理论上可以等到天荒地老。
真正的电梯算法：SCAN
终于轮到主角出场了。SCAN 算法，也叫”电梯算法”（Elevator Algorithm）——是的，这个名字就是从真实电梯的运行方式中得来的。
SCAN 的逻辑非常直观：电梯先选定一个方向（比如向上），然后一路往上走，沿途接人放人，一直走到顶层或者没有更高的请求为止，然后掉头向下，重复这个过程。就像一个扫地机器人，先扫到墙边，再调头往回扫。
这个算法最早出现在 Donald Knuth 的经典著作《计算机程序设计艺术》（The Art of Computer Programming）第一卷中。有趣的是，Knuth 在书中模拟了加州理工学院数学楼里一台电梯的运行，以此来讲解协程（coroutine）和双向链表。到了 1970 年代，学者们正式将这种扫描策略应用于磁盘调度，并通过数学证明了它在高负载场景下的优越性。
SCAN 解决了 SSTF 的饥饿问题，因为电梯保证会扫过所有楼层。但它也有缺点：住在楼层两端的人会比住在中间楼层的人等更久，因为电梯到边缘就掉头了，意味着边缘楼层两次被服务之间的间隔最长。
SCAN 的改良家族
SCAN 的基本思路虽好，但工程师们当然不会止步于此。围绕它衍生出了好几个变种：
LOOK 是对 SCAN 的一个小优化。SCAN 要求电梯跑到最顶层或最底层才掉头，即使那里根本没有人在等。LOOK 则聪明一些——如果当前方向上已经没有任何请求了，它就直接掉头。这就像你开车到了一条空无一人的路，没必要开到尽头再掉头，看到没人了直接 U-turn 就行。真实世界中的电梯，绝大多数用的其实是 LOOK 而不是严格的 SCAN。
C-SCAN（Circular SCAN）则是另一种思路。它让电梯只朝一个方向服务（比如只在上行时停靠），到顶之后不掉头服务，而是直接快速回到底层重新开始。这样做牺牲了回程的时间，但换来的是更均匀的等待体验——对所有楼层来说，平均等待时间是差不多的。
C-LOOK 结合了 C-SCAN 和 LOOK 的优点：只单向服务，且不跑到物理极端楼层，而是跑到最远的那个有请求的楼层就直接回到最低请求处重新开始。在理论分析中，C-LOOK 通常能给出最小的总位移量。
等一下，为什么和磁盘调度这么像？
如果你学过操作系统，你一定会觉得上面这些名字非常眼熟。没错，FCFS、SSTF、SCAN、C-SCAN、LOOK、C-LOOK——这些全是经典的磁盘调度算法。在机械硬盘的年代，读写磁头需要在不同磁道之间来回移动，这和电梯在楼层之间来回运行几乎一模一样。磁头就是电梯轿厢，磁道就是楼层，读写请求就是乘客。
这大概是计算机科学中最美妙的类比之一：一个物理世界中的工程问题和一个数字世界中的系统问题，居然共享同一套数学模型。Donald Knuth 在 1960 年代用电梯来类比磁盘调度时，可能也没想到这个比喻能如此长寿。
当然，随着固态硬盘（SSD）的普及，磁盘调度算法已经不太用得上了——SSD 没有物理磁头，寻道时间几乎为零。但电梯可没法变成”固态”的，它还是得在钢轨上老老实实地跑，所以这些经典算法在电梯领域依然活跃。
从单部电梯到群控：复杂度爆炸
上面说的所有算法，都有一个前提假设：只有一部电梯。然而现实世界里，一栋商业大楼里通常有 4 到 8 部甚至更多电梯。这时候问题就变成了：某个楼层有人按了按钮，该派哪一部电梯去？
这就是电梯群控（Elevator Group Control System, EGCS）的领域。它不再只是决定一部电梯的方向和停靠楼层，而是要协调多部电梯的整体行为。你需要考虑每部电梯的当前位置、运行方向、载客量、已排队的目标楼层，甚至当前时段的客流模式。
这个问题有多难？2010 年一项 IBM 的调查显示，纽约的上班族在一年中累计花了大约 16 年时间等电梯，另外还有 6 年时间待在电梯里。而从理论上讲，在确定性环境下优化电梯调度已经被证明是一个 NP-hard 问题。这意味着不存在一个”完美”算法能在合理时间内找到最优解——我们只能靠各种启发式方法去逼近。
大多数电梯厂商的群控算法都是商业机密。你在公开文献中很难找到奥的斯（Otis）或者迅达（Schindler）的核心调度逻辑。它们只会告诉你结果：等待时间减少了百分之多少，运力提升了百分之多少。
目的地派梯：一场交互革命
在传统电梯系统中，你的交互方式是这样的：在大厅按上/下箭头 → 电梯来了 → 进去之后再按目标楼层。这意味着电梯来接你的时候，系统其实并不知道你要去几楼。它只知道”有人在 1 楼想上去”，仅此而已。
目的地派梯（Destination Dispatch）彻底颠覆了这一点。它要求你在走进电梯之前，就在大厅的触摸屏或键盘上输入你的目标楼层。系统会告诉你”请去 C 号电梯”。走进电梯后，你会发现里面没有楼层按钮——因为不需要了，系统已经知道你要去哪。
这个概念最早由澳大利亚悉尼的 Leo Port 在 1961 年提出，但受限于当时的技术——电梯控制还在用机械继电器——这个想法并没有落地。直到 1990 年代，迅达集团（Schindler）推出了世界上第一个实用化的目的地派梯系统 Miconic 10，安装在德国汉堡电力公司的大楼里。此后，各大电梯厂商纷纷推出自己的版本。
目的地派梯的核心优势在于：系统知道了每个人的目的地，就可以把去同一层或相近楼层的人分配到同一部电梯。这大大减少了电梯的停靠次数，从而缩短了所有人的行程时间。根据行业数据，这种系统能将总行程时间缩短约 25%，同时将运力提升约 30%。
此外，它还能和楼宇安防系统集成。你的门禁卡记录了你在哪一层办公，过闸机的时候系统就自动帮你叫好了电梯，连触摸屏都不用碰。VIP 用户还可以享受专梯直达、优先调度等特权。
AI 入场：让电梯自己学会怎么跑
近年来，强化学习（Reinforcement Learning）开始进入电梯调度的视野。
想法很简单：与其让人类工程师费尽心思设计规则，不如让算法自己在模拟环境中反复试错，找到最优策略。早在 1998 年，Crites 和 Barto 就发表了开创性的论文，用多智能体强化学习来控制电梯组。每部电梯由一个独立的 RL 智能体控制，它们共享一个全局奖励信号。尽管每个智能体只能看到部分状态信息，而且奖励信号因为其他智能体的行为而充满噪声，但最终的效果在仿真中超过了所有已知的启发式算法。
这篇论文的一个关键洞察是：电梯群控是一个超大规模的随机动态优化问题，状态空间巨大（对于一栋 10 层楼、4 部电梯的建筑，状态数就已经超过 10 的 22 次方），人类专家很难给出好的教学数据，因此特别适合让机器自己学。
到了 2020 年代，深度强化学习进一步推动了这个方向。阿姆斯特丹自由大学的研究者在一栋 15 层、6 部电梯的建筑上训练了基于 Dueling Double DQN 的群控系统，让它在不同的客流模式下自适应调度。而 ThyssenKrupp（现 TK Elevator）的 MAX 系统则更进一步，将超过 11 万部电梯接入 IoT 云平台，利用实时数据和机器学习来做预测性维护——甚至能在故障发生之前就识别出潜在问题。
还有研究者把计算机视觉引入了电梯调度。通过在每层大厅安装摄像头，用 YOLO 等目标检测模型实时数出等候区有多少人，然后动态调整调度策略。实验表明，这种摄像头辅助的调度方法能将乘客的平均行程时间缩短约 40%。
电梯的终极形态：无绳、多轿厢、水平移动
当传统电梯被钢缆束缚在单一竖井中时，TK Elevator 提出了一个激进的构想——MULTI 系统。它抛弃了钢缆，改用线性电机驱动，多个轿厢可以在同一个竖井中独立运行，甚至能水平移动——从一个竖井转入另一个竖井。这就像从单线铁路升级到了立体地铁网络。
虽然截至目前 MULTI 还只在测试塔中运行，没有商业化安装，但它代表了一种全新的思维方式：电梯不再是在一维空间里上下移动的盒子，而是在二维甚至三维管道网络中穿梭的运输单元。这也意味着调度算法需要从”一维寻路”升级为真正的”路径规划”——问题的复杂度又上了一个台阶。
不是所有问题都需要算法来解
聊了这么多技术，最后说一个有意思的小故事。
据说，曾经有一栋写字楼收到大量投诉，说电梯等待时间太长。管理层请来了各路专家，研究怎么优化调度、怎么提升电梯速度。最后一个刚入职的年轻人提了一个完全不同的建议：在电梯候梯厅装面镜子。
结果呢？投诉几乎消失了。
这不是因为电梯变快了，而是人们有了事情做——照镜子、整理仪容、偷偷观察别人。等待的感受完全取决于你是否有事可做。排队理论中有一条著名的原则：空闲的等待比有事做的等待感觉更漫长。
这就是为什么今天几乎所有电梯大厅都有镜子，电梯内部也有镜子。这也是为什么越来越多的大楼在候梯区装上屏幕播放新闻和广告。它们并没有让电梯更快，但它们让等待变得没那么难以忍受。
从这个角度看，电梯调度其实是一个同时跨越工程学和心理学的问题。最优的方案不只是让电梯跑得更聪明，还要让乘客感觉等得更短。有研究表明，很多人宁愿电梯 10 秒内到达、然后在里面待 60 秒，也不愿意等 30 秒、坐 30 秒——即使后者总耗时更短。因为等待的痛苦远大于乘坐的痛苦。
所以下次你站在电梯前无聊等待的时候，不妨想想：此刻在大楼的某个控制柜里，一颗小小的芯片正在疯狂地计算——它要考虑六部电梯的位置和方向，三十几层楼的呼叫请求，每部电梯里的载重，甚至今天的上下班客流曲线。然后在几十毫秒内给出一个决策：派哪部电梯去接你。
它不一定是最优解。但在一个 NP-hard 的世界里，能在几十毫秒内给出一个不错的答案，已经相当厉害了。
发表回复