第9章 Hermes三层记忆系统

本章前置检查：

• □ Hermes已成功部署并运行（完成第8章内容）
• □ 能通过CLI与Hermes进行基础对话
• □ 理解AI记忆的基本概念（什么是“金鱼记忆”问题）

本章预估总时长：4小时

本章难点提示：

• 9.2节（MEMORY.md和USER.md）需要理解“冻结快照”机制——会话启动时记忆被“冷冻”为系统提示词，会话中修改了记忆但当前会话看不到变化，这个反直觉的设计是Hermes记忆系统中最容易让人困惑的地方。
• 9.3节（FTS5全文检索）的核心是理解session_search工具需要Agent主动调用，而不是自动加载。
• 9.4节（技能记忆）涉及Agent如何将成功经验固化为可复用技能，建议结合第7章的学习循环一起理解。
• 9.6节（记忆删除）和9.7节（外部数据库）是本章的实操重点，建议动手实践。外部记忆提供商属于进阶内容，优先掌握内置记忆即可。

🎯 本章教学目标：深入理解Hermes的三层记忆架构，掌握MEMORY.md和USER.md的撰写方法和使用场景，学会使用memory工具管理记忆条目，掌握session_search工具检索历史对话，理解技能记忆的工作机制，学会删除各类记忆以及了解外部数据库扩展方案，能够根据需求正确选择记忆类型和容量管理策略。

9.1 为什么需要三层记忆

🎯 本节目标：理解Hermes记忆系统的设计理念和分层原则。

预计时长：0.3小时

从“金鱼记忆”说起

大多数AI助手有一个致命问题：每次会话都是一张白纸。你跟它聊了半天，告诉它你的喜好、项目进度、代码规范，它都记住了——但下周一打开新会话，它又问：“你好，我是AI助手，请问有什么可以帮你的？”

这种“每次从零开始”的体验，被称为AI的“金鱼记忆”问题。Hermes针对这一问题设计了一套三层记忆系统：持久记忆、会话记忆和技能记忆。

这三层的核心区别在于：

记忆类型	存储什么	访问方式
持久记忆	用户偏好、项目规范等长期信息	每次会话启动时自动加载到系统提示词
会话记忆	每轮对话的具体内容	通过session_search工具按需检索
技能记忆	成功的多步工作流程和方法论	按需加载，跨会话复用

三层分别对应认知科学中的语义记忆、情景记忆和程序性记忆——不仅记录“发生了什么”，更记录“什么方法管用”，从而在未来更高效地解决问题-。

从更精细的视角来看，Hermes的记忆实际上是四层架构，但为便于理解，我们将其分为三层——即便加上外部记忆提供商，内存层和技能层永远并行运行，互不干扰，不会因为启用了外部提供商就舍弃内置记忆。

龙马注：你不需要记住这几层是在第几层、源头在哪，用的时候记住这点就行——“热记忆，永远在脑子里（MEMORY.md/USER.md）；冷记忆，主动搜才能看到（session_search）；技能记忆，干成事后自动存档（Skills/）。”

🛠️ 实践任务（本节）：访问Hermes的GitHub仓库，在~/.hermes/目录下查看记忆相关的文件夹，初步了解文件结构。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

9.2 第一层：持久记忆——MEMORY.md与USER.md

🎯 本节目标：掌握MEMORY.md和USER.md的写作方法，理解它们的区别和使用场景，学会让Hermes“记住”重要信息。

预计时长：1.2小时

9.2.1 MEMORY.md和USER.md是什么？

Hermes使用两个核心Markdown文件来实现跨会话的持久记忆。这两个文件位于~/.hermes/memories/目录下，会在每次新会话启动时作为“冻结快照”加载到系统提示词中。

两个文件的分工非常明确：

• MEMORY.md：存储环境和项目的客观事实，例如服务器配置、常用部署路径、项目规范、发现的解决方案等。
• USER.md：存储用户的偏好和习惯，例如沟通风格、决策习惯、偏好的输出格式等。

容量限制：MEMORY.md约2,200字符（约800 tokens），USER.md约1,375字符（约500 tokens），两者合计约3,575字符。这强制了Agent只保留最核心、最有价值的信息。

容量限制带来的后果也不容忽视：当文件写满时，memory工具会返回错误，Agent必须先将现有记忆合并、精简或删除，才能添加新条目。在这个过程中，一些细节可能会被压缩或丢失——并非Agent忘记了，而是它在容量硬约束下的权衡。

这个容量设计是Hermes提供开箱即用记忆的同时又不显著增加Token成本的关键权衡。500-800 tokens的记忆压力极低，每条记忆都需要高度精炼。

9.2.2 两者的具体区别

维度	MEMORY.md	USER.md
存储内容	环境事实、项目规范、经验教训	用户偏好、沟通风格、身份信息
关注点	“世界是什么样的”	“这个人是什么样的”
典型条目	常用API密钥、部署路径、代码规范	喜欢简洁回答、偏好Python

在实际使用中，一条粗粒度的规则可以写在MEMORY.md中，而需要持续跟踪的用户临时偏好或细微变化，更适合放在会话级的执行记录或必要时更新的USER.md中，而不是一次性把所有规则全塞进MEMORY.md。

9.2.3 写入机制：谁在写，什么时候写？

