OpenClaw中Session自动清理实践指南

目录

• 问题的起源
• 先搞清楚：Session 和 Transcript 是什么关系
• 解决方案：自动化清理脚本
• 核心逻辑（Node.js 内嵌）
• 特殊处理：Main Session 每日强制重置
• 重启 Gateway
• 自动化：配置 Cron Job
• 效果对比
• 延伸思考：AI Agent 的"记忆管理"
• 总结

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

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

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

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

在 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

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

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

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

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

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

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

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

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));

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

除了 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];
}

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

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

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

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

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

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

{
  "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" }
}

几个设计要点：

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

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

指标	清理前	清理后
上下文长度	~122k tokens	< 5k tokens
平均响应时间	21-86 秒	3-8 秒
磁盘占用（sessions）	持续增长	每日重置

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

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

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

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

正确的做法是：

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

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

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

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

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

到此这篇关于OpenClaw中Session自动清理实践指南的文章就介绍到这了,更多相关OpenClaw自动清理Session内容请搜索风君子博客以前的文章或继续浏览下面的相关文章，希望大家以后多多支持风君子博客！