想象一下，你用了 Codex 大半年，某天系统提醒你磁盘快满了。你打开磁盘分析工具，发现一个叫 ~/.codex 的目录居然占了二十多 GB。你的第一反应很可能是：这些旧对话留着干嘛，删掉算了。

但在动手之前，有一个更冷静的问题值得先问：这些字节里，到底装的是什么？如果不知道里面是什么，任何"清理"都等于蒙着眼睛删东西。

Mint 的开发者做了一件很少人愿意做的事：他们把一台开发者 Mac 上整个 Codex 会话存储逐字节读了一遍。1,231 个文件、22.83 GB，每张内嵌图片都做了指纹，每个指纹都在会话内部和会话之间做了比对，每段会话都标注了最后使用时间。这不是抽样，是一次普查。而普查的结果，推翻了不少他们原本的假设。

十成字节里，有七成是图片#

先说总量。22.83 GB 里，图片占了 16.18 GB，文字（提示词、工具输出、agent 的推理过程）只有 6.65 GB。剩下的东西不值一提：音频几乎为零，没有视频，也没有构建产物，只有藏在工具输出里的构建日志。

真正有意思的，是图片内部的结构。16.18 GB 里，只有 3.81 GB 是存储只保存过一次的图片，剩下的大半都是重复：

  • 5.71 GB 是同一段会话里反复出现的截图，也就是上下文压缩机制在"重新嵌入"它刚刚总结过的内容；
  • 6.66 GB 是跨会话的重复截图，同一个终端、同一个被测页面，被几天后粘进了另一条线程。

换句话说，这台机器上的"对话历史"，每十个字节里就有七个是像素，而其中不到两个字节是别处不存在的像素。

文字也有类似的结构，只是规模小一点。6.65 GB 里，大约 2.7 GB 是被写了两遍的同一段文字：agent 每完成一步，既记一次"步骤"，又记一次"完成该步骤的事件"；一条命令的输出，既作为输出落一份，又作为聚合副本落一份，每份都封顶 1 MB。一条很长的构建日志，最多可以被存四遍。

这里作者的态度很有意思：他们测出来了，但他们不去动它。因为这是 agent 自己的读取约定，一个会去改写"别的程序依赖的数据"的工具，就已经不是一个清理工具了。

重复的截图，几乎都藏在"最近"里#

最常见的清理思路是按时长：给用户一个滑块，“7 天没用、14 天、30 天”，让用户清掉那些不再使用的东西。几乎每个存储工具都有这个滑块，Mint 一开始也做了。

但等他们把会话内的重复截图按"所在会话的年龄"排个序，结果就反过来了：92% 的重复截图，都待在最近六天内还在使用的会话里。这台机器上最大的一个文件，1.76 GB、才 3.9 天新，光它一个就装下了 1.57 GB 的重复截图。而超过一个月的旧会话，加起来只有 0.02 GB。

这不是某一台 Mac 的怪癖。重复是"又长、又新、又截图密集"的会话的属性：压缩机制只在会话长到需要它的时候才启动，而且它重新嵌入的是它自己所在会话里的图片。旧会话要么短、要么纯文字、要么两者都是。

于是问题就来了：如果你从"一周没碰的东西"开始清理，你恰好绕开了几乎所有值得回收的空间。一个用户把滑块拖到七天、按下按钮、拿回 151 MB，实际上等于被告知"里面啥也没有"。可里面有 5.7 GB，只是它藏在滑块的另一头。

五种策略，一笔账#

一旦每个字节都有了指纹和年龄，你就能在动手之前，先给每一种清理策略标个价。对这台机器来说，这个"账本"是这样的：

  • 删掉五天没碰的会话，能释放 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 里、在部署里。人们回头翻一段对话，为的是文字：试过什么、决定了什么、为什么。

