你的 AI 助手在偷偷吃磁盘：一套通用的系统瘦身方法论

一、问题：AI 助手跑久了，垃圾从哪来？

如果你在本地部署了 AI Agent（不管是 Hermes、LangChain 还是自己搭的），几周后你会发现： - 磁盘占用悄悄涨了几百 MB - 助手"记性"变差了——回答越来越啰嗦 - 技能库里一堆不认识的东西，不敢删 这不是你的问题，是 AI 助手的工作方式决定的： | 垃圾来源 | 怎么产生的 | 典型大小 | |----------|-----------|---------| | Session 快照 | 每次对话自动保存一份完整记录 | 几十到几百 MB | | 调试残留 | 报错时保存的请求/响应 dump | 几十 MB | | 碎片记忆 | 每次学到一个新东西就追加一条，同一件事记了五六遍 | 几 KB 但影响检索质量 | | 死技能 | 试过一次就再也没用过的插件 | 几 MB 到几十 MB | | 旧配置备份 | 每次改配置前的自动备份 | 几十 KB | 放任不管的后果： 1. 磁盘被占满（尤其是跑在 Jetson/树莓派等小容量设备上） 2. 向量记忆库混入大量过时信息，召回质量下降 3. 本地 Memory 膨胀到上限，新知识存不进去 本文提供一套通用的五层审计框架，你可以直接套用到自己的系统上。

二、五层审计框架

把 AI 助手系统从外到内分为五层，逐层扫描：

第 1 层  文件系统    →  磁盘文件（日志、缓存、临时文件、工作区）
第 2 层  配置与备份  →  数据库快照、配置备份、废弃 profile
第 3 层  技能/插件   →  不再使用的 skills、plugins
第 4 层  本地记忆    →  注入 prompt 的系统级 Memory
第 5 层  向量记忆    →  长期向量数据库（如 Hindsight/Mem0）

核心原则：每层先扫描 → 分类 → 逐类确认，不自作主张全删。尤其是第 5 层，删错比不删更糟糕。

三、第 1 层：文件系统

3.1 先摸清家底

# 找出最大的 20 个文件/目录
du -sh /path/to/your/agent/* | sort -rh | head -20
# 找出超过 30 天未修改的文件（可能是遗留）
find /path/to/your/agent -type f -mtime +30 -ls | head -30
# 看看日志目录
du -sh /path/to/your/agent/logs/*
ls -lht /path/to/your/agent/logs/ | head -10

3.2 可以安全删除的

workspace/
├── 研究方向/          # 调研报告、市场分析
│   └── 2025-06-04/
├── 公文报告/           # 给领导/客户的正式汇报
│   └── 2025-06-03/
├── 技术方案/           # 部署方案、架构设计
│   └── 2025-06-01/
└── 已发表文章/         # 公众号/博客文章
    └── 2025-05/

规则：四分类 + 日期子目录 + 中文文件名。不够再扩展。

⚠️ 注意事项 - 删除前用 du -sh 确认大小，防止误删大文件 - 数据库文件（*.db、*.sqlite）除非明确知道是废弃的，否则不要动 - 文件名带 corrupted 或旧日期后缀的，当前系统正常 → 可删

四、第 2 层：配置与备份清理

4.1 数据库快照

如果系统自动保存了数据库快照（如 state.db.bak、state.db.corrupted.*），检查当前数据库是否正常：

# 确认当前数据库健康（以 SQLite 为例）
sqlite3 /path/to/state.db "PRAGMA integrity_check;"
# 预期输出: ok
# 健康 → 旧备份可以删除
rm /path/to/state.db.bak
rm /path/to/state.db.corrupted.*

4.2 废弃的 Profile/环境

如果系统支持多 profile（如 Hermes），检查哪些还在用：

# 查看每个 profile 的最近活跃时间
ls -lt /path/to/profiles/*/logs/agent.log | head -5

超过两周没有日志更新的 profile，确认无人使用后可以整删。

4.3 Curator/包管理快照

如果系统有自动备份机制，检查备份目录。建议只保留最近 1-2 次快照，更早的删除。

⚠️ 注意事项 - 删 profile 前确认没有定时任务还在引用它的脚本 - 删配置备份前确认当前配置能正常工作 - 如果在"事故恢复期"，先不要删任何备份

五、第 3 层：技能/插件库清理

5.1 找到使用记录

大多数 AI Agent 框架会记录技能/插件的使用统计。以 Hermes 为例，每个技能目录下有 .usage.json：

