1950 年代后期，克利夫兰凯斯理工学院的一位年轻教授，在一堂讲排队的课结束时提了一句：他们学过的每个模型里，都有同一个公式反复冒出来。看起来非常普遍。
下课后，一个叫锡德·赫斯的学生过来问：「要证明它普遍成立，有多难？」
「应该不太难吧。」这位教授约翰·利特尔说。
五十年后写到这一幕，利特尔补了一句：「有名的遗言。」
当时赫斯接着说：「那你就该去证！」利特尔趁着一家人在楠塔基特岛过夏天的时候做这件事，他写道，「海滩就是我们的保姆」。1961 年，证明发表了。然后他认定这类数学不适合自己，用他的话说，「从排队论退休了」。经过详见案例。
三个数
公式是 L = λW。系统里平均有多少件东西（L），等于它们进来的速度（λ）乘以每件平均待多久（W）。
利特尔和合著者史蒂夫·格雷夫斯举过一个超市的例子：早上 7 点开门，晚上 11 点关门。假设每小时进来 120 个顾客，平均每人逛 25 分钟，那么店里平均就有 50 个人。
让人意外的，也是利特尔证明了的，是这条法则的要求有多么少。顾客怎么来、每人逛多久、开几个收银台、谁先结账，它都不管。利特尔 2011 年说明，只要看的这段时间开头和结尾店里都是空的，它就严格成立；一个一直在运转的系统，只要状态平稳，它对长期平均值成立。
倒过来用
管事的人通常想知道第三个数：这件事要多久？倒过来就是 W = L / λ。运营管理教科书写成：周期时间等于在制品除以产出。
设想一家小会计事务所，整个报税季平均手上有 60 份报税单在办，每周办完 15 份左右。平均算下来，每份从收进来到办完送出，要在所里待四个星期。答应某个客户一周搞定，可以把他插到前面，但别人就得多等。除非少接几份，或者每周多办完几份，否则平均数纹丝不动。
所以积压越堆越高，危害才那么大。2004 年，微软 XIT 组积压着 80 多个改动需求，每月只做完六七个，一个需求通常要等至少五个月。他们的办法，是给进入开发的活设上限，这就是在制品限制讲的事。
一面照妖镜
利特尔法则也能用来检验数字。密歇根大学的比尔·洛夫乔伊用它给一家医院的观察病房定规模，他告诉利特尔：「我经常拿到加起来对不上的数据表。利特尔法则就是一道现实检验。」一个病区报上来的平均在院人数、收治速度、平均住院天数，三个数必须对得上。
他也拿它来做规划。观察病人平均待 1.14 天，所以只要估出病人来的速度，就能算出病房里平均有多少人。再除以一个目标占用率，比如 90%，就得到该设多少张床的初步估计。
这条法则改变不了任何东西。它「不负责改变这些量」，利特尔写道。它也说不出满负荷附近会发生什么。这一点，利特尔借用的是基础的排队论：在急诊科，病人来的速度越接近医护处理得了的速度，平均在科的病人数和停留时间就会「先慢慢涨，然后猛涨」。所以给急诊科设计排班系统的马克·哈里斯给的经验法则是：在最低配置之上多排 10% 到 20% 的人。
排队的智能体
AI 的活，也按这道算术走。Anthropic 的 API 按每分钟请求数设上限。假设你的智能体每次调用平均要 30 秒，你稳定地每分钟发 50 次，那么长期平均下来，同时在跑的调用大约 25 个，短时的突发可能更高。想让长期平均保持 100 个在途、每个仍要 30 秒，就得每分钟发 200 次。它的批量接口干脆直接给队列设了上限：同一时间排在处理队列里的请求，最多只能有那么多。
不过，最卡多数人的，是排到自己面前的那条队。要是一周又一周，你的待审堆里平均躺着二十个智能体做完的任务，你每天审五个左右，那么每个从进堆到审完，平均要四天。智能体再快也没用。待审的那一摞不变小、或者你审得不更快，平均等待就一天也短不了。