1. 为什么 OpenClaw 的内存会成为头号问题先抛结论OpenClaw 这个东西本身并不算重。它本质上是一个开源的个人智能体AI agent框架负责把你的本地大模型、外部消息渠道比如 Microsoft Teams、笔记库Obsidian以及你自定义的各种工具串起来。真正吃内存的从来不是那一小撮调度代码而是它“背后拖着的一整套生态”。我第一次把 OpenClaw 部署到一台 4GB 的小云主机上时满以为只要模型不加载到本地内存就轻轻松松。结果跑起来不到半小时free -h一看可用内存只剩 300MBSwap 已经开始疯狂读写。后来我把 NGINX 的日志、Teams 的实时连接、Obsidian 插件的索引进程全查了一遍才发现问题不是出在某一个“元凶”上而是 OpenClaw 的内存模型决定了它默认就是个“贪吃鬼”。我写下这篇文章的目的很直接把 OpenClaw 在内存里到底干了什么讲清楚然后给出一套可以照着抄的内存控制方案。这篇文章适合两类人一类是刚把 OpenClaw 部署成功正准备接入各种渠道和插件的新手另一类是已经跑了很久发现内存天天报警想知道该从哪里下刀的老手。在开始之前先说一个我踩过的最大的坑不要用看普通 Web 服务的思路去看 OpenClaw。普通 Web 服务的内存峰值是可预测的而 OpenClaw 的内存会随着会话累积、工具调用、向量缓存和插件状态而动态增长。你不理解它的工作原理就不可能真正控制住它。2. OpenClaw 内存工作原理拆解2.1 进程视角运行时主要由哪几个内存区域组成OpenClaw 基于 Node.js 运行这是理解它内存模型的第一把钥匙。Node.js 本身是一个带垃圾回收GC的运行时所以 OpenClaw 的内存问题本质上和 JVM 应用的内存问题非常像你得先区分堆内内存、堆外内存以及操作系统层面的原生内存。具体拆开看OpenClaw 进程运行时主要由这几块构成堆内存Heap存放 JavaScript 对象、字符串、闭包状态、事件回调等。大多数“内存泄漏”都发生在这里表现为 GC 无法回收的悬浮对象越来越多。栈内存Stack存放函数调用帧。OpenClaw 大量使用异步回调如果回调嵌套过深或者有死循环栈也会涨但相对来说是少数情况。外部内存 / 原生内存External / Native这是最容易忽略的一块。OpenClaw 会把 SQLite 数据库ChromaDB 的索引映射到内存还会加载 WASM 模块、TLS 连接缓存、zlib 压缩缓冲等。这些内存不在 V8 堆内但占用巨大。子进程内存OpenClaw 经常要拉起子进程来执行工具比如调 Python 脚本、调本地推理引擎这些子进程的内存不计入 Node.js 主进程却同样消耗你的系统内存。理解这几块之后你就能看懂一个现象为什么ps -aux看到 OpenClaw 主进程只占 300MB但系统的可用内存却快没了因为真正的内存使用在大门外面——向量数据库、模型推理进程、浏览器自动化组件全都挂在 OpenClaw 名下。2.2 上下文与消息队列最容易被低估的“偷内存”大户OpenClaw 的核心功能是会话管理。每个会话都有上下文窗口这个窗口里塞的是什么是你和智能体之间的每条消息、每次工具调用的结果、每个被检索到的文档片段。问题就在这里很多人在配置时把上下文窗口设置得非常大比如直接给模型传 32768 个 token 的上下文。每个 token 在 OpenClaw 内部并不是一个数字而是一堆带有元数据的对象——token 文本、注意力权重引用、会话 ID、时间戳、消息来源渠道。在内存里一个 token 轻松能用掉几百字节。我实测过一个 32768 token 的上下文OpenClaw 内部光是保存这些消息对象就要占用 80MB 到 200MB 内存这还没算传给模型 API 时的序列化开销。更隐蔽的是消息队列。OpenClaw 同时接 Teams、Obsidian、Web UI 时每一个渠道都有自己的事件循环和收发缓冲。如果某个渠道出现网络抖动消息会堆积在队列里等待重发。这些堆积的消息不会自动清理它们会一直蹲在内存里直到发送成功或者达到超时时间。如果你的 Teams 连接断了一个晚上早上起来看内存往往就多出了几百 MB 的队列缓冲。我的建议很简单不要迷信大上下文。开头的 4096 token 和 32768 token 对于大部分日常自动化任务来说体感差别很小但内存差别是肉眼可见的。2.3 模型加载与向量索引大块内存的两个来源如果你用的是本地模型比如通过 Ollama 跑 Qwen2.5-3B那模型权重占的内存你是能看见的一个 3B 参数的模型半精度FP16量化下大约占 6GB 内存在 8GB 的小机器上几乎是灾难。换成 Q4_K_M 量化之后3B 模型会压缩到 2GB 左右这才勉强能跑。但向量索引比模型更阴险。OpenClaw 默认用 ChromaDB 做记忆存储。每当你让它“记住”一段对话、一份文档它都会生成对应的 embedding 向量然后写入向量库。ChromaDB 默认配置下会把索引文件映射到内存也就是说你的知识库越大宿主的常驻内存就越大。有一回我导入了一批 Obsidian 笔记大概 2 万多个文本块索引生成后ChromaDB 直接吃掉了 1.5GB 内存而且这部分内存你从 Node.js 进程上是看不出来的因为它属于 ChromaDB 的 Python 子进程。2.4 工具调用与插件隔离内存会随着会话增长而增长的原因OpenClaw 的设计哲学是“万物皆工具”。每个工具调用都会经历一次完整的请求-响应周期期间会创建临时对象、缓存响应结果、记录调用审计日志。这些数据默认会被保留在会话内存里供后续的“反思”和“记忆”功能读取。这就导致了一个我称之为“累积膨胀”的现象假设一个工具调用结束后只留下 1MB 的临时数据看起来微不足道但当你连续跑几百次工具调用后这 300MB 就积沙成塔了。OpenClaw 的 GC 对这些数据并不敏感因为它们在 JS 层面还保持着引用关系——可能是为了让你在后续对话中能“回忆”工具调用结果但实际上 99% 的场景下你根本不会回头去看那些旧的工具返回。现在你应该明白为什么 OpenClaw 的内存控制是个系统工程了。它不是单一参数能搞定的而是要从运行时、框架配置、模型选型、插件管理四个层面一起压。3. 控制 OpenClaw 内存的实操手段3.1 先搞清楚你的内存被谁吃了监控与诊断三板斧搞内存优化的第一步不是盲目改配置而是先量化。我给自己定了一个三板斧流程每次机器内存报警都按这个顺序排查第一板斧看系统全局。用free -h看可用内存和 Swap用top -o %MEM看所有进程的内存占用排名。这一步能快速定位是 Node.js 主进程的问题还是子进程Python、Ollama、ChromaDB的问题。第二板斧看 Node.js 内部。Node.js 本身提供了--trace-gc和--print-handle-statistics参数可以输出 GC 日志和句柄统计。你还可以在 OpenClaw 的配置文件里开启诊断端点通过curl http://localhost:3000/debug/vars拿到堆内存的实时快照。这些数据能帮你判断是不是真的存在内存泄漏还是只是缓存策略太激进。第三板斧看动态增长曲线。我强烈建议你在部署机上挂一个简单的监控脚本每 5 分钟记录一次内存数据跑个两三天。然后画出一条曲线。如果曲线是一条持续上扬的斜线说明有泄漏或者累积膨胀如果曲线是锯齿状但总体持平说明 GC 还在正常工作你只需要把上限调低即可。注意这里有一个新手最容易犯的错只看 RSS驻留内存不看堆内实际使用量。RSS 高不一定有问题可能是 Node.js 向操作系统申请了更大的内存池但还没真正用完。你要结合堆内使用量来看才能真正判断是否“浪费”。3.2 Node.js 运行时内存上限控制OpenClaw 既然是 Node.js 应用最直接的控制手段就是限制 V8 的堆大小。在启动命令里加两个环境变量NODE_OPTIONS--max-old-space-size1024 --max-semi-space-size64这里的--max-old-space-size1024表示老生代堆上限为 1GB。老生代是存放大对象的区域OpenClaw 的会话记忆、工具调用结果都在这里。限制这个参数能让 V8 的 GC 更频繁地尝试回收内存而不是等到内存快爆炸才动手。--max-semi-space-size64表示半空间大小影响新生代 GC 频率设得太小会让 GC 频繁到影响性能设得太大又会占用额外内存64MB 是我试过在性能和内存之间比较平衡的值。如果运行多条消息之后发现进程被 OOM Killer 杀掉先不要急着提高这个数而是先想想是不是别的地方比如 ChromaDB 子进程占掉了太多系统内存把主进程的内存上限让出来了。我还要提醒一句这个参数只对 V8 堆生效对外部内存无效。如果你发现设置之后系统内存并没有下降多少那就得看第三层配置了。3.3 上下文窗口限制与历史消息裁剪上下文窗口是 OpenClaw 内存增长的头号源头也是最容易控制的项。在 OpenClaw 的配置文件中核心配置项如下context: max_tokens: 8192 message_history_limit: 20 tool_result_cache_size: 5 summary_after_messages: 10max_tokens别迷信大数字8192 对绝大多数交互场景都够用。message_history_limit是保底方案告诉 OpenClaw 在内存里最多保存多少条原始消息超过之后就会把更早的消息压缩成摘要。这个参数很关键默认值 50 条和 20 条长期运行下来内存差很多。tool_result_cache_size表示只缓存最近 5 次工具调用的完整结果更早的只保留摘要。summary_after_messages控制每多少条消息触发一次自动摘要自动摘要会合并旧消息释放大量内存。这套组合拳的实际效果非常明显。我把一台 8GB 机器上的 OpenClaw 从默认配置改成这个配置后连续跑了一周主进程的 RSS 从 2.8GB 降到了 1.2GB 左右而且回答质量没有明显下降。原因是对于大多数任务型对话老消息本来就不需要逐字保留摘要足够支撑后续的“记忆”功能。3.4 向量库缓存与嵌入索引的按需加载ChromaDB 是 OpenClaw 记忆系统的默认后端但它的默认配置是为了查询性能设计的对内存极不友好。如果你是单人使用、查询量不大完全可以把它改成“轻量模式”。我的做法是给 ChromaDB 设置环境变量CHROMA_PERSIST_DIRECTORY/var/lib/openclaw/chroma CHROMA_ANONYMIZED_TELEMETRYFalse CHROMA_MEMORY_MAPFalse其中CHROMA_MEMORY_MAPFalse最关键。开启 memory map 可以让 ChromaDB 把索引文件直接映射到内存查询速度会快不少但代价是索引文件哪怕不访问的部分也会占着内存地址空间。对个人部署来说查询量根本到不了需要 mmap 的程度关闭之后 ChromaDB 的常驻内存能下降一半还多。另外OpenClaw 启动时会默认对全部文档重新生成或校验索引。如果你有一个超大 Obsidian 库这个操作能瞬间拉满内存。我建议把向量化的时机改成手动触发或者限制单次索引的文档数量比如在配置里加vectorize_on_startup: false然后写一个定时任务在凌晨低峰期执行索引。这样内存峰值就变得可控了。3.5 本地模型选型与量化Qwen2.5-3B 这类小模型的正确打开方式如果你本地跑模型选型和量化直接决定内存基线的下限。我试过几条路线直接说结论7B 模型全精度FP168GB 机器别想光加载模型就 14GB。7B 模型 Q4_K_M 量化安装内存约 4.5GB加上 OpenClaw 和 ChromaDB一台 16GB 机器勉强能跑。3B 模型 Q4_K_M 量化大约 2GB 内存配合 8GB 机器比较舒适。3B 模型 Q8_0 量化约 3GB 内存回答质量比 Q4 好一些但离 Qwen2.5-3B 的满血版还是有一段距离。所以如果你是个人日常用我推荐把 Qwen2.5-3B 作为主力模型Q4_K_M 量化。它不仅内存友好中文能力和工具调用能力在 3B 级别里也是第一梯队。还要注意一点不要同时把模型加载到 GPU 和 CPU 两边。有些部署教程会教你设置OLLAMA_NUM_GPU999让模型尽量上显卡但如果你的显卡显存只有 4GB而 3B 模型量化后需要 2GB这时候强行全部上 GPU 反而会导致显存溢出系统被迫用 GTT 慢速内存补充内存占用不降反升。稳妥的做法是设OLLAMA_NUM_GPU20让 20% 的层跑在 GPU剩下 80% 跑 CPU换取稳定的内存水线。3.6 云服务器与小内存机器上的部署策略如果你用的是阿里云这类云主机的免费试用套装通常是 2 核 4GB 或 2 核 8GB 的配置。这种小内存机器的部署策略和物理机完全不一样核心原则是能分包就跑分包能不入内存就不入内存。我的推荐组合是这套OpenClaw 主程序跑在 1GB 堆限制下。本地模型通过 Ollama 跑作为独立服务模型量化选 Q4_K_M。ChromaDB 的索引目录放在数据盘上关闭 memory map。Redis 做一个外置缓存把 OpenClaw 的会话临时缓存挪到磁盘之外。用 systemd 管理各个服务设置MemoryMax2G这样的 cgroup 限制防止单个服务失控拖垮整机。小内存机器上最忌讳的是“全家桶”式部署OpenClaw、ChromaDB、Ollama、Redis、Web UI 全塞在一个进程组里互相抢内存。我用 systemd 拆开之后每个服务的独立上限都设好了系统长时间运行的内存使用曲线稳定得让人放心。4. 实操从安装到内存优化的完整流程4.1 环境准备Ubuntu 22.04 示例先声明我选的系统Ubuntu 22.04 LTS这是目前踩坑最少的环境。Debian 也行但 Ubuntu 的 Node.js 源更新更及时。第一步安装 Node.js。这里我用的是 nvm 方式方便切换版本。OpenClaw 目前要求 Node.js 18 以上我建议直接装 20 LTScurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash source ~/.bashrc nvm install 20 node -v第二步安装 OpenClaw 本体。官方推荐的方式是 npm 全局安装npm install -g openclaw openclaw init my-claw cd my-claw注意把安装日志打出来看一眼有没有编译原生模块失败的警告。OpenClaw 依赖部分原生模块如果编译失败后面跑起来会出现各种奇怪的内存溢出问题。4.2 安装与初始配置初始化完成后先别急着跑直接把配置文件打开。默认配置在~/.openclaw/config.yml。我把自己压箱底的一套内存友好配置贴在下面可以直接抄server: port: 3000 max_connections: 20 context: max_tokens: 8192 message_history_limit: 20 tool_result_cache_size: 5 summary_after_messages: 10 memory: backend: chroma chroma: memory_map: false persist_directory: /var/lib/openclaw/chroma llm: provider: ollama base_url: http://127.0.0.1:11434 model: qwen2.5:3b-q4_K_M num_ctx: 8192 num_predict: 1024这里有几个参数我单独说明一下num_ctx要和上面的max_tokens对应否则会出现上下文不一致的问题。num_predict限制生成时最多输出的 token 数这项设得太高模型会生成多余的废话同时也占用更多的推理内存。4.3 接入 Microsoft Teams 与 Obsidian 插件接入 Microsoft Teams 需要创建一个 Azure 机器人应用把 App ID 和 App Secret 填进 OpenClaw 的渠道配置里。这个过程不算“吃内存”但有个坑Teams 的 WebSocket 长连接如果断线重连太频繁会在 OpenClaw 内部累积连接状态对象。我的做法是在 Teams 渠道配置里加一条channels: teams: enabled: true reconnect_backoff: 30000把重连退避时间设成 30 秒避免网络抖动时疯狂重连导致内存暴涨。Obsidian 插件这边核心是控制索引频率。默认配置里 OpenClaw 会监听 Obsidian vault 的文件变化实时更新向量索引。笔记多的时候一次批量同步能吃掉 1GB 内存。建议改成plugins: obsidian: vault_path: /path/to/Vault watch_mode: false sync_interval: 43200watch_mode: false关闭实时监听sync_interval设为 12 小时一次。这样你的笔记改动最多延迟半天被智能体感知但内存压力大大缓解。4.4 运行时内存参数配置实战配置文件搞定之后还需要用 systemd 把我们前面说的 Node.js 内存参数固化下来。新建一个 service 文件sudo nano /etc/systemd/system/openclaw.service写入[Unit] DescriptionOpenClaw AI Assistant Afternetwork.target [Service] Useryouruser WorkingDirectory/home/youruser/my-claw EnvironmentNODE_OPTIONS--max-old-space-size1024 --max-semi-space-size64 EnvironmentCHROMA_MEMORY_MAPFalse ExecStart/home/youruser/.nvm/versions/node/v20.x.x/bin/openclaw start Restarton-failure MemoryMax3G [Install] WantedBymulti-user.target这个文件里MemoryMax3G是兜底即使配置有疏漏OpenClaw 主进程也不会把整机拖死。重启服务后用下面命令验证参数是否生效systemctl daemon-reload systemctl enable openclaw systemctl start openclaw systemctl status openclaw然后跑一个简单对话再用ps -o rss,vsz,cmd -p $(pgrep -f openclaw)看看常驻内存有没有明显下降。4.5 把内存压到 1GB 以内的一个参考方案可能有人会问我只有 2GB 内存的机器能不能跑能但要更狠一些。我提供一个极限压榨方案牺牲一些响应速度换稳定运行模型改用 Qwen2.5-1.5B 的 Q4_K_M 量化内存占用不到 1GB。OpenClaw 的堆内存上限压到 384MBGC 频率会变高但单人对话场景完全能接受。ChromaDB 直接禁用持久化全部走内存临时索引。这样每次重启会丢失部分历史记忆但在文档量不大的前提下体验损失并不明显。关闭所有非必要插件只保留 Teams 或 Web UI 其中一个入口。给系统设置 zramsudo apt install zram-tools echo ALGOlz4 | sudo tee -a /etc/zram-tools.conf echo SIZE1024 | sudo tee -a /etc/zram-tools.conf systemctl restart zram-tools这一套下来OpenClaw 加模型加系统的总内存占用大概在 1.5GB 到 2GB 之间2GB 的云主机终于不用靠 Swap 续命了。代价是首次响应时间会慢一到两秒毕竟 GC 频繁了一些。但这个方案的核心价值是“能跑”而且是 7×24 小时稳定跑。5. 常见问题与排查技巧实录5.1 OpenClaw 无法安全验证 WSL2 环境怎么办这个问题通常出现在 Windows 环境下用 PowerShell 启动 OpenClaw 时。报错信息大概长这样“无法安全验证 WSL2 环境请在 PowerShell 中运行 wsl --status”。我先说原因OpenClaw 检测到 Windows 上有 WSL2 环境但无法确认 WSL2 的内核版本和并发内存分配是否满足要求。这个检查本身是为了防止在 WSL1 或者未启用嵌套虚拟化的情况下直接跑内存密集任务导致系统崩溃。解决办法分两步。第一步在 PowerShell 里执行wsl --update wsl --status确认WSL 版本2.x.x和默认版本2这两项都正常。如果默认版本还是 1执行wsl --set-default-version 2。第二步如果你压根不想用 WSL 跑Windows 下直接用 Node.js 运行 OpenClaw 也是一条路。在 PowerShell 里设置环境变量WSL_UTILS_ENABLED0OpenClaw 就会跳过 WSL 检测走纯 Windows 的原生模式。顺带一提Windows 原生模式下进程内存模型和 Linux 下略有差异。V8 在 Windows 上的堆上限默认也是 2GB 左右这时候建议把NODE_OPTIONS里的堆上限调到 768MB给系统和其他软件留够余量。5.2 Antimalware Service Executable 占内存怎么办这个问题很多人会碰到尤其是一边跑 OpenClaw 一遍做测试的时候。Windows 自带的 Defender 进程Antimalware Service Executable经常在后台全盘扫描内存占用直接飙到 1GB 以上把本来就紧张的机器压得喘不过气。我的建议不是让你关掉 Defender那太危险了。正确做法是给工作目录加排除项Add-Module Defender Add-MpPreference -ExclusionPath C:\workspace\openclaw把 OpenClaw 的工作目录、模型目录、ChromaDB 数据目录都加进去。这样 Defender 就不会反复扫描那几千个小文件。JDK 类的编译目录也建议顺便加上。如果你还想再压一点可以修改 Defender 的计划扫描时间避开你使用高峰期。运行打开“任务计划程序” - Microsoft - Windows - Windows Defender把计划扫描触发时间改成凌晨这样白天跑 OpenClaw 时后台扫描的情况会少很多。5.3 用户拒绝访问内存文件权限怎么办这个报错我见过好几回场景是 OpenClaw 的向量数据库或者缓存文件放在了只读目录下。具体报错可能类似“用户拒绝访问内存文件权限”但其实不是内存的问题是文件系统权限的问题。排查步骤很简单ls -la /var/lib/openclaw/chroma/ sudo chown -R $(whoami):$(whoami) /var/lib/openclaw/chroma/ chmod -R 755 /var/lib/openclaw/chroma/如果是 Windows 下右键目录 - 属性 - 安全 - 编辑给当前用户完全控制权限即可。这个坑多发生在你用sudo openclaw init初始化之后又改用普通用户启动的场景。记住一条原则OpenClaw 的数据目录要么全部归 root 管要么全部归普通用户管不要混合。5.4 内存泄漏会话越长越卡这是所有 OpenClaw 用户在长时间运行后一定会遇到的现象。会话跑了两天之后响应速度越来越慢内存越涨越高。排查思路我推荐这套第一步打开openclaw logs --tail50看看有没有“内存警告”或“GC overhead limit exceeded”日志。第二步用node --inspect连接 ChromDevTools抓一份堆快照看看内存里到底是什么对象最多。我在实际排查中发现最常见的两类残留是已经被摘要替代的原始消息对象以及工具调用返回的大型 JSON 结构。第三步也是最重要的确认你的message_history_limit和summary_after_messages是不是真的生效了。我见过很多人改完配置没有重启服务改了个寂寞。OpenClaw 部分配置支持热加载但内存相关的配置必须重启进程才生效。如果确认配置没问题那就上“重启大法”。别觉得重启丢人这恰恰是最稳定的内存控制手段。用一个每天凌晨 4 点的定时任务重启 OpenClaw是内存控制最好的兜底策略0 4 * * * systemctl restart openclaw5.5 16GB 内存开机就被吃掉一半这是一个典型的“大内存机器幻觉”问题。很多人说“我 16GB 内存开机就占 50%是不是中毒了”。先不急把资源监视器打开看看到底是谁占的。通常罪魁祸首不是 OpenClaw而是浏览器、Electron 应用、Defender 这三个巨头。OpenClaw 在这种机器上要做的反而是“少占内存”因为机器上跑的东西太多内存分配一旦撞车系统就开始换页卡顿。建议把 Node.js 堆上限设在 1.5GB模型选 3B 量化ChromDB 关闭 memory map。这是我在 16GB Windows 笔记本上的配置实测日常内存占用能稳定在 60% 以内浏览器开 30 个标签页也不卡。另外Windows 上还有一个小技巧虚拟内存。默认情况下 Windows 会用“系统管理的大小”容易在内存紧张时创建巨大的 pagefile。手动设置为固定值能够减少磁盘碎片化和交换延迟比如设置为 8GB 固定大小。这个优化对 OpenClaw 这种长时间运行的 Node 应用比 Linux 下的 swap 配置要明显得多。5.6 常见问题速查表问题现象最可能原因推荐解决动作WSL2 环境无法安全验证WSL 内核过旧或默认版本不对wsl --updatewsl --status确认版本为 2Defender 进程吃满内存系统扫描工作目录给 OpenClaw 数据目录加 Defender 排除项用户拒绝访问内存文件数据目录权限错乱统一目录属主为当前用户chmod 755会话越长响应越慢上下文和工具结果在内存累积重启进程 设置message_history_limit16GB 机器开机卡顿浏览器/Electron/Defender 竞争压 OpenClaw 堆上限固定 pagefile向量库导入时内存飙升批量索引未限流设vectorize_on_startup: false错峰手动触发Teams 断线重连导致内存涨重连退避太短设置reconnect_backoff: 300006. 写在最后我的一点经验文章最后我不准备做什么宏大的总结就分享一条我自己在多次内存踩坑之后悟出来的体会控制 OpenClaw 的内存本质上是在控制它的“记忆策略”。你希望它记住多少历史消息、缓存多少工具结果、索引多少文档、保留多少上下文直接决定了你的内存占用。所以我建议在做任何内存参数调整之前先想清楚你的真实使用场景。如果你只是拿 OpenClaw 当一个日常提醒和笔记助手那么降低消息保留量、关闭实时文件监控对你完全没有损失如果你要用它做复杂的多步任务编排那该保留的工具调用上下文还是要保留不然它会在长任务中丢失状态。另外一个小技巧给所有折腾到深夜的朋友OpenClaw 的openclaw admin memory命令可以手动触发一次压缩它会主动清理过期会话缓存。但要注意这个命令本身也会消耗一些 CPU 来做序列化扫描建议在低峰期执行。我一般会在每周日晚上的定时任务里加上它配合周一重启整个星期的内存水位都很健康。还是那句话OpenClaw 是一个不断迭代的项目内存模型也可能随之变化但“先诊断、再配置、后验证”这个思路是永远不过时的。祝你的智能体越跑越顺。