前言：为什么你需要关心Agent的记忆？

你有没有遇到过这样的情况：跟AI助手聊了很久，它帮你梳理了一个复杂问题的解决思路，你满心欢喜地按照计划执行，中途问了它一个相关问题，结果它像是失忆了一样，完全忘了之前讨论的上下文？

或者更糟——你反复告诉它你的偏好（“我喜欢简洁的回答，不要废话”），但它每次对话都像是第一次认识你，依然滔滔不绝地输出长篇大论。

这不是AI变笨了，而是触及了一个根本性的工程约束：语言模型本身没有状态。

每次你发送消息，模型都是从零开始处理。它不记得任何历史，除非我们主动告诉它。这个看似简单的约束，实际上是所有AI Agent系统设计的起点，也是区分优秀架构与平庸实现的分水岭。

今天，我想带你深入三个主流框架——OpenClaw、Claude Code和Hermes Agent——的记忆系统设计。它们代表了三种截然不同的哲学思考。读完这篇文章，你不仅会理解“怎么实现记忆”，更会明白“为什么这样设计记忆”。

---

第一部分：记忆系统的四个架构问题

在拆解具体框架之前，我们先建立一个分析框架。任何一个Agent的记忆系统，都必须回答四个根本问题：

1. 存什么？

不是所有信息都值得保留。用户的随口一句“今天天气不错”和“我的API密钥是xxx”，显然有不同的记忆价值。但如何让Agent自动判断？如何避免记忆系统退化成垃圾堆？

2. 存在哪？

用什么介质？文件系统、SQLite、向量数据库，还是专用的记忆服务？每种介质都有自己的访问模式、持久化保证和性能特征。选错了，后期重构成本极高。

3. 怎么取？

需要的时候如何找到相关记忆？精确匹配（关键词搜索）适合查找已知实体，语义搜索适合模糊匹配，但两者各有优劣。更复杂的是：什么时候触发检索？是每次对话都检索，还是Agent自己判断需要时才检索？

4. 怎么管？

记忆会过时、会冲突、会积累成噪音。如何衰减、更新、压缩？谁来执行这些管理操作——系统自动还是人工介入？

学术界通常将Agent记忆分为四个层次：

• 上下文记忆：当前窗口内的内容，访问快但容量小

• 外部记忆：持久化存储，跨会话存活但需要检索

• 情景记忆：结构化的历史行为记录，是学习的基础

• 参数记忆：模型权重中的知识，无法运行时更新

真正有趣的架构差异，集中在外部记忆和情景记忆的设计上。下面我们来看三个框架给出的不同答案。

---

第二部分：OpenClaw——文件系统即真理

设计哲学：可见性压倒一切

OpenClaw的记忆架构建立在一个极简的约束上：没有写进文件的，不存在。

这不是一句口号，而是一个强制的架构约束。Agent的所有长期状态，必须持久化到磁盘上的Markdown文件里。文件本身既是存储介质，也是人机协作的接口。

text

~/.openclaw/workspace/
├── MEMORY.md              ← 长期记忆（精华提炼）
├── SOUL.md                ← Agent身份定义
└── memory/
    ├── 2026-04-12.md      ← 当日日志（短期）
    ├── 2026-04-11.md      ← 昨日日志
    └── ...

为什么选文件而不是数据库？

这是一个刻意的、有代价的设计取舍。文件有三个数据库不具备的特性：

1. 人类可读：用任何文本编辑器都能打开查看

2. 人类可编辑：发现错误可以直接修改

3. 可版本控制：用Git追踪变化历史

想象一下调试场景：Agent行为异常，你怀疑是记忆污染了。如果是黑盒数据库，你只能猜测。但在OpenClaw里，你可以直接打开MEMORY.md，看到Agent到底“记住”了什么，甚至可以直接修正错误记忆，然后用Git diff看是什么时候引入的。

这种透明性在建立信任和调试复杂行为上，价值巨大。

