Hermes 记忆系统详解与 Provider 选型
本文深入讲解 Hermes Agent 的记忆系统——它如何工作、有哪些 Provider 可选、以及我们在 Hindsight 和 Holographic 之间踩过的坑。
前置：Hermes Agent 已安装 → Hermes Agent 安装与踩坑实录
内置记忆系统
两层结构
Hermes 的默认记忆系统由两个 Markdown 文件组成：
| 文件 | 用途 | 上限 |
|---|---|---|
MEMORY.md |
Agent 的笔记——环境、项目、约定、教训 | 2,200 字 |
USER.md |
用户画像——身份、偏好、习惯 | 1,375 字 |
都存储在 ~/.hermes/memories/ 下，每会话开始时注入到系统提示词。
工作原理
每次新会话启动
│
├─→ 读取 MEMORY.md + USER.md
│
└─→ 注入到 Agent 的「系统提示词」里
会话进行中
│
├─→ 用户纠正 Agent / 说「记住这个」→ Agent 用 memory 工具写入
│
├─→ Agent 发现新环境信息 / 约定 → 自动写入
│
└─→ 写入成功后，下次会话生效
⚠️ 重要： 记忆在会话中写入后，不会立即生效。要等到下一次新会话，更新的记忆才会注入。这是故意的——避免中途改提示词破坏 LLM 的 prefix cache。
记什么、不记什么
| ✅ 存（持久） | ❌ 不存（临时） |
|---|---|
| 用户身份、偏好 | 会话进度、TODO 列表 |
| 项目路径、环境信息 | PR 号、issue 号 |
| 经验教训、工作约定 | 已完成的任务日志 |
| 工具配置、踩坑记录 | 一周内会过期的信息 |
原则：存「下次还用得上的事实」，不存「这次干了什么」。
三个操作
Agent 通过 memory 工具管理记忆：
add—— 新增一条记忆replace—— 用old_text匹配旧条目，替换为新内容（子串匹配，不需要完整旧文本）remove—— 删除一条过时记忆
为什么需要 Memory Provider
内置记忆系统的问题：
| 限制 | 影响 |
|---|---|
| 2,200 字上限 | 项目多时不够用 |
| 纯文本匹配 | 只能按子串搜索，不能语义检索 |
| 无去重 | 可能存重复信息 |
| 无优先级 | 新旧记忆同等权重 |
Memory Provider 是 Hermes 的可插拔记忆后端，解决这些问题。
8 个 Provider 对比
Hermes 共有 8 个 Provider，通过 ops config set memory.provider <name> 切换：
| Provider | 存储方式 | 外部依赖 | 从国内访问 | 复杂度 |
|---|---|---|---|---|
| holographic | 本地 SQLite + FTS5 | ❌ 零 | 本地 0ms | ⭐ 低 |
| 内置默认 | Markdown 文件 | ❌ 零 | 本地 0ms | ⭐ 低 |
| honcho | 独立服务 | 需部署 | 本地 0ms | ⭐⭐ 中 |
| openviking | 字节跳动云 | 云服务 | 国内快 | ⭐ 低 |
| mem0 | Mem0 云 API | API Key | 海外慢 | ⭐ 低 |
| supermemory | Docker 向量 DB | Docker | 本地 0ms | ⭐⭐⭐ 高 |
| hindsight | 知识图谱 + 向量 | 云/本地 | 看模式 | ⭐⭐⭐ 高 |
| byterover | 本地 CLI | brv CLI | 本地 0ms | ⭐⭐ 中 |
| retaindb | 云 API | API Key | 海外慢 | ⭐ 低 |
Hindsight vs Holographic：实战对比
这是我们尝试的两个 Provider，过程和结果完全不同。
Hindsight：想用最牛的，被现实教育
Hindsight 是 vectorize-io 开发的记忆系统，功能最强：
- 知识图谱 —— 自动提取实体并建立关系
- 多策略检索 —— 语义 + 图谱 + 向量混合检索
- 实体解析 —— 自动合并同一实体的不同表述
- 三种模式 —— Cloud、Local Embedded、Local External
我们选的是 local_embedded（本地嵌入式），理论上最理想——功能全、隐私好、不走云。
🕳 坑点 1：安装超大。
uv pip install hindsight-all包体积 ~200MB，还带一个嵌入的 PostgreSQL。在国内从清华镜像下载就很慢。
🕳 坑点 2：需要下载 HuggingFace 模型，国内几乎不可能。
Hindsight 本地模式需要两个 HuggingFace 模型：
BAAI/bge-small-en-v1.5（嵌入模型，~130MB）cross-encoder/ms-marco-MiniLM-L-6-v2（重排序模型，~200MB）从国内下载 HuggingFace 模型的成功率极低。我们的 daemon 反复下载超时：
RuntimeError: Cannot send a request, as the client has been closed. ERROR: Application startup failed. Exiting.
🕳 坑点 3：内存爆炸。
PostgreSQL + Python daemon + 模型加载 ≈ 1.6GB 内存。我们的服务器总共才 4GB。
🕳 坑点 4：端口混乱。
Hindsight daemon 默认端口 8888，但实际启动后绑定到 9177。Hermes 配置默认连 8888，导致 Gateway 报错：
Hindsight API at http://localhost:8888 reports version None
结论：放弃 Hindsight，不适合国内环境。
Holographic：够用就好
Holographic 是本地的轻量级 Provider：
| 特性 | 说明 |
|---|---|
| 存储 | 本地 SQLite |
| 检索 | FTS5 全文搜索（比子串匹配强一个量级） |
| 自动去重 | ✅ |
| 信任评分 | ✅ 旧信息自动降权 |
| 实体解析 | ✅ |
| 外部依赖 | ❌ 零 |
| 内存占用 | 零额外（SQLite 本身几乎不吃内存） |
| 安装 | 内置，无需 pip install |
切换到 holographic 只需一行：
ops config set memory.provider holographic
然后重启 Gateway（/restart 或 pkill + 重启）。
🕳 注意： 切换 Provider 后旧的 MEMORY.md 不会自动迁移。如果需要保留旧记忆，先确保
memory工具在当前会话中确认过旧记忆内容，新 Provider 会在后续会话中重建。
实战教训
1. 先跑通再优化
内置记忆（2,200 字）对绝大多数个人场景完全够用。别急着换 Provider——等真的撞到上限再说。
2. 国内环境下，零依赖是王道
凡是需要下载 HuggingFace 模型、访问海外 API 的 Provider，在国内大概率翻车。优先考虑：
- holographic（零依赖 SQLite）
- 内置（Markdown 文件）
- openviking（字节跳动云，国内快）
3. 切换 Provider 后要验证
# 1. 确认 config
grep provider ~/.hermes/config.yaml | grep memory
# 2. 重启 Gateway
pkill -f "ops gateway run"
~/.hermes/scripts/start-gateway.sh &
# 3. 检查日志没有 provider 相关报错
tail -f ~/.hermes/logs/gateway-cron.log | grep -i memory
相关阅读：
- Hermes 安装踩坑 → Hermes Agent 安装与踩坑实录
- 微信 Gateway 接入 → 微信 Gateway 接入 Hermes
- 服务器部署全过程 → 从零购买并配置云服务器