第七册：三层记忆系统详解
本章你将学到
- 为什么记忆系统是 Hermes Agent 区别于普通聊天机器人的核心竞争力
- Hermes 独创的「四层温度记忆模型」是如何工作的
- 会话记忆（热记忆）的 Token 管理策略和 /compact 命令的使用技巧
- 持久记忆（温记忆）中 MEMORY.md 和 USER.md 的详细配置方法
- 检索记忆（冷记忆）的 SQLite + FTS5 架构和智能检索机制
- Honcho、Mem0 等外部记忆扩展方案的集成方法
- SOUL.md 深度配置模板和隐私安全最佳实践
- 记忆系统的日常维护、排障和高级调优技巧
1. 为什么记忆系统是 Hermes 的核心竞争力
1.1 Agent 没有记忆会怎样——上下文爆炸的痛苦
想象一下，你请了一位秘书，但这位秘书有个致命缺陷：每次你跟他讲完一件事，他转身就忘得一干二净。你不得不把同样的话重复说一百遍。更糟糕的是，这位秘书的脑袋（上下文窗口）还很小，塞不下太多信息。当你交代一个稍微复杂点的任务时，他前面记住的内容就会被后面的内容挤掉，就像往一个装满水的杯子里继续倒水，旧的记忆不断溢出来。
这就是没有记忆系统的 AI Agent 的真实写照。
让我们看一个具体的例子。假设你要让 Agent 帮你做一个「季度投研报告」，这个任务需要：
- 先搜索某行业的最新新闻（10条结果）
- 用 Python 分析这些新闻的情感倾向
- 结合财务数据生成图表
- 把图表插入到报告模板中
- 输出最终的 PDF 文件
如果没有记忆系统，会发生什么呢？
当你在第3步说「用刚才爬取的数据做分析」时，Agent 可能会一脸茫然地问：「什么数据？我刚才没保存任何数据啊。」因为它在前两步的工具调用结果，如果没有被妥善记录到上下文中，就会像写在沙滩上的字一样被潮水冲走。
即使你的大模型有 128K 的上下文窗口（相当于能记住约 10 万字的文本），在长时间、多步骤的复杂任务中，Token 消耗也会像滚雪球一样越滚越大。每一次工具调用的结果、每一条系统提示、每一个中间变量，都在无情地吞噬着有限的上下文空间。当上下文接近上限时，模型要么开始「失忆」（遗忘早期信息），要么响应速度急剧下降，要么干脆报错退出。
这种「上下文爆炸」的痛苦，是每个深度使用 AI Agent 的用户都经历过的。它直接限制了 Agent 能够处理任务的复杂度，也严重影响了用户体验的连贯性。
注意
很多新手会误以为「上下文窗口越大越好」。确实，从 4K 到 128K 甚至 200K 的窗口扩展，让单次对话能处理的信息量变大了。但窗口大不等于记忆好——它只是「短期记忆」的容量变大了。如果没有智能的记忆管理系统，再大的窗口也会在复杂任务中被填满，而且成本会呈指数级增长。
1.2 传统 Agent 的记忆方案及其局限
在 Hermes 出现之前，开源社区对 Agent 记忆问题的解决方案大致可以分为以下几类：
方案一：纯上下文记忆（即无记忆方案）
这是最原始的方式，也是很多早期 Agent 框架（如最初的 AutoGPT）采用的方式。所有信息都依赖大模型的上下文窗口来承载。优点是简单直接，缺点是前面已经详细描述过了——上下文爆炸、Token 成本高、无法跨会话保留信息。
方案二：向量数据库（Vector DB）记忆
这是目前最主流的方案，包括使用 Pinecone、Weaviate、Milvus、Chroma 等向量数据库来存储和检索记忆。工作原理是将文本转为向量（Embedding），通过向量相似度来检索相关内容。
这种方案的问题在于：
- 检索精度依赖 Embedding 质量：如果向量模型不能准确理解语义，检索结果就会偏差很大。比如用户说「上次我提到的那个项目」，Agent 可能检索到完全不相关的内容。
- 无法精确匹配关键词：向量相似度擅长找「意思相近」的内容，但不擅长找「包含某个确切词语」的内容。如果你说「把上次生成的那个叫『报表_v2』的文件发给我」，向量检索很可能找不到精确匹配。
- 冷启动问题：新数据刚写入向量数据库时，检索效果往往不好，需要积累一定量数据后才能发挥作用。
- 运维成本高：需要额外部署和维护向量数据库服务，增加了系统复杂度。
方案三：简单的文件持久化
一些轻量级方案会把重要信息写入本地文件（如 JSON、TXT），下次启动时读取。这种方式虽然实现了跨会话记忆，但缺乏智能的检索和筛选机制——要么一次性加载所有内容（可能文件很大），要么只能按固定规则读取（不够灵活）。
方案四：外部记忆服务
如 Mem0、Zep 等专门的记忆服务。它们通常提供云端 API，负责记忆的存储、检索和更新。这种方案的问题是：
- 数据离开本地：敏感信息需要上传到第三方服务器
- 网络依赖：没有网络就无法工作
- 额外成本：大多数服务需要付费使用
- 延迟较高：每次记忆操作都需要网络请求
1.3 Hermes 记忆系统的设计哲学：让 AI 像人一样记忆
Hermes 的设计团队在研究了大量用户反馈和现有方案的局限后，提出了一个核心问题：人类是怎么记忆的？
与很多 Agent 框架追求「无限记忆」不同，Hermes 走了一条截然相反的路——有界记忆（Bounded Memory）。官方的设计理念非常明确：无限记忆听起来诱人，但会让 Agent 变成一个「垃圾杂物抽屉」，什么都往里塞，最后连自己有什么都记不住。Hermes 强制整合：当 MEMORY.md 满时，Agent 必须主动决定什么值得保留、什么应该丢弃。这种「纪律」保持了工作上下文的精简，让模型始终专注在真正重要的事情上。
正如 Hermes Atlas 官方文档所说：「Claude Code 的 memory 存储关于你的事实——偏好要点。而 Hermes 存储的是程序——产生你想要的要点的研究-过滤-格式化工作流。事实告知模型，程序直接被复用。」这句话精准地概括了 Hermes 记忆系统的本质：它不仅记住「是什么」，更记住「怎么做」。
人类记忆系统不是单一的结构，而是由多个层次组成的精妙体系：
- 工作记忆（短期记忆）：你正在思考的事情，容量极小（约 4-7 个信息单元），但访问速度极快。
- 情景记忆（中期记忆）：最近发生的事情，比如今天早上吃了什么、昨天和谁聊了天。容量中等，需要主动回忆才能提取。
- 语义记忆（长期记忆）：你学会的知识和技能，比如知道 2+2=4、知道北京是中国的首都。容量几乎无限，但需要线索才能激活相关部分。
- 外部记忆：你写在笔记本上的备忘、存在电脑里的文档、书架上的书籍。容量不受限，但需要主动查找。
Hermes 的记忆系统正是借鉴了这种分层架构，创造了「四层温度记忆模型」。它的设计哲学可以总结为三条核心原则：
原则一：分层存储，各尽其用
不同温度（时效性）的记忆，存放在不同层级的存储介质中。热数据放在内存中快速访问，温数据放在文件中持久保存，冷数据放在数据库中按需检索。就像你不会把全家老小的照片都贴在工作电脑的桌面上，而是会分类存放在不同的位置。
原则二：按需加载，而非全量加载
传统方案最大的问题之一是「启动时加载所有记忆」。想象一下，你每天早上上班，秘书都要把过去十年的所有会议记录、邮件往来、项目文档都摆在你面前——这不仅浪费你的时间，还会让你被海量信息淹没，找不到真正需要的东西。
Hermes 采用的是「按需检索」策略：Agent 在新对话开始时，不会加载全部历史记录，而是根据当前话题智能检索最相关的片段。这大大降低了 Token 消耗，也避免了信息过载。
原则三：纯本地优先，隐私至上
所有记忆数据默认存储在本地 SQLite 数据库和 Markdown 文件中。你的对话内容、行为习惯、个人偏好，都不会离开你的电脑。这对于处理敏感信息（如企业内网数据、个人隐私数据）至关重要。
1.4 三层记忆 vs 传统方案的优势对比
为了让你更直观地理解 Hermes 记忆系统的优势，我们来做一个横向对比：
| 对比维度 | 纯上下文记忆 | 向量数据库方案 | 简单文件持久化 | Hermes 四层记忆 |
|---|---|---|---|---|
| 跨会话记忆 | 无 | 有 | 有 | 有 |
| 检索精度 | 无检索 | 语义相似度 | 无检索 | FTS5 全文 + LLM 摘要 |
| 启动速度 | 快 | 中等 | 中等 | 快（按需加载） |
| Token 成本 | 极高 | 中等 | 低 | 极低（按需检索） |
| 本地隐私 | 有 | 依赖部署 | 有 | 完全本地 |
| 运维复杂度 | 低 | 高 | 低 | 低（SQLite 内置） |
| 用户画像 | 无 | 无 | 无 | 自动建模（USER.md） |
| 自我压缩 | 无 | 无 | 无 | /compact 智能压缩 |
| 外部扩展 | 无 | 有 | 无 | Honcho/Mem0/OpenViking |
从这个对比表中可以清楚地看到，Hermes 的四层记忆模型在几乎所有维度上都做到了优秀或良好，而且是一个开箱即用的「全家桶」方案——你不需要单独部署向量数据库、不需要写复杂的检索逻辑、不需要担心数据隐私，一切都内置在 Hermes 中，只需要简单的配置就能工作。
Tips
如果你是技术人员，可能会问：「向量检索在某些场景下确实很有用，Hermes 不支持吗？」答案是支持的！通过外部记忆扩展（如 Mem0），你可以无缝集成向量检索能力。但 Hermes 的默认方案选择 FTS5 全文索引作为主力检索引擎，是因为在大多数实际场景中，精确的关键词匹配比语义相似度更可靠、更可预测。
2. 总览：四层温度记忆模型
2.1 热记忆（即时）—— 当前会话上下文
热记忆是最「热」的记忆，就像你大脑中正在思考的内容一样，访问速度最快，但容量最小，而且会随着会话结束而消失。
在 Hermes 中，热记忆就是当前会话的上下文窗口。它包含了：
- 当前对话中你和 Agent 的所有消息
- 最近一次工具调用的结果
- 系统提示（System Prompt）和 SOUL.md 的内容
- 当前激活的 Skill 的上下文
热记忆的特点可以用三个词概括：快、小、暂存。
- 快：所有数据都在内存中，访问延迟几乎为零
- 小：受限于大模型的上下文窗口（通常是 4K-200K Tokens）
- 暂存：会话结束或 /compact 执行后，部分内容会被压缩或丢弃
2.2 温记忆（持久）—— MEMORY.md + USER.md
温记忆就像你写在便利贴上的重要提醒，或者是你手机备忘录里的关键信息。它们不像热记忆那样随时在眼前，但比翻查旧笔记本要快得多。
Hermes 的温记忆由两个核心文件组成：
MEMORY.md：存储与任务相关的持久化信息。比如：
- 「用户要求所有 Python 代码都使用 Type Hints」
- 「当前项目的 Git 仓库地址是 https://github.com/user/project」
- 「上次分析的那只股票代码是 600519」
USER.md：存储用户画像和行为模式。比如：
- 「用户喜欢用中文交流，但技术术语保留英文」
- 「用户在上午 9-11 点效率最高，适合安排复杂任务」
- 「用户对深度学习话题感兴趣，对区块链话题不感兴趣」
这两个文件都是纯文本的 Markdown 格式，存储在 Hermes 的配置目录中。它们的容量被严格限制（MEMORY.md 约 2200 字符，USER.md 约 1375 字符），这是经过精心设计的——如果文件太大，每次加载都会消耗大量 Token；如果太小，又无法记录足够有用的信息。
2.3 冷记忆（检索）—— SQLite + FTS5 + LLM 摘要
冷记忆就像你书架上排列整齐的档案柜，或者是电脑里分门别类的文件夹。里面存储了海量的历史信息，但你不会一次性把它们全部搬到桌面上，而是需要时去查找。
Hermes 的冷记忆系统由三个核心组件构成：
SQLite 数据库：轻量级的本地关系型数据库，存储所有的历史对话、工具调用结果、文件操作记录等。一个 SQLite 文件就是一个完整的数据库，不需要单独的服务进程。
FTS5 全文索引：SQLite 内置的全文搜索引擎。你可以把它理解为一个小型的「本地 Google」——输入关键词，它能瞬间从海量文本中找到包含这些词的记录。
LLM 摘要：利用大语言模型的能力，自动为每次会话生成简明扼要的摘要。这些摘要也会被索引到 FTS5 中，让你在搜索时能更快地定位到相关会话。
冷记忆的核心设计思想是「按需检索」。当你开启一个新会话时，Hermes 不会把过去一年的所有对话都加载到上下文中，而是：
- 分析你当前输入的内容，提取关键词
- 用 FTS5 在历史记录中检索相关片段
- 只把最相关的几条记录（通常 3-5 条）提取出来
- 将这些相关片段注入到当前上下文中
这种方式让 Agent 拥有了「回想」能力，同时又不会因为记忆太多而「大脑过载」。
2.4 外部记忆（扩展）—— Honcho、Mem0 等
外部记忆是四层模型的最外层，相当于你的个人图书馆、云端笔记、或者是请了一位专门帮你整理资料的研究助理。它们不是 Hermes 内置的，但可以通过插件或 API 无缝集成。
目前支持的外部记忆方案包括：
- Honcho：专门用于推导用户行为模式的记忆模块
- Mem0：强大的记忆管理平台，支持向量检索
- OpenViking：面向企业级场景的记忆扩展
- 以及更多社区开发的记忆插件
外部记忆的优势在于专业化和扩展性。比如 Honcho 在用户行为建模方面比 Hermes 内置的 USER.md 更深入；Mem0 在跨设备同步方面有独到之处。但它们的缺点是需要额外配置，且部分服务涉及数据外传。
2.5 各层的容量、速度、成本对比表
| 记忆层级 | 存储介质 | 典型容量 | 访问速度 | Token 成本 | 持久性 | 检索方式 |
|---|---|---|---|---|---|---|
| 热记忆 | 内存（上下文窗口） | 4K-200K Tokens | 毫秒级 | 高（全部计费） | 会话级 | 直接访问 |
| 温记忆 | 本地 Markdown 文件 | ~3.5K 字符 | 毫秒级 | 低（固定大小） | 永久 | 全量加载 |
| 冷记忆 | SQLite + FTS5 | 无上限 | 百毫秒级 | 极低（只加载相关片段） | 永久 | 全文检索 |
| 外部记忆 | 网络服务/外部 DB | 依赖服务 | 百毫秒-秒级 | 依赖服务 | 依赖服务 | 依赖服务 |
2.6 类比：就像人的短期记忆、长期记忆、笔记本、图书馆
为了让四层记忆模型更加直观，我用一个生活中的类比来总结：
想象一下你正在准备一个重要的演讲。
热记忆就像你此刻脑中正在构思的内容。你正在想「第一页 PPT 要讲团队介绍」，这个念头在你的意识中非常清晰，但如果你想别的事情，这个念头可能就会被挤掉。这就是工作记忆的容量限制。
温记忆就像你贴在显示器边缘的便利贴。上面写着「演讲时间：15分钟」「重点强调 Q3 业绩」「别忘提到新客户案例」。你不需要去翻笔记本，一眼就能看到。但如果便利贴太多，你反而会找不到重点，所以温记忆的容量被刻意限制了。
冷记忆就像你的笔记本和电脑文件夹。过去半年里，你做的每一次演讲、每一份报告、每一条客户反馈，都记录在里面。你不会在准备演讲时把过去半年的所有文件都摊开，而是会根据「这次演讲的主题」去搜索相关资料——找到其中 3-5 份最相关的文档，提取关键内容。
外部记忆就像你公司里的资料室，或者是国家图书馆。里面有海量的专业书籍、行业报告、历史档案。你需要的时候可以去查阅，获取更深入、更全面的信息。但去图书馆需要时间和交通成本，所以你通常先在笔记本里找，找不到再去图书馆。
常见问题
Q：为什么温记忆的容量这么小？只有几千字符？
A：这是经过深思熟虑的设计。温记忆（MEMORY.md + USER.md）每次会话都会完整加载到上下文中。如果它们太大，会挤占宝贵的上下文空间，导致热记忆可用容量减少。限制容量的另一个原因是「逼迫 Agent 做选择」——不是什么都记，而是只记最重要、最精炼的信息。这就像一个优秀的秘书，不会把你说的每句话都记下来，而是只记关键点。
3. 第一层：会话记忆（热记忆）
3.1 会话上下文的工作原理
会话记忆（热记忆）是 Hermes 记忆系统的最前线，也是你作为用户最直接感受到的部分。理解它的工作原理，能帮助你更高效地与 Agent 协作。
当你启动 Hermes 并开始一段对话时，系统会构建一个「上下文窗口」（Context Window）。这个窗口里装的不是简单的聊天记录，而是一个精心编排的「信息包」，按照固定的顺序排列：
[系统提示 / System Prompt]
↓
[SOUL.md 内容]
↓
[激活的 Skill 说明]
↓
[MEMORY.md 内容（温记忆注入）]
↓
[检索到的相关历史片段（冷记忆注入）]
↓
[当前对话历史]
↓
[用户的最新输入]
这个顺序是有讲究的。越靠前的内容，在模型处理时的「注意力权重」通常越高（具体取决于模型架构，但一般来说位置越靠前越不容易被遗忘）。所以 Hermes 把最重要的系统指令放在最前面，把动态的对话历史放在后面。
让我们看一个具体的例子。假设你正在使用 Hermes 分析一份财报，上下文窗口的内容可能如下（简化版）：
System: 你是一个专业的财务分析助手...
SOUL.md: [用户的个人偏好和角色设定]
Skill: financial_analysis v2.1 [激活的财务分析技能]
MEMORY.md: 用户关注白酒行业，上次分析的是贵州茅台(600519)
冷记忆片段: [上次对话中关于ROE分析的结论]
User: 帮我分析一下五粮液今年的三季报
Assistant: 好的，我来获取五粮液(000858)的最新三季报数据...
[工具调用结果：获取到的财务数据]
User: 和茅台对比一下毛利率
Assistant: [分析中...]
每次你发送新消息，或者 Agent 执行工具调用后，这个上下文窗口都会被更新。窗口里的内容越多，发送给大模型的 Token 数就越多，响应时间越长，成本也越高。
Tips
如果你使用的是按 Token 计费的商业模型（如 GPT-4、Claude），上下文窗口里的每一条信息都在计费范围内——包括系统提示、SOUL.md、MEMORY.md、历史对话。所以理解上下文构成，能帮助你优化成本。使用
hermes status命令可以查看当前会话的 Token 使用情况。
3.2 Token 窗口管理策略
Token 窗口管理是热记忆的核心挑战。想象你的上下文窗口是一个容量固定的背包（比如能装 1000 个 Tokens），每次对话都在往里面塞东西。当背包快满的时候，你该怎么办？
Hermes 采用了一套智能的 Token 管理策略，主要包含以下几个机制：
机制一：固定保留区 + 动态对话区
上下文窗口被划分为两个区域：
- 固定保留区：系统提示、SOUL.md、温记忆（MEMORY.md + USER.md）。这部分内容每次请求都必须包含，占用固定的 Token 预算。
- 动态对话区：实际的对话历史和工具调用结果。这部分是弹性变化的，当空间不足时需要被压缩或截断。
假设你使用的是一个 32K 上下文的模型：
总容量：32,000 Tokens
固定保留区：~2,000 Tokens（系统提示 + SOUL.md + 温记忆）
动态对话区可用：~30,000 Tokens
机制二：FIFO（先进先出）截断
当动态对话区超出容量时，Hermes 会采用「先进先出」的策略，截断最早的对话消息。也就是说，你最早说的话会被逐渐「遗忘」，最近的消息会被保留。
但这里有个重要的例外：工具调用和工具调用结果通常会被优先保留。因为它们是 Agent 实际执行任务的证据，如果丢失了，Agent 可能会重复执行已经做过的事情。
机制三：智能压缩（/compact）
这是 Hermes 最具特色的功能之一。当对话越来越长时，你可以主动执行 /compact 命令，让 Agent 对当前会话的内容进行智能压缩。具体过程如下：
- Agent 回顾整个对话历史
- 识别出关键信息（决策、结论、重要的中间结果）
- 用简洁的语言把这些关键信息总结成一段话
- 将总结替换掉原来的长对话，释放大量 Token 空间
- 把这次压缩的摘要存入 SQLite，方便以后检索
/compact 的效果通常非常显著。一个 50 轮对话、消耗 15,000 Tokens 的会话，经过压缩后可能只需要 500 Tokens 就能保留全部关键信息。
注意
/compact是一个「有损压缩」。它会丢弃对话中的细节（比如具体的思考过程、不重要的闲聊），只保留结论和关键决策。如果你需要保留完整的对话记录用于审计或复盘，建议在执行/compact之前先用hermes export导出会话。
3.3 /compact 命令：智能压缩上下文
/compact 是 Hermes 最强大的热记忆管理工具之一。让我们深入了解它的使用方法和内部逻辑。
基本用法：
在 Hermes 的交互界面中，任何时候你都可以输入：
/compactAgent 会立即开始压缩过程。你会看到类似这样的输出：
正在压缩会话上下文...
✓ 已识别 12 个关键决策点
✓ 已提取 5 条重要结论
✓ 已总结 3 个工具调用结果
压缩完成：15,420 Tokens → 486 Tokens（节省 96.8%）
摘要已保存至数据库，ID: conv_20260421_001
什么时候应该用 /compact？
| 场景 | 建议 |
|---|---|
| 对话已经超过 30 轮 | 强烈建议使用 |
| 工具调用超过 10 次 | 建议使用 |
| 上下文 Token 超过总容量的 70% | 必须使用 |
| 感觉 Agent 开始「遗忘」早期内容 | 立即使用 |
| 正在执行一个长期、多步骤的任务 | 每完成一个阶段就使用一次 |
| 对话即将结束，想保留关键信息 | 结束前使用 |
自动压缩配置：
你可以在 config.yaml 中设置自动压缩的触发条件：
# config.yaml 中的记忆相关配置
memory:
# 当上下文 Token 数超过此阈值时自动触发压缩
auto_compact_threshold: 12000
# 是否启用自动压缩
auto_compact_enabled: true
# 压缩时保留的最近消息数（这些消息不会被压缩）
preserve_recent_messages: 5常见问题
Q：/compact 会删除我的原始对话记录吗？
A：不会。
/compact只会影响当前加载到上下文窗口中的内容。完整的原始对话仍然保存在 SQLite 数据库中，你可以随时用hermes history查看完整记录。压缩只是让当前工作内存更精简。Q：压缩后 Agent 还能回答关于细节的问题吗？
A：如果细节在压缩过程中被丢弃了，Agent 就无法直接回答。但它可以通过检索冷记忆（SQLite 中的完整记录）来查找原始细节。你可以明确告诉它「去数据库里查一下详细记录」。
3.4 上下文溢出时的处理机制
当上下文窗口达到极限时，Hermes 有一套优雅的处理机制，确保系统不会崩溃，同时尽量保留最重要的信息。
溢出检测：
每次发送请求前，Hermes 会计算当前上下文的 Token 数。如果加上即将发送的消息后超过模型容量，就会触发溢出处理。
处理流程（按优先级）：
1. 检查是否可以使用 /compact
↓ 是 → 自动执行压缩
↓ 否（压缩后仍然溢出）→ 下一步
2. 截断动态对话区（FIFO）
- 从最早的对话开始删除
- 保留工具调用和结果
- 保留最近的 3-5 轮对话
↓ 仍然溢出 → 下一步
3. 缩减冷记忆注入
- 减少检索到的历史片段数量
- 缩短每个片段的长度
↓ 仍然溢出 → 下一步
4. 缩减温记忆注入
- 临时不加载 USER.md（只保留 MEMORY.md）
↓ 仍然溢出（极罕见）→ 下一步
5. 报错提示用户
- "当前会话上下文已达到极限，建议开启新会话"
这种分层降级策略确保了在绝大多数情况下，系统都能自动恢复，而不需要用户手动干预。
3.5 最佳实践：如何让单次会话效率最高
经过前面的讲解，你应该已经理解了热记忆的工作原理。下面是经过社区大量实践总结出的最佳实践：
实践一：定期使用 /compact
不要让对话无限增长。建议每完成一个任务阶段就压缩一次。就像你写完一个章节就保存一次文档一样，这是良好的工作习惯。
# 示例：一个多阶段任务中的压缩策略
User: 帮我分析一下 Q3 的财报数据
[Agent 执行分析...]
User: /compact # 第一阶段完成，压缩
User: 基于刚才的分析，生成一份 PPT 大纲
[Agent 生成大纲...]
User: /compact # 第二阶段完成，压缩
User: 把大纲导出为 Markdown 文件
[Agent 导出...]实践二：善用 MEMORY.md 记录跨会话信息
如果你知道某个信息在后续会话中还会用到，直接告诉 Agent 把它写入 MEMORY.md：
User: 把这个项目的 Git 地址记住：github.com/mycompany/project-alpha
Agent: 已记录到 MEMORY.md
User: 以后提到 "alpha 项目" 就是指这个仓库
Agent: 已更新 MEMORY.md这样下次会话开始时，Agent 就会自动知道这些信息，不需要你重复交代。
实践三：避免在单一会话中处理过多不相关的任务
如果你刚让 Agent 分析了财报，接下来想让它帮你写一封邮件，建议开启新会话。因为财报分析的上下文对写邮件没有帮助，反而会挤占 Token 空间。你可以这样：
# 不推荐：在同一个会话中混杂不相关任务
User: 分析财报...
[20轮对话后...]
User: 对了，帮我写封邮件给李总 # 浪费Token
# 推荐：任务切换时开启新会话
User: /new # 开启新会话
User: 帮我写封邮件给李总...实践四：明确指定需要保留的信息
在复杂任务中，如果你知道某些中间结果特别重要，可以明确告诉 Agent：
User: 这个 API 的认证令牌很重要，请把它记录到 MEMORY.md 中
Agent: 已记录：API认证令牌 = sk-abc123...
User: 刚才生成的那个 SQL 查询语句，摘要里一定要保留
Agent: 已将该 SQL 查询标记为重要，压缩时会优先保留实践五：关注 Token 使用情况
定期使用 hermes status 查看当前 Token 消耗：
$ hermes status
会话状态
========
会话ID: session_20260421_001
模型: claude-3-7-sonnet-20250219
上下文窗口: 32,000 Tokens
已使用: 18,450 Tokens (57.7%)
固定保留区: 2,100 Tokens
动态对话区: 16,350 Tokens
建议: 上下文使用率较高，建议在 80% 前执行 /compact当使用率超过 70% 时，就应该考虑压缩或结束当前任务了。
Tips
很多用户有个误区：认为「单轮对话越长越好」。实际上，Agent 的效率不在于单轮对话的长度，而在于信息的组织方式。把一个大任务拆分成多个小任务，每个任务在独立的压缩单元中完成，整体效率往往更高。
4. 第二层：持久记忆（温记忆）
4.1 MEMORY.md 文件详解
MEMORY.md 是 Hermes 持久记忆系统的核心文件之一。它的作用就像是 Agent 的「随身记事本」——里面记录着与当前任务、当前项目、当前环境相关的关键信息。每次会话开始时，这个记事本的内容都会被加载到上下文中，让 Agent 能够「记得」之前交代过的重要事项。
4.1.1 文件结构与格式
MEMORY.md 采用纯 Markdown 格式存储，这有两个好处：一是人类可以直接阅读和编辑，二是 Markdown 的结构性让 Agent 更容易理解其中的内容层次。
默认情况下，MEMORY.md 位于：
~/.hermes/memory/MEMORY.md
文件的基本结构如下：
# Memory
## Project Context
- 项目名称：智能客服系统升级
- 技术栈：Python 3.11 + FastAPI + PostgreSQL
- Git 仓库：github.com/company/customer-service-v2
## Key Decisions
- 使用 JWT 进行身份认证，Token 有效期 24 小时
- 数据库迁移工具选用 Alembic，不选 Django ORM
- API 响应格式统一为 JSON:API 规范
## Important Notes
- 生产环境数据库密码不要在对话中明文展示
- 测试服务器地址：http://test-api.company.internal
- 部署前必须先跑完整测试套件
## Current Focus
- 正在实现订单查询接口的缓存层（Redis）
- 预计本周五完成压力测试你可以看到，这个文件分为几个逻辑区块（用 ## 二级标题分隔），每个区块下面用列表形式记录具体事项。这种结构既清晰又节省空间。
注意
MEMORY.md 的容量被限制在约 2200 字符（具体值可能因版本略有差异）。这不是一个硬性的技术限制，而是一个「软约束」——当内容接近上限时，Agent 会主动压缩或合并旧条目。如果你的 MEMORY.md 经常写满，说明记录的信息不够精炼，需要学习如何提取「真正重要的」信息。
4.1.2 自动写入机制
MEMORY.md 最智能的地方在于：Agent 会自动判断哪些信息值得记录，哪些不值得。
当你与 Agent 对话时，系统会在后台运行一个「记忆评估器」。这个评估器会分析对话内容，根据以下标准判断信息的重要性：
高优先级（几乎一定会记录）：
- 用户明确说「记住这个」「记下来」「以后都要用」
- 关键配置信息（API 密钥、服务器地址、数据库连接串）
- 重要的决策和结论（「我们决定用方案 A 而不是方案 B」）
- 项目相关的上下文（项目名称、技术栈、特殊要求）
中优先级（根据上下文判断是否记录）：
- 用户的偏好设置（「我喜欢深色主题」「用中文回复」）
- 中间计算结果（如果后续步骤会用到）
- 错误和解决方案（「上次是因为权限不足导致的」）
低优先级（通常不记录）：
- 临时性的查询（「今天北京天气怎么样」）
- 已经被执行的命令的具体输出（保留命令本身，不保留输出）
- 闲聊内容
自动写入的触发时机通常是在：
- 用户明确指示记录时：即时写入
- 任务成功完成时：总结关键信息并写入
- 发生重要决策时：即时写入
- 会话结束时：回顾整个对话，补录遗漏的重要信息
4.1.3 手动编辑方法
虽然自动写入很方便，但有时候你需要手动编辑 MEMORY.md。Hermes 提供了几种方式：
方式一：通过命令行直接编辑
# 使用你喜欢的编辑器打开 MEMORY.md
nano ~/.hermes/memory/MEMORY.md
# 或者
vim ~/.hermes/memory/MEMORY.md
# 或者
code ~/.hermes/memory/MEMORY.md # VS Code方式二：在对话中让 Agent 帮你编辑
User: 帮我在 MEMORY.md 里加一条：测试环境的 Redis 端口是 6380
Agent: 已添加。
User: 把 MEMORY.md 里关于 JWT 的那条删掉，我们改用 Session 了
Agent: 已删除 JWT 相关条目，并添加了新条目：身份认证改为 Session-Cookie 方案。
User: 给我看看现在的 MEMORY.md
Agent: [展示当前 MEMORY.md 的完整内容]方式三：使用 /memory 命令系列（详见第7章）
/memory add "生产服务器 IP: 192.168.1.100"
/memory remove "JWT" # 删除包含"JWT"的条目
/memory show # 显示当前内容4.1.4 容量限制（~2200字符）与管理策略
2200 字符大约是 700-800 个汉字，或者 300-400 个英文单词。这个容量看起来不大，但如果使用得当，足以记录一个中等复杂度项目的所有关键信息。
高效利用容量的技巧：
- 使用列表而非段落：列表更节省空间，也更容易被 Agent 解析
# 好：简洁的列表
- API 基地址: https://api.example.com/v2
- 认证方式: Bearer Token
- 超时设置: 30s
# 差：冗长的段落
API 的基地址是 https://api.example.com/v2，这是生产环境的地址。
认证方式我们选用了 Bearer Token，因为相比 Basic Auth 它更安全。
请求的超时时间设置为 30 秒，这是考虑到网络延迟和服务器响应速度...-
定期清理过期信息：项目结束后，把不再相关的条目删掉
-
合并相似条目：如果有三条都是关于数据库配置的，合并成一条
-
使用缩写和代码：技术术语用标准缩写，节省空间
# 好
- DB: PostgreSQL 15, host=db.internal, port=5432
- ORM: SQLAlchemy 2.0 + Alembic
# 差
- 数据库使用的是 PostgreSQL 的第 15 个版本...
- 对象关系映射工具选用了 SQLAlchemy...- 分级管理：如果同时处理多个项目，可以用不同的 MEMORY.md 文件
# 为不同项目使用不同的记忆文件
~/.hermes/memory/MEMORY.md # 默认
~/.hermes/memory/project_a_MEMORY.md # 项目A
~/.hermes/memory/project_b_MEMORY.md # 项目B在对话中切换：
User: 切换到项目 A 的上下文
Agent: 已加载 project_a_MEMORY.md4.1.5 实际 MEMORY.md 示例
以下是一个真实的 MEMORY.md 示例（来自一个实际使用 Hermes 进行 Web 开发的开发者）：
# Memory
## Project
- Name: E-commerce Dashboard
- Stack: Next.js 14 + Tailwind + Prisma + PostgreSQL
- Repo: github.com/acme/ecom-dashboard
- Node: v20 LTS
## Auth
- Provider: NextAuth.js v5
- Methods: OAuth (Google, GitHub) + Credentials
- Session: JWT, maxAge 7d
- Admin emails: [email protected], [email protected]
## API
- Base: /api/v1
- Rate limit: 100req/min per IP
- All endpoints require auth except /api/v1/health
## DB
- Host: localhost (dev) / db.acme.internal (prod)
- Name: ecom_prod / ecom_dev
- Migrations: prisma migrate dev
- Seed: prisma db seed
## Style
- Color: primary=#3B82F6, secondary=#10B981
- Font: Inter (Google Fonts)
- Dark mode: enabled by default
- Mobile-first: min-width 320px
## Deploy
- Platform: Vercel
- Env vars: set in Vercel dashboard
- Branch: main auto-deploys
- Preview: all PRs get preview URL
## Current Sprint
- Task: Cart page redesign
- Due: 2026-04-25
- Blocker: waiting for design team assets这个文件总共约 1100 字符，远低于 2200 的上限，但包含了项目的所有关键信息。当你下次启动 Hermes 继续开发这个项目时，Agent 能立即知道技术栈、认证方式、数据库配置、部署方式等所有上下文，不需要你再重复交代。
4.2 USER.md 文件详解
如果说 MEMORY.md 是「项目记事本」，那 USER.md 就是「用户画像档案」。它记录的不是项目信息，而是你——作为用户的偏好、习惯、行为模式和个性化需求。
4.2.1 用户画像的自动建模
Hermes 最令人惊叹的功能之一，就是它能够「观察」你的行为，自动构建用户画像。这个过程不需要你做任何特殊操作，完全在后台静默进行。
自动建模的数据来源包括：
- 显式反馈：你直接说「我喜欢用中文」「请用 TypeScript」
- 隐式行为：
- 你经常查询什么类型的信息（技术文档 > 新闻 > 娱乐）
- 你倾向什么编程语言（Python 比 JavaScript 用得多）
- 你通常在什么时间段使用 Agent（上午 vs 深夜）
- 你对 Agent 的回复做什么修改（经常删减冗余内容 = 喜欢简洁风格）
- 错误模式：你经常纠正 Agent 的某些错误类型（比如混淆两个相似的概念）
- 任务偏好：你更倾向于让 Agent 自主决策，还是喜欢逐步确认
这些信息会被提炼成简洁的条目，写入 USER.md。
4.2.2 记录哪些信息
USER.md 中常见的信息类型包括：
# User Profile
## Communication
- Language: 中文为主，技术术语保留英文
- Style: 简洁直接，不喜欢冗余解释
- Tone: 专业但不死板
## Technical
- Primary: Python, TypeScript
- Secondary: Go, Rust
- Editor: VS Code with Vim keybindings
- OS: macOS
- Shell: zsh with Oh My Zsh
## Preferences
- Code: 必须包含类型注解和 docstring
- Comments: 英文注释，复杂逻辑加中文说明
- Format: 遵循 Black (Python) / Prettier (JS)
- Testing: pytest for Python, vitest for JS
## Patterns
- Active hours: 9:00-12:00, 14:00-18:00
- Response speed: prefer async over sync
- Error handling: 详细日志 + 优雅降级
- Documentation: README + inline comments
## Interests
- Strong: AI/ML, distributed systems, performance optimization
- Moderate: web dev, DevOps, data engineering
- Weak: frontend UI design, mobile apps
## Avoid
- 不要生成未经验证的代码建议
- 不要假设我有管理员权限
- 不要推荐付费工具 unless 确实必要这些信息的价值在于：它们让 Agent 能够「像你的老搭档一样」与你协作。当你说「帮我写个脚本」，Agent 会自动用 Python（你的首选语言）；当你问一个技术问题，Agent 知道你的水平层次，不会从最基础的概念讲起；当你让它审查代码，它会自动检查类型注解和测试覆盖率。
4.2.3 容量限制（~1375字符）
USER.md 的容量限制（约 1375 字符）比 MEMORY.md 更严格。这是因为：
- 用户画像的变化频率比项目信息低，不需要频繁更新
- 用户画像应该高度精炼——只记录最核心的特征
- 限制容量可以避免画像过于「臃肿」，导致加载时消耗过多 Token
当 USER.md 接近容量上限时，Agent 会启动「画像合并」机制：
- 把两个相似的偏好合并成一条更通用的
- 删除已经不再适用的旧偏好
- 把低频偏好降级或删除
4.2.4 如何查看和编辑
查看 USER.md：
# 命令行
$ cat ~/.hermes/memory/USER.md
# 在对话中
User: 给我看看我的用户画像
Agent: [展示 USER.md 内容]编辑 USER.md：
# 直接编辑
$ nano ~/.hermes/memory/USER.md
# 在对话中
User: 我换用 Neovim 了，更新一下我的编辑器偏好
Agent: 已更新 USER.md：编辑器从 VS Code 改为 Neovim。
User: 我最近在学习 Rust，把它加到我的技术栈里
Agent: 已添加 Rust 到 Secondary languages。
User: 删掉关于「不喜欢注释」那条，我改主意了
Agent: 已删除该条目。Tips
定期检查和清理 USER.md 是个好习惯。就像你的微信头像不会永远用五年前的照片一样，你的技术偏好、工作习惯也会变化。建议每 1-2 个月让 Agent 「重新审视」你的画像，删除过时的条目。
4.2.5 实际 USER.md 示例
以下是一个实际开发者的 USER.md：
# User
## Profile
- Role: Senior Backend Engineer
- Company: FinTech startup
- Experience: 8+ years
## Tech Stack
- Primary: Python (Django/FastAPI), PostgreSQL
- Learning: Rust, Kubernetes
- Tools: Docker, GitHub Actions, Datadog
## Preferences
- Code style: PEP8, type hints mandatory, 100 char line
- Architecture: microservices over monolith
- DB: prefer SQL over NoSQL for structured data
- API: REST > GraphQL (for now)
## Communication
- Language: English for code/docs, 中文 for discussion
- Detail level: high for architecture, medium for implementation
- Examples: always provide runnable code snippets
## Work Patterns
- Active: UTC+8 9:00-18:00
- Reviews: thorough, focus on edge cases and security
- Testing: integration tests > unit tests for APIs
- Docs: OpenAPI spec + README per service
## Context
- Current project: payment gateway v2 redesign
- Deadline: end of Q2
- Team size: 5 engineers
- Constraint: must comply with PCI-DSS这个文件约 800 字符，信息密度很高。想象一下，如果没有 USER.md，每次新会话你都要告诉 Agent：「我是后端工程师，用 Python，喜欢类型注解，现在在做一个支付网关项目...」而有了 USER.md，这一切都在会话开始时自动加载，你只需要直接说「帮我看看这个支付接口的设计」就够了。
4.3 持久记忆的读取时机与优先级
了解了 MEMORY.md 和 USER.md 的内容后，我们来看看它们是如何被加载到会话中的。
读取时机：
- 会话开始时：每次启动新会话，Hermes 都会读取这两个文件
- 文件被修改后：如果你在对话中让 Agent 修改了记忆文件，修改会立即生效
- 执行 /refresh 命令时：强制重新加载所有记忆
加载优先级（高到低）：
1. 系统提示（System Prompt）
2. SOUL.md
3. 激活的 Skill 说明
4. USER.md（用户画像）
5. MEMORY.md（项目记忆）
6. 冷记忆检索结果
7. 当前对话历史
8. 用户输入
这个优先级顺序的设计理由：
- 系统提示和 SOUL.md 在最前面：它们是 Agent 的「基本行为准则」，必须最先被看到
- USER.md 在 MEMORY.md 前面：你的个人偏好比项目信息更根本。比如你喜欢简洁回复，这个偏好应该优先于某个项目要求详细文档的需求
- 温记忆在冷记忆前面：当前项目的直接记忆，比历史检索到的片段更相关
- 对话历史在最后面：动态变化的内容放在最后，符合 FIFO 截断策略（如果溢出，最先丢失的是最早的对话）
注意
如果你发现 Agent 在某些情况下「记不住」你的偏好，可能是因为 MEMORY.md 中的某条项目级设置覆盖了 USER.md 中的用户级设置。例如，USER.md 说你喜欢简洁回复，但 MEMORY.md 中写着「这个项目需要详细的文档说明」，Agent 可能会为了项目需求而提供更详细的回复。这是预期行为——项目上下文优先于个人偏好。
5. 第三层：检索记忆（冷记忆）
5.1 SQLite 数据库架构详解
冷记忆是 Hermes 记忆系统中技术含量最高的部分，也是它与大多数其他 Agent 框架拉开差距的地方。让我们从最底层的存储架构开始，一层一层地向上理解。
5.1.1 表结构设计
Hermes 使用 SQLite 作为冷记忆的存储引擎。SQLite 的选择是深思熟虑的：
- 零配置：不需要安装独立的数据库服务，一个
.db文件就是完整的数据库 - 跨平台：Windows、macOS、Linux 都能用
- 高性能：对于本地单用户场景，SQLite 的性能完全够用
- 事务安全：支持 ACID，数据不会损坏
- 内置 FTS5：SQLite 从 3.19.0 版本开始内置 FTS5 全文搜索扩展
数据库文件默认位于：
~/.hermes/memory/hermes_memory.db
核心表结构如下（简化版）：
-- 会话表：记录每一次对话会话
CREATE TABLE conversations (
id INTEGER PRIMARY KEY AUTOINCREMENT,
session_id TEXT UNIQUE NOT NULL, -- 会话唯一标识
started_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
ended_at TIMESTAMP,
summary TEXT, -- LLM 生成的会话摘要
tags TEXT, -- 标签，用逗号分隔
total_messages INTEGER DEFAULT 0, -- 消息总数
total_tokens INTEGER DEFAULT 0 -- Token 总数
);
-- 消息表：存储每一条消息
CREATE TABLE messages (
id INTEGER PRIMARY KEY AUTOINCREMENT,
conversation_id INTEGER NOT NULL,
role TEXT NOT NULL, -- 'user' 或 'assistant'
content TEXT NOT NULL,
timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
tokens INTEGER, -- 该消息的 Token 数
FOREIGN KEY (conversation_id) REFERENCES conversations(id)
);
-- 工具调用表：记录 Agent 的每一次工具使用
CREATE TABLE tool_calls (
id INTEGER PRIMARY KEY AUTOINCREMENT,
conversation_id INTEGER NOT NULL,
tool_name TEXT NOT NULL, -- 工具名称
arguments TEXT, -- 调用参数（JSON 格式）
result TEXT, -- 调用结果
success BOOLEAN DEFAULT 1,
duration_ms INTEGER, -- 执行耗时（毫秒）
timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (conversation_id) REFERENCES conversations(id)
);
-- 文件操作表：记录 Agent 的文件读写操作
CREATE TABLE file_operations (
id INTEGER PRIMARY KEY AUTOINCREMENT,
conversation_id INTEGER NOT NULL,
operation TEXT NOT NULL, -- 'read', 'write', 'edit', 'delete'
file_path TEXT NOT NULL,
content_hash TEXT, -- 内容哈希（用于检测变更）
timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (conversation_id) REFERENCES conversations(id)
);
-- 记忆片段表：存储提取出的关键记忆
CREATE TABLE memory_fragments (
id INTEGER PRIMARY KEY AUTOINCREMENT,
source_conversation_id INTEGER,
content TEXT NOT NULL, -- 记忆内容
importance_score REAL, -- 重要性评分（0-1）
category TEXT, -- 分类：'fact', 'decision', 'preference', etc.
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
last_accessed TIMESTAMP,
access_count INTEGER DEFAULT 0, -- 被检索到的次数
FOREIGN KEY (source_conversation_id) REFERENCES conversations(id)
);这个设计的精妙之处在于：不仅存储了「说什么」，还存储了「做什么」。工具调用记录和文件操作记录，让 Agent 能够回答这样的问题：「上次我是怎么解决那个问题的？」「我修改过这个文件的哪几行？」
5.1.2 存储的数据类型
Hermes 的冷记忆数据库不仅存储对话文本，还记录了丰富的元数据：
对话类数据：
- 完整的用户输入和 Agent 回复
- 每次对话的时间戳和持续时间
- 对话中使用的模型和参数
- 会话级别的 Token 统计
工具类数据：
- 工具名称和调用参数
- 工具执行结果（成功/失败）
- 执行耗时
- 调用链（一个工具调用触发了另一个工具）
文件类数据：
- 读写的文件路径
- 操作类型（创建/修改/删除）
- 内容哈希值（用于追踪变更）
- 操作时间
知识类数据：
- 从对话中提取的关键事实
- 用户明确记录的备忘
- 自动生成的会话摘要
- 用户偏好和行为的推断结果
5.1.3 数据量增长估算
很多用户关心：这个数据库会不会无限膨胀？我需要手动清理吗？
让我们做一个估算。假设你是一个「中等强度」的用户：
- 每天与 Agent 对话 20 轮
- 每轮平均 200 Tokens
- 每天使用 5 次工具调用
- 每天产生 3 次文件操作
一天的数据量：
消息：20 轮 × 2 条（用户+Agent）= 40 条消息
工具调用：5 次
文件操作：3 次
文本总量：20 × 200 = 4,000 Tokens ≈ 12,000 字符
一年的数据量：
消息：40 × 365 = 14,600 条
工具调用：5 × 365 = 1,825 次
文件操作：3 × 365 = 1,095 次
文本总量：12,000 × 365 ≈ 4,380,000 字符 ≈ 4.4 MB
加上索引和元数据，一年的数据库大小大约在 10-20 MB 左右。这个体积在现代电脑上完全微不足道——你的微信聊天记录一个月可能就几百 MB。
即使你是「重度用户」（每天 100 轮对话），一年的数据量也就在 50-100 MB 级别。SQLite 能轻松处理 GB 级别的数据库，所以你完全不需要担心存储空间的问题。
Tips
虽然存储空间不是问题，但检索速度会随着数据量增加而有所下降。Hermes 内置了自动维护机制（详见第7章），包括索引优化和旧数据归档。你也可以手动设置保留策略（详见第10章）。
5.2 FTS5 全文索引
FTS5（Full-Text Search 5）是 SQLite 内置的全文搜索引擎。它是 Hermes 冷记忆检索能力的核心支柱。理解 FTS5，就理解了 Hermes 如何做到「瞬间从海量历史中找到相关内容」。
5.2.1 什么是 FTS5（通俗解释）
我们先不用技术术语，用一个类比来解释 FTS5。
想象你有一个巨大的图书馆，里面有 10 万本书。如果你要找一本「讲 Python 编程的书」，传统的方式是一本一本地翻看——这显然太慢了。
于是你做了一个「目录卡片」系统：每本书你都在卡片上记录书名、作者、关键词。所有卡片按字母顺序排列在一个巨大的抽屉柜里。当你要找 Python 的书时，直接去 "P" 开头的抽屉里找就行了。这就是「索引」。
但 FTS5 比这个更强大。它不仅记录「这本书里有 Python 这个词」，还记录「Python 这个词在书的第 3 页第 2 段出现了」。更进一步，它能理解「Python 编程」「Python 开发」「Python 语言」都是相关的，甚至能处理拼写错误（比如你把 Python 拼成了 Pthon）。
在 Hermes 的语境中，FTS5 做的事情是：
- 把每一条历史消息、每一个工具调用结果、每一个文件操作记录，都「拆开」成单词
- 建立一个巨大的「倒排索引」——记录每个词出现在哪些记录中
- 当你搜索时，瞬间找到包含这些词的所有记录
- 按照相关度排序，把最相关的结果返回给你
5.2.2 索引建立过程
FTS5 索引的建立是自动的，你不需要手动操作。但为了让你理解背后的机制，我们来看看索引是如何构建的：
-- 创建 FTS5 虚拟表（Hermes 内部自动完成）
CREATE VIRTUAL TABLE messages_fts USING fts5(
content, -- 要索引的文本内容
conversation_id UNINDEXED, -- 不索引，仅存储关联ID
timestamp UNINDEXED -- 不索引，仅存储
);
-- 当新消息写入时，自动添加到索引（触发器自动完成）
INSERT INTO messages_fts(content, conversation_id, timestamp)
VALUES ('用户输入的内容...', 123, '2026-04-21 10:30:00');索引建立的过程：
-
分词（Tokenization）：将文本拆分成单词。对于中文，需要使用专门的分词器（如
jieba或 SQLite 的icu分词器）。Hermes 默认使用porter分词器处理英文，simple分词器处理中文。 -
标准化（Normalization）：
- 统一大小写（"Python" 和 "python" 视为同一个词）
- 去除标点符号
- 词干提取（"running" 和 "runs" 都归为 "run"）
-
去停用词：过滤掉「的」「是」「the」「and」等无意义的词，减少索引体积
-
构建倒排索引：记录每个词在哪些文档中出现，以及出现的位置
5.2.3 检索速度与效果
FTS5 的检索速度非常快。在普通笔记本电脑上，从 100 万条记录中检索关键词，通常只需要 几毫秒到几十毫秒。
让我们看一个实际的检索场景：
假设你在半年前的一个会话中讨论过「如何用 Docker 部署 PostgreSQL」。现在你忘了具体的命令，只记得「Docker」和「PostgreSQL」两个关键词。你开启新会话，输入：
User: 上次部署 PostgreSQL 的 Docker 命令是什么来着？Hermes 的内部检索过程：
-- 1. 提取关键词
-- 分析输入："部署 PostgreSQL 的 Docker 命令"
-- 提取关键词：PostgreSQL, Docker, 部署, 命令
-- 过滤停用词：保留 PostgreSQL, Docker, 命令
-- 2. FTS5 检索
SELECT
content,
conversation_id,
rank -- FTS5 内置的相关度评分
FROM messages_fts
WHERE messages_fts MATCH 'PostgreSQL AND Docker AND 命令'
ORDER BY rank
LIMIT 5;检索结果可能是：
结果1 (rank: 1.2): "docker run -d --name pg -e POSTGRES_PASSWORD=secret postgres:15"
结果2 (rank: 2.5): "我用 Docker 部署了 PostgreSQL，配置如下..."
结果3 (rank: 3.1): "Docker Compose 文件里 PostgreSQL 的部分..."
然后 Hermes 会把这些相关片段注入到当前上下文中，Agent 就能回答你的问题：
Agent: 根据之前的记录，你使用的 Docker 命令是：
docker run -d \
--name pg \
-e POSTGRES_PASSWORD=secret \
-p 5432:5432 \
postgres:15
这是你在 2025 年 10 月 15 日的会话中使用的配置。
5.2.4 与传统全文搜索的对比
如果你做过信息检索相关的工作，可能会问：FTS5 和 Elasticsearch、Solr 等传统全文搜索引擎相比如何？
| 特性 | FTS5 (SQLite) | Elasticsearch | 传统 SQL LIKE |
|---|---|---|---|
| 部署复杂度 | 零（内置） | 高（需独立服务） | 零 |
| 检索速度 | 毫秒级 | 毫秒级 | 秒级（大数据量时） |
| 相关性排序 | 支持 | 支持（更强大） | 不支持 |
| 模糊匹配 | 基本支持 | 强大 | 不支持 |
| 分布式 | 不支持 | 支持 | 不支持 |
| 数据量上限 | GB 级 | TB 级 | 无索引时很慢 |
| 维护成本 | 极低 | 高 | 低 |
对于 Hermes 的使用场景（个人或小型团队的本地 Agent），FTS5 在绝大多数情况下已经绰绰有余。它的「零部署」优势尤其重要——你只需要安装 Hermes，全文检索能力就自动可用了。
注意
FTS5 的一个局限是中文分词能力相对较弱（默认的
simple分词器对中文只是按字拆分）。Hermes 通过预处理优化了这个问题，但在某些复杂的中文查询场景下，检索效果可能不如专门的搜索引擎。如果你主要用中文工作且对检索精度要求极高，可以考虑通过 Mem0 等外部方案增强检索能力。
5.3 按需检索机制
按需检索是 Hermes 冷记忆系统最具创新性的设计。传统的记忆方案往往在会话开始时就把所有历史记录加载到上下文中，而 Hermes 采用了一种更智能的方式。
5.3.1 新对话时不再全量加载
让我们对比一下两种策略：
传统策略（全量加载）：
会话开始
↓
加载过去 100 个会话的所有消息（50,000 Tokens）
↓
加上系统提示和当前输入（2,000 Tokens）
↓
总上下文：52,000 Tokens
↓
模型处理（慢、贵、容易混乱）
Hermes 策略（按需检索）：
会话开始
↓
只加载固定保留区（系统提示 + SOUL.md + 温记忆）（2,000 Tokens）
↓
分析用户输入，提取关键词
↓
FTS5 检索，只取最相关的 3-5 条记录（~500 Tokens）
↓
总上下文：~2,500 Tokens
↓
模型处理（快、便宜、聚焦）
差异是惊人的：传统策略可能一次请求就消耗 50,000+ Tokens，而 Hermes 的策略通常只消耗 2,000-3,000 Tokens。按照 GPT-4 的定价（输入 $0.03/1K Tokens），每轮对话的成本差异是 $1.5 vs $0.075——相差 20 倍！
5.3.2 根据当前话题智能检索
Hermes 的检索不是简单的关键词匹配，而是一个多阶段的智能过程：
阶段一：查询理解
当用户输入一条消息时，Hermes 首先分析这条消息的意图和主题：
用户输入: "帮我看看上次那个支付接口的 bug 修好了没"
提取关键词: 支付接口, bug, 修好
推断主题: code_review, bug_fix, payment
时间范围: 最近（"上次"暗示近期）
阶段二：多维度检索
根据理解的结果，从不同维度并行检索：
-- 维度1：消息内容匹配
SELECT * FROM messages_fts
WHERE messages_fts MATCH '支付 AND (bug OR 修复 OR 修好)'
ORDER BY rank LIMIT 3;
-- 维度2：工具调用记录
SELECT * FROM tool_calls
WHERE tool_name IN ('code_review', 'file_edit')
AND (result LIKE '%支付%' OR arguments LIKE '%支付%')
ORDER BY timestamp DESC LIMIT 2;
-- 维度3：文件操作记录
SELECT * FROM file_operations
WHERE file_path LIKE '%payment%' OR file_path LIKE '%pay%'
ORDER BY timestamp DESC LIMIT 2;阶段三：相关度融合与排序
将多个维度的结果合并，按综合相关度排序：
相关度评分 =
FTS 排名分数 × 0.4 + -- 文本匹配度
时间衰减因子 × 0.3 + -- 越新的越重要
工具成功率 × 0.2 + -- 成功的操作更重要
用户反馈权重 × 0.1 -- 用户标注重要的优先
阶段四：片段提取与注入
从选中的记录中提取最相关的片段（不是整段对话，而是包含关键词的那几句话），然后格式化为上下文注入：
[相关历史片段 #1]
来源：2026-04-15 的会话
内容：用户报告支付接口在并发请求时出现 500 错误。Agent 建议使用连接池并增加了重试逻辑。
[相关历史片段 #2]
来源：2026-04-16 的会话
内容：修复了 payment/service.py 中的 race condition，提交了 commit a3f7d2e。
5.3.3 只提取相关片段
这是一个关键设计：不是把整个历史会话都加载进来，而是只提取「相关的那几句话」。
这样做的好处：
- 极大节省 Token：一条完整的会话可能 500 Tokens，但相关片段可能只有 50 Tokens
- 减少噪声：不相关的历史信息不会干扰当前任务
- 提高精度：模型只看到了真正需要的信息，不会被无关内容分散注意力
提取算法会围绕关键词向外扩展，取包含关键词的句子和前后各一句，形成一个「语义完整的片段」。如果关键词出现在工具调用结果中，会同时提取工具名称、参数和结果摘要。
5.3.4 API 调用成本大幅降低
按需检索机制带来的最大实际好处，就是 API 调用成本的大幅降低。
假设你使用 Claude 3.7 Sonnet（$0.03/1K input tokens），每天进行 50 轮对话：
| 策略 | 每轮平均 Tokens | 每日 Tokens | 每日成本 |
|---|---|---|---|
| 全量加载 | 25,000 | 1,250,000 | $37.50 |
| Hermes 按需检索 | 3,000 | 150,000 | $4.50 |
| 节省 | 88% | 88% | $33/天 |
一个月下来，Hermes 的按需检索机制可以为你节省约 $990 的 API 费用。这不仅仅是省钱——更重要的是，更低的成本让你可以更频繁、更深度地使用 Agent，而不必心疼账单。
Tips
如果你想进一步降低成本，可以在
config.yaml中调整检索参数：memory: retrieval: max_fragments: 3 # 减少检索到的片段数量（默认5） fragment_max_tokens: 80 # 限制每个片段的长度（默认150） time_decay_days: 30 # 只检索最近30天的记录（默认90）这些调整会在检索精度和成本之间做权衡。如果你主要处理近期任务，把时间范围缩小可以显著减少检索开销。
5.4 LLM 摘要生成
除了 FTS5 全文检索，Hermes 还利用大语言模型本身的能力，为每次会话生成智能摘要。这些摘要既服务于人类用户（快速回顾），也服务于 Agent（高效检索）。
5.4.1 自动生成会话摘要
每次会话结束时（或执行 /compact 时），Hermes 会触发摘要生成流程：
1. 获取当前会话的完整对话记录
2. 构建摘要提示模板：
"请为以下对话生成一个简洁的摘要（100字以内）。
摘要应包括：主要任务、关键决策、重要结论、遗留问题。"
3. 调用 LLM 生成摘要
4. 将摘要保存到 conversations 表的 summary 字段
5. 同时为摘要建立 FTS5 索引
生成的摘要示例：
会话摘要（2026-04-21）:
用户要求分析 Q1 财报数据。使用 Python 抓取并清洗了 3 家公司的
财务数据，生成对比图表。关键结论：A 公司毛利率最高（42%）。
遗留：需要补充行业均值数据。
5.4.2 摘要的存储与索引
摘要会被存储在两个地方：
- conversations 表的 summary 字段：作为元数据，便于快速浏览
- FTS5 索引：让摘要也能被检索到
当用户搜索时，FTS5 会同时搜索：
- 原始消息内容
- 会话摘要
- 工具调用结果
- 文件操作记录
这意味着，即使用户记不住具体的对话内容，只记得「大概是什么主题」，也能通过摘要找到相关会话。
5.4.3 摘要质量的影响因素
摘要的质量直接影响检索的效果。以下因素会影响摘要质量：
正向因素：
- 对话主题明确、任务清晰
- 有明确的决策点和结论
- 用户和 Agent 的互动质量高
负向因素：
- 对话过于零散、话题频繁切换
- 大量闲聊和无关内容
- 任务中途被打断
你可以通过以下方式帮助 Agent 生成更好的摘要：
- 在任务完成时做总结：「总结一下我们今天做了什么」
- 给会话打标签：「给这个会话打个标签：投研-Q1-白酒」
- 手动修正摘要：如果你觉得自动摘要不够准确，可以手动编辑
User: 修改刚才那个会话的摘要，加上「最终输出了一份 Excel 报告」
Agent: 已更新会话摘要。6. 外部记忆扩展
虽然 Hermes 内置的记忆系统已经非常强大，但在某些特定场景下，外部记忆扩展可以提供更专业的能力。本节介绍几种主流的外部记忆方案及其集成方法。
6.1 Honcho 模块详解
Honcho 是一个专注于「用户行为模式推导」的记忆模块，由 a16z 支持开发。它的核心理念是：通过分析用户的历史行为，推断出用户的隐性偏好和需求，从而让 Agent 的响应更加个性化。
6.1.1 Honcho 的设计理念
Honcho 的设计灵感来自心理学中的「认知建模」理论。它认为，一个真正智能的 Agent 不应该只是「记住用户说过什么」，而应该「理解用户是什么样的人」。
具体来说，Honcho 会：
- 分析对话模式：你在什么情况下会打断 Agent？你通常如何纠正 Agent 的错误？
- 推断认知风格：你是「先整体后细节」的人，还是「先细节后整体」的人？
- 识别情感触发点：哪些类型的话题会让你表现出兴奋、困惑或不耐烦？
- 建模知识水平：你在不同领域的能力层次（专家/熟练/新手）
基于这些分析，Honcho 生成一个「用户心理模型」，供 Agent 在后续交互中参考。
6.1.2 行为模式推导机制
Honcho 的行为模式推导分为三个层次：
第一层：表面模式（Surface Patterns）
从原始对话中提取可直接观察的模式：
{
"communication_patterns": {
"average_response_length": 45,
"preferred_language": "zh-CN",
"uses_technical_jargon": true,
"asks_clarifying_questions": false
},
"timing_patterns": {
"peak_activity_hours": [9, 10, 14, 15],
"average_session_duration_minutes": 23,
"typical_task_complexity": "medium"
}
}第二层：推断特征（Inferred Traits）
基于表面模式，推断更深层的用户特征：
{
"cognitive_style": "analytical",
"risk_tolerance": "medium",
"learning_preference": "example-driven",
"decision_making": "data-driven",
"expertise_areas": ["backend_development", "system_design"],
"novice_areas": ["frontend_design", "mobile_development"]
}第三层：预测模型（Predictive Model）
基于历史数据，预测用户在未来场景中的行为：
{
"predicted_behaviors": {
"when_introducing_new_tech": "will_ask_for_examples",
"when_facing_errors": "prefers_step_by_step_debugging",
"when_given_options": "tends_to_choose_performance_over_convenience"
}
}6.1.3 安装与配置方法
在 Hermes 中集成 Honcho：
# 1. 安装 Honcho Python 包
pip install honcho-ai
# 2. 在 config.yaml 中启用 Honcho
```yaml
# ~/.hermes/config.yaml
memory:
external:
honcho:
enabled: true
api_key: "your_honcho_api_key" # 可选，本地模式可不填
mode: "local" # 或 "cloud"
inference_frequency: "per_session" # per_message / per_session / per_day
depth: "full" # surface / inferred / full3. 重启 Hermes
hermes restart
如果你选择 `mode: "local"`，所有 Honcho 的数据处理都在本地完成，不会上传到 Honcho 的服务器。但某些高级推断功能可能需要 `cloud` 模式。
#### 6.1.4 实际效果展示
启用 Honcho 前后对比：
**启用前：**
User: 帮我写个脚本处理日志文件 Agent: 好的，这是一个 Python 脚本... [生成一个通用脚本]
**启用后（Honcho 已推断出用户偏好）：**
User: 帮我写个脚本处理日志文件 Agent: 好的，基于你之前的偏好（喜欢用 Go 写工具脚本、重视错误处理、 偏好结构化输出），这是一个 Go 脚本... [生成一个带 error handling、JSON 输出的 Go 脚本]
Honcho 的推断不是基于你明确说过的偏好，而是基于你过去的行为模式。比如你可能从来没说过「我喜欢 Go 语言」，但如果你过去 10 次让 Agent 写脚本时 8 次都选了 Go，Honcho 就会推断出这个偏好。
> **注意**
>
> Honcho 是一个相对较新的项目，其推断算法的准确性还在持续改进中。建议把它作为「增强」而非「替代」Hermes 内置的记忆系统。在使用过程中，如果你发现 Honcho 的推断有偏差，可以通过 `honcho feedback` 命令提供纠正反馈。
### 6.2 Mem0 集成
Mem0 是目前最流行的外部记忆平台之一，被描述为「AI 应用的记忆层」。它提供了比 Hermes 内置记忆更强大的检索和管理能力，特别适合需要跨设备同步记忆的场景。
**Mem0 的核心特性：**
1. **混合检索**：同时支持向量检索（语义相似度）和关键词检索（精确匹配）
2. **记忆层级**：自动区分短期记忆、长期记忆和核心事实
3. **多模态**：支持文本、图像、音频等多种类型记忆
4. **跨平台**：记忆可以在不同设备、不同应用间同步
5. **记忆冲突解决**：当新旧记忆矛盾时，自动判断哪个更可靠
**在 Hermes 中集成 Mem0：**
```bash
# 1. 安装 Mem0
pip install mem0ai
# 2. 获取 API 密钥（在 mem0.ai 注册）
# 3. 配置 Hermes
```yaml
memory:
external:
mem0:
enabled: true
api_key: "m0-your-api-key"
organization_id: "your-org-id"
project_id: "your-project-id"
# 检索配置
retrieval:
method: "hybrid" # semantic / keyword / hybrid
top_k: 5
# 记忆更新配置
update:
auto_add: true
importance_threshold: 0.7
4. 重启 Hermes
**Mem0 与内置记忆的协作模式：**
Hermes 支持「分层记忆」模式：内置记忆处理日常任务，Mem0 处理需要高级检索能力的场景。具体协作方式：
用户输入 ↓ 同时查询 Hermes 内置记忆 和 Mem0 ↓ 融合两个来源的结果 ↓ 按相关度排序，去重 ↓ 注入上下文
> **Tips**
>
> 如果你同时使用 Mem0 和内置记忆，建议在 `config.yaml` 中设置优先级：
> ```yaml
> memory:
> retrieval_priority: ["local", "mem0"] # 先查本地，再查 Mem0
> # 或
> retrieval_priority: ["mem0", "local"] # 先查 Mem0，再查本地
> ```
### 6.3 OpenViking 集成
OpenViking 是一个面向企业级场景的记忆扩展方案，由 Viking Analytics 开发。它专注于解决以下企业痛点：
1. **团队协作记忆**：多个用户共享项目记忆，新成员加入时能快速了解项目上下文
2. **权限控制**：不同角色可以访问不同层级的记忆（公开/团队/个人/机密）
3. **合规审计**：所有记忆操作都有完整的审计日志，满足企业合规要求
4. **数据隔离**：不同客户/项目的数据严格隔离，防止交叉污染
**OpenViking 的架构：**
OpenViking Server ├── Project Memory Pool (共享项目记忆) ├── Team Memory Pool (团队知识库) ├── Personal Memory Pool (个人记忆) └── Audit Log (审计日志)
Hermes Agent ←→ OpenViking Client ←→ OpenViking Server
**集成方式：**
```yaml
memory:
external:
openviking:
enabled: true
server_url: "https://openviking.company.internal"
api_key: "vk-xxx"
# 企业级配置
project_id: "project-alpha"
team_id: "backend-team"
access_level: "team" # personal / team / project / admin
# 合规配置
audit_enabled: true
data_retention_days: 365
encryption: "aes-256-gcm"
OpenViking 更适合以下场景：
- 中大型开发团队使用 Hermes 协作
- 需要满足数据合规要求的企业
- 项目记忆需要在团队成员间共享
- 需要精细的权限控制
对于个人用户和小团队，Hermes 内置的记忆系统通常已经足够。
6.4 其他 5 种外部记忆方案
除了 Honcho、Mem0 和 OpenViking，社区还开发了多种其他记忆扩展方案。根据 Hermes Atlas 官方文档，目前已支持 8 种社区记忆扩展，包括 Honcho、Mem0、Hindsight、Supermemory 等。以下是值得了解的方案：
方案一：Hindsight —— 事后反思增强记忆
Hindsight 是一款专注于「事后反思」的记忆扩展。它的核心理念是：Agent 不应该只记录「发生了什么」，还应该记录「为什么会这样」以及「下次如何做得更好」。每次会话结束后，Hindsight 会触发一个反思流程，自动生成「经验卡片」，记录成功模式、失败教训和优化建议。
Hindsight 特别适合需要持续改进的复杂工作流场景，比如代码审查、投研分析、内容创作等。
memory:
external:
hindsight:
enabled: true
reflection_depth: "detailed" # brief / detailed / deep
auto_reflect: true
retention: "lessons_only" # 只保留提炼出的经验教训方案二：Supermemory —— 超级个人记忆库
Supermemory 是一个主打「捕获一切」的外部记忆方案。它不仅可以存储对话历史，还能主动抓取你浏览的网页、收藏的推文、阅读的文章，建立统一的个人知识库。通过浏览器插件和 API，Supermemory 能让 Hermes 访问你的整个数字生活轨迹。
适合希望 Agent 拥有「完整上下文」的深度用户。但需注意隐私影响——它确实需要访问大量个人数据。
memory:
external:
supermemory:
enabled: true
api_key: "sm-your-key"
capture_web_browsing: true
capture_bookmarks: true方案三：Chroma + LangChain Memory
使用 Chroma 向量数据库作为后端，通过 LangChain 的 ConversationBufferMemory 接口集成。适合需要语义检索的场景。
memory:
external:
chroma:
enabled: true
persist_directory: "~/.hermes/chroma_db"
collection_name: "hermes_memories"
embedding_model: "sentence-transformers/all-MiniLM-L6-v2"方案二：Pinecone 云端向量记忆
Pinecone 是一个托管的向量数据库服务，提供高性能的语义检索。适合不需要本地部署、愿意使用云服务的用户。
优点：检索速度快、支持大规模数据、自动扩缩容 缺点：数据上云、有额外成本、需要网络连接
方案三：Zep Memory
Zep 是专门为 LLM 应用设计的长期记忆服务。它的特点是「渐进式摘要」——随着对话进行，自动将短期记忆提炼成长期记忆。
Zep 的独特之处在于它理解「时间」的概念。比如它能回答「用户上周对什么话题最感兴趣？」这种需要时间维度分析的问题。
方案四：Zep Memory
Zep 是专门为 LLM 应用设计的长期记忆服务。它的特点是「渐进式摘要」——随着对话进行，自动将短期记忆提炼成长期记忆。Zep 的独特之处在于它理解「时间」的概念。比如它能回答「用户上周对什么话题最感兴趣？」这种需要时间维度分析的问题。
方案五：本地文件系统记忆（增强版）
如果你不想用任何外部服务，可以用增强的本地文件方案：
~/.hermes/memory/
├── daily/ # 按日期归档
│ ├── 2026-04-21.md
│ ├── 2026-04-20.md
│ └── ...
├── projects/ # 按项目归档
│ ├── project-alpha/
│ ├── project-beta/
│ └── ...
├── topics/ # 按主题归档
│ ├── python-tips.md
│ ├── docker-notes.md
│ └── ...
└── index.json # 所有文件的索引
配合一个简单的检索脚本，就能实现基本的记忆管理。这种方式完全离线，但检索能力较弱。
方案六：Obsidian / Notion 集成
如果你已经在使用 Obsidian 或 Notion 作为个人知识库，可以把它们作为 Hermes 的外部记忆：
memory:
external:
obsidian:
enabled: true
vault_path: "~/Documents/Obsidian Vault"
# Hermes 会索引你的 Obsidian 笔记
# 并在检索时纳入搜索结果这种方式的最大好处是：你的 Agent 记忆和你的个人知识库合二为一。你在 Obsidian 中记录的读书笔记、会议记录、项目文档，Agent 都能检索到。
6.5 选择建议：什么场景用什么方案
面对这么多记忆方案，如何选择？以下是针对不同场景的推荐：
| 使用场景 | 推荐方案 | 理由 |
|---|---|---|
| 个人开发者，日常使用 | Hermes 内置记忆 | 零配置、完全本地、有界设计保持专注 |
| 需要语义检索（找「意思相近」的内容） | Mem0 或 Chroma | 向量检索擅长语义匹配 |
| 需要事后反思和经验积累 | Hindsight | 自动生成经验卡片，持续改进 |
| 希望 Agent 拥有完整数字生活上下文 | Supermemory | 捕获浏览历史、收藏、阅读记录 |
| 跨设备同步记忆 | Mem0 Cloud | 云端同步，多设备一致 |
| 企业团队协作用 | OpenViking | 权限控制、审计合规 |
| 深度用户行为分析 | Honcho | 行为模式推断 |
| 已有 Obsidian/Notion 知识库 | 对应集成方案 | 统一知识管理 |
| 极度隐私敏感（如处理医疗/金融数据） | 纯内置记忆 | 数据绝不出本地 |
| 超大规模数据（百万级会话） | Pinecone / 定制方案 | 专业向量数据库的扩展性 |
Tips
对于绝大多数用户，我的建议是：先用好 Hermes 内置的记忆系统。它覆盖了 80% 的使用场景，而且零配置、零成本。当你遇到内置系统无法解决的特定问题时，再考虑引入外部扩展。不要为了「技术炫酷」而增加不必要的复杂度。
7. 记忆管理实战
7.1 /memory 命令系列详解
Hermes 提供了一套完整的 /memory 命令，让你能够像操作数据库一样管理记忆。掌握这些命令，是高效使用 Hermes 的必备技能。
命令总览：
/memory show # 查看当前记忆状态
/memory add <内容> # 手动添加一条记忆
/memory remove <关键词> # 删除包含关键词的记忆条目
/memory edit <id> <新内容> # 编辑指定记忆
/memory search <关键词> # 搜索记忆
/memory export [文件名] # 导出记忆
/memory import <文件名> # 导入记忆
/memory compact # 压缩记忆文件
/memory clear # 清空所有记忆（谨慎使用！）/memory show —— 查看当前记忆状态
这是你最常用的命令之一。它会展示当前加载的所有记忆内容：
User: /memory show
Agent:
📋 当前记忆状态
═══════════════
📄 MEMORY.md (~1,850 / 2,200 字符)
━━━━━━━━━━━━━━━━━━━━
## Project
- 项目: 智能客服系统 v2
- 技术栈: Python + FastAPI + PostgreSQL
- Git: github.com/acme/customer-service-v2
## Key Info
- API 基地址: https://api.cs2.acme.com
- 认证: JWT, 过期 24h
- DB 主机: db.acme.internal
## Current Sprint
- 任务: 实现工单自动分配
- 截止日期: 2026-04-30
👤 USER.md (~890 / 1,375 字符)
━━━━━━━━━━━━━━━━━━━━
## Profile
- Role: 后端工程师
- 经验: 5年
## Tech
- 主要: Python, Go
- 数据库: PostgreSQL, Redis
- 框架: FastAPI, Django
## Preferences
- 代码风格: PEP8 + Type Hints
- 文档: 中文注释 + 英文 docstring
🗄️ 冷记忆统计
━━━━━━━━━━━━━━━━━━━━
总会话数: 147
总消息数: 3,284
总工具调用: 892
数据库大小: 18.5 MB
FTS5 索引: 已建立
最后检索: 3 秒前这个视图让你一目了然地看到所有记忆的状态，包括容量使用情况。
/memory add —— 手动添加记忆
有时候你需要手动添加一些信息到记忆中：
# 添加到 MEMORY.md
User: /memory add "测试服务器密码: TestPass123! (仅内部使用)"
Agent: 已添加到 MEMORY.md。
# 添加到 USER.md（使用 --user 标志）
User: /memory add --user "最近在学习 Kubernetes"
Agent: 已添加到 USER.md。
# 添加到特定分类
User: /memory add --category "credentials" "AWS Access Key: AKIA..."
Agent: 已添加到 MEMORY.md 的 credentials 分类下。添加时的一些技巧：
- 使用关键词：添加的内容要包含你未来可能搜索的关键词
- 保持简洁：一条记忆只记录一件事
- 定期回顾：添加后过段时间看看是否真的有用
/memory remove —— 删除记忆
当某些记忆过期或错误时，你需要删除它们：
# 按关键词删除（删除包含该关键词的所有条目）
User: /memory remove "测试服务器"
Agent: 已删除 2 条包含"测试服务器"的记忆：
- "测试服务器地址: 192.168.1.50"
- "测试服务器密码: TestPass123!"
# 精确匹配删除
User: /memory remove --exact "JWT"
Agent: 已删除 1 条精确匹配的记忆。
# 删除整个分类
User: /memory remove --category "sprint-2026-Q1"
Agent: 已删除分类 "sprint-2026-Q1" 下的 15 条记忆。注意
/memory remove删除的是温记忆（MEMORY.md / USER.md）中的条目。如果你想删除冷记忆（SQLite 中的历史记录），需要使用hermes history delete命令。两者的删除范围不同，不要混淆。
/memory edit —— 编辑记忆
有时候记忆的内容需要更新，但不需要完全删除重写：
# 查看所有记忆的编号
User: /memory list
Agent:
MEMORY.md:
[1] 项目: 智能客服系统 v2
[2] API 基地址: https://api.cs2.acme.com
[3] 认证: JWT, 过期 24h
# 编辑指定编号
User: /memory edit 3 "认证: Session-Cookie, 过期 7天"
Agent: 已将第 3 条记忆更新为：认证: Session-Cookie, 过期 7天/memory search —— 搜索记忆
这个命令让你在温记忆中快速找到需要的内容：
# 简单搜索
User: /memory search "PostgreSQL"
Agent:
找到 3 条记忆：
1. [MEMORY.md] 数据库: PostgreSQL, Redis
2. [MEMORY.md] DB 主机: db.acme.internal (PostgreSQL)
3. [USER.md] 数据库偏好: PostgreSQL > MySQL
# 高级搜索（支持逻辑运算符）
User: /memory search "API AND (认证 OR 密码)"
Agent: ...
# 在指定文件中搜索
User: /memory search --file USER.md "Python"
Agent: .../memory export —— 导出记忆
导出功能非常重要，用于备份和迁移：
# 导出所有记忆
User: /memory export
Agent: 记忆已导出到 ~/.hermes/exports/memory_backup_20260421_143052.json
# 指定文件名
User: /memory export my_backup
Agent: 记忆已导出到 ~/.hermes/exports/my_backup.json
# 导出格式选项
User: /memory export --format markdown
Agent: 记忆已导出到 ~/.hermes/exports/memory_backup_20260421.md导出文件的结构示例：
{
"export_time": "2026-04-21T14:30:52+08:00",
"hermes_version": "2.1.0",
"warm_memory": {
"MEMORY.md": "# Memory\n\n## Project\n...",
"USER.md": "# User\n\n## Profile\n..."
},
"cold_memory": {
"database_path": "~/.hermes/memory/hermes_memory.db",
"stats": {
"conversations": 147,
"messages": 3284,
"tool_calls": 892
}
},
"checksum": "sha256:a3f7d2e..."
}/memory import —— 导入记忆
与导出对应，导入让你可以恢复备份或迁移记忆：
# 从文件导入
User: /memory import my_backup.json
Agent: 正在导入记忆...
✓ MEMORY.md: 已导入 24 条记忆
✓ USER.md: 已导入 12 条记忆
⚠ 发现 3 条重复记忆，已跳过
导入完成。
# 合并模式（不覆盖已有记忆）
User: /memory import --merge my_backup.json
Agent: 已合并导入，原有记忆保持不变。
# 强制覆盖
User: /memory import --overwrite my_backup.json
Agent: ⚠ 这将覆盖所有现有记忆。确认吗？(y/N)/memory compact —— 压缩记忆文件
当 MEMORY.md 或 USER.md 接近容量上限时，可以手动压缩：
User: /memory compact
Agent:
正在压缩记忆文件...
MEMORY.md:
压缩前: 2,180 字符
压缩后: 1,560 字符
节省: 28.4%
合并了 3 组相似条目
删除了 2 条过期条目
USER.md:
压缩前: 1,320 字符
压缩后: 980 字符
节省: 25.8%
合并了 2 组相似条目压缩算法会：
- 合并语义相似的条目
- 删除明确过期的信息
- 缩短过长的描述
- 移除冗余的修饰词
/memory clear —— 清空记忆
⚠️ 危险操作！ 这个命令会删除所有记忆。使用前请确保已导出备份。
User: /memory clear
Agent: ⚠️ 警告：这将永久删除所有记忆！
包括：MEMORY.md、USER.md、SQLite 数据库中的所有历史记录。
建议先执行 /memory export 进行备份。
如果你确定要删除，请输入：DELETE ALL MEMORY
User: DELETE ALL MEMORY
Agent: 正在清空所有记忆...
✓ MEMORY.md 已清空
✓ USER.md 已清空
✓ SQLite 数据库已重置
✓ FTS5 索引已重建
所有记忆已清空。Agent 已恢复出厂状态。7.2 查看当前记忆状态
除了 /memory show，还有多种方式查看记忆状态：
方式一：使用 hermes status
$ hermes status --memory
记忆系统状态
═══════════════
温记忆:
MEMORY.md: 1,850 / 2,200 字符 (84.1%)
USER.md: 890 / 1,375 字符 (64.7%)
状态: 正常
冷记忆:
数据库: ~/.hermes/memory/hermes_memory.db
大小: 18.5 MB
会话: 147
消息: 3,284
工具调用: 892
文件操作: 456
FTS5 索引: 健康
最后维护: 2026-04-20 03:00
外部记忆:
Honcho: 未启用
Mem0: 已启用 (cloud)
OpenViking: 未启用
总体健康度: 良好 ✅
建议: USER.md 容量充足，MEMORY.md 接近上限，建议执行 /memory compact方式二：使用 hermes memory stats
$ hermes memory stats --detail
详细记忆统计
═══════════════
按时间分布:
今天: 23 条消息
本周: 156 条消息
本月: 892 条消息
本年: 3,284 条消息
按工具类型分布:
web_search: 234 次
file_read: 198 次
file_write: 145 次
code_execute: 112 次
git_commit: 67 次
...
按话题分布 (Top 10):
1. Python 开发 (456 条)
2. 数据库优化 (234 条)
3. API 设计 (189 条)
4. Docker 部署 (156 条)
5. 系统监控 (123 条)
...
高频关键词:
- FastAPI: 89 次
- PostgreSQL: 67 次
- Redis: 54 次
- Docker: 45 次
- pytest: 38 次7.3 手动添加/删除/修改记忆
除了命令，你还可以在对话中直接用自然语言管理记忆：
# 添加记忆（自然语言方式）
User: 记住，以后提到「老项目」就是指 customer-service-v1
Agent: 已记录到 MEMORY.md：「老项目」= customer-service-v1。
User: 我换手机号了，新号是 138-xxxx-8888
Agent: 已更新 USER.md 中的联系方式。
# 删除记忆
User: 忘掉关于「测试服务器密码」那条，密码已经改了
Agent: 已从 MEMORY.md 中删除包含"测试服务器密码"的条目。
User: 我不用 Django 了，从我的技术栈里删掉
Agent: 已从 USER.md 中删除 Django。
# 修改记忆
User: 更新一下 MEMORY.md，项目的截止日期改成 5 月 15 号
Agent: 已更新：截止日期从 2026-04-30 改为 2026-05-15。
User: 我的主要编程语言现在变成 Go 了，Python 排第二
Agent: 已更新 USER.md：主要语言改为 Go，Python 移到次要语言。这种方式更直观，不需要记住具体的命令语法。Agent 会理解你的意图并执行相应操作。
7.4 记忆搜索与检索
在冷记忆中搜索历史记录：
# 搜索历史对话
User: /search "Docker Compose"
Agent:
找到 12 条相关记录：
[2026-04-18] 你让 Agent 帮你编写了一个 Docker Compose 文件，
包含 PostgreSQL、Redis 和 Nginx 三个服务。
[2026-04-15] 你询问了 Docker Compose 的网络配置问题，
Agent 建议使用自定义 bridge 网络。
[2026-04-10] ...
要查看某条记录的完整内容，告诉我编号即可。
User: 显示第 1 条
Agent: [展示完整对话内容]高级搜索语法：
# 时间范围搜索
/search "Docker" --after 2026-04-01 --before 2026-04-20
# 按工具类型过滤
/search "API" --tool file_write
# 按会话标签过滤
/search "性能优化" --tag "project-alpha"
# 组合条件
/search "bug AND (修复 OR 解决)" --after 2026-03-017.5 记忆导出与备份
定期备份记忆是良好的数据管理习惯。以下是完整的备份策略：
手动备份：
# 完整备份（推荐每周执行一次）
$ hermes memory backup --full
备份完成:
文件: ~/.hermes/backups/full_backup_20260421.tar.gz
大小: 12.3 MB
包含:
✓ MEMORY.md
✓ USER.md
✓ hermes_memory.db
✓ FTS5 索引
✓ 配置文件
校验和: sha256:7a3f...
# 快速备份（只备份温记忆）
$ hermes memory backup --warm-only自动备份配置：
# config.yaml
memory:
backup:
enabled: true
schedule: "0 3 * * 0" # 每周日凌晨3点
retention: 10 # 保留最近 10 个备份
destination: "~/.hermes/backups"
compress: true # 压缩备份
encrypt: true # 加密备份（需要设置密码）
encryption_password: "${BACKUP_PASSWORD}" # 从环境变量读取备份文件结构：
~/.hermes/backups/
├── full_backup_20260414_030000.tar.gz
├── full_backup_20260407_030000.tar.gz
├── full_backup_20260331_030000.tar.gz
└── ...
恢复备份：
# 列出可用备份
$ hermes memory backup --list
可用备份:
1. full_backup_20260421_030000.tar.gz (12.3 MB)
2. full_backup_20260414_030000.tar.gz (11.8 MB)
...
# 恢复指定备份
$ hermes memory restore 1
⚠️ 这将覆盖当前所有记忆。确认吗？(y/N): y
正在恢复...
✓ 恢复完成7.6 记忆清理与维护
随着时间推移，记忆中会积累一些「垃圾数据」——过时的信息、重复的内容、测试时留下的临时数据。定期清理可以保持记忆系统的高效运作。
自动清理配置：
memory:
maintenance:
auto_cleanup: true
cleanup_schedule: "0 2 * * 0" # 每周日凌晨2点
# 清理规则
rules:
# 规则1：删除30天前的临时会话
- type: "delete_old_sessions"
age_days: 30
conditions:
- "message_count < 5" # 少于5条消息的会话
- "NOT tagged 'important'" # 且没有被标记为重要
# 规则2：合并重复的记忆条目
- type: "merge_duplicates"
similarity_threshold: 0.85
# 规则3：归档旧数据
- type: "archive"
age_days: 90
destination: "~/.hermes/memory/archive/"手动清理：
# 查看可以清理的内容
$ hermes memory cleanup --dry-run
预计可清理:
- 临时会话: 23 个 (可释放 2.1 MB)
- 重复记忆条目: 7 条 (可释放 350 字符)
- 已删除文件的引用: 12 条
总计可释放: ~2.5 MB
# 执行清理
$ hermes memory cleanup
正在清理...
✓ 已删除 23 个临时会话
✓ 已合并 7 条重复记忆
✓ 已清理 12 条失效引用
已释放 2.5 MB 空间
# 重建索引（如果检索变慢）
$ hermes memory rebuild-index
正在重建 FTS5 索引...
✓ 索引重建完成 (耗时 3.2s)7.7 定期维护建议
基于社区最佳实践，以下是推荐的记忆系统维护时间表：
| 频率 | 操作 | 命令/方法 |
|---|---|---|
| 每天 | 查看记忆容量状态 | /memory show |
| 每周 | 压缩温记忆 | /memory compact |
| 每周 | 执行自动清理 | hermes memory cleanup |
| 每月 | 完整备份 | hermes memory backup --full |
| 每季度 | 回顾和清理 USER.md | 手动编辑或让 Agent 协助 |
| 每季度 | 重建 FTS5 索引 | hermes memory rebuild-index |
| 每年 | 归档旧数据 | 导出并归档到外部存储 |
Tips
建议在日历中设置定期提醒，或者使用 Hermes 的 Cron 功能自动执行维护任务：
# config.yaml cron: - schedule: "0 3 * * 0" # 每周日凌晨3点 command: "hermes memory cleanup && hermes memory backup --full"
8. SOUL.md 深度配置
8.1 SOUL.md 与记忆系统的关系
SOUL.md 是 Hermes 中最特殊的配置文件。它不是传统意义上的「记忆」（它不记录历史信息），但它直接影响记忆系统的工作方式。可以把 SOUL.md 理解为 Agent 的「人格设定」和「工作守则」，它决定了 Agent 如何对待记忆、如何使用记忆、以及如何在记忆中筛选信息。
SOUL.md 与记忆系统的关系可以用一个类比来理解：
- SOUL.md 是公司的《员工手册》，规定了员工应该如何工作
- MEMORY.md 是员工手边的「项目笔记本」，记录具体项目的注意事项
- USER.md 是员工的「客户档案」，记录服务对象的偏好
- SQLite 是公司的「档案室」，存放所有历史资料
没有 SOUL.md，Agent 就不知道「我是谁」「我应该怎么工作」「什么信息值得记住」。
SOUL.md 默认位于：
~/.hermes/SOUL.md
8.2 高效 SOUL.md 模板大全
根据不同的使用场景，SOUL.md 的内容应该有所不同。以下提供 5 个经过社区验证的高效模板。
模板一：投研助手
# SOUL — 投研助手
## 身份
你是专业的投研分析师，擅长从海量信息中提取投资逻辑，
生成结构化的研究报告。
## 工作准则
1. 所有数据来源必须标注，不可编造数据
2. 财务指标计算必须展示公式和过程
3. 风险提示必须用单独章节呈现
4. 观点必须区分「事实」「推断」「猜测」
## 记忆策略
- 记住用户关注的行业和个股
- 记录每次研究的关键结论和置信度
- 保留重要的财务数据和估值模型
- 建立「观点追踪」：记录观点的形成时间和修正历史
## 输出格式
- 标题层级不超过 3 级
- 关键数据用表格呈现
- 图表用 Mermaid 或 ASCII 绘制
- 报告末尾附「信息来源」和「免责声明」
## 语言风格
- 专业、客观、冷静
- 避免使用「肯定」「绝对」等确定性词汇
- 多用「数据显示」「从...来看」「如果...则」
## 特殊规则
- 涉及具体股票时，必须提醒「不构成投资建议」
- 使用 MEMORY.md 记录：关注列表、估值模型参数、研究进度
- 使用 USER.md 了解用户的风险偏好和投资周期模板二：编程助手
# SOUL — 编程助手
## 身份
你是资深全栈工程师，代码风格严谨，注重可维护性和性能。
## 工作准则
1. 所有代码必须包含类型注解和 docstring
2. 必须先写测试用例，再写实现代码（TDD）
3. 复杂逻辑必须添加注释说明「为什么」而非「做什么」
4. 提交代码前必须运行 linter 和 formatter
## 记忆策略
- 记住项目的技术栈和架构决策
- 记录代码规范和团队约定
- 保留重要 API 的接口定义
- 建立「常见错误」清单，避免重复犯错
## 代码规范
- Python: PEP8 + Black + isort + mypy --strict
- JavaScript: ESLint + Prettier + TypeScript strict
- Go: gofmt + golint + go vet
- Rust: rustfmt + clippy
- Git: conventional commits
## 调试策略
1. 先看日志，再看代码
2. 用二分法定位问题
3. 修复后必须添加回归测试
4. 复杂 bug 记录到 MEMORY.md，避免重复踩坑
## 特殊规则
- 遇到不确定的 API 行为，先查官方文档而非猜测
- 涉及安全（密码、密钥、Token）时，提醒用户检查 .env 配置
- 重构前先备份，使用 git branch 隔离变更模板三：写作助手
# SOUL — 写作助手
## 身份
你是专业编辑和内容策略师，帮助用户产出高质量的文字内容。
## 工作准则
1. 先理解受众和目的，再开始写作
2. 每个段落只讲一个核心观点
3. 使用主动语态，少用被动语态
4. 删除所有不必要的副词和形容词
## 记忆策略
- 记住用户的写作风格和常用表达
- 记录用户的品牌调性和内容禁忌
- 保留高质量的文章模板和框架
- 建立「金句库」和「案例库」
## 写作流程
1. 需求澄清：确定主题、受众、目的、长度
2. 大纲构建：列出核心观点和支撑论据
3. 初稿撰写：快速产出，不纠结细节
4. 修改润色：检查逻辑、删减冗余、优化表达
5. 终稿确认：检查事实、校对文字
## 风格偏好（从 USER.md 获取）
- 根据用户的行业调整专业度
- 根据用户的受众调整语言难度
- 根据用户的品牌调整语气（正式/亲和/幽默）
## 特殊规则
- 涉及数据时必须标注来源
- 引用他人观点必须注明出处
- 避免使用 AI 味重的表达（如「值得注意的是」「总的来说」）
- 中文写作时，技术术语保留英文，其余用中文模板四：客服助手
# SOUL — 客服助手
## 身份
你是专业的客户服务代表，代表公司与客户沟通。
你的目标是：快速理解客户问题，提供准确有效的解决方案，
同时维护公司形象和客户满意度。
## 工作准则
1. 首次回复必须在理解问题后 30 秒内给出
2. 每个回复都要包含「共情表达」+「解决方案」+「下一步行动」
3. 不确定的答案不要猜测，明确说「我需要确认一下」
4. 涉及退款/赔偿等敏感操作，必须按流程升级
## 记忆策略
- 记住客户的历史工单和解决记录
- 记录常见问题和标准答案（FAQ）
- 保留产品已知问题和 workaround
- 记录客户的情绪状态和沟通风格
## 沟通模板
**开场白：**
"您好，感谢您联系客服。我是您的专属客服助手。
我已经查看了您的账户信息，请问有什么可以帮您？"
**问题确认：**
"我理解您的意思是...（复述问题），对吗？"
**提供方案：**
"针对您的问题，我建议...
[方案1] ...
[方案2] ...
您希望选择哪种方式？"
**结束语：**
"问题已解决/正在处理中。如有其他问题随时联系。
祝您使用愉快！"
## 升级规则
以下情况必须转人工：
- 客户明确要求人工
- 涉及法律纠纷
- 退款金额超过 $100
- 客户情绪极度激动
- 技术问题超出知识库范围
## 特殊规则
- 绝不透露其他客户的信息
- 绝不承诺无法兑现的服务
- 所有承诺必须记录到 MEMORY.md模板五：个人助理
# SOUL — 个人助理
## 身份
你是用户的私人助理，帮助管理日程、提醒事项、信息整理和日常决策。
你像一位经验丰富、值得信赖的行政助理。
## 工作准则
1. 主动但不越界——提供建议，但不替用户做决定
2. 时间管理优先于任务管理——帮助用户决定「什么时候做」而非「做什么」
3. 信息过滤——只推送用户真正关心的信息
4. 保护隐私——绝不泄露用户的个人信息
## 记忆策略
- 记住用户的日程安排和截止日期
- 记录重要联系人和关系网络
- 保留用户的生活习惯和偏好
- 建立「待办事项」和「购物清单」
## 日常流程
**每天早上：**
- 查看当日日程
- 提醒即将到期的事项
- 建议今日优先级
**每周一：**
- 总结上周完成情况
- 规划本周重点任务
- 检查长期目标的进度
**每月初：**
- 回顾上月支出（如配置了记账）
- 更新目标和计划
- 清理过期的提醒和清单
## 提醒规则
- 重要事项提前 1 天提醒
- 紧急事项提前 2 小时提醒
- 周期性事项（生日、纪念日）提前 1 周提醒
- 用户说过「别忘了...」的事项，在合适的时间提醒
## 特殊规则
- 涉及金钱决策时，提供分析但不建议
- 涉及健康问题时，建议咨询专业人士
- 涉及人际关系时，保持中立和同理心
- 使用 MEMORY.md 记录：待办事项、重要日期、购物清单8.3 让 Agent 自动优化 SOUL.md 的技巧
SOUL.md 不是一成不变的。随着你使用 Hermes 的时间增长，你会发现某些规则有效、某些规则需要调整。Hermes 支持让 Agent 自动优化 SOUL.md。
技巧一：定期回顾
User: 回顾过去两周的对话，看看 SOUL.md 中有哪些规则经常被我纠正或忽略
Agent:
分析了过去 30 个会话，发现：
- 「所有代码必须包含类型注解」这条你经常补充说明「这次不用」
建议：添加例外规则「脚本/原型代码可省略类型注解」
- 「先写测试再写实现」在实际工作中执行率只有 30%
建议：改为「重要模块必须写测试，脚本/工具可灵活处理」
- 你多次要求 Agent 用中文解释技术概念
建议：在语言风格中添加「技术概念优先用中文解释」
是否应用这些优化？
User: 应用
Agent: 已更新 SOUL.md。技巧二：A/B 测试
你可以维护两个版本的 SOUL.md，测试哪个效果更好：
~/.hermes/
├── SOUL.md # 当前版本
├── SOUL.md.v1 # 版本1（控制组）
└── SOUL.md.v2 # 版本2（实验组）
切换版本：
User: 切换到 SOUL 版本 2
Agent: 已加载 SOUL.md.v2，本次会话将使用新版本。技巧三：分场景 SOUL
为不同任务类型准备不同的 SOUL.md：
# config.yaml
soul:
default: "~/.hermes/SOUL.md"
profiles:
coding: "~/.hermes/SOUL-coding.md"
writing: "~/.hermes/SOUL-writing.md"
research: "~/.hermes/SOUL-research.md"在对话中切换：
User: /soul coding
Agent: 已切换至编程助手人格。8.4 SOUL.md 的版本管理
SOUL.md 是核心配置文件，建议使用版本控制：
# 初始化 Git 仓库
$ cd ~/.hermes
$ git init
$ git add SOUL.md MEMORY.md USER.md config.yaml
$ git commit -m "初始配置"
# 每次修改后提交
$ git add SOUL.md
$ git commit -m "优化代码规范：允许原型代码省略类型注解"
# 查看修改历史
$ git log --oneline SOUL.md
a3f7d2e 优化代码规范：允许原型代码省略类型注解
c8e9b1a 添加调试策略章节
f2d4e8c 初始配置
# 回退到某个版本
$ git checkout f2d4e8c -- SOUL.md你也可以让 Hermes 帮你管理版本：
User: 保存当前 SOUL.md 为 "v2.1-宽松版"
Agent: 已保存快照：SOUL.md.v2.1-宽松版
User: 列出所有 SOUL 版本
Agent:
可用版本:
1. v1.0-初始版 (2026-03-01)
2. v1.1-添加写作规则 (2026-03-15)
3. v2.0-严格版 (2026-04-01)
4. v2.1-宽松版 (当前)
User: 回退到 v2.0-严格版
Agent: 已回退到 v2.0-严格版。9. 隐私与安全
9.1 纯本地存储的安全优势
Hermes 记忆系统最核心的安全特性就是：所有数据默认存储在本地。
这意味着：
- 数据不出境：你的对话内容、工作文件、个人偏好，永远不会离开你的电脑
- 无网络依赖：即使没有网络，记忆系统也能正常工作
- 无第三方访问：没有云服务提供商能看到你的数据
- 完全可控：你可以随时查看、修改、删除任何数据
对比一下云端方案：
| 维度 | Hermes 本地存储 | 云端记忆服务 |
|---|---|---|
| 数据位置 | 你的电脑 | 服务商的服务器 |
| 网络依赖 | 无 | 必须有网络 |
| 隐私控制 | 完全自主 | 依赖服务商政策 |
| 数据泄露风险 | 低（物理安全） | 中（依赖服务商安全） |
| 合规审计 | 容易 | 困难 |
| 跨设备同步 | 需手动 | 自动 |
对于处理敏感信息的用户（如企业内网开发、医疗数据处理、金融分析），纯本地存储几乎是必选方案。
9.2 数据加密选项
虽然本地存储已经很安全，但如果你有多人共用电脑、或者担心电脑被盗，可以启用数据加密。
SQLite 数据库加密：
SQLite 本身不内置加密，但可以通过 SQLCipher 扩展实现：
# 安装 SQLCipher
$ brew install sqlcipher # macOS
$ apt-get install sqlcipher # Ubuntu
# 在 Hermes 配置中启用
```yaml
memory:
encryption:
enabled: true
provider: "sqlcipher"
# 密码从环境变量读取，不会写入配置文件
password_env: "HERMES_DB_PASSWORD"设置环境变量
$ export HERMES_DB_PASSWORD="your-strong-password"
启用加密后，即使有人拿到了你的 `.db` 文件，没有密码也无法读取内容。
**温记忆文件加密：**
MEMORY.md 和 USER.md 是纯文本文件，可以用 GPG 加密：
```bash
# 加密
$ gpg --symmetric --cipher-algo AES256 ~/.hermes/memory/MEMORY.md
# 会生成 MEMORY.md.gpg
# 解密（Hermes 启动时自动执行）
$ gpg --decrypt ~/.hermes/memory/MEMORY.md.gpg > ~/.hermes/memory/MEMORY.md
Hermes 支持自动加解密配置：
memory:
encryption:
warm_memory:
enabled: true
method: "gpg"
key_id: "your-gpg-key-id"9.3 敏感信息过滤机制
即使数据存储在本地，你仍然可能不小心在对话中透露敏感信息（如密码、API 密钥、身份证号）。Hermes 提供了敏感信息过滤机制：
自动检测与替换：
security:
sensitive_data_filter:
enabled: true
# 检测规则
patterns:
- name: "api_key"
regex: "(sk-|ak-|pk-)[a-zA-Z0-9]{20,}"
action: "hash_and_store" # 哈希存储，不存明文
- name: "password"
regex: "(?i)(password|passwd|pwd)\s*[:=]\s*[^\s]+"
action: "redact" # 替换为 [REDACTED]
- name: "credit_card"
regex: "\b(?:\d{4}[-\s]?){3}\d{4}\b"
action: "block" # 阻止保存
- name: "id_card"
regex: "\d{17}[\dXx]|\d{15}"
action: "block"
# 自定义规则
custom_patterns:
- name: "internal_ip"
regex: "10\.\d{1,3}\.\d{1,3}\.\d{1,3}"
action: "redact"效果示例：
用户输入: "我的 API Key 是 sk-abc123xyz789..."
存储到数据库前:
→ 检测到 api_key 模式
→ 替换为: "我的 API Key 是 [API_KEY_HASH:a3f7d2e...]"
→ 原始密钥不存储，只存哈希值
用户输入: "密码是 Secret123!"
存储到数据库前:
→ 检测到 password 模式
→ 替换为: "密码是 [REDACTED]"
注意
敏感信息过滤只在存储到冷记忆（SQLite）时生效。如果你让 Agent 把敏感信息写入 MEMORY.md，它仍然会以明文形式存储在文件中（虽然文件在本地）。建议不要把真正的密码写入 MEMORY.md，而是使用环境变量或密码管理器。
9.4 数据备份加密方案
前面我们讲了如何备份记忆。如果备份文件也需要加密（比如你要把备份存到云盘）：
# 方法1：使用 GPG 加密备份
$ tar czf - ~/.hermes/memory/ | gpg --symmetric --cipher-algo AES256 > backup_20260421.tar.gz.gpg
# 解密恢复
$ gpg --decrypt backup_20260421.tar.gz.gpg | tar xzf -
# 方法2：使用 age（更现代的加密工具）
$ tar czf - ~/.hermes/memory/ | age -p > backup_20260421.tar.gz.age
# 方法3：使用 Hermes 内置的备份加密
$ hermes memory backup --full --encrypt --password-file ~/.hermes/.backup_pass9.5 与云端记忆方案的隐私对比
最后，我们用一张详细的对比表来总结 Hermes 本地记忆与云端记忆的隐私差异：
| 隐私维度 | Hermes 本地 | 云端记忆服务 |
|---|---|---|
| 数据存储位置 | 用户设备 | 服务商服务器 |
| 数据传输 | 无（纯本地） | 必须通过HTTPS上传 |
| 服务商能否读取数据 | 不能 | 技术上可以（依赖信任） |
| 政府/法律调取 | 需物理获取设备 | 服务商可能被迫提供 |
| 数据删除彻底性 | 用户自行删除，可控 | 依赖服务商执行 |
| 加密密钥控制 | 用户持有 | 服务商持有或托管 |
| 审计能力 | 完全透明 | 黑盒 |
| 合规认证（SOC2/ISO27001） | 不适用 | 需查验服务商证书 |
结论：
- 如果你处理的是公开信息或非敏感数据，云端记忆的便利性可能更重要
- 如果你处理的是企业机密、个人隐私或受监管数据，Hermes 的纯本地存储是更安全的选择
- 最佳实践是：敏感数据用本地存储，非敏感数据可选择云端扩展
10. 高级配置与调优
10.1 记忆相关 config.yaml 参数详解
config.yaml 是 Hermes 的核心配置文件，其中与记忆系统相关的参数众多。以下是完整参数说明：
# ~/.hermes/config.yaml
memory:
# ═══════════════════════════════════════
# 温记忆配置
# ═══════════════════════════════════════
warm:
# MEMORY.md 的最大字符数（软限制）
max_memory_md_chars: 2200
# USER.md 的最大字符数（软限制）
max_user_md_chars: 1375
# 自动压缩阈值（超过此比例自动触发 compact）
auto_compact_threshold: 0.85
# 温记忆文件路径
memory_md_path: "~/.hermes/memory/MEMORY.md"
user_md_path: "~/.hermes/memory/USER.md"
# 自动写入的触发条件
auto_write:
enabled: true
triggers:
- explicit_request # 用户明确要求记录
- task_completion # 任务完成时
- important_decision # 重要决策时
- session_end # 会话结束时
# ═══════════════════════════════════════
# 冷记忆配置
# ═══════════════════════════════════════
cold:
# SQLite 数据库路径
db_path: "~/.hermes/memory/hermes_memory.db"
# FTS5 配置
fts5:
enabled: true
tokenizer: "porter" # 分词器: porter / simple / icu
# 检索配置
retrieval:
# 每次检索返回的最大片段数
max_fragments: 5
# 每个片段的最大 Token 数
fragment_max_tokens: 150
# 检索的时间范围（天）
time_decay_days: 90
# 检索时使用的字段权重
field_weights:
message_content: 1.0
tool_result: 0.8
file_operation: 0.6
summary: 1.2
# 相似度阈值（低于此值的结果丢弃）
min_relevance_score: 0.3
# 会话摘要配置
summarization:
enabled: true
# 摘要模型（使用主模型或轻量模型）
model: "same_as_main" # 或指定如 "gpt-4o-mini"
max_summary_length: 200
# 数据保留策略
retention:
# 保留策略类型: forever / age_based / count_based
policy: "age_based"
# 按时间保留：超过此天数的会话归档
max_age_days: 365
# 按数量保留：最多保留多少条会话
max_conversations: 2000
# 归档路径（不删除，只移动）
archive_path: "~/.hermes/memory/archive/"
# ═══════════════════════════════════════
# 热记忆配置
# ═══════════════════════════════════════
hot:
# 上下文管理策略
context_management:
# 自动 compact 触发阈值（上下文使用比例）
auto_compact_threshold: 0.75
# 压缩时保留的最近消息数
preserve_recent: 5
# 溢出时的处理策略: compact / truncate / error
overflow_strategy: "compact"
# 系统提示和 SOUL.md 是否计入上下文限制
count_system_in_limit: true
# ═══════════════════════════════════════
# 外部记忆配置
# ═══════════════════════════════════════
external:
honcho:
enabled: false
# 详见第6章
mem0:
enabled: false
# 详见第6章
openviking:
enabled: false
# 详见第6章
# ═══════════════════════════════════════
# 维护配置
# ═══════════════════════════════════════
maintenance:
# 自动维护任务
auto_cleanup:
enabled: true
schedule: "0 2 * * 0" # Cron 表达式
# 备份配置
backup:
enabled: true
schedule: "0 3 * * 0"
retention: 10
encrypt: false
destination: "~/.hermes/backups"
# 索引优化
index_optimization:
enabled: true
schedule: "0 4 1 * *" # 每月1日凌晨4点10.2 记忆保留策略调整
根据你的使用习惯，可以调整记忆的保留策略：
场景一：短期项目（1-3个月）
memory:
cold:
retention:
policy: "age_based"
max_age_days: 90 # 只保留3个月
archive_path: "~/.hermes/memory/archive/"
warm:
auto_compact_threshold: 0.70 # 更频繁地压缩场景二：长期知识积累（1年以上）
memory:
cold:
retention:
policy: "count_based"
max_conversations: 5000 # 保留大量会话
max_age_days: 730 # 最多2年
warm:
auto_compact_threshold: 0.90 # 允许温记忆更满场景三：极简模式（只保留关键信息）
memory:
cold:
retention:
policy: "age_based"
max_age_days: 30 # 只保留1个月
summarization:
enabled: true # 但必须生成摘要
warm:
auto_compact_threshold: 0.60 # 频繁压缩
max_memory_md_chars: 1500 # 更小的温记忆
max_user_md_chars: 100010.3 检索精度 vs 召回率的平衡
在信息检索领域，有两个核心指标：
- 精度（Precision）：检索到的结果中，真正相关的比例。精度高 = 垃圾结果少
- 召回率（Recall）：所有相关结果中，被检索到的比例。召回率高 = 漏掉的少
这两个指标通常此消彼长。在 Hermes 中，你可以通过参数调整这个平衡：
偏向精度（适合明确知道要找什么的场景）：
memory:
cold:
retrieval:
max_fragments: 3 # 只取最相关的结果
min_relevance_score: 0.6 # 提高门槛
fragment_max_tokens: 100 # 更短的片段偏向召回率（适合探索性查询，宁可多不要漏）：
memory:
cold:
retrieval:
max_fragments: 10 # 取更多结果
min_relevance_score: 0.1 # 降低门槛
fragment_max_tokens: 200 # 更长的片段
time_decay_days: 180 # 更广的时间范围10.4 大数据量下的性能优化
当数据库增长到几百 MB 甚至 GB 级别时，检索速度可能会下降。以下是优化策略：
策略一：分区存储
memory:
cold:
# 按时间分区，每个季度的数据一个数据库文件
partitioning:
enabled: true
granularity: "quarterly" # monthly / quarterly / yearly
# 检索时只查最近的分区，除非用户明确要求
retrieval:
default_partitions: 2 # 默认查最近2个分区策略二：索引优化
# 手动执行索引优化
$ hermes memory optimize-index
# 这个命令会：
# 1. 重建 FTS5 索引（消除碎片）
# 2. 运行 ANALYZE 优化查询计划
# 3. 清理已删除数据占用的空间（VACUUM）策略三：读写分离
如果你需要同时进行大量写入和查询：
memory:
cold:
# 写入到主库，查询从副本
replication:
enabled: true
sync_interval: 60 # 每60秒同步一次策略四：硬件加速
memory:
cold:
# 使用 SSD（如果还没用的话）
# SQLite 在 SSD 上性能提升数倍
# 调整缓存大小
pragma:
cache_size: 10000 # 页面数（约 40 MB）
temp_store: "memory" # 临时表存内存
journal_mode: "wal" # Write-Ahead Logging，提高并发10.5 hermes status 查看记忆统计
hermes status 是监控记忆系统健康状况的重要工具。让我们详细解读它的输出：
$ hermes status --verbose
═══════════════════════════════════════════════════
Hermes Agent Status
═══════════════════════════════════════════════════
版本: 2.1.0
运行时间: 3天 7小时 22分钟
── 模型 ──────────────────────────────────────────
当前模型: claude-3-7-sonnet-20250219
上下文窗口: 32,000 Tokens
当前使用: 8,450 Tokens (26.4%)
- 系统提示: 450 Tokens
- SOUL.md: 320 Tokens
- USER.md: 180 Tokens
- MEMORY.md: 290 Tokens
- 冷记忆片段: 210 Tokens
- 对话历史: 7,000 Tokens
── 记忆系统 ──────────────────────────────────────
温记忆:
MEMORY.md:
大小: 1,850 / 2,200 字符 (84.1%) ⚠️ 接近上限
上次更新: 2小时前
条目数: 23
USER.md:
大小: 890 / 1,375 字符 (64.7%) ✅ 正常
上次更新: 1天前
条目数: 15
冷记忆:
数据库: ~/.hermes/memory/hermes_memory.db
文件大小: 18.5 MB
统计:
会话: 147
消息: 3,284
工具调用: 892 (成功率: 94.2%)
文件操作: 456
记忆片段: 1,234
FTS5 索引:
状态: ✅ 健康
索引大小: 2.3 MB
最后优化: 2天前
碎片化程度: 12% (正常范围)
检索性能:
平均响应时间: 23ms
99分位响应时间: 87ms
近7天查询次数: 234
外部记忆:
Honcho: 未启用
Mem0: ✅ 已启用 (cloud)
同步状态: 已同步 (2分钟前)
云端记忆数: 156
OpenViking: 未启用
── 健康度评估 ────────────────────────────────────
总体健康度: 良好 (85/100)
建议:
1. ⚠️ MEMORY.md 使用率超过 80%，建议执行 /memory compact
2. ℹ️ FTS5 索引已 2 天未优化，建议执行 hermes memory optimize-index
3. ✅ 其他指标正常
── 资源使用 ──────────────────────────────────────
CPU: 2.3% (平均)
内存: 245 MB
磁盘: 18.5 MB (记忆) + 45.2 MB (其他)
网络: 1.2 KB/s (Mem0 同步)
═══════════════════════════════════════════════════重点关注这些指标：
- 上下文使用率：超过 70% 就应该 compact
- 温记忆使用率：超过 85% 需要清理或压缩
- FTS5 碎片化：超过 30% 需要优化
- 检索响应时间：超过 200ms 需要优化索引
- 工具调用成功率：低于 90% 可能表示配置问题
11. 常见问题与排障
11.1 记忆不生效？
症状： 你明明告诉 Agent 记住了某件事情，但下次会话时它似乎「忘了」。
排查步骤：
步骤1：检查记忆是否真的被写入
User: /memory show看看你要记住的内容是否在 MEMORY.md 或 USER.md 中。如果没有，说明写入失败了。
步骤2：检查写入时机
如果你是在会话中途让 Agent 记住的，但随后会话崩溃了（比如网络断开），写入可能没有完成。建议在让 Agent 记住重要信息后，再确认一次：
User: 记住了吗？给我看看 MEMORY.md
Agent: [展示内容]步骤3：检查容量是否已满
如果 MEMORY.md 或 USER.md 已经达到容量上限，新内容可能无法写入：
User: /memory show
# 查看使用率是否 100%如果是满的，执行 /memory compact 或手动删除不重要的条目。
步骤4：检查检索是否被触发
有时候记忆确实存储了，但检索时没有匹配到。可能是因为：
- 你的查询关键词和记忆中存储的关键词不匹配
- 检索的时间范围太窄（只查最近7天，但记忆是30天前的）
- 相关度阈值太高，结果被过滤掉了
尝试扩大检索范围：
memory:
cold:
retrieval:
time_decay_days: 365 # 扩大时间范围
min_relevance_score: 0.1 # 降低门槛步骤5：检查外部记忆冲突
如果你同时启用了外部记忆（如 Mem0），可能存在数据不一致：
User: 当前使用哪些记忆来源？
Agent: 正在使用：本地 SQLite、Mem0 Cloud。
本地记忆：156 条会话
Mem0 记忆：89 条记录
注意：Mem0 中的部分记忆与本地记忆有冲突（3条）。如果有冲突，优先使用本地记忆，或手动同步两个来源。
11.2 记忆太多太杂？
症状： MEMORY.md 里塞满了各种信息，Agent 经常被不相关的内容干扰。
解决方案：
方案1：分类管理
把 MEMORY.md 按项目/主题分成多个文件：
~/.hermes/memory/
├── MEMORY.md # 通用记忆
├── MEMORY-project-alpha.md # 项目A
├── MEMORY-project-beta.md # 项目B
└── MEMORY-personal.md # 个人事务
在对话中切换：
User: 切换到 project-alpha 的记忆
Agent: 已加载 MEMORY-project-alpha.md。方案2：定期审计
每月让 Agent 帮你审查 MEMORY.md：
User: 审查一下 MEMORY.md，删除过时的、合并重复的
Agent:
审查结果:
建议删除（已过时）:
- "测试服务器地址: 192.168.1.50" (服务器已下线)
- "项目 deadline: 2026-03-01" (已过期)
建议合并（内容重复）:
- 3 条关于 API 地址的条目 → 合并为 1 条
建议保留:
- 所有关于技术栈的信息
- Git 仓库地址
是否执行这些修改？
User: 执行
Agent: 已优化 MEMORY.md。
删除: 4 条
合并: 3 条 → 1 条
当前使用率: 68% (原为 94%)方案3：使用标签系统
给记忆条目打标签，便于分类和筛选：
## Project [tag:work, tag:active]
- 项目名称: Alpha
- 状态: 进行中
## Personal [tag:personal]
- 生日提醒: 妈妈的生日是 5 月 15 日
## Archived [tag:work, tag:archived]
- 旧项目 Beta 的信息...11.3 检索结果不准确？
症状： 你搜索某个关键词，返回的结果完全不相关；或者明明记得某件事情，却检索不到。
原因和解决方案：
原因1：分词问题（尤其是中文）
FTS5 的默认分词器对中文支持不够好。如果你搜索「数据分析」，它可能只匹配「数」「据」「分」「析」单独出现的情况。
解决： 确保启用了适合中文的分词器：
memory:
cold:
fts5:
tokenizer: "icu zh_CN" # 使用 ICU 分词器，中文支持更好或者安装 jieba 分词器：
pip install jiebamemory:
cold:
fts5:
tokenizer: "jieba"原因2：关键词不匹配
你可能搜索「Docker」，但记忆中写的是「容器化技术」。
解决： 使用更宽泛的搜索词，或让 Agent 帮你找：
User: 帮我找找关于容器部署的记录
Agent: 找到以下内容（包含 Docker、Kubernetes、container 等关键词）...原因3：时间范围过滤
默认只检索最近 90 天的记录，你要找的内容可能是半年前的。
解决： 扩大时间范围：
User: /search "Docker" --after 2025-01-01原因4：相关度阈值过高
如果 min_relevance_score 设置得太高（如 0.8），很多相关但匹配度不够高的结果会被过滤掉。
解决： 暂时降低阈值：
memory:
cold:
retrieval:
min_relevance_score: 0.111.4 数据库损坏修复
SQLite 数据库虽然稳定，但在极端情况下（如电脑突然断电、磁盘空间不足、文件系统损坏）可能会损坏。
症状：
- Hermes 启动时报数据库错误
- 检索功能完全失效
hermes status显示数据库异常
修复步骤：
步骤1：备份当前数据库
$ cp ~/.hermes/memory/hermes_memory.db ~/.hermes/memory/hermes_memory.db.bak步骤2：检查数据库完整性
$ sqlite3 ~/.hermes/memory/hermes_memory.db "PRAGMA integrity_check;"如果返回 ok，说明数据库结构完整。如果返回错误信息，继续下一步。
步骤3：尝试修复
# 方法1：使用 SQLite 的恢复模式
$ sqlite3 ~/.hermes/memory/hermes_memory.db ".recover" | sqlite3 ~/.hermes/memory/hermes_memory_fixed.db
# 方法2：使用 Hermes 内置修复工具
$ hermes memory repair --force步骤4：如果修复失败，从备份恢复
# 使用最近的自动备份
$ hermes memory restore --latest
# 或手动恢复
$ cp ~/.hermes/backups/full_backup_20260414/hermes_memory.db ~/.hermes/memory/步骤5：如果备份也损坏
最坏的情况下，你可以重建数据库：
$ hermes memory reset
# 这会删除所有冷记忆，但保留温记忆（MEMORY.md 和 USER.md）注意
数据库损坏的情况非常罕见（SQLite 被设计为在断电时也能保持数据完整）。真正发生损坏时，通常是磁盘硬件问题。建议定期检查磁盘健康状态，并保持定期备份的习惯。
11.5 迁移时记忆丢失？
症状： 你把 Hermes 从一台电脑迁移到另一台电脑，发现记忆「丢失」了。
原因： 记忆文件没有正确迁移，或者路径配置不一致。
正确的迁移步骤：
步骤1：在旧机器上导出完整备份
$ hermes memory backup --full
备份已保存到: ~/.hermes/backups/full_backup_20260421.tar.gz步骤2：复制配置文件和记忆目录
# 需要复制的文件和目录
~/.hermes/config.yaml
~/.hermes/SOUL.md
~/.hermes/memory/ # 整个记忆目录
~/.hermes/skills/ # 如果有自定义技能步骤3：在新机器上安装 Hermes
# 按照安装指南安装 Hermes
# 但不要启动，等配置文件复制完成后再启动步骤4：复制文件到新机器
# 使用 scp
$ scp -r ~/.hermes/ user@new-machine:~/
# 或使用云存储同步
# 将 ~/.hermes/ 放入 Dropbox / iCloud / OneDrive 同步步骤5：验证路径配置
# 检查 config.yaml 中的路径是否匹配新机器
memory:
cold:
db_path: "~/.hermes/memory/hermes_memory.db" # 使用 ~ 会自动解析为当前用户目录如果使用绝对路径，需要确保新机器上的路径一致。
步骤6：启动 Hermes 并验证
$ hermes status --memory
# 检查会话数、消息数是否与旧机器一致
$ /memory show
# 检查 MEMORY.md 和 USER.md 内容是否完整
$ /search "测试"
# 检查冷记忆检索是否正常常见问题：
- 权限问题：确保新机器上的文件权限正确（
chmod 600对于敏感文件） - 路径问题：Windows 和 macOS/Linux 的路径格式不同，注意转换
- 版本兼容：如果新旧机器的 Hermes 版本差异很大，可能需要升级数据库格式：
hermes memory migrate
本章小结
恭喜你读完了这本白皮书中最「硬核」的一章！让我们回顾一下核心要点：
四层温度记忆模型是 Hermes 记忆系统的核心架构：
- 热记忆（会话上下文）—— 快速但易逝，善用
/compact管理 - 温记忆（MEMORY.md + USER.md）—— 持久但精简，是 Agent 的「随身记事本」
- 冷记忆（SQLite + FTS5）—— 海量但按需，智能检索让成本降低 88%
- 外部记忆（Honcho/Mem0 等）—— 扩展能力强，按需集成
关键操作命令：
/compact—— 压缩会话上下文，节省 Token/memory show—— 查看记忆状态/memory add/remove/edit—— 管理温记忆hermes memory backup—— 定期备份hermes memory cleanup—— 清理维护
最佳实践：
- 定期使用
/compact，不要让上下文无限增长 - 善用 MEMORY.md 记录项目信息，善用 USER.md 记录个人偏好
- 温记忆容量有限，只记录真正重要的信息
- 按需检索比全量加载高效 20 倍，是 Hermes 的核心优势
- 定期备份，定期维护，保持记忆系统健康
- SOUL.md 决定了 Agent 如何使用记忆，花时间为不同场景配置合适的模板
隐私与安全：
- 纯本地存储是 Hermes 的最大安全优势
- 如需更高安全性，可启用 SQLite 加密和文件加密
- 敏感信息过滤机制防止意外泄露
- 云端扩展虽好，但敏感数据建议留在本地
记忆系统是 Hermes Agent 的灵魂。没有记忆，Agent 只是一个「聪明的聊天机器人」；有了记忆，Agent 才能真正成为你的「长期搭档」——它记得你的偏好、了解你的项目、回顾你的历史，每一次交互都在积累对「你」的理解。
正如一个好的合作伙伴，不是因为他聪明（市面上聪明的 AI 很多），而是因为他懂你。Hermes 的记忆系统，正在让这种「懂」成为可能。