【文章目的】本文基于 OpenClaw Memory 底层运行原理，面向两类读者：

想提升养虾技巧的人：从原理出发，给出更好地使用 OpenClaw（龙虾）的具体建议，让你的龙虾更稳、更聪明、更省钱。

想学习 OpenClaw Memory 原理的人：系统梳理 Memory 的四层结构、运行机制，帮你真正看懂这套系统。

写给完全小白：OpenClaw 是一个 AI Agent 系统，你可以把它想象成一只聪明的助手。它能帮你搜索信息、执行任务、记住你的偏好。但它的「记忆」和人类不同——每次对话结束后，工作记忆会清空，只有写入文件的内容才能被下次记住。理解这一点，是用好它的关键。

第一部分：OpenClaw Memory 运行原理

在学会「养虾技巧」之前，我们先要搞清楚龙虾的「大脑」是怎么工作的。很多人用了很久 OpenClaw，却不知道为什么它有时候「记得」，有时候又「忘了」。

1.1 核心设计哲学：文件即记忆

OpenClaw 的官方AGENTS.md文档第一句话就是：

You wake up fresh each session. 

这意味着：每次会话启动时，Agent 是全新状态，没有任何记忆。记忆的连续性完全靠文件系统来桥接。官方文档进一步说明：

OpenClaw memory is plain Markdown in the agent workspace. The files are the source of truth; the model only remembers what gets written to disk. 

总结后就是OpenClaw是靠写入磁盘来记得各种事情。而你的OpenClaw的记忆就存储在<你配置的Claw的 workspace>/memory目录下。但是，除了要「记得」，我们还需要OpenClaw记得准确，记忆稳定性与哪些因素相关？

记忆的连续性靠文件桥接，但「记忆稳定性」（即龙虾是否能可靠地记住并正确召回信息）还受以下三个因素影响：

这三个因素直接对应后文「养虾技巧」中的三类优化方向：保障写入→控制质量→管理索引。

1.2 四层记忆结构

OpenClaw 的记忆分为四层，每层的存储位置、注入方式、生命周期完全不同：

第一层：工作记忆（Working Memory）= 当前对话窗口

小白理解：就像人的「短期记忆」，只在当前对话中有效。对话结束后，这部分记忆就消失了。工作记忆由两部分组成：

System Prompt区：包含认知层文件（SOUL/AGENTS/USER 等）、MEMORY.md（仅私聊注入）、近两天日志、激活的 SKILL.md。这些内容在会话启动时直接拼入，模型不需要检索就能看到。

