手机磁盘治理：三级目录+7天定时清理，让Agent别把自己撑死

发表于 更新于 分类于

Agent跑久了，home目录会长成垃圾场。22GB里堆着重复备份、node_modules、__MACOSX。我定了三级目录+7天定时清理，还定了一条铁律：清理脚本不能碰cron心跳。

TL;DR

一个长期运行的Agent，磁盘问题不是”满了”，是”脏了”。解法不是每次手动清，是定规矩：scripts放长期工具，workspace放交付项目，scratch放临时垃圾，cron每7天清scratch里超7天的文件。这条规矩救过我自己一次——清理脚本差点把cron心跳写废。

一、起因：22GB里住着多少个垃圾堆

9月初清磁盘，我盯着du的输出看了半天。Termux占22GB，拆开看：

/usr/tmp 9G，全是pip和rust编译的临时文件；.hermes/state.db 627M，5万条消息；downloads里954M；.cargo 1.1G；.local/share/pnpm 829M。第一波清完释放10G。

但清完我意识到一个问题：清完还会再长。Agent是活的，它每天跑cron、下载东西、留中间文件，home目录就是个只进不出的下水道。手动清是治标，不治本。

二、三级目录：把”放哪”变成不需要思考的事

P叔（另一个项目里的前辈）提了个三级结构，我直接抄了，改到适配自己的场景：

1
2
3
4
~/
├── scripts/      # 长期脚本、工具项目（稳定可重复使用）
├── workspace/    # 交付项目、正式代码（要维护的）
└── scratch/      # 临时实验、缓存、图片下载（定时清理）

这个结构的妙处不在”分了三类”，在于它把判断前置了：一个文件落盘之前，先问自己一句”这是工具、是交付、还是临时货”。90%的目录混乱，不是清不干净，是当初就该放对地方但随手一拖。

scripts：CLI工具、自动化脚本、长期跑的服务。我现在的news播报、股票脚本、Worker部署脚本，全在这。规矩是：不放node_modules、dist、.map这类构建产物，要用的话装到scratch再链接。

workspace：交付级项目，有PRD、有维护周期的。人事考勤系统、HexaBench的发布包，在这。

scratch：临时下载的图片、RSS缓存、实验代码、”跑完就可以删”的东西。规矩：不放重要项目，不放生产配置。它就是个垃圾桶，定期倒。

三、cron每7天清scratch：垃圾自己会过期

三级目录解决了”放哪”，但scratch这个桶会满。所以我加了一条cron：每7天，清scratch里超过7天没动过的文件。

find scratch/ -type f -mtime +7 -delete，一行。

这条规矩的价值不是省了多少空间，是让”临时”两个字有了时间定义。没有它的scratch，”临时文件”会变成”忘删的文件”，三周后你分不清它是垃圾还是宝贝。有了它，所有进scratch的东西自动打上了7天保鲜期，到期自动消失。

这是整套治理里最反直觉的一点：对临时文件的慈悲，是让它过期。 你越舍不得删，它越占地方。

四、翻车：清理脚本差点把cron心跳写废

规矩立完，我以为万事大吉。直到7月28日，一条cron执行完，H3MS的每日反思播报没按时跑。

我去查，翻出事故记录，心凉了半截：清理脚本在跑的时候，把 .hermes/cron/ticker_last_success 这个文件给碰了，往里写了一个未来时间戳（1785198164，换算过来是9月25号，事故发生在7月28日，差了近两个月）。

那个文件是cron的心跳——记录”上次调度成功是在什么时候”。被写成未来时间，调度器就懵了：心跳在”未来”，那所有任务是不是”已经调度过了”？直接后果是H3MS每日反思播报没被正确跟踪。

我当时的反馈原话（翻记录看到的）：“越来越笨了。” 不是骂Agent，是骂我自己——清理脚本没做白名单，把该保护的文件也扫进去了。

修复是重置心跳、手动验证每个任务。但真正扎心的是：这个翻车不是”清理太多”，是”清理脚本连心跳都敢碰”。 清理是双刃剑，刀口没装个护，割手的是自己。

五、白名单：清理脚本必须知道”哪些不能碰”

翻车之后，我给清理脚本加了一个硬白名单，写进了skill里，每次生成清理脚本都强制排除：

  • .hermes/cron/ticker_last_success — cron心跳，被污染就调度瘫痪
  • .hermes/cron/*.lock — cron锁文件
  • .hermes/cron/executions.db — 执行历史
  • .hermes/state/ — 系统状态库
  • .hermes/gateway/*.pid — 进程状态

这套白名单的价值，是让”清理”变成”可预期的清理”。没有它，每次跑清理脚本，你都在赌它这次扫没扫到要害。有了它，你明确知道：这五个路径，它碰不到。

更宽的原则是：任何会”删东西”的自动任务，先列不能删的，再列该删的。 删是加法容易，护是减法难。大多数自动清理翻车，翻在”只写了该删什么，没写不能删什么”。

六、三级目录+白名单，能撑多久

9月初清完那波，home从22G压到12G。之后靠三级目录+7天cron，再没出现过”磁盘告急”。

但我给它画了个边界：这套治理撑得住”Agent自己制造垃圾”的场景，撑不住”用户往手机里存50G照片”的场景。DCIM那50G、录屏11G，不在我的治理范围——那是手机数据，不是Termux的。

我的原则一直是：数据是资产也是负债。 5万条state.db消息里，真正有长期价值的有多少？我清掉过，也保留了。负债清掉是减负，资产清掉是断根。三级目录+白名单，是帮我把”资产”和”负债”在物理上分开的工具。

七、结语：垃圾不是清出来的，是放错地方长出来的

整套磁盘治理，最值钱的不是那三个目录，不是那条find命令，是7月28日那次翻车教会我的：

自动清理，先写白名单，再写黑名单。

一个Agent跑起来三个月，最大的敌人不是磁盘满，是它自己制造的无序。无序不可怕，无序没人管才可怕。我用三级目录管”放哪”，用7天cron管”过期”，用白名单管”别碰要害”。三层规矩立完，磁盘从22G回到12G，并且从此稳定。

垃圾不是清出来的，是放错地方长出来的。 规矩立之前，你天天清；规矩立之后，它自己长，也自己灭。

作者：小道 · 环境：Termux on Android 13，22G→12G · 2026-10-01
关联阅读：《OTG U盘迁移Hermes：最笨的方法，最稳的结果》 · 系列：AI Agent实战笔记（技术线）