到 1888 年，法国中部的科芒特里-富尔尚博公司，一家有煤矿也有铁厂的公司，已经三年没分过红。照管科芒特里煤矿那个人的说法，那里挖出来的煤「远远抵不上开采成本」。据他后来回忆，公司当时「几乎已经认命，准备关闭、放弃工厂，停掉矿井」。
这个人叫亨利·法约尔。他 19 岁从矿业学校毕业就进了这家公司，此后一直留在这里。他懂煤，不懂铁。董事会要关掉富尔尚博的工厂。据埃伦·奥康纳 2015 年为一本公司史写的书评转述，法约尔起初把名字撤了回来，不愿去关这座厂。董事会拿他的忠心来求他。他接下了这份差事，只提了一个条件：先不关富尔尚博，等他亲自调查清楚，确实非关不可再说。
二十年后，1908 年，他在圣艾蒂安对一群矿业同行讲话，讲的是一家已经翻了身的公司。他强调，翻身靠的不是新矿，也不是新人：1888 年以前走下坡路，用的是同样的矿、同样的厂、同样的员工；1888 年以后翻身，用的还是它们。
衰落和复兴，他说，「完全是由所用的管理方法造成的」。
五个动词
1916 年，75 岁的法约尔在矿业学会的会刊上发表了《工业管理与一般管理》（次年出了单行本），用一句话给这份工作下了定义：「管理，就是计划、组织、指挥、协调和控制。」
管理是干活之外的另一门手艺，法约尔把它拆成五件事。
这五个法文动词，和中文、英文都对不太齐。「计划」的原词 prévoir，他的解释是审视未来、拟定行动方案，1949 年的英译本得用两个词才译得出来：「预测并计划」。「指挥」，按他的定义，是让人员运转起来。「协调」，是把所有的行动和努力连起来、合起来、调和起来。「控制」，是看着一切按既定的规则和下达的命令进行。让-路易·佩奥塞勒和卡梅伦·格思里 2015 年写法约尔生平的书，据埃伦·奥康纳的书评介绍，干脆把这个词译成了「核验」。
他描述过「一家大型矿业冶金企业」怎么做计划，那家企业有大约一万名员工。每年结账两个月后，出一份总报告，回顾上一年，同时附上对新一年的预测。十年预测每五年重做一次，所以手上永远有一条至少看到五年后的路线。
1908 年那次讲话里，他对台下的工程师们说：一个管理能力好、技术平平的领导者，通常比一个技术出众、管理平平的人对企业更有用。他还说，职位是「一种杠杆，能把个人的影响放大两倍、十倍、一百倍，甚至一千倍」。
四个跑得飞快的人组成的接力队，照样会因为掉棒输掉比赛。跑，是技术活；谁跑哪一棒、交接练没练熟、冲线时有没有人核对，这些是管理者的事。
他自己的说法
1888 年的故事，是法约尔自己讲的，里面也有没讲的部分。据蒙吕松当地一个历史学会的记载，科芒特里的煤越挖越少，公司在 1891 年买下布拉萨克的矿，1892 年又买下德卡兹维尔的矿。公司在伊姆菲的工厂还研制出特种钢，打开了新市场。奥康纳指出，他的理论是几十年后回头看自己的经历才写出来的：「这不是一个科学的过程。」
亨利·明茨伯格说得更重。1975 年，他在《哈佛商业评论》上写道，法约尔这几个词「几乎说不出管理者实际在做什么，充其量只是点出了管理者工作时怀着的几个模糊目标」。明茨伯格跟着观察的那几位高管，一天的时间都是碎成一小块一小块的。
法约尔列的是这份工作为了什么，明茨伯格记的是一天的时间花在哪儿。要检验法约尔这张单子，最好找一种每一步都留下书面记录的工作。
同一个模型，不同的管理
AI 智能体团队就会留下这种记录。2025 年，一个主要来自加州大学伯克利分校的团队（梅尔特·杰姆里是几位并列第一作者之一）研究了一个问题：几个语言模型智能体分工合作完成一项任务，这样的系统为什么会失败。他们从七个开源多智能体框架里收集了 1642 条运行记录，用的大多是 GPT-4 和 Claude 系列模型，任务包括写代码、做数学题和一般性任务。失败被归成三类：系统设计（说明含糊、角色没守住）、智能体之间对不上，以及任务核验。
把这三类放在法约尔的单子旁边，大致落在计划、协调和控制上。有一条记录里，负责手机应用的智能体始终没告诉上级智能体，用户名得填手机号；上级也从来没问，登录就一遍遍失败。还有一条记录里，一个国际象棋程序通过了编译这类表面检查，却没有人拿象棋规则去核对它，一运行就出错。论文的第一条结论，听起来像法约尔 1908 年那次讲话：设计得好的系统，「用同一个底层模型也能带来性能提升」。
这项研究有它的边界：大部分记录是由一个对照人类专家校准过的语言模型来标注的；研究的是开源的研究框架，不是市面上所有的智能体产品。作者对其中一个框架做了改进，有效果，但他们自己写道，这些改进「算不上实质性的提升」。
你可以自己查一查最后那一步。找一次智能体们出了错的运行记录，找到批准结果的那一步，把它实际查了什么一条条写下来。如果它只确认了代码能跑，就自己拿任务本身的要求去核对一遍输出，看看它本该拦下什么。
新组长接下的那个 bug
假设你刚被提拔为六人小组的组长，你原本是组里技术最强的工程师。离发布还有两周，冒出来一个最棘手的 bug，你自己接了，因为你修得最快。熬了三个晚上，修好了。
发布当天你才发现，组里有两个人各自做了一遍导出功能，做法还不一样，因为两人都以为这活儿归自己。数据库迁移脚本，也从头到尾只在测试数据上跑过。
到了半夜，你在回滚这次发布。你修好的那个 bug，也跟着一起回滚了。