AI Agent 记忆系统架构设计：OpenClaw、Claude Code、Hermes Agent 深度对比

记忆，是把 Agent 从“用完就走”的工具变成“持续成长”的智能体的关键。如果说大模型是 Agent 的大脑，那记忆系统就是它的硬盘——决定了它能不能跨会话记住你的偏好、从过往经验里学点东西、在复杂任务里保持一致性。没有记忆，每次对话都是一次“格式化重启”。

这篇文章要深入对比三个代表性项目的记忆系统设计：OpenClaw（通用 Agent 框架）、Claude Code（编程 Agent）和 Hermes Agent（自进化 Agent）。它们各自代表了三种截然不同的设计哲学——文件优先的本地记忆、工程化的上下文压缩、以及自主学习的闭环系统。哪个更适合你的场景？看完你应该会有答案。

一、为什么记忆系统是 Agent 架构的核心瓶颈？

在深入细节之前，有必要先搞清楚记忆系统到底要解决什么问题。大语言模型本质上是个无状态的推理引擎——每次调用都从零开始，Session 内有效，Session 外失忆。这就带来了三个实实在在的工程问题：

1. 上下文污染：长对话里会混入冗余指令、已经过时的决策、甚至错误的假设残留，模型越聊越不稳定，你都不知道它什么时候会“发疯”。
2. 经验无法复用：用户每次都得重新解释项目结构、编码规范和个人偏好。试想一下，每次打开 IDE 都要告诉它“我不喜欢 TypeScript”——这体验太糟糕了。
3. 成本指数上升：上下文越长，Token 成本越高、推理延迟越大，质量反而还往下掉。花更多的钱，办更差的事，谁也不愿意。

一个设计良好的记忆系统，需要在速度、成本和保真度之间找到动态平衡。但不同场景对记忆的需求差异很大——个人助手需要记住用户偏好，企业客服需要多客户隔离，编程 Agent 需要压缩长对话，自进化 Agent 需要从经验中提炼技能。

先看看这三个项目的定位差异：

二、OpenClaw：文件优先的本地记忆架构

OpenClaw 代表了一种很有意思的设计思潮——“逆数据库”。它拒绝把记忆黑盒化地塞进向量数据库，而是用本地的 Markdown 文件作为真理的唯一来源。这种做法的核心优势非常明显：透明、可控、可审计。你可以像读笔记一样翻看它的“记忆”，也可以直接编辑文件来纠正它。

2.1 双层记忆拓扑

OpenClaw 的记忆体系分为两个独立但协同的层次：

瞬时情境层：以 memory/YYYY-MM-DD.md 格式存储的每日日志，采用“仅追加”模式记录当天所有对话。这一层不做任何过滤或压缩，保留原始对话流供后续回溯。说白了就是原原本本地记下来，好坏不论。

持久知识层：MEMORY.md 作为长期记忆的入口文件，存储经过筛选、压缩和固化的高价值信息。Agent 通过严格的“隐私门控”决定哪些瞬时记忆“有资格”晋升到持久层。

这种分层设计的价值在于“预压缩”——当会话的 Token 使用量触及软阈值时，会触发一个静默的“智能体回合”，强制模型在遗忘之前主动进行认知结晶。OpenClaw 不会等到上下文爆满才被动处理，而是在关键节点主动触发记忆沉淀。这个设计思路，有点像我们每天写日记，但周末会整理出值得长期保留的要点。

2.2 混合检索算法

OpenClaw 放弃了传统的 RRF（倒数排名融合），转而采用一种保留原始分数幅度信号的混合检索策略：

• 向量检索（70% 权重）：利用 sqlite-vec 进行余弦相似度计算，主要捕获语义层面的相关性。
• 关键词检索（30% 权重）：利用 SQLite FTS5 进行精准匹配，确保专有名词和技术术语不会被遗漏。

