三层记忆：从金鱼到老友
04 三层记忆：从金鱼到老友
Three-Layer Memory: From Goldfish to Old Friend
大多数AI聊天工具的记忆像金鱼，上一轮说的话下一轮就忘了。Hermes的目标是做一个老友：记得你说过什
么，知道你是什么样的人，还学会了你做事的方式。
为什么记忆是最难的问题
你可能觉得AI的记忆不就是存聊天记录吗？存下来，下次加载进去就行了。
没那么简单。一个活跃用户每天跟AI聊几千字，一个月就是几万字。全塞进上下文窗口，要么装不下，要么模型因为信息
太多反而变迟钝。而且聊天记录里大部分是废话和重复，真正有价值的信息可能只占10%。
好的记忆系统不是存得多，是找得准。
Hermes用三层架构解决这个问题，每一层处理不同类型的记忆。
第一层：会话记忆
会话记忆回答的问题是：发生了什么？
每轮对话的内容、工具调用和返回结果，全部写入SQLite数据库，同时建FTS5全文搜索索引。这是情景记忆，类似人类
大脑中的海马体。
关键设计决策是按需检索而不是全量加载。新对话开始时，Hermes不会把过去所有对话历史都塞进来。它根据当前话
题，用FTS5搜索相关的历史片段，只加载需要的部分。
这个方案的好处：
方式 全量加载 按需检索（Hermes）
上下文占用 随对话增长线性膨胀 基本恒定
检索精度 什么都在，什么都找不到 按关键词精准匹配
长期可用性 几天后就撑不下了 可以用几个月甚至几年
响应速度 越来越慢 基本不变
FTS5是SQLite的全文搜索扩展，不需要额外装数据库。所有数据存在本地SQLite文件里，没有网络依赖，没有隐私顾
虑。你的对话记忆不会离开你的机器。
第二层：持久记忆
持久记忆回答的问题是：你是谁？
这一层存的不是对话内容，而是从对话中提炼出的持久状态。比如你的编码偏好、项目结构习惯、常用工具链、工作时间
规律。这些跨会话保持，不会因为开了新对话就丢失。
技术实现上，持久记忆也存在SQLite里，由memory工具管理。整个方案纯文件级：没有外部服务器，没有云端同步，数
据就在 ~/.hermes/ 目录下。
这意味着你可以：
把 ~/.hermes/ 备份到U盘，换台电脑继续用
用Docker部署时，挂载 /opt/data 目录到宿主机保持状态
多设备之间用网盘同步（虽然不推荐实时同步SQLite，但定期拷贝没问题）
便携性是一个被低估的特性。很多AI工具的记忆锁在云端，你换个工具就得从零开始。Hermes的记忆是你自己的文件，
想怎么搬怎么搬。
第三层：Skill记忆
Skill记忆回答的问题是：怎么做事？
前两层记住了发生过什么、你是什么样的人。第三层记住的是方法论和操作规范。每个Skill是 ~/.hermes/skills/ 下的
一个markdown文件，可读可编辑。
这三层对应了认知科学里的三种记忆类型：
情景记忆 语义记忆 程序性记忆
→ →
发生了什么 世界是什么样的 怎么做事
人类学骑自行车的过程就是这三层记忆的协作：你记得上次摔了（情景），你知道重心要放低（语义），你的身体会自动保
持平衡（程序性）。Hermes处理任务的过程类似：它记得上次你怎么改的代码，知道你的偏好是什么，手头有一套验证过
的执行方案。
三层协作的例子：你说「帮我部署这个项目」。Hermes先用FTS5搜索会话记忆，找到你上次部署时遇到的端口冲突问题
（情景）。再查持久记忆，知道你用的是阿里云ECS、Nginx反向代理（语义）。最后加载deployment-checklist这个
Skill，按你验证过的步骤执行（程序性）。三层各司其职。
Honcho：比你更了解你自己
三层本地记忆之外，Hermes还有一个可选的外挂：Honcho用户建模系统，由Plastic Labs开发。
Honcho做的事情比记住你说了什么更深一步。它在推理你这个人的特征。官方叫辩证用户建模，覆盖多个身份维度。
具体什么意思？用一个场景来说明。
假设你连续三周每天都在让Hermes帮你写Python脚本。Honcho在这个过程中可能推断出：
技术水平：你不是纯新手，但也不是专家。你能看懂代码但不太写得出来
工作节奏：你通常在晚上9-11点活跃，可能是下班后的个人项目
沟通风格：你喜欢先看结果再问原理，不喜欢长篇大论的解释
目标推断：你可能在准备一个数据分析项目，因为最近的任务都围绕数据处理
情绪模式：你在代码报错时会有点急躁，这时候简洁直接的回答效果更好
偏好矛盾：你口头上说要写完整注释，但实际review代码时从不看注释
注意最后一条。Honcho能捕捉到你言行不一致的地方。你嘴上说的偏好和实际行为展现的偏好可能不同，辩证建模就是
同时关注这两者。
这些推断会注入到后续对话的prompt里，作为隐形上下文。你看不到这些信息，但会感受到Hermes变得更懂你了。
和Claude Code auto-memory的对比
Claude Code也有记忆系统：CLAUDE.md文件和auto-memory。它们和Hermes的记忆有什么区别？
维度 Claude Code Hermes Agent
记忆格式 CLAUDE.md + auto-memory文本文件 SQLite数据库 + FTS5索引 + Skill文件
写入方式 CLAUDE.md手动写，auto-memory半自动 全自动写入，人可以随时覆盖
检索方式 启动时全量加载CLAUDE.md 按需FTS5全文检索
记忆粒度 项目级（每个项目一份CLAUDE.md） 全局级 + 项目级都有
用户建模 无（需要用户自己写偏好） Honcho自动推理用户画像
程序性记忆 CLAUDE.md中的指令 独立Skill文件，可自改进
跨项目共享 ~/.claude/CLAUDE.md（全局指令文件） 所有记忆天然全局
存储上限 CLAUDE.md建议控制在几KB SQLite理论上限很高
两者的设计哲学不同。Claude Code的CLAUDE.md是人编写、AI执行的模式，好处是人有完全的控制权，坏处是需要持
续投入维护。Hermes是AI自写、人审核的模式，好处是门槛低、自动化程度高，坏处是自动生成的内容不一定都准确。
哪种更好取决于使用场景。如果你是重度Claude Code用户，已经花了几周精心打磨CLAUDE.md，那你手工编织的缰绳
可能比Hermes自动生成的更精确。但如果你不想花时间维护配置文件，Hermes的全自动方案确实省心不少。
记忆不是万能的
说了这么多好处，也得聊聊记忆的局限。
什么该记：
用户偏好和习惯（代码风格、工具选择、沟通方式）
项目上下文（架构决策、技术栈、文件结构）
验证过的解决方案（Skill）
重复出现的模式（比如某类错误的处理方式）
什么不该记：
一次性任务的细节（帮我写个生日贺词——这不需要记住）
过时的信息（三个月前的API版本号，现在可能已经变了）
错误的推断（Hermes可能误判你的偏好，这些应该被清理）
敏感信息（密码、密钥、个人身份信息不应该进记忆库）
注意
Hermes的记忆系统目前没有自动过期机制。如果你长期使用，记忆数据库会持续增长。建议定期检查 ~/.hermes/ 目录
的大小，清理过时的Skill文件。这是一个已知的待改进点。
还有一个问题是记忆污染。如果Hermes在早期对话中记住了错误信息，这个错误可能持续影响后续行为。比如它错误地
记住了你偏好Python 2，之后生成的代码可能都带着Python 2的语法。
所以定期审查记忆很有必要。看看 ~/.hermes/skills/ 下有哪些Skill，删掉不合适的。查看持久记忆，修正错误的推
断。就像整理笔记本，偶尔翻翻会发现不少需要更新的内容。
从存储到理解
回到标题：从金鱼到老友。
金鱼的问题不是没有眼睛，是没有记忆。它每次看到你都像第一次见面。大多数AI工具就是这样，每次打开新对话，一切
从零开始。
老友不一样。老友知道你的脾气、你的习惯，知道你嘴上说不在意其实很在意。老友不需要你每次都解释背景，因为背景
已经在那了。
Hermes的三层记忆加上Honcho用户建模，走的就是这条路。会话记忆提供素材，持久记忆提供画像，Skill记忆提供方
法论，Honcho把这些碎片拼成对你的完整理解。
用的时间越长，理解越深。这不是口号，是三层记忆加闭环学习的数学必然。
下一章我们看看Hermes的另一个核心机制：Skill系统。如果记忆是「知道」，Skill就是「会做」。
Three-Layer Memory: From Goldfish to Old Friend
大多数AI聊天工具的记忆像金鱼，上一轮说的话下一轮就忘了。Hermes的目标是做一个老友：记得你说过什
么，知道你是什么样的人，还学会了你做事的方式。
为什么记忆是最难的问题
你可能觉得AI的记忆不就是存聊天记录吗？存下来，下次加载进去就行了。
没那么简单。一个活跃用户每天跟AI聊几千字，一个月就是几万字。全塞进上下文窗口，要么装不下，要么模型因为信息
太多反而变迟钝。而且聊天记录里大部分是废话和重复，真正有价值的信息可能只占10%。
好的记忆系统不是存得多，是找得准。
Hermes用三层架构解决这个问题，每一层处理不同类型的记忆。
第一层：会话记忆
会话记忆回答的问题是：发生了什么？
每轮对话的内容、工具调用和返回结果，全部写入SQLite数据库，同时建FTS5全文搜索索引。这是情景记忆，类似人类
大脑中的海马体。
关键设计决策是按需检索而不是全量加载。新对话开始时，Hermes不会把过去所有对话历史都塞进来。它根据当前话
题，用FTS5搜索相关的历史片段，只加载需要的部分。
这个方案的好处：
方式 全量加载 按需检索（Hermes）
上下文占用 随对话增长线性膨胀 基本恒定
检索精度 什么都在，什么都找不到 按关键词精准匹配
长期可用性 几天后就撑不下了 可以用几个月甚至几年
响应速度 越来越慢 基本不变
FTS5是SQLite的全文搜索扩展，不需要额外装数据库。所有数据存在本地SQLite文件里，没有网络依赖，没有隐私顾
虑。你的对话记忆不会离开你的机器。
第二层：持久记忆
持久记忆回答的问题是：你是谁？
这一层存的不是对话内容，而是从对话中提炼出的持久状态。比如你的编码偏好、项目结构习惯、常用工具链、工作时间
规律。这些跨会话保持，不会因为开了新对话就丢失。
技术实现上，持久记忆也存在SQLite里，由memory工具管理。整个方案纯文件级：没有外部服务器，没有云端同步，数
据就在 ~/.hermes/ 目录下。
这意味着你可以：
把 ~/.hermes/ 备份到U盘，换台电脑继续用
用Docker部署时，挂载 /opt/data 目录到宿主机保持状态
多设备之间用网盘同步（虽然不推荐实时同步SQLite，但定期拷贝没问题）
便携性是一个被低估的特性。很多AI工具的记忆锁在云端，你换个工具就得从零开始。Hermes的记忆是你自己的文件，
想怎么搬怎么搬。
第三层：Skill记忆
Skill记忆回答的问题是：怎么做事？
前两层记住了发生过什么、你是什么样的人。第三层记住的是方法论和操作规范。每个Skill是 ~/.hermes/skills/ 下的
一个markdown文件，可读可编辑。
这三层对应了认知科学里的三种记忆类型：
情景记忆 语义记忆 程序性记忆
→ →
发生了什么 世界是什么样的 怎么做事
人类学骑自行车的过程就是这三层记忆的协作：你记得上次摔了（情景），你知道重心要放低（语义），你的身体会自动保
持平衡（程序性）。Hermes处理任务的过程类似：它记得上次你怎么改的代码，知道你的偏好是什么，手头有一套验证过
的执行方案。
三层协作的例子：你说「帮我部署这个项目」。Hermes先用FTS5搜索会话记忆，找到你上次部署时遇到的端口冲突问题
（情景）。再查持久记忆，知道你用的是阿里云ECS、Nginx反向代理（语义）。最后加载deployment-checklist这个
Skill，按你验证过的步骤执行（程序性）。三层各司其职。
Honcho：比你更了解你自己
三层本地记忆之外，Hermes还有一个可选的外挂：Honcho用户建模系统，由Plastic Labs开发。
Honcho做的事情比记住你说了什么更深一步。它在推理你这个人的特征。官方叫辩证用户建模，覆盖多个身份维度。
具体什么意思？用一个场景来说明。
假设你连续三周每天都在让Hermes帮你写Python脚本。Honcho在这个过程中可能推断出：
技术水平：你不是纯新手，但也不是专家。你能看懂代码但不太写得出来
工作节奏：你通常在晚上9-11点活跃，可能是下班后的个人项目
沟通风格：你喜欢先看结果再问原理，不喜欢长篇大论的解释
目标推断：你可能在准备一个数据分析项目，因为最近的任务都围绕数据处理
情绪模式：你在代码报错时会有点急躁，这时候简洁直接的回答效果更好
偏好矛盾：你口头上说要写完整注释，但实际review代码时从不看注释
注意最后一条。Honcho能捕捉到你言行不一致的地方。你嘴上说的偏好和实际行为展现的偏好可能不同，辩证建模就是
同时关注这两者。
这些推断会注入到后续对话的prompt里，作为隐形上下文。你看不到这些信息，但会感受到Hermes变得更懂你了。
和Claude Code auto-memory的对比
Claude Code也有记忆系统：CLAUDE.md文件和auto-memory。它们和Hermes的记忆有什么区别？
维度 Claude Code Hermes Agent
记忆格式 CLAUDE.md + auto-memory文本文件 SQLite数据库 + FTS5索引 + Skill文件
写入方式 CLAUDE.md手动写，auto-memory半自动 全自动写入，人可以随时覆盖
检索方式 启动时全量加载CLAUDE.md 按需FTS5全文检索
记忆粒度 项目级（每个项目一份CLAUDE.md） 全局级 + 项目级都有
用户建模 无（需要用户自己写偏好） Honcho自动推理用户画像
程序性记忆 CLAUDE.md中的指令 独立Skill文件，可自改进
跨项目共享 ~/.claude/CLAUDE.md（全局指令文件） 所有记忆天然全局
存储上限 CLAUDE.md建议控制在几KB SQLite理论上限很高
两者的设计哲学不同。Claude Code的CLAUDE.md是人编写、AI执行的模式，好处是人有完全的控制权，坏处是需要持
续投入维护。Hermes是AI自写、人审核的模式，好处是门槛低、自动化程度高，坏处是自动生成的内容不一定都准确。
哪种更好取决于使用场景。如果你是重度Claude Code用户，已经花了几周精心打磨CLAUDE.md，那你手工编织的缰绳
可能比Hermes自动生成的更精确。但如果你不想花时间维护配置文件，Hermes的全自动方案确实省心不少。
记忆不是万能的
说了这么多好处，也得聊聊记忆的局限。
什么该记：
用户偏好和习惯（代码风格、工具选择、沟通方式）
项目上下文（架构决策、技术栈、文件结构）
验证过的解决方案（Skill）
重复出现的模式（比如某类错误的处理方式）
什么不该记：
一次性任务的细节（帮我写个生日贺词——这不需要记住）
过时的信息（三个月前的API版本号，现在可能已经变了）
错误的推断（Hermes可能误判你的偏好，这些应该被清理）
敏感信息（密码、密钥、个人身份信息不应该进记忆库）
注意
Hermes的记忆系统目前没有自动过期机制。如果你长期使用，记忆数据库会持续增长。建议定期检查 ~/.hermes/ 目录
的大小，清理过时的Skill文件。这是一个已知的待改进点。
还有一个问题是记忆污染。如果Hermes在早期对话中记住了错误信息，这个错误可能持续影响后续行为。比如它错误地
记住了你偏好Python 2，之后生成的代码可能都带着Python 2的语法。
所以定期审查记忆很有必要。看看 ~/.hermes/skills/ 下有哪些Skill，删掉不合适的。查看持久记忆，修正错误的推
断。就像整理笔记本，偶尔翻翻会发现不少需要更新的内容。
从存储到理解
回到标题：从金鱼到老友。
金鱼的问题不是没有眼睛，是没有记忆。它每次看到你都像第一次见面。大多数AI工具就是这样，每次打开新对话，一切
从零开始。
老友不一样。老友知道你的脾气、你的习惯，知道你嘴上说不在意其实很在意。老友不需要你每次都解释背景，因为背景
已经在那了。
Hermes的三层记忆加上Honcho用户建模，走的就是这条路。会话记忆提供素材，持久记忆提供画像，Skill记忆提供方
法论，Honcho把这些碎片拼成对你的完整理解。
用的时间越长，理解越深。这不是口号，是三层记忆加闭环学习的数学必然。
下一章我们看看Hermes的另一个核心机制：Skill系统。如果记忆是「知道」，Skill就是「会做」。