1. MEMORY.md 和 USER.md 不是“存档”，而是 Hermes Agent 的长期记忆调度中心大多数人第一次看到MEMORY.md和USER.md，下意识会把它当成一个“AI 的笔记本”——写进去就记住，改了就更新，删了就遗忘。我最初也这么想，直到在三个不同规模的项目里反复踩坑：一次是客户反馈“上周确认过的接口字段，今天又问了一遍”；一次是团队协作时两个开发者对同一段业务逻辑的记忆完全冲突；还有一次最致命——上线前夜，Agent 把已废弃三年的旧支付回调地址当成了最新配置，差点触发灰度环境的误调用。问题不在模型，也不在 prompt 工程。根子出在我们对这两份文件的存储策略和更新节奏缺乏系统性设计。Hermes Agent 的四层记忆架构中，第一层（短期上下文）和第二层（FTS5 会话搜索）解决的是“此刻正在做什么”，而第三层——也就是MEMORY.md与USER.md所承载的长期记忆层——解决的是“我们是谁、我们信什么、我们做过什么”。它不是静态快照，而是一套带版本控制、访问权重、语义衰减和人工干预通道的主动记忆调度系统。它的核心矛盾在于：既要足够稳定以支撑跨周/跨月的连续推理，又要足够灵敏以响应业务变更、安全加固或团队共识演进。过度保守，Agent 就会“守旧”；过度激进，它又会“失忆”或“幻觉”。这正是本文要拆解的：4 类真实工程场景中必须采用的存储策略，以及每类策略背后对应的更新频率数学模型。不讲抽象概念，只说我们在v0.