# 查看所有技能的使用次数
cat .usage.json | python3 -c "
import json, sys
d = json.load(sys.stdin)
for k, v in sorted(d.items(), key=lambda x: x[1].get('use_count', 0)):
    print(f\"{v.get('use_count', 0):4} 次 | {k}\")
"

5.2 判断标准

# 找出空壳分类
for dir in /path/to/skills/*/; do
  count=$(find "$dir" -name "SKILL.md" | wc -l)
  if [ "$count" -eq 0 ]; then
    echo "空壳: $dir"
  fi
done

整类删除即可。

⚠️ 注意事项 - 跨 profile 同步：如果系统有多个 profile，删一个技能时必须在所有 profile 中同步删除 - 不要因为"可能以后有用"而保留——你可以从备份中恢复 - 已被其他技能引用的不要删（检查 imports/external references）

六、第 4 层：本地记忆合并

6.1 怎么判断记忆碎片化了

本地 Memory（注入 prompt 的系统级记忆，通常有字符上限）容易碎片化——每次遇到新情况追加一条，同一件事记录了多次。 判断标准： - 同一话题出现了 3 条以上 - 条目里出现"v2"、"v3"、"强化"、"修正"等版本迭代标记 - 条目里出现"踩坑"、"过程"等过程描述（结论不需要过程）

6.2 合并策略

步骤 1：列出所有条目，按主题分类
步骤 2：删除已在系统配置文件中覆盖的重复项
步骤 3：同类碎片合并为一条"铁律"
步骤 4：只保留最终结论，删掉版本号和踩坑过程
步骤 5：验证合并后的总字符数是否在限制以内

合并前（6 条碎片）： - 文档格式 v1（踩坑总结） - 文档格式 v2（多轮修正） - 文档格式 v3（精简版） - 文档格式 v4（强化版） - 汇报风格（用户反馈） - 服务推荐偏好 合并后（1 条铁律）： - 文档生成铁律：含格式、水印、表格、标点、推荐偏好等 6 条核心规则

6.3 什么时候不该合并

还在进行中的事项不要合并。比如某台机器的部署还没完成，相关的多条记录留着——等事情搞定再统一整理。

⚠️ 注意事项 - Memory 通常有 10KB 上限，保持使用率在 80% 以下 - 结论型信息放 Memory，过程型信息放向量数据库 - 不要在 Memory 里存"踩坑过程"——那是向量数据库的活

七、第 5 层：向量记忆清理（最关键的一步）

7.1 先理解两种记忆的分工

这是整个瘦身中最容易犯错的一层。必须理解一个核心原则：

"覆盖 ≠ 重复" —— 本地 Memory 记了结论，不代表向量记忆里的过程就多余了。 | 存储位置 | 记什么 | 举例 | |----------|--------|------| | 本地 Memory | 结论、规则、配置 | "Hindsight 端口是 8888" | | 向量记忆 | 过程、上下文、排障路径 | "当时端口不通，排查发现是 uvicorn 协程在长时间运行后异常退出，重建容器后自愈" | 下次遇到类似问题，向量记忆里的排障路径比 Memory 里的结论有用得多。

7.2 可以删的

拉出所有文档列表（以 Hindsight API 为例）：

# 列出所有文档
curl http://your-hindsight:8888/v1/default/banks/your-bank/documents?limit=100

标记以下类型： | 类型 | 特征 | 原因 | |------|------|------| | 空内容文档 | text_length ≈ 0 或无 chunks | 占位符，零价值 | | 一次性补丁记录 | 标题含"修复"、"配置修正"、且修复已永久生效 | 不会再遇到 | | 碎片化更新日志 | 同一技能多次"更新"，内容已被最新版覆盖 | 重复信息 | | 已入 skill 的技术细节 | 标题如"PDF水印方案"、"表格规范" | skill 已有正式版本 |

7.3 不能删的

# 1. 先拉取文档内容确认
curl http://your-hindsight:8888/v1/default/banks/your-bank/documents/{doc_id}/chunks
# 2. 确认无价值后再删除
curl -X DELETE http://your-hindsight:8888/v1/default/banks/your-bank/documents/{doc_id}

批量删除建议：每批 5-10 个文档，避免 API 超时。

⚠️ 注意事项 - 绝对不要在没查看内容的情况下删文档——有些文档标题看起来是碎片日志，实际包含了重要的排障过程 - 删除前确认没有正在运行的 consolidation 任务 - 不要删除标记为 session:* 的完整会话转储——这些是自动保留的，含全量上下文 - 如果不确定，保留。向量数据库的存储成本远低于误删的代价

八、自动化建议

手动审计一次约 2 小时。建议建立定期巡检机制： | 频率 | 任务 | 工具 | |------|------|------| | 每周 | 扫描日志和缓存目录大小 | du -sh + cron | | 每月 | 标记 use_count=0 超过两周的技能 | 读取 .usage.json | | 每月 | Memory 使用率检查（超过 85% 告警） | Python 脚本 | | 每季 | 全量审计（五层扫描） | 本文框架 |

参考脚本：磁盘健康检查

#!/bin/bash
# 保存为 disk_health_check.sh，cron 每周跑一次
AGENT_DIR="/path/to/your/agent"
THRESHOLD_MB=500
# 检查工作区大小
WS_SIZE=$(du -sm "$AGENT_DIR/workspace" 2>/dev/null | cut -f1)
if [ "$WS_SIZE" -gt "$THRESHOLD_MB" ]; then
    echo "⚠️ Workspace 超过 ${THRESHOLD_MB}MB，当前 ${WS_SIZE}MB"
fi
# 检查日志目录
LOG_SIZE=$(du -sm "$AGENT_DIR/logs" 2>/dev/null | cut -f1)
echo "📊 Logs: ${LOG_SIZE}MB | Sessions: $(du -sm $AGENT_DIR/sessions 2>/dev/null | cut -f1)MB"

九、常见踩坑清单

本文由 admin 原创，转载请注明出处。