这个权重分配背后有一个很实在的洞察：在多数 Agent 场景中，“意思相近”比“用词相同”更重要。但完全放弃关键词匹配也不行——你说“Flask”和“Django”语义相近，但技术选型时它们完全是两码事。

2.3 企业级扩展：memory-agentcore

OpenClaw 的基础版是为单用户设计的——所有客户的偏好都混在同一个 MEMORY.md 里。这在多客户服务场景下会出大问题：客户 A 的“喜欢素色”和客户 B 的“喜欢鲜艳”相互污染，Agent 召回的信息一团乱麻。

Amazon 开源的 memory-agentcore 插件就是来解决这个问题的。它在原有双层架构上叠加了一层云端共享层：

这个插件的核心创新在于层级命名空间 + actorId 驱动的权限隔离。在多客户场景下，通过 peerId 实现记忆按客户自动隔离，同时支持跨 Agent 天然共享。比如，导购 Agent 记录的“客户对化纤过敏”可以被客服 Agent 直接访问，但客户 B 永远看不到客户 A 的偏好。这在企业级应用里是刚需。

2.4 2026.4.11 升级：主动记忆型运行时

2026 年 4 月，OpenClaw 完成了一次架构层面的重大升级，从“被动查询”转向“主动推送”模式。这个变化很关键——之前是“你问我才想起来”，现在是“我根据情况主动告诉你”。

新增的 Dreaming 模块 实现了三大突破：

1. 多源数据适配层：通过标准化适配器接口，支持 JSON、CSV、Markdown 等 12 种常见对话格式的自动解析。不管你的数据从哪来，都能往里灌。
2. 语义对齐算法：采用 BERT+BiLSTM 混合模型，将不同平台的对话片段映射到统一语义空间。这解决了跨平台数据“语言不通”的问题。
3. 增量记忆更新：支持每秒处理 500+ 条历史记录的实时导入。批量导入不再是大问题。

Memory Palace（记忆宫殿）模块 则引入了一个三维空间记忆模型——用户可以创建多达 200 个独立记忆场景，通过 R-Tree 空间索引实现毫秒级检索，甚至还提供了 Web 端 3D 编辑器进行可视化布局。直观地管理记忆，不再是一堆文件。

三、Claude Code：工程化的上下文压缩记忆

Claude Code 是 Anthropic 推出的编程 Agent。它的记忆系统设计面临一个核心挑战：在极长的代码生成会话中，如何在不丢失关键信息的前提下控制上下文窗口？答案是一套精密的“多级压缩 + 按需检索”架构。它不像 OpenClaw 那样什么都存，而是想方设法把有用的东西“塞”进有限的上下文里。

3.1 记忆文件体系

Claude Code 的记忆文件采用分类存储策略：

每个记忆文件都是 Markdown 格式，通过 frontmatter 记录类型、描述、修改时间等元数据。系统还配置了严格的容量上限：

• MEMORY.md 最大 200 行 / 25KB
• 最大记忆文件数 200 个
• 单次最多召回 5 条相关记忆

这些限制不是随便定的——200 行约等于 5-10 分钟阅读量，25KB 约 6000-8000 tokens，正好是 LLM 高效处理的“甜区”。多了它消化不了，少了又不够用。

3.2 多级上下文压缩机制

这是 Claude Code 记忆系统中最具工程价值的部分。当 Token 使用量达到预设阈值时，系统按顺序执行四种压缩模式，每种模式由独立的 feature gate 控制：

第四级压缩是最激进的——当上下文使用率达到 87% 时，系统会触发一个独立的“压缩袋里”，由该袋里读取当前完整上下文，生成一个 SystemCompactBoundaryMessage，然后用这个摘要消息替换原有上下文。这个设计的关键在于：压缩本身也是由 Agent 完成的，而不是简单的截断或摘要算法。相当于让 Agent 自己“写总结”，比任何人写的都更懂上下文。

3.3 记忆查询流程

Claude Code 的记忆检索采用“清单 + 模型选择”模式，而不是自动向量检索：

