系列AI Agent 架构设计一记忆系统设计目标从架构层面理解三个主流框架的记忆系统设计决策以及背后的工程取舍适合对 Agent 底层设计感兴趣想真正理解为什么这样设计的读者预计阅读15 分钟为什么记忆系统是 Agent 架构的核心问题设计一个 AI Agent第一个绕不过去的问题不是用什么模型而是语言模型本身没有状态。每次调用都从零开始它不记得任何事情。这个根本约束决定了所有 Agent 框架都必须在模型外面搭一套记忆系统。这套系统要回答四个架构问题存什么——哪些信息值得保留哪些该丢弃存在哪——用什么介质什么格式什么生命周期怎么取——需要的时候怎么找到精确匹配还是语义搜索怎么管——记忆怎么衰减、更新、压缩防止积累成噪音OpenClaw、Claude Code、Hermes Agent 对这四个问题给出了三种不同的答案。把它们放在一起看能看清楚记忆系统设计的核心取舍。理论框架记忆的四个层次在拆解三个框架之前先建立一个分析框架。研究界把 Agent 记忆分成四种类型对应不同的存储机制和访问方式23 | AI Agent 记忆系统四层架构拆解一只不会忘记的龙虾上下文记忆In-context当前 Token 窗口里的所有内容。访问成本最低但容量有限会话结束即消失。外部记忆External持久化在模型外部的存储——文件、数据库、向量库。跨会话存活但每次访问需要检索步骤。情景记忆Episodic过去行为的结构化记录。不只是存事实而是存做过什么、怎么做的、结果如何。是 Agent 从自身经验学习的基础。参数记忆Parametric模型训练权重里编码的知识。始终存在不需要检索但运行时无法更新也存在幻觉风险。真正有趣的架构问题是外部记忆和情景记忆怎么设计——这是三个框架差异最大的地方。OpenClaw文件系统即记忆核心设计决策文件是唯一真理OpenClaw 的记忆架构建立在一个极简原则上没有写进文件的不存在。这不是一句口号而是一个架构约束。Agent 的所有长期状态必须持久化到磁盘上的 Markdown 文件里。文件本身就是记忆的存储介质也是人机协作的接口。~/.openclaw/workspace/├── MEMORY.md ← 长期记忆精华├── SOUL.md ← Agent 身份定义└── memory/├── 2026-04-12.md ← 当日日志短期├── 2026-04-11.md ← 昨日日志└── ...为什么选择文件而不是数据库这是一个刻意的设计取舍。文件有三个数据库没有的特性人类可读、可编辑、可版本控制。你可以用任何文本编辑器打开 MEMORY.md看到 Agent 记住了什么直接修改错误的记忆用 Git 追踪变化历史。这种透明性在调试和信任建立上有很大价值。代价是文件系统的查询能力远不如数据库。复杂的关系型查询、快速的精确匹配都是文件的弱项。两层记忆结构短期与长期的分离OpenClaw 把外部记忆分成两层对应两种不同的信息生命周期短期层memory/YYYY-MM-DD.md当天的工作日志。追加写入不做整理捕获所有可能有用的上下文。今天和昨天的日志自动注入上下文更早的通过检索访问。长期层MEMORY.md精华提炼。从日志中沉淀出来的稳定事实、用户偏好、工作规范。每次会话都加载始终在场。这个两层设计解决了一个根本矛盾你想要 Agent 记住很多东西但上下文窗口放不下很多东西。短期层解决不丢失长期层解决高效访问。代价是需要一个主动的提炼过程——谁来决定什么东西从日志升级到 MEMORY.mdOpenClaw 的答案是主要靠人辅以实验性的自动化Dreaming 机制。这意味着记忆质量依赖用户的主动维护。检索设计混合搜索单纯的语义搜索向量相似度有一个问题它找的是意思相近但有时候你需要精确匹配。比如搜索一个具体的 API 端点名称语义搜索可能返回一堆相关但不准确的结果。OpenClaw 用混合搜索解决这个问题语义搜索 BM25 关键词搜索并行运行结果合并取最相关片段。两种搜索互补语义搜索处理措辞不同但含义相近的情况BM25 处理精确词匹配的情况。实现上向量索引存在 SQLite通过 sqlite-vec 扩展而不是独立的向量数据库。这个选择降低了部署复杂度代价是大规模下性能不如专用向量库。最危险的环节Context CompactionOpenClaw 的记忆系统最复杂的部分不是存储而是压缩。长会话会撑爆 Token 窗口。当历史对话积累到接近上限系统必须压缩——把旧的对话历史替换成摘要腾出空间。压缩本身是正确的操作但会引入一个隐患只存在于对话历史里的约定会在压缩中消失。这产生了一个有名的 bug 模式用户在对话里告诉 Agent 某个重要规则Agent 说好的但没有写进文件。几轮对话后触发 Compaction这个约定消失Agent 之后的行为违反了用户以为已经被记住的规则。OpenClaw 的解法是Memory Flush在 Compaction 触发前系统先发起一个静默的 Agent 轮次——提示模型把当前上下文里所有重要信息写进磁盘文件然后再压缩。这个设计很聪明把写进文件才算记住这个原则从人工操作变成了系统级的自动保障。检测到即将 Compaction↓触发静默 Memory Flush↓Agent 把重要信息写入 memory/YYYY-MM-DD.md↓执行 Compaction压缩历史对话↓继续会话文件里的内容压缩不会碰。只有对话历史会被压缩。Dreaming情景记忆的实验性尝试OpenClaw 新版本加入了 Dreaming 机制——一个定期运行的后台任务扫描日志文件对内容打分把达到阈值的内容提升到 MEMORY.md。这是向自动化情景记忆迈出的一步让系统而不是人来做记忆的沉淀工作。但目前仍是实验性的默认关闭。背后的挑战是什么信息值得长期保留很难用规则描述需要上下文判断。Claude Code上下文工程优先核心设计决策Token 预算是稀缺资源必须主动管理Claude Code 的记忆架构建立在一个明确的工程判断上上下文窗口的容量不等于可用容量模型对不同位置的信息注意力分布是不均匀的。研究表明语言模型对上下文头部和尾部注意力最强中间最弱——这就是Lost in the Middle现象。这意味着把记忆直接堆进上下文不够还需要主动管理哪些信息放在哪里、放多少。Claude Code 的记忆架构不是一个存储系统而是一套Token 预算分配和信息注入机制。系统提示的精确构建分层注入从泄露的源码可以看到Claude Code 在每次调用模型之前会精细地组装系统提示。这个过程不是简单拼接而是有条件的分层注入固定注入层每次都有走 Prefix CacheAgent 身份定义和基本行为规范编码哲学最小化修改、不过度工程化、只做被要求的事工具使用规范和风险操作确认逻辑条件注入层按需加载不浪费 TokenCLAUDE.md文件内容按作用域层级加载Git 状态快照当前分支、最近提交、工作区变更Skills 名称和描述列表只有索引不是完整内容Token 预算指令当用户设定了消耗目标时固定层走 Prefix Cache只需付一次费用条件层按需注入不浪费 Token。这个分层是 Claude Code 上下文优化的基础设计。分层文件体系用路径编码相关性Claude Code 用作用域层级解决哪些规则对当前任务有用的问题~/.claude/CLAUDE.md ← 用户级所有项目都加载~/project/CLAUDE.md ← 项目级进入项目加载~/project/src/CLAUDE.md ← 目录级进入该目录加载不需要写检索算法——当前工作目录在哪文件系统路径本身就决定加载哪些规则。相关性被编码进了目录结构用 O(1) 的路径查找替代了语义检索。代价是只能做静态的这个目录用什么规则不能做动态的这个任务需要什么知识。Token 预算的三档预警让 Agent 感知自身状态Claude Code 对 Token 消耗有明确的三档预警​​​​​​​70% 阈值 → 第一次提示压缩可能即将发生85% 阈值 → 第二次提示压缩即将触发90% 阈值 → 执行自动压缩或停止并提示更重要的设计Token 使用量会注入 Agent 自身的上下文让 Agent 能在规划任务时感知剩余预算我还有足够的 Token 分析三个文件然后就会触发压缩。Agent 可以据此主动决策——优先处理哪些文件、在压缩前完成哪些关键步骤。记忆系统的状态成为 Agent 推理的输入而不只是被动的存储后端。这是上下文工程里一个很值得借鉴的设计思路。Hermes Agent四层分离情景记忆是核心核心设计决策把记忆按访问模式分层Hermes 的记忆架构是三者中最系统化的。它的核心设计思路是不同访问模式的记忆必须在不同的存储介质里用不同的方式管理。把所有东西混在一起是大多数 Agent 记忆系统变得不可靠的根本原因。Hermes 把记忆严格分成四层第一层热记忆始终注入永远在场​​​​​​​~/.hermes/memories/├── MEMORY.md ← 环境事实上限 ~800 token└── USER.md ← 用户偏好上限 ~500 token这两个文件在每次会话开始时直接注入系统提示不需要检索零延迟访问。为什么把上限设得这么小这是一个反直觉但正确的设计决策。上限小强制你做信息的质量控制。每次想写进去一条新记忆你必须问这条信息值得占用宝贵的系统提示空间吗它比已有的哪条更重要如果上限很大记忆会自然地退化成一个什么都往里堆的垃圾桶检索质量随着积累不断下降。同时小的系统提示对 Prefix Cache 友好——固定的前缀意味着更高的缓存命中率降低推理成本。第二层历史归档按需检索~/.hermes/state.db ← SQLiteFTS5 全文索引所有会话历史都存进这个数据库。当 Agent 判断当前任务可能和历史相关它主动调用session_search工具搜索数据库召回相关历史经过轻量 LLM 摘要压缩后注入当前上下文。这里有一个重要的架构决策历史归档不是自动注入的是 Agent 主动决策检索的。这是架构决定访问方式而不是 Agent 的判断原则的体现。为什么这样设计如果每次会话都自动加载历史系统提示会随着使用时间增长而不断膨胀。按需检索让系统提示保持稳定历史记忆只在真正需要的时候才进来。FTS5 全文搜索的局限是语义理解弱——搜auth service不一定能找到记录里写的身份验证微服务。这是当前架构的一个已知权衡点Hermes 社区有一些用向量搜索替代或增强 FTS5 的扩展方案。第三层情景记忆SkillsHermes 的核心差异这是 Hermes 和 OpenClaw、Claude Code 最根本的架构差异。情景记忆存储的不是事实而是经验——做过什么、怎么做的、效果如何。Hermes 的实现是 Skills 系统​​​​​​​~/.hermes/skills/├── research-workflow.md ← 某类任务的最优执行路径├── image-generation.md ← 图片生成任务的经验积累└──>把三个框架放在一起可以看出三种根本不同的设计哲学OpenClaw文件系统作为真理来源设计核心是可见性和可控性。所有记忆都在磁盘上人类可以直接读写系统行为透明可预期。代价是需要用户主动维护记忆质量记忆的准确性依赖人的持续投入。这个架构适合重视控制感和透明度的场景——你想知道 Agent 记住了什么你想能随时纠正它的记忆。Claude Code上下文工程优先设计核心是信息的精准调度。不追求存储更多而是追求在正确时机注入正确信息。文件系统的层级结构本身就是相关性的编码。代价是没有情景记忆每次任务都是全新开始。这个架构适合边界清晰的工程任务——规则是稳定的任务是相对独立的不需要从历史经验里学习。Hermes分层积累情景记忆是核心设计核心是随时间积累能力。四层分离确保不同访问模式的信息不互相干扰情景记忆让 Agent 从自身经验中学习。代价是系统更复杂需要时间积累才能看到效果。这个架构适合长期运行、重复性高的场景——任务类型相对固定时间越长 Agent 越熟悉你的工作方式。