二、为什么是 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 Memory（LanceDB）作为嵌入式数据库同样持久化在磁盘。24/7 承诺的前提是"宕机可恢复"而非"永不宕机"——这是工程诚实。
So What：没有 24/7 的在场能力，记忆根本没有输入源。封闭在 App 内的助手只能记住你在 App 里说的话。OpenClaw 通过全渠道接入，获得了你在所有数字场景中的上下文——这是丰富记忆的物理前提。[召回率]
多语言注意事项：跨渠道记忆在多语言场景下依赖 Embedding 模型的跨语言能力。OpenAI
text-embedding-3-small对中英文混合检索表现良好，但小语种之间的跨语言召回可能衰减。如果你在 Telegram 说英文、微信说中文，同一主题的记忆能否互通，取决于 Embedding 模型对这两种语言的语义空间对齐程度。
2.2 三层记忆架构总览
本节只讲"是什么"和"为什么这么分层"。技术细节在第三章的记忆生命旅程中展开。
理解 OpenClaw 记忆系统的关键是理解它的分层。不是一个向量数据库就完事了——不同类型的信息需要不同的存储策略、不同的生命周期、不同的访问模式。就像人类不会把"今天的早餐"和"毕生的技能"存在同一个大脑区域一样。
从上面的架构图可以看到，信息在三层之间的流动是双向的：从 Session 流向 Workspace 和 Plugin 实现持久化，又从 Workspace 和 Plugin 流回 Session 实现召回。这对应人类的记忆巩固与提取过程：你在对话中（工作记忆）学到的东西，入睡后经过巩固进入长时记忆，未来需要时再提取回工作记忆使用。
下表量化了三层的关键差异：
| 层级 | 认知科学角色 | 存储形式 | 生命周期 | 信息保真度 | 容量 |
|---|---|---|---|---|---|
| Session | 工作记忆 | JSONL 转录 | 会话级（小时~天） | ~100%（原始对话逐字记录） | 有限（受上下文窗口约束） |
| Workspace | 陈述性长时记忆 | Markdown 文件 | 永久（手动/Agent 编辑） | ~80%（结构化提炼，丢失对话语气） | 中（每文件数 KB） |
| Plugin | 程序性长时记忆 | 向量数据库 | 永久（Weibull 衰减） | ~2%–40%（L0 索引 ~2%，L2 完整叙述 ~40%） | 高（数万条+） |
认知科学对照表（§1.4 预告的完整版）：
| 人类记忆系统 | 特征 | OpenClaw 对应 | 映射理由 |
|---|---|---|---|
| 感觉记忆(Sensory) | 毫秒级暂存、快速衰减 | 实时消息流（未处理的原始输入） | 信息还未进入处理管线 |
| 工作记忆(Working) | 秒~分钟级、7±2 项容量 | Session Context（上下文窗口） | 有限容量、活跃处理 |
| 短时记忆(Short-term) | 分钟~小时级、需复述维持 | Session Pruning +/compact摘要 | 信息压缩以延长留存 |
| 长时 · 陈述性(Declarative) | 可言说的事实与事件 | Workspace Memory（4 注入文件） | 显式可读的持久知识 |
| 长时 · 程序性(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：所有人共享同一个会话（适用于公开 Agent）per-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 Pruning：LLM 调用前的智能减法[成本]
上下文窗口总会被填满。当它接近容量上限时，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 init），Agent 写错了可以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_write
api.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-pro | 3.6k | 生产级混合检索 + 衰减 | +Cross-Encoder +Weibull +L0/L1/L2 分层 |
memU | 13k | 24/7 主动式记忆 | +双 Agent 架构 +预测式记忆 |
graph-memory | — | 知识图谱记忆 | +实体关系建模 +多跳推理 |
MemOS | 7.8k | 跨任务技能记忆 | +技能迁移 +任务图谱 |
EverMemOS | 3.2k | 省 Token 的记忆 OS | +Token 优化 +记忆压缩 |
关于 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 热插拔） |
memU（24/7 主动式记忆） | 社区增强(13k Star) | 是 |
graph-memory/MemOS/EverMemOS等 | 社区增强 | 是 |
So What：OpenClaw 平台保证了记忆的底座（存储、隔离、注入、钩子），而将记忆的策略（提取什么、如何检索、怎样衰减）开放给生态。这就像操作系统提供文件系统 API，具体实现由 ext4 / ZFS / Btrfs 竞争优化。你可以从最简单的内置方案开始，随着需求增长逐步升级到社区插件——迁移成本为零，因为接口不变。[可控性]
下一章：架构讲完了"是什么"，第三章将以一条具体记忆的生命旅程为叙事线，讲透"怎么运作"——从你说出一句话，到这句话变成三个月后可以被召回的永久记忆，中间那 8 步到底发生了什么。
