【Hermes：核心机制】6、Hermes 三层记忆机制彻底拆解：从金鱼到老友，AI 如何真正记住你？

Hermes 三层记忆机制彻底拆解：从金鱼到老友，AI 如何真正记住你？

会话级记忆、持久化画像、可复用 Skill——三层体系让 Agent 从“聊完就忘”进化为“越聊越懂你”

前言：大多数 AI 为什么像“金鱼”？

如果你用过 AI Agent，一定经历过这样的场景：

周一：你告诉 Agent：“我是后端工程师，主要用 Python，工作目录在 /data/services。”

周二：Agent 问你：“请问您的工作目录在哪里？”

周三：你教了 Agent 一套完整的部署流程。周五换了个会话窗口，它又从头问起。

这不是某个产品偷懒，而是大多数 Agent 框架的底层架构就这么设计的——会话结束，一切归零。

那么，什么样的 Agent 才配得上“记住你”？

2026 年 2 月，Nous Research 正式开源 Hermes Agent，截至本文撰写时 GitHub Star 已突破 9.5 万。短短两个月内，它成为继 OpenClaw 之后最受关注的 AI Agent 框架，核心原因之一就是它那套三层记忆机制。

这套机制让 Agent 从“金鱼”（7 秒记忆）进化成“老友”（真正了解你）。

一、传统 AI 记忆的四大痛点

在深入 Hermes 之前，先搞清楚传统 AI 的“记忆”问题到底出在哪。

1.1 全量加载：把整个图书馆搬上工作台

传统 Agent 的记忆管理方式非常简单粗暴：把所有能记得的东西，一股脑塞进上下文窗口。

但这带来了一个悖论——上下文窗口是有限的。Claude 的上下文窗口为 200K tokens，GPT-4 为 128K tokens。当你试图“记住”越来越多的东西时，上下文窗口会被迅速填满。

打个比方：你的工作台只有一张桌子，但你非要把整个图书馆的书都堆上去。最后的结果是——桌子堆不下了，新书没地方放，旧书也找不到。

1.2 上下文溢出：记不住就是真的记不住

当对话足够长时，模型会开始“遗忘”早期内容。这被称为上下文溢出或上下文压缩——超过限制后，模型要么会丢失早期信息，要么因为成本暴涨而不得不重置会话窗口。

实际体验：你在第 10 轮对话中告诉 Agent 一个重要的配置项，到了第 50 轮，它可能已经完全“忘记”了。

1.3 检索低效：搜得到≠用得上

即便 Agent 把所有对话存在 SQLite 或文件系统中，检索效率也是个老大难。根据 Anthropic 的最新开发者调研，68% 的 AI 应用团队都在为“上下文丢失”的问题苦恼。

1.4 隐私顾虑：数据到底去了哪？

这是很多开发者和企业用户最关心的问题。如果你的记忆数据被上传到云端，你对 Agent 说的每一句话——包括公司内部信息、代码、API 密钥——都有可能被第三方访问。

Hermes 选择了一条不同的路径：记忆全部存储在本地，默认目录 ~/.hermes/。

一句话总结传统记忆的困境：Agent 不是不想记住你，是它的“大脑”架构从一开始就不支持真正的长期记忆。

二、Hermes 的三层记忆架构（总览）

Hermes 为这个“失忆”问题设计了一套系统的解决方案——三层记忆体系。

2.1 为什么是三层？

人类大脑处理信息的方式是分层的：

• 工作记忆：正在处理的信息（几秒到几分钟）
• 情景记忆：过去发生了什么事（几小时到几天）
• 程序性记忆：怎么做事（永久）

Hermes 的三层记忆正是借鉴了这种认知科学模型，将 Agent 的记忆分为三个层次，分别对应不同的时间跨度和信息类型：