代价也很明显：文件系统的查询能力远不如数据库。复杂的关系查询、快速的精确匹配，都是文件的弱项。OpenClaw用混合搜索（语义+BM25）部分缓解了这个问题，但架构层面的取舍是清晰的。

两层记忆：短期与长期的分离

OpenClaw把外部记忆分成两层，对应不同的信息生命周期：

短期层（memory/YYYY-MM-DD.md）：当天的工作日志，追加写入，不做整理，捕获所有可能有用的上下文。今天和昨天的日志自动注入上下文，更早的通过检索访问。

长期层（MEMORY.md）：精华提炼，从日志中沉淀出来的稳定事实、用户偏好、工作规范。每次会话都加载，始终在场。

这个两层设计解决了一个根本矛盾：你想要Agent记住很多东西，但上下文窗口放不下很多东西。

短期层解决“不丢失”，长期层解决“高效访问”。代价是需要一个主动的提炼过程——谁来决定什么东西从日志升级到MEMORY.md？

OpenClaw的答案是：主要靠人，辅以实验性的自动化。这意味着记忆质量依赖用户的主动维护。这对技术人员来说可能不是问题，但对普通用户而言，维护成本太高了。

Memory Flush：防止压缩丢失记忆

OpenClaw记忆系统最精妙的设计，不是存储，而是压缩时的保护机制。

长会话会撑爆Token窗口。当历史对话积累到接近上限，系统必须压缩——把旧的对话历史替换成摘要，腾出空间。

压缩本身是正确的，但会引入一个隐患：只存在于对话历史里的约定，会在压缩中消失。

这产生了一个经典的bug模式：用户在对话里告诉Agent某个重要规则（比如“所有代码注释必须用英文”），Agent回复“好的”，但没有写进文件。几轮对话后触发压缩，这个约定消失。用户以为Agent记住了，但Agent之后的行为违反了这个规则。

OpenClaw的解法是Memory Flush：在压缩触发前，系统先发起一个静默的Agent轮次——提示模型把当前上下文里所有重要信息写进磁盘文件，然后再压缩。

text

检测到即将Compaction
    ↓
触发静默Memory Flush
    ↓
Agent把重要信息写入 memory/YYYY-MM-DD.md
    ↓
执行Compaction（压缩历史对话）
    ↓
继续会话

这个设计很聪明：把“写进文件才算记住”这个原则，从人工操作变成了系统级的自动保障。压缩只碰对话历史，文件里的内容不受影响。

Dreaming：向自动情景记忆的探索

OpenClaw的新版本加入了Dreaming机制——一个定期运行的后台任务，扫描日志文件，对内容打分，把达到阈值的内容提升到MEMORY.md。

这是向自动化情景记忆迈出的一步：让系统而不是人来做记忆的沉淀工作。但目前仍是实验性的，默认关闭。

背后的挑战很本质：什么信息“值得”长期保留？很难用规则描述。信息价值依赖上下文——在某个项目里“API地址是localhost:3000”是核心事实，在另一个项目里可能是无关噪音。让算法自动判断，目前还没有可靠的方案。

OpenClaw的适用场景

OpenClaw的设计最适合重视控制感和透明度的场景——你想知道Agent记住了什么，你想能随时纠正它的记忆。

典型用户是开发者和技术运维，他们愿意花时间维护记忆质量，换取系统的可预测性和可调试性。

代价是：如果你不主动维护，MEMORY.md会过时，记忆会退化。

---

第三部分：Claude Code——上下文工程优先

设计哲学：Token是稀缺资源

Claude Code的记忆架构建立在一个更激进的工程判断上：

上下文窗口的容量不等于可用容量。模型对不同位置的信息，注意力分布是不均匀的。

研究表明，语言模型对上下文头部和尾部的注意力最强，中间最弱——这就是著名的“Lost in the Middle”现象。这意味着，即使你把记忆堆进上下文，模型也可能忽略中间的部分。

Claude Code的记忆架构，本质上不是“存储系统”，而是一套Token预算分配和信息注入机制。

分层系统提示：Prefix Cache的妙用

