OpenClaw中Session自动清理配置与实践指南

时间：2026-08-21 | 作者：冻月看渠 | 阅读：0

问题的起源

某天下午，发现 AI 助手变得越来越"迟钝"了。

一个简单的问题，从发送到收到回复，足足等了将近 86 秒。

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

这其实是运行 AI Agent 时的一个经典陷阱。

每次对话都会被完整写进 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

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 小时阈值

核心逻辑（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];
}

这里不判断年龄，直接删。理由其实很充分：

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

重启 Gateway

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

pkill -f openclaw-gateway || true
sleep 2
nohup 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" }
}

几个设计要点很关键：