1. OpenClaw 跑着跑着就没了一次凌晨三点的 OOM 崩溃复盘OpenClaw 是一个面向自动化任务编排与浏览器操作的执行框架能帮你把采集、截图、表单填写、多步 Agent 流程串成一条流水线适合在本地开发机或 CI 环境里长期跑批处理任务。它本身不挑硬件一台 8GB 内存的机器就能起步但很多人第一次把它挂上定时任务后都会遇到同一个场景进程在某个凌晨悄悄消失日志停在几小时前没有任何异常堆栈。我试过在一个 8GB 的云主机上跑一周的采集任务第二天早上ps aux | grep openclaw只剩下一行 grep 自己。翻日志最后一行停在 03:12之后什么都没有。这不是 OpenClaw 主动退出而是被系统 OOM Killer 直接 SIGKILL 掉了——进程连写遗言的机会都没有。这里有个反常识的点OpenClaw 的内存峰值往往只有 1GB 出头远低于物理内存上限为什么还会 OOM原因通常不在“内存总量不够”而在三件事上——临时文件被系统清理导致框架反复重试、浏览器实例内存不释放、会话上下文无限膨胀。这三条路径都会让 RSS 持续爬升最终撞上内核的 OOM 阈值。这篇文章按“先定位、再预防、后兜底”的顺序展开同时把 TaoToken 的统一 Key/API 通道配置一起讲清楚因为很多 OOM 其实是重试风暴引起的而重试风暴的源头是模型调用链路不稳定。把 API 通道收敛到一条稳定入口能直接砍掉一大块无效内存消耗。2. 先搞清楚 OOM 从哪来三类内存增长路径与排查命令在动手改配置之前先花十分钟确认你的 OpenClaw 到底属于哪一类内存增长。不同路径的解法完全不同盲目加 Swap 只会把崩溃时间往后推。2.1 用 ps 和 smem 定位 RSS 增长曲线最直接的办法是每隔一段时间采样一次进程内存。下面这个脚本我放在 crontab 里每 5 分钟跑一次输出到 CSV跑一天就能看出趋势#!/bin/bash # mem_watch.sh - OpenClaw 内存采样脚本 LOG/var/log/openclaw_mem.csv PID$(pgrep -f openclaw | head -n1) if [ -z $PID ]; then echo $(date %s),0,0,0 $LOG exit 0 fi RSS$(awk /VmRSS/{print $2} /proc/$PID/status) TMPCNT$(ls -1 /data/openclaw_temp 2/dev/null | wc -l) FDCNT$(ls /proc/$PID/fd 2/dev/null | wc -l) echo $(date %s),$RSS,$TMPCNT,$FDCNT $LOG跑完之后用 awk 看斜率awk -F, NR1{print $1, $2} /var/log/openclaw_mem.csv | \ awk {t$1-prev_t; m$2-prev_m; if(t0) print $1, m/t KB/s; prev_t$1; prev_m$2}如果 RSS 斜率稳定在几百 KB/s 以上基本可以判定是泄漏而不是正常波动。文件描述符数量同步上涨的话八成是临时文件或浏览器连接没关。2.2 三类增长路径的日志特征第一类是临时文件失控。OpenClaw 默认把中间结果写到/tmp而主流 Linux 的 systemd-tmpfiles 默认清理周期是 7200 秒。任务跑超过两小时文件可能被系统判定为垃圾删掉框架再去读就抛FileNotFoundError然后触发重试重试又生成新临时文件形成循环。日志里会看到大量FileNotFoundError和retry关键字。第二类是浏览器自动化泄漏。如果你用 OpenClaw 做页面采集Chromium 长时间运行后即使关闭页面内存也不释放。实测跑几小时后 RSS 能从 400MB 涨到 3GB 以上。日志特征不明显但ps里能看到多个 chrome 子进程残留。第三类是上下文膨胀。OpenClaw 默认会话 TTL 是 1 小时历史消息不清洗用户寒暄也会反复送进模型。一个 5 轮交互的客服场景内存峰值能到 4GB 左右。日志里表现为 token 消耗随时间线性增长。2.3 确认是不是 OOM Killer 干的dmesg -T | grep -i killed process journalctl -k | grep -i oom如果看到Out of memory: Killed process 12345 (openclaw)那就是内核级终止。如果日志里是FileNotFoundError堆栈那是框架级崩溃。两者解法不同前者要加资源限制和 Swap后者要修临时文件路径。3. TaoToken 前置把模型调用通道收敛成一条稳定入口很多 OpenClaw 的 OOM 不是内存本身的问题而是模型调用失败引发的重试风暴。每次调用失败框架会缓存失败上下文、创建临时文件记录状态、启动重试机制这些都是额外的内存开销。把 API 通道统一到 TaoToken能直接减少这类无效消耗。TaoToken 是一个统一的模型 API 网关把多家模型的 Key 收敛成一个入口适合在 OpenClaw 这类需要频繁切换模型的框架里使用。你只需要在配置里写一个 Base URL 和一个 Key就能调用多个模型不用为每个模型单独维护环境变量。3.1 获取 Key 与配置路径先去控制台创建一个 API Keyhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite拿到 Key 之后OpenClaw 的模型配置一般放在~/.openclaw/config.yaml或项目根目录的openclaw-config.yaml。下面是一份可直接复制的配置片段路径和字段名按 OpenClaw 常见约定写# ~/.openclaw/config.yaml model: provider: openai-compatible base_url: https://taotoken.net/api api_key: sk-你的TaoTokenKey model_id: claude-sonnet-4-20250514 timeout: 60 max_retries: 2 retry_backoff: 1.5如果你用的是 JSON 格式的配置比如 Codex 风格的auth.json对应写法是{ model: { provider: openai-compatible, base_url: https://taotoken.net/api, api_key: sk-你的TaoTokenKey, model_id: claude-sonnet-4-20250514, timeout: 60, max_retries: 2 } }三件套必须齐全Base URL 填https://taotoken.net/apiKey 填控制台生成的Model ID 填你要用的模型标识。少任何一个都会在启动时报401或model not found。3.2 为什么这能减少 OOM把max_retries从默认的 5 降到 2配合稳定的通道重试次数直接砍掉一半以上。每次重试都会在内存里保留一份请求上下文和临时文件句柄重试少了内存增长曲线就平缓了。另外统一入口之后你不用在多个环境变量之间切换减少了配置错误导致的启动失败循环。如果你需要长期跑编码类 Agent 任务可以考虑 Coding Plan它针对高频调用场景做了配额优化https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite4. 可复制配置临时文件、浏览器、上下文三层防御这一节是全文的核心操作部分三层配置都给出可直接粘贴的片段。建议按顺序改每改一层跑一次验证。4.1 临时文件迁移到独立目录第一步是把临时目录从/tmp挪到独立分区避开系统清理周期。在 OpenClaw 配置里加# openclaw-config.yaml storage: temp_dir: /data/openclaw_temp max_temp_files: 1000 cleanup_interval: 3600 cleanup_on_start: true然后创建目录并挂载独立分区如果没有独立盘至少换个非 /tmp 路径sudo mkdir -p /data/openclaw_temp sudo chown -R $USER:$USER /data/openclaw_temp如果你必须用/tmp可以延长 systemd 清理周期# /etc/systemd/tmpfiles.d/tmp.conf D /tmp 1777 root root 7d改完执行sudo systemd-tmpfiles --clean让配置生效。4.2 浏览器实例治理浏览器泄漏是最粗暴也最好治的。先加大 Docker 共享内存docker run -d \ --shm-size2gb \ -p 9222:9222 \ browserless/chrome:latest然后在 OpenClaw 的浏览器配置里关掉非必要渲染browser: headless: true disable_images: true disable_gpu: true disable_javascript: false page_timeout: 15000 restart_every_n_tasks: 30restart_every_n_tasks是关键每 30 个任务强制重启一次浏览器实例。这是解决 Chromium 内存泄漏最有效的手段没有之一。4.3 上下文压缩配置把会话 TTL 缩短限制上下文长度context: ttl: 300 max_turns: 3 pruning_strategy: smart max_context_messages: 30 cleanup_interval: 3600 cache: preload_models: true warmup_interval: 480优化前后对比大致是这样指标优化前优化后降幅Token 消耗1,847,3921,016,065↓45%内存峰值4.1GB1.8GB↓56%平均响应时间3.2s1.6s↓50%日常运维可以在对话里手动触发压缩/compact /reset /new4.4 系统级兜底Swap 与 cgroups给内存受限的实例配 Swap防止 OOM Killer 直接杀进程sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo /swapfile none swap sw 0 0 | sudo tee -a /etc/fstab echo vm.swappiness10 | sudo tee -a /etc/sysctl.conf sudo sysctl -p再用 cgroups 给 OpenClaw 设硬上限sudo cgcreate -g memory,cpu:/openclaw echo 4G | sudo tee /sys/fs/cgroup/memory/openclaw/memory.limit_in_bytes echo 200000 | sudo tee /sys/fs/cgroup/cpu/openclaw/cpu.cfs_quota_us sudo cgclassify -g memory,cpu:/openclaw $(pgrep -f openclaw)5. 验证请求与成功结果确认配置真的生效改完配置不能只看进程还活着要主动验证三层防御都起作用了。5.1 验证模型通道先用 curl 直接打 TaoToken 的接口确认 Key 和 Base URL 没问题curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoTokenKey \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: ping}], max_tokens: 16 }返回里能看到choices数组就说明通道正常。如果返回401检查 Key 是否复制完整如果返回model not found检查 Model ID 拼写。5.2 验证临时文件路径启动 OpenClaw 后跑一个短任务然后检查临时目录ls -la /data/openclaw_temp | head ls -la /data/openclaw_temp | wc -l确认文件生成在新路径下且数量没有失控。如果max_temp_files设了 1000超过之后应该能看到旧文件被清理。5.3 验证内存曲线把第 2 节的采样脚本挂上跑两小时看曲线watch -n 60 ps -o pid,rss,vsz,cmd -p $(pgrep -f openclaw | head -n1)正常情况 RSS 应该在 1.5GB 到 2GB 之间波动不会持续单调上涨。如果还在涨回到第 2 节重新定位是哪条路径。5.4 验证 OOM 兜底故意把 cgroups 上限设小一点跑一个重任务看是否被限制而不是被杀echo 1G | sudo tee /sys/fs/cgroup/memory/openclaw/memory.limit_in_bytes如果进程被限制后变慢但没有消失说明 cgroups 生效了。测完记得改回 4G。6. 本篇常见错排查401、local proxy failed、reading choices、OAuth这一节列出实际跑 OpenClaw 时最常撞到的四类报错每条都给出定位方法和修复动作。6.1 401 Unauthorized报错长这样Error: 401 Unauthorized - invalid api key原因通常是 Key 没填对、Key 过期、或者 Base URL 写成了带路径的完整地址。检查三件套base_url: https://taotoken.net/api api_key: sk-... model_id: claude-sonnet-4-20250514Base URL 不要写成https://taotoken.net/api/v1/chat/completions框架会自己拼路径。Key 前后不要有空格YAML 里用引号包起来。6.2 local proxy failed报错长这样Error: local proxy failed - connection refused这是 OpenClaw 内部代理层连不上上游。先确认网络能通curl -I https://taotoken.net/api如果 curl 通但 OpenClaw 不通检查配置里有没有残留的HTTP_PROXY环境变量指向一个不存在的本地端口。清掉unset HTTP_PROXY HTTPS_PROXY ALL_PROXY然后重启 OpenClaw。6.3 reading choices 相关报错报错长这样TypeError: Cannot read properties of undefined (reading choices)这是响应体解析失败通常是上游返回了非预期格式。可能原因有两个一是 Model ID 写错上游返回了错误 JSON二是超时设置太短请求被截断。把timeout调到 60 秒以上并确认 Model ID 在 TaoToken 的模型列表里存在。6.4 OAuth 相关报错如果你用的是 Claude Code 风格的 OAuth 流程报错可能是Error: OAuth token expired这类问题在 OpenClaw 里一般出现在用 Anthropic 原生通道时。解决办法是切到 TaoToken 的 API Key 模式不走 OAuth。配置改成model: provider: openai-compatible base_url: https://taotoken.net/api api_key: sk-你的TaoTokenKey model_id: claude-sonnet-4-20250514这样就不依赖 OAuth 刷新机制Key 长期有效省掉一整类认证相关的内存开销。6.5 排查顺序速查遇到崩溃先按这个顺序走先看dmesg确认是不是 OOM Killer再看日志有没有FileNotFoundError然后ps看 RSS 曲线最后检查模型通道是否稳定。四步走完基本能定位到具体哪一层。7. 把通道和内存一起收口长期运行的稳定姿势OpenClaw 的 OOM 问题说到底是一个“资源用错地方”的问题。临时文件写到会被清理的目录、浏览器实例不重启、上下文不清洗、模型调用反复重试这四件事叠加起来8GB 内存也能被吃干净。把临时目录迁到独立分区、浏览器每 30 个任务重启一次、上下文 TTL 缩到 5 分钟、模型通道收敛到 TaoToken 一条入口这四步做完OOM 概率能降一个数量级。剩下的交给 Swap 和 cgroups 兜底即使真出问题也不会直接杀进程。如果你还在用多个 Key 手动切换模型建议先去控制台把 Key 统一了https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入文档在这里里面有各框架的配置示例https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite想先验证模型通不通可以直接在对话页试一条请求https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite长期跑编码类 Agent 的话Coding Plan 的配额更适合高频场景https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite最后留一个我常用的检查习惯每次改完配置先跑openclaw status --deep再挂上内存采样脚本跑两小时确认 RSS 曲线平稳再上生产。这一步花二十分钟能省掉后面一整晚的救火。