夜雨聆风摘要
在使用 OpenClaw 构建自动化系统时，开发者经常会遇到 Gateway 进程内存持续增长直至 OOM 崩溃的问题。本文深入分析了该问题的根本原因——agentTurn 模式的 session 管理机制缺陷，并提出了基于 systemEvent 的零内存泄漏解决方案。
关键词：OpenClaw, 内存泄漏, agentTurn, systemEvent, Node.js, V8
1. 问题现象
1.1 典型症状
在长期运行 OpenClaw Gateway 的生产环境中，我们观察到以下现象：
Gateway 进程内存占用持续增长，数小时至数天后触发 OOM 系统日志出现 FatalProcessOutOfMemory错误Gateway 服务异常退出，状态码 6/ABRT重启后短期内恢复正常，随后再次累积增长
1.2 环境特征
该问题在以下场景尤为明显：
高频定时任务（间隔 < 30 分钟） 使用 agentTurn模式的 cron 任务内存受限的运行环境（< 4GB）
2. 根因分析
2.1 OpenClaw 定时任务架构
OpenClaw 的 cron 调度系统支持两种任务执行模式：
systemEvent | main | ||
agentTurn | isolated |
2.2 agentTurn 的 session 生命周期
agentTurn 模式的完整执行流程：
Cron Trigger ↓Create Isolated Session ↓Initialize AI Context ↓Execute Task (AI reasoning + tool calls) ↓Mark Session Completed ↓Session History Persisted to sessions.json ↓[Session metadata retained indefinitely]2.3 内存泄漏机制
核心问题：session 元数据永久累积
OpenClaw 将每个 session 的完整元数据持久化到 sessions.json：
{ "sessions": [ { "id": "uuid-1", "createdAt": 1775362485985, "status": "completed", "context": {...}, "messages": [...], "toolCalls": [...] }, { "id": "uuid-2", "createdAt": 1775362647123, "status": "completed", ... } // ... 持续增长 ]}Node.js 内存模型影响：
sessions.json在 Gateway 启动时加载到内存 文件持续增长 → 内存占用线性增长 V8 堆内存达到上限（默认 ~1.4GB）→ OOM
2.4 量化分析
在典型的高频任务场景下：
3. 解决方案
3.1 方案一：systemEvent 模式（推荐）
设计原则：避免创建 AI session，直接执行系统命令
配置示例：
{ "name": "data-processor", "schedule": { "kind": "every", "everyMs": 1800000 }, "sessionTarget": "main", "payload": { "kind": "systemEvent", "text": "python3 /path/to/script.py" }}内存特征：
不创建 isolated session 不写入 sessions.json 内存占用恒定
3.2 方案二：session 元数据清理
对于必须使用 agentTurn 的场景，实施主动清理：
#!/usr/bin/env python3"""Session 元数据清理脚本建议作为每日定时任务执行"""import jsonimport timefrom pathlib import PathSESSIONS_FILE = Path("/path/to/sessions.json")RETENTION_DAYS = 3def cleanup_sessions(): if not SESSIONS_FILE.exists(): return with open(SESSIONS_FILE, 'r') as f: data = json.load(f) cutoff_ms = (time.time() - RETENTION_DAYS * 86400) * 1000 original_count = len(data.get('sessions', [])) data['sessions'] = [ s for s in data['sessions'] if s.get('createdAt', 0) > cutoff_ms ] removed = original_count - len(data['sessions']) # 原子写入 temp_file = SESSIONS_FILE.with_suffix('.tmp') with open(temp_file, 'w') as f: json.dump(data, f) temp_file.replace(SESSIONS_FILE) print(f"Cleaned {removed} sessions, retained {len(data['sessions'])}")if __name__ == "__main__": cleanup_sessions()3.3 方案三：外部消息通道
当 systemEvent 需要发送消息通知时，绕过 OpenClaw 的 message 工具，直接使用外部 API：
飞书 Bot 示例：
import requestsimport jsonclass FeishuNotifier: def __init__(self, app_id, app_secret, user_id): self.app_id = app_id self.app_secret = app_secret self.user_id = user_id self.base_url = "https://open.feishu.cn/open-apis" self._token = None self._token_expire = 0 def _get_token(self): if self._token and time.time() < self._token_expire - 300: return self._token resp = requests.post( f"{self.base_url}/auth/v3/tenant_access_token/internal", json={"app_id": self.app_id, "app_secret": self.app_secret} ) data = resp.json() self._token = data["tenant_access_token"] self._token_expire = time.time() + data["expire"] return self._token def send_message(self, text, image_path=None): token = self._get_token() # Upload image if provided image_key = None if image_path: with open(image_path, 'rb') as f: resp = requests.post( f"{self.base_url}/im/v1/images", headers={"Authorization": f"Bearer {token}"}, files={"image": f}, data={"image_type": "message"} ) image_key = resp.json()["data"]["image_key"] # Build message content = {"text": text} if image_key: content = { "zh_cn": { "title": "System Alert", "content": [ [{"tag": "text", "text": text}], [{"tag": "img", "image_key": image_key}] ] } } # Send requests.post( f"{self.base_url}/im/v1/messages", headers={"Authorization": f"Bearer {token}"}, params={"receive_id_type": "open_id"}, json={ "receive_id": self.user_id, "msg_type": "post" if image_key else "text", "content": json.dumps(content) } )4. 最佳实践
4.1 架构设计原则
┌─────────────────────────────────────────┐│ Task Frequency ││ High ──────────────────► Low ││ │ │ ││ ▼ ▼ ││ ┌─────────────┐ ┌─────────────┐ ││ │ systemEvent │ │ agentTurn │ ││ │ (Direct) │ │ (AI-based) │ ││ └─────────────┘ └─────────────┘ ││ │ │ ││ ▼ ▼ ││ Zero memory leak Rich AI context │└─────────────────────────────────────────┘4.2 决策矩阵
systemEvent | ||
systemEvent | ||
systemEvent | ||
agentTurn | ||
agentTurn |
4.3 监控指标
建议对以下指标进行监控：
# sessions.json 大小监控import osSESSIONS_FILE = "/path/to/sessions.json"size_mb = os.path.getsize(SESSIONS_FILE) / 1024 / 1024if size_mb > 50: # 阈值 alert(f"sessions.json too large: {size_mb:.1f} MB")# Gateway 内存监控import psutilprocess = psutil.Process(gateway_pid)mem_mb = process.memory_info().rss / 1024 / 1024if mem_mb > 1000: # 阈值 alert(f"Gateway memory high: {mem_mb:.1f} MB")5. 总结
OpenClaw 的 agentTurn 模式虽然提供了强大的 AI 能力，但在高频定时任务场景下存在固有的内存泄漏风险。其根本原因在于 session 元数据的永久累积，而非 session 本身未被销毁。
通过迁移到 systemEvent 模式，并结合外部消息通道（如飞书、钉钉等支持 Webhook 的平台），可以实现零内存泄漏的自动化系统。对于必须使用 agentTurn 的场景，应实施定期的 session 元数据清理策略。
核心建议：
默认使用 systemEvent，除非明确需要 AI 能力避免高频（< 30 分钟）的 agentTurn任务实施 sessions.json大小监控和自动清理考虑使用外部消息通道替代 OpenClaw 内置工具
参考
OpenClaw Documentation: https://docs.openclaw.ai Node.js Memory Management: https://nodejs.org/en/docs/guides/memory-management V8 Garbage Collection: https://v8.dev/blog/trash-talk
本文基于 OpenClaw 2026.3.11 版本的技术实践