Kenco 的 AI 代理：单仓月省 500 工时，准确率 99.96%

先把公告真正确立的事说清楚。肯高集团做了一层叫 Agent K 的代理层，它看人把流程跑一遍就学会逻辑，之后自己排计划、定优先级、执行日常事务。公告记录：单月自动化 500 个工时，准确率 99.96%；一家快消品仓预计年省可控成本超过 10 万美元；覆盖 3 家客户、5 个配送中心；2025 年 11 月上线。落地的场景是波次计划——决定哪些订单进哪个波次，依据船期、依据当天真有多少人、依据现场背着的那些约束。挂了微软的 Teams，远程派活和收告警。同一届奖还有一个 Takt 的员工激励项目：68 名员工、6 支队伍，1,500 美元激励换来 6,500 美元节省，投资回报率 337%。

现在把它建模。订单到达。到达是成串成串的，因为客户的系统什么时候批处理怎么排，跟你没关系。放行规则决定哪一批什么时候进入服务。服务是拣货、打包、叠板、装车，由一组有限的服务器完成：人、台位、月台门，尤其是那天早班到底来了多少人。截止时间来自外部，来自承运商，而错过一次不是小错过。排队论里有一条基本关系：在制品数量等于产出率乘通过时间。任何能在不加服务器的前提下缩通过时间的动作都给你赚钱；任何在不加服务器的前提下堆在制品的动作都让你亏钱——尽管后者在头两周看上去像产出提高。

所以第一个问题不是 Agent K 行不行。第一个问题是这个队列的瓶颈到底在哪一段，因为挪动一个队列不等同于排空一个队列。

认真对待那 500 个工时，问一句：里头到底装的是什么。假设一个月 22 个工作日、一天 8 小时。一个月 500 个工时等于每天 22.7 小时，接近 2.9 个全职人力，每天如此，而且是在同一栋楼里。现在回想一下真实的波次计划长什么样：有人打开订单池，按承运商截件时间和目的地分组，看看明天楼里有多少人，排出大概四到八个波次，发出去。乱一点的现场一小时，干净的现场喝杯咖啡二十分钟。不存在任何一种版本的“编计划”能吃掉每天 22.7 小时。

也就是说，这 500 个工时不在计划本身，而在计划外面那一圈循环里：盯着今天跑下去，发现三号波次落后了，重分拣货区域，追那两票缺件的订单，回答班长“四号月台司机没来、现在该先做哪个”的问题，更新状态，确认完工，发现周二那辆车只装了一半又得重排。这就是协调税，它之所以看不见，是因为从来没有人给它设过一行会计科目。你要是想给你自己的仓库估这个机会有多大，别去掐“编一次波次计划要多久”，去掐“每班有多少小时是班长在围着计划做反应”。

下面是通稿里不会写的那一段，也是我会复印给所有正在写投资方案的人的那一句。把两个标题数字对着看。如果每月 500 小时能重复，一年就是 6,000 小时；一年省 10 万美元。相除，每个释放出来的工时值 16.67 美元。现在给它配一个真实单价：假设一个仓库协调员或班长全负荷成本每小时 35 美元——工资、附加、所有东西都算进去；你的仓库要是在工会区或沿海地区，往上调。6,000 小时乘 35 美元是 21 万美元，不是 10 万。按 45 美元算就是 27 万。而公告里的预测值，大约只等于这些释放工时的一半。

反过来算一遍更有用，因为这才是你做自己预算的方法。按每小时 35 美元、按 45% 的转化率假设，要做到年省 10 万美元，需要每月释放大约 529 小时。他们报的是 500。两者相差约 6%——这其实是让人安心的地方：数字不是编的，是某人按“大约一半的释放时间变成钱、另一半变成余量”这个假设算出来的。这一句话对你的价值，比那个准确率高得多，因为它把转化率这件事摆明了。软件释放了计划员的一天，不等于抹掉了计划员的一份工资。只有人头降了、加班降了、或者不再请临时工了，你才真的拿到现金。其余的全部被当作产能吸收掉，而产能只有在你打算长进去的时候才值钱。

还要注意那个数字配的词：可控成本。这是个有定义的篮子，装的是现场管理者管得到的那部分——加班、临时工、耗材、部分运费——刻意排除了租金、折旧和总部摊销。这个口径是诚实的。但它同时也意味着，这笔省下来的钱落在运营方的账上，于是就带出一个对进出口方才是唯一要紧的问题：如果你的第三方仓用了它，你能分到一块钱吗。开放式账本或成本加成的合同，节省一般在下一次结算时流向你；固定单价（按箱、按托）的合同，你的单价在整个协议期内被冻住，两三年里每一分都归运营方。同一套软件、同样的 500 小时，结局完全不同，而决定结局的是几年前某个人签下的一个条款。

