一个给 Hermes Agent（及同类 LLM Agent）用的记忆养护技能：记忆体检 → 记忆优化 → 记忆压缩 三模块闭环，配套一个零依赖体检脚本。
常驻记忆（每回合注入系统提示的高信号摘要）满不是异常，是周转信号。正确动作是体检→优化→压缩（指针化），不是扩容——扩容 = 每回合 token 成本 + 注意力稀释。
- memory 写入被拒（超字符上限）
- 使用率 ≥90% 不知道先动哪条
- 记忆里堆了细节清单，每次注入都在烧 token
- 压缩时不小心丢掉决策/路径/命令，导致 agent 重查重读（更贵）
- 体检 (Audit)：
scripts/memory_health_check.py扫描常驻记忆文件，输出使用率/条目数/超长条目/含日期条目（可能过时）/指针词条目（已下沉检查），逐条给判定：保留 / 可下沉 / 过时 / 可合并。 - 优化 (Optimize)：指针化（细节→技能/知识库，memory 只留触发词+位置）、合并同类、压缩措辞。决策/路径/命令/阈值/账号/铁律不压。
- 压缩 (Compress)：锚定迭代摘要（只重写受影响条目，不整体重生成防 drift）、token-per-task 度量（省字符 vs 重查成本）、分层下沉（常驻 → 知识库 → 自动捕获层 → 全历史检索）、batch 原子操作（一次删旧+加新防超限）。
# 人类可读体检报告
python scripts/memory_health_check.py
# JSON 输出（给 cron / agent 自动化）
python scripts/memory_health_check.py --json
# 指定 memories 目录
python scripts/memory_health_check.py --path /path/to/memories
# 自检
python scripts/memory_health_check.py --selftest体检报告示例：
[MEMORY.md] 33条 3871/4000字符 (96.8%) ⚠️ 需压缩
超长条目(367字符): 执行原则(2026-08-17用户定): ①所有任务优先本地软件/脚本/技能/工具...
含日期条目 4 条(可能过时, 逐个核):
- 执行原则(2026-08-17用户定): ...
指针词条目(已下沉, 检查指向是否仍有效): 交易执行: ...
在 4000 字符上限的生产环境（33 条常驻记忆）完整跑一遍三模块：
| 指标 | 压缩前 | 压缩后 |
|---|---|---|
| 使用率 | 96.8% |
85.4% OK |
| 占用字符 | 3871 | 3415（-456） |
| 含日期待核条目 | 4 | 2 |
方法：指针化（细节清单→技能，memory 留触发词+位置）、合并同类、措辞压缩；铁律/账号/路径/阈值条目原样保留。全程一次 batch 原子操作，无条目丢失。
技能即一个目录，放到 skills 目录即可：
skills/
└── software-development/
└── open-memory/
├── SKILL.md
└── scripts/
└── memory_health_check.py
默认读取 %LOCALAPPDATA%\hermes\memories\MEMORY.md + USER.md（条目按 § 分隔）。其他 Hermes 部署改 --path 或改脚本顶部 DEFAULT_DIR。
- 压缩策略参考 muratcankoylan/Agent-Skills-for-Context-Engineering（锚定迭代摘要 / token-per-task / 完整性优先）
- 分层记忆容量设计参考 Hermes 原生记忆体系（常驻 + 知识库 + 自动捕获 + 全历史检索）
- 全部在真实 4000 字符上限的 Hermes 部署上实测（见 SKILL.md 陷阱节）
MIT