OpenClaw 会话机制与记忆系统深度剖析

OpenClaw 会话机制与记忆系统深度剖析

OpenClaw 会话机制与记忆系统深度剖析：文件源真理 + 混合检索驱动的持久化 Agent OS 架构
大家好，我是fishyue，这次分享的是  OpenClaw 会话机制与记忆系统。
因为最近一直在折腾openclaw，看了很多博客和视频都在刷屏它，通过了解它有一定的安全风险，所以我是在 win 10 平台下 安装VM虚拟机，然后在安装 centos 7 系统下 使用docker  安装openclaw。

这样安装是最效率也是最方便的,整个流程下来,半个小时解决战斗,麻烦的是，为解决这个大龙虾失忆的问题,也就延伸出我写以下这篇文章的原因,去理解Peter Steinberger是如何构建起这个大龙虾的。
每次启动后，都需要让他去读下MEMORY.MD他才会恢复之前的上下文内容。

然后我还使用QMD去记忆核心的事情，并且QMD能够解决“检索速度和质量”的问题，重要是他免费，而且节省龙虾token。

当然也有解决每次/rest 或者新建对话框失忆的问题，这个我下次会分享。

以下是我对 OpenClaw 会话机制与记忆系统深度剖析：

2026 年的 Agent 浪潮中，LLM 的核心瓶颈不再是推理速度，而是状态持久化与上下文管理。传统框架（如 LangChain Memory 或 MemGPT）要么依赖云端向量库（隐私风险 + 延迟），要么简单追加历史导致 token 爆炸。OpenClaw（前 Clawdbot/Moltbot，由 Peter Steinberger 开源）给出了极简却硬核的本地优先方案：一切记忆以纯 Markdown 文件为单一源真理（Source of Truth），模型仅读取磁盘上显式写入的内容。会话状态通过 JSONL append-only 日志 + 自动 compaction 管理，检索层采用 SQLite-vec 驱动的 hybrid（vector + BM25 + MMR + temporal decay）搜索。
本文结合官方文档（docs.openclaw.ai/concepts/memory）、Substack 架构解析（ppaolo）、Gitbook 深度笔记（snowan）、DEV.to/Medium 技术拆解，以及社区讨论（如 @indexsy 的高级内存套件提示、@ivaavimusic 的本地 embedding 启用），系统化拆解 OpenClaw 的会话生命周期、记忆分层架构、推理流水线及设计权衡。结合用户提供的 OpenClaw 生成内容，进行硬核技术扩展。

（图：OpenClaw 高层架构概览。Gateway 负责 Session Resolution 与消息路由，Agent Runtime 组装上下文（Session History + Workspace + Persistent Memory），Skills 通过 sandbox 执行，持久化内存以本地文件系统 + DB 为后盾。来源：Medium / Tech-Practice）
一、会话生命周期机制（Session Lifecycle）：OS 进程隔离的 Agent 实现

OpenClaw 会话设计仿照操作系统进程模型，强调命名空间隔离、安全边界与状态持久化。
1.1 初始化与重置流程

• • 新会话创建：/new 或 /reset 命令触发 Gateway Session Resolution。新 Session ID 生成（格式：agent::，如 agent:main:telegram:dm:... 或 group:discord:...）。
  
• • 上下文重置：短期内存（Session Context）清零，重新加载 workspace 根目录核心文件。
  
• • 模型绑定：动态加载配置模型（我使用的是：longcat/LongCat-Flash-Thinking-2601，常通过 OpenRouter/Kimi 等）。
  
• • 持久化存储：所有对话以 append-only JSONL 形式落盘于 ~/.openclaw/agents//sessions/，支持 branching（对话树 fork）与恢复。
  

1.2 记忆读取优先级（严格顺序）

• 1. 当前会话实时历史（Session JSONL）—— 首选，保持连续性。
  
• 2. Workspace 核心文件：AGENTS.md（全局规范）、SOUL.md（人格/语气）、USER.md（用户画像）、TOOLS.md（工具使用指南）。
  
• 3. 条件加载：MEMORY.md + memory/YYYY-MM-DD.md 需显式 memory_get / memory_search（主私聊会话可配置自动注入部分；群聊永不加载，防敏感泄露）。
  

这种显式读取避免了“自动过载”，新会话启动默认仅读 today + yesterday 日志（

感谢分享