接下来说那个 99.96%，这是整条公告里我最喜欢的一个数，因为所有的活都是分母在干。准确率可以按波次算、按任务算、按某次分配决策算、按订单行算，甚至按击键次数算。挑两种合理口径，看看会发生什么。

假设口径是波次。假设这个仓每天放二十个波次，一月 22 天，即每月 440 个波次。440 的 0.04% 是 0.176 个缺陷，也就是每仓大约每五个半月错一次，五个仓一年大约十到十一次。非常可以忍受——前提是真的有人能拦住。

再假设口径是订单行。假设同一个仓一个月处理 4 万行订单，这在快消品配送里毫不出奇。4 万的 0.04% 是每月 16 行，每仓每月 16 行；五个仓就是每月 80 行，一年接近一千行。

同样的准确率、同样的系统、两种完全不同的日常现实。而且这里的错，代价不跟数量成正比。一个被错分的行，如果在拣货环节暴露，你损失的是一个拣货员的一分钟；一票被错放进波次的订单，如果下午四点在月台上暴露，车已经走了，你损失的是一笔救急运费、一次重新排期，以及可能一个从此对你的服务水平有意见的客户。便宜的错和贵的错，在准确率这个指标里各计一次，而两者都由现场那些人擦屁股——那些人的工时，从头到尾没被算进那 500 小时里。

所以你要是那个签试点协议的人，别要一个百分率，要三样东西。书面写明计量的单位。要一份带分类的错误台账，因为“优先级排错”和“没赶上截件时间”之间的差距，就是麻烦事和一张运费账单之间的差距。还要指明恢复成本的承担人。就我见过的绝大多数仓储合同而言，这个承担人目前叫“没人”——也就是你。

接进 Teams 这件事也值得一说，它是一个穿着功能外衣的治理变更。远程派活确实有用：周日在家的班长调明天优先级，胜过夜里十一点开车来公司的班长。但告警进聊天频道，也恰恰是让好系统悄悄失效的方式。每一个弹出来的异常都在跟别的所有异常抢注意力，而它失效的量化形态非常枯燥也非常容易预测：量涨上去，人把频道静音，那个真需要人看的事件和另外九十条不需要的一起被忽略。事先设阈值。事先定好什么事配得上推送，给频道设一个你一个班次真能读完的量，然后考核确认时长，而不是送达时长。

为什么偏偏是波次计划适合放一个代理，什么时候又不适合。想想放行规则到底管的是什么。它管某一时刻系统里压着多少活、每一票什么时候开始被处理。如果你的配送中心真正的约束是高峰期四小时窗口里的拣货人力，那么再聪明的计划也变不出拣货员；它最多能做到的，是不再把根本做不完的活推到他们面前——这有价值，但值不了每天 22.7 小时。如果约束在打包能力、在月台门数量、在暂存区面积，那么更聪明的放行规则会把活推到下一个最紧的环节，在制品涨上去，你看到的证据是通道堆满、订单卡在“完成度 98%”的尾巴上。那条排队论的基本关系，不在乎你的哪个指标变好看了。

真正藏钱的地方是波动，不是人头。服务器利用率逼近 1 的时候通过时间是非线性地往上窜的，而吃掉加班工时的恰恰是突发的那几下：十五分钟里掉进来三百票、某个波次的人力严重不均、四十票小单前面压着一票大单而截止快到了。一套按实际人力把波次拉平的规则，是直接冲着方差去的；方差降下来，结果是加班工时少了、救急运费少了。我判断那 10 万美元来自加班和救急运费，不是来自裁员，公告里每个数字都跟这个判断对得上。你若想在自己的现场验它，别问厂商要一个产出提高百分比，问他每周加班工时和加急运费各变了多少。

“看一遍演示就学会”这件事值得单起一段，因为它是最不寻常的一个卖点，也是没人想透的一个。从一个演示里学会一个仓库的逻辑，部署成本确实低：没有集成项目，没有几个月的配置，没有顾问按小时收着发现业务流程的钱。但它也意味着流程定义从此永久地住在做演示的那个人脑子里。跟着来两个后果。第一，系统学到的是那个人的实际做法，包括每一条早在三次组织调整之前就该死的本地变通，然后把它固化成了策略。第二，这个人转岗、离职或者去休产假的时候，没人能复现当初教了什么。3 家客户、5 个站点，等于有 5 个人的脑子里各存了一份本地知识。