所以他们交付的核心动作叫"压缩”（Compress）。挑出你还想能读的对话，里面的每张截图变成小预览图，其他多媒体变成一个占位符，文字一个字都不动。对话在 agent 里照常打开，预览图就待在原来截图的位置。它在这台机器上能释放 22 GB 里的约 9 GB。它是不可逆的，确认框会用一句话说清楚：原尺寸的图回不来了。

他们第一次运行它，用的就是上一篇文章里那个 14.84 GB 的会话，压缩后变成 907 MB。15,354 张截图变成了预览图，agent 自己的读取器之后返回的还是同样的 68 轮、3,895 个条目，文字逐字节一致。一批 275 个会话、3 GB 的文件，大约 20 秒处理完。

旁边挨着的是"删除”（Delete），给那些你已经用完了的对话：整段离开 agent，走 agent 自己的删除路径，所有空间都回来。产品里这两个按钮并排解释，从用户的视角出发，“还想回头看看？“对比"用完了？"。因为普查教会了他们，这两个选项的差别，几乎就是一个存储工具需要说的全部。

他们把原地的去重按钮下架了。它可逆、它聪明，但整个存储上它只值 2.73 GB 的归档空间，而那个诚实的动词值 9.7 GB。

其他 agent 也跑了一遍同样的普查#

同样的普查，在这台机器的其他工具上跑了一遍：

  • Claude Code 把会话存成项目文件夹下的普通文件：610 个会话、1.75 GB，其中 526 MB（30%）是内嵌图片，175 MB 是会话内重复，66 MB 跨会话重复。形状一样，只是规模更小，同样的动词也适用。
  • Cursor 把聊天图片作为普通文件放在 workspace 数据旁边，284 张、56 MB，而它 2.6 GB 的状态数据库是文字。这里没什么可做的。
  • Claude Desktop 把对话放在服务端。它本地 12.6 GB 的数据里，10.9 GB 是"电脑操作"功能的虚拟机镜像，1 GB 是无图的会话记录。那是另一个问题，也是另一篇文章。

真正学到的东西#

抽样告诉我们，agent 存了大量重复的图片。普查告诉我们的，是"在哪里”，在那些人们还在使用的会话里，而不是被遗弃的会话里；以及"每种补救值多少”，在他们动手构建任何东西之前。

这直接重排了他们的路线图：最显眼的杠杆其实是最小的，最显眼的坐标轴其实指向了反方向，而那个诚实的动词，保住文字、缩小图片、并坦承这是不可逆的，值三倍于那个聪明的动词。

它也告诉我们，一个会话不是一个文件。它可能是通往另一个文件的一扇窗，而一个不知道这一点的清理工具，会弄坏它从没碰过的东西。

我自己读下来，有三层体会。第一层是关于"测量"本身。很多产品的坑，在于用一个"抽样"的结论去做"普查"层面的决策。抽样说"有重复"，普查说"重复在哪、值多少"。差的不是答案，是粒度。一个会读全量数据、会做指纹、会在动手之后再用原程序验证的工具，和只看目录列表的工具，差的不是聪明，是基本功。

第二层是关于"诚实"。压缩和删除的差别，被他们用一句话点破：一个还想要，一个不想要。而"可逆的去重"这种听起来更高级的方案，恰恰因为它试图同时讨好两边，反而两头不讨好。做存储清理这类事，最值钱的往往不是技术上的精巧，而是坦率地把"不可逆"三个字写在按钮上。

第三层是关于 agent 数据的本质。我们习惯把文件当成独立、自足的东西，但 agent 会话不是。它会引用另一个文件里的字节偏移，它的文字被设计成写两遍，它里头的截图是流程而非成果。当你用对待"普通文档"的方式去对待 agent 数据时，你已经埋下了破坏的种子。

下一次你的磁盘报警，别急着删 ~/.codex。先问一句：里面到底装了什么。

参考来源：Yukun Gao，《What 22 GB of Agent Conversations Is Made Of — Building Mint》，DZG STUDIO / Mint for Mac，2026-09-03。原文链接：https://mint.dzgapp.com/build-journey/what-22-gb-of-agent-conversations-is-made-of/