你有没有过这样的体验：一个会话从周一开到周五，上下文越滚越长，每次回复越来越慢、越来越贵，可 Hermes 好像也没变“聪明”多少——它甚至想不起来上周你告诉过它的偏好。一位开发者上周在博客里分享了他的反思（I think I used the Hermes Agent wrong），他发现自己的用法可能正是问题所在：他几乎从不结束会话。

这位作者用树莓派 + Telegram 跑了 18 天 Hermes，一共只产生了 5 个会话——因为每晚关机、早上重启后，Hermes 会自动接着上一个会话聊。结果呢？在 1990 条消息里，Hermes 主动使用 session_search（跨会话检索工具）只有 9 次；记忆文件也几乎不更新。原因很简单：一切重要信息都还在上下文里，它根本不需要“回忆”。而 Hermes 的长期记忆，恰恰是围绕“会话会结束”这个前提设计的。

先弄清 Hermes 的记忆是怎么工作的

Hermes 的持久记忆分两块，理解它们各自的角色，才能明白为什么会话边界如此重要。

第一块：跨会话的“便签”——MEMORY.md 和 USER.md。 每个 profile 下都有这两个文本文件（还有可选的 SOUL.md）：USER.md 记关于你的事实，MEMORY.md 记 Hermes 自己积累的笔记和偏好。新会话启动时，这两个文件会被读进上下文，让 Hermes“记得”你是谁、你踩过什么坑。但它们有字符上限——源码里默认是 memory_char_limit: 2200、user_char_limit: 1375，大约是 800 和 500 token 的样子。快写满时，Hermes 必须靠记忆工具做合并、精简、删旧加新，把最重要的留下。

第二块：会话历史数据库（state.db）里的完整记录。 你与 Hermes 的每一条消息都存在本地 SQLite 里。session_search 这个工具就是让 Hermes 在当前会话之外检索过去的对话——比如“我上次是怎么修好那个 CI 报错的”。这正是记忆系统的另一半：上下文装不下时，靠检索把旧细节捞回来。

再看“写入”发生在什么时候。 除了对话过程中主动用记忆工具，Hermes 还有后台回顾机制：回合结束后，它会异步回看这段对话，把值得沉淀的经验、纠正、偏好写进记忆。这套机制想正常运转，前提就是会话有自然的终点——结束时沉淀一批、下个会话开头注入一批，形成“记下来→带过去→再沉淀”的循环。

永远不结束会话，会发生什么

把上面的机制代入“一个会话跑 18 天”的场景，问题就清楚了：

• 记忆文件形同虚设。MEMORY.md/USER.md 只在会话开头注入。一个超长会话里，这些内容早就在上下文里了，Hermes 不需要靠记忆文件“想起”什么——于是后台回顾也懒得更新它们，文件渐渐成了摆设。
• session_search 几乎不触发。工具是给“上下文里没有、但历史里有”的情况用的。会话足够长时，过去几天的内容都还在上下文窗口里，检索自然没有用武之地。作者统计的 9 次/1990 条，不是 Hermes 变笨了，是它真的不需要。
• 费用和延迟不断攀升。每个回合都要把越来越长的历史重新发给模型，token 账单随会话长度线性上涨；上下文逼近窗口上限时，压缩机制开始介入，把老内容压成摘要——而压缩是有损的，细节就在一次次摘要里悄悄流失。
• 你失去了“记忆的分层”。长会话把短期上下文和长期记忆搅在一起：什么都“记得”，等于什么都不精。该靠便签记住的长期偏好，和该靠检索找回的一次性细节，全糊在同一锅粥里。

什么时候该开新会话，什么时候该续旧的

好消息是，判断标准其实很简单，核心就一句话：任务是否还在继续。

适合继续旧会话（resume）的情况：

• 同一个任务还没做完，中间只是暂停（比如写一篇长文，写到一半去吃午饭）；
• 上下文里那些临时细节（某个文件的路径、某段正在调试的代码）下一步马上要用，不值得重新交代；
• 你在同一个终端里来回切换任务，想保留各自的来龙去脉。

适合开新会话的情况：

• 上一个任务已经交付或明确结束——哪怕只是“暂时告一段落”；
• 话题切换了，而且新旧任务之间没有必须共享的上下文；
• 你发现上下文已经很大（可以用状态栏或 hermes status 之类看 token 占用），而新任务其实用不上那些旧内容；
• 你希望 Hermes 真正“记住”这次对话的结论——结束会话让后台回顾有机会把经验沉淀进记忆。

切换时的正确姿势：新任务开始前，如果旧会话里有值得带走的结论，可以让 Hermes 把要点写进记忆，或者用我们介绍过的 /save 命令导出存档再开新篇；续旧会话用我们之前讲过的 hermes chat -c 续接技巧，每个终端各自续自己的会话，不会串台。万一遇到会话数据异常，这篇文章里还有排查和自救的完整流程可以参考。

把会话边界当成一种习惯

那位作者的反思之所以值得分享，是因为他踩中的不是某个 bug，而是用法的错位：把为“多会话”设计的记忆系统，用成了“一个会话到底”。你不需要刻意卡着时间结束会话，只需在任务告一段落时自然开新篇——让记忆文件的注入、后台回顾的沉淀、session_search 的检索各就各位。会话有边界，记忆才有循环；而一个会“记得”你的 Hermes，才是当初吸引你安装它的那个样子。