Hermes Agent 不记得会话内容：定位与修复

你的智能体本该记住

周一你告诉了 Hermes Agent 你的项目。周三它像从未见过你一样重新自我介绍。持久化记忆是你选择自托管智能体而不是 ChatGPT 的全部理由，现在它却像同一个健忘的工具，只是配置步骤更多。

好消息是，Hermes Agent 的记忆系统足够简单，可以从外部诊断。MEMORY.md 和 USER.md 都是磁盘上的纯 markdown 文件。如果智能体不记事，一定是这四种情况之一，每一种都有明确的修复方法。

Hermes Agent 的记忆机制到底怎么运转

在动手诊断之前，先看清楚被弄坏的东西是什么形状。

Hermes Agent 会把两种记忆写到数据目录里（通常是 ~/.hermes/memories/）：

• MEMORY.md - 由智能体自己维护的笔记，涵盖你的项目、偏好和工作流程，上限约 2200 字符，迫使模型主动排序优先级。
• USER.md - 关于你是谁的稳定档案：角色、技术栈和沟通风格。

每次会话开始时，智能体都会读取这两个文件，并注入到 system prompt。会话进行中，它会根据你们聊的内容自动更新。会话结束后，这两个文件仍留在磁盘上。

最后这句话就是全部承诺。如果重启后文件不在磁盘上，就说明记忆没有持久化。如果文件在，智能体依然遗忘，那是另一个 bug。这是两个完全不同的问题。

想更全面了解记忆系统本身，参见 Hermes Agent 的记忆与技能是如何工作的。本篇只讨论失败模式。

原因一：数据卷根本没挂载

这是最常见的原因。症状是：智能体在一整次对话里表现良好，能记住你五分钟前说的话，然后容器重启，它就忘了你的存在。

发生的事情：记忆文件被写进了容器的可写层，而不是持久化卷。当你 docker stop 再 docker start，可写层还在。当你 docker rm（或 docker compose down，或宿主机重启并重建容器），可写层就会被销毁，MEMORY.md 也随之消失。

先检查一件事： 你宿主机上的记忆目录到底是否存在？

ls -la ~/.hermes/memories/

如果智能体已经运行一段时间，这个目录依然为空或不存在，说明容器根本没往那里写。

修复： 把 ~/.hermes 挂载为卷。docker run 里这样写：

docker run -v ~/.hermes:/root/.hermes ...

docker-compose.yml 里这样写：

services:
  hermes:
    volumes:
      - ~/.hermes:/root/.hermes

改动之后，重新创建容器（不是简单地重启），并在你使用智能体的过程中确认宿主机上的 memories 目录逐步被填充。完整的 compose 配置见 Hermes Agent 的 Docker 部署指南。

原因二：卷已挂载，但权限不对

你已经挂载了卷，宿主机上目录也在，但文件依然为空，或者智能体日志里出现 "permission denied"。

容器和宿主机共享同一套数字 UID 空间，默认没有任何机制在两边对齐这些编号。如果容器内的智能体以 UID 1000 运行，而宿主机上的目录归 root 所有，写入就会静默失败。在 Fedora、RHEL 等启用 SELinux 的发行版上，即使标准 Unix 权限允许写入，写操作也会被拒绝，而 Docker 不会给你任何提示。

查看目录所有者：

ls -ln ~/.hermes/memories/

修复，标准 Docker： 让宿主机目录可以被容器所用的同一个 UID 写入：

sudo chown -R $(id -u):$(id -g) ~/.hermes

修复，SELinux 宿主机： 给卷挂载加上 :Z 标签，让 Docker 重新打标签以便容器访问：

volumes:
  - ~/.hermes:/root/.hermes:Z

修复，rootless Docker： 容器里的 "root" 通过 user namespace 被映射到你的宿主机 UID，而不是真正的 UID 0。上面的 chown 已经覆盖了这种情况，但如果不理解这个心智模型，很多人会尝试 sudo 去操作文件，结果依然失败。

原因三：上下文窗口满了，而不是记忆文件

症状是：MEMORY.md 就在磁盘上，里面写着你的项目笔记，cat 也能看到内容，但智能体的表现仍像什么都不记得。这不是记忆的 bug，是伪装成记忆问题的上下文窗口 bug。

Hermes Agent 会在会话开始时把 MEMORY.md 和 USER.md 读入 system prompt，同时也把当前会话的历史消息塞进同一个上下文窗口。如果两者合起来超出模型上限，最先被截掉的是较早的 token。哪怕还没触及硬性上限，"lost in the middle" 效应也会先出现：模型对上下文开头和结尾的信息取回可靠，中间部分则明显更弱。

