如果你在用OpenClaw，你大概率经历过这样的场景。昨天下午你和Agent花了两个小时排查一个线上问题，过程中它帮你查了日志、读了配置、试了好几种方案，最后定位到是连接池配置导致的。你们还顺便讨论了项目里几个服务之间的依赖关系，以及下周要做的重构计划。第二天早上，你让它继续昨天聊到的重构，它回了一句："你好，请问你说的是哪个重构？能给我一些背景吗？"昨天那些讨论，它全忘了。
这不是偶发现象。MEMORY.md里的基本信息，你的名字、偏好、常用工具，这些它记得住，因为每次都会加载。但昨天对话里的具体细节，排查过程中发现的关键线索、讨论过的方案取舍、约定好的下一步计划，这些留在了session历史和memory目录的文件里。新session开始后，Agent需要主动搜索才能找回这些细节，但它不一定知道该搜什么，也不一定搜得准。
根本矛盾是：OpenClaw的记忆机制是为单次对话设计的，而用户期望的是一个长期相处的私人助理。
这就是seekdb M0要解决的问题。
一、OpenClaw记忆为什么会失效
1.1 记忆机制的运作原理
OpenClaw通过在工作区写入纯Markdown文件来记住内容。模型只会记住保存到磁盘的内容，没有隐藏状态。
智能体有三个与记忆相关的文件。MEMORY.md是长期记忆，存放持久事实、偏好和决策，会在每个私信会话开始时加载。memory/YYYY-MM-DD.md是每日笔记，存放持续上下文和观察记录，今天和昨天的笔记会自动加载。DREAMS.md是Dream Diary和Dreaming扫描摘要。
当Agent需要记住某件事时，用户直接告诉它："记住我偏好TypeScript。"它会把内容写入适当的文件。MEMORY.md是紧凑、经过整理的层，用于持久事实和长期决策。memory/YYYY-MM-DD.md是工作层，用于详细的每日笔记、观察记录和会话摘要，这些文件会被索引用于memory_search和memory_get，但不会在每一轮都注入到常规启动提示中。
这套机制存在几个关键弱点。
MEMORY.md会被全量加载到每次请求的系统提示词里。用的时间越长，MEMORY.md越大，每次API调用的input token越多，响应越慢。Bootstrap文件有单文件20K字符的默认上限，但早在到达上限之前，臃肿的上下文就已经开始挤占Agent的工作空间了。
当session太长时，OpenClaw会触发compaction，用LLM把旧对话分段总结压缩，腾出上下文空间。同时触发memory flush，在compaction前启动一个嵌入式agent，让它自行决定把哪些重要信息写入memory文件。但compaction的总结本质上是有损压缩，而检索侧的切片逻辑按行和字符预算硬切，不识别语义边界。关键上下文可能被切断，检索召回质量差。
更糟糕的是，Agent知道信息可能会丢，于是更积极地往MEMORY.md里塞东西，加速膨胀。记住的代价是昂贵，遗忘的代价是犯错。需要第三条路。
1.2 工具调用是加速器
很多OpenClaw用户没意识到的一点是，Agent调用工具产生的中间结果，web_fetch返回的网页、exec输出的命令结果，单条最大400K字符，会快速填满session。这些中间过程不适合写进MEMORY.md，但可能包含有价值的信息。无论选哪条路，工具调用都会加剧恶性循环。
二、seekdb M0的设计思路
2.1 记忆独立于上下文
seekdb M0是一个OpenClaw云端记忆插件，核心理念一句话：不把所有记忆塞进system prompt，而是在每次对话开始前，只检索与当前话题相关的记忆片段注入上下文。
和MEMORY.md的全量加载不同，seekdb M0把记忆拆解为独立的事实存储在云端数据库中。每条事实都有向量表示和全文索引。对话开始前，seekdb M0用混合检索找到最相关的几条记忆注入上下文；对话结束后，自动从对话中提取新事实，与已有记忆比对后决定新增、更新还是跳过。
这意味着MEMORY.md不再膨胀，记忆存在云端，不占系统提示词空间。session重置不再是灾难，记忆是持久化的，新session开始时自动召回。跨设备同步，换一台机器，记忆还在。
2.2 两阶段记忆管理
seekdb M0把"存什么"和"怎么存"拆成两个独立的阶段。
第一阶段是事实提取。对话结束后，seekdb M0只提取user和assistant之间的对话文本，跳过所有工具调用的中间输出，用LLM抽取出原子化的事实。比如"用户叫张三，是数据库工程师，在杭州工作"会被拆成三条独立事实。
提取时有几条硬规则：时间信息必须保留，保持原语言不翻译，敏感信息一律不提取。
第二阶段是记忆决策。提取出的事实不是直接写入数据库，而是先和已有记忆做比对。M0用向量检索找到最相似的已有记忆，然后让LLM判断：这条事实应该新增、更新已有记忆、删除矛盾记忆，还是已经被覆盖可以跳过。实际运行中，为了避免误删，插件侧会把DELETE当作NONE处理，只新增和更新，永远不主动删除已有记录。
这种两阶段设计的好处是关注点分离，提取阶段保证事实的质量和合规性，决策阶段保证记忆库不会无限膨胀。
2.3 工具调用自动压缩
seekdb M0对工具调用的中间输出用确定性规则压缩，不花一个LLM token。当工具结果被持久化到会话历史时，tool_result_persist钩子会介入，把原始输出替换为结构化摘要。
压缩比极高，几万字符压缩到几百字符，且完全是规则化的，不需要LLM理解内容，只需要保留"做了什么、结果如何、简要预览"。在事实提取阶段，seekdb M0直接跳过所有tool/toolResult类型的消息，只看人和Agent之间的对话。这意味着即使一次对话涉及大量工具调用，事实提取的LLM输入也被控制在很小的范围内。
与OpenClaw原生的做法相比，compaction时把完整session送进LLM压缩，这种方式从源头控制了送入LLM的数据量，而不是等到溢出了再惰性压缩。
三、经验系统：从孤立知识到团队智慧
3.1 记忆与经验的区别
记忆解决的是"记住用户是谁、喜欢什么"的问题。但OpenClaw用户还有另一个困扰：Agent有skill，但没有实践经验。一个装了各种skill的OpenClaw Agent，就像一个刚从学校毕业的学生，专业知识有了，但真正上手办事时，会遇到各种课本里没写过的问题。
经验是通用智慧。一个Agent踩过的坑，所有Agent都能受益。
在早期M0版本中，经验是一个单一概念。但在真实工作流中，这个词实际上包含了两种完全不同性质的东西。
第一种是操作型知识。例如Spotify的列表端点是分页的，默认page_limit只有5，必须显式设置为20，循环调用直到返回空列表。这是可结构化、可流程化的知识，有明确的步骤和陷阱，适合在不同用户间共享。
第二种是策略型知识。例如要查找用户播放最多的R&B歌曲，不能只查询歌曲库，还需要从专辑库和播放列表库中收集歌曲ID，去重后逐一获取详情。没有参数，没有响应字段，只有方向指引。没有它，Agent会默默遗漏歌曲，返回不完整的结果。
把两者混在一起会导致两个问题。检索信号会互相干扰。操作型知识往往很长，策略型知识很短。在向量搜索中，长文本有更丰富的语义，会把短的策略型条目挤出去。上下文管理会失效。把完整操作手册直接塞进Agent上下文，模型会开始"读手册"而不是推理状态。
3.2 经验与技能的拆分
基于这个认识，seekdb M0将知识拆分为两部分。
经验是策略型知识，用一两句话描述"做什么、注意什么"，轻量级，注入成本低。技能是操作型知识，是结构化的程序，包含步骤、陷阱和前置条件，有清晰的执行路径。
两者通过skill_refs链接。一条经验可以引用多个技能。Agent先读取经验获取整体策略，当需要具体步骤时，再通过skill_refs展开完整的技能。
这种"先摘要、按需展开"的设计是核心，称为渐进式加载。
3.3 经验系统的运作流程
经验系统有四个阶段。
自动蒸馏：当一次对话成功完成且涉及工具调用时，seekdb M0在后台异步分析这次交互，提炼出可复用的经验。这个过程是非阻塞的，不影响正常对话。
分级验证：新经验不会立刻对外公开。它有一个生命周期，草稿阶段仅对创建者可见。正向反馈累积达到阈值后进入公开池，所有用户可检索。负向反馈比例过高时标记淘汰。
自动注入：下次有Agent遇到类似场景时，seekdb M0在对话开始前检索相关经验，和记忆一起注入上下文。Agent不需要主动去查经验，相关经验会自动出现在视野里。
反馈闭环：Agent在对话中被注入了某条经验后，本轮对话的执行结果作为反馈信号自动上报。成功的执行驱动经验晋升，反复失败的执行让低质量经验被淘汰。
经验中不包含原始对话内容，只保留蒸馏后的通用知识。一个用户的隐私信息不会通过经验系统泄露给其他用户。
3.3 AppWorld基准测试结果
在AppWorld基准测试中，GPT-4o的基准通过率为24%。引入M0的经验技能系统后，通过率提升到39%，相对提升62%。平均步骤从9.5下降到6.2，下降35%。Token消耗从256万下降到174万，下降32%。Hermes的SKILL.md方法在相同轨迹上通过率仅为22%。
这个结果表明，系统不是让Agent记住更多历史，而是让它们真正从已完成的工作中学习。
四、与其他记忆方案的对比
4.1 OpenClaw内置组件的局限
OpenClaw内置了两个记忆组件。memory-core是基于文件的记忆搜索，通过memory_search和memory_get两个工具对工作区下的MEMORY.md和memory/*.md文件进行混合搜索。memory-lancedb使用LanceDB存储向量嵌入，支持auto-recall和auto-capture。
两者都缺失多用户隔离能力，所有客户的记忆存在同一个地方，检索时无法按用户过滤。在多客户场景中，不同客户的偏好混合在同一份文档里，相互冲突的信息会让Agent混乱。
4.2 云端记忆插件的定位
memory-agentcore基于AWS AgentCore Memory构建，采用三层记忆模型。上下文层管理当前对话发生了什么和短期记忆。本地记忆层管理记住了什么和召回需要的长期记忆。云端共享层管理共享了什么和如何实现用户隔离与跨Agent共享。
该方案采用层级命名空间加actorId驱动的最小权限隔离，在多客户面客模式下通过peerId实现记忆按客户自动隔离、跨Agent天然共享。
Alibaba Cloud的Agentic Memory API方案为OpenClaw提供持久化的长记忆能力。通过向量混合云存储，实现跨会话信息持久化及智能检索，突破上下文限制，赋予Agent长期个性化记忆能力。
该方案支持自动召回和自动捕获。在before_agent_start事件中自动搜索相关记忆注入上下文。在agent_end事件中自动提取对话中的关键信息并写入云端。
4.3 TeamMemory与mcp-agents-memory
TeamMemory是一个基于MCP协议的团队经验数据库服务，通过MCP把语义可搜索的经验库接进AI。遇到问题自动查历史方案，解决后自动提炼并存下来。适合3到10人的技术团队共享经验。
mcp-agents-memory是一个跨会话、跨机器的共享记忆池，按时间顺序组织记忆，多个Agent共享同一个记忆池，每个平台和模型自动获得自己的视图，项目标签让协作者看到彼此的上下文。
五、技术实现与部署
5.1 混合检索的实现
经验与技能拆分后，分别存储在独立的OceanBase表中。每个表都有title和description字段，两者都建立了向量索引和全文索引。检索时并行执行四条路径：标题向量、描述向量、标题全文、描述全文，然后通过RRF融合排序。
标题匹配按名称查找，描述匹配按内容查找。向量和全文互补，向量处理语义等价，全文处理精确匹配。
5.2 蒸馏的顺序
从轨迹中提取知识遵循特定顺序。先提取技能，识别操作流并将其结构化为步骤、陷阱和前置条件。存储技能，去重后审查写入。构建技能上下文，将已有技能列表传递给下一步。然后提取经验，LLM可以看到已有技能并自然地引用其ID。存储经验，skill_refs记录引用关系。
技能优先顺序意味着经验到技能的链接不是人工策划的，而是在蒸馏过程中自然形成的。
5.3 部署方式
seekdb M0以OpenClaw插件形式安装，支持云端SaaS部署和私有化部署两种模式。配置完成后，Agent在每轮对话中自动完成记忆的召回和捕获，无需用户显式调用工具。
六、总结
OpenClaw记忆丢失的根本原因在于其记忆机制是为单次对话设计的，而不是为长期陪伴设计的。MEMORY.md的全量加载导致上下文膨胀，compaction的有损压缩导致信息丢失，工具调用的中间输出加速了session膨胀。
seekdb M0通过三个核心设计解决了这些问题。记忆独立于上下文，用云端存储替代文件全量加载，在对话开始前只检索相关记忆。两阶段记忆管理，分离事实提取和记忆决策，保证质量的同时控制记忆库规模。经验与技能拆分，让Agent不仅能记住，还能从已完成的工作中学习。
在AppWorld基准测试中，这套方案将GPT-4o的通过率从24%提升到39%，步骤减少35%，Token消耗减少32%。
Agent能力的进步不会停止，记忆与经验系统也会持续演进。从记住到学习，从孤立到共享，这是AI Agent走向真正实用的必经之路。