从泄露的源码可以看到，Claude Code在每次调用模型之前，会精细地组装系统提示。这个过程不是简单拼接，而是有条件的分层注入：

固定注入层（每次都有，走Prefix Cache）：

• Agent身份定义和基本行为规范

• 编码哲学：最小化修改、不过度工程化

• 工具使用规范和风险操作确认逻辑

条件注入层（按需加载，不浪费Token）：

• CLAUDE.md文件内容（按作用域层级加载）

• Git状态快照（当前分支、最近提交、工作区变更）

• Skills名称和描述列表（只有索引，不是完整内容）

• Token预算指令（当用户设定了消耗目标时）

固定层走Prefix Cache，只需付一次费用；条件层按需注入，不浪费Token。这个分层是Claude Code上下文优化的基础设计。

用文件路径编码相关性

Claude Code用作用域层级解决“哪些规则对当前任务有用”的问题：

text

~/.claude/CLAUDE.md          ← 用户级：所有项目都加载
~/project/CLAUDE.md          ← 项目级：进入项目加载
~/project/src/CLAUDE.md      ← 目录级：进入该目录加载

这里有一个深刻的洞察：不需要写检索算法。当前工作目录在哪，文件系统路径本身就决定了加载哪些规则。相关性被编码进了目录结构，用O(1)的路径查找替代了语义检索。

代价是只能做静态的“这个目录用什么规则”，不能做动态的“这个任务需要什么知识”。如果你的任务需要跨目录的知识，或者需要根据任务内容动态判断相关性，这个方案就不够用了。

Token预算预警：让Agent感知自身状态

Claude Code对Token消耗有明确的三档预警：

text

70% 阈值 → 第一次提示：压缩可能即将发生
85% 阈值 → 第二次提示：压缩即将触发
90% 阈值 → 执行自动压缩（或停止并提示）

更重要的设计：Token使用量会注入Agent自身的上下文，让Agent能在规划任务时感知剩余预算：

“我还有足够的Token分析三个文件，然后就会触发压缩。”

Agent可以据此主动决策——优先处理哪些文件、在压缩前完成哪些关键步骤。记忆系统的状态成为Agent推理的输入，而不只是被动的存储后端。

这是一个很值得借鉴的设计思路。大多数Agent把记忆当作“存和取”的问题，Claude Code把它变成了“调度和管理”的问题。

Claude Code的适用场景

Claude Code的设计最适合边界清晰的工程任务——规则是稳定的，任务是相对独立的，不需要从历史经验里学习。

典型场景是代码生成、重构、调试。每次任务的目标明确，上下文相对独立，不需要跨会话的长期记忆。

Claude Code的架构在效率和成本上是最优的，但它没有情景记忆。每次任务都是全新开始，不会从之前的成功或失败中学习。对于重复性高的任务，这意味着你每次都要重新教它。

---

第四部分：Hermes Agent——四层分离，情景记忆是核心

设计哲学：不同访问模式，不同存储介质

Hermes的记忆架构是三者中最系统化的。它的核心设计思路是：

不同访问模式的记忆，必须在不同的存储介质里，用不同的方式管理。把所有东西混在一起是大多数Agent记忆系统变得不可靠的根本原因。

Hermes把记忆严格分成四层，每层都有自己的访问模式、容量限制和管理策略。

第一层：热记忆（始终注入，永远在场）

text

~/.hermes/memories/
├── MEMORY.md    ← 环境事实，上限 ~800 token
└── USER.md      ← 用户偏好，上限 ~500 token

这两个文件在每次会话开始时直接注入系统提示，不需要检索，零延迟访问。

为什么把上限设得这么小？

这是一个反直觉但正确的设计决策。上限小，强制你做信息的质量控制。每次想写进去一条新记忆，你必须问：这条信息值得占用宝贵的系统提示空间吗？它比已有的哪条更重要？

如果上限很大，记忆会自然地退化成一个垃圾桶，什么都往里堆，检索质量随着积累不断下降。

同时，小的系统提示对Prefix Cache友好——固定的前缀意味着更高的缓存命中率，降低推理成本。

