Hermes Agent 里 Memory、Session Search、Skills 到底有什么区别？
一、先给结论：三者不是同义词，而是三种不同的长期能力
很多人第一次看 Hermes Agent，会把 Memory、Session Search、Skills 都理解成“记忆”。这种理解不算错，但太粗了。真正落到工程实现时，这三者解决的是完全不同的问题：Memory 解决“关键事实要一直在场”；Session Search 解决“过去聊过的细节要能找回来”；Skills 解决“成功流程要能复用”。
Hermes 官方文档把内置 Memory 描述为有边界、被整理过、能跨会话持久存在的记忆；它用于保存用户偏好、项目、环境和学到的事实。Session Search 则基于本地 session 数据库做全文检索，返回的是过去会话里的真实消息。Skills 是按需加载的知识文档，用来记录任务流程、工具用法、坑点和验证方式。
机制 | 一句话定义 | 最适合保存 | 不适合保存 |
Memory | 高价值事实便签 | 用户偏好、项目约定、环境事实、工具坑点 | 临时日志、大段代码、一次性任务进度 |
Session Search | 可搜索的历史会话档案馆 | 过去具体聊过什么、当时怎么决策、任务做到哪一步 | 需要每次都立即可见的稳定偏好 |
Skills | 可复用的流程手册 | 发版流程、PR 工作流、排错 SOP、工具操作步骤 | 单个事实、一次性聊天记录、没有复用价值的信息 |
二、为什么要分成三套机制？因为“长期能力”也有成本
普通 Chatbot 的问题是“关掉窗口就忘”。但如果反过来，把所有内容都塞进系统提示词，新的问题又来了：Prompt 变长、成本变高、模型注意力被噪声干扰、过期信息还会误导后续任务。Hermes 的思路不是把所有历史变成一个巨大 Prompt，而是把长期信息分层。
分层的核心逻辑很简单：高频、稳定、短小的信息进入 Memory；低频、具体、可追溯的信息留在 Session Search；可重复、步骤化、能指导执行的信息沉淀成 Skills。这样既能让 Agent 不从零开始，又能避免上下文失控。
三、Memory：Agent 每次开工前都带着的“随身便签”
1、Memory 记的是事实，不是整段历史
Hermes 的内置 Memory 由两个文件组成：MEMORY.md 和 USER.md。前者更偏 Agent 自己的工作笔记，比如项目结构、机器环境、约定、工具经验；后者更偏用户画像，比如用户偏好、沟通风格、长期习惯。官方文档说明，这两个文件都位于 ~/.hermes/memories/，并且会在 session 开始时作为冻结快照注入系统提示词。
这意味着 Memory 的信息不是“需要时再查”，而是“每次开场就带着”。这种机制让 Hermes 一开始就知道用户偏好和项目背景，但也带来一个限制：Memory 不能太大、不能太乱，否则每次调用模型都会为它付出上下文成本。
2、Memory 应该短、准、稳定
Memory 里最值得保存的是长期稳定且经常影响决策的信息。例如用户喜欢简洁回答、项目使用 pnpm、服务部署在某台机器、测试命令是 make test、某个工具有特殊坑点。这类信息越早被 Agent 知道，后续工作越顺。
不适合放 Memory 的信息包括：大段日志、完整代码、临时文件路径、一次性任务进度、某次聊天的完整过程。这些内容要么太大，要么很快过期，要么可以从 Session Search 里按需找回来。
适合放 Memory | 原因 |
用户偏好 | 每次回复风格都会受影响，比如要详细还是简洁 |
项目约定 | 每次改代码、写文档、跑命令都可能用到 |
环境事实 | 比如系统、包管理器、部署路径，避免重复询问 |
工具坑点 | 比如某个命令不能加 sudo，能减少重复踩坑 |
明确要求记住的信息 | 用户主动要求长期记住，优先级最高 |
不适合放 Memory | 原因 |
一次性任务日志 | 任务结束后价值快速下降 |
大段代码或数据表 | 太占上下文，应放文件或知识库 |
完整聊天记录 | 应该留在 Session 中，通过搜索找 |
能轻易重新搜索的公共知识 | 没有必要占用长期上下文 |
已经在 AGENTS.md 或 SOUL.md 里的内容 | 重复注入会浪费上下文 |
3、Memory 的风险：太多会变成噪声，太旧会变成误导
Memory 的优势是“稳定在场”，风险也是“稳定在场”。一条过期的项目路径、一条不再适用的部署命令、一个已经改变的偏好，如果长期留在 Memory 里，就会持续影响 Agent 的判断。所以 Memory 需要被整理、合并、替换，而不是只增不删。
官方文档也强调了容量管理：当 Memory 接近上限时，Agent 应该合并相关条目、替换冗余条目，而不是无脑追加。这一点非常像人类整理笔记：笔记越多不等于越聪明，关键是结构清晰、信息密度高。
四、Session Search：把历史会话变成可检索档案
1、Session Search 不是 Memory，而是历史检索工具
Session Search 解决的问题是：用户说“上次那个问题”“之前我们讨论过的方案”“继续昨天的进度”，Agent 怎么知道具体指哪件事？如果全部依赖 Memory，就会把很多临时历史塞进长期上下文；如果完全不记，就只能让用户重复说明。
Hermes 的 Sessions 文档说明，每一次来自 CLI、Telegram、Discord、Slack、WhatsApp、Signal、Matrix、Teams 等入口的对话都会保存为 session，并存入 ~/.hermes/state.db。这个数据库保存 session 元数据、完整消息历史、工具调用、工具结果、Token 计数等，还通过 messages_fts 建立 FTS5 全文检索。
2、Session Search 返回的是“真实消息”，不是模型编的总结
官方文档对 session_search 的描述很关键：它会跨过去所有会话做 FTS5 全文搜索，并且返回数据库里的真实消息，不做 LLM 总结，不做截断式想象。这个设计让它更像“聊天记录搜索”，而不是“模型凭感觉回忆”。
Session Search 有三种典型使用方式：第一是 Discovery，传入关键词，找到相关会话；第二是 Scroll，围绕某条消息继续向前或向后看更多上下文；第三是 Browse，不传参数，浏览会话列表。对于“我们之前怎么决定的”这类问题，它比 Memory 更合适。
调用形态 | 输入 | 作用 |
Discovery | query | 用关键词搜索过去会话，找到相关 session |
Scroll | session_id + around_message_id | 在某个命中位置前后继续滚动，补充上下文 |
Browse | 无参数 | 浏览最近或已有 session，适合找不确定关键词的历史 |
3、Session Search 适合找“曾经发生过什么”
比如用户说：“上次我们是不是把登录模块改到一半？”这时 Agent 不应该把“登录模块改到一半”长期写进 Memory，因为这种状态可能很快过期。更合适的方式是调用 Session Search，检索过去相关对话，找到当时的最后结论、未完成事项和工具输出。
Session Search 的价值在于可追溯。它能让 Agent 说清楚“我找到了之前那段对话，当时我们决定先改 token 刷新逻辑，剩下的是前端兼容验证”。这比一句模糊的“我记得我们讨论过”更可靠。
五、Skills：把一次成功做法沉淀为下次可复用的流程
1、Skills 不是事实库，而是任务手册
Hermes 官方文档把 Skills 定义为按需加载的知识文档。所有技能默认位于 ~/.hermes/skills/，新安装的 bundled skills、Hub 安装的技能、Agent 自己创建的技能都可以进入这里。每个 Skill 的核心通常是 SKILL.md，里面写明什么时候使用、具体步骤、已知坑点、验证方式，以及需要的工具集。
如果说 Memory 是“用户喜欢简洁回答”，Session Search 是“上周我们讨论了发版失败”，那么 Skill 就是“以后每次发版应该按这 8 步执行，并用这 3 个命令验证”。它关注的是可重复执行的方法，而不是单个事实或某次聊天。
2、Skills 的关键设计：按需加载，而不是全量注入
Skills 如果全部塞进系统提示词，成本会非常高。Hermes 使用 Progressive Disclosure，也就是“渐进披露”：先通过 skills_list 看到技能名称、描述、分类；只有判断某个技能真正相关时，才通过 skill_view 加载完整 SKILL.md；如果还需要脚本、模板、参考文件，再加载具体路径。
这个设计很像人类查手册：先看目录，再翻到某章，最后才打开附录或脚本。这样能让 Hermes 拥有大量技能，又不会让每次对话都背着一大堆无关说明。
3、什么内容应该做成 Skill？
一个判断标准是：如果同类任务未来还会反复出现，而且每次都需要一套稳定步骤，那么它就值得做成 Skill。例如创建 PR、排查线上 500 错误、发版、生成技术文章、跑数据分析、处理某类图片、对接某个 API。
好的 Skill 不只是步骤列表，还应该包含触发条件、输入要求、容易出错的地方、验证标准和回滚策略。这样下次 Agent 不是简单“记得有这件事”，而是真正知道怎么把任务做完。
适合做成 Skill 的内容 | 为什么 |
发版流程 | 步骤固定，风险高，适合沉淀检查清单 |
PR 工作流 | 每次都涉及分支、测试、提交、描述、审查 |
故障排查 SOP | 可复用排查顺序能显著节省时间 |
内容生成模板 | 结构稳定，能保持输出风格一致 |
外部工具操作流程 | 减少重复解释账号、路径、参数格式 |
六、核心对比：Memory、Session Search、Skills 的边界
理解这三者，最重要的是不要按“是不是记忆”来分，而要按“信息类型”来分。事实、历史、流程分别走不同通道。
维度 | Memory | Session Search | Skills |
本质 | 长期事实便签 | 历史会话搜索 | 可复用流程手册 |
典型内容 | 偏好、环境、约定、坑点 | 过去某次对话、工具输出、决策过程 | 步骤、模板、脚本、验证方法 |
进入上下文时机 | session 开始时注入 | 需要时工具检索 | 需要时按层级加载 |
容量特点 | 小，必须高密度 | 大，存完整历史 | 中到大，按需加载 |
Token 成本 | 每次会话固定消耗 | 不用不消耗 | 用到才消耗 |
维护方式 | Agent 通过 memory 工具增删改 | 自动保存 session，可搜索和清理 | skill_manage 创建、更新、删除 |
最怕什么 | 信息过期、越存越乱 | 关键词找不到、历史太多没清理 | 流程写得太宽泛、没有验证标准 |
七、真实场景：用户说“继续上次那个项目”时，三者怎么配合？
假设用户说：“继续上次那个发版任务，还是按我们项目的规则来。”这句话里同时包含三个信号。第一，“项目规则”需要 Memory 或 Context File 提供稳定背景；第二，“上次那个发版任务”需要 Session Search 找到历史上下文；第三，“发版任务”本身可能对应一个 release Skill。
最终 Hermes 的表现不是简单回答“好的”，而是可能先从 Memory 知道项目使用 pnpm、CI 在 GitHub Actions、用户希望简洁汇报；再用 Session Search 找到上次停在 staging 验证；然后加载发版 Skill，按流程继续执行。
八、常见误区：把三者混用，会让 Agent 越用越乱
1、误区一：什么都存 Memory
这会让 Memory 从“便签”变成“垃圾桶”。一开始看似更聪明，长期看会导致系统提示词变长、成本升高、过期信息干扰新任务。Memory 只应该保存少量高价值事实。
2、误区二：所有历史都靠 Session Search
Session Search 很适合查具体历史，但它不适合替代稳定偏好。比如用户长期要求“生成 Word 文档并嵌入图片”，这种偏好应该进入 Memory 或项目规则，而不是每次都去翻历史会话。
3、误区三：成功流程只留在聊天记录里
如果一个流程已经反复出现，就不应该每次都从 Session Search 里找零散历史。更好的方式是升级成 Skill，让 Agent 下次按标准流程执行。
九、如果把这套思想用到自己的 Agent 系统，应该怎么设计？
即使你不用 Hermes，也可以借鉴这套分层方式。很多自研 Agent 系统失败，不是模型不够强，而是把所有上下文都混在一起：用户偏好、项目规则、历史聊天、工具输出、流程文档、临时日志全部塞进一个 Prompt。短期能跑，长期必乱。
更好的设计是三层资产化：第一层是 Memory，记录稳定事实；第二层是 Session Store + Search，保留历史证据；第三层是 Skill Library，把成功经验写成可执行流程。这样 Agent 的长期能力不是靠“模型神奇地记住”，而是靠工程系统把信息放在正确的位置。
自研系统模块 | 对应 Hermes 思想 | 实现建议 |
用户画像表 | USER.md | 只存长期偏好、语言风格、角色信息 |
项目事实表 | MEMORY.md | 只存稳定环境、项目约定、工具坑点 |
聊天记录库 | Sessions + FTS5 | 所有消息、工具调用、结果都可检索 |
流程模板库 | Skills | 把高频任务写成 SOP、模板、脚本 |
上下文组装器 | Prompt Builder | 按优先级和触发条件把信息送进模型 |
十、源码阅读路线：想看实现，应该先看哪里？
从源码角度看，建议不要一上来追所有函数，而是带着三个问题去看：第一，Memory 是怎么被保存、限制、注入系统提示词的；第二，Session Search 是怎么基于 state.db 和 FTS5 找历史消息的；第三，Skills 是怎么列出、加载、管理和变成 slash command 的。
先看官方 Persistent Memory 文档，理解 MEMORY.md、USER.md、冻结快照、memory 工具和容量限制。
再看 Sessions 文档，理解 state.db、messages、messages_fts、Session Search 三种调用方式。
然后看 Skills System 文档，理解 SKILL.md、progressive disclosure、slash command 和 skill_manage。
最后回到 GitHub，看 prompt_builder.py、run_agent.py、skills 相关工具和 session 相关存储代码如何串起来。
十一、总结：Memory 记事实，Session Search 找历史，Skills 记流程
Hermes Agent 的长期能力，不是单靠模型参数里的“记忆”，而是靠工程系统把不同类型的信息分层处理。Memory 负责少量、稳定、高价值的事实；Session Search 负责庞大、具体、可追溯的历史；Skills 负责可复用、步骤化、能指导执行的经验。
这三者组合起来，才让 Hermes 表现得像一个“越用越懂你”的 Agent：它知道你的偏好，能找回过去的讨论，还能把成功做法沉淀为下次可复用的流程。真正值得学习的不是某个单点功能，而是这套分层思想：事实、历史、流程，各归其位。