OpenClaw Session 机制详解：重置、压缩、剪枝与记忆管理

关键理解：

• Session Key 是固定的，决定消息路由到哪个"桶"
• Session ID 会变，每次重置就换一个新的 JSONL 文件
• 重置 ≠ 删除——旧 JSONL 文件还在磁盘上，只是模型不再读取

Session Key 的生成规则

私聊的 dmScope 模式

这个配置决定了不同渠道的私聊是否共享同一个 Session：

💡 如果你用的是默认 main 模式，飞书私聊和 webchat 私聊会共享同一个 session。

存储位置

~/.openclaw/agents/<agentId>/sessions/
├── sessions.json ← Session 元数据（Key → ID 映射）
├── abc123.jsonl ← 当前对话记录
├── def456.jsonl ← 旧对话记录（重置后留下的）
└── ghi789-topic-42.jsonl ← Telegram 话题会话 

第 2 章 · Session 生命周期——什么时候开始、什么时候结束

生命周期全景图

消息到达 │
▼
┌──────────────┐ 是 ┌──────────────┐
│ Session 过期？ │───────→│ 创建新 Session │
│ │ │ ID + JSONL │
└──────┬───────┘ └──────┬───────┘
│ 否 │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ 继续使用当前 │ │ 开始新对话 │
│ Session │ │（旧上下文丢失）│
└──────┬───────┘ └──────────────┘
│ ▼
[对话进行中] │
▼
┌──────────────┐ 是 ┌──────────────┐
│ 上下文快满了？ │───────→│ Memory Flush │
│ │ │（静默写日志） │
└──────┬───────┘ └──────┬───────┘
│ 否 │
▼ ▼
[继续对话] ┌──────────────┐ │
│ Auto-Compact │ ▼
│（压缩旧内容） │
┌──────────────┐ └──────────────┘
│ 上下文溢出？ │ │
│───→ 强制 Compact → 重试 └──────────────┘

三种重置触发方式

① 每日重置（默认启用）

{"session":{"reset":{"mode":"daily","atHour":4}}}

⚠️ 重点来了：不是到凌晨 4 点就立刻清空，而是下一条消息到来时才检查。

23:00 聊天 ──→ 凌晨 4:00（重置边界）──→ 早上 9:00 发消息 ──→ 💥 新 Session！
↑ 这时候才真正重置 

这就是我踩坑的根本原因——昨晚聊的内容，在今早第一条消息时被判定为"过期"，直接创建了新 Session。

② 空闲重置（可选）

{"session":{"reset":{"mode":"daily","atHour":4,"idleMinutes":120}}}

同时配置每日 + 空闲时，先到期的那个生效。

③ 手动重置

发送 /new 或 /reset 立即创建新 Session：

• /new claude-sonnet → 重置并切换模型
• 单独发 /new → 重置并发一条问候确认

按类型/渠道覆盖

不同场景可以设不同策略：

{"session":{"resetByType":{"dm":{"mode":"idle","idleMinutes":480},"group":{"mode":"idle","idleMinutes":120},"thread":{"mode":"daily","atHour":4}},"resetByChannel":{"discord":{"mode":"idle","idleMinutes":10080}}}}

优先级：resetByChannel > resetByType > reset（全局默认）

第 3 章 · Compaction（压缩）——上下文满了怎么办

为什么需要压缩？

每个模型有上下文窗口限制（比如 200k tokens）。聊久了，历史消息会撑满窗口。

压缩 = 把旧对话总结成摘要，腾出空间继续聊。

压缩 vs 重置

自动压缩触发条件

两种情况：

1. 溢出恢复：模型返回上下文溢出错误 → 压缩 → 重试
2. 阈值维护：成功回复后检查 contextTokens > contextWindow - reserveTokens

配置

{"compaction":{"enabled":true,"reserveTokens":16384,"keepRecentTokens":20000}}

压缩后模型看到什么？

┌─────────────────────────────────┐
│ [压缩摘要] │
│ "之前讨论了 A、B、C 三个话题..." │
├─────────────────────────────────┤
│ [保留的最近消息] │
│ 用户：xxx │
│ 助手：xxx │
│ 用户：xxx │
│ 助手：xxx │
└─────────────────────────────────┘

💡 手动压缩：发送 /compact 即可触发，还可以附带指令，比如 /compact 重点保留关于项目架构的讨论

第 4 章 · Session Pruning（剪枝）——省钱的隐形优化

剪枝 vs 压缩

为什么需要剪枝？

Anthropic 的提示缓存有 TTL（生存时间）。如果会话空闲超过 TTL，下次请求会重新缓存整个提示，很贵。剪枝在 TTL 过期后裁掉旧的工具结果，减少重新缓存的大小。

两个级别

工具结果（很大） │
▼
┌──────────────┐
│ 软修剪 │ 保留头尾，中间用 ... 替代 │
(Soft Trim) │
└──────┬───────┘
│ 如果还是太大 ▼
┌──────────────┐
│ 硬清除 │ 整个替换为占位符 │
(Hard Clear) │
"[Old tool result content cleared]" └──────────────┘

什么不会被剪枝？

• ❌ 用户消息——永不修改
• ❌ 助手消息——永不修改
• ❌ 包含图片的工具结果——跳过
• ❌ 最近 N 条助手消息之后的工具结果——受保护

配置