很多新手会发现：跑了好几轮对话，这两个文件却还是空的。这不是Bug，而是设计决策的体现。

Hermes的持久记忆是Agent自主筛选的，不是自动录音机。只有当Agent判断某些信息值得长久保留时，才会写入MEMORY.md或USER.md。触发写入的情形包括：学到新的事实、用户纠正、发现的解决方案、用户的偏好变化等。

写入触发还依赖于nudge_interval配置——系统会定期提醒Agent进行“反思”，回顾对话并筛选值得保存的信息。

情形	是否写入
普通闲聊（“今天天气不错”）	❌ 不写入
用户纠正偏好（“以后回答问题请用表格”）	✅ 写入USER.md
发现服务器配置（“数据库在5432端口”）	✅ 写入MEMORY.md
重复模式识别（连续三次被问相同配置）	✅ 写入MEMORY.md

如果希望强制写入，可以明确对Hermes说：“请记住，我的生产数据库在5433端口”——这条指令会迫使memory工具立即执行写入操作。

9.2.4 memory工具的完整操作

Agent通过memory工具管理持久记忆，支持三个核心操作：

1. add——添加记忆

python

# 向MEMORY.md添加环境事实
memory(action="add", target="memory", content="这台服务器运行Debian 12，PostgreSQL 16")

# 向USER.md添加用户偏好
memory(action="add", target="user", content="用户偏好简洁的回复，不喜欢冗长的解释")

2. replace——替换记忆（使用子串匹配，不需要完整文本）

python

# 如果记忆中包含"dark mode"，将其替换为新内容
memory(action="replace", target="memory", old_text="dark mode", 
       content="User prefers light mode in VS Code, dark mode in terminal")

3. remove——删除记忆

python

# 删除MEMORY.md中包含"旧的项目信息"的条目
memory(action="remove", target="memory", old_text="旧的项目信息")

这三种工具操作都有对应的用户侧斜杠命令。在对话中可直接使用/memory add <内容>添加记忆，/memory remove <内容>删除记忆，/memory查看记忆摘要-1。

9.2.5 为什么叫“冻结快照”？

会话启动时，系统读取MEMORY.md和USER.md的当前内容，将其“冻结”为系统提示词的一部分。这两个文件在这个会话中不会再变。

会话中对MEMORY.md或USER.md的修改会立即写入磁盘，但当前会话看不到变化——因为系统提示词中的快照已经“冻住了”。这些变化要在下个新会话中才会生效。这个设计保障了prefix cache的稳定性，防止缓存击穿导致推理性能大幅下降。

龙马注：这个冻结机制第一次遇到时可能会困惑——你让Hermes记住了一件事，它说“好的”，但你继续问它，它还是不知道。这不是它没记住，是当前的“记忆快照”已经定死了，换一个新会话你再问，它就知道了。

9.2.6 如何撰写有效的MEMORY.md

MEMORY.md应当存储与环境强关联的客观事实。每个条目应是一个独立的语义单元，用Markdown的无序列表或段落形式组织。

MEMORY.md示例（位于~/.hermes/memories/MEMORY.md）：

markdown

# 环境知识库

## 服务器配置
- 生产服务器的SSH地址：user@prod.example.com -p 2222
- 测试环境的API基础地址：https://test-api.example.com
- 数据库备份存储在 `/backups/sql/`，保留策略为30天

## 项目规范
- Python项目统一使用`poetry`管理依赖
- 代码风格遵循black格式化，行宽88
- Git提交信息遵循Conventional Commits规范

## 常用工具
- 数据分析使用`pandas`和`plotly`
- 数据库查询使用`psql`命令行工具

## 已发现的问题与解决方案
- 包安装时需加`--no-deps`标志，否则会拉取多余的依赖导致冲突
- 内存不足时重启Gateway的有效命令是`hermes gateway restart`

MEMORY.md的维护原则：

• 只保留跨项目通用或长期不变的配置信息。
• 定期清理不再适用的陈旧条目。
• 当文件接近容量上限时，主动要求Hermes合并冗余条目。

9.2.7 如何撰写有效的USER.md

USER.md存储用户自身的偏好和习惯，帮助Hermes更好地理解你、用你习惯的方式与你沟通。

USER.md示例（位于~/.hermes/memories/USER.md）：

markdown

# 用户画像

## 基本信息
- 称呼：小沈
- 职业：量化策略研究员
- 技术栈偏好：Python、TypeScript、Rust

## 沟通偏好
- 回答尽量简洁，先给结论再给详细分析
- 代码示例优先，其次才是文字描述
- 喜欢表格而非长段落

## 工作习惯
- 周一上午通常不开会，可以安排深度任务
- 偏好TDD（测试驱动开发）
- 习惯每天收盘后（15:00-16:00）处理事务

## 决策偏好
- 风控优先：宁可少赚，不可大亏
- 数据驱动：做决策前需要先看到回测数据

9.2.8 会话中的记忆可视化

在新会话开始时，记忆被注入系统提示词，格式如下：

═════════════════════════════════════════════
MEMORY (你的个人笔记) [67% — 1,474/2,200 字符]
═════════════════════════════════════════════
用户项目是一个 Rust Web 服务，位于 ~/code/myapi，使用 Axum + SQLx
§
这台机器运行 Ubuntu 22.04，安装了 Docker 和 Podman
§
用户偏好简洁的回复，不喜欢冗长的解释