于是记忆文件可以既存在又正确，但在一段长对话的第 30 轮，模型看到的可能是被截断或深埋在中间的版本，表现得像根本没见过一样。

排查：

• 对比一下不同模型的上下文窗口。看看你配置的是哪一个。窗口小的模型会比 200k 或 1M token 的模型更早撞墙。
• 检查 MEMORY.md 的大小。如果接近 2200 字符的上限，属于正常。如果被某个旧版本 Hermes 撑到了 20k，请修剪。
• 关注当前会话的长度。单次超长会话比多次短会话更容易触发这个问题。

修复：

• 在配置里换成上下文窗口更大的模型。
• 如果 MEMORY.md 已经超上限，手动修剪一下。
• 定期开新会话。Hermes 在每次会话开始时都会重新读取记忆，新会话就会把 MEMORY.md 和 USER.md 加载到一个干净的上下文中。

同一个失败模式在 Telegram 故障排查指南 中"消息能进来但智能体忽略内容"一节里从另一个角度描述过。这是不同渠道上同一个底层 bug。

原因四：按聊天与全局记忆混淆

有的部署方式会为每个 Telegram 聊天启动一个独立的 Hermes Agent 进程，另一些则在多个聊天之间共享记忆。如果你在私聊里告诉过智能体某件事，切到群聊后它却不知道，这是范围不一致，不是持久化的 bug。

排查：

• 看看你的配置。如果里面有"按聊天设定数据目录"的模式，那么记忆就是按聊天隔离的，属于设计意图。
• 如果你是自托管，多个聊天共用同一个 ~/.hermes，那记忆是全局的，问题应当到别处找。
• 如果你为多个聊天启动了多个 Hermes 进程指向同一个 home 目录，那你遇到的是另一个完全不同的问题：两个写入者都会往同一个 MEMORY.md 里写，最终这个文件会落到一个谁都没写过的状态。不要这么做。

修复： 想清楚你要哪种模型，并让配置与之对齐。多数自托管操作者想要全局记忆（一个你、一个智能体、所有聊天）。多用户或多租户部署通常需要按聊天隔离。两种都合理，但不可互换。

崩溃重启后的恢复流程

如果 MEMORY.md 在崩溃或异常关机后损坏、被截为零字节，或内容变成乱码，恢复路径其实很直白，因为它只是一个普通的 markdown 文件。

1. 先停掉智能体，再去动这个文件。运行中的智能体可能会覆盖你的修复动作。
2. 找一下备份。 如果你之前按 将 Hermes Agent 迁移到新机器 的建议做过定期备份，你已经有 ~/.hermes 的历史快照，恢复最近的一份完好快照即可。
3. 需要时手动编辑。 MEMORY.md 是 markdown。用任意文本编辑器打开，删掉损坏部分，保存即可，没有任何 schema 需要遵守。
4. 重启智能体，在下一次会话中确认恢复出的记忆确实回来了。

如果之前没有备份，现在正是配置备份的时机。cron 里加一条 tar czf hermes-backup-$(date +%F).tar.gz ~/.hermes 每天执行，只需几秒，就能为下一次故障买来一条可用的恢复路径。

什么时候该停止 debug，把基础设施交出去

本文的每一个修复都是对容器接线的一次小调整，单独看都不难。真正吞时间的，是在智能体在两周项目对话进行到一半时突然遗忘的那一天，才发现卷从没被挂载、权限一直是错的、也没有任何备份可退回。

如果你希望以后再也不用在 Hermes 日志里看到 "permission denied"，Hermify 在 Telegram 上运行一个托管的 Hermes Agent，使用相同的 MEMORY.md 和 USER.md 文件，卷已正确挂载、每晚自动备份、一键即可恢复。记忆始终归你所有（文件在静态时加密，可随时下载），卷挂载的 debug 也不再是你的事。

若想更全面地看这场部署权衡如何取舍，参见 Hermes Agent 托管服务与自托管对比。

使用 Hermify 快速开始，把记忆持久化的整个清单彻底跳过。

参考资料

• Hermes Agent 记忆机制官方文档
• Hermes Agent Docker 部署文档
• 非 root 容器下的 Docker 卷权限问题
• 上下文窗口是内存，不是存储（Mem0）
• LLM 上下文窗口与截断（Redis）