最近一段时间，OpenClaw有多火，已经不必多说。

Andrej Karpathy将其形容为科学与科幻临界点，马斯克将其视为奇点来临的前兆。

相比其他AI应用，它不仅能自主的执行任务，更是能够调用电脑上的各种访问权限，并牢记历史会话的信息，知道你的个人偏好。

那么这套全量记忆系统是如何打造的？为什么说它是agent记忆打造的标准模板？

不久前，一位科技博主Manthan Gupta对其进行了逆向，以下是逆向结果的完整解读。

01 

上下文和记忆，不是一回事

要理解OpenClaw的记忆，首先得分清两个容易混淆的概念：上下文和记忆。

先说说上下文，它就是每次你给OpenClaw发请求时，它能接收到的所有信息。它的特点在于，临时（只在当次对话中有效）、有上限（首先模型窗口）、还费钱。

Context = System Prompt + Conversation History + Tool Results + Attachments

具体来说，上下文主要包括四部分：静态+条件化的系统提示词、AGENTS.md和SOUL.md这类引导文件的项目上下文、过往的对话历史（包括消息、工具调用记录和压缩摘要），还有你当下发的消息。

其中，AGENTS.md存着智能体的指令和记忆使用规则，SOUL.md定义了它的性格和说话语气，USER.md专门记你的相关信息，TOOLS.md则是外部工具的使用指南。这些文件都和记忆文件存在一起，配置透明可见，想可以随时更改。

再来看看记忆，它是存在你本地磁盘里的持久化数据，是MEMORY.md文件、memory文件夹里所有的md文件，再加上会话转录文件的总和。

