二、为什么是 OpenClaw——从架构前提到三层记忆模型⏱ 30 秒速览| OpenClaw 记忆 三层分工Session工作台秒级逐字记录→Workspace书架永久确定性注入系统提示词→Plugin深层数据库向量检索概率性召回。三层对应人类工作记忆→长时记忆→元记忆。核心洞察元记忆知道什么该记、什么该忘是多数竞品缺失的层次——OpenClaw 通过 Weibull 衰减 三级晋升 六步清理实现了它。记忆方案可热插拔替换生态竞争而非一家垄断。2.1 24/7 Always-On记忆的前提是在场大多数 AI 助手只在你打开 App 时存在。你关闭标签页它就消失了。这种按需存在的模式对记忆系统来说是致命的——你不在的时候发生的事情它永远无法记住。OpenClaw 走了一条完全不同的路Gateway 架构WebSocket 控制平面常驻运行Node 24 长进程。这不是一个等你来用的 App而是一个 24/7 在线的服务端。20 通信渠道WhatsApp / Telegram / Slack / Discord / SMS / Email / Webhook……你在哪里它就在哪里。不是你来找它是它一直在支持 Cron 定时任务、Heartbeat 心跳、Webhook 事件触发——即使你没有主动发消息Agent 也在后台观察、整理、预判详见 §3.3 路径 C。Gateway 韧性Gateway 进程崩溃或重启时Session 状态已持久化在 JSONL 文件中重启后自动恢复。Plugin MemoryLanceDB作为嵌入式数据库同样持久化在磁盘。24/7 承诺的前提是宕机可恢复而非永不宕机——这是工程诚实。So What没有 24/7 的在场能力记忆根本没有输入源。封闭在 App 内的助手只能记住你在 App 里说的话。OpenClaw 通过全渠道接入获得了你在所有数字场景中的上下文——这是丰富记忆的物理前提。[召回率]多语言注意事项跨渠道记忆在多语言场景下依赖 Embedding 模型的跨语言能力。OpenAItext-embedding-3-small对中英文混合检索表现良好但小语种之间的跨语言召回可能衰减。如果你在 Telegram 说英文、微信说中文同一主题的记忆能否互通取决于 Embedding 模型对这两种语言的语义空间对齐程度。2.2 三层记忆架构总览本节只讲是什么和为什么这么分层。技术细节在第三章的记忆生命旅程中展开。理解 OpenClaw 记忆系统的关键是理解它的分层。不是一个向量数据库就完事了——不同类型的信息需要不同的存储策略、不同的生命周期、不同的访问模式。就像人类不会把今天的早餐和毕生的技能存在同一个大脑区域一样。③ Plugin Memory · 程序性长时记忆② Workspace Memory · 陈述性长时记忆① Session Memory · 工作记忆实时流入摘要压缩压缩前刷写Pre-compaction Flushagent_end 钩子对话结束回调before_prompt_build提示词构建前召回系统提示词注入每次调用自动加载Agent 自主创建技能注入热重载上下文窗口分钟~小时级Pruning 裁剪 /compact 摘要AGENTS.md · SOUL.mdTOOLS.md · USER.mdSkills 技能文件memory-lancedb内置基线memory-lancedb-pro社区生产级memU / graph-memory / MemOS 等用户对话从上面的架构图可以看到信息在三层之间的流动是双向的从 Session 流向 Workspace 和 Plugin 实现持久化又从 Workspace 和 Plugin 流回 Session 实现召回。这对应人类的记忆巩固与提取过程你在对话中工作记忆学到的东西入睡后经过巩固进入长时记忆未来需要时再提取回工作记忆使用。下表量化了三层的关键差异层级认知科学角色存储形式生命周期信息保真度容量Session工作记忆JSONL 转录会话级小时~天~100%原始对话逐字记录有限受上下文窗口约束Workspace陈述性长时记忆Markdown 文件永久手动/Agent 编辑~80%结构化提炼丢失对话语气中每文件数 KBPlugin程序性长时记忆向量数据库永久Weibull 衰减~2%–40%L0 索引 ~2%L2 完整叙述 ~40%高数万条认知科学对照表§1.4 预告的完整版人类记忆系统特征OpenClaw 对应映射理由感觉记忆(Sensory)毫秒级暂存、快速衰减实时消息流未处理的原始输入信息还未进入处理管线工作记忆(Working)秒~分钟级、7±2 项容量Session Context上下文窗口有限容量、活跃处理短时记忆(Short-term)分钟~小时级、需复述维持Session Pruning /compact摘要信息压缩以延长留存长时 · 陈述性(Declarative)可言说的事实与事件Workspace Memory4 注入文件显式可读的持久知识长时 · 程序性(Procedural)不可言说的技能与习惯Skills Plugin Memory 向量存储隐式的行为模式元记忆(Metamemory)对自身记忆的监控与调节Weibull 衰减 三级晋升 六步清理知道什么该记、什么该忘值得特别注意最后一行元记忆是大多数 AI 记忆系统缺失的层次。多数方案只实现了存储和检索——相当于只有记和取没有对记忆本身的管理。OpenClaw 通过 Weibull 衰减控制遗忘速率 三级晋升评估记忆重要性 六步清理执行记忆淘汰实现了计算意义上的元记忆——系统不仅能记还知道什么值得记、什么应该忘。这是从记忆数据库到记忆系统的关键跨越。现在让我们逐层展开。2.2.1 Session Memory 关键机制Session Memory 是离用户最近、更新最频繁的一层。每次你和 Agent 对话原始消息就逐条写入 JSONL 文件——这是记忆系统的第一手数据源。Session Model 的隔离设计谁的记忆这个问题在多用户、多渠道、多 Agent 场景下变得异常复杂。OpenClaw 通过三个维度来唯一标识一个会话每个会话由agentId channelId peerId唯一标识三种隔离粒度供选择per-agent所有人共享同一个会话适用于公开 Agentper-channel-peer推荐每个用户在每个渠道有独立会话per-account-channel-peer同一个人在不同账号下也独立最严格identityLinks反过来同一用户在 Telegram / Discord / WhatsApp 上的账号可以合并为一个身份让记忆在渠道间打通dmScope→ Direct Message 作用域配置决定记忆边界——配置不当可导致 A 用户看到 B 用户的对话历史详见第五章 F7这套隔离模型的设计哲学是默认安全显式开放——默认每人一份记忆想共享得主动配置。会话生命周期管理会话不是永远存在的。OpenClaw 提供了丰富的生命周期控制自动重置Daily Reset每日凌晨清空/ Idle Reset空闲超时重置/ 双条件触发手动重置/new新建会话//reset清空当前会话 自定义触发词群聊激活mention gating需 Agent/ reply tags需回复 Agent 消息——避免群聊中的每条消息都填充 Agent 的上下文窗口分渠道策略覆盖resetByType按消息类型/resetByChannel按渠道——Slack 可以设为日重置WhatsApp 设为周重置Session PruningLLM 调用前的智能减法[成本]上下文窗口总会被填满。当它接近容量上限时Pruning 机制自动执行减法腾出空间给新内容策略行为信息保真度cache-ttl模式与 Anthropic prompt caching 联动保留缓存窗口内的内容高仅移除缓存外Soft-trim保留头部 尾部中间省略并附注原始大小中丢失中间细节Hard-clear整体替换为占位符[toolResult pruned]低仅保留存在标记关键约束只修剪toolResult工具调用结果用户消息和助手消息不可动。包含图片 block 的toolResult也跳过。toolResult 与记忆的交互一个常见问题是Pruning 会不会把重要信息丢掉。答案是不会——因为agent_end钩子在 Pruning之前触发值得记住的 toolResult 内容已经被 Smart Extraction 提取到向量库了。Pruning 删除的是窗口内的副本不是记忆本身。这两个管线的执行顺序是精心设计的。上下文摘要化当 Pruning 还不够用或者你想主动压缩上下文时/compact命令将旧上下文摘要为精简版释放窗口空间Pre-compaction Memory Flush压缩之前先让模型将值得保存的内容写入 Workspace 持久笔记——确保压缩不丢失关键信息。这是一个非常巧妙的设计先存档再压缩两步操作顺序不可颠倒。Session Maintenance 六步清理流程[成本]长期运行的 Session 数据通过 6 步自动维护防止磁盘被历史对话填满prune stale— 按时间淘汰过期条目cap count— 按数量上限淘汰最旧条目archive transcript— 为已移除条目归档 JSONL 转录文件可追溯purge archives— 清理超龄归档rotate store— sessions.json 超限时自动轮转enforce disk budget— 硬性磁盘预算约束可配置上限这六步形成了一条从软清理到硬约束的梯度管线。大多数时候只需前两步就能保持 Session 规模可控最后一步是兜底安全阀。2.2.2 Workspace Memory 关键机制如果说 Session Memory 是短暂的工作台Workspace Memory 就是长久的书架。它由一组 Markdown 文件组成每次 LLM 调用时自动注入系统提示词——Agent 不需要检索就能知道这些内容。四大注入文件的角色划分文件角色典型内容AGENTS.md行为指令与能力声明“使用 tabs 缩进”、“回复用中文”SOUL.md人格、语气、价值观“你是一个专业但友好的助手”TOOLS.md工具使用偏好与限制“优先使用 ripgrep 而非 grep”USER.md用户画像与偏好“用户是全栈开发者偏好 PostgreSQL”这四个文件的内容不需要通过检索来获取——它们每次调用都会完整注入。这意味着写在AGENTS.md里的偏好是确定性生效的而存在向量库里的记忆是概率性召回的。这个区别至关重要第三章路径 B 会详细分析。Agent 自我修改 热重载这是 OpenClaw 最不寻常的特性之一Agent 可以改写自己的指令文件。Agent 通过文件读写工具直接编辑上述四个文件Gateway 检测文件变更 → 触发热重载 →所有会话立即生效并发安全Gateway 作为单一写入协调者防止多 Agent 同时改同一文件想象一下你在 Telegram 上告诉 Agent “以后用 tabs 不要 spaces”Agent 自己把这条偏好写进AGENTS.md热重载后你在 Slack 上发起的新对话里 Agent 已经默认使用 tabs 了。不需要你重复说不需要检索找回——它成为了 Agent 的本能。记忆可观测性[可控性]“Agent 到底记住了什么”——这个问题在大多数 AI 产品中是一个黑箱。OpenClaw 的设计哲学是让记忆完全可观测所有 Workspace 文件是纯 Markdown可用任何编辑器查看和编辑JSONL 转录文件可直接cat/grep/jq查询memory-lancedb-pro支持通过 Agent 对话查询已存储的记忆“你记住了什么关于我的数据库偏好”回滚路径Workspace 文件支持 git 版本控制cd ~/.openclaw/workspace git initAgent 写错了可以git revert向量记忆目前不支持时间点回滚但可通过 scope category 过滤后批量删除2.2.3 Plugin Memory 关键机制第三层是最深的记忆——向量数据库存储通过检索召回容量理论上无限。这也是记忆系统最复杂、最具技术含量的一层。插件 Slot 架构OpenClaw 的记忆层不是写死的而是可插拔的plugins.slots.memory记忆插槽可热插拔→ 不需要重启 Gateway 就能切换记忆实现生命周期钩子体系——这些钩子定义了记忆插件与 Agent 的交互时机before_prompt_build召回记忆注入上下文最关键的记忆钩子agent_end捕获新记忆after_tool_call/message_received/before_message_writeapi.on()vsapi.registerHook()的区别前者是事件监听可多个后者是钩子注册单一拦截点这种设计意味着你可以把默认的memory-lancedb替换成社区的memory-lancedb-pro整个记忆策略就从基础向量搜索升级到8 步混合检索管线——而 Agent 代码一行不动。多 Agent 记忆隔离[隐私]当你运行多个 Agent 时它们的记忆关系是怎样的Workspace 文件默认所有 Agent 共享——因为它们在同一个 workspace 目录下。这是有意的设计所有 Agent 都应该了解同一个USER.md你的偏好保持行为一致。Plugin Memory 通过scope字段隔离——每个 Agent 只能读写自己 scope 内的向量记忆。这也是有意的金融 Agent 的交易记忆不该被闲聊 Agent 读到。跨 Agent 共享需要显式配置将scope设为共享级别或使用 Workspace 文件作为跨 Agent 通信通道。设计取舍很清晰Workspace 共享有利于一致性Plugin 隔离有利于安全。社区方案生态OpenClaw 的记忆生态不是一个方案独大而是多方案并存、各有所长项目Star定位与内置方案的关键差异memory-lancedb-pro3.6k生产级混合检索 衰减Cross-Encoder Weibull L0/L1/L2 分层memU13k24/7 主动式记忆双 Agent 架构 预测式记忆graph-memory—知识图谱记忆实体关系建模 多跳推理MemOS7.8k跨任务技能记忆技能迁移 任务图谱EverMemOS3.2k省 Token 的记忆 OSToken 优化 记忆压缩关于 memory-lancedb vs memory-lancedb-pro目前缺乏公开的 A/B 基准对比数据。从架构差异看pro 版增加了 Cross-Encoder 精排、Weibull 衰减、L0/L1/L2 分层存储和两阶段去重——这些在 IR信息检索领域有成熟的理论支撑但具体在 OpenClaw 记忆场景中的量化提升社区尚未发布正式 benchmark。本文基于架构分析而非实测数据。memory-core 演进信号值得关注的是官方正在进行的重构memory-core extension将社区验证的最佳实践收编为核心模块memory host SDK为第三方插件提供统一的记忆宿主接口方向很清晰——从插件提供记忆到平台内置记忆。这和 Linux 内核的演化路径一模一样社区模块足够成熟后被收编进上游。2.3 三个层级的所有权边界一个容易混淆的问题哪些能力是 OpenClaw平台提供的哪些是内置方案哪些是社区增强厘清这一点对技术选型至关重要。能力提供者能否替换Session 管理、JSONL 存储、会话生命周期OpenClaw 平台否核心基础设施Workspace 文件、热重载、Agent 自修改OpenClaw 平台否核心基础设施plugins.slots.memory插槽机制OpenClaw 平台否框架层memory-lancedb基线向量记忆内置方案是可替换为社区插件memory-lancedb-pro混合检索衰减社区增强(3.6k Star)是plugin slot 热插拔memU24/7 主动式记忆社区增强(13k Star)是graph-memory/MemOS/EverMemOS等社区增强是So WhatOpenClaw 平台保证了记忆的底座存储、隔离、注入、钩子而将记忆的策略提取什么、如何检索、怎样衰减开放给生态。这就像操作系统提供文件系统 API具体实现由 ext4 / ZFS / Btrfs 竞争优化。你可以从最简单的内置方案开始随着需求增长逐步升级到社区插件——迁移成本为零因为接口不变。[可控性]下一章架构讲完了是什么第三章将以一条具体记忆的生命旅程为叙事线讲透怎么运作——从你说出一句话到这句话变成三个月后可以被召回的永久记忆中间那 8 步到底发生了什么。