Flowness 是我们搭的多 agent 工程系统，由一个人和一群 AI agent 一起运行：人定方向、做取舍，agent 写代码、派活、审查。它从 2026 年 3 月下旬跑到现在，6 个多月；只算还留着会话记录的部分（大多是 7 月以后的），它就消耗了超过 1400 亿 Claude token，其中九成以上是缓存读取。
我们把它们写出来，是想和在做同样事情的人交流。
Flowness 真实问题 · 第 1 期 ↗
五篇里没有一条证据是假的。每条证据都正确回答了某个问题，错在做判断的 agent 拿它去回答了另一个问题。
两个进程在交替写账本，账本里看不出是两个写入者 ↗
一把互斥锁让两个进程的写入按提交顺序一条接一条，账本里每条记录的写入者标识相同、间隔相同，至今看不出是两个写入者。
一个任务派出 9 个执行会话，只有最后一个成功结束 ↗
系统里 6 月就写好了同一任务最多自动重派 3 次的上限。这个任务的重试计数记到了 8，上限一次也没有生效：据代码阅读，它不在当时实际运行的那条派发路径上。
只见过“通过”的检查，不能证明它在工作 ↗
到 10 月 6 日，一道检查留下了 332 条“通过”，其中真正判断过的，我们推断最多 4 条。没有判断的“通过”和判断后的“通过”，在账本的结果字段上一模一样。
子 agent 拒绝写入的那条记录，协调 agent 自己写了 ↗
评审子 agent 判断这条记录不该写，把理由写进了最终报告。报告写出前 6.7 秒，派出它的协调 agent 已经用它磁盘上的结果文件发出了写入命令。
上下文只用了一半就被压缩：advisor 调用与我们自己的计数错误 ↗
在我们的记录里，含 advisor 调用的请求，顶层用量约为真实上下文的 2 倍，而在 9 月 14 日的 194 次压缩里，记下的“压缩前大小”基本等于这个数字，我们推断客户端是按它判断上下文已满的。调低压缩阈值后，一天 452 次自动压缩里有 194 次发生在真实上下文只有记录值一半的时候。
术语页：本系列用到的 Flowness 内部概念 ↗
文章里碰到不熟悉的内部概念，在这里查。词条按主题分组，每条一到三句，只写文章里已经写过的内容；文章写得含糊的地方，这里同样含糊。
每篇末尾的问题都是真问题，我们想听你的做法。