1. 用户发起对话后，系统调用 loadMemoryPrompt() 加载记忆入口。
2. scanMemoryFiles() 遍历记忆目录下所有 .md 文件，排除 MEMORY.md。
3. 解析每个文件的 frontmatter，提取 type、description、mtime 等字段。
4. 将扫描结果格式化为模型可读的清单，由模型自主选择最相关的 ≤5 条记忆。
5. 选中的记忆与当前对话一起提交给模型生成回答。

这种设计的优势是模型拥有选择权——只有模型自己知道当前任务需要哪些历史信息。缺点是每次都需要扫描所有记忆文件，随着记忆文件数量增加，扫描开销也会线性增长。不过对于编程场景来说，200 个文件的上限其实不算大问题。

3.4 claude-mem：第三方长期记忆扩展

除了 Claude Code 内置的记忆系统，社区还开发了 claude-mem 插件，为 Claude Code 增加长期记忆能力。其核心设计是“AI 压缩 + 精准注入”：

• 全量记录：捕获 Claude 在 coding session 中的所有行为——对话、修改、决策路径。
• AI 压缩：将 5000 tokens 的原始上下文压缩为 200 tokens 的高密度记忆片段，保留核心信息、丢弃冗余。
• 精准注入：在未来交互中根据当前任务自动检索相关记忆并注入 prompt。

claude-mem 与 Claude Code 的关系可以这样理解：Claude Code 像是“手”，OpenClaw 像是“身体”，而 claude-mem 则是“大脑记忆”。它并不是要替代 Claude Code 的内置记忆，而是在其之上叠加一层长期记忆能力，让编程 Agent 也能“记性好一点”。

3.5 后台 Dream 整合机制

Claude Code 还有一个独特的设计：Dream 整合（Dream Consolidation）。对话结束后，系统在后台异步执行记忆整合：

• 读取会话记录（.jsonl 格式）
• 提取新知识存入对应类型的记忆文件
• 定期执行“Dream 压缩”——合并冗余条目、修剪过时信息、优化记忆结构
• 使用锁文件（.consolidate-lock）防止并发冲突

这个机制的命名很有意思，致敬了人类睡眠中的记忆巩固过程——白天的经历在睡眠中被重新激活、筛选、固化到长期存储中。Agent 也需要“睡一觉”才能更好地记住东西。

四、Hermes Agent：自主进化的记忆系统

Hermes Agent 代表了第三代 Agent 记忆系统的设计方向：Self-Improving——不仅记住信息，更从经验中提炼可复用的技能，让 Agent 越用越强。上线不到半年 GitHub 星标破 10 万，是目前增长最快的 Agent 项目之一。为什么这么火？因为它解决了一个很痛的问题：大多数 Agent 干完活就“失忆”，下次还得从头学起。

4.1 Memory：声明式事实存储

Hermes 的 Memory 系统设计极为克制——只有两个纯文本文件，用 § 分隔条目：

~/.hermes/memories/
├── MEMORY.md    # Agent 的环境认知（项目约定、工具怪癖、环境细节）
└── USER.md      # Agent 对用户的认知（偏好、沟通风格、工作习惯）

关键的设计决策是严格的字符上限：MEMORY 限 2200 字符，USER 限 1375 字符。这迫使 Agent 只能记录最高密度的信息，过时的条目会被新信息自然“挤掉”。

对比一下 OpenClaw 的纯追加模式——几个月后 MEMORY.md 可能膨胀成几万行的怪兽文件，找一句话需要通读全文。Hermes 的做法是“被动淘汰”而非“主动清理”。当添加新条目会超限时，add 操作直接失败，并返回当前所有条目给模型，由模型自己决定删什么、改什么、合并什么：

if new_total > limit:
    return {
        "success": False,
        "error": f"Memory at {current:,}/{limit:,} chars. Adding would exceed limit.",
        "current_entries": entries,  # 让模型看到现有内容，自己决定如何整理
    }

