公司里只有一个人类，每天上班的是 400 多个 Agent

这家公司的人类员工，只有我一个。

平均每个干活的日子，有 400 多个 Agent（领了活就自己去干的 AI 程序）开工。

10 月 17 日凌晨，我交代了一件活：把我们系统里的机制挨个查一遍，看每一条实际被用了多少次、用了起没起作用。一个主 Agent 把它拆成 20 批，派给子 Agent（主 Agent 临时叫起来、各干一小块的 Agent），自己派、自己收，一直干到当天下午。这一件活，它前后派出了 1,109 个子 Agent。

中间的点是主 Agent，每根深色枝是一批，枝头的每个点是一个子 Agent。外圈的数字是最大的五批各有多少个，右上那一束是其余的小批。

那天凌晨，Anthropic 刚发了一份报告，讲他们楼里的 Agent 是怎么干活的：Agent 写出来的东西多到人读不完，跟人对话的 Agent，等人回话的时间比干活还长，有人开始给自己带的 Claude 小队写绩效评语。Anthropic 楼里上千人分担的事，在我们这里压在一个人身上。下面把我们这边摊开来看：同样这几件事，到了只有一个人的公司，会变成什么样。

同样的活，比 7 月少开口多了

Agent 每做 1,000 次操作要我开口的次数，从 7 月到 10 月少了 73%。

每个点是一周。纵轴是对数刻度；灰虚线是这 16 周的大致趋势，尾端标的是它从头到尾降了多少。两条竖线只标日子：9 月 24 日总控（负责一个项目、给下面派活收结果的 Agent）上线，10 月 9 日起新稿不再送我过目。

我现在常用语音跟它们说话，一句话说清要做什么，剩下的交给它们。我发得最多的消息只有两个字：“继续”，一共发了 1,037 次。

代码我也不再自己看。可它们写出来的东西，早就多到我看不过来了。

它们写的东西我读不完，审稿也交给了 Agent

Anthropic 算过：Claude 一周跟一名工程师对话写下的东西，读完要两个半星期，不吃不睡。我们这边，光是我参与过的对话，一周写下的就要读 6 个星期；连后台干活的 Agent 一起算，不吃不睡要读 19 个星期。

每个点是一周：我们的 Agent 那一周写出的全部文字，一个人不吃不睡要读几个星期。贴着底的灰线是一个星期本身，也就是一个人读得完的上限。

10 月 9 日起，新稿不再送我过目。稿子交给一个没参与写作的 Agent，按规范核对，通过就发表。需要核对事实的稿子，再加一个审计 Agent，只看原始记录，逐句核。我放弃了逐篇把关，换来的是稿子不再排队等我。

错由它们自己修，修一个就堵住一类

9 月 25 日，我们两台电脑上的代码库收到了 248 次修复提交（往代码库里存一次改动，就是一次提交）。从早上 9 点前到傍晚 7 点，每两次修复之间的间隔都没有超过半小时。

横轴是 9 月 25 日这一天的 24 个钟点，线是到那个钟点为止累计的修复提交，越陡修得越密。蓝线按常见的修复字样认，灰线按更严的认法认，两条线走势一样。

那段时间，查出来的问题越积越多。9 月 24 日，一个总控接手时，审查和临时发现的问题里，还没修好的积到了 1,757 件。它带着一批子 Agent 连着修。接手五天后，我定了一条做法：每修好一个问题，就把同一类问题从根上堵住。办法是给代码库加一道自动检查，同类问题再出现，提交时就会被拦下。接手十天后，积压降了近 500 件。

上：每周新查出的问题，按怎么发现的分三层，标数的两周一样多。下：还没修好的问题。深线是审查和临时发现的，正文说的是这一条；灰线是自动规则查出的，单独算。线尾的数是这份记录停记那天的积压。两条虚线是总控接手（9 月 24 日）和定下这条做法（9 月 29 日）的日子。

我成了最大的瓶颈

Agent 停下来等我回话时，有一半能在 23 分钟内等到，一成要等 9 个小时以上。等得最久的一次，对话搁了快两个月，我回去说了一句话，它就接着干了。

最近四个星期，Agent 停下来等我的回合。曲线上每一点表示：等这么久以内就等到我回话的，占多少。横轴是对数刻度，越往右等得越久。

等不到我的时候，它们也没闲着。凌晨 4 点到上午 10 点我几乎不说话，这 6 个小时里 Agent 照样在干活，和白天差不多多。

