OpenClaw 养虾“马”实战006 案例分享:Hermes 分层记忆,让助手又稳又懂你

不少人着急，是期待没对齐：把聊天窗口当成记事本，又嫌模型转眼接不上。其实单次对话里，模型能稳定吃下的上下文有上限，全堆在一起只会又闹又费 token。本篇 006 案例分享讲一件实在事：用 Hermes 这套分层记忆，让助手该记的记住、该查的能查、该腾位置时会腾；从工程上看是热冷分层与归档，从使用上看就是少返工、少车轱辘话。

一、先弄清一件事：为什么要分三层

一句话：不是什么都要在每一轮都塞进上下文。

• 身份和底线（你怎么称呼我、什么绝对不能做）要场场在场，否则每轮都要重新教。
• 经常要用的短句规则（偏好、环境路径、你定死的铁律）适合小体量、高频率地跟着走。
• 成篇的项目说明、历史决策、从热层挪出去的归档，适合进大口袋，用到再取，不占用每轮都有限的热位。

下面三层，就是在工程上把上面三类需求拆开存放。名字是术语，但职责可以当常识记。

二、三层各管什么

你可以这样对应理解（和知识库里的技术说明是一回事）：

热层小、冷层大，是刻意设计：热层保当下不跑偏，冷层保老本不丢、以后还能翻。

三、往哪记：三条好记的规则

1. 会反复约束行为的
   
   （偏好、规矩、错一次就要纠的那种）… 进Memory，走热层工具写入，下轮就还在。
2. 要长久保存、但不必每轮都摆上桌的
   
   （方案说明、大段背景）… 进Brain，用时再查，避免把对话窗口当硬盘。
3. 本次任务进度、临时中间结果
   
   … 尽量别都固化进长期记忆；该回溯会话的，用产品提供的会话搜索类能力，比把流水账硬写进记忆库要干净。

这样做，助手的表现会更像有纪律的同事：先读身份和便签，再决定要不要去档案里翻大材料。

四、热层会满，怎么办

Memory 有上限，不是产品偷懒，是逼你把高频提醒和大库存档分开。快满了，就把稳定条目归档到 Brain，再从热层删掉占位，信息不丢，只是不挤在便签里。

可以记四个设计意图（和工程文档一致，方便你和别人对齐口径）：

• 热冷分开：
  
  常带的少，库里的全。
• 容量守得住：
  
  热层不无限长，才守得住每轮质量。
• 归档不是删号：
  
  进冷层是迁移，不是扔掉。
• 能自动就不甩给人：
  
  能监控、能归档的，尽量别让使用者天天手搓清理。

五、需要动手时，通常碰这几类

具体命令、路径、脚本名，以你本机与仓库里的README为准。这里只记要干什么：

• 改热层条文：memory
  
  的增删改类操作。
• 往冷层写大段、按主题查：brain
  
  的写入与查询
• 看热层使用、做归档、腾位置：memory-manager
  
  一类脚本，按说明做 status、archive 等。

把README 当速查表，比背命令重要：环境一变，意图不变就能对上号。

六、收束一句

和解在这里的意思很朴素：承认单靠一段提示词扛不住长期协作，那就用分层记忆给助手身份、近处提醒、远处档案三件事分工。你养的是 Hermes 这一套工程能力，不是赌模型这一把心情。

效果展示

本篇以结构图讲清设计为主。若你后续有从空热层到第一次归档的短录屏，可放在本案例下作补充；版式可参照养虾实战005同节。

关于本系列：养虾实战

006这一篇是案例分享性质：在能跑任务的前提下，把记忆怎么设计说透一层。001在线 PPT；002小红书内容流水线；003公众号采集；004生活场景；005云端开发流水线。编号延续，只是方便你按篇检索。

#OpenClaw养虾实战 #养虾实战006 #Hermes #记忆 #gbrain #OpenClaw #案例006