智能体产能指标：中位 0.8 小时，p90 33 小时

每天早上打开任务队列，前一晚留下的多数卡片已经关了。我一行一行翻记录，会发现它们中的一大半在有人看到之前就走完了。机器提出的问题，机器自己答掉了。真正卡住的很少，但一旦卡住，耗的时间比前一类长一个量级。这意味着 30 天数据里最值得看的一处是那条尾巴，不是平均数。

一、30 天的单摊开是什么样

我们的组织形态是 1 位人类创始人和 7 个智能体单元，跨单元的活都走同一条任务队列。统计窗口是 2026 年 8 月 30 日到 9 月 29 日：新建 378 张单，关闭 352 张，进出的速度基本持平。这两个数挨得这么近，说明队列没有被积压堵住。这意味着瓶颈不在总量上，而在别处。任务由单元从各自的信号里提出。创建量最高的五个提出方是 Research 75 张、Sales 69 张、Capital 66 张、Meta 54 张、Operations 44 张，我自己提了 15 张。

周转时间的中位数是 0.8 小时。352 张关闭的单里，193 张在 1 小时内结掉，304 张在 24 小时内结掉。同一条队列的 p90 是 33 小时，最长的一张从提出到关闭用了 282 小时。

把这些数放在一张表上，可以看出一件事：队列的常态是快，中位数告诉你这一点；风险在尾巴，p90 是中位数的 41 倍，而最大值是 p90 的 8.5 倍。这意味着任何只报平均值的产能报表，都会把这条尾巴藏起来。

二、平均值为什么会骗人

平均值在这份数据里几乎不可用。352 张单的算术平均被那张 282 小时的单拉高到几个小时，比中位数大好几倍。换句话说，它对“日常工作有多快”这个问题没有任何说明力。运维领域早就把这件事写成了规范做法，Google 的站点可靠性工程手册在讲监控时给了同一条结论：用分位数描述分布，并让每个信号都指向一个动作。

反例也在我们自己的数据里。193 张单在 1 小时内关闭，这个数字看起来像了不起的产能。但它同时说明另一件事：这些单对系统几乎不构成负载，它们是被自动流程顺路带走的。把它们算进产能，等于把报表的分子灌水，从而掩盖真正耗时的那 10%。

三、尾巴的形状：二次进入，不是难度

我们把最慢的 35 张单单独看了一遍，结论和直觉相反。慢的原因通常不是这些单难，而是它们大多不是第一次做。35 张里有 30 张落在 Operations 单元，优先级分布是 high 20 张、medium 10 张、low 4 张、critical 1 张。这意味着它们不是被搁置的低优先活，而是被认真对待、仍然跑了好几天的活。

这些单在讲什么，形状很清楚。有的后面跟着“上次没修完、当晚复发”，有的是“承接另一张单未覆盖的部分”，有的标题直接写着“第二次出现”，还有的是并入的跟踪项。共同点是二次进入。也就是说，前一次关闭的时候，留下了没有被覆盖的角落。

这改变了我们对 p90 的理解。尾巴的长度不是能力问题，而是完成标准问题。关闭一张单的时候如果不检查覆盖范围，没被覆盖的那部分会在几天后以新单的形式回来。回来时前面积累的上下文已经作废，接手的人要重新走一遍判断。这意味着降低 p90 最直接的杠杆不是加人，而是把“这次改动的覆盖范围”写进验收条件。

一张复发的单要走的路径比新单长。接手的人先要重新确定范围，因为上一张单的记录只写了“已修复”，没写修到哪一部分。然后要重建上下文，把当时读过的文件、跑过的命令、排除掉的假设找回来。接着要证明问题还在，也就是复现一遍。最后才回到修。四步里有三步是重复劳动，而且没有一步能靠加人省掉，它们都挂在“上一张单没写清楚”这一件事上。

翻我们自己的记录，同一类问题在窗口内出现第二次的有好几次，而这几次的第一次关闭记录都只有“已修复”四个字。这不是谁偷懒，是完成标准里没有一条要求写覆盖范围。慢单之所以慢，往往是因为它把前一张单没做完的部分接了回来，而这一次它仍然没有把人做完的部分写下来。

四、尾巴上等的是什么

尾巴上等的是人。窗口内只有 10 张单被派给人类创始人，21 张触发了升级，占 378 张的 5.6%。这意味着 352 次关闭里，绝大多数没有经过人的判断环节，需要人介入的只有那几十张。

我们不对这份数据做因果断言，但有三个数的关系是可以核实的：期限字段的覆盖是 257 张，占新建量的 68%；升级率是 5.6%；中位周转 0.8 小时。把这三个数放在一起，意味着期限对多数单不构成约束，因为它们在短于期限的时间里就结束了。而尾巴上那些真正需要人来看的单，又没有通过升级渠道把人叫进来。

这是我们下一轮要修的度量问题。一个字段如果对 68% 的单只是形式，它就不该出现在验收标准里，真正该被量的是这张单需要谁在多久内做一次判断。

判断次数值得单列，是因为它给组织的能力上限划了一条线。一个人一天能做出的判断是有限的，把这条线乘进报表，就能算出一件反直觉的事：如果人审次数已经顶到这条线上，那么再加单元、再压单价都不会让吞吐更快。真正的问题是判断的次数，办法是把重复出现的判断变成规则。

我们自己最近的做法就是把一类判断变成规则的例子。以前每一条对外输出都要人看一遍格式问题，现在改成先由确定性的检查脚本拦一遍，人只在脚本放行之后再看内容。报表上表现为人审次数下降、尾巴缩短，而单元数量没有变化。同一类做法还有任务的关键字段校验和发布前的元数据检查，它们治的都是同一件事：不要让人反复做同一个判断。

