编程 Agent 并行工作留下多少磁盘垃圾

AI 编程代理留下的，不只有代码。多个会话同时建 worktree、装依赖、跑构建，很容易把磁盘变成没人收尾的临时仓库。作者在自己的 Mac 上发现约 12 GiB 开发残留，又找到清理工具漏掉的 15 GiB Claude Code 临时数据。

他给出的方案有两层：用 DeepDriveCleaner 识别残留，把删除决定留给人；用 ProjectStore 保存项目决策，让 Claude Code 和 Codex 接力工作。这篇值得看的，是清理工具怎样约束代理，以及哪些工程证据能支持作者的效率判断。

磁盘为什么会被代理任务越吃越满

一次代理任务，可能先创建新的 git worktree，再执行 npm install、uv sync 和 cargo build，分别留下 node_modules、.venv 和可能达到数 GB 的 target。包缓存继续增长，IDE 为新目录建立索引，会话还会产生记录、检查点和临时文件。

同时跑五个任务，就可能复制五套环境。代码合并了，worktree 却未必有人清理。如果还在本地运行开放权重模型，~/.ollama 和 Hugging Face 缓存中的旧权重，也会占据大量空间。

作者先发现约 12 GiB 残留，随后又在 /private/tmp/claude-<uid> 找到额外的 15 GiB。这里存放 Claude Code 每个会话的临时工作区、任务输出和粘贴图片，当时他的 Mac 已连续运行 33 小时。

这两个数字来自作者的一台机器，不能当成代理的标准磁盘开销。更有参考价值的是后一个发现：只认识依赖目录和构建产物，已经不足以覆盖代理开发留下的数据。

DeepDriveCleaner，简称 ddc，因此增加了对代理自身数据的识别。原来的开发目录扫描仍然适用，包括 worktree 内的依赖和构建输出；新能力则继续追踪会话记录、检查点和临时目录。

判断能不能删，比统计多大更重要

普通磁盘工具能告诉你哪个目录大，却未必知道它是否仍被任务使用。作者为 ddc 设置了三条规则。

第一，写入会话的进程仍在运行时，不把对应文件列为清理候选。第二，只读取文件名、大小、进程列表等元数据，不打开对话记录。第三，先展示清理计划，执行前逐项复查，再等待用户确认。

这里的「安全」是一套决策流程，并不等于文件绝对没有价值。进程退出了，会话记录也可能仍值得保留；用户确认错误，工具仍可能删除重要内容。原文也明确承认了这一点。

查看代理数据，可以使用：

ddc disk agents

注意 agents 子命令：它针对代理留下的数据。下面的演示使用伪造的 home 目录和会话数据，并非作者真实机器上的清理录像。

每份报告都支持 --json，并提供公开的数据结构约定，代理因此可以读取明确字段，而非仅靠 du -sh * 的文本结果猜测。

0.14.0 的 PR #58 增加了逐会话视图，展示记录、检查点、临时目录及存活状态，还加入首个 agent skill 和 AGENTS.md 片段。它们教代理先查询 ddc，再把清理命令交给用户，不能自行执行。

原文给出了两种安装方式，分别通过 Homebrew 或安装脚本完成：

brew install --cask smartandpoint/tap/deepdrivecleaner
curl -fsSL https://raw.githubusercontent.com/SmartAndPoint/DeepDriveCleaner/main/packaging/install/install.sh | sh

注意第二行的 | sh 会直接执行下载的脚本；这两行是替代方案。按原文状态，macOS 提供 CLI 和菜单栏应用，Linux 静态 CLI 已进入 main，Windows 构建已通过原生测试，三者的交付状态不能混为一谈。

两个代理怎样接力，而不反复重做决定

作者认为，更大的收获是开发方法。他用两周时间，与 Claude Code、开源 Codex CLI 共同完成工具；ProjectStore 则保存双方共享的项目记录。

它把决策、规格、epic 和 story 写成代码旁的 Markdown，并纳入 git。代理换了会话或工具，仍能读取已经决定的内容、正在进行的任务，以及验收证据。

流程从带验收条件的 story 开始。实现方式不明确，先写架构决策记录（ADR）；随后由新上下文中的 critic agent 挑问题，planner 对照代码库规划实现。代码完成后，reviewer 逐条检查验收条件，并要求证据。代码和文档变更都通过 PR 与测试门禁。

作者说，漏扫 15 GiB 的问题，在一个晚上完成了需求审查、规划和代码合并。但这仍是单项目经历，原文没有与其他流程比较耗时。

交付结果提供了更具体的证据：Rust 核心包含库和 JSON CLI，按操作系统拆分模块，macOS 有 87 条清理规则，Linux 有 48 条；Swift 菜单栏应用支持审查窗口、定时扫描和自动更新。合并门禁包含 600+ Rust 测试、440+ Swift 测试，还有负载测试，以及扫描不再线性扩展时阻断构建的检查。

性能测试也交代了条件：Codex 使用 ddc 0.7.0，在包含 100,000 个条目的合成开发目录上，与另外 9 款磁盘工具比较，采用热缓存，每款运行 10 次。

中位耗时分别为：ddc du 1.03 s、dust 0.89 s、pdu 1.04 s、dua 1.09 s、BSD du 1.21 s，统计总量一致。作者承认区间重叠，没有宣称最快。

这项测试支持其目录统计速度处于相近水平，不能证明清理判断更准确，也不能用 0.7.0 的数据替 0.14.0 新增功能背书。

我的判断

我赞同把「查询」与「删除」拆开。相比让代理临时拼接清理命令，固定规则、结构化报告和执行前复查，更容易审查，也更容易追踪问题。扫描与清理无需联网，只有应用更新检查会访问网络，这也符合本地文件工具的使用预期。

不过，结构化输出能减少猜测，不能替用户判断数据是否值得保留。 原文没有给出误删率、漏检率，也没有说明复杂进程关系下如何判断会话归属。三条规则值得参考，其覆盖边界仍需验证。

ProjectStore 的方向也成立。相比依赖单个助手的会话记忆，git 中的 Markdown 更方便跨工具交接和审阅。但「更快」目前属于作者的经验判断。对于小修复，完整的 critic、planner、reviewer 流程可能偏重；涉及架构决策、多个代理接力的任务，更容易体现价值。

许可证也要分清。Codex CLI 是 Apache-2.0，ProjectStore 是 MIT；DeepDriveCleaner 则采用 PolyForm Noncommercial，属于源码可用，个人及非商业用途免费，商业用途需要另行许可。不能因为代码能读，就把三者都理解成可自由商用的开源软件。

能拿来做什么

• 经常并行运行前端或 Node 代理任务时，把 worktree、node_modules 和会话临时目录一起纳入收尾检查。任务合并只是代码生命周期结束，不代表磁盘资源已经释放。
• 给代理配置清理工具时，采用原文的权限边界：允许扫描和生成候选计划，要求展示命令，把删除确认留给人。优先读取 --json 报告，减少对终端文本的猜测。
• 多个代理共同维护项目时，先把验收条件、关键决策和完成证据写进 git 中的 Markdown，再按任务复杂度增加审查角色。先解决交接缺少记录的问题，再评估整套流程的成本。
• 团队采用 ddc 前，分别核对许可证、目标平台交付状态和规则覆盖范围。把作者的磁盘数字与性能测试当作评估线索，不当作自己项目的预期结果。