格式说明：

• 标题：显示哪个存储（MEMORY或USER PROFILE）
• 使用百分比：让Agent知道容量
• §分隔符：标记不同条目
• 冻结模式：会话期间不变，保持LLM前缀缓存

9.2.9 如何启用和验证记忆加载

如果发现Hermes似乎没有加载你的记忆，按以下步骤检查：

步骤1：检查文件是否存在

bash

ls -la ~/.hermes/memories/
# 应显示 MEMORY.md 和 USER.md

如果文件不存在，手动创建它们。

步骤2：验证配置是否正确

在~/.hermes/config.yaml中确认memory配置段落：

yaml

memory:
  enable: true
  files:
    - ~/.hermes/memories/MEMORY.md
    - ~/.hermes/memories/USER.md

步骤3：使用诊断命令检查

bash

hermes doctor --check memory
# 输出应包含 "✓ Memory files loaded successfully"

✏️ 即时自测：MEMORY.md和USER.md的核心区别是什么？如果在当前会话中让Hermes记住了新信息，立即问它能回答吗？为什么？

🛠️ 实践任务（本节）：

1. 检查~/.hermes/memories/目录是否存在这两个文件（无则手动创建）
2. 在MEMORY.md中添加一条你的项目规范
3. 在USER.md中添加一条你的沟通偏好
4. 启动一个新会话，向Hermes问一个关于你项目规范的问题，观察它是否能回答
5. 在会话中使用/memory add添加一条新记忆，然后用/memory查看记忆摘要

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

✏️ 自测答案：MEMORY.md存储客观事实和项目规范，USER.md存储用户偏好和习惯。不会立即生效，因为当前会话的冻结快照在会话启动时已固定——修改会在下个新会话中生效。

9.3 第二层：会话记忆——FTS5全文检索

🎯 本节目标：理解Hermes如何通过FTS5实现跨会话历史检索，掌握session_search工具的使用方法。

预计时长：0.8小时

学习提示：FTS5（Full-Text Search 5）是SQLite自带的全文搜索引擎。Hermes利用它在state.db数据库中为所有会话建立全文索引，使Agent能够跨会话检索历史对话中的关键词。

9.3.1 什么是会话记忆？

如果说MEMORY.md存储的是“提炼后的精华”，那么会话记忆存储的是“完整的历史底稿”。

Hermes会将所有CLI和消息网关的会话完整记录存储在~/.hermes/state.db这个SQLite数据库中，并通过FTS5全文检索引擎建立索引。

为什么需要会话历史？
MEMORY.md存的是你提炼后的结论，而session_search能搜到的，是当初讨论过程的完整对话——包括你当时为什么选择了这个端口，最后怎么解决的。这是区别。

9.3.2 session_search工具的使用

Agent不会自动加载全部历史（那样Token消耗太大），而是需要通过session_search工具在需要的时候主动检索。

在对话中使用session_search：

你可以直接告诉Agent，让它帮你搜索：

回想一下，我们上次讨论数据库连接问题时的记录，找出解决方案。

使用session_search工具，在历史会话中搜索关键词“数据库连接失败”，然后告诉我结果。

Agent会用session_search工具执行查询，返回匹配的历史片段，并由LLM进行摘要。

用户侧斜杠命令：

在对话中直接使用/search <关键词>即可触发历史搜索-1。例如：

• /search 数据库连接：在所有历史会话中搜索“数据库连接”
• /search 报价单：搜索包含“报价单”的历史对话

典型使用场景：

• 找回几周前讨论过的配置参数
• 查询之前处理过的类似问题解决方案
• 追溯某个技术决策的决策过程和历史背景

9.3.3 FTS5检索引擎的优势

Hermes选择FTS5作为检索引擎，带来了三个方面的优势：

优势	说明
毫秒级检索	倒排索引结构支持TB级上下文数据的毫秒级检索
语义压缩	用LLM自动概括历史摘要，压缩存储的同时保留关键信息
结构化与非结构化混合存储	支持结构化与非结构化数据的混合存储-

检索链路：当Agent执行session_search时，Hermes会从state.db中的FTS5虚拟表检索匹配的历史片段，再用LLM将这些片段压缩成摘要，最终与当前对话上下文一起提交给模型。

9.3.4 会话数据的存储与管理

通过CLI可以查看和管理会话：

bash

# 查看所有会话
hermes session list

# 查看特定会话详情
hermes session info --id <session-id>

在对话中也可直接使用斜杠命令：

• /session list：列出所有历史会话
• /session delete <ID>：删除指定会话

9.3.5 一个完整的检索示例

假设你两周前曾向Hermes咨询过关于数据库连接配置的问题。今天的对话中，你问：

“我之前提到的数据库连接字符串是什么？”

Agent的逻辑：

1. 识别这是一个历史查询。
2. 调用session_search工具，使用“数据库连接”作为检索词。
3. FTS5从state.db中快速定位包含相关关键词的历史片段。
4. LLM将检索到的片段压缩成摘要，提取连接字符串。
5. Agent返回答案：“你上次设置的PostgreSQL连接是postgresql://user:pass@localhost:5432/mydb。”

