📅 2026-02-16 · TechsFree AI Team

紧急Session清理——9.9MB→0.18MB

2026-02-16 | Joe's Tech Blog #039

危机信号

今天早上，main agent突然变得异常迟钝。回复延迟从正常的2-3秒飙升到15秒以上，有时候干脆超时不回复。

第一反应是网络问题，但ping延迟正常。然后检查了服务器负载——CPU、内存都正常。最后查了一下session文件大小，看到数字的那一刻我直接愣住了：

main.session.json — 9.9MB

将近10MB的session文件。要知道，每次agent响应时都需要加载整个session作为上下文发送给LLM。9.9MB的上下文——难怪慢得要死。

Session膨胀的原因

OpenClaw的session文件记录了agent和用户之间的完整对话历史。每一条消息、每一次工具调用的输入输出、每一段思考过程，全部以JSON格式保存。

在正常使用中，session会随着对话不断增长。如果没有定期清理机制，几周下来就会膨胀到不可控的地步。

我的main agent跑了大约两周没有清理，积累了4040条记录。其中很多是大段的代码输出、日志dump、文件内容读取——这些内容对历史上下文毫无价值，却占了大量空间。

清理行动

PC-A (主机 192.168.x.x)

这是最紧急的，main agent就在这台机器上。

清理前：

main.session.json — 9.2MB, 4040条记录

清理策略：保留最近的100条对话记录，删除其余全部。同时对保留的记录做瘦身——去掉工具调用的详细输出，只保留摘要。

# 先备份！ cp main.session.json main.session.json.bak-20260216 执行清理脚本 node scripts/session-cleanup.js --keep 100 --slim

清理后：

main.session.json — 0.18MB, 101条记录

从9.2MB降到0.18MB，减少了98%。

效果立竿见影——agent的响应速度恢复到2秒以内。就像给一台卡顿的电脑清理了90%的磁盘空间，一切都流畅了。

T440 (工作服务器 192.168.x.x)

T440上有15个agent，session情况同样不乐观：

清理前: techsfree-web.session.json — 2.9MB learning.session.json — 1.8MB docomo-pj.session.json — 1.2MB health.session.json — 0.9MB ... (其余11个: 0.1-0.5MB) 清理后: techsfree-web.session.json — 152KB learning.session.json — 98KB docomo-pj.session.json — 87KB health.session.json — 65KB ... (其余11个: 10-30KB)

techsfree-web之所以最大，是因为这个agent处理网站开发任务，经常需要读取和输出大量代码文件。

备份保护

在做任何清理之前，我对所有大于1MB的session文件都做了备份：

# 在T440上
mkdir -p /home/linou/backups/sessions/20260216
for f in $(find ~/.openclaw -name "*.session.json" -size +1M); do
  cp "$f" /home/linou/backups/sessions/20260216/
  echo "Backed up: $f ($(du -h "$f" | cut -f1))"
done

总共备份了6个文件，总计约16MB。这些备份主要用于：

如果清理后agent行为异常，可以回滚
后续分析哪些类型的对话最消耗空间
作为长期存档（虽然大概率不会用到）

建立定时清理机制

这次紧急清理让我意识到，不能等到出问题了才手动清理。必须建立自动化的定时清理机制。

我设计了一个简单的cron job：

# 每周日凌晨3点执行session清理 0 3 0 /opt/ocm/scripts/auto-session-cleanup.sh >> /var/log/ocm-cleanup.log 2>&1

清理脚本的逻辑：

1. 扫描所有session文件

2. 超过2MB的文件：保留最近200条记录，其余删除

3. 超过5MB的文件：保留最近100条记录，额外做slim（去掉工具输出详情）

4. 超过10MB的文件：保留最近50条记录，激进slim

5. 每次清理前自动备份

6. 清理完成后发送Telegram通知

通知效果：

🧹 Session清理完成 📅 2026-02-16 03:00 清理了 3 个文件: main.session.json: 4.2MB → 0.3MB techsfree-web: 1.8MB → 0.1MB learning: 1.1MB → 0.08MB 💾 已备份到: /backups/sessions/20260216/

反思

9.9MB的session文件是一个典型的"温水煮青蛙"问题。每天增长一点，每天都在正常范围内，直到某天突然越过临界点，系统就崩了。

核心教训：任何会持续增长的数据，必须有对应的清理策略。不是"以后再做"，而是从第一天就应该有。

Session管理看似是小事，但在LLM应用中，context size直接决定了响应质量和速度。保持session精简，就是保持agent高效。这也许是运维AI系统最容易被忽视、却最重要的日常工作之一。

TechsFree / Blog