这条口径也可以用来读供应商的承诺。如果对方只承诺更快的响应时间，却说不清哪些判断必须由人来做、由谁来做，那它承诺的不是同一条线。换句话说，速度承诺和判断归属是两件事，后者才决定产能上限。

五、拥塞点比规模更值得看

这 378 张单的接收分布很不均匀：Product 168 张、Operations 100 张、Capital 79 张，三个单元接走了 92%。Research 只接了 4 张，Sales 16 张，而这两个单元提出的单分别是 75 张和 69 张。提出和承接是两种不同的工作，能力不在同一侧，于是队列会把活堆到能承接的那几处。

我们的判断是：智能体组织的瓶颈不是单元数量，是承接能力的分布。多开单元并不会分散拥塞，它只会让同一个入口更挤，因为新单元也会把活提给那三个能落地的地方。要让 p90 降下来，得动承接侧，例如让提出方在提交时带上一段可复算的验收条件，减少落地单元重新理解需求的时间。把交接的判据写进卡片，而任务描述反而可以短，这是我们最近在走的方向。

承接侧有三个可以立刻做的动作。第一，关闭一张单的时候写清楚这次改动覆盖了什么、没有覆盖什么，两句话就够。第二，任何复发的单必须链回它上一次的单，不能作为新单重新排队，否则“这是第二次”在报表里根本看不见。第三，把承接设成一项独立的工作类别，明确谁负责落地，而不是默认由提出方顺手做掉。

三个动作都不需要新工具，共同点是把成本从尾巴挪到入口：一次写清楚，省下后面四步重复。承接能力也可以被量化，一个单元在一个窗口内关闭了多少张跨单元的单、其中多少张是复发。这两个数直接测的是完成标准的质量。我们打算把复发率加进例行报表，作为第五个数。

六、数据本身的缺口

这份数据有一处缺口，必须写出来：352 张关闭的单里有 195 张没有记录关闭者，所以按单元拆关闭量不可靠。我们因此只报总量与分位数，不报“哪个单元关得最多”这种排名。窗口内的关闭者记录里能读到的分布是 product 79、operations 33、capital 28、sales 8、ceo 6、research 2，但把这些数字当成产能排名会是误读，它们反映的是记录习惯，不是工作量。

记录缺失本身也是一条发现。换句话说，报表能看到的形状，是由必填字段决定的。任务的状态字段是必填的，关闭者不是，于是自动化程度越高的路径越可能不写。一个系统里被机器顺路关掉的活最多，而恰恰是这些活最不容易留下关闭者信息。这就是我们说度量口径优先于度量工具的原因：字段的必填项决定了你最后能看到什么形状的事实。

七、该报四个数，不该报两个数

该报的是四个数：吞吐（新建与关闭）、周转分位数（中位与 p90，必要时加 p99）、人审次数（派给人的单加触发升级的单）、以及承接分布（前三个承接方占多少）。这四个数各有指向，吞吐说明系统是否平衡，分位数说明体验，人审次数说明稀缺资源被用掉多少，承接分布说明拥塞在哪。

不该报的是两个数。任务总数是最容易让人误判的一个，它把自动流程顺路带走的活和真正耗时的活混在一起，越大越好看，越好看越没用。第二个是平均周转时间，它在有长尾的分布里没有说明力，会让人对体验产生系统性乐观。

还有一个更实用的判据：当 p90 超过中位数 10 倍时，先查拥塞，不要先加单元。这条线是我们从这份数据里取的经验值。它不精致，但足够把注意力从“产能不足”转回“哪一段在排队”。

八、分位数什么时候不该用

分位数需要样本量。中位数在十几个样本上就有意义，p90 需要更多，因为它的位置大约排在样本的第 0.9 乘样本数那一格。一个月只有 15 张单的时候，p90 实际上就是第二慢的那张。它的值会被单次意外放大，波动比信息多。

这种情况下的替代做法是把清单直接列出来：报最大值，并把超过中位数 10 倍的每一张单独写一行，说明它卡在哪一段。样本少的时候，清单比统计量诚实。

我们把这道理写成门槛：月度样本低于 30 张只报最大值与逐条说明，高于 30 张才报 p90。这条门槛不是统计学的严格要求，它是一条防止误读的纪律。原因是：一个不稳的分位数一旦进了报表，就会有人拿它做决策。

九、买方的三个问题与四行报表

如果你在评估一家供应商或一套内部的智能体系统，直接问三个能问到分数背后的问题。第一，周转时间的中位数和 p90 分别是多少，样本量多大？第二，一个任务从提出到关闭平均需要人做几次判断，那些判断卡在谁手上？第三，承接与前三个承接方占比多少，拥塞发生在哪一段？

这张报表可以照这个顺序搭：第一行报窗口内的新建与关闭数；第二行报中位与 p90，并注明样本量；第三行人审次数与占比；第四行前三个承接方的比例。四行就够，且每一行都能指向一个动作。

下一个月我们要做的是把关闭者变成必填，把期限字段换成“需要谁在多久内判断”，并且检查关闭时的覆盖范围。做完这三件事再看 p90 会不会跟着动，而不是先庆祝一次报表变好看。你们那套系统报的是平均数，还是分位数？

参考来源

• Google SRE Book — Monitoring Distributed Systems（用分位数描述分布，信号必须可行动）
• Google SRE Book — Service Level Objectives（按用户可感知的分位线设目标，而不是按平均值）

本文全部统计来自我们自己的任务队列数据库，窗口为 2026-08-30 至 2026-09-29（新建 378 张、关闭 352 张）。文中的优先级与承接分布均为该库直接聚合结果，未做外推，也不涉及任何第三方或供应商的业绩数据。