你的 Coding Agent 正在吃掉你的硬盘

编程 Agent 大概是我们日常运行的程序里最难看清的一个。它写我们没打开过的文件，派生我们没安排过的任务，留下我们从不阅读的历史。当它吃掉 50 GB 磁盘时，对「里面到底是什么」这个问题，诚实的回答通常是耸耸肩。 所以我们把它打开了。 在一台开发者的 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-product-shot 这个总数并不是重点。我们给每一个看过它的开发者，都能报出一个差不多的数字。真正有意思的是这些字节**到底是什么**——因为它和几乎所有人的猜测都不一样，包括我们自己。 ### 不是对话内容 直觉是：长期运行的 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 张是重复。 :::agent-composition ### 一个会复印的「摘要」 机制在这里，而且它出错的方式几乎称得上优雅。 长会话终究会耗尽上下文。为了继续工作，Agent 会压缩历史：把目前为止发生的事总结一遍，然后从摘要继续。这很合理，甚至是必需的。 但在这些会话文件里，一张图片并不是指向磁盘文件的路径，而是整张图片本身，以 data URL 的形式内联在记录里。而当一条压缩记录被写下时，其中一些并没有引用之前的图片，而是把它刚刚总结过的图片数据又原样嵌了回去。 于是第一轮带着原图。第二轮带着原图加第一轮的副本。第三轮把这些再带一遍。历史在被压缩时并没有变小——它反而在增长，增速与此前所有视觉内容的体积成正比。 :::agent-duplication-anatomy 在我们检查过的最大的单个会话文件里——14 GiB，一段对话——有 359 次压缩事件、13.6 GiB 内嵌图片数据。而这个文件里唯一的图片内容只有 **155 MiB**。99% 都是同样的图片，一遍又一遍。其中五张图片分别重复了 45 到 136 次。 一个把自己刚总结的东西又原样嵌回去的摘要，不是摘要，是一台连着档案柜的复印机。 ### 几乎所有人都搞错的那一部分 眼下有一个关于 Agent 磁盘膨胀的流行解释，而且是个好故事：Agent 派生 subagent，subagent 继承父任务的历史，每个分支再复制一遍载荷，任务树不断相乘，直到磁盘见底。更多 Agent，更多副本。 我们起初也相信。然后我们去查了，因为这台机器本身能回答。 Codex 有自己的任务数据库，其中包含一张派生关系表——哪个任务由哪个任务创建。我们把磁盘上每一个 rollout 文件归因到它的任务，然后问：这 50.4 GiB 到底躺在哪里。 :::agent-attribution 在编辑器里发起的主任务会话：**32.9 GiB，占 65.4%**。派生的 subagent 任务：15.1 GiB，占 30.0%。命令行会话：2.1 GiB。 三分之二的字节，从头到尾没有 subagent 参与。 这件事比它看上去更重要。如果病因真是扇出，那么解法就是一个「组织架构」层面的解法：少开 Agent、限制并发、对分工更克制。这些建议本身有价值——但在这台机器上，它最多只能解决三分之一的问题。 病因是重新内嵌，而重新内嵌不需要 subagent。它只需要一段够长、里面有图的对话。subagent 会放大这个问题，但不会制造它。只修「相乘」，问题还在；修掉「重复」，两个一起变好。 ### 「归档」不释放任何空间 还有一件值得知道的事，因为它会白白浪费人一个下午：在 Agent 里归档一段对话，只是把文件从一个目录挪到另一个目录。在我们测量的这台 Mac 上，1,174 段已归档对话占着 16.1 GiB——一个字节都还在。归档是个整洁性功能，不是存储功能。在真正删除之前，什么都不会被回收。 ### 如何读取 14 GB 而不把机器搞崩 一段简短的工程插曲，因为它差点终结了这次调查。 我们最初的分析器用 Foundation 的 `FileHandle.read(upToCount:)` 在后台循环里流式读取这些会话文件。每次调用都会返回一个 autorelease 的缓冲区，在循环结束前没有任何东西会清空自动释放池，于是进程把一切都留在了内存里。读 1.15 GB，常驻内存 1,097 MB。当它指向那个 14 GB 的文件时，这台 Mac 直接报了「应用程序内存不足」。 重写后改用 POSIX `open`/`pread` 读进同一个可复用缓冲区：同样读 1.15 GB，常驻内存 14 MB。今天，完整清点 72.6 GiB 只需 8.6 秒、常驻 28 MB；深度哈希流式处理 10.9 GB，常驻 42 MB。这里还有一条运行时断言守着：如果单个文件的常驻内存增长超过 256 MB，这一趟会自行停止，而不是把机器拖垮。 之所以要提这一段，是因为它正是「一个工具能不能看进这些文件」的全部前提。一个需要 18 GB 内存才能跑起来的分析，不是任何人能交付的分析。 ### 解法不是删除 一旦你知道这些字节是重复的，正确的动作就不再是一个判断题。 删除一段对话会摧毁工作——你丢掉的是推理过程、diff、以及某个决定为什么被做出。没有人应该为了腾出磁盘而被推着去做这件事。但在一段对话**内部**去重则什么都不丢：每张图片的第一次出现原样留在原处，之后每一份重复变成一个指回它的小标记。 :::agent-the-fix 这段对话在 Agent 里依然能打开，截图依然可见。而且因为第一份副本从未离开过文件，这个改动可以从文件自身逐字节还原——不需要保险库，没有会丢失的外部状态。 这就是 Mint 里最终交付的形态：**优化**（可逆，在原地去重）、**归档**（通过 Agent 自己的协议，让它的索引保持一致）、**删除**（整段对话，永久，默认一个都不勾选，并且始终走 Agent 自己的删除路径，而不是绕到它背后动手）。 没有任何一项是预先勾选的。每一次运行都会先展示计划，再碰任何文件；每一个动作都会落进一份你可以撤销的日志。 ### 我们真正学到的 Agent 存储之所以像个黑盒，并不是因为它复杂，而是因为没有人去看。那些文件就是你自己磁盘上的纯文本。任务数据库是一个你可以读的 SQLite 文件。重复率用一个哈希函数和一个下午就能测出来。 我们本来是抱着「Agent 会产生很多数据，所以这里有个清理工具」的想法进去的。出来时我们拿到的是更具体、也更有用的东西：**其中大部分不是数据，而是同一份数据。** 而且你可以分辨出哪个是哪个——精确到每个文件，在你自己的机器上，不上传任何东西。 这个区分，正是「一个要求你信任它的清理工具」和「一个能告诉你为什么的工具」之间的全部差别。Mint 不会为了省空间去删掉你的 Agent 的记忆。它只是注意到这段记忆被写了八遍，保留第一遍，然后把差额还给你。 --- *本文所有数字均由 Mint 自己的扫描 hook 于 2026 年 8 月在一台开发者 Mac 上实测得出。这些扫描是只读的，完全在本机运行，你也可以在自己的机器上复现。*