你有没有遇到过这种情况：跟 AI 聊了一个月，它还是不知道你叫什么，还是会犯同样的错，还是要你一遍遍解释背景。

这不是模型的问题，是架构的问题。

一、你的 AI 助手为什么越用越蠢

大多数 AI 工具的工作方式是这样的：你打开对话框，输入问题，它回答，对话结束。下次你再来，它什么都不记得。

这不是 bug，是设计。语言模型本身是无状态的——每次推理都从空白开始。所谓的”记忆”，要么是把历史消息塞进上下文窗口（有长度限制），要么是靠外部存储（需要架构支持）。

很多 Agent 框架选择了最简单的方案：让 Agent 自己维护一些 Markdown 文件，每次启动时读一读。这能解决基本问题，但有个隐患——它依赖 Agent 的自律性。Agent 得记得去读，得记得去写，得知道什么值得记。一旦 Agent 偷懒或者判断失误，记忆就断了。

更深层的问题是：记住信息和真正学习是两回事。

记住信息是”我知道你叫微尘”。真正学习是”上次我用这个方法帮你解决了问题，下次遇到类似情况我知道该怎么做，而且我会主动优化这个方法”。

前者是存储，后者是进化。

二、两种记忆哲学：文件 vs 结构

OpenClaw 的方式

OpenClaw 是一个成熟的 CLI Agent，它的记忆系统基于文件：

• MEMORY.md：长期记忆，Agent 手动维护的精华笔记
• memory/YYYY-MM-DD.md：每日日志，原始记录
• USER.md：关于用户的信息
• SOUL.md / IDENTITY.md：Agent 的人格设定

每次会话启动，Agent 按照 AGENTS.md 的指引，依次读取这些文件，把上下文装进脑子里。底层用 QMD 做向量索引，支持语义搜索。

这套方案的优点是透明、可控。所有记忆都是普通文本文件，你随时可以打开编辑，完全掌控 Agent 知道什么。

缺点也很明显：依赖 Agent 的执行纪律。Agent 必须记得在对话开始时读文件，必须记得在对话结束时更新文件，必须判断什么值得写进长期记忆。这些都是软约束，没有强制保证。

Skills 在 OpenClaw 里是 workspace 下的 Python 脚本，本质上是工具集合，靠人工管理，没有统一的结构规范。

Hermes 的方式

Hermes 把记忆做成了工具调用，而不是文件读写。

Agent 通过 memory() 工具写入记忆，系统自动把记忆注入到每一轮对话的系统提示里。不需要 Agent 记得去读，不需要 Agent 记得去写——这是框架层面的强制保证。

这个差异看起来很小，实际上影响很大：记忆从Agent 的责任变成了系统的责任。

三、Memory 三层拆解

Hermes 把记忆分成三层，各司其职：

第一层：user profile（你是谁）

存关于用户的稳定信息：名字、偏好、工作背景、沟通风格、时区。

这层信息变化慢，但影响每一次交互。Agent 知道你喜欢简洁的回答还是详细的解释，知道你是开发者还是运营，知道你的技术栈——这些都会影响它怎么跟你说话。

第二层：memory notes（知道什么）

存环境事实、工具怪癖、踩过的坑、已确认的规则。

比如：”这台服务器的 Python 环境在 /usr/local/bin/python3，不是系统默认的”，”这个 API 的分页参数叫 offset 不叫 page“，”用户不喜欢在回答里用 emoji”。

这层信息是 Agent 在实际工作中积累的，每次踩坑都是一次更新机会。

第三层：session search（做过什么）

这层不是主动存储，而是被动检索。Hermes 保存所有历史对话，当 Agent 需要回忆”上次我们怎么解决这个问题的”，可以用 session_search 跨会话搜索。

三层的分工：user profile 和 memory notes 是精华，小而精，每轮都注入；session search 是全量，按需检索，不占常驻上下文。

什么值得存，什么是噪音

记忆不是越多越好。塞太多进去，Agent 反而找不到重点。

值得存的：

• 用户纠正了 Agent 的行为（”不要这样做”）
• 发现了环境里的特殊情况
• 确认了某个工作流程有效
• 用户的稳定偏好

不值得存的：

• 单次任务的进度（用 session search 找）
• 临时状态（任务完成就过期了）
• 可以随时重新发现的信息

四、Skills：从”脚本”到”可进化的知识单元”