{"agent":{"contextPruning":{"mode":"cache-ttl","ttl":"5m","keepLastAssistants":3,"softTrim":{"maxChars":4000,"headChars":1500,"tailChars":1500},"hardClear":{"enabled":true,"placeholder":"[Old tool result content cleared]"}}}}

💡 智能默认值：如果你用的是 Anthropic 的 key，OpenClaw 会自动启用 cache-ttl 模式，不需要手动配。

第 5 章 · Memory（记忆）——跨 Session 的持久化方案

核心问题

Session 会重置、会压缩，模型的"记忆"是短暂的。Memory 系统就是解决"AI 失忆"的终极方案。

三层记忆架构

┌─────────────────────────────────────────────┐
│ 第 1 层：Session 上下文（最短暂） │
│ · 当前对话的消息历史 │
│ · 压缩后变摘要，重置后完全丢失 │
└─────────────────────────────────────────────┘
▼ 写入文件
┌─────────────────────────────────────────────┐
│ 第 2 层：Workspace 文件（持久） │
│ · MEMORY.md — 长期记忆 │
│ · memory/YYYY-MM-DD.md — 每日日志 │
│ · AGENTS.md, SOUL.md 等 — 注入系统提示 │
└─────────────────────────────────────────────┘
▼ 语义搜索
┌─────────────────────────────────────────────┐
│ 第 3 层：Memory Search（语义检索） │
│ · 基于 Embedding 的向量搜索 │
│ · 搜索 MEMORY.md + memory/*.md │
│ · 每次新 session 启动时可自动召回相关记忆 │
└─────────────────────────────────────────────┘

Workspace 文件注入

OpenClaw 会自动把 workspace 中的特定文件注入到系统提示中：

workspace/
├── AGENTS.md ← 工作规范（自动注入）
├── SOUL.md ← 人格定义（自动注入）
├── USER.md ← 用户信息（自动注入）
├── TOOLS.md ← 工具笔记（自动注入）
├── MEMORY.md ← 长期记忆（自动注入）
├── HEARTBEAT.md ← 心跳任务（自动注入）
└── memory/
    ├── 2026-02-07.md ← 每日日志（需搜索读取）
    └── 2026-02-08.md

⚠️ 注入的文件会占用上下文窗口！MEMORY.md 太大会挤压对话空间。

压缩前记忆刷新（Memory Flush）⭐ 最聪明的设计

上下文使用量 │
███████████████████░░░░░░ ← 软阈值（flush 触发）
████████████████████████░ ← 硬阈值（compaction 触发）
█████████████████████████ ← 上下文窗口上限 

流程：

1. 上下文接近压缩阈值（但还没到）
2. OpenClaw 静默运行一轮，让模型把重要内容写入 memory/YYYY-MM-DD.md
3. 用户看不到这个过程
4. 然后正常触发压缩

{"agents":{"defaults":{"compaction":{"memoryFlush":{"enabled":true,"softThresholdTokens":4000}}}}}

⚠️ Memory Flush 的致命盲区

这就是"失忆"的根本原因：凌晨 4 点重置时，没有任何机制把昨晚的对话写入持久记忆。对话就这么没了。

第 6 章 · Session Tool——运行时的会话控制

常用命令

Send Policy（发送策略）

可以按规则阻止特定 session 的消息投递：

{"session":{"sendPolicy":{"rules":[{"action":"deny","match":{"channel":"discord","chatType":"group"}},{"action":"deny","match":{"keyPrefix":"cron:"}}],"default":"allow"}}}

第 7 章 · 实战：五个机制如何协同工作

一条消息的完整旅程

用户发送消息 │
▼
[1] Session 路由 │
根据来源生成 Session Key │
检查是否过期（每日/空闲/手动重置） │
过期 → 创建新 Session ID ▼
[2] 加载上下文 │
读取 JSONL 对话记录 │
注入 workspace 文件（MEMORY.md 等） │
如果有压缩摘要，从摘要开始 ▼
[3] Session Pruning（剪枝） │
检查缓存 TTL 是否过期 │
过期 → 裁剪旧工具结果（省钱） ▼
[4] 发送给模型 → 生成回复 ▼
[5] 回复后检查 │
接近阈值 → Memory Flush（静默写日志） │
超过阈值 → Auto-Compaction（压缩） ▼
[6] 投递回复 │
检查 Send Policy → 通过则发送 ▼
[7] 写入 JSONL + 更新 sessions.json ▼
✅ 完成 

记忆保持可靠性排行

 可靠性 ▲
手动写入文件 ────┤ ★★★★★ 最可靠，但需要主动操作
Memory Flush ───────┤ ★★★★ 压缩前自动触发，重置前不触发
Memory Search ──────┤ ★★★ 新 session 可召回，依赖搜索质量
Compaction 摘要 ────┤ ★★ 保留大意，丢失细节
纯靠 Session ───────┤ ★ 重置就没了
└──────────→ 自动化程度 

🏆 推荐配置组合

{"session":{"reset":{"mode":"daily","atHour":4,"idleMinutes":480}},"agents":{"defaults":{"compaction":{"memoryFlush":{"enabled":true,"softThresholdTokens":4000}},"memorySearch":{"enabled":true}}}}

📋 全文速查表

写在最后

OpenClaw 的 Session 体系设计得其实很精巧——重置保证干净、压缩保证连续、剪枝保证省钱、记忆保证持久。但如果你不了解这套机制，就会在某个早晨被"你好，请问有什么可以帮你？"当头一棒。

希望这篇文章能帮你少踩一个坑。