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 tokensGPT-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 的记忆分为三个层次分别对应不同的时间跨度和信息类型层级名称认知科学对应存储内容时效存储位置第一层会话记忆Session Memory工作记忆 情景记忆对话内容、任务上下文当前会话SQLite FTS5 索引第二层持久记忆Persistent Memory语义记忆用户画像、偏好、长期事实跨会话、永久MEMORY.md USER.md第三层Skill 记忆Skill Memory程序性记忆做事的方法论、执行步骤跨会话、持续优化~/.hermes/skills/*.md┌─────────────────────────────────────────────────────────────────┐ │ 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 SQLiteHermes 将所有 CLI 会话和消息平台会话存储在~/.hermes/state.db这个 SQLite 数据库中。但存储只是第一步更重要的是怎么检索。Hermes 使用的是FTS5Full-Text Search 5全文索引技术。FTS5 是 SQLite 内置的全文搜索引擎能够对数据库中的文本内容建立倒排索引实现高效的关键词检索。FTS5 的核心优势特性说明无需外部依赖SQLite 原生支持零额外配置按需检索Agent 只在需要时才调用session_search工具摘要总结检索结果由可配置的 LLM 进行摘要而非全量返回恒定上下文避免全量加载导致的上下文膨胀设计哲学上下文窗口是昂贵且有限的资源。Hermes 不在每次请求中都加载所有历史对话而是让 Agent按需检索——通过session_search工具主动查询历史由 LLM 对结果进行摘要只把最相关的内容注入上下文。3.3 工作流程当用户问“我们上周讨论过那个 API 密钥吗”时Agent 会调用session_search工具传入关键词“API 密钥”“上周”FTS5 全文索引在state.db中快速定位相关会话LLM 摘要检索到的历史对话片段将摘要注入当前上下文生成回答这种“按需检索 摘要注入”的模式既保留了历史信息的可追溯性又避免了全量加载带来的 token 浪费。3.4 会话记忆的局限会话记忆的设计非常克制——它只解决“检索历史”的问题不负责记忆用户偏好或做事方法。那些能力交给了第二层和第三层。四、第二层持久记忆Persistent Memory——记录“你是谁”4.1 概念与定位持久记忆是 Hermes 的语义记忆层负责存储跨会话持久的用户状态与偏好——你的编码风格、工作习惯、项目环境、沟通偏好等。与传统 Agent 的“手动写文件”不同Hermes 的持久记忆是Agent 自己维护的。它通过定期“自我提醒”nudge机制主动将重要信息固化到持久记忆文件中。4.2 核心文件MEMORY.md 和 USER.mdHermes 的持久记忆由两个核心文件构成文件位置容量存储内容MEMORY.md~/.hermes/memories/~2,200 字符约 800 tokens客观事实环境配置、项目规范、已发现的工作流、经验教训USER.md~/.hermes/memories/~1,375 字符约 500 tokens用户画像偏好、沟通风格、身份信息、行为模式这两个文件在每个会话开始时以“冻结快照”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_profile快速获取用户的关键事实卡片无 LLM 调用honcho_search语义搜索记忆按相关性排序返回原始摘录honcho_contextLLM 驱动的辩证问答从对话历史中综合答案honcho_conclude当用户表达偏好、纠正或重要上下文时写入持久化事实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. 启动 gunicorngunicorn app:app -b 0.0.0.0:8000 ## 已知陷阱 - 如果数据库迁移脚本未执行应用会启动失败 - 生产环境需设置环境变量 FLASK_ENVproduction渐进式加载策略Hermes 不会把所有 Skill 都塞进上下文。它采用四层渐进加载Tier 0元数据名称、描述总是加载~100 tokensTier 1完整 Skill 内容在激活时加载建议不超过 5,000 tokensTier 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 内置了GEPAGenetic-Pareto Prompt Evolution算法和DSPy 框架持续对已有的 Skills 进行批量优化迭代。GEPA 的核心思想是用进化算法生成变体、评估性能、选择最佳版本实现提示词的自我优化。自我进化的典型流程Agent 调用某个 Skill 执行任务执行过程中发现某个步骤已过时例如依赖包版本已更新Agent 使用patch工具采用模糊匹配替换机制精准修改 Skill 文件修改后的 Skill 保存下次调用时使用新版本5.5 Skill 记忆 vs 传统代码维度传统代码/手动 SkillHermes Skill 记忆生成方式人工编写Agent 自动生成更新方式人工维护Agent 自动 patch格式标准各自为政agentskills.io 开放标准可移植性低高可迁移至 11 工具优化机制无GEPA DSPy 批量进化六、三层记忆协同工作流程完整示例为了更好地理解三层记忆是如何协同工作的让我们通过一个完整的示例来走一遍流程┌─────────────────────────────────────────────────────────────────────────┐ │ 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 隐私保障机制机制说明完全本地存储所有记忆数据默认存储在用户自己的机器上不上传任何云端密钥隔离API 密钥存储在.env权限自动设为 0600仅所有者可读写配置优先级.env中的环境变量 config.yaml 默认值确保密钥不会意外暴露可选外部服务Honcho 是可选的不启用则无数据离开本地容器隔离支持 Docker 等容器后端进程级隔离7.3 跨会话一致性的保证Hermes 的设计确保在一个会话中学习的记忆在其他会话中也能生效。这是因为所有会话共享同一个~/.hermes/目录MEMORY.md 和 USER.md 在每个会话开始时都被加载Skill 文件被所有会话共享这意味着你在 CLI 中教会 Agent 某个技能下次在 Telegram 上调用同一个 Agent技能依然可用。八、与 OpenClaw、Claude Code 记忆对比8.1 横向对比表对比维度Hermes AgentOpenClawClaude Code记忆架构三层体系会话持久Skill三层体系短期日志核心四层体系CLAUDE.md 自动记忆 Auto Dream KAIROS自动记忆✅ Agent 主动写入⚠️ 需主动指令保存✅ Auto Memory 自动保存跨会话加载✅ 自动MEMORY.md USER.md⚠️ 仅最近 2 天日志自动加载✅ CLAUDE.md 每次启动加载Skill 生成✅自动生成 自进化❌ 人工编写❌ 人工编写CLAUDE.md全文检索✅ FTS5 全文搜索✅ SQLite 向量索引❌ 仅精确关键词匹配用户建模✅ Honcho 辩证推理⚠️ 需插件✅ Auto Memory 四类记忆本地存储✅~/.hermes/✅ 本地 Markdown 文件✅~/.claude/记忆上限无硬性上限无硬性上限~200 行索引开放标准✅ agentskills.io❌ 私有格式❌ 私有格式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 URLHoncho 启用后Agent 会在对话中自动记录和更新关于你的 12 个身份层次。9.3 查看和编辑记忆# 查看当前持久记忆cat~/.hermes/memories/MEMORY.mdcat~/.hermes/memories/USER.md# 查看已生成的 Skillls~/.hermes/skills/ hermes skills list# 手动编辑如果需要修正错误hermes memory edit# 编辑持久记忆hermes skills editname# 编辑指定 Skill9.4 跨平台记忆一致性如果你在多个消息平台使用 HermesCLI Telegram 飞书记忆是完全共享的。在 CLI 中教会 Agent 的技能在 Telegram 中同样生效。这是因为所有平台共用同一个~/.hermes/目录和 Gateway 进程。十、总结从“金鱼”到“老友”Hermes 的三层记忆体系从根本上改变了 AI Agent 与用户的关系第一层会话记忆让 Agent 能够“回头看”——需要时翻查历史对话第二层持久记忆让 Agent 能够“认识你”——记得你是谁、喜欢什么第三层 Skill 记忆让 Agent 能够“记得怎么做”——把经验固化为可复用的能力三层同时运转Agent 执行任务时记忆层在喂上下文执行完之后技能层在判断要不要把这次的解法提炼成可复用文件执行轨迹则在后台积累成潜在的训练数据。最终的结果Hermes 不是“用完就忘”的工具而是一个会随着使用不断成长的数字伙伴。每一次对话、每一次任务都在让它更懂你、更会用你的方式解决问题。核心启示真正聪明的 AI 不需要你教它第二次。Hermes 的三层记忆机制正是实现这一目标的工程化路径——让 Agent 从“金鱼”变成“老友”从“工具”变成“伙伴”。 延伸阅读Hermes Agent GitHubhttps://github.com/NousResearch/hermes-agentHermes 官方文档https://hermes-agent.nousresearch.com/agentskills.io 开放标准https://agentskills.io/Honcho 用户建模https://honcho.dev/ 欢迎在评论区分享你使用 Hermes 的记忆体验你遇到过“AI 失忆”的尴尬瞬间吗