这是 Hermes 和其他 Agent 框架差距最大的地方。

OpenClaw 的 Skills

OpenClaw 的 skills 是 workspace 下的 Python 脚本。你写一个脚本，Agent 知道它在那里，需要的时候调用。本质上是工具，不是知识。

Hermes 的 Skills

Hermes 的 skill 是一个结构化的知识文档，格式是 YAML frontmatter + Markdown 正文：

---name:deploy-fastapidescription:在Ubuntu上用systemd部署FastAPI应用的完整流程tags:[python,fastapi,deployment,systemd]triggers:-部署FastAPI-fastapi上线-python服务部署---# 部署 FastAPI 到 Ubuntu## 前置条件-Python3.10+-有sudo权限## 步骤1.安装依赖...2.创建systemdservice文件...3.启动并设置开机自启...## 常见坑-注意WorkingDirectory要用绝对路径-环境变量要在service文件里单独声明

这个结构有几个关键设计：

触发词（triggers）：Agent 看到相关任务时，会自动匹配并加载对应 skill，不需要用户手动指定。

坑点（pitfalls）：把踩过的坑记录在 skill 里，下次遇到同样情况直接规避，不用重新踩。

关联文件：skill 可以附带脚本、模板、参考文档，形成一个完整的知识包。

Skills Hub：Hermes 有社区 skill 仓库，hermes skills browse 可以浏览，hermes skills install 一键安装。别人踩过的坑，你不用再踩。

Agent 怎么知道该存成 skill

Hermes 的设计原则是：完成一个复杂任务（5 步以上）、克服了非显而易见的错误、发现了特定环境的工作流程，就应该存成 skill。

Agent 在完成任务后会主动判断，也可以直接告诉它”把这个存成 skill”。

五、进化闭环：从踩坑到自我修正

真正的进化不是一次性的，是持续的。

纠错即学习

当你纠正 Agent 的行为时，这个纠正本身就是一次学习机会。Hermes 会把纠正写入 memory notes，下次遇到同样情况，它会记得你的偏好。

这个机制的关键是主动性。不是等你说”记住这个”，而是 Agent 自己判断”这个纠正值得记住”。

Skill 的生命周期

一个 skill 不是写完就完了，它有自己的生命周期：

1. 创建：解决了一个复杂问题，把过程提炼成 skill
2. 使用：下次遇到类似任务，自动加载
3. 发现问题：执行过程中发现 skill 有遗漏或错误
4. Patch：立即更新，不等下次

Hermes 有个原则：用完一个 skill 发现它有问题，必须在当次会话结束前 patch 它。过期的 skill 比没有 skill 更危险，因为它会给 Agent 错误的信心。

Session Search 补位

有些信息太细节，不适合放进常驻记忆，但将来可能用得上。这类信息就留在历史对话里，用 session search 按需检索。

比如”上次那个 nginx 配置问题怎么解决的”——不需要存进 memory，直接搜历史对话就能找到。

六、多 Provider 自由：不被一家模型绑架

这一点和”进化”关系不那么直接，但对实际使用影响很大。

Hermes 支持 18 个 provider，包括 OpenRouter、Anthropic、OpenAI、DeepSeek、阿里云百炼、MiniMax、Kimi，以及任何兼容 OpenAI 格式的自定义端点。

切换模型只需要：

hermes model

交互式选择，不需要改配置文件。

更实用的是凭证池：同一个 provider 可以配置多个 API key，Hermes 自动轮转，某个 key 用完了自动切下一个，不会因为单个 key 的限额中断工作。

对于有隐私需求或者想用国产模型的场景，可以自建 gateway，把本地部署的模型接入 Hermes，完全不依赖外部服务。

七、总结：工具 vs 伙伴的本质差距

工具是用完即走的。你用锤子钉钉子，锤子不会因此变得更擅长钉钉子。

伙伴是越来越懂你的。你们一起工作的时间越长，它越了解你的习惯、你的偏好、你的工作方式，越能在你开口之前就知道你想要什么。

Hermes 的设计目标是后者。Memory 让它记住你，Skills 让它积累经验，Session Search 让它不忘历史，多 Provider 支持让它不受限制。

这些机制单独看都不复杂，组合在一起，形成了一个越用越聪明的正向循环。

开始积累你自己的 skill 库吧。三个月后，你会发现你的 Agent 和别人的已经不一样了。