Hermes Agent 的长期记忆治理：少而准的四条铁律
摘要
Hermes Agent 的长期记忆治理不是靠"存得多"，而是靠一套"少而准"的四条铁律：
- 有界：
USER.md~1,375 字符、MEMORY.md~2,200 字符，强制精简。 - 冻结：会话内不改写，保护 KV 缓存与推理稳定性。
- 透明：每次写入都有通知（
💾 Memory updated），可审批、可撤销、可/journey回顾。 - 自我整合：容量满时不静默丢弃，而是通过
Memory at 2,100/2,200 chars. Consolidate now...错误响应，强迫 Agent 用add / replace / remove三原子操作主动取舍。
结果就是：Agent 越用越懂你，但从不臃肿；记忆越攒越丰富，但从不失控。
引子：一个常见误解
"AI 助手记得越多越聪明。"
事实恰恰相反。记得多而杂，会让 Agent 变笨——它开始把你临时的、错误的、过时的信息，当成关于你的稳定事实。真正好用的长期记忆系统，一定是"少而准"的。
要落地"少而准"，Hermes 回答了四个反问：
- 什么值得进入长期记忆？（写入闸门）
- 已经进来的碎片怎么变成规范条目？（整理）
- 信息变化了怎么办？（更新语义）
- 容量满了怎么办？（consolidate 强制）
下面按顺序把这四道题一次讲透。
一、写入：Agent 自己是第一道闸门
Hermes 的第一道门是写入过滤。它不会把每一句话都存下来，而是在四种明确时机由 Agent 自己判断要不要写：
- Compression（压缩时）：上下文接近上限时，Agent 会 review 当前会话，把"值得跨会话保留"的信息抽出来。
- Checkpoint（关键节点）：任务闭环、话题切换等时刻，做一次记忆盘点。
- Nudges（周期性提醒）：系统会周期性地问 Agent："这一段有什么值得写进长期记忆的吗？"避免忘掉重要片段。
- 用户显式指令："请记住 X" 会被优先写入。
判断标准通常包括：
| 判断维度 | 具体含义 | 反例 |
|---|---|---|
| 可复用性 | 这条信息在未来其他任务里可能还会用到吗？ | "今天想喝拿铁" |
| 稳定性 | 它是暂时的还是长期的？ | "今天头有点疼" |
| 具体性 | 是模糊态度，还是可复用的事实？ | "我大概比较喜欢简洁一点" |
| 隐私敏感度 | 未经用户显式确认的邮箱、密码、地址 | 默认不写 |
一个训练良好的 Hermes Agent，宁可少记，也不乱记。
二、整理：把碎片重写成条目
即便通过了写入过滤，进来的信息也往往是"碎片"。Hermes 的第二道处理，是把碎片重写成规范条目。
举个例子。原始对话可能是：
"哦对了，我们那个 API 后来改成走 gateway 了，不再直连服务了，是上个礼拜的事。"
Hermes 不会原样保存这句话，它会写成：
- [~2026-07-24] Project X 的 API 已从直连改为经由 gateway 路由。这里发生了四件事：
- 抽事实：去掉"哦对了"这类语气词。
- 补主语：把"我们那个"补成"Project X"。
- 加时间：把"上个礼拜"锚定成大致时间。
- 可检索：写成结构化条目，方便日后 FTS5 命中（~20ms 命中，~1ms 翻页）。
结构化整理之后，记忆条目才具备"几个月后被再次召回"的可能。
三、三原子操作：add / replace / remove
Hermes 对 MEMORY.md 的每一次改写，都必须落到三种原子操作之一：
| 操作 | 语义 | 触发场景 |
|---|---|---|
| add | 新增一条 | 新事件、新决策 |
| replace | 用新条目覆盖旧条目 | 状态变化（"API 现在走 gateway"覆盖"API 直连"） |
| remove | 物理删除 | 用户否认、条目过期、consolidate 后被合并的旧条目 |
为什么不允许模糊操作（比如"更新一下相关字段"）？
理由 1：原子操作可审计。每一次记忆变化都能对应到"哪条 → 变成哪条"，从而支持 /memory diff <id> 这种精确 review。
理由 2：迫使 Agent 显式决策。"我现在是想替换，还是想新增？"这个二选一，本身就是取舍的开始，能防止"分裂人格"。
理由 3：为审批闸门（第七节）打基础——每个 pending 项都能被独立 approve / reject。
四、更新语义：优先修改，不追加相反
这是很多简单记忆系统会翻车的地方：信息变化了怎么办？
朴素做法是"再记一条"，结果 Agent 里同时存在：
- "用户偏好 Vue"
- "用户后来换成了 React"
- "用户又回到了 Vue"
三条并列，模型自己都不知道该信谁。
Hermes 的做法是优先更新，而不是追加相反：
USER.md里的偏好类字段，倾向于"覆盖旧值"（replace）。MEMORY.md里，历史事件保留，但当前状态字段被更新（replace），并保留一个简短的"版本迁移"痕迹。- 用户明确否认的内容（"我从来不是那样"），会被
remove——物理删除，而不是记录成"用户否认了 X"。
这样做的核心目的，是让 Agent 的世界模型保持自洽。
五、容量满了：Consolidate now
Hermes 给 MEMORY.md 定的硬上限是 ~2,200 字符。当容量逼近时，任何 add 操作会返回：
{
"success": false,
"error": "Memory at 2,100/2,200 chars. Consolidate now...",
"current_entries": [...],
"usage": "2,100/2,200"
}这不是 bug，是设计。
如果容量满了自动丢弃最旧的条目，Agent 就永远学不会取舍——重要的信息可能被踢，无关的信息可能留着。Hermes 反其道而行之：满了不让写，直到 Agent 自己整理出空间。
整理动作通常包括：
- 主题聚合：若干相似条目 → LLM 摘要成一条更概括的记忆。
- 过期归档："本周 sprint 的目标是…" 时间点之后
remove。 - 访问频率降权：长期没被召回的条目排到队尾，被优先合并或删除。
这些机制加在一起的效果是：你几个月前的碎碎念不会一直污染 Agent 对你的判断，但真正长期重要的信息会被反复强化。
六、Consent-aware learning loop：Agent 在后台学，但不打扰你
Hermes 还有一个隐藏能力：后台自省循环。它会周期性地：
- 拉出最近几次会话；
- 让一个便宜的模型（比如 Gemini Flash）跑一遍"值得记的内容"提取；
- 生成候选记忆条目，标记
[auto]。
官方把这个循环称为 consent-aware learning loop（同意感知学习循环）——学习不该打扰用户，但用户随时可以介入。
这套设计的好处是：
- 成本降到 1/3~1/5：便宜模型跑回顾，官方测试对记忆捕获质量几乎没影响。
- Agent"你不用的时候也在成长"：只要它长期在线。
- 不干扰前台对话：候选条目在下一节的审批闸门里等你批。
七、审批闸门：如果你不放心 Agent 自作主张
有些用户会担心："Agent 自动写 MEMORY 万一写错了呢？"
Hermes 提供了显式开关：
memory:
write_approval: true # 打开审批闸门打开后，所有记忆写入（包括后台自省的自动写入）都会暂存待审。用户通过以下命令逐条审阅：
/memory pending # 列出待审条目（后台自省标记 [auto]）
/memory diff <id> # 查看具体变更
/memory approve <id> # 批准（或 all）
/memory reject <id> # 拒绝Skills 有独立的 skills.write_approval，因为 SKILL.md 可能很长，无法在聊天窗口直接展示，Hermes 提供 /skills diff <id> 让你看完整 unified diff。
审批闸门本质上是把"Agent 自主学习"和"用户主权"做了个显式解耦——Agent 可以自由地积累经验，但每一次改写用户档案都要过用户这一关。
八、透明化：你能看见 Agent 每一次记忆更新
Hermes 会通过通知让你实时看到记忆动作：
| 配置值 | 显示效果 |
|---|---|
off | 静默写入，不显示 |
on（默认） | 💾 Memory updated |
verbose | 💾 Memory ➕ User prefers terse replies（带内容预览） |
从"记住了什么"到"记住了具体哪条"，粒度都可控。这种可观测性在 AI Agent 里其实很少见——大多数 Agent 的记忆是黑盒。
九、Learning Journey：审阅 Agent 的成长过程
如果你想回顾几个月来 Agent 学过什么，Hermes 提供了 /journey（别名 /learning、/memory-graph）：
- CLI：
hermes journey（支持--play动画回放、--json导出） - TUI：
/journey覆盖层 - 桌面版：Star Map 交互面板
配套的清理命令：
hermes journey list # 列出所有节点
hermes journey delete <node> # 归档 Skill（可恢复）或删除记忆
hermes journey edit <node> # 用 $EDITOR 打开编辑这个工具的存在意义远超"炫技"——它承认了一件事：Agent 的成长过程本身，值得被审阅。
十、这套克制哲学的现实意义
把上面所有机制串起来，Hermes 的记忆哲学其实是四条铁律：
- 有界：字符上限强制精简。
- 冻结：会话内不改，保护缓存。
- 透明：每次写入用户看得见，可审批可撤销。
- 自我整合：容量满了不静默丢弃，而是逼 Agent 主动取舍。
在宣传"AI 记忆能力"时，很多产品强调"支持多大记忆库、记住多少条目"。但站在使用者的角度，你真正关心的是三件事：
- 它有没有记住真正重要的东西？
- 它有没有把已经不成立的信息及时更新掉？
- 它会不会因为记了一堆无关的东西，反而变得更啰嗦、更容易搞错？
能回答"什么不该记"的记忆系统，才是好的记忆系统。
十一、可这套机制想真的跑通，还差一个东西
再好的记忆机制，也需要一个前提：Agent 得一直活着。
如果你把 Hermes 装在自己笔记本上，笔记本一合盖就"打盹"，后台自省循环停摆，nudge_interval 永远等不到下一次触发。换设备、系统重装还要手动搬 ~/.hermes/ 目录。
这时候，云托管方案就变得非常有意义。LightVela 是云托管的 Hermes Agent 服务：
- 独立云端实例，24×7 在线，
MEMORY.md/USER.md/SQLite 会话档案永久驻留； - 后台自省循环持续运行，Agent 真正做到"你不用它的时候也在成长"；
- 数据仅存于你的专属服务器；
- 手机、笔记本、Telegram、飞书……多渠道进来都是同一个"认识你的 Agent"。
Hermes 把"记忆不是越多越好"的哲学做到了极致；LightVela 让这套哲学真的每一天都在你身边生效。 这才是"越用越懂你"这句 slogan 兑现的方式。
小结
- 好记忆系统 = 严格写入 + 规范整理 + 三原子操作 + Consolidate 强制 + 后台自省 + 审批闸门 + 全程透明。
- 记得多不等于聪明，能识别"什么不该记"、能被逼着"取舍"才更重要。
- Hermes 给出了工程实现的参考，LightVela 想把它做成用户能触达的产品体验。