由于历史记录没有被全量加载，当前上下文Token消耗极小，只有被检索回来的摘要片段。

⚠️ 常见误区：

• 误以为会话历史会自动加载——事实是必须通过session_search或/search命令主动调用。
• 误以为删除会话文件会释放特殊资源——FTS5索引会同步删除，不会无限膨胀。
• 误以为FTS5“永久存储不会遗忘”——它存在可配置的保留周期，并非无限保留。

龙马注：session_search确实是Hermes唯一让你随时“翻自己聊天记录”的工具。但它只在Agent主动调用时才会生效，你想要它做任何历史关联，都需要明确让它调用。在Agent的提示词层面，除非特别要求，否则不会在每轮对话前自动运行session_search。

沈飞注：在量化场景中，session_search的跨会话能力是我的复盘神器。我经常用一句话让Hermes找出上次用什么参数跑的“沪深300轮动策略”。但前提是，之前在策略报告中让Agent显式记录过。你聊天记录里没提过的内容，永远搜不出来。

✏️ 即时自测：session_search检索的历史内容会自动进入当前会话的系统提示词吗？

🛠️ 实践任务（本节）：

1. 与Hermes进行几轮关于某个话题的对话（如“Python虚拟环境配置”）。
2. 结束当前会话，启动一个新会话。
3. 在新会话中使用/search命令搜索关键词，观察Hermes是否成功检索到了历史内容。
4. 也可打开state.db文件，用SQLite客户端查看sessions和transcripts表的结构。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

✏️ 自测答案：不会自动进入系统提示词，需要通过session_search工具或/search命令主动检索后才能将摘要加载到上下文中。

9.4 第三层：技能记忆——可复用的工作流

🎯 本节目标：理解Hermes如何将成功经验固化为可复用的技能记忆，实现“越用越聪明”。

预计时长：0.5小时

9.4.1 什么是技能记忆？

MEMORY.md存“是什么”（事实），session_search找“聊过什么”（对话），技能记忆存“怎么做”（方法论）。

当Hermes完成一个复杂任务后，它会自动将解决方案提炼为结构化的SKILL.md文件，存储到~/.hermes/skills/目录中。

skills.md遵循agentskills.io开放标准，与Claude Code、OpenClaw等工具编写的技能可以无缝迁移。Hermes的预置技能数量根据安装版本而变化，通常约40+个内置技能。

9.4.2 技能记忆的自动生成与自改进

当任务使用了5次以上工具调用，或从某个错误中恢复，或走通了一条不那么直观的有效流程时，Hermes会自动将执行轨迹蒸馏为SKILL.md。

随着Hermes积累的技能越来越多，它的“专业度”会越来越高。甚至可能出现多个技能之间相互组合使用，大幅提升工作效率的现象。

技能记忆的核心优势：

• 一次学会，重复使用：不用每次遇到同类问题都重新试错。
• 跨会话可用：技能是持久化文档，不受会话结束影响。
• 同行评议机制：多个Agent可以就技能质量进行同行评议，累积经验。
• 可分享：遵循开放标准，可导出分享给其他工具使用。

9.4.3 与OpenClaw技能的区别

维度	Hermes技能	OpenClaw技能
生成方式	任务过程中自动生成	手动编写或从社区安装
存储位置	~/.hermes/skills/	工作区skills/目录
触发方式	任务匹配时自动加载	需在AGENTS.md中声明
进化能力	在使用中自动改进（同行评议）	基本由人工更新

9.4.4 如何用好技能记忆

技能记忆是Hermes“越用越聪明”能力的核心载体。但自动生成的技能也可能出错或不完整，建议定期用hermes skills list浏览已生成的技能清单，必要时可以手动编辑SKILL.md文件来完善。手动编辑时请确保保持agentskills.io标准格式。

用户侧命令：

• /skill list：列出所有可用技能-1
• /skill enable <技能名>：启用指定技能-1
• /skill disable <技能名>：禁用指定技能-1

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

9.5 外部记忆提供商（可选扩展）

🎯 本节目标：了解Hermes支持的7种外部记忆提供商，知道何时需要考虑接入外部记忆。

预计时长：0.2小时

学习提示：本节内容为可选扩展。对于大多数个人使用场景，内置的三层记忆已经足够。建议先熟练掌握内置记忆后再考虑外部提供商。

9.5.1 什么是外部记忆提供商？

你可以将外部记忆提供商理解为“知识库里的外置硬盘”。内置记忆适合存储高频、小容量的核心信息，外部记忆提供商能提供结构化抽取、实体识别和更强大的跨会话持久化能力——它能帮你自动从对话中提取关键信息存入向量搜索库。

Hermes的内存层（MEMORY.md/USER.md）在任何外部提供商启用时都保持运行，不会随provider变化而开关。也就是说，外置存储器提供的检索信息不会覆盖你的系统核心记忆，两者协同运行。

9.5.2 全部7种外部记忆提供商速览

Hermes Agent目前支持7种外部记忆提供商，可通过一条命令hermes memory setup打开选择器并安装-10。以下是对所有7种选项的对比：