最近四个星期。下面每一行是一天，每一格是一个钟点，颜色越深，那个钟点在干活的 Agent 越多，带黑框的是最忙的一格。上面的灰柱是四周里我在每个钟点开口的次数合计，标数的是最多的那个钟点。虚线框圈出我最安静的那 6 个小时。

很多事，它们干脆不等我。10 月 23 日凌晨 3 点多，负责网站的 Agent 上线了一个改动，网站上所有文章页一下子都打不开了。它上线前先把全站每一页的状态记了一份底，上线后马上逐页比对，5 分钟内发现问题、撤掉新加的路由、恢复原样，又把整站重新比了一遍。这次的教训当天就定成了上线规矩。从出错到恢复，没有一步等我。

总有事非我不可：登录、扫码、付款、拍板。对外团队（负责我们发文章、发帖的那组 Agent）的做法是，需要我本人做的事先交给总控，记进一本叫“找 Nature 的账”的账里（Nature 就是我），攒成一条消息发给我。公众号定时发表要我扫码，就把一周的稿子攒到一起，一次扫完。

三层 Agent 管 Agent

我们的 Agent 平常分三层。大一些的项目各有一个总控；总控下面是部门，每个部门是一个管一块事的 Agent，比如管网站搜索的、管发帖的；部门下面才是临时派出去干具体活的子 Agent。

产品工厂（我们把常见业务场景做成可卖产品的项目）的总控，叫总参谋。10 月 10 日凌晨，产品工厂开工：总参谋是一个 Fable 5.1（Anthropic 的模型），带着 10 个部门，一个部门领一个产品，再派自己的子 Agent 干活。做的是给中小企业和工厂用的小工具，应收账款催收、合同风险审查、紧急插单评估这一类。总参谋每 3 小时给各部门写一次复盘，看谁快谁慢、谁在空等、现在能不能卖。两天，10 个产品全部做完评测。

总参谋是我开的头，下面怎么分、怎么派，是它们自己定的。从 9 月 20 日到 10 月 18 日，Agent 之间直接发出了 3,754 条消息，有些协调已经不需要经过我了。下面这张图是其中一角，图里一个人都没有。

每个点是一个 Agent，点越大，它收发的消息越多；线表示两个 Agent 之间有过消息来往。颜色是算法按来往疏密自己分出来的队，数字是每队的 Agent 数：左边一队以对外团队为主，带圈的是对外团队的总控；右下一队是另一条产品线。底下一排灰点是只有两到四个 Agent 的小块。

人的决定，要放在 Agent 每次都会读的地方

我们写给 Agent 的规矩，包括说明书、遇到某类活才读的技能手册、跨对话留下的记忆，去年 12 月盘上能追到的还只有 97 行。现在，4.1 万行。可一个 Agent 开工时真正读进去的，最多也就五百多行：先读一份全局规矩，再读一份所在项目的说明，用到哪个技能，再去读哪个。这几处写了什么，它就照做什么。

上：写给 Agent 的规矩一共有多少行，从去年 12 月数起，加粗那段是涨得最快的三个月。下：9 月 10 日以后，每天开工时读进规矩最多的那个 Agent 读了多少行，右下角是它占累计行数的比例。

规矩多了，也闹过笑话。“每篇新稿先推给 Nature 过目”这条规矩已经作废，却还留在一个部门每次醒来都要先读的那段开工交代里。那个部门每醒来一次就读一遍，前后读了 83 次，这条旧规矩才被发现并换掉。

我们的办法是黑板系统（AI 里一种老办法：大家往同一块板上写，也都从这块板上读），落到我们这里，就是一份写着目标、进度和待办的文件。常驻的部门（一直开着、按固定钟点自己醒来的部门）醒来先读黑板，再在第一行留一句心跳，相当于报到：记下几点醒的、上一轮干了什么。

心跳也是被逼出来的。有一阵，3 个部门停了四五天，居然没有一个 Agent 发现，最后是我自己问了一句才知道。之后定了规矩：总控每小时检查一遍所有常驻部门的心跳，隔了几个钟点还没动，就把它重新拉起来。总控自己停了也有人管：别的部门醒来的时候，顺手看一眼总控的心跳。

底座是我一个人带着 Agent 造的