┌─────────────────────────────────────────────────────────────────┐
│ Hermes 三层记忆架构总览图 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 用户交互层 │ │
│ │ 用户输入 → 理解意图 → 调用记忆 → 生成响应 → 执行任务 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 第一层：会话记忆（Session Memory） │ │
│ │ ┌───────────────────────────────────────────────────┐ │ │
│ │ │ 存储位置：~/.hermes/state.db (SQLite) │ │ │
│ │ │ 检索方式：FTS5 全文索引 + session_search 工具 │ │ │
│ │ │ 典型内容：“我们上周讨论过那个 API 密钥吗？” │ │ │
│ │ └───────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 第二层：持久记忆（Persistent Memory） │ │
│ │ ┌───────────────────────────────────────────────────┐ │ │
│ │ │ MEMORY.md（~2,200 字符）→ 客观事实、环境、工作流 │ │ │
│ │ │ USER.md（~1,375 字符）→ 用户画像、偏好、沟通风格 │ │ │
│ │ │ Honcho（可选）→ 辩证推理、12 个身份层次深度建模 │ │ │
│ │ └───────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 第三层：Skill 记忆（Skill Memory） │ │
│ │ ┌───────────────────────────────────────────────────┐ │ │
│ │ │ 存储位置：~/.hermes/skills/*.md │ │ │
│ │ │ 格式标准：agentskills.io 开放标准 │ │ │
│ │ │ 典型内容：部署流程、调试步骤、API 调用链 │ │ │
│ │ │ 自进化机制：GEPA 算法 + DSPy 框架批量优化 │ │ │
│ │ └───────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘

2.2 三层如何协同？

三层记忆不是孤立工作的，而是在 Agent 执行任务时协同运转。当用户输入一条消息时，下面这张流程图展示了三层记忆的完整交互过程：

┌─────────────────────────────────────────────────────────────────────────┐
│ Hermes 三层记忆协同工作流程图 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 用户输入：“帮我部署刚才写的那个 Flask 应用” │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Step 1: Agent 接收消息 │ │
│ │ └─ 加载第二层持久记忆（MEMORY.md + USER.md）至系统提示词 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Step 2: 检查是否有匹配的 Skill │ │
│ │ └─ 检索第三层 Skill 记忆 → 找到“Flask 部署流程” │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Step 3: 按 Skill 步骤执行任务 │ │
│ │ ├─ 检查 Python 环境（从 MEMORY.md 获取路径） │ │
│ │ ├─ 安装依赖 │ │
│ │ ├─ 启动服务 │ │
│ │ └─ 执行完毕后，更新记忆（写入本次执行结果） │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Step 4: 判断是否需要更新记忆 │ │
│ │ ├─ 如果本次执行有新的最佳实践 → 更新 Skill │ │
│ │ ├─ 如果用户表达了新的偏好 → 更新 USER.md │ │
│ │ └─ 如果发现了新的客观事实 → 更新 MEMORY.md │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Step 5: 写入 SQLite 会话存档（FTS5 索引） │ │
│ │ └─ 本次对话全文写入 ~/.hermes/state.db，建立全文索引 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘

实际运行效果：当 Hermes 执行任务时，记忆层在喂上下文（你是谁、在哪里、偏好什么）；执行完之后，技能层在判断要不要把这次的解法提炼成可复用文件；执行轨迹则在后台积累。

三、第一层：会话记忆（Session Memory）——记录“发生了什么”

3.1 概念与定位

会话记忆是 Hermes 最基础的记忆层，对应认知科学中的工作记忆和情景记忆——它负责存储在当前会话中发生的具体对话内容和任务上下文。

换句话说，会话记忆回答的是“刚才我们聊了什么”。

3.2 技术实现：FTS5 + SQLite

Hermes 将所有 CLI 会话和消息平台会话存储在 ~/.hermes/state.db 这个 SQLite 数据库中。但存储只是第一步，更重要的是怎么检索。

Hermes 使用的是 FTS5（Full-Text Search 5）全文索引技术。FTS5 是 SQLite 内置的全文搜索引擎，能够对数据库中的文本内容建立倒排索引，实现高效的关键词检索。

FTS5 的核心优势：

💡 设计哲学：上下文窗口是昂贵且有限的资源。Hermes 不在每次请求中都加载所有历史对话，而是让 Agent 按需检索——通过 session_search 工具主动查询历史，由 LLM 对结果进行摘要，只把最相关的内容注入上下文。

3.3 工作流程

当用户问“我们上周讨论过那个 API 密钥吗？”时，Agent 会：

这种“按需检索 + 摘要注入”的模式，既保留了历史信息的可追溯性，又避免了全量加载带来的 token 浪费。

3.4 会话记忆的局限

会话记忆的设计非常克制——它只解决“检索历史”的问题，不负责记忆用户偏好或做事方法。那些能力交给了第二层和第三层。

四、第二层：持久记忆（Persistent Memory）——记录“你是谁”

4.1 概念与定位

持久记忆是 Hermes 的语义记忆层，负责存储跨会话持久的用户状态与偏好——你的编码风格、工作习惯、项目环境、沟通偏好等。

与传统 Agent 的“手动写文件”不同，Hermes 的持久记忆是 Agent 自己维护的。它通过定期“自我提醒”（nudge）机制，主动将重要信息固化到持久记忆文件中。

4.2 核心文件：MEMORY.md 和 USER.md

Hermes 的持久记忆由两个核心文件构成：

这两个文件在每个会话开始时以“冻结快照”（frozen snapshot）的形式加载到系统提示词中。

🔒 为什么要“冻结”？ 这是为了保持 LLM 前缀缓存（prefix cache）的稳定性。如果文件在会话中途发生变化，缓存会失效，导致每次请求都要重新计算提示词，大幅增加成本和延迟。因此，会话中途的变更虽然会立即写入磁盘，但要等到下次新会话才能看到效果。

4.3 MEMORY.md：客观事实的仓库

MEMORY.md 记录的是与用户无关的客观事实，例如：

# 环境配置
– Python 版本：3.11
– 工作目录：/data/services/api
– 数据库：PostgreSQL 15 运行在 localhost:5432

# 项目规范
– API 响应格式：{ "code": 0, "data": {}, "msg": "" }
– 日志级别：生产环境 INFO，开发环境 DEBUG

# 经验教训
– 部署前必须执行 pytest，否则可能遗漏数据库迁移
– Redis 连接池上限设为 100，超过会报错

4.4 USER.md：用户画像的演进

USER.md 记录的是关于用户的行为档案——不是你说了什么，而是你怎么做事：

# 任务偏好
– 输出格式：优先用中文，简洁专业，不冗余
– 代码风格：喜欢类型注解，优先使用 f-string

# 决策历史
– 类似情况下，用户倾向于选择开源方案而非商业服务
– 用户偏好直接给出答案，不要“你怎么看”

# 任务模式
– 常做：后端 API 开发、数据库优化、部署自动化
– 回避：前端开发、UI 设计

# 反馈信号
– 用户连续三次不修改输出 → 认可这个方向
– 用户反复纠正 → 说明跑偏了，需要调整

4.5 可选增强：Honcho 用户建模

Hermes 还有一个可选的记忆增强层——Honcho。Honcho 是由 Plastic Labs 开发的用户建模服务，通过 “辩证推理”（dialectical reasoning） 从对话中推导出关于用户的深层结论。

Honcho 的四个核心工具：

Honcho 的核心价值：它不存储原始对话，而是从中推导结论。这意味着：

• 即使存储系统被攻破，攻击者看到的也不是你说了什么，而是 AI“推断”你是什么样的人
• 支持双端建模——不仅建模用户，也建模 Agent 本身的知识表征
• 通过 12 个身份层次持续建模用户，记录用户角色、目标、职责和知识

⚠️ 注意：Honcho 是可选的外部服务。如果你追求极致隐私（所有数据完全本地），可以不启用 Honcho。Hermes 的本地 MEMORY.md + USER.md 已经能够覆盖绝大多数持久记忆需求。

4.6 持久记忆的更新机制

持久记忆不是静态的——Hermes 会定期主动更新它。通过配置 nudge_interval 参数，Agent 会在指定时间间隔后主动复盘近期对话，提取值得长期保存的信息，写入 MEMORY.md 或 USER.md。

五、第三层：Skill 记忆——记录“怎么做事”

5.1 概念与定位

如果说持久记忆回答的是“你是谁”，那么 Skill 记忆回答的就是**“怎么做事”**——它是程序性记忆的数字化实现。

Skill 本质上是存储在 ~/.hermes/skills/ 目录下的 Markdown 文件，每个文件包含名称、描述、执行步骤、工具调用等结构化信息。当 Agent 完成复杂任务后，会自动将解决方案提炼成 Skill 文件存储起来。

Skill 记忆与传统代码的最大区别：传统代码需要人工编写和维护；Skill 是 Agent 自己生成的，并且会持续自我优化。

5.2 标准格式与渐进式加载

Hermes 的 Skill 遵循 agentskills.io 开放标准——这意味着为 Claude Code 等工具编写的 Skill 可以无缝迁移到 Hermes 使用。

Skill 文件结构如下：

—
name: "flask-deploy"
description: "部署 Flask 应用到生产环境"
license: "MIT"
compatibility: "Python 3.8+"
allowed-tools: ["terminal", "file", "git"]
—

## 执行步骤

1. 检查 Python 版本（需要 3.8+）
2. 创建虚拟环境：`python -m venv venv`
3. 安装依赖：`pip install -r requirements.txt`
4. 运行测试：`pytest`
5. 启动 gunicorn：`gunicorn app:app -b 0.0.0.0:8000`

## 已知陷阱

– 如果数据库迁移脚本未执行，应用会启动失败
– 生产环境需设置环境变量 FLASK_ENV=production

渐进式加载策略：Hermes 不会把所有 Skill 都塞进上下文。它采用四层渐进加载：

• Tier 0：元数据（名称、描述）总是加载（~100 tokens）
• Tier 1：完整 Skill 内容在激活时加载（建议不超过 5,000 tokens）
• Tier 2：资源文件按需加载
• Tier 3：脚本文件执行时调用

这种设计大幅降低了日常运行的 token 消耗——相比全量加载，日常运行仅需约 3000 token。

5.3 Skill 自动生成

Skill 的生成是完全自动化的，不需要用户干预。触发条件包括：

• 任务调用了 5 次及以上 工具
• 从某个错误中成功恢复
• 用户提供了修正指导
• 走通了一套不那么直观的有效流程

┌─────────────────────────────────────────────────────────────────┐
│ Skill 自动生成流程图 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 用户任务：“分析上周日志中的错误并生成报告” │
│ │ │
│ ▼ │
│ 执行阶段： │
│ ├─ 调用 read_file（读取日志） │
│ ├─ 调用 grep（筛选错误关键词） │
│ ├─ 调用 LLM 分析（归类错误类型） │
│ ├─ 调用 write_file（生成报告） │
│ └─ 调用 send_message（发送到飞书） │
│ │ │
│ ▼ │
│ 触发条件检查：工具调用次数 = 5 ✅ → 触发 Skill 生成 │
│ │ │
│ ▼ │
│ Agent 执行 skill_manage 工具： │
│ ├─ 提取执行步骤和工具调用序列 │
│ ├─ 生成 SKILL.md（包含名称、描述、步骤、陷阱） │
│ └─ 保存到 ~/.hermes/skills/ │
│ │ │
│ ▼ │
│ 下次遇到同类任务 → 直接加载该 Skill，跳过重复推理 │
│ │
└─────────────────────────────────────────────────────────────────┘

5.4 Skill 的自我进化

Skill 生成后不是静态的。Hermes 在使用过程中会主动检测 Skill 是否过时、不完整或有错误，一旦发现问题，立即通过 patch 动作精准修复。

自我进化的技术路线：Hermes 内置了 GEPA（Genetic-Pareto Prompt Evolution）算法 和 DSPy 框架，持续对已有的 Skills 进行批量优化迭代。GEPA 的核心思想是用进化算法生成变体、评估性能、选择最佳版本，实现提示词的自我优化。

自我进化的典型流程：

5.5 Skill 记忆 vs 传统代码

六、三层记忆协同工作流程（完整示例）

为了更好地理解三层记忆是如何协同工作的，让我们通过一个完整的示例来走一遍流程：

┌─────────────────────────────────────────────────────────────────────────┐
│ Hermes 三层记忆协同完整示例 │
│ 场景：用户第一次部署 Flask 应用 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 【阶段一：会话开始】 │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 用户：帮我部署这个 Flask 应用到生产环境 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 【阶段二：加载记忆】 │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 第二层：加载 MEMORY.md │ │
│ │ → 知道 Python 版本是 3.11，工作目录是 /data/services │ │
│ │ 第二层：加载 USER.md │ │
│ │ → 知道用户偏好简洁输出，不喜欢冗长解释 │ │
│ │ 第三层：检索 Skill 记忆 │ │
│ │ → 未找到匹配的“Flask 部署”Skill，这是第一次 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 【阶段三：执行任务】 │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 1. 检查 Python 环境（从 MEMORY.md 获取路径） │ │
│ │ 2. 创建虚拟环境 │ │
│ │ 3. 安装依赖 │ │
│ │ 4. 配置环境变量 │ │
│ │ 5. 启动 gunicorn │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 【阶段四：生成 Skill（第三层写入）】 │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Agent 判断：工具调用 5 次 ✅ → 触发 Skill 生成 │ │
│ │ → 将本次执行步骤自动打包成 SKILL.md │ │
│ │ → 保存到 ~/.hermes/skills/flask-deploy.md │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 【阶段五：更新持久记忆（第二层写入）】 │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 如果用户说“下次不要显示 pip install 的输出”： │ │
│ │ → Agent 更新 USER.md，记录这个偏好 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 【阶段六：写入会话存档（第一层写入）】 │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 本次对话全文写入 state.db，建立 FTS5 索引 │ │
│ │ → 下次用户问“上次部署是什么时候”，可直接检索 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘

七、本地存储：~/.hermes 目录与隐私保障

7.1 目录结构详解

Hermes 的所有数据都存储在本地 ~/.hermes/ 目录中：

~/.hermes/
├── config.yaml # 主配置文件（模型、工具、终端后端等）
├── .env # API 密钥（权限 0600，仅所有者可读写）
├── auth.json # OAuth 凭据
├── SOUL.md # Agent 人格定义
├── state.db # SQLite 会话数据库
├── memories/ # 持久记忆目录
│ ├── MEMORY.md # 客观事实
│ └── USER.md # 用户画像
├── skills/ # Skill 记忆目录（存放所有 SKILL.md）
├── cron/ # 定时任务配置
├── sessions/ # 消息平台会话数据
└── logs/ # 日志文件

7.2 隐私保障机制

7.3 跨会话一致性的保证

Hermes 的设计确保在一个会话中学习的记忆，在其他会话中也能生效。这是因为：

这意味着，你在 CLI 中教会 Agent 某个技能，下次在 Telegram 上调用同一个 Agent，技能依然可用。

八、与 OpenClaw、Claude Code 记忆对比

8.1 横向对比表

8.2 OpenClaw 记忆的痛点

OpenClaw 的默认记忆系统虽然设计精良，但存在几个核心问题：

问题一：Agent 决定存什么，模型不稳定。OpenClaw 的文档明确指出：“如果你希望某件事被记住，告诉 Agent 写下来。”如果模型没想到要存，信息就丢了。

问题二：只有最近 2 天的日志自动加载。上周的信息虽然在磁盘上，但 Agent 必须“知道”应该在什么时候、用什么关键词去搜索——模型不会一致地做到这一点。

问题三：Skill 需要人工编写。OpenClaw 的 Skill 体系依赖人工编写，扩展需要投入时间。

8.3 Claude Code 记忆的痛点

Claude Code 的记忆系统也有明显短板：

问题一：索引上限 ~200 行。所有记忆挤在一个文件里，达到上限后旧条目会被压缩或删除。

问题二：只能精确关键词匹配。如果你问“端口冲突”，但笔记写的是“docker-compose 映射”，你什么都找不到。

问题三：无跨会话持久化。Claude Code 默认在会话之间不保留记忆。

8.4 Hermes 的差异化优势

Hermes 在上述三个方向上都做了根本性的改进：

• 自动决策：不依赖用户指令，Agent 自主决定什么值得记忆
• Skill 自进化：Skill 不是静态的，会在使用中持续优化
• 标准化：遵循 agentskills.io 开放标准，Skill 可跨平台移植
• FTS5 全文搜索：支持任意关键词检索，不限于精确匹配
• 无硬性上限：Skill 数量不受 200 条限制

一句话总结：OpenClaw 和 Claude Code 把记忆看作是“配置文件”，需要人工维护；Hermes 把记忆看作是“学习成果”，由 Agent 自动生成和进化。

九、实践建议：如何用好 Hermes 的三层记忆

9.1 理解三层记忆的边界

• 第一层会话记忆：适合检索“之前说过什么”
• 第二层持久记忆：适合存储“我是什么样的人”
• 第三层 Skill 记忆：适合沉淀“怎么做某件事”

最佳实践：不要试图让 Agent 把任务执行细节记在 MEMORY.md 里——那是 Skill 的职责。不要试图让 Skill 记录你的个人偏好——那是 USER.md 的职责。

9.2 启用和配置 Honcho（可选）

如果你希望 Agent 拥有更深度的用户理解，可以启用 Honcho：

# 安装 Honcho（参考官方文档）
# 然后配置 Hermes 使用 Honcho 作为记忆提供商
hermes memory setup
# 选择 honcho，输入 localhost:8000 作为 base URL

Honcho 启用后，Agent 会在对话中自动记录和更新关于你的 12 个身份层次。

9.3 查看和编辑记忆

# 查看当前持久记忆
cat ~/.hermes/memories/MEMORY.md
cat ~/.hermes/memories/USER.md

# 查看已生成的 Skill
ls ~/.hermes/skills/
hermes skills list

# 手动编辑（如果需要修正错误）
hermes memory edit # 编辑持久记忆
hermes skills edit <name> # 编辑指定 Skill

9.4 跨平台记忆一致性

如果你在多个消息平台使用 Hermes（CLI + Telegram + 飞书），记忆是完全共享的。在 CLI 中教会 Agent 的技能，在 Telegram 中同样生效。

这是因为所有平台共用同一个 ~/.hermes/ 目录和 Gateway 进程。

十、总结：从“金鱼”到“老友”

Hermes 的三层记忆体系，从根本上改变了 AI Agent 与用户的关系：

• 第一层会话记忆：让 Agent 能够“回头看”——需要时翻查历史对话
• 第二层持久记忆：让 Agent 能够“认识你”——记得你是谁、喜欢什么
• 第三层 Skill 记忆：让 Agent 能够“记得怎么做”——把经验固化为可复用的能力

三层同时运转：Agent 执行任务时记忆层在喂上下文，执行完之后技能层在判断要不要把这次的解法提炼成可复用文件，执行轨迹则在后台积累成潜在的训练数据。

最终的结果：Hermes 不是“用完就忘”的工具，而是一个会随着使用不断成长的数字伙伴。每一次对话、每一次任务都在让它更懂你、更会用你的方式解决问题。

核心启示：真正聪明的 AI 不需要你教它第二次。Hermes 的三层记忆机制正是实现这一目标的工程化路径——让 Agent 从“金鱼”变成“老友”，从“工具”变成“伙伴”。

📌 延伸阅读

• Hermes Agent GitHub：https://github.com/NousResearch/hermes-agent
• Hermes 官方文档：https://hermes-agent.nousresearch.com/
• agentskills.io 开放标准：https://agentskills.io/
• Honcho 用户建模：https://honcho.dev/

💬 欢迎在评论区分享你使用 Hermes 的记忆体验！你遇到过“AI 失忆”的尴尬瞬间吗？