提供商	存储方式	独特方法	适用场景
Hindsight	本地PostgreSQL或云端	知识图谱，唯一支持reflect跨记忆洞察，BEAM基准91.4%（Gemini-3）	企业级结构化记忆，最高检索精度
Mem0	云端	零延迟预取，自动事实提取，LongMemEval-S得分67.6%	需要智能语义检索
Honcho	云端（开源版可自托管）	辩证用户建模双存档系统，推断未明说偏好	深度个性化，长期跟踪
Holographic	本地SQLite	HRR代数+信任评分，零依赖	完全本地化，无需外部服务
OpenViking	自托管	L0/L1/L2分级加载，节省80-90% Token	希望自托管降低长期成本
ByteRover	本地或云端	人类可读的知识树（Markdown层级）	需要透明的知识管理
RetainDB	云端付费	混合搜索：向量+BM25+重排序	需要最高召回质量

关键说明：外部提供商只能同时激活一个，不能同时启用两个外部记忆provider。官方建议内外结合：内置记忆保持稳定，外部只选一个主力provider。

9.5.3 重点关注：Hindsight

Hindsight是目前唯一采用知识图谱结构的记忆提供商——它不是存储纯文本语义块，而是抽取离散事实（“生产数据库在5433端口”）、命名实体（人、服务、项目）以及它们之间的关系（“认证服务依赖Redis会话”）。这种设计带来极高的检索精度：询问某个特定服务时，Hindsight返回关于该服务的事实，而不是提到它的语义块。

Hindsight独有的reflect操作是一个亮点——定期跨所有记忆综合扫描，推导更高层次的洞察并合并相关事实。其他提供商只是积累原始提取，Hindsight主动优化自己的知识。

BEAM行业基准成绩：Hindsight在LongMemEval（智能体记忆标准基准）上，Gemini-3得分为91.4%，开源120B模型得分为89.0%——在所有测试提供商中最高，且无需发送数据到云端API。

存储方式：默认使用本地PostgreSQL守护进程（无需云账号），Hindsight Cloud可用于跨机器或团队的共享记忆。

工具集：当Hindsight激活时，Agent获得hindsight_recall、hindsight_retain、hindsight_reflect三个工具。

9.5.4 重点关注：Mem0

Mem0是另一个主流选择，采用智能开源记忆层设计——自动提取事实，无需手动告知。Mem0在对话中的工作节奏是：每次LLM响应后，后台自动将(用户消息, 回复)对发送给Mem0，云端LLM自动提取事实；同时后台预取下一轮的记忆，实现零延迟注入。

Mem0 Agent工具：

• mem0_profile：获取用户的所有存储记忆
• mem0_search：语义搜索（支持rerank重排序和top_k过滤）
• mem0_conclude：原样存储事实（无服务器端提取）

可靠性机制：（官方认证）内置断路器——Mem0 API连续失败5次后，Hermes停止调用2分钟，之后重试，Agent在此期间照常工作。

配置步骤：

bash

hermes memory setup
# 选择 mem0，按提示输入API Key

9.5.5 重要风险提示：Provider注入失控

自己动手注入Provider可能存在风险。外部插件加载失败时，框架底层不仅无法优雅捕获，还会将半初始化的“脏实例”或占位符强行残留在内存路由表中-。主要风险包括：

• 外部插件加载失败可能导致核心Agent进程损坏：若网络、依赖、配置等触发异常，错误不可控可能留下Dirty Instance导致进程崩溃，无法优雅回退-。
• 事务原子性缺失：register_provider先占位再实例化，加载失败时_active_routes中的脏占位符未能去除，对后续所有记忆操作造成污染。
• 升级与维护成本高：自行改造的代码与主分支强耦合，新版本发布后需不断维护补丁。
• 最大压力测试：即使官方经认证的提供商也需长期社区验证，建议在升级前做充分回滚预案。

9.5.6 外部记忆体系的价值

最好的总结是：外部 Provider 自动捕捉全部对话，Agent 全量记录再筛选，并且多维度审计持续分析历史对话质量，长期逐步提升记忆召回质量。内置的 MEMORY 有两个问题：一是只有 Hermes 自己觉得重要才往里写，二是有硬上限，大概 2200 字符就满了。外部提供商能彻底打破这个瓶颈。

何时需要外部记忆提供商？

• 对实时跨会话检索有较高要求。
• 内置记忆的容量限制（约3,575字符）不够用。
• 需要更智能的实体识别和关系抽取（如多跳推理）。
• 希望完全自动化，不依赖Agent的自主筛选判断。
• Honcho等组件支持额外的悖论分析：不仅记录用户明说的偏好，还能推断未明说的倾向甚至言行不一致之处，构建更深入的用户画像。

沈飞注：外部记忆提供商是量化场景的“外置硬盘”——当你需要对所有市场分析对话做跨度几个月的语义召回时，MEMORY.md和USER.md的上限很快就被撑爆了。Hindsight的reflect操作非常适合定期的策略复盘，每周跑一次主动分析过去所有策略对话记录的关系变更和因果链，很有实用性。

🛠️ 实践任务（本节）：（可选）运行hermes memory setup浏览外部提供商选项，但不做实际配置。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

9.6 记忆的删除与维护

🎯 本节目标：掌握删除三类记忆的完整方法，了解容量超限时的多种解决方案，学会主动管理记忆而非被动等待溢出。

预计时长：0.5小时

