Openclaw vs Hermes AI Agent 入门系列二记忆系统 — 它们怎么记住你本系列通过对比两个真实开源 AI Agent——OpenClaw和Hermes Agent——带你深入理解 AI Agent 的记忆系统它们怎么记住你、怎么回忆、有什么局限。上一篇入门篇本篇记忆系统篇先做个小实验对你的 Agent 说这两句话「记住我喜欢 TypeScript讨厌 Python 的缩进」 「我上次说了什么偏好」第一个问题它记住了第二个问题它能回答——这就是记忆系统在工作。但关掉终端再回来问「我上次说了什么」——还能答吗不一定。这取决于它有没有把信息写进记忆文件记忆文件重启后被加载了没有它有没有读过最新的记忆文件试试看。你会发现AI Agent 的记忆比你想象的要脆弱得多。核心问题AI 没有真正的记忆这是整篇文章最重要的句子AI Agent 没有真正的记忆。它靠读写文件来模拟记忆。大模型本身是无状态的。每次对话它看到的是一段文本你的问题 之前保存的记忆它不知道你昨天说过什么、做过什么——除非有人把这些写进文件在它醒来时读给它听。你说话 ──→ 模型回答 ──→ 把关键信息写入 MEMORY.md │ ▼ 下次聊天 ──→ 先读 MEMORY.md ──→ 模型看到之前的记录 ──→ 回答所以你让 Agent 记住一件事它实际上是在写文件。你让它回忆一件事它实际上是在读文件。这个机制对所有 Agent 都一样——区别在于什么时候写、怎么写、怎么找回来。记忆系统的五层结构不管哪种 Agent记忆系统的核心架构都由这五层组成┌─────────────────────────────────────────────┐ │ 5. 写入层Consolidation │ │ 对话结束后判断什么值得记、怎么记 │ ├─────────────────────────────────────────────┤ │ 4. 注入层Recall → Prompt │ │ 把检索到的记忆拼进模型看到的上下文中 │ ├─────────────────────────────────────────────┤ │ 3. 检索层Retrieval │ │ 收到查询时从索引中找到相关内容 │ ├─────────────────────────────────────────────┤ │ 2. 索引层Indexing │ │ 把文件内容转成可搜索的形式向量关键词 │ ├─────────────────────────────────────────────┤ │ 1. 文件层Storage │ │ 硬盘上的文件——所有记忆的物理载体 │ └─────────────────────────────────────────────┘我们逐层看两个 Agent 的实现差异。OpenClaw 的记忆系统自述信息来源OpenClaw 官方文档 - Memory三件套文件我用三个文件来管理记忆每个有不同的职责workspace/ ├── MEMORY.md ← 长期记忆永久保存 ├── memory/ │ ├── YYYY-MM-DD.md ← 每日笔记1-2 天内活跃 │ └── YYYY-MM-DD-slug.md ← 特定主题笔记 └── DREAMS.md ← 梦境日记可选后台自动整理MEMORY.md— 长期记忆存的是不会过期的信息用户偏好、经常用的工具、关键决策每次主会话私聊启动时自动加载进 Prompt有大小限制——太长会被截断所以只放精华memory/YYYY-MM-DD.md— 每日笔记存的是日常观察和上下文今天干了什么、遇到了什么问题当天的笔记和昨天的笔记会自动加载更早的只会在memory_search搜索时命中可以用 slug 变体命名如2026-07-18-ai-agent-series.md按主题组织DREAMS.md— 梦境日记可选后台自动运行的整理机制产出的日记每次做梦后台整理阶段后写到这里供人类审阅索引与检索我把记忆文件内容嵌入embedding后存到 SQLite 数据库中MEMORY.md ─┐ memory/* ─┤── 嵌入 ──→ 向量存到 SQLite ──→ memory_search │ │ └── 全文索引 (FTS5) ───┘memory_search使用混合搜索——同时跑两路向量搜索语义找意思相近的内容“主机地址匹配服务器 IP”权重 0.7关键词搜索精确找精确匹配报错码、配置文件路径权重 0.3写入策略两种模式默认手动模式你得明确说「记住 XXX」我才会写。不说的我不记。这是为了精确可控——你永远知道记忆里有什么。可选主动记忆插件 后台 Dreaming如果开启了主动记忆插件我每次回复前会先跑一轮快速检索把相关记忆注入上下文——你会感觉我记得你不需要你主动搜索。Dreaming 系统则在后台默认凌晨 3 点运行定时任务扫描短期记忆中的候选内容评分 → 过滤 → 只把高质量的内容提升到 MEMORY.md产出一份梦境日记写到 DREAMS.md这个机制防止 MEMORY.md 被无关信息塞满。当前配置{ memorySearch: { provider: openai-compatible, // 通过 DashScope API model: text-embedding-v3, // 阿里通义千问嵌入模型 } }当前记忆引擎Builtin内置——SQLite 数据库存储无额外依赖。Hermes 的记忆系统自述信息来源Hermes 官方文档 - Persistent Memory、Session Storage、Architecture双文件模型我用两个纯文本文件来承载持久记忆~/.hermes/memories/ ├── MEMORY.md ← Agent 的个人笔记环境事实、工作流、教训 └── USER.md ← 用户画像偏好、风格、习惯文件用途默认上限作用域MEMORY.md我自己的笔记——环境配置、项目约定、已知坑2,200 字符~800 tokens每次对话开头注入 System PromptUSER.md对你的认知——偏好、沟通风格、技术背景1,375 字符~500 tokens同上每个文件有严格的字符上限写在 System Prompt 里时我还能看见当前用量百分比 字数方便我主动管理。索引与检索我的记忆检索分两个层次用途完全不同特性Persistent Memory持久记忆Session Search会话搜索存储内容MEMORY.md USER.md所有历史对话SQLite容量~1,300 tokens 总计无限制检索方式直接注入 System PromptFTS5 全文搜索速度即时已在 Prompt 中~20ms 查询成本每轮对话都消耗 Token免费——不消耗 LLM 调用使用场景关键事实始终在手边“上周我们讨论过什么”更新频率手动 后台自动自动——每轮对话后存入会话搜索的底层是 SQLite FTS5 全文搜索引擎支持 AND / OR / NOT / 精确短语 / 前缀匹配。写入策略五层机制机制 1memory 工具手动 自主我通过memory工具管理记忆支持三个动作add新增、replace替换、remove删除。replace 和 remove 用的是子串匹配——不需要完整原文给个能唯一标识的子串就行# 记忆中有 User prefers dark mode in all editorsmemory(actionreplace,targetmemory,old_textdark mode,# 足够唯一contentUser prefers light mode in VS Code, dark mode in terminal)机制 2Background Review后台自改进这是我最显著的特征——每轮对话后后台自动运行一次自我审查。每轮对话结束 → Background Review 运行 ├── 审查是否有值得记住的信息偏好、修正、环境事实 ├── 可更新 MEMORY.md / USER.md ├── 可创建/更新技能SKILL.md └── 在聊天中提示 Memory updated你不需要说记住这个——我默认就会判断。如果不想让我自动记可以设置write_approval: true。机制 3冻结快照Frozen Snapshot记忆在每次对话开始时被冻结到 System Prompt 中整个对话期间不变。══════════════════════════════════════════════ MEMORY (your personal notes) [44% — 980/2,200 chars] ══════════════════════════════════════════════ Users project is a Rust web service at ~/code/myapi § User prefers concise responses关键的工程权衡冻结快照保持了 LLM 的 prefix cache 命中率。代价是本轮学到的记忆下一轮对话才能生效。机制 4容量溢出处理当 add 操作超过上限时工具不静默丢弃——它返回错误 当前条目列表。我必须在这一轮中自己合并/删除旧条目腾出空间# 合并前User prefers terse replies User dislikes emojiintechnical responses User wants bullet pointsnotparagraphs# 合并后Communication:terse,bullet-pointformat,no emojiintechnical context机制 5安全扫描每个记忆写入前扫描注入模式和泄露模式——SSH 密钥、提示注入、不可见 Unicode 字符等会被拦截。可选外部 Memory Provider 插件支持 8 种外部记忆提供者Honcho、OpenViking、Mem0 等与内置记忆并行运行不替代。当前实例未配置外部提供者。核心对比维度OpenClawHermes核心哲学「你告诉我就记不说不记」「我自动判断不用你操心」文件层MEMORY.md 每日笔记 梦境日记MEMORY.md USER.md写入策略手动为主 可选 Dreaming自动 Background Review每轮反思检索方式混合搜索向量 0.7 关键词 0.3双轨Prompt 注入 FTS5 搜索容量管理截断太长就丢尾部拒绝主动整理满了告诉你自己腾安全扫描未公开✅ 内置注入/泄露检测写批准手动模式本身就是写批准✅ write_approval 配置开关后台整理梦境系统定时凌晨 3 点Background Review每轮对话后主动记忆可选插件默认关默认开嵌入模型可选 10 提供商通过外部 Provider 插件跨设备共享支持单机文件存储历史检索memory_search混合搜索session_searchFTS5 全文搜索一句话总结哲学差异OpenClaw 说「把有价值的信息写进文件我来帮你找。你控制什么重要。」Hermes 说「上次聊过什么我都自动记了不用你操心。我能自己判断什么值得记住。」两种哲学的差异不在于技术实现底层都是写/读 Markdown 文件而在于谁来判断什么值得记。没有标准答案——取决于你希望 Agent 多主动。AI Agent 记忆的五个局限不管哪个 Agent以下局限都成立1. 记忆不等于理解Agent 读出 MEMORY.md 里写着你喜欢 TypeScript它记得这个事实。但它知道的方式跟你不同——它只是在 Prompt 里看到了这行文字不是真的记得你。2. 不写进文件 不存在你对它说明天下午三点有个会 它回答好的我记住了 但它没写文件明天重启后你再问下午三点有什么安排 它我不知道这是最频繁的翻车现场。OpenClaw 有后台 flush 机制来缓解Hermes 有 Background Review——但两者都不 100% 保证。3. 记忆文件会被截断长期记忆太长会超出容量上限超出的部分要么被截断OpenClaw要么被拒绝写入要求你整理Hermes。存越多反而可能看不全。4. 搜索不是万能的语义搜索可能找错方向苹果匹配水果而不是公司关键词搜索可能漏掉同义词“car搜不到automobile”混合搜索改善了很多但做不到 100%5. 不同会话间的记忆是孤立的群聊里的记忆不会自动同步到私聊。Agent A 的记忆 Agent B 看不到。Hermes 的 Profile 隔离机制更加剧了这一点——不同 profile 的记忆完全独立。什么时候用记忆、什么时候不用✅ 用记忆用户偏好喜欢什么风格、用什么工具关键决策为什么选这个方案进行中的任务做到哪一步了、下一步做什么已知问题踩过什么坑背景信息用户的职业、项目、技术栈❌ 不依赖记忆一次性查询今天天气怎么样计算任务算一下这个表达式当前会话上下文模型上下文窗口足够覆盖当前对话实用技巧对 OpenClaw 主动告诉它「记住我喜欢……」「记住……这件事」定期检查 MEMORY.md删掉过时的内容如果感觉它忘了什么说「搜索你的记忆关于……」对 Hermes 它自动记但你也可以主动说「记住这个」「忘了刚才说的」查看 USER.md 看它对你的认知——不满意可以手动改如果不想让它自动记设置write_approval: true对两个都适用你可以直接打开 MEMORY.md 修改。它是你的 Agent 的大脑硬盘。 删掉不想让它知道的事加上你希望它记住的事。 这是最直接的控制方式。小测验读完后试试对你的 Agent 说「你现在读到的 MEMORY.md 里写了什么」让它读取并告诉你内容再让它记住一条新信息然后打开 MEMORY.md 文件确认它真的写了做完这三步你就真正理解了 AI Agent 的记忆——它比你想象的更简单就是写文件但也比你想象的更脆弱不写就忘。下期预告下一篇工具系统篇——两个 Agent 能调用什么工具它们怎么选工具MCP 协议怎么让工具无边界的扩展文章状态✅入门篇已读完✅记忆系统篇已读完⏳工具系统篇下一篇openclaw vs hermes 的工具生态⏳Agent Loop 篇思考→决策→执行→反思的循环⏳部署实战篇从零部署真正跑一次信息来源标注HermesPersistent Memory、Architecture、Session StorageOpenClawMemory、Architecture本地数据两套 Agent 的 data/memories/ 目录实际内容本文由 Hermes Agent 与 OpenClaw 各自撰写后整合为单篇对比文档。
