- 问题： 一位开发者的 Mac 上，AI 工具占了 72.6 GiB，光 Codex 就有 53.7 GiB、21,613 个文件。
- 我们发现： 最大的那批对话里，77% 是图片；其中 39% 是 Agent 压缩上下文时又存了一遍的副本。子 Agent 只占 30%。
- 我们做了什么： Mint 的 Optimize 会保留继续对话时 Codex 要读的图片。Keep text only 则永久去掉图片、音频和视频，文字全部保留。
Codex、Claude 或 Cursor 占到几十 GB 时，直接删掉整个文件夹可能会丢掉工作记录。先把对话和其中的图片，与缓存、临时构建和虚拟机镜像分开。这篇记录了我们在一台 Mac 上测到的差别；具体操作请结合文中链接的各工具现行清理指南。
所以我们打开看了看。在一台开发者的 Mac 上，AI 工具一共占了 72.6 GiB。光 Codex 就有 53.7 GiB、21,613 个文件。Claude Desktop 11.8 GiB，其中 10.1 GiB 是虚拟机镜像。然后是 Cursor 5.4 GiB，Claude Code 1.5 GiB，Gemini CLI 0.2 GiB。
总数本身不算意外，我们给别的开发者看过，每个人的数字都差不多。让我们意外的是这些字节到底是什么。几乎没人猜对，我们自己一开始也没猜对。
文字占得很少
大家一般会觉得，Agent 跑得久，写的文字多，堆起来就大了。并不是，文字几乎不占空间。
我们在本机流式读了最大的 50 个活跃会话文件，一共 10.9 GB，给里面每一段内嵌数据都算了哈希。图片占了 10.9 GB 中的 8.43 GB，这份「对话历史」里 77% 是像素：Agent 截的图、它生成的图，还有它只看过一次的可视化工具输出。
接着看这些图片里有多少不重复。8.43 GB 图片里，只有 5.17 GB 是唯一的。3.26 GB，也就是 39%，是同一个文件里已有的内容又存了一遍。 17,643 张内嵌图片里，11,790 张各不相同，5,853 张是重复的。
17,643 张内嵌图片 · 11,790 张唯一 · 5,853 张是文件里已有内容的重复
压缩是怎么产生副本的
会话一长，上下文迟早会用完。为了接着干活，Agent 会压缩历史，把到目前为止发生的事总结一遍，再从摘要往下走。这很合理，也是必须的。
可这些会话文件里的图片，是整张以 data URL 的形式直接内联在记录里的，没有存成指向磁盘文件的路径。写压缩记录时，有一些记录没去引用之前的图片，而是把刚总结过的图片数据原样又嵌了一遍。
于是第一轮带着原图，第二轮带着原图加第一轮的副本，第三轮再把这些全带一遍。每压缩一次，历史就更大一点，而且增长是线性的，跟之前所有图片内容的体积成正比。
我们看过的最大的单个会话文件有 14 GiB，就是一段对话。里面有 359 次压缩事件、13.6 GiB 内嵌图片数据，唯一的图片内容却只有 155 MiB。99% 是同样的图片反复出现，其中五张图，每张重复了 45 到 136 次。到这一步，压缩记录里装的大多是文件里早就有的图片副本。
字节是从哪来的
网上现在有个很流行的说法，解释 Agent 为什么吃磁盘，听起来也很有道理：Agent 派生 subagent，subagent 继承父任务的历史，每个分支再复制一遍数据，任务树越分越多，Agent 越多副本就越多，直到磁盘满了。
我们一开始也信。不过这台机器上就有能查证的数据，那就查一下。
Codex 有自己的任务数据库，里面有一张派生关系表，记着哪个任务是由哪个任务创建的。我们把磁盘上每个 rollout 文件都对应到它的任务上，然后看这 50.4 GiB 分别在哪。
在编辑器里发起的主任务会话占 32.9 GiB，65.4%；派生的 subagent 任务占 15.1 GiB，30.0%；命令行会话 2.1 GiB。三分之二的字节跟 subagent 毫无关系。
这决定了该怎么解决。如果原因是扇出，解法就在怎么用 Agent 上：少开几个 Agent，限制并发，分工时克制一点。这些建议本身有用，但在这台机器上最多只能解决三分之一的问题。
原因在重新内嵌，这用不着 subagent，一段够长、里面有图的对话就够了。subagent 只是把问题放大。只减少 subagent，重复还在；把重复去掉，subagent 那部分也会跟着变小。
「归档」不释放任何空间
还有一件事要提，很多人在这上面白花过一个下午。在 Agent 里归档一段对话，只是把文件从一个目录挪到另一个目录。在我们测的这台 Mac 上，1,174 段已归档对话还占着 16.1 GiB。归档让列表更整洁，但不省空间。东西删掉了，空间才会回来。
如何读取 14 GB 而不把机器搞崩
这里插一段工程上的事，它差点让这次调查做不下去。
我们最早的分析器，是在一个循环里流式读这些会话文件，读过的东西一直不放手，进程就把所有东西都留在了内存里。读 1.15 GB，常驻内存就到了 1,097 MB。拿它去读那个 14 GB 的文件，这台 Mac 直接报了「应用程序内存不足」。
重写以后改成读进同一个可复用的缓冲区，同样读 1.15 GB，常驻内存只有 14 MB。重写之后，完整清点 72.6 GiB 只用了 8.6 秒，常驻 28 MB；深度哈希流式处理 10.9 GB，常驻 42 MB。我们还加了一条运行时检查：读一个文件的过程中，内存涨得太多，这一趟就自己停下来，不会把机器拖垮。
没有这一步，工具根本没法看这些文件里面有什么。一个要 18 GB 内存才跑得起来的分析，谁也没法做成产品发出去。
用去重代替删除
知道这些字节是重复的，该怎么做就好判断多了。
删掉一段对话，丢的是工作本身：推理过程、diff，还有当时为什么做某个决定。不该让人为了腾点磁盘被推着去删。在对话内部去重，什么都不会丢。每张图片第一次出现的地方原样保留，后面的重复都被替换掉。
当时这样改完，对话在 Agent 里照样能打开，截图也都还在。因为第一份一直留在文件里，这个改动能直接从文件本身逐字节还原，不需要保险库，也没有会丢的外部状态。
我们最先上线的就是这个，叫优化，它说的都是实话。后来我们把同样的测量跑遍了整个存储，不只是最大的五十个文件，发现了三件事：对话内的重复是三个池子里最小的；这些重复大多在还在用的对话里；一段对话可能依赖另一段对话的文件，所以改动那个文件并不安全。完整的普查写在《22 GB 的 Agent 对话里到底是什么》里，那篇提到的早期小预览图做法已经停用了。现在 Mint 把两个操作分开：Optimize（优化）保留 Codex 继续受支持对话时读取的图片；Keep text only（只留文字）保留文字，永久移除内嵌图片、音频和视频，原来放图片的地方留一条说明，不是小预览图。
有些东西没变。永久删除删的是整段对话，通过 Agent 本身来删，这样它的索引能保持一致。对话默认都不勾选，Keep text only 和永久删除都会先让你确认，再去动文件。受支持的 Optimize，只要所需的原始数据和历史还在，就可以撤销；Keep text only 和永久删除都撤销不了。具体以你安装的版本在确认框里的说明为准。
我们学到了什么
Agent 存储看起来像个黑盒，主要是因为没人去看，它没那么复杂。那些文件就是你自己磁盘上的纯文本，任务数据库是一个你能直接打开的 SQLite 文件，重复率用一个哈希函数花一个下午就能测出来。
我们一开始想写的是「Agent 会产生很多数据，这里有个清理工具」。查完发现情况更具体：大部分是同一份数据被存了一遍又一遍。有多少你都能看到，精确到每个文件，就在你自己的机器上，什么都不用上传。
所以 Mint 会把数字和原因都摆出来，你不用光凭信任。除非你点「永久删除」，它不会删掉对话。Optimize 保留 Codex 会读取的内容；Keep text only 则是另一种取舍，保留文字并丢弃媒体。现行指南说明了两者的区别。
文中所有数字都是 2026 年 8 月用 Mint 自己的只读扫描在一台开发者 Mac 上实测的。这些扫描是只读的，全部在本机跑，你也可以在自己的机器上复现。