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 不从零开始又能避免上下文失控。三、MemoryAgent 每次开工前都带着的“随身便签”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 更合适。调用形态输入作用Discoveryquery用关键词搜索过去会话找到相关 sessionScrollsession_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 的边界理解这三者最重要的是不要按“是不是记忆”来分而要按“信息类型”来分。事实、历史、流程分别走不同通道。维度MemorySession SearchSkills本质长期事实便签历史会话搜索可复用流程手册典型内容偏好、环境、约定、坑点过去某次对话、工具输出、决策过程步骤、模板、脚本、验证方法进入上下文时机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 SearchSession 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它知道你的偏好能找回过去的讨论还能把成功做法沉淀为下次可复用的流程。真正值得学习的不是某个单点功能而是这套分层思想事实、历史、流程各归其位。