03 OpenClaw Session 与 Memory——多用户状态管理

原文：Session + Memory

Session：多渠道会话管理

核心挑战

Claude Code 的会话简单——一个终端一个会话。OpenClaw 面对的问题复杂得多：同一个 Agent 可能同时被 WhatsApp、Telegram、Slack 上的多个用户 @，每个对话需要隔离的上下文。

Session Key 格式

agent:<agentId>:<sessionKey>

sessionKey 由 dmScope 策略决定如何生成：

dmScope	隔离级别	适用
`main`	所有 DM 共享一个 session	单用户
`per-peer`	按发送者隔离	多用户基础
`per-channel-peer`	按 channel + 发送者隔离	推荐（多用户）
`per-account-channel-peer`	最细粒度	多账号多渠道

安全警告：不设隔离时，所有用户共享对话上下文——A 发的消息 B 能看到回复中的上下文。

存储

~/.openclaw/agents/<agentId>/sessions/
├── sessions.json       ← sessionKey → {sessionId, updatedAt} 映射
└── <sessionId>.jsonl    ← 对话记录（JSONL 格式）

会话重置策略

策略	默认值	说明
定时重置	每日 4:00 AM	每天清空，防止上下文无限膨胀
空闲重置	可选（`idleMinutes`）	空闲 N 分钟后重置
手动	`/new`、`/reset`	用户主动触发
按类型	`resetByType`	DM/群组/线程分别设置

维护（自动清理）

参数	默认值	作用
`pruneAfter`	30 天	删除过期条目
`maxEntries`	500	限制总条目
`rotateBytes`	10MB	sessions.json 滚动

Memory：文件即记忆

两层结构

层	文件	加载时机	用途
Daily Log	`memory/YYYY-MM-DD.md`	每次 session start	当天笔记（追加写）
Long-term	`MEMORY.md`	仅私有 session	持久偏好和决策

“文件是唯一的真相来源”——模型只”记住”写到磁盘上的东西。

Agent 工具

工具	作用
`memory_search`	向量语义搜索
`memory_get`	按文件/行范围精确读取

自动记忆刷新（Flush）

当 token 接近上下文限制时，OpenClaw 触发一个静默 Agent 轮次，让模型把重要记忆写入文件：

触发阈值：softThresholdTokens: 4000
默认开启
在 Compaction 之前运行

向量搜索

支持多种 Embedding 提供者（OpenAI、Gemini、Voyage、Mistral、Ollama、本地 GGUF），混合 BM25 + 向量搜索，MMR 多样性重排序。

与 Claude Code 的对比

	Claude Code	OpenClaw
Session 隔离	按 git repo + 目录	按 channel + peer + agent
自动重置	无（手动 /clear）	定时（每日 4am）+ 空闲
记忆存储	`~/.claude/projects/<proj>/memory/`	workspace 内 Markdown 文件
记忆加载	MEMORY.md 前 200 行	Daily log 全部 + MEMORY.md（仅私有 session）
语义搜索	无	向量搜索（多 provider）
记忆刷新	无（随会话自然写入）	Compaction 前自动 flush
维护	手动（/memory 编辑）	自动（prune + rotate）

关键洞察：OpenClaw 的记忆系统更”工业级”——自动清理、向量搜索、多用户隔离。代价是配置复杂度更高。

知识检测

概念理解题

为什么 OpenClaw 需要 dmScope 而 Claude Code 不需要？这反映了两种产品的什么根本差异？
“每日 4AM 自动重置”——这个设计决策的利弊是什么？什么场景下你会想关闭它？
OpenClaw 的 Memory Flush 在 Compaction 之前运行——为什么这个顺序很重要？如果反过来会怎样？

应用题

你要用 OpenClaw 搭建一个家庭共享 AI 助手，家里 4 个人通过 WhatsApp 和它聊天。设计 session 隔离策略，确保每个人的对话隐私。
你的 Agent 需要记住每个用户的饮食偏好。这个信息应该放在 Daily Log 还是 MEMORY.md 中？为什么？

迁移思考题

Claude Code 没有向量搜索记忆。如果给 Claude Code 加上这个能力，你会怎么设计？是作为内置功能还是 MCP Server？

参见

01-OpenClaw-Gateway-架构 — Session 存储在 Gateway 中
02-OpenClaw-Agent-Loop — Loop 如何使用 Session
SlipBox 相关：Session、Context Window、OpenClaw Session

参考答案

1. 为什么 OpenClaw 需要 dmScope

Claude Code 是单用户 CLI——终端里只有你一个人。OpenClaw 是多渠道服务——WhatsApp 群里可能有 10 个人都在 @ 你的 Agent。如果不隔离，A 问的问题会出现在 B 的回复上下文中（隐私泄露）。dmScope 本质上是 Web 开发中”session 隔离”的翻版——和 HTTP session 用 cookie 隔离不同用户的逻辑一样。

2. 每日 4AM 自动重置的利弊

利：防止 session 无限增长（一个 session 跑几周后消息历史巨大，compaction 效率下降、上下文质量降低）。弊：用户前一天的对话上下文丢失——如果你前一天和 Agent 讨论了一个复杂问题还没解决，第二天得重新说明背景。想关闭的场景：长期项目讨论（跨多天的技术方案设计）、Agent 需要”记住”用户长期偏好（这时应该用 MEMORY.md 而非 session 历史）。

3. Memory Flush 在 Compaction 之前的顺序

Compaction 会摘要对话——摘要过程中细节信息丢失。如果先 Compaction 再 Flush，模型要从已经摘要过（信息缺失）的上下文中提取记忆，质量会下降。先 Flush 确保模型在完整上下文中识别重要信息并写入磁盘，然后 Compaction 安全地摘要——即使摘要丢了细节，重要的东西已经保存到文件里了。

4. 家庭共享 AI 助手的 session 隔离

设置 dmScope: per-channel-peer——每个家庭成员的 WhatsApp 号码自动分配独立 session。这样每个人的对话互不可见。如果某些信息需要跨成员共享（如家庭日程），可以用一个共享的 Memory 文件（所有 session 都读取同一个 memory/family-schedule.md）。补充安全措施：设置 session.dailyReset: false（家庭场景不需要每天重置），设置 memory.longTerm: true（记住每个人的偏好）。

5. 饮食偏好放哪里

放 MEMORY.md（长期记忆），不是 Daily Log。原因：饮食偏好是长期稳定的信息（“不吃辣”不会每天变），Daily Log 是按天的临时笔记。MEMORY.md 在每次私有 session 开始时加载，确保 Agent 始终记得这个偏好。Daily Log 只加载当天的，昨天记的偏好今天就看不到了。

6. 给 Claude Code 加向量搜索

推荐作为 MCP Server 实现——创建一个 memory-search MCP Server，它 (1) 监控 ~/.claude/projects/<project>/memory/ 目录 (2) 对所有 memory 文件做 embedding 索引 (3) 提供 memory_search(query) 工具。这样不需要修改 Claude Code 核心，通过 MCP 即插即用。为什么不内置：向量搜索需要 embedding API（成本和隐私考虑），不是所有用户都需要，作为可选 MCP Server 更灵活。