Hermes 三层记忆系统上会话记忆——让 AI 记住刚才聊了什么第 19 篇讲了 Hermes 的核心理念是会记住你。第 20 篇配好了 config.yml里面有个 memory 块分了三层session / persistent / skill。从这一篇开始我们一层一层拆开看。先从最底层的会话记忆开始——它是整个记忆系统的基础也是最容易被忽视的一层。会话记忆是什么当你和 Hermes 对话时每一轮你说的话、它的回复、它读过的文件、它执行的命令……所有这些信息按时间顺序组成一个数组这就是会话记忆。┌──────────────────────────────────────────────────────────┐ │ 会话记忆Session Memory │ ├──────────────────────────────────────────────────────────┤ │ │ │ Turn 1: 帮我写一个 FastAPI 的用户认证接口 │ │ [生成代码...] │ │ │ │ Turn 2: 密码哈希记得加 salt │ │ 已修正[更新后的代码...] │ │ │ │ Turn 3: 再加一个 JWT token 刷新接口 │ │ 好的基于刚才的认证模块我加上 refresh... │ ← 它知道刚才的认证模块 │ │ │ ...以此类推... │ │ │ └──────────────────────────────────────────────────────────┘会话记忆和普通聊天记录的区别聊天记录只是文本。会话记忆是结构化的——每条消息包含角色user/assistant/system/tool、时间戳、Token 数、关联的文件路径、被引用的记忆条目 ID 等元信息。会话记忆 vs 上下文窗口这两个概念经常被混淆但它们的区别很关键会话记忆Session Memory AI 可以访问的对话历史数据存储层 → 存在 SQLite 的 sessions 表中 → 理论上可以无限存储 上下文窗口Context Window AI 模型一次能看到的最大 Token 数推理层 → Claude Sonnet 4: 200K tokens → GPT-5: 128K tokens → 是模型架构决定的硬限制 关系 会话记忆 上下文窗口时 → 最旧的对话被裁剪掉 会话记忆 上下文窗口时 → 全部对话都在 AI 的视野内一个更直观的类比会话记忆 你桌上的所有文件一直在积累 上下文窗口 你能同时摊开看的桌面面积固定的 当文件太多 → 桌面放不下 → 最早的文件被收到抽屉里裁剪 你需要这些文件时 → 只能从抽屉里找持久记忆 / 摘要裁剪发生时会发生什么假设上下文窗口是 200K当前会话记忆是 250K ┌──────────────────────────────────────────────────────────┐ │ 被裁剪的区域50K │ 上下文窗口内的区域200K │ │ ──────────────────────── │ ──────────────────────────── │ │ Turn 1-15: │ Turn 16-30: │ │ 帮我建 FastAPI 项目 │ JWT 刷新逻辑有个 bug... │ │ 用 SQLAlchemy │ 这里的 expire time... │ │ 密码加 salt 和 bcrypt │ 不对应该是 refresh... │ │ │ │ │ ❌ AI 看不到这些了 │ ✅ AI 能看到 │ └──────────────────────────────────────────────────────────┘影响如果你在第 25 轮说之前那个密码加密方案改一下AI 已经看不到第 1-15 轮的对话了它不知道之前那个指的是什么——这就是为什么超长对话中 AI 会变笨。Hermes 的会话记忆存储在~/.hermes/data/memory.db中会话记忆存储在两张核心表中sessions 表CREATETABLEsessions(session_idTEXTPRIMARYKEY,-- UUIDuser_idTEXT,-- 关联用户titleTEXT,-- 自动生成的会话标题created_atTIMESTAMPDEFAULTCURRENT_TIMESTAMP,updated_atTIMESTAMPDEFAULTCURRENT_TIMESTAMP,total_tokensINTEGERDEFAULT0,-- 会话累计 Tokenmessage_countINTEGERDEFAULT0,-- 消息轮数statusTEXTDEFAULTactive,-- active | archived | deletedsummaryTEXT-- 超过上下文的早期内容摘要);messages 表CREATETABLEmessages(message_idTEXTPRIMARYKEY,session_idTEXTREFERENCESsessions(session_id),roleTEXTNOTNULL,-- user | assistant | system | toolcontentTEXTNOTNULL,token_countINTEGER,tool_calls JSON,-- 如果这轮调用了工具记录参数和结果file_refs JSON,-- 引用的文件路径列表memory_refs JSON,-- 引用的持久记忆条目 IDcreated_atTIMESTAMPDEFAULTCURRENT_TIMESTAMP);CREATEINDEXidx_messages_sessionONmessages(session_id,created_at);会话恢复机制当你退出 Hermes 再重新进入时# 查看所有会话hermes session list# 输出示例# session_id title updated messages# a1b2c3d4... FastAPI 用户认证模块开发 2026-06-04 15:30 12# e5f6g7h8... 数据库连接池优化讨论 2026-06-03 10:15 8# i9j0k1l2... 上周的代码风格讨论 2026-05-28 18:00 25# 恢复上次会话hermes session resume# 或恢复指定的会话hermes session resume a1b2c3d4恢复时 Hermes 会做什么从messages表加载该会话的所有消息根据total_tokens判断是否超过当前模型的上下文窗口如果没超过 → 全部注入上下文无缝衔接如果超过了 → 加载最近的消息 将早期的消息用summary替代让会话记忆更高效四个实践实践一一件事一个会话❌ 一个会话做所有事 Turn 1-5: 写用户认证模块FastAPI → JWT → bcrypt → 测试 Turn 6-10: 审查前端的登录页面React → 表单验证 → CSS Turn 11-15: 讨论 Kubernetes 部署方案Docker → K8s → CI/CD 问题三个不相关的话题挤在一个上下文里 → 每个话题能用的 Token 变少 → 讨论 K8s 时上下文里还留着 bcrypt 的细节噪音 ✅ 一个会话一件事 Session A: 写用户认证模块 → 做完 → /clear Session B: 审查前端登录页 → 做完 → /clear Session C: 讨论 K8s 部署 → 做完 → /clear 每个会话的上下文都聚焦在一个任务上 → AI 的注意力不会被无关信息稀释实践二主动清除不用的上下文# 1. 清除当前会话最常用/clear# 效果清空消息数组但保留持久记忆中记录的关键信息# 2. 忘记当前会话中最近 N 轮/forget-session5# 效果删除最近 5 轮对话适用于刚才那段讨论走错方向了# 3. 忘记当前会话中特定的内容/forget-session--keywordMySQL# 效果删除当前会话中包含MySQL的所有消息# 4. 归档会话不删除但不再加载到上下文hermes session archivesession_id什么时候该/clear当你感觉 Hermes 的回复开始出现这些信号信号 1它开始混淆这个任务和上一个任务的信息 信号 2它的代码开始偏离你的要求说明 System Prompt 的约束被对话历史稀释了 信号 3回复明显变慢上下文太大推理耗时增加 信号 4hermes session info 显示上下文使用率 80%实践三用摘要替代完整对话Hermes 支持预压缩——把早期的完整对话用一段摘要替代而不是直接丢弃# config.ymlmemory:session:backend:memorymax_messages:50ttl:3600# 新增上下文压缩策略compression:enabled:truestrategy:hybrid# rolling_window | summary | hybridkeep_recent:10# 最近 10 轮保持完整summarize_older:true# 更早的对话用 LLM 摘要替代三种策略的对比策略 最近的消息 早期的消息 效果 ───────────────────────────────────────────────────────── rolling_window 全部保留 直接丢弃 简单但丢失历史信息 summary 全部摘要 全部摘要 省 Token但细节丢失 hybrid 完整保留 自动摘要 推荐兼顾连贯性和省 Tokenhybrid的工作原理原始会话25 轮150K Token Turn 1 → ... → Turn 15 → Turn 16 → ... → Turn 25 压缩后~80K Token [摘要Turn 1-15 讨论了 FastAPI 的 JWT 认证方案 关键决策access token 30min/refresh token 7d 密码用 bcrypt salt数据库用 PostgreSQL] Turn 16完整→ ... → Turn 25完整实践四关键信息及时转入持久记忆会话记忆的局限是它会随着会话结束或裁剪而消失。所以——当前会话中的重要信息 → 应该尽快写入持久记忆 方式一Hermes 自动提取默认开启 Hermes 在后台分析对话 → 发现用户偏好函数式风格 → 自动写入持久记忆 方式二你主动标记 /remember JWT access token 过期时间设为 30 分钟 已存入持久记忆。 方式三对话中自然触发 记住我们这个项目用 PostgreSQL不用 MySQL 已记录项目数据库选型。会话记忆的常见问题问题一接近上下文天花板时 AI 变笨这是最常见的问题。现象前半段对话Hermes 的代码质量很高逻辑严密 后半段对话同一个话题Hermes 开始犯低级错误 → 变量名拼错 → 忽略了前面自己写的函数 → 重复问了已经回答过的问题原因上下文太满时模型的注意力被稀释。它在扫描海量历史消息时分配给每条消息的注意力远低于前半段。解决# 1. 先检查hermes session info# Token usage: 178K / 200K (89%) ← 危险# 2. 果断 /clear/clear# 3. 如果需要保留关键上下文先 /remember/remember当前任务重构用户模块的认证逻辑。已完成的JWT 签发和验证。待处理refresh token 轮换、token 黑名单。/clear# 这样持久记忆会保留下关键信息新会话自动加载问题二会话切换时上下文断裂Session A: 讨论了 20 轮 FastAPI 的项目结构 Session B: 全新的对话 → Hermes 不知道这个项目指的是什么 在刚才的项目里加一个接口 你指的是哪个项目我目前没有上下文。解决重要信息不放刚才的对话里放持久记忆里# Session A 结束时/remember项目 my-api 使用 FastAPI SQLAlchemy PostgreSQL目录结构 src/models → src/services → src/routers → src/schemas# Session B 开始时Hermes 自动从持久记忆中检索到项目 my-api的信息 → 不需要你重新介绍问题三工具调用结果占用大量 Token 帮我查一下用户表的结构 [调用工具读取 src/models/user.py] [工具返回整个文件 300 行代码8000 Token] 问题这 8000 Token 的模型定义会留在会话记忆中 → 后面 10 轮讨论要不要加个字段时这些字段定义一直在占用上下文解决Hermes 会自动将工具返回的大文件在对话历史中替换为摘要# config.yml 中可以配置advanced:context_management:tool_result_max_tokens:2000# 工具返回结果在对话中最多保留 2000 Tokentool_result_summarize:true# 超过上限的部分用 AI 摘要替代会话记忆的配置参考# config.yml 中 session 块的完整参数memory:session:backend:memory# memory(进程内重启丢失) | redis(跨重启)max_messages:50# 保留最近 N 条消息ttl:3600# 无活动后过期时间秒0 不过期compression:enabled:truestrategy:hybrid# rolling_window | summary | hybridkeep_recent:10# hybrid 模式下保留最近 N 轮完整summarize_older:truesummary_model:default# 用于生成摘要的模型default 当前主模型auto_title:true# 自动为会话生成标题save_tool_results:true# 是否保存工具调用结果tool_result_max_tokens:2000# 工具结果在对话中最多保留 Token 数persistent:# ... 下一篇讲skill:# ... 下下篇讲和 ChatGPT / Claude Code 的会话记忆对比ChatGPT Claude Code Hermes ────────────────────────────────────────────────────────────────── 会话恢复 自动30天 无每次独立 手动或自动 resume 上下文裁剪 透明用户无感 透明 可配置裁剪策略 预压缩 不支持 不支持 支持 hybrid 摘要 跨会话传递 靠持久记忆 靠 CLAUDE.md 靠持久记忆 resume 存储位置 云端 本地.claude/ 本地 SQLite 可见性 用户看不到会话数据 可查看 JSON 文件 hermes session list 可操作性 很低只能改名/删 低 高归档/恢复/搜索关键差异ChatGPT 和 Claude Code 的会话记忆对用户来说更像黑箱——你感受到它们记住了但你控制不了怎么记、记多少、什么时候清。Hermes 把会话记忆当作一个可管理、可调优的系统暴露出来。这篇文章的要点1. 会话记忆 ≠ 上下文窗口 → 会话记忆是存储层可以无限存 → 上下文窗口是推理层模型架构决定的硬限制 200K → 会话记忆 上下文窗口时最旧的对话被裁剪 2. 会话记忆存储在 SQLite 的 sessions messages 表中 → 支持会话恢复hermes session resume → 支持会话列表和归档 3. 四个让会话记忆更高效的实践 → 一件事一个会话做完就 /clear → 主动清除不用的上下文/forget-session → 用 hybrid 摘要替代完整历史省 40-50% Token → 关键信息及时转入持久记忆 4. 上下文使用率 80% 时 AI 开始变笨——这是我的经验阈值延伸阅读Hermes Memory 官方文档Claude 上下文窗口机制