Memory = MEMORY.md + memory/*.md + Session Transcripts

它的优势刚好和上下文互补：

• 持久化，不管你重启设备、隔十天半个月，记忆都不会丢；

• 无上限，只要你设备存储空间足够，就能无限扩容；

• 低成本，本地存储不用花一分钱API费用；

• 还能快速检索，系统会给记忆建立索引，想找之前的内容，很快就能定位到。

02 

OpenClaw如何打造agent记忆？

OpenClaw靠两个专用工具来访问记忆库，一个是memory_search负责找，一个是memory_get负责读。

先看第一个工具memory_search。顾名思义，就是用来检索记忆的。不管你想找过往的工作决策、具体日期、相关人物，还是自己的偏好、待办事项，在回答之前，它都会先在MEMORY.md和memory文件夹的所有md文件里，做一次语义检索。

这个工具的调用参数示例如下：

{  "name": "memory_search",  "description": "必选的记忆调取步骤：回答关于过往工作、决策、日期、人物、偏好或待办事项的问题前，先对MEMORY.md和memory/*.md文件进行语义检索",  "parameters": {    "query": "我们关于API的决策是什么？",    "maxResults": 6,    "minScore": 0.35  }}

比如你问 “我们之前关于 API 的决策是什么”，它就会按照设定的参数，最多返回 6 条相关结果，并且过滤掉匹配度低于 0.35 的内容，返回结果示例如下：

{  "results": [    {      "path": "memory/2026-01-20.md",      "startLine": 45,      "endLine": 52,      "score": 0.87,      "snippet": "## API讨论\n为追求简洁性，决定采用REST而非GraphQL...",      "source": "memory"    }  ],  "provider": "openai",  "model": "text-embedding-3-small"}

第二个工具是memory_get，它在memory_search之后用。当你通过检索找到相关内容的文件路径后，用这个工具就能精准读取文件里的指定内容，比如你想读某个记忆文件第45行开始的15行内容，输入参数就能直接获取，不用自己去翻整个文件。

示例如下：

{  "name": "memory_get",  "description": "执行memory_search后，读取记忆文件的指定内容行",  "parameters": {    "path": "memory/2026-01-20.md",    "from": 45,    "lines": 15  }}

返回：

{  "path": "memory/2026-01-20.md",  "text": "## API讨论\n\n团队讨论了API架构设计方案。\n\n### 最终决策\n基于以下原因，选择REST而非GraphQL：\n1. 实现难度更低\n2. 缓存效果更优\n3. 团队对其更熟悉\n\n### 接口列表\n- GET /users\n- POST /auth/login\n- GET /projects/:id"}

可能看到这里，大家会有一个疑问，有了读也有了找，那写怎么处理？

没有设计专属的 memory_write 工具，而是直接用智能体自带的、用于文件操作的标准write和edit工具完成记忆写入，这种设计让整个系统更轻量化，也让用户的手动操作更便捷。

所有记忆都是以 Markdown 格式存储在本地文件中，除了智能体自动写入，你也可以直接手动编辑这些 md 文件，而且只要文件修改并保存，系统会自动对新内容重新建立索引，确保后续能被正常检索，不用额外执行操作。

agent的写入行为由 AGENTS.md 中的提示词规则驱动，不同的记忆内容会被写入不同的文件，形成了清晰的写入规则，不同触发场景对应不同的写入文件：

• 日常笔记、临时需要记录的内容，会写入memory/YYYY-MM-DD.md按日归档；

• 长期有效的事实、个人偏好、关键决策，会写入MEMORY.md作为核心知识库；

• 经验总结、工具的实操技巧，会写入AGENTS.md或TOOLS.md，让记忆和智能体的能力配置结合更紧密。

除此之外，系统还会在两个关键节点自动执行记忆写入：一是对话历史压缩前的记忆刷写阶段，二是会话正式结束时，这两个节点的自动写入，能有效避免关键信息因对话结束或压缩而丢失（这里我们在后续详细展开）。

03 

记忆怎么存？本地双层存储

OpenClaw记忆系统中，所有记忆都存在本地智能体的工作目录里，默认路径是~/clawd/，整个架构分为两层：第一层是日常日志，第二层是长期记忆。

整个架构的目录如下

~/clawd/├── MEMORY.md              - 第二层：经整理的长期知识库└── memory/    ├── 2026-01-26.md      - 第一层：今日笔记    ├── 2026-01-25.md      - 第一层：昨日笔记    ├── 2026-01-24.md      - 第一层：往期笔记    └── ...

日常日志存在memory文件夹里，按日期命名。平时你和OpenClaw聊天，它会把需要记录的内容实时写进当天的日志里；如果你明确说“记住这件事”，它也会立刻写入这个文件。

# 2026-01-26## 上午10:30 - API讨论与用户探讨了REST和GraphQL的选型，最终决定：为追求简洁性，采用REST方案。核心接口：/users、/auth、/projects。## 下午14:15 - 版本部署将v2.3.0版本部署至生产环境，全程无异常。## 下午16:00 - 用户偏好用户表示相比JavaScript，更倾向使用TypeScript。

里面的内容很灵活，比如上午和它聊的API选型、下午的版本部署、你说的偏好，都会按时间线记录下来，一目了然。

长期记忆则存在MEMORY.md文件里，这是OpenClaw整理后的核心知识库，这一层不会什么都记，只存重要的内容——比如你的长期偏好、关键决策、核心联系人、正在推进的项目等等。

# 长期记忆## 用户偏好- 编程语言：更倾向TypeScript（而非JavaScript）- 内容需求：喜欢简洁的解释说明- 正在推进的项目：Acme数据看板## 重要决策- 2026-01-15：数据库选用milvus- 2026-01-20：API架构采用REST而非GraphQL- 2026-01-26：样式开发使用Tailwind CSS## 核心联系人- 艾丽斯（alice@xxx.com）：设计负责人- 鲍勃（bob@xxx.com）：后端工程师

举个例子，你说自己更喜欢用TypeScript，数据库选了Milvus，这些重要信息都会被整理到这里，不管过多久，OpenClaw都能快速调取。

04

关键一环：agent怎么记起内容

很多人会好奇，OpenClaw每次和你聊天，怎么知道该调取哪些记忆？其实答案很简单：它有一套固定的记忆读取规则，还搭配了自动的索引构建机制。

其中，记忆读取规则就存在自动加载的 AGENTS.md 文件里，每次会话开始，它都会严格按这个规则执行。示例如下：

每次会话的必做步骤开始任何操作前，需完成以下步骤：1. 读取SOUL.md文件——定义智能体的自身定位2. 读取USER.md文件——明确服务的用户信息3. 读取memory目录下今日和昨日的日志文件——获取近期上下文4. 若为「主会话」（与用户的直接聊天），额外读取MEMORY.md——获取长期记忆无需向用户申请权限，直接执行即可。

随着使用时间变长，记忆文件会越来越多，要是没有索引，检索起来会越来越慢。Clawdbot 设计了自动索引构建功能，只要你保存了任意一个记忆文件（不管是智能体自动写入还是手动编辑），系统都会在后台自动触发索引构建流程，确保新内容能被快速检索。示例如下：

在你保存记忆文件后，系统会用Chokidar工具监控文件变化，为了避免频繁写入触发重复操作，还设置了1.5秒的防抖延迟；然后，系统会把文件内容分成约400个token的文本块，相邻文本块会保留80个token的重叠区域，这样既能保证语义连贯，又能提高检索精度；接着每个文本块会被传入embedding模型，转换成1536维的embedding数据，最后存储在数据库里。

文本块1：第1-15行 → 与文本块2重叠80个token文本块2：第12-28行 → 与文本块3重叠80个token文本块3：第25-40行

这个数据库里有四张核心表，分别存储文本块、embedding数据、全文检索内容和向量缓存（存储文本哈希值和对应向量，用于避免生成重复向量）。过程中，会结合语义检索（向量检索）和关键词检索（BM25）两种方式，按 7:3 的权重计算最终检索得分，公式如下

最终得分 = 0.7 × 向量检索得分 + 0.3 × 关键词检索得分

这样的混合检索方式，既能匹配语义相近的抽象内容（比如 “关于数据库的相关讨论”），又能精准捕捉人名、编号、日期这类具体信息（比如某人哪天提了什么信息）。

05 

如何做多智能体记忆的隔离与管理

OpenClaw支持创建多个agent，比如你可以建一个个人agent对接WhatsApp，再建一个工作agent对接Slack。用户完全不用担心不同agent的记忆会串在一起，因为每个agent的都有自己的专属工作目录，记忆源文件（md文件）会存在各自的目录里；而索引文件会统一存放在状态目录中，用agent ID区分，不会混淆。

具体的隔离结构示例如下：

~/.clawdbot/memory/              # 索引存储目录├── main.sqlite                  # 「主智能体」的向量索引└── work.sqlite                  # 「工作智能体」的向量索引~/clawd/                         # 「主智能体」的工作目录（记忆源文件）├── MEMORY.md└── memory/    └── 2026-01-26.md~/clawd-work/                    # 「工作智能体」的工作目录（记忆源文件）├── MEMORY.md└── memory/    └── 2026-01-26.md

默认情况下，每个agent 只能访问自己的记忆，无法读取其他agent 的内容；除非你没开启严格沙箱模式，否则不会出现记忆串用的情况。

06 

历史信息过多时，如何管理？

不管什么大语言模型，都有上下文窗口的限制。针对这个问题，OpenClaw会启动对话历史压缩功能，还搭配了记忆刷写机制。

压缩的逻辑在于：把早期的对话总结成简洁的摘要，完整保留近期的10轮左右对话，然后把摘要存到会话转录文件里，持久化到本地。这样一来，上下文占用会大幅减少，比如从18万token压缩到4.5万token，既能继续聊天，又不会浪费API费用。

压缩有自动和手动两种方式：自动压缩会在上下文接近窗口限制时触发，开启详细日志就能看到提示；手动压缩可以用/compact命令，还能自定义摘要重点，比如让它只总结决策内容和待解决问题。

但这里有个问题：对话压缩是有损操作，难免会有重要信息在摘要里丢失。为了解决这个问题，OpenClaw设计了记忆刷写机制——在压缩触发前，先把关键信息存到记忆文件里。

当上下文占用达到模型窗口的75%左右，系统会给agent发指令，让它把需要长期保留的内容写入当天的记忆文件；如果没有要存的内容，agent就会回复NO_REPLY，整个过程对你完全透明，但不用手动操作。等重要信息存好后，再执行压缩，就不用担心关键记忆丢失了。

记忆刷写的相关参数都能自定义配置，在clawdbot.json配置文件中就能修改，示例如下：

{  "agents": {    "defaults": {      "compaction": {        "reserveTokensFloor": 20000,        "memoryFlush": {          "enabled": true,          "softThresholdTokens": 4000,          "systemPrompt": "会话即将触发压缩，请立即存储需要长期保留的记忆。",          "prompt": "将需要长期记录的内容写入memory/YYYY-MM-DD.md，若无相关内容，回复NO_REPLY。"        }      }    }  }}

07 

冗余信息太多，如何裁剪

除了对话历史，工具执行结果也可能有很多冗余信息——比如一次npm install的安装日志，可能有5万个字符，全部保留会快速占满上下文窗口。这时候，OpenClaw的内容裁剪功能就会发挥作用。

它会对历史工具执行结果进行精简，比如把冗长的日志截断，只保留关键信息；对于更早的工具执行结果，还会直接清空，只留一个占位符。需要注意的是，这种裁剪只作用于传递给模型的上下文，磁盘里的完整执行结果不会被修改，后续想找的话，还是能通过记忆检索找到。

另外，很多大模型服务商（比如 Anthropic）为了降低延迟和成本，会对提示词前缀进行缓存，最长缓存 5 分钟：在缓存有效期内，重复发送相同的提示词前缀，只需要支付约 10% 的 token 费用；但如果会话闲置超过缓存有效期，后续请求需要重新缓存完整的对话历史，会产生全额 token 费用。

为此，Clawdbot 的裁剪还会结合模型的缓存有效期来优化。系统检测到缓存过期后，会在后续请求前自动修剪旧的工具执行结果，通过减小提示词的整体体积，降低重新缓存的 token 成本。

这套裁剪逻辑的核心配置也能自定义，示例如下：

{  "agent": {    "contextPruning": {      "mode": "cache-ttl",      // 仅在缓存过期后执行裁剪      "ttl": "600",              // 与模型的缓存有效期保持一致（单位：秒）      "keepLastAssistants": 3,  // 保留最近3次智能体的工具执行结果      "softTrim": {        "maxChars": 4000,        "headChars": 1500,        "tailChars": 1500      },      "hardClear": {        "enabled": true,        "placeholder": "[旧工具执行结果已清空]"      }    }  }}

总结

聊到这里，相信你已经明白OpenClaw全量记忆的实现逻辑了，这套7×24小时持久记忆、全量检索系统，最高的原则就是用户可控，具体体现在四个方面：

第一是透明化，所有记忆都是纯md文件，看得见、能编辑，没有晦涩的数据库格式，也没有隐藏的存储方案；

第二是检索优先，不会把所有记忆都塞进上下文，而是通过检索获取相关内容，既聚焦又省成本；

第三是持久化，重要信息都存在本地磁盘，不会因为对话压缩、会话结束而丢失；

第四是混合检索优先，结合语义检索和关键词检索，兼顾了检索的精准度和灵活性（这里原始版本用的是sqlite分别执行关键词与语义检索，然后对两路检索结果进行手动合并，这里我们建议可以直接采用Milvus混合检索，可以用一次检索搞定两个环节）。

如果你也对AI记忆机制感兴趣，或者想尝试部署OpenClaw，不妨去它的GitHub仓库看看，亲手体验一下。

阅读推荐
自动驾驶+百亿向量，全球GPU龙头如何用Milvus加速模型训练
高效索引之HNSW_SQ：如何同时兼顾RAG的速度、召回率与成本
Spark做ETL，与Ray/Daft做特征工程的区别在哪里，如何选型？
RAG优化不抓瞎！Milvus检索可视化，帮你快速定位嵌入、切块、索引哪有问题
都有混合检索与智能路由了，谁还在给RAG赛博哭坟？