在长期使用Hermes记忆系统的过程中，记忆的删除和维护是保持记忆“清洁高效”的关键。本节将详细介绍如何删除三类记忆、应对容量超限问题，以及容量管理的完整方案。

9.6.1 为什么要删除记忆？

删除记忆不仅在容量紧张时用于腾出空间，也帮助管理系统效率、隐私和准确性。具体包括：

• 纠正错误信息：先前自动记录的错误记忆需要被修正或删除，避免被再次检索使用。
• 腾出容量空间：MEMORY.md和USER.md有严格的容量上限，删除冗余旧信息可为新知识腾出空间-。
• 保护隐私数据：对话历史中涉及的敏感API密钥或个人身份信息应被及时清除。

9.6.2 如何删除不同类型的记忆？

一、删除持久记忆（MEMORY.md / USER.md 中的条目）

方法1：通过memory工具删除（推荐）

python

# 删除MEMORY.md中包含"旧的项目信息"的条目
memory(action="remove", target="memory", old_text="旧的项目信息")

# 删除USER.md中的特定偏好
memory(action="remove", target="user", old_text="喜欢冗长回答")

remove操作使用子字符串匹配，不需要完整文本。

方法2：通过斜杠命令删除

在对话中直接使用：

/memory remove 旧的项目信息

/memory remove <内容>会删除包含指定内容的记忆条目。

/memory         # 查看当前记忆摘要

方法3：手动编辑文件

bash

nano ~/.hermes/memories/MEMORY.md
# 或
nano ~/.hermes/memories/USER.md

手动删除对应行，保存退出。

⚠️ 重要提示：记忆更改会立即持久化到磁盘，但当前会话由于“冻结快照”机制看不到变化——删除效果要在下个新会话中才会体现在系统提示中。

二、删除会话历史（FTS5索引中的对话记录）

删除整个会话：

bash

# 删除指定会话（通过会话ID）
hermes session delete --id <session-id>

在对话中也可使用斜杠命令：

/session delete <ID>

删除指定会话。

清理过期会话：

Hermes未提供直接按天数删除的命令，但可以通过以下方式管理：

bash

# 列出所有会话，手动识别并删除过期会话
hermes session list
# 记录需要删除的会话ID，逐一执行删除

龙马注：如果想定期清理会话，可以考虑写一个简单的脚本读取state.db中会话的时间戳，结合hermes session delete批量操作。

执行删除后FTS5索引同步更新，历史不再可检索。

彻底清空所有数据（慎用） ：

bash

# 删除所有配置、记忆、模型设置
rm -rf ~/.hermes/

此方式直接删除全部用户数据目录，确保无残留配置干扰，适用于需要彻底清空记忆的场景-。

三、删除技能记忆（SKILL.md）

方法1：手动删除文件

bash

rm ~/.hermes/skills/<skill-name>.md

方法2：通过CLI删除

bash

hermes skill remove <skill-name>

方法3：在对话中禁用/管理

text

/skill disable <技能名>   # 禁用技能但不删除文件
/skill list               # 查看所有可用技能

9.6.3 容量限制与完整管理方案

9.6.3.1 容量上限速查

存储	限制	典型条目数
MEMORY.md	2,200 字符（约800 tokens）	8-15 条
USER.md	1,375 字符（约500 tokens）	5-10 条
SQLite会话库	可存储百万级记忆条目	理论上无硬限制

注意：MEMORY.md和USER.md的容量上限是硬限制。如果新记忆写入时文件已满，写入操作直接失败，提示先删除或合并旧条目，而非静默丢弃-11。SQLite会话库则为按需检索，无需手动清理，但可通过hermes session delete进行过期清理。

9.6.3.2 容量超限的四种解决方案

当MEMORY.md达到约2,200字符上限，导致新记忆无法写入或上下文检索失效时，可通过以下方式解决：

方案一：手动清理低价值记忆项

直接编辑记忆源文件，人工识别并删除陈旧、重复或泛化程度高的条目：

bash

nano ~/.hermes/MEMORY.md
# 逐段扫描，删除以下类型的记忆：
# - 无具体项目名称的条目
# - 未包含用户明确偏好的条目
# - 超过3个会话未被检索引用的条目
# - 内容为通用知识而非个人事实的条目

保存退出后，运行hermes memory compact触发索引重建。

方案二：启用自动记忆筛选与压缩

bash

# 启动自动压缩流程
hermes memory prune --aggressive
# 等待终端输出 "Pruned X entries, retained Y" 提示
# 验证剩余字符数
wc -c ~/.hermes/MEMORY.md   # 确认结果小于2200

此命令启动全文重评估流程，使LLM依据当前知识图谱对全部现有记忆进行重要性重打分，并剔除评分低于阈值的条目。

方案三：拆分记忆为多文件结构

当用户记忆体量持续增长且高频涉及多个独立领域时，可绕开单文件限制：

bash

# 新建分类文件
touch ~/.hermes/MEMORY-work.md
touch ~/.hermes/MEMORY-life.md

# 将原 MEMORY.md 中对应内容剪切至新文件，保留原始格式与时间戳
# 删除原文件首行声明注释（含“# MEMORY.md —— auto-managed”字样），避免被覆盖
# 重启 Hermes 进程使新文件纳入索引范围

Hermes的FTS5检索机制兼容多文件结构，系统仍可统一检索这些分散的记忆文件。

