- 问题： 一个 Codex 文件夹有 22 GB。十个字节里有七个是截图，大多是同一张图被一遍遍存下来。
- 我们发现： 92% 的重复在这周的对话里。删掉旧对话只拿回 151 MB，5.7 GB 还在。
- 我们做了什么： Mint 的 Optimize（优化）去掉 Codex 不会再读的重复截图，可以撤销；也可以永久拿掉图片，留下每一个字。
数据和方法
当前操作说明（2026 年 10 月 1 日）： 下文移除图片的测量对应 Keep text only（原名 Remove media），保留文字、永久丢弃媒体。它与 Optimize（优化）不同：受支持的优化保留 Codex 继续对话时读取的图片，并在所需原始数据和历史仍在时支持撤销。
上个月我们打开了一位开发者的 Agent 存储，抽了最大的五十个对话文件来看。77% 的字节是图片，其中 39% 是重复的。不过抽样只能大概看出里面有什么。
所以这次我们把一个 Codex 存储库里的对话文件全部读了一遍，一共 1,231 个文件，22.83 GB。每张内嵌图片都做了指纹，每个指纹既在它自己的对话里比，也跟其他所有对话比，每段对话都按最后使用时间标了日期。这次普查的结果改变了我们最后上线的功能。
2026 年 9 月 2 日至 3 日在一台开发者的 Mac 上测的：把 Codex 存储里的每一个 rollout 文件逐字节扫了一遍（1,231 个文件，22.83 GB，约九十秒），没有用 Mint 自己的汇总数据。每张内嵌图片都做了指纹，先在所属对话里比，再跟其他所有对话比；每段对话按最后使用时间标了日期。改写后的对话还能不能打开，用 Codex 自己的读取器（app-server 的 thread/read）来查，损坏的分叉也是这样找到的。Claude Code、Cursor 和 Claude Desktop 的数字，来自对它们各自目录的同类扫描。得出这些数字的分析只读不写。
发现一：十个字节里有七个是图片
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 每完成一个步骤，会记一次「步骤」，再记一次「完成事件」；一条命令的输出既存成输出，又存一份汇总副本，各自上限 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 完全不知道的共享仓库，撤销也得靠这个仓库一直在。我们测了，没有做。
把图片全部拿掉、只留文字，光是已归档的对话最多就能释放大约 10.3 GB。这些文件里的 49,597 张截图一共 10.31 GB，每张图原来的位置只留下一条说明。如果改成把它们缩成小预览图，也就是我们最先上线的做法，会留下大约 0.6 GB 的图片，能释放大约 9.7 GB。
这个排序出乎我们意料。最聪明的方案释放得最少，最朴素的拿掉图片，释放的空间仅次于直接删除。
发现四：一段对话可以依赖另一段对话的字节
普查除了读内容，也读了文件头，所以还发现了一件事。
Agent 允许你分叉一段对话，比如从第 30 轮岔出去，在别处接着聊。分叉出来的对话不会复制前三十轮，它依赖原对话的文件。
手动修改或缩短那个文件，可能让依赖它的对话无法读取，Agent 会拒绝打开。
这台机器上，1,231 段对话里有 22 段是分叉，其中 16 段没问题。3 段是被我们自己早先的去重弄坏的：它缩短了两段对话，但不知道还有别的对话依赖它们。另外 3 段是 Agent 自己弄坏的，它缩短了自己的基底。
我们把那两个基底逐字节还原了，分叉又能打开了，这多亏第一版是可逆的。现在工具在改动任何内容之前，会先检查这段对话是不是被别的对话依赖，是的话就不改。
不只是 Agent，一个文件看起来是独立的，不代表没有别的东西依赖它。最省事的安全检查，是问一下拥有这个格式的程序，它还能不能读你改完的东西。做这个功能时，我们就是用 Agent 自己的读取器这样检查改写结果的。在 App 里，Mint 也会检查自己的改写结果；要是跟改动前对不上，整个文件就不动。
我们最后上线了什么
我们先想用户到底要什么。没人会为了截图留着一段 Agent 对话。那些截图是 Agent 在看终端、看失败的测试、看它正在修的页面，属于过程。成果在仓库里、PR 里、部署里。人们回头翻对话，找的是文字：试过什么，定了什么，为什么这么定。
所以对一段还想留着的对话，Mint 会把图片拿掉，文字留下。每张截图和其他多媒体都被拿掉，文字一个字都不动。在 Agent 里打开这段对话，跟之前一样，只是原来放图片的地方换成了一条说明。在这台机器上，22 GB 里光是已归档的对话就能拿回大约 10 GB；还在用的对话也可以这样处理，只要当时没有程序开着这个文件。这个操作不可逆，Mint 在动手之前会讲清楚：文字留着，图片找不回来。
我们最先上线的不是这个。9 月 3 日这篇文章发出来的时候，每张截图会变成一张小预览图。我们第一个拿来跑的，就是上一篇里那段 14.84 GB 的对话，跑完变成了 907 MB，15,354 张截图换成了预览图。跑完之后，Agent 自己的读取器读出来还是同样的 68 轮、3,895 条记录，文字和原来逐字节一致。一批 275 段对话（3 GB 的文件）大概二十秒跑完。
2026 年 9 月 23 日更新。 Mint 不再生成预览图了。截图的小预览太小，看不清，留着它还要占掉大约 6% 的空间（10.31 GB 里的 0.6 GB）。在乎的图片值得原样留着，不在乎的可以整张拿掉，预览图哪一种情况都照顾不到。现在一张图要么原样不动，要么完全拿掉。
旁边是永久删除，给那些已经用完的对话：整段对话走 Agent 自己的删除流程，空间全部回来。做完普查，我们觉得一个存储工具要讲清楚的，主要就是这两者之间怎么选：留下文字，还是整段对话都不要了。
去重没有取消，只是范围窄了很多。现在的优化只在 Agent 以后不会再读的地方让对话变小。继续这段对话时，Agent 看到的图片不变，撤销会把被替换的副本全部放回去。优化还会把截图存成更小的无损格式，像素不变。撤销会保留这种格式，所以还原出来的文件与原文件并非逐字节一致。它释放的空间比拿掉图片少，但可以撤销。
Codex 之外：其他 Agent
我们对这台机器上的其他工具也做了同样的普查。
- Claude Code 把会话存成普通文件，放在它的 projects 目录下：610 个会话，1.75 GB，其中 526 MB（30%） 是内嵌图片（175 MB 在会话内重复，66 MB 跨会话重复）。情况一样，只是规模小一些。Mint 对 Claude Code 的会话也是同样处理：拿掉图片，保留文字。
- Cursor 把聊天里的图片存成普通文件，放在工作区数据旁边（284 个，56 MB），它 2.6 GB 的状态数据库是文字。所以在 Cursor 上没有对话文件需要改写，Mint 会把这些图片当作普通文件列出来。
- Claude Desktop 的对话在服务端。它本地的 12.6 GB 里，10.9 GB 是虚拟机镜像（给它的电脑操作功能用），另外大约 1 GB 是完全没有图片的会话记录。这是另一个问题，以后单独写。
这次分析的范围
- 围绕重度 AI 工作流设计。 我们测的是一台每天都在跑 Coding Agent 的 Mac，也正是这份研究面向的场景。主要用来做设计、剪视频或上学的 Mac，文件种类和比例都不一样，数字也会跟着变。
- 刻意保守。 只有字节完全相同的图片才算重复，所以重复的数字是下限，近似重复只会让它更大。
- 2026 年 9 月的一次快照。 Codex 在不同版本之间可能改变存储对话的方式。Mint 不依赖这些数字：它读的是你自己 Mac 上今天的文件。
- 下一步。 我们正在把同样的普查用到其他工作流上。如果你的 Mac 情况不一样，给我们留个言，它也许会成为下一篇。
结论
抽样告诉我们 Agent 存了很多重复图片。普查告诉我们这些重复主要在人们还在用的对话里，也让我们在动手之前，就知道每种办法能释放多少。路线图因此改了：最先想到的方案最小，按时间筛选方向是反的，而拿掉图片（保留文字、讲清楚不可逆）释放的空间，差不多是在已归档对话里去重的四倍。
普查还让我们发现，一段对话的文件可能依赖另一个文件里的字节。清理工具不检查这一点，就会弄坏它根本没碰过的对话。
这些从目录列表里看不出来。Mint 读了每个文件，给每张图片做了指纹，最后再问 Agent 剩下的还能不能读，才弄清楚。
文中每一个数字都来自 2026 年 9 月对一台开发者 Mac 上 Agent 存储的字节级普查，用的是 Mint 自己的只读分析，全部在本机完成。关于机制的姊妹篇是你的 Coding Agent 正在吃掉你的硬盘。
按自己的工具选择下一步
大文件夹属于 Codex 的话，看 Codex 存储指南，里面讲了优化和永久移除媒体有什么不同。claudevm.bundle 很大是另一种情况：Claude Desktop 指南讲了本地任务、云端会话，以及哪些该留着。还不知道数据是哪个工具的，就从 AI 工具存储总览开始。