OpenClaw中Session自动清理实践指南

处理OpenClaw中Session自动清理实践指南这类问题时，先确认目标场景，再按步骤核对配置或玩法细节。

问题的起源

某天下午，我发现我的 AI 助手越来越"迟钝"——一个简单的问题，从发送到回复，等了将近 86 秒。

翻了翻日志，找到了罪魁祸首：上下文长度 122k tokens。

这是因为 AI Agent 的每一次对话都会被记录到 session transcript 文件中。随着时间累积，这个文件越来越大，每次推理都要把整个历史塞进模型的上下文窗口，推理时间自然指数级增长。

这就是 长上下文问题（Long Context Problem），是 AI Agent 生产运营中最容易被忽视的性能瓶颈之一。

先搞清楚：Session 和 Transcript 是什么关系

在 OpenClaw 这类 AI Agent 框架里，session 管理通常分两层：

sessions.json (索引层)

├── agent:main:feishu-xxx → sessionFile: /path/to/transcript-abc.json

├── agent:main:feishu-yyy → sessionFile: /path/to/transcript-def.json

└── agent:main:main → sessionFile: /path/to/transcript-main.json

1. sessions.json — 轻量的"索引文件"，记录每个 session 的元数据（创建时间、最后更新时间、对应的文件路径等）
2. transcript 文件 — 实际存储完整对话历史的 JSON 文件，每条消息、每次 tool call、每个 token 都在这里

关键点：这两个东西是独立存在的。

如果你只删了 sessions.json 里的 key（索引），而没有删对应的 transcript 文件（数据），会发生什么？

1. 下次启动时，框架找不到这个 session 的索引，会重新创建
2. 但旧的 transcript 文件还静静躺在磁盘上，永远不会被清理
3. 随着时间推移，磁盘上堆满了孤儿文件，慢慢侵蚀存储空间

这就是为什么清理要同时处理 key 和 file，缺一不可。

解决方案：自动化清理脚本

我写了一个 Bash + Node.js 混合脚本来处理这个问题：

#!/usr/bin/env bash# 清理 Feishu session + Main session 脚本set -eSESSIONS_FILE="/home/water/.openclaw/agents/main/sessions/sessions.json"THRESHOLD_MS=$((24 * 60 * 60 * 1000))  # 24 小时阈值

核心逻辑（Node.js 内嵌）

const data = JSON.parse(fs.readFileSync(SESSIONS_FILE, 'utf8'));const now = Date.now();Object.keys(data).forEach(k => {  if (!k.includes('feishu')) return;  // 只处理 feishu sessions  if (k.includes('cron')) return;      // 跳过 cron sessions  const session = data[k];  const updatedAt = session.updatedAt || session.createdAt || 0;  const age = now - updatedAt;  if (age > threshold) {    // ① 先删文件    const sessionFile = session.sessionFile;    if (sessionFile && fs.existsSync(sessionFile)) {      fs.unlinkSync(sessionFile);    }    // ② 再删索引    delete data[k];    deleted++;  }});// 写回索引文件fs.writeFileSync(SESSIONS_FILE, JSON.stringify(data, null, 2));

注意操作顺序：先删文件，再删索引。 反过来的话，如果删完索引时进程崩溃，文件就变成永久孤儿了。

特殊处理：Main Session 每日强制重置

除了 Feishu session，我还对 main session 做了无条件的每日清理：

const mainKey = 'agent:main:main';if (data[mainKey]) {  const sessionFile = data[mainKey].sessionFile;  if (sessionFile && fs.existsSync(sessionFile)) {    fs.unlinkSync(sessionFile);  }  delete data[mainKey];}

这里不判断年龄，直接删。理由是：

1. Main session 是日常对话的主 session，积累最快
2. 每天重置一次，保持上下文干净，推理速度稳定
3. 重要信息通过 MEMORY.md 持久化，不依赖对话历史

重启 Gateway

清理完 sessions.json 后，需要重启 Gateway 让变更生效：

pkill -f openclaw-gateway || truesleep 2nohup openclaw-gateway >> "$LOG_FILE" 2>&1 &sleep 3

这里用 || true 避免 pkill 找不到进程时退出码非零触发 set -e。

自动化：配置 Cron Job

把这个脚本配成每天定时跑，完全不用人工介入：

{  "name": "Daily Feishu Session Cleanup",  "schedule": { "kind": "cron", "expr": "0 14 * * *", "tz": "Asia/Shanghai" },  "sessionTarget": "isolated",  "payload": {    "kind": "agentTurn",    "message": "Run the Feishu session cleanup script and report results",    "timeoutSeconds": 120  },  "delivery": { "mode": "announce", "channel": "feishu" }}

几个设计要点：

1. sessionTarget: isolated — 在隔离 session 里跑，不污染主 session
2. kind: agentTurn — 让 Agent 执行脚本并汇总结果，通过 Feishu 推送
3. 每天 14:00 — 下午低峰期执行，避免影响正常使用

坑点：sessionTarget: main 只支持 payload.kind = systemEvent（直接执行，无 LLM）。需要 LLM 汇报 + 推送通知，必须用 isolated + agentTurn，混用会超时或无推送。

效果对比

响应时间从最差 86 秒降回 3-8 秒，体感差别非常明显。

延伸思考：AI Agent 的"记忆管理"

这个问题本质上是 AI Agent 的工作记忆（Working Memory）vs 长期记忆（Long-term Memory）的分离问题。

1. 对话 session / transcript = 工作记忆，应该短暂且聚焦
2. MEMORY.md / 知识库 = 长期记忆，存真正重要的决策和知识

很多人在部署 AI Agent 时，会默认让它"记住一切"，结果把工作记忆当成了永久存储，导致上下文爆炸。

正确的做法是：

1. 定期蒸馏——把对话中有价值的信息提炼写入长期记忆
2. 定期清理——工作记忆不需要无限堆积
3. 分层存储——工作 session、日志、知识库各司其职

这和人类的记忆机制其实很像——你不会把每天说过的每句话都记着，但重要的决定、学到的知识会留下来。

总结

一个简单的 cron 清理脚本，解决了 AI Agent 最常见的性能退化问题。关键点：

1. 同时删 key 和 file，避免磁盘泄漏
2. 先删文件再删索引，保证原子性
3. Main session 每日强制重置，保持上下文干净
4. 自动化 + 通知，完全无人值守

如果你也在跑 AI Agent，不妨检查一下你的 session 文件有多大——也许已经悄悄堆了几十 MB 的历史对话了