22 GB 的 Agent 对话里到底是什么

上个月我们打开了一位开发者的 Agent 存储，抽样了最大的五十个对话文件。77% 的字节是图片，其中 39% 是重复的。那是一次抽样，而抽样只能大概回答「里面到底是什么」。 所以这一次我们把它全部读了一遍。一个 Codex 存储库里的每一个对话文件——**1,231 个文件，22.83 GB**——每一张内嵌图片都做了指纹，每个指纹既在它自己的对话里比对，也和其他所有对话比对，每一段对话都按最后使用时间标了日期。不是抽样，是普查。 普查改变了我们最终上线的东西。 ### 十个字节里有七个是图片 :::census-composition 22.83 GB 里，图片占 **16.18 GB**。文字——提示词、工具输出、Agent 的推理——是 6.65 GB。其他都不值一提：音频四舍五入为零，没有视频，也没有构建产物，只有工具输出里的构建*日志*。 有意思的划分在图片内部。只有 **3.81 GB** 是整个库里只存一份的图片。**5.71 GB** 是同一段对话里更早出现过的截图的重复——就是上一篇讲的那个压缩上下文机制，把刚摘要过的图再嵌一遍。还有 **6.66 GB** 是*另一段*对话里已经有的截图的重复：同一个终端、同一个待测页面，几天后被贴进了另一个线程。 换句话说：这台机器上每十个字节的「对话历史」里，七个是像素，而其中只存在于此一处的像素不到两个。 文字也有一个小号的同款形状。6.65 GB 里约有 **2.7 GB** 是同一段文字被写了两遍——Agent 把每一个完成的步骤记一次「步骤」、再记一次「完成事件」；一条命令的输出既作为输出落盘，又作为汇总副本落盘，各自上限一兆。一份很长的构建日志最多可以被存四遍。我们测量了它，但不碰它。那是 Agent 自己的读取契约，一个改写别的程序所依赖内容的工具，就不再是清理工具了。 ### 重复都是新的 最显而易见的清理维度是时间。给用户一个滑块——「7 天、14 天、30 天没碰过」——让他们清掉不再用的。所有存储工具都有这个滑块，我们也有。 然后我们把对话内的重复按它所在对话的年龄排了序。 :::census-duplicates-by-age **92% 的重复位于最近六天用过的对话里。** 这台机器上最大的单个文件——1.76 GB，3.9 天前的——自己就装着 1.57 GB 的重复截图。超过一个月没碰的对话加起来只有 0.02 GB。 这不是某一台 Mac 的怪癖。重复是「长、新、截图多」的会话的属性：压缩上下文只在对话长到需要它时才发生，而它重新嵌入的正是它所在这段会话里的图片。老对话要么短，要么是纯文字，要么两者皆是。所以一个从「你一周没碰过什么」出发的清理，几乎完全指向了不值得回收的那一头——一个把滑块拖到七天、按下按钮、拿回 151 MB 的用户，实际上被告知：那里什么都没有。 那里有 5.7 GB。它在滑块的另一端。 ### 五种深度，一把梯子 一旦每个字节都有了指纹和年龄，你就可以在运行任何一种策略之前，给每一种清理策略定价。这是这个存储库的那把梯子： :::census-depth-ladder 删除五天没碰过的对话能释放 **16.02 GB**，也是唯一会碰到文字的策略。它同样是唯一会毁掉你可能想找回的东西的策略：推理过程、diff、某个决定为什么被做出的记录。 对话内去重——我们最先上线的那个想法——在整个库里能释放 **5.71 GB**，其中只有 **2.73 GB** 位于用户已归档、不再使用的对话里。跨对话去重还能再释放 **6.66 GB**，但它需要一个 Agent 一无所知的共享仓库，以及一条依赖那个仓库存活的撤销路径。我们测量了，没有做。 而把每一张截图换成一张小预览图——保留文字，保持对话可读——仅在已归档的对话里就能释放约 **9.7 GB**。那些文件里的 49,597 张截图共 10.31 GB；它们的预览图大约 0.6 GB。 这个排序让我们意外。最聪明的策略是最小的。最诚实的那个是第二大的。 ### 一段对话可以依赖另一段对话的字节 普查还翻出一件事，因为它读的不只是载荷，还有文件头。 Agent 允许你分叉一段对话——从第 30 轮岔出去，在别处继续。分叉出来的对话并不复制前三十轮。它记录的是：*「我的历史是那段对话的前 117,348,378 个字节。」* 一个字节偏移量，指向一个它并不拥有的文件。 把基底缩小——去重它、压缩它、以任何会挪动一个字节的方式碰它——偏移量就指到了文件末尾之外。Agent 拒绝打开这个分叉：*cutoff byte offset is past the source rollout*。 这台机器上，1,231 段对话里有 22 段是分叉。16 段完好。**3 段被我们自己早先的去重弄坏了**——它缩短了两个基底对话，却不知道有人依赖它们。另外 3 段是 Agent 自己弄坏的，它缩短了自己的基底。 我们把那两个基底逐字节还原了——第一版的可逆性在这里挣回了它的价值——分叉重新能打开了。而工具现在在读取任何一个载荷之前，就拒绝改动任何被别的对话所依赖的对话。这个教训不止于 Agent：一个看起来自成一体的文件未必真的自成一体，而最便宜的安全检查，是去问那个拥有这种格式的程序，它还能不能读你产出的东西。我们现在每次改动之后都用 Agent 自己的读取器问一遍。 ### 我们转而上线的东西 从用户真正想要什么出发。没有人是为了截图而保留一段 Agent 对话。那些截图是 Agent 在看一个终端、一个失败的测试、一个它正在修的页面——是工作流，不是工作。工作在仓库里、在 PR 里、在部署里。人们回头翻一段对话，要找的是*文字*：试过什么、决定了什么、为什么。 所以我们上线的动词是**压缩**。挑出那些你仍希望能读的对话；里面的每一张截图变成一张小预览图，其他任何多媒体变成占位符，文字一个字都不动。这段对话在 Agent 里打开时和之前一模一样，预览图就在截图原来的位置。它在这台机器上释放了二十二 GB 里的约九 GB。它是不可逆的，确认框用一句话说清楚：原尺寸的图片无法找回。 我们跑的第一段对话，就是上一篇里那个 14.84 GB 的。它变成了 **907 MB**。15,354 张截图变成了预览图；之后 Agent 自己的读取器返回的仍是同样的 68 轮、3,895 条记录，文字与原来逐字节一致。一批 275 段对话——三 GB 的文件——大约二十秒。 它旁边是**删除**，留给那些你已经用完的对话：整段对话通过 Agent 自己的删除路径离开 Agent，它的全部空间都回来。产品里把这两个按钮并排解释，从用户的角度——*以后还想回看？* 和 *不再需要了？*——因为普查教会我们，两者之间的差别，就是一个存储工具要说的大部分内容。 我们下线了那个原地去重按钮。它可逆，它聪明，而在整个库上它值 2.73 GB 的已归档空间，诚实的那个动词值 9.7 GB。 ### 其他 Agent 同样的普查，跑在这台机器上的其他工具上： - **Claude Code** 把会话作为纯文件放在它的 projects 目录下：610 个会话，1.75 GB，其中 **526 MB（30%）** 是内嵌图片——175 MB 在会话内重复，66 MB 跨会话重复。同样的形状，小一号的规模；同样的动词适用。 - **Cursor** 把聊天里的图片作为普通文件存在工作区数据旁边——284 个，56 MB——它 2.6 GB 的状态数据库是文字。这个动词在那里无事可做。 - **Claude Desktop** 的对话在服务端。它本地的 12.6 GB 是 10.9 GB 的虚拟机镜像（给它的电脑操作功能用）和一 GB 没有任何图片的会话记录。另一个问题，另一篇文章。 ### 我们真正学到的 抽样告诉我们 Agent 存了很多重复的图片。普查告诉我们*在哪里*——在人们还在用的对话里，而不是他们放弃的那些——以及*每一种补救各值多少*，而且是在我们做出任何一种之前。这重排了路线图：显而易见的杠杆是最小的，显而易见的维度指向了错误方向，而诚实的动词——留下文字、缩小图片、说清楚不可逆——值那个聪明动词的三倍。 它还告诉我们：一段对话不是一个文件。它可能是通向另一个文件的一扇窗，一个不知道这一点的清理工具，会弄坏它从未碰过的东西。 Mint 知道这些，不是因为它比目录列表更聪明。是因为它读了全部、给全部做了指纹，然后问 Agent：剩下的你还读得了吗。 --- *文中每一个数字都来自 2026 年 9 月对一台开发者 Mac 上 Agent 存储的字节级普查，由 Mint 自己的只读分析在设备本地完成。关于机制的姊妹篇是[你的 Coding Agent 正在吃掉你的硬盘](/build-journey/agents-are-not-a-black-box)。*

测量方法