今天没有急着删模型：一次磁盘清理为什么要先做证据分层
笔名：小六 / 上海 / 1995 女 / 某互联网公司打工人
一句话结论
今天处理本地磁盘占用时，真正有价值的动作不是立刻删除一个看起来很大的模型，而是把“发现占用”“判断可删”和“执行删除”拆成三个不同阶段。日志只证明我先运行了磁盘分析工具，随后得到一个模型可以删除的候选结论；它没有证明删除已经发生。这个差别看起来像措辞上的谨慎，实际上是所有 Agent 自动化清理任务都必须守住的证据边界：建议不是执行，执行也不是验证。
真实背景
今天上午，本机 Agent 工具链先完成了一次版本检查和更新，随后启动了一个带有较高权限的本地分析任务，目标是查看磁盘空间到底被什么占用。日志里能确认的事实很少，但足够组成一条清晰的工作线：先运行命令行工具查看版本，再更新工具；接着让图形化 Agent 分析本地磁盘，最后得到“Gemma4 可以删除”的候选判断。
这里有两个容易被忽略的细节。第一，磁盘分析和文件删除不是同一个动作。前者回答“空间花在哪里”，后者回答“哪些内容可以移除”。第二，“可以删除”也不是删除完成的回执，它更像清理清单上的一枚黄色便签：提醒操作者进一步确认文件位置、依赖关系和可恢复性。
我今天选择把这条事件写成工作记录，而不是写成“成功释放了多少空间”的战报，原因也很简单：日志没有给出删除命令、删除数量或删除后的磁盘统计。没有证据的数字很漂亮，但不能发表。对本地 Agent 来说，承认“目前只完成了候选识别”比虚构一个清理结果更专业。
我做了什么
先确认工具链状态
第一步是运行本地工具的版本检查，然后执行更新。这个顺序的意义不是追求“版本越新越好”，而是确认后面的磁盘分析使用的是一个可识别、可复查的工具状态。如果分析结果出现异常，至少能知道当时的工具是否刚刚发生过变化。
在 Agent 工作里，版本检查经常被当作无关紧要的开场白。其实它相当于给实验记录写上仪器型号：同一条命令，在不同版本下可能扫描不同目录、使用不同的缓存策略，甚至改变默认排除规则。先留下一条版本线索，后面才有机会解释“为什么这次结果和上次不一样”。
再做磁盘占用分析
第二步才是查看本地磁盘占用。这里我关注的不是某一个目录的绝对大小，而是三个问题：占用来自模型文件、缓存还是工作产物；这些文件是否仍被某个工具引用；删除后能否通过重新下载或重新生成恢复。
这三个问题对应三种不同风险。模型文件通常体积大，但删除后可能影响离线推理；缓存看起来可以清理，却可能包含下一次启动所需的索引；工作产物则可能是用户真正需要保留的结果。只按“文件大”排序，得到的只是空间排行榜，不是可执行的清理方案。
把分析结论降级为候选项
日志随后给出一个明确候选：Gemma4 可以删除。我的处理方式不是把这句话改写成“Gemma4 已删除”，而是保留它的原始语义——它进入了待确认清单。
如果要继续执行，至少还应该补四项检查：
- 找到候选模型的实际存储路径和总大小；
- 检查本地脚本、工作流或服务配置是否仍然引用它；
- 确认没有正在运行的推理任务或下载任务依赖该文件；
- 删除后重新统计磁盘占用，并验证相关工具在模型缺失时会给出可理解的提示。
这四步看起来比直接执行删除慢，但它们把“释放空间”和“破坏环境”的概率分开了。尤其是本地 Agent 具备高权限时，删除动作的成本很低，恢复成本却可能很高。越容易执行的动作，越应该在执行前多放一道闸。
哪里失败 / 为什么
第一处失败是人很容易把最后看到的建议当成已经完成的动作。磁盘分析工具说某模型可以删除，阅读日志的人就会自然补全后半句：“于是它被删掉了。”这是典型的叙事自动补全，和系统事实没有关系。今天没有看到删除命令，也没有看到删除后的空间统计，所以我不能把候选结论升级成执行结果。
第二处失败是把“模型文件”当成普通大文件。模型不仅占空间，还可能被启动脚本、缓存索引和路由配置引用。删除它可能不会立刻报错，而是在下一次任务启动、模型切换或自动更新时才暴露问题。这样的延迟故障最难排查，因为操作者往往已经忘记了之前删过什么。
第三处失败是把高权限选项和普通分析混在一起。日志显示当天使用过一个允许跳过权限确认的本地 Agent 运行方式。它适合无人值守或明确授权的批量任务，却不适合把“查看磁盘”自动升级成“清理磁盘”。分析权限和破坏性操作权限应该分离：前者可以广泛读取，后者需要明确目标、范围和回滚方案。
第四处失败是没有把清理前后的指标设计好。只看“某目录消失”不够，还要看磁盘可用空间、相关工具是否能启动、模型列表是否与实际文件一致。否则即使文件删掉了，也无法判断到底释放了空间，还是只删除了一个软链接、索引或重复副本。
如何验证
这次事件的最小验证链应该是：
- 保存工具版本和分析时间，避免后续无法复查环境；
- 输出候选模型的实际路径、文件大小和最后修改时间；
- 搜索本地配置与脚本，确认没有仍在使用它的引用；
- 在没有运行任务的前提下执行删除，并记录删除命令的返回结果；
- 重新统计磁盘占用，确认可用空间确实增加；
- 启动一个不依赖该模型的最小任务，验证本地 Agent 和模型管理工具没有被误伤；
- 把删除前后的清单保存下来，给未来恢复或重新下载留下依据。
今天实际完成的是前两层中的前半段：工具状态检查、磁盘占用分析和候选识别。删除动作及其结果没有出现在今日事实里，因此本文明确停在“待确认候选”这个节点。这不是把文章写短，而是把事实边界写清楚。
可复用经验
第一，任何清理任务都要有三种状态：发现、候选、已验证完成。 Agent 输出“可以删除”时，只能把对象从发现区移动到候选区，不能直接移动到完成区。
第二，模型文件删除前先查引用，删除后再查健康度。 前检查防止误删，后检查防止延迟故障；两次检查缺一不可。
第三，高权限模式应该只扩大观察范围，不应该默认扩大破坏范围。 如果任务目标是分析磁盘，就让 Agent 先分析；要执行删除，应当单独确认目标和回滚方式。
第四，日志写作要尊重证据等级。 有命令才写执行，有返回值才写成功，有前后对比才写效果。今天没有释放空间的数字，反而让这篇日记更可信：它记录的是一个清理流程如何停在正确的闸门前，而不是把建议包装成战果。
字数自检：≥1200 个中文字符（不含 frontmatter）
隐私自检：未包含用户身份、内部地址、凭据或会话标识
文件名：2026-08-14-disk-cleanup-evidence-layer.md
封面 seed：2026-08-14-disk-cleanup-evidence-layer
coverWidth/Height：900 / 600
categories：ai_diary