方案四：调整记忆写入策略降低增量压力

通过修改配置禁止非关键对话自动生成记忆，从源头减少字符增长速率：

bash

nano ~/.hermes/config.yaml
# 在 memory: 区块下添加字段：
memory:
  auto_save_threshold: 0.85

该数值表示LLM对记忆价值的置信度阈值，仅当评估得分 ≥ 0.85 时才写入，有效过滤中低信息量陈述-31。

💭 本节总结（不看书写3行）：

📊 用时记录：计划____min → 实际____min → 偏差原因：________

9.7 🚀 进阶：外接数据库管理记忆

🎯 本节目标：了解外接数据库管理记忆的正规方式——外部记忆提供商，掌握Hindsight和Mem0的配置方法，理解自行改造的风险。

预计时长：0.5小时

许多用户在记忆积累到一定量后，会问“能否把记忆放到外部MySQL/PostgreSQL里统一管理”。答案是可以实现，但并非Hermes内置的原生功能，属于系统工程级的改造。

9.7.1 为什么会有这个疑问？

内置记忆有两个问题：一是只有Hermes自己觉得重要才往里写，二是有硬上限，大约2,200字符就满了。跨会话稍多一点就容易丢失-。外接数据库的需求由此而来。

9.7.2 使用外部数据库的正规方式：第三方记忆提供商

Hermes官方为高级用户提供了通过外部记忆提供商进行超越SQLite能力扩展的方案。这不是新功能——Hermes于2026年4月初发布了可插拔的记忆提供商系统，从根本上改变了外部记忆的工作方式。社区评价中，“只要开启外部提供商，就能抓住关键信息”是用户迁移到Provider的核心动机。

9.7.3 Hindsight配置详解

Hindsight是Vectorize.io开源的记忆服务，可以为AI Agent提供长期记忆能力，支持自动记忆提取和存储、语义搜索召回，以及与Hermes Agent的无缝集成。

配置步骤：

bash

# 1. 启动 Hermes 记忆设置向导
hermes memory setup

# 2. 选择 Hindsight
# 3. 如需使用云端版，在 .env 中设置 HINDSIGHT_API_KEY
# 4. 本地版无需 API Key，使用本地 PostgreSQL 守护进程

相关工具：

工具	功能
hindsight_recall	按需检索记忆
hindsight_retain	主动存储记忆
hindsight_reflect	跨所有记忆综合扫描，推导高层次洞察

Hindsight Cloud：用于跨机器或团队的共享记忆，需注册获取API Key-。存储后端默认使用本地PostgreSQL，无需云账号。

龙马注：Hindsight 的reflect操作是目前7个Provider中唯一具备的跨记忆洞察能力。对我来说更有价值的是这条设计路线，每周跑一次，系统自动生成“过去7天内我对哪些领域的记忆最活跃”这样的洞察报告，自己不用写额外脚本。

9.7.4 Mem0配置详解

Mem0是一个智能开源记忆层，专为LLM设计，支持跨会话的上下文感知交互。

配置步骤：

bash

# 1. 启动 Hermes 记忆设置向导
hermes memory setup

# 2. 选择 mem0
# 3. 输入你的 Mem0 API Key（可从 app.mem0.ai 获取）
# 4. 配置文件写入 ~/.hermes/mem0.json

Mem0 Agent工具：

工具	功能
mem0_profile	获取用户的所有存储记忆
mem0_search	语义搜索（支持rerank重排序和top_k过滤）
mem0_conclude	原样存储事实（无服务器端提取）

手动配置（可选）：

bash

hermes config set memory.provider mem0
echo "MEM0_API_KEY=your-api-key" >> ~/.hermes/.env

配置项存储在~/.hermes/mem0.json，支持通过环境变量覆盖。

可靠性机制（断路器） ：Mem0 API连续失败5次后，Hermes停止调用2分钟，之后重试，Agent在此期间照常工作——无需担心API问题导致Agent停摆。

9.7.5 自行改造与官方Provider的抉择

很多人一遇到记忆瓶颈，第一反应是想直接改Hermes内核接入MySQL。请克制这个念头。

• 外部Provider是最佳实践：官方7种Provider覆盖了本地SQLite、PostgreSQL、云端向量库等场景，比自研方案成熟得多。
• 第三方Provider已在社区长期验证：有完整的工具链、文档和社区经验，很多踩坑记录可以帮其他用户绕过问题。
• 社区积极维护：外部Provider长期得到社区贡献者和用户的推敲，任何一个Provider的质量和可靠性都在不断被验证。你的自研方案要在安全性、更新兼容性和背后社区支持上达到同等成熟度，成本极高。
• 唯一合理的MySQL/PostgreSQL途径：走官方Hindsight Provider，它默认就是用本地PostgreSQL作为存储后端——相当于绕过了“外接MySQL”的工程难题，配置即用-。

沈飞注：我的量化部署经验中，Hindsight 的本地 PostgreSQL 后端性能和完全离线特性最契合风控要求。云端 Provider 无论多稳定都多了一条外部调用链路，排错时多了一层变数。本地 Hindsight 一旦配好，那就是你的“本地知识库”，所有策略对话都存储在自己的数据库里，完全可控。

第9章 参考资料与扩展阅读