Conversation History 区：本次会话的所有对话内容，按时间顺序追加。这是最核心的工作记忆，同时实时落盘到 sessions/*.jsonl。

当对话历史积累到接近上限时，触发压缩（Compaction）：先执行 Memory Flush 把重要内容写入文件，再对历史消息做摘要压缩，释放空间。

第二层：会话记忆（Session Memory）= memory/YYYY-MM-DD.md

小白理解：就像每天的「工作日记」，按天记录当日发生的事情。

会话记忆是按天追加写入，记录当日上下文、决策、活动。会话启动时自动加载今天和昨天两天的日志注入 Context，更早的历史只能通过 memory_search 按需召回。如果开启时间衰减（temporalDecay），召回分数会随时间指数衰减，半衰期默认 30 天。

第三层：长期记忆（Long-term Memory）= MEMORY.md

小白理解：就像人的「长期记忆」，存放跨会话都稳定的重要知识，永不遗忘。

长期存放用户偏好、项目惯例、关键决策、命名规范等稳定内容。需要人工或 Agent 显式写入，不会自动生成。私聊会话启动时直接注入 Context。豁免时间衰减，无论多久都不降权。MEMORY.md 仅在私聊（1对1）中加载，群聊中不会注入，防止个人信息泄露。

第四层：技能记忆（Skill Memory）= SKILL.md（渐进式加载）

小白理解：就像「操作手册」，只有在需要用到某项技能时才会翻出来看，平时不占用大脑空间。SKILL.md采用渐进式加载策略，具体如下：

这意味着会话启动时模型只知道「有哪些 Skill」，不知道「每个 Skill 怎么用」。只有当 Agent 判断某个 Skill 与当前任务相关，才会把完整的 SKILL.md 注入 Context。这是 OpenClaw 控制 Context 消耗的核心机制。

1.3 memory_search 的召回机制

memory_search 是 Agent 在推理过程中主动调用的一个工具，就是在龙虾需要时自己去搜以前记下的内容，和调用浏览器、读文件是同一个层级的东西。它搜的是 SQLite 向量索引，使用机器预先建好的关键词与语义进行索引（可以理解成给笔记做的检索目录），而不是每次都对笔记原文做全文扫描。

重要提醒：memory_search 的召回结果不稳定，不适合作为重要决策的来源。重要决策的信息来源只能来自数据库和API的实时查询。召回结果不稳定因为以下原因：

• 文件有时间差：你刚改完笔记，目录可能还没完全更新，搜到的仍是上一版里的片段。

• 像不代表对：语义检索会按相似度凑结果，话说法接近但事实已变时，仍可能被搜出来。

• 关键词会漏或偏：ID、错误码这类要靠字面匹配的信息，一旦写法略变或目录未收录，可能搜不到或搜到旧的。

• 后台实现常落在 SQLite 里：读者只需知道这是本地的一个检索库；若更换嵌入模型或重建索引，排序和结果集合也可能变化，同一句问话前后两次不完全一样是正常现象。

• 没有配置语义：系统会退化成更偏关键词的检索，近义说法的召回会变弱，你会感觉明明写过却搜不到。

检索算法（混合搜索）：finalScore = 0.7 × 向量语义分 + 0.3 × BM25 关键词分

向量搜索：找语义相关的内容，即使措辞不同也能匹配（如「Mac Studio 主机」和「跑 Gateway 的那台机器」）。

BM25 关键词搜索：精确匹配特殊 token，如 ID、错误码、接口名等。

1.4 Memory Flush——防止「失忆」的关键机制

当 Context 接近上限时（以 200K 窗口为例，约在 176,000 tokens 时触发），系统会插入一个静默 Agentic Turn，提示模型把当前会话中值得持久化的内容写入 memory/今天.md。这是防止信息在压缩时永久丢失的关键机制。

关键特性：静默执行提示词包含 NO_REPLY，不会在对话中显示；每次压缩循环只触发一次；只读沙箱模式下此机制会被跳过，是常见的记忆失效原因之一。

第二部分：养虾实战技巧（按目标分类）

理解了 Memory 的运行原理，我们就能从根本上改变使用 OpenClaw 的方式。下面的技巧按照解决什么问题来分类，每一条都有其背后的原理支撑。

A类技巧：提升记忆稳定性——让龙虾「记得住」

A1：保障写入——不要让重要信息在压缩时丢失

原理依据：Memory Flush 是工作记忆向会话记忆的唯一自动转化通道。只读沙箱模式下此机制会被跳过，是最常见的记忆失效原因。

养虾建议：确保工作区不是只读模式（workspaceAccess 不能设为 ro 或 none）。对于重要的长对话，在关键节点主动让龙虾写入日志，不要完全依赖自动 Flush。

A2：控制写入质量——写进去的内容要「值得写」

原理依据：MEMORY.md 的核心定位是精华提炼，不是流水账。写入噪声数据（如原始日志、高波动数据）会放大乱召回，干扰决策。

养虾建议：按信息类型分层存储：

MEMORY.md应该写什么：重大决策及其原因、个人偏好和工作习惯、跨项目的重要上下文、需要长期记住的约定和禁忌。

MEMORY.md不该写什么：日常对话记录（放daily notes）、临时性的任务状态（会变化，写了会污染）、密码和密钥（安全风险）。

B类技巧：提升执行准确性——让龙虾「做得对」

B1：任务边界清晰——把龙虾当任务系统，不要当聊天助手

原理依据：OpenClaw 背后有消息路由、Agent 运行环境、工具系统和会话上下文。模糊的任务会让它在很大的空间里乱跑，输出发散。当任务边界清晰时，Agent 的行为就会更稳定。

养虾建议：每次会话都当成给龙虾下一张任务单，明确定义：它服务的是哪个场景、能调用哪些工具、要读哪些资料、要输出成什么结果、什么时候该停。

最适合用龙虾的任务：有明确输入输出的知识类工作（资料搜集、文档整理、方案初稿）；需要工具参与的半自动执行任务（批量读文件、搜索项目文档）。

B2：增加检查点——对稳定交付的任务，半自动比全自动更可靠

原理依据：大语言模型会产生幻觉（即编造不存在的内容）。在高风险执行链路上，每次执行前开新会话或执行前显式让模型重新确认当前状态是必要的工程实践，防止会话中积累的错误推理污染后续决策。

养虾建议：在关键步骤增加检查点：（1）先让它列计划，不直接执行（2）先让它展示将读哪些文件（3）先给中间稿，再决定是否继续（4）让它干完活儿自己检查（幻觉率大大减少）

B3：关键链路关掉 memory_search——确定性操作不靠召回

原理依据：对话历史是最大的 Context 污染源。在一次会话中，如果模型产生了错误的中间推理，这个错误会以确定性方式留在 Conversation History 里影响后续所有轮次，比 memory_search 的概率性召回错误更危险。

养虾建议：对必须确定性的链路（如执行工作上的修改任务等），可为该 Agent 关闭 memorySearch，只靠 DB + 工具 + SKILL.md 的确定性约束。凡是可以通过 DB/API 实时获取的数据，一律不走 Memory 召回，Memory 只补充 DB 查不到的语义知识。

C类技巧：提升成本效率——让龙虾「更省钱」

C1：最小必要上下文——让模型知道得更少，反而更聪明

原理依据：System Prompt 会把工作目录、可用工具、项目文档、记忆文件等全部拼进去。上下文越长，token 消耗越高，模型注意力会被稀释，推理质量下降。

养虾建议：遵循「最小必要原则」：（1）长期规则文件只保留真正稳定的原则（2）一个文件只写一类事情（3）背景材料尽量摘要化，不要整篇原文硬塞（3）每次任务只给最小必要上下文，和当前任务无关的内容尽量不带入会话

当记忆内容较多时，单一MEMORY.md文件会变得臃肿，影响检索精度。社区实践推荐「宏观索引+微观语义搜索」的分层结构：MEMORY.md作为简短索引，详细内容通过向量搜索按需召回。

C2：按任务类型分层选择模型

原理依据：任务效果由模型能力、上下文长度、工具调用稳定性三者综合决定，不同任务的瓶颈不同。一刀切地用最贵的模型，既浪费钱，也不一定效果最好。

养虾建议：按任务类型分层选择模型：

C3：把 Skill 设计成 SOP，不要当能力清单

原理依据：SKILL.md 是行为规范，不是记忆。它控制的是Agent 怎么做事，而不是Agent 记得什么。无脑堆 Skill 会让系统越来越乱、过度输出、频繁消耗 token。

养虾建议：让每个 Skill 都面向一个固定任务，有固定输入、固定步骤和标准输出，也有精确的停止条件。把一个大 Skill 拆成多个小 SOP，效果会稳定很多，也更适合复用。

D类技巧：提升任务质量——让龙虾「输出更好」

D1：指令写成任务说明，不要写成聊天

原理依据：Agent 会根据上下文和工具去执行操作，模糊的指令会导致过度解读，消耗大量 token 却输出不是你想要的。

养虾建议：把指令写成结构化的任务说明，包含：明确目标、输入材料、执行步骤、输出格式、限制条件。

❌不好的写法：「帮我看懂这个项目源码」

✅好的写法：请只从 README.md、ARCHITECTURE.md、src/auto-reply 目录下的文件进行分析。先回答系统入口在哪里，再回答消息链路如何流转。不要泛泛总结，不要猜测未读到的内容。最后输出一份 5 段式分析，包含关键文件名和职责。

D2：复杂任务采用两段式调用

原理依据：对话历史是最大的 Context 污染源。让 Agent 一次完成探索和总结两件事，会导致输出冗长且结构混乱，错误推理还会污染后续决策。

养虾建议：分两轮执行：

第一轮：让龙虾做探索——搜集、扫描、初步归类、列出可能路径

第二轮：再让它做收口——只基于第一轮的结果，输出判断、摘要、对比、结论

D3：少写人格设定，多写行为约束

原理依据：SOUL.md 里的人格描述对模型行为影响有限，真正影响行为路径的是操作约束。模型真正吃的是操作约束，不是人格夸奖。

养虾建议：在 AGENTS.md 里写清楚：只允许读取哪些目录、优先使用哪些工具、什么情况下必须先提问、什么情况下禁止直接执行、输出必须包含哪些字段、引用结论时必须给出处。

第三部分：Memory 治理进阶（系统化管理）

如果你已经理解了前两部分，想进一步提升龙虾的稳定性和可靠性，这一部分的治理方案将帮助你系统化地管理 Memory。

三条核心原则

原则一：memory_search不能作为事实。它本质是 Markdown + 可选向量索引，召回结果不稳定。

原则二：对话历史是最大的Context污染源。在一次会话中，如果模型产生了错误的中间推理，这个错误会以确定性方式留在 Conversation History 里影响后续所有轮次，比 memory_search 的概率性召回错误更危险。

原则三：SKILL.md是行为规范，不是记忆。投放 SOP、工具调用规范、字段校验逻辑应该放在 SKILL.md 里，而不是放在 MEMORY.md 里——前者是确定性注入的行为约束，后者是概率性召回的背景知识。

总结

SKILL.md管行为规范，MEMORY.md放稳定知识，每日日志放过程记录，DB/API扛资金真相，memory_search只做语义补充，关键执行链路关掉Memory召回，对话历史是最大的Context污染源要主动管理。

--本文基于 OpenClaw 源码级实现原理及社区资料整理，经修订补充后作为独立完整版使用。具体行为以您所用版本与官方文档为准。