前面修问题的那批 Agent，跑在我们自己造的底座上：包在模型外面的一层程序，业内叫 Harness，管派活、记账、拦错。从 5 月 21 日第一次提交算起，我一个人带着 Agent，留下了 9,648 次提交。

Agent 往底座的事件记录里写东西之前，先过一道门。到现在它拦下了 1,261 次，大多是 Agent 要改的东西碰了定过的规矩。

组织要搭成不用等我的样子

我在它们身上花 1 小时，它们干 100 小时。这 1 小时，我主要干 3 件事。定方向，一句话说清要做什么。处理必须由我本人完成的事，登录、扫码、付款、本人授权。还有拍板，Agent 拿不准的时候由我决定，难拍的先交给 Fable 5.1，让它给出决定和理由。

这篇文章也是这么来的。我说了一段话，Agent 去翻记录、查旧账、出图、审事实、复审；我看稿、挑毛病，最后拍板。

这半年我学到的就一件事：Agent 多到一定程度，产能的上限就是人。Anthropic 楼里上千人，可以分着等；我这里只有一个人，等的全是我。所以我只在非我不可的地方出现，其余的事由它们按钟点排好、互相核过，攒成一条再来找我。

如果你也在用 Agent 干活，可以先数一个数：上周，它们等了你多久。翻翻对话记录，就能数出来。

附录：数据与方法

正文里的数，来自两台电脑上的运行记录（533 万条消息）、底座的事件记录（93 万条）、代码库的提交记录（5.7 万次）和语音输入记录。只取时间、计数和分类，不取文字。所有数据装进一个 DuckDB 仓库，每张图都有对应的 SQL 或脚本。我们让一个没参与分析的 Agent 照跑了一遍，正文九张图的数字全部对上。

几处口径：

“400 多个”是 8 月 25 日到 10 月 22 日这 59 天里，每个干活日有过工具调用的 Agent 数的平均值。中位数是 254，四分之一的日子超过 585。
“23 分钟”只算 Agent 已经停下、我再开口的那些回合，取等待时长的中位。按对话整块重抽 2,000 次，中位的 95% 区间是 18.6 到 25.8 分钟。
“少了 73%”：每周我发的消息数除以每周操作千次数，从 7 月 3 日那周到 10 月 16 日那周共 16 周。取对数做线性回归，斜率是每周 −0.086，95% 区间 −0.132 到 −0.040；按这条趋势线首尾相比（跨 15 周），降到原来的 0.275 倍左右（0.2747），少了约 73%。单周波动大，不拿两个单周直接比。
“19 个星期”按 Anthropic 的换算（每个 token 0.75 个词，每分钟读 250 词），取 9 月 25 日到 10 月 22 日四周的平均。9 月中那四周是 25 个星期。
“248 次”按提交主题含 fix、修复、修正、bug、hotfix 一类字样算，两台电脑去重。只认 fix、修复、bug 的严格口径是 194 次。
“1,757 件”和“近 500 件”来自底座事件记录里的问题事件。这份记录从 10 月 4 日起不再记这类事件，之后积压了多少，我们不知道。
“继续 1,037 次”和“常用语音”来自 10 月 19 日存档的统计。仓库里不存文字，这两个数没有在仓库里重新算过。
和 Anthropic 并排的两笔：读完一周输出，他们只算跟人对话的那部分，424 小时，约两个半星期；我们同口径是 1,000 小时，约 6 个星期，把后台 Agent 全算上是 3,235 小时，约 19 个星期。交互中等人的时间占比，他们约八成，我们最近四周 76%。
“1 小时对 100 小时”来自 10 月 12 日定稿的一份工时核算，不在上面的仓库里：9 月 14 日到 10 月 11 日这四周，Agent 平均每周干 1,479 小时（每 5 分钟里有输出就记 5 分钟，空等不算）；我每周花在它们身上 14.8 小时，含说话和读、想的时间。

我们还登记了四个预测：10 月 27 日到 11 月 2 日这一周的 Agent 工时、每千步要我开口的次数、回话延迟中位（登记的是全部回话的中位，和正文的 23 分钟不是一个口径）、修复类提交数，每一项都给了模型算出的 95% 预测区间。11 月 3 日，由一个没参与分析的 Agent 算实际值，中不中都补在本页文末。

关于我们　ToWow Flowness 是我们自己做的多 Agent 框架，一种分布式 Harness。很多个 Agent 节点共用一份事件记录，按时间记下每个决定和结果，一起完成复杂任务。