第二层：历史归档（按需检索）

text

~/.hermes/state.db    ← SQLite，FTS5全文索引

所有会话历史都存进这个数据库。当Agent判断当前任务可能和历史相关，它主动调用session_search工具搜索数据库，召回相关历史，经过轻量LLM摘要压缩后注入当前上下文。

这里有一个重要的架构决策：历史归档不是自动注入的，是Agent主动决策检索的。

为什么这样设计？如果每次会话都自动加载历史，系统提示会随着使用时间增长而不断膨胀。按需检索让系统提示保持稳定，历史记忆只在真正需要的时候才进来。

FTS5全文搜索的局限是语义理解弱——搜“auth service”不一定能找到记录里写的“身份验证微服务”。这是当前架构的一个已知权衡点，Hermes社区有一些用向量搜索替代或增强FTS5的扩展方案。

第三层：情景记忆（Skills，Hermes的核心差异）

这是Hermes和OpenClaw、Claude Code最根本的架构差异。

情景记忆存储的不是事实，而是经验——做过什么、怎么做的、效果如何。

Hermes的实现是Skills系统：

text

~/.hermes/skills/
├── research-workflow.md     ← 某类任务的最优执行路径
├── image-generation.md      ← 图片生成任务的经验积累
└── data-analysis.md         ← 数据分析任务的方法论

每当Agent完成一个复杂任务（通常是五次以上工具调用），系统评估这次执行过程是否值得保留为Skill。如果值得，Agent自动把执行步骤、使用的工具、遇到的问题、解决方法，结构化写入一份Markdown文件。

Skills的加载方式用了渐进式披露：

text

Level 0：只加载Skill名称和描述（极少Token）
    ↓（如果相关）
Level 1：加载完整Skill内容

平时只知道“有哪些Skill可用”，当判断当前任务和某个Skill相关，才加载完整内容。这让你可以积累几十上百个Skill而不撑爆上下文。

更重要的是：Skill会在使用中自我更新。

Agent用一个已有的Skill执行任务，发现某个步骤有更好的做法，会自动修改Skill文档。经验在积累，方法在迭代。这是真正意义上的情景记忆——不只记住发生了什么，还知道下次怎么做更好。

这个设计回答了情景记忆最核心的问题：如何让Agent从自己的执行历史里学习，而不只是从人类事先定义的规则里执行？

第四层：深度用户建模（可选）

通过接入Honcho，Hermes可以建立对用户的结构化模型——不只是记录“用户说了什么”，而是建立“用户怎么思考、倾向于什么决策风格”的持久模型。

这层是可选的，使用了一种叫“对话式用户建模”的方法：通过分析用户的历史表达，推断用户的偏好和价值观，在未来的交互中主动适应。

这是最接近“真正了解用户”的记忆层，但也是最重的——需要额外服务，有隐私考量，适合有特定需求的场景。

Hermes的适用场景

Hermes的设计最适合长期运行、重复性高的场景——任务类型相对固定，时间越长Agent越熟悉你的工作方式。

典型场景是个人助理、项目管理、持续集成。这些场景下，Agent的执行经验可以不断积累，形成越来越高效的工作流。

代价是系统更复杂，需要时间积累才能看到效果。刚开始使用时，Skills系统是空的，Agent不会比简单的Agent表现更好。只有经过一段时间的“磨合”，价值才会体现。

---

第五部分：三种架构哲学的本质差异

把三个框架放在一起，可以看出三种根本不同的设计哲学：

维度	OpenClaw	Claude Code	Hermes Agent
设计核心	可见性和可控性	信息的精准调度	分层积累与学习
记忆载体	Markdown文件	系统提示分层	四层分离存储
检索方式	混合搜索（语义+BM25）	路径编码+条件注入	Agent主动决策按需检索
情景记忆	实验性（Dreaming）	无	核心（Skills自我更新）
依赖人工维护	高	低	中（初期需积累）
成本效率	中	高	中低（随时间改善）
透明度	高（文件直接可读）	中（需要理解注入逻辑）	中（Skills可查看）