1. Hermes Agent Memory Providers: All 7 Options Compared https://vectorize.io/articles/hermes-agent-memory-providers-compared
2. How Hermes Agent Memory Actually Works (And How to Make It Better) https://vectorize.io/articles/hermes-agent-memory-explained
3. Hermes Agent 记忆系统详解：MEMORY.md 与跨会话持久化
   https://www.e-com-net.com/article/2047235061903843328.htm
4. How to Add Memory to Your Hermes Agent – Mem0 Official https://mem0.ai/blog/how-to-add-memory-to-your-hermes-agent
5. Hermes Agent – Mem0 Integration Docs https://mem0.mintlify.app/integrations/hermes
6. 一颗老鼠屎坏了一锅汤：慎用 MemoryManager 的外部 Provider 注入 https://blog.gitcode.com/2026/04/16/hermes-memory-manager-warning
7. Hermes Agent 斜杠命令中文对照表 https://www.cnblogs.com/yih/p/19897952
8. HermesAgent记忆字符限制超限的解决办法 https://www.php.cn/faq/2362258.html
9. Hindsight本地安装部署完整记录 https://zengwu.com.cn/archives/hindsight-local-install.html
10. Hermes Agent Context机制详解——从上下文溢出的真实场景重新理解记忆分层 https://blog.csdn.net/weixin_53039099/article/details/160734262

本篇综合实践（第9章完成后）

任务：完成以下所有检查项，并记录输出。

🔰 强制任务（1小时，必须完成）

• 检查~/.hermes/memories/目录，确认MEMORY.md和USER.md存在
• 在MEMORY.md中写入至少3条你常用的项目配置或工具信息
• 在USER.md中写入至少3条你的工作偏好或沟通习惯
• 启动新会话，验证Hermes能正确回答关于这些记忆的问题
• 使用hermes doctor --check memory验证记忆加载状态
• 在会话中使用/memory add添加一条记忆，然后用/memory查看摘要，最后用/memory remove删除它

🚀 进阶任务（1小时，推荐完成）

• 与Hermes进行一个多轮对话，涉及具体的项目配置或技术决策
• 结束会话后启动新会话，使用/search命令让Hermes回顾之前的讨论
• 让Hermes完成一个复杂任务，观察~/.hermes/skills/目录下是否自动生成SKILL.md
• 使用hermes skills list查看已生成的技能列表
• 手动删除一个不再需要的记忆条目（任选一种方法）
• （可选）运行hermes memory prune --aggressive体验自动压缩
• （可选）运行hermes memory setup浏览外部记忆提供商选项

完成后，保存一份记忆状态快照，命名为chapter9_memory_snapshot.txt，至少包含：

• ls -la ~/.hermes/memories/ 的输出
• hermes doctor --check memory 的输出
• MEMORY.md和USER.md的核心条目（可以脱敏）
• 你遇到的记忆问题的解决记录（如有）

龙马的评审：

“9.2节的冻结快照机制在我第一次接触Hermes记忆系统时让我困惑很久：你让Agent记住了一件事，它也答应你说‘记住了’，但你继续问，它还是不知道。这不是它没记住，是当前会话的‘记忆快照’已经在启动时固定了。为了教学效果的直观性，建议：如果读者想即时验证记忆写入是否成功，与其在当前会话里反复提问，不如直接查看磁盘上MEMORY.md文件的内容，确认写入记录是否真实存在。

另外补充，容量限制是硬性的。当文件写满时，memory工具会返回错误，Agent必须先合并或删除一些条目才能继续写入。这期间可能会丢掉一些有效信息——但原则上丢掉的是最低价值的部分。”

“关于9.6节的删除操作，memory(action="remove", ...)是用自然语言表达的Agent动作示例，不是直接在终端可执行的命令格式。读者如果需要在终端直接删除，请改用/memory remove <内容>斜杠命令，或手动编辑~/.hermes/memories/下的文件。

在对话中用/memory remove要注意：必须提供与记忆条目中完全一致的关键词片段才能匹配上。如果删除失败，先/memory查看当前记忆内容，确认关键词无误。”

沈飞的评审：

“MEMORY.md和USER.md这两个文件的职责划分在量化场景中需要仔细设计。我的配置里，MEMORY.md放的是回测框架的版本、常用数据源的endpoint密码占位符、风险模型的参数说明。USER.md放的是我自己的量化偏好，比如‘除非明确要求，否则不加杠杆’‘胜率高于55%才值得执行策略’等风控指令。

最关键的是，我会在USER.md中加入一条硬性规则：‘任何关于风控参数修改的请求必须通过Audit Agent审批’。这条规则现在是被Agent理解和记忆的。这是量化系统里Agent自主行为约束的底线。

session_search的能力在量化场景中体现为‘策略复盘’。如果你每天收盘时都能让Hermes总结当日信号单的发出逻辑，和实盘交易日志做对比，这种习惯远比一两天的盈亏本身更有价值，值得长期坚持。”

下一章预告：第10章 Hermes Skill系统：自动生成的进化能力——你将深入理解Hermes的自动技能生成机制，学会质量治理和生命周期管理，并对比Hermes Skill与OpenClaw Skill的核心差异。这是第七章“闭环学习系统”的延续，让Hero从“学得更快”变为“干得更快”。