这个设计的精妙之处在于：它迫使模型进行主动的信息整理——这本身就是一次“自我反思”过程。模型需要思考哪些信息更重要，哪些可以合并，哪些已经过时。这不就是我们在整理笔记时做的事情吗？

另一个精妙设计是冻结快照机制：每次会话启动时，Memory 加载后立刻捕获一份快照，之后系统提示词里用的都是这份快照，而非实时内容。为什么这么设计？因为系统提示词在会话内不变可以共享前缀缓存（Prefix Cache），能大幅节省 API 成本。新写入的内容只改磁盘，下一个会话才刷新进来。你看，技术的细节里往往藏着省钱的门道。

Memory 的写入遵循“声明式事实”原则——提示词中明确要求：

• ✓ “User prefers concise responses”（用户偏好简洁回复）
• ✗ “Always respond concisely”（始终简洁回复）

前者是可供推理的偏好，后者是僵硬的指令。Memory 只存前者，保持 Agent 的灵活性，不会因为一条记忆就把 Agent 的能力“框死”了。

4.2 Skill：程序性记忆与自主进化

如果说 Memory 是“知道什么”，那么 Skill 就是“会做什么”。这是 Hermes 与 OpenClaw 最核心的差异所在。

OpenClaw 也有 Skill 系统（SKILL.md + YAML frontmatter），但它的 Skill 要么是用户手写的，要么是从社区装的——Agent 本身不会从工作中学习任何东西。干了一百次部署，第一百零一次犯的错跟第一次一模一样，这是个很明显的瓶颈。

Hermes 的设计则完全不同：Agent 在完成任务后，会自动将踩坑经验提炼成可复用的 Skill。每个 Skill 是一个目录，核心是 SKILL.md 文件：

---
name: flask-k8s-deploy
description: Deploy a Flask app to Kubernetes with health checks
version: 1.0.0
---
# Flask K8s Deployment

## When to use
- User wants to deploy a Flask/Python app to Kubernetes

## Steps
1. Create Dockerfile with gunicorn (not dev server)
2. Build and push image to registry BEFORE creating deployment
3. Write deployment.yaml with livenessProbe pointing to /health
...

## Pitfalls
- MUST push image to registry before kubectl apply, otherwise ImagePullBackOff
- Flask 默认没有 /health 端点，需要手动添加

注意 Pitfalls 这一节，它不是预先写好的，而是 Agent 踩坑后追加的——这就是 Skill 层面的“自我进化”。第一次部署踩到了 ImagePullBackOff 的坑，Agent 就会把它记录到 Pitfalls 里，下次再碰到类似任务时就不会再犯同样错误了。这不就是我们常说的“吃一堑，长一智”吗？

创建 Skill 的触发条件在 skill_manage 工具的 schema 中明确定义：

• 复杂任务成功完成（工具调用超过 5 次）
• 成功克服了错误
• 用户纠正的方法验证有效
• 发现了非简单的工作流

同时还有一条关键规则：如果使用 Skill 时遇到了 Skill 没覆盖的问题，立即用 patch 操作更新它，不要等用户提醒。 这确保了 Skill 会随着使用不断精化、迭代。

Skill 的更新不是简单的追加，而是版本化的差异管理——Agent 可以对比新旧版本，只更新变化的部分，保留完整的历史演进轨迹。如果你需要审计某个 Skill 是怎么一步步“进化”成今天这个样子的，完全可以回溯。

4.3 三层记忆架构

Hermes 官方文档中描述了三层记忆系统，比前两个项目更完整：

会话记忆使用时间衰减算法自动清理过期数据；持久记忆通过增量学习机制避免“灾难性遗忘”——学新东西不会把旧的给忘了；技能记忆支持版本控制和差异比对，当检测到重复性任务时自动提炼为标准化技能模板。

4.4 闭环系统：Nudge Engine

连接 Memory 和 Skill 的是 Nudge Engine——一个定时运行的提醒机制，定期“推”Agent 进行反思：