OpenClaw的哲学：信任但验证

OpenClaw的设计师相信：用户应该能够看到和修改Agent记住的一切。文件系统不是技术限制，而是一种设计选择——用透明性换取信任，用可编辑性换取可控性。

这个哲学适合技术人员，适合对系统行为有严格要求的场景。但代价是：记忆质量依赖用户维护，自动化程度低。

Claude Code的哲学：效率即正义

Claude Code的设计师相信：Token是硬约束，所有设计必须围绕预算管理。不追求存储更多，而是追求在正确时机注入正确信息。文件系统的层级结构本身就是相关性的编码。

这个哲学适合边界清晰、任务独立的工程场景。代价是没有学习能力，每次任务都是全新开始。

Hermes的哲学：积累产生智能

Hermes的设计师相信：真正的智能来自经验积累。四层分离确保不同访问模式的信息不互相干扰，情景记忆让Agent从自身执行历史中学习并自我优化。

这个哲学适合长期运行、重复性高的场景。代价是系统复杂，需要时间才能体现价值。

---

第六部分：如何选择？——一个决策框架

没有最好的架构，只有最匹配你场景的取舍。我建议你从三个问题出发做决策：

问题1：你的Agent是短期任务还是长期运行？

如果是一次性任务或短期项目，Claude Code的上下文工程方案最合适——效率高、成本低、不需要跨会话记忆。

如果是长期运行的助手（比如个人助理、持续集成机器人），Hermes的学习能力会随时间体现价值。

如果是介于两者之间（比如开发工具，项目周期几个月），OpenClaw的透明性和可控性可能是平衡的选择。

问题2：用户是技术人员还是普通用户？

如果是技术人员，OpenClaw的文件系统透明性很有价值——他们愿意也懂得如何维护记忆。

如果是普通用户，Hermes的自动化学习更友好——用户不需要手动维护记忆，Agent会自己从经验中学习。

Claude Code介于两者之间——配置简单（只需要写CLAUDE.md），但高级优化需要理解上下文工程。

问题3：任务是否高度重复？

如果是高度重复的任务（比如每天做数据分析报告、每周生成项目总结），Hermes的Skills系统会越用越顺手。

如果是多样化、每次不同的任务，情景记忆的价值有限，OpenClaw或Claude Code可能更合适。

混合策略：现实项目的选择

在实际项目中，你可能需要混合策略。一个常见的模式是：

• 用OpenClaw的文件透明性做调试和审计

• 用Claude Code的上下文分层做效率优化

• 用Hermes的情景记忆做长期学习

这不是“选一个”的问题，而是理解每种设计的核心思想，在自己的系统里组合使用。

---

结语：记忆只是开始

记忆系统只是Agent架构的一个维度。在后续的文章中，我们会深入讨论：

• 规划系统：Agent如何分解任务、处理依赖、应对变化

• 工具使用：如何设计可扩展的工具接口，如何让Agent安全地执行操作

• 多Agent协作：多个Agent如何共享记忆、协调行动

但理解记忆系统是很好的起点——因为它触及了AI Agent最本质的矛盾：无状态的模型，需要有状态的系统。

没有一个架构能解决所有问题。每个设计选择都是取舍，都反映了设计师对“什么更重要”的判断。希望这篇文章能帮你建立自己的判断框架，在设计你的Agent时，做出有意识的选择，而不是无意识的复制。

---

思考题

读完这篇文章，我想留给你三个问题：

1. 你的使用场景中，最看重什么？ 透明性、效率，还是学习能力？

2. 你愿意花多少精力维护Agent的记忆？ 是希望全自动，还是愿意定期检查和修正？

3. 如果你的Agent犯了错，你希望怎么定位问题？ 是打开文件看记忆内容，还是分析上下文注入日志？

欢迎在评论区分享你的想法。如果你对某个框架的实现细节感兴趣，也可以告诉我，我会在后续的文章中深入展开。

---

本文是“AI Agent架构设计”系列的第一篇。后续文章会深入规划系统、工具使用和多Agent协作，欢迎关注。