这些都构不成拒绝它的理由，但都构成在上线前写进合同的理由：必须存在一份书面的、有版本管理的流程定义；必须有第二个人能从头重跑一遍演示。然后每半年搞一次复训演练，就像演练灾备预案那样认真——站在现场的角度，那本来就是一回事。

再跟同台的那个 Takt 项目比一比，因为这个对比能教出我一直在讲的那种纪律。68 名员工、6 支队伍，花了 1,500 美元激励，省了 6,500 美元，回报率 337%。人均 22 美元。它的杠杆不是来自替代了谁，而是用每人 22 美元把六十八个人脑子里关于“浪费在哪里”的本地知识收割了一遍。还要注意：这个项目把投入也公布了，1,500 和 6,500 都知道，连队伍数都给了，让你能反算出人均值。另一个项目只公布了产出。几乎所有自动化公告都这样，不是恶意，只是自动化的投入那一侧从来都写得让人不舒服。

我还想提一句，看多了就知道激励性方案的回报是衰减的。提案型项目的第一年最好，之后就稀了——显而易见的点子被收完，新鲜劲也过了。第一年跑出来的 337% 不是一个可持续速率，500 小时同样未必。去问厂商第十八个月会怎样。

时间维度。2025 年 11 月上线，大约十一个月之后才公布了一个可信的成效点。这才是真实的上量曲线，也是你该写进自己计划的那个数。假设六到十二个月才谈得上稳定态，假设头两个月是净负的，因为那两个月里你的人在正常上班的同时还要培训另一个东西。你要是打算一季度就见效，把里程碑写进协议里而不是写进幻灯片：第二周打通数据访问，第六周系统排出第一个波次，第十二周人工复核可以不再盯着。

下面说边界条件，因为每一条都能把回报打到零。如果你的货量结构是少品种、大批量地走，一天可能只有四个波次，那没什么可优化的：排程复杂度跟着品种数和交期分布走，不跟着吨位走。如果你的需求波动极大、月度摆动超过三成，从一段行为里学到的策略衰减很快，你会陷入反复复训。如果这个站点多家客户共用、优先级互相打架，代理优化的是一个它自己都没学干净的约束集合，而话语权最小的那家承担退化。如果你的数据是脏的——库存数不准、排班表过期、承运商船期在某人的邮箱里——那么一个学得很到位的策略，正在对着虚构的事实做优化。

反面情形也摊开讲清楚。假设你那栋楼的瓶颈从头到尾就是高峰期的实际拣货速度。那么自动化任何在拣货上游的东西，你只买到一样东西：决策延迟变短。如果你的计划目前是在截件前十六小时就锁死、而现实一直在窗口里变化，那这一点值得花钱；如果你的计划本来每两小时就重排一次，它几乎一文不值。这里的回报跟“决策量乘决策延迟”成正比，跟软件先进程度无关。在任何人给你报百分比之前，先把这两个数掐出来。

拼起来，这就是我会交给客户的一套动作。肯高做出的是真东西，一个站点一月 500 小时是硬结果，不是营销数字。但价值不在于这个结果，而在于你知道它对应你自己哪几个数。用两周时间把你自己现场那圈协调循环量化出来。写下你自己的准确率定义，写明单位，给每类错误标价格。把转化假设设成释放工时的大约一半，除非你能指名道姓说出哪一条人头线、哪一条加班线真的会掉下来。然后——只有到那时候——再去决定该打的目标是那份计划，还是那份计划没能吸收掉的波动。它就是一个队列。在买东西去挪它之前，先把瓶颈找出来。

• 试点合同签署前，要求厂商书面写明分母口径——500 小时是单仓单月还是五个站点合计，目标：一季度预算批复前合同中必须有书面的基线定义。
• 从 10 月 6 日那周起做两周基线测算，量化每班花在排计划、盯进度、追异常上的班组长工时，目标：在任何厂商演示之前拿出一个站得住的每日小时数。
• 把试点合同里任何准确率百分比换成写明单位的口径，外加一份按类别拆分、并按补救成本标好价格的台账，目标：试点期内零笔无法归属主体的加急运费。
• 节省额按你自己全负荷小时成本的约 45% 折算，若没有人头线、加班线或临时工线真的下降就不计入任何现金效果，目标：第 6 个月预测与实际偏差在 10% 以内。
• 上线前要求提供书面的、有版本管理的流程定义，并指定第二名能重跑演示的人，之后每半年做一次复训演练，目标：任何上线流程都不依赖单一人员。
• 现在就去问第三方仓哪几条费用线是开放式账本或成本加成，并在部署前而不是部署后谈收益分成，目标：12 月 31 日前完成合同条款修订。