• 回顾最近完成的任务
• 检查是否有值得提炼的操作模式
• 如果发现重复性工作，创建或更新相关 Skill
• 清理过时的 Memory 条目

这个闭环系统是 Hermes “自主进化”能力的工程化实现：Memory 提供事实基础 → 任务执行积累经验 → Skill 提炼可复用流程 → 下次任务更高效 → 继续发现新的可提炼点。就像一个不断自我进化的“飞轮”，越转越快，越转越强。

五、三种架构的对比分析

5.1 设计哲学对比

5.2 核心差异：信息密度的处理

三种架构最本质的差异在于对信息密度的不同处理方式：

OpenClaw 采用“文件即真理”的低密度存储。所有信息都以原始或接近原始的形式存入 Markdown，优势是完全透明、可审计、可 Git 管理；劣势是文件会无限膨胀，检索效率随数据量增长而下降。它就像一个从不收拾抽屉的人，什么都在里面，但你要找东西就得翻半天。

Claude Code 采用“按需压缩”的中密度策略。通过四级压缩机制在运行时动态决定信息的详细程度——不常用的信息被高度压缩，关键信息保留完整。这是最工程化的方案，也是成本和质量之间最务实的平衡。

Hermes 采用“认知分层”的高密度策略。Memory 和 Skill 的分离本身就是一种认知压缩——Memory 存声明式事实（知道什么），Skill 存过程性知识（会做什么）。严格的字符上限迫使模型只保留最高密度的信息。它就像一个精于整理的知识工作者，知道什么东西该记在哪里、该记多细。

5.3 适用场景对比

5.4 三种架构的可组合性

值得强调的是，这三种架构不是互斥的。实际生产系统完全可以按需组合使用：

• OpenClaw 的文件层 + Claude Code 的压缩机制：用 Markdown 存储原始数据，但在上下文注入前执行分级压缩。数据透明，成本可控。
• Hermes 的 Skill 系统 + OpenClaw 的工具生态：让 OpenClaw 的技能也能自我进化。如果 OpenClaw 能学会自己写 Skill，那就太强了。
• Claude Code 的 Dream 整合 + memory-agentcore 的云端共享：编程 Agent 的经验可以被团队其他 Agent 复用。一个人踩过的坑，全团队受益。

在工程实践中，很少有“一个方案打天下”的情况。理解每种架构的优缺点，才能做出最适合自己场景的选择。

六、总结与展望

OpenClaw、Claude Code 和 Hermes Agent 分别代表了 Agent 记忆系统演进的三代思路：

• 第一代（OpenClaw）：文件即记忆。简单、透明、可控，但缺少智能化的信息管理。适合对透明度和可控性有高要求的场景。
• 第二代（Claude Code）：工程化压缩。通过多级压缩在有限上下文中塞入更多信息，但 Agent 本身不学习。适合对成本和效率有极致追求的场景。
• 第三代（Hermes）：自主进化。Agent 不仅使用记忆，还能从经验中提炼技能，实现能力增长。适合需要 Agent 长期陪伴并越来越强的场景。

未来的 Agent 记忆系统可能会向三个方向演进：

1. 混合架构：在文件系统基础上构建轻量级索引层，兼顾透明度和检索效率。不需要在“全存”和“全压缩”之间二选一。
2. 联邦记忆网络：实现跨实例的记忆共享与协作，形成“集体智能”。单个 Agent 的“痛苦经历”可以变成整个 Agent 集群的“宝贵经验”。
3. 量子化记忆压缩：将记忆存储需求降低 70% 以上，让长时间跨度的记忆成为可能。也许未来的 Agent 能记住你三年前提到的某个需求细节。

正如 HN 上一个高赞评论所说：“Data Is the Final Moat”——当模型智能被商品化、Agent 框架被开源，真正的护城河是 Agent 在工作中积累的领域知识。记忆系统的设计，将直接决定这条护城河的深度和宽度。选择哪种架构，其实就是选择你要挖多深的护城河。