搞常驻型智能体项目的人，基本都遇到过同一个场景：服务刚起来的时候内存占用很干净，跑了两三天以后，直接翻了好几倍，最后被系统 OOM 干掉。我最早调试 OpenClaw 内存问题时也是这个状态，到处加日志、看监控、重启服务，结果治标不治本，过几个小时又涨回来。后来把内存组成和生命周期彻底拆了一遍，才发现问题根本不在某个具体功能上，而是整套内存管理机制没有理顺。
OpenClaw 的内存原理，本质上要回答三个问题：内存被谁占用了、为什么只增不减、怎么在保住对话能力的前提下把峰值压下来。这篇文章就是围绕这三件事展开的，从模块拆解到控制手段再到排查实录，全部来自实际部署和调优过程中反复验证过的做法。
如果你正在跑 OpenClaw 或者类似的长驻型智能体服务，并且已经被内存问题折磨过，这篇文章应该能帮你省下不少排查时间。
1. 先拆清楚：OpenClaw 的内存到底被哪些模块吃掉
很多人以为内存主要是大模型推理占的，实际跑起来才发现，模型进程往往独立部署，真正让你服务内存飙升的，是框架自身管理的那部分数据。OpenClaw 的内存占用可以分成四块来看，每一块的膨胀逻辑都不太一样。
1.1 会话上下文是内存的最大头
会话上下文就是智能体“记得”的内容。你每发一句话、模型每回一句话、工具每返回一个结果，都会被追加进上下文集里。OpenClaw 默认会把最近 N 轮对话完整保留，N 的大小直接决定内存天花板。
这里有个容易误判的点：上下文窗口单位是 token，内存占用单位是字节。虽然不能简单地画等号，但数量级上可以估算。中英文混用场景下，1 个 token 大约对应 0.7 到 1.5 个汉字，一个 32K 窗口的完整上下文，仅原始文本就有 30KB 到 50KB，这个量级本身不大，可一旦框架里还存了 embedding 向量、工具调用记录、消息元数据，单会话可能直接到几十 MB。
我记得第一次看 OpenClaw 的上下文对象时有点意外：它不是一个纯文本数组，每条消息都带着 role、时间戳、token 数、工具调用参数等结构化字段。这意味着内存占用不是“文本长度乘以单字节”那么简单，而是每条消息都有固定开销。会话轮数越多，这部分膨胀得越明显。
1.2 工具调用记录与中间产物是最容易忽略的“隐形空间”
OpenClaw 这类框架主打工具调用能力，所以工具返回数据会直接进上下文。问题在于，工具返回的内容往往不受对话长度限制。一个文件读取工具可能返回几万行内容，一个搜索工具可能把整个页面抓回来，这些数据如果原样塞进上下文，内存会瞬间暴涨。
我遇到过最夸张的一次，某个脚本执行工具返回了约 30MB 的日志输出，OpenClaw 把它全量存进会话记录里，服务内存直接在几分钟内从 800MB 冲到 3GB。更麻烦的是，工具结果不像普通对话那样会被修剪策略优先处理，部分版本对工具结果的保留策略偏保守，宁可多留也不愿意截断，理由是后续模型可能还需要引用。
如果框架还做了中间产物缓存，比如把工具输出写到临时目录时同步维护一份内存索引，这部分占用就更难在监控里定位了。排查的时候不能用“消息条数”来衡量，要看“单条消息体量”。
1.3 隐性模块：插件运行时、日志缓冲与向量缓存
OpenClaw 的插件系统会让内存里多出几块你平时根本不会注意的数据：插件自身的静态资源、运行时状态、事件监听器等。如果开了 embedding 相关的记忆插件，还会有一份向量缓存常驻内存。向量缓存的量级容易被低估，几百条文本的 embedding，每条 1536 维浮点数，算下来就是几十 MB 起步，而且通常不会自动清理。
日志缓冲也是隐形大户。默认 info 级别还好，一旦切到 debug 模式，框架内部的事件循环、工具调用过程会打出大量结构化日志。有些版本的日志模块是异步批量写的，内存里会积压一批待落盘的日志事件，高峰期能占到总内存的 10% 到 20%。
还有就是多会话并发。前面说的都是单会话的场景，如果 OpenClaw 服务同时挂着多个会话，所有数据都是独立保留的，内存占用基本是线性叠加。叠加之后又会产生新的问题：上下文管理器的索引结构、LRU 缓存、调度队列都会膨胀，这部分开销在并发数超过 10 以后会变得非常可观。
2. 为什么内存只增不减：失控的根因分析
理解了模块组成之后，第二个问题就是：为什么设置了限制，内存还是一路往上涨？我总结下来有三个根因，基本覆盖了绝大多数内存失控场景。
2.1 无界增长的工作区机制
OpenClaw 默认的工作区设计是“只追加，不清理”。每轮对话、每次工具调用、每个中间状态都会往工作区里写。它的设计初衷是保证会话的可回溯性，但从内存角度看，这就是无界增长。
打个比方，就像你往房间里堆纸箱，每个纸箱都是这次会话的“记忆”，正常情况下应该定期把不用的纸箱搬走。但默认策略是“万一后面还要翻旧箱子呢”，于是一个都不扔。短期没问题，跑上几百轮之后，房间就满了。
更隐蔽的是，有些清理动作不是立刻生效的。你调用了修剪接口，框架只是把上下文里标记为“可丢弃”，实际的内存释放要等垃圾回收触发，或者要等下一次写入时才真正执行。所以经常出现“明明已经修剪了，RSS 却不降”的假象。
2.2 会话隔离与并发资源争抢
OpenClaw 在单进程模式下，所有会话共享同一个运行时。单个会话内存失控会拖垮全部会话，这个很好理解。但还有一个容易被忽略的点：框架的全局缓存和会话本地缓存没有严格区分。
比如 embedding 缓存，它会缓存在多个会话之间共享的文本片段，这部分数据理论上可以复用，但如果缓存没有设置上限，每个会话的新文本都会往里面塞，内存就会持续增长。再比如工具执行器的临时文件索引，多个会话并发执行同一个工具时，索引结构可能被重复构建。
这就是并发场景下内存非线性增长的原因：每个会话表面上只占用自己的内存，实际上全局层的缓存和索引被反复撑大。
2.3 外部工具的不确定性
工具调用是 OpenClaw 内存暴涨的最大不确定性来源。你无法预知用户会让模型执行什么命令、搜索什么内容、读取什么文件。模型本身也没有“返回体要小一点”的意识，它会原样把工具输出拿过来处理。
这部分问题靠框架自身很难完全解决，只能在控制和策略层面做约束。比如给工具返回体设置大小上限、对输出做截断、或者在工具调用前后做一次上下文压缩。
3. 如何控制内存：从参数到架构的完整手段
控制内存不是一个参数就能解决的，需要从硬边界、软回收、外置存储、并发治理四个层面同时下手。下面按优先级从高到低说。
3.1 用上下文窗口参数设置“硬边界”
首先确认 OpenClaw 的配置里有没有上下文窗口上限参数，通常叫 max_context_tokens 或者 max_window_size。这个值决定了单次会话能保留的最大 token 数，是最重要的“硬边界”。
设置的时候要考虑模型的实际上下文能力。如果用的模型只支持 8192 token，你却把窗口配成 16384，框架在调用模型前会被迫截断，而且截断策略默认是丢最前面的消息，也就是最早的历史。这样会导致对话连贯性变差，甚至工具调用链断裂。
我的建议是：窗口值配成模型支持能力的 60% 到 70%，预留一部分给系统提示词和工具定义。比如模型支持 32K，窗口设 20K 到 22K 左右比较稳妥。这样框架内部有足够的余量做修剪和摘要，不会频繁触发硬截断。
另一个参数是 max_history_rounds，控制对话轮数上限。这个参数比窗口值更容易理解，每轮对话的平均 token 数可以通过实际流量统计出来，然后用窗口值除以单轮平均 token 数，就能反推出一个合理的轮数上限。
3.2 用修剪策略实现“软回收”
硬边界是防止内存突破阈值，软回收是让内存保持在一个合理的波动区间。OpenClaw 的修剪策略一般有几种模式：
滑动窗口模式最简单，只保留最近 N 轮，之前的全部丢弃。对简单问答场景够用，但缺点是模型会彻底丢失早期信息，比如用户一开始交代的背景约束。
摘要压缩模式则是把旧消息喂给模型生成摘要，用一段话替代之前的几十轮。这个模式对长会话非常友好，代价是要额外消耗一次模型调用。
还有一种针对工具结果的修剪，就是丢弃或压缩历史工具返回的原始数据。大部分场景下，模型对工具结果的引用都发生在当前轮或最近几轮，早期工具结果基本都是占内存的废数据，可以放心处理。
我实测下来，摘要压缩对内存回收的效果最明显，但会带来 10% 到 20% 的额外模型调用成本。如果对成本敏感，可以只在会话轮数超过阈值时才启用摘要，短会话直接用滑动窗口。
3.3 把内存换到磁盘：持久化与外部存储
内存有限，磁盘便宜，所以把不热的数据换到磁盘是很自然的思路。OpenClaw 支持会话数据持久化，可以把完整的历史消息、工具记录写到本地存储，内存里只保留当前活跃窗口。
这里的关键是正确配置存储位置和存储策略。需要确认几个点：
- 数据写入的触发条件：是按轮写入，还是定时批量写入
- 数据读取的时机：切换回旧会话时，是重新加载全部上下文，还是只加载摘要
- 旧会话的淘汰策略：保留多少个会话在磁盘上，超过数量后是删除最旧的还是会话归档
实际操作中，我建议把“会话完整记录”和“模型上下文”拆成两份数据。完整记录放磁盘用于追溯，模型上下文只放当前窗口。每次会话恢复时，先读摘要，需要细节时再按需加载，尽量避免一次性把完整记录拉回内存。
如果 OpenClaw 接入了向量记忆插件，还可以把长期记忆放到外部向量数据库中，内存里只保留最近交互的向量索引。这样单会话内存可以从大几百 MB 降到几十 MB 量级。
3.4 限制并发与插件加载
最后一步是治理并发和插件。OpenClaw 的并发参数一般包括最大会话数、单会话请求队列长度、工具执行超时时间。
最大会话数要结合实际内存预算来设。假设服务限制是 4GB，单会话稳定占用约 400MB，那并发上限设 8 到 10 比较安全，留出余量给系统本身的负载。
工具超时是一个容易被忽视的控制点。某些工具调用会长时间占用内存缓存，比如持续输出流的命令。设置超时时间可以强制中断异常调用，避免内存被无限占用。
插件的加载策略也一样。只加载当前业务真正用到的插件，不用的插件全部禁用。每多一个插件，内存里就多一份运行时开销，还有可能多一个定时任务，这些都是纯消耗。
4. 实操：从建立监控基线到完成一次内存调优
理论讲再多，不如完整跑一遍流程。我把自己做内存调优的步骤整理出来，每一步都有明确目的和验证方式。
4.1 先建立监控基线，不要凭感觉调参
调优的第一步不是改配置，而是拿到当前服务的真实数据。我通常会在服务跑满一个业务周期后，比如一天或一周，记录以下几个指标：
- 进程常驻内存（RSS）的均值、峰值和增长趋势
- 会话数量及其分布
- 上下文窗口的平均使用率
- 工具返回体的平均大小
- 垃圾回收后内存是否能回到基线
Linux 下我用得最多的是 pidstat 和 /proc 接口。pidstat -r -p 进程ID 1 可以每秒输出一次 RSS 变化，能很直观地看到内存增长的速率和触发点。
# 每 5 秒采样一次指定进程的内存 pidstat -r -p 12345 5 # 查看进程当前内存详细状态 cat /proc/12345/status | grep -E "VmRSS|VmSize|VmData" # 用 ps 快速看所有 OpenClaw 相关进程的排序 ps aux --sort=-rss | grep openclaw有了基线数据后，先别急着改配置。先回答一个问题：内存增长是线性趋势还是阶段性跳变。如果是跳变，跳变的那个时间点大概率对应某次大工具调用或者某条超长消息，直接查日志就行。
以我自己某次调优为例，基线数据是：单会话运行 8 小时，RSS 从 620MB 涨到 1.85GB，会话轮数 300 轮左右，工具调用 87 次。这个数据意味着什么？平均每轮让内存涨了约 4MB，大部分来自工具结果缓存。
4.2 分步骤调整配置并逐项验证
拿到基线后，按下面这个顺序调整，每调整一项就跑一个验证周期。
第一步，核对模型上下文窗口。我用的模型支持 32K 上下文，原配置窗口值也是 32K，这显然太激进。把窗口改成 20K，预留 12K 给系统提示和工具定义。这一步能把最坏情况下的内存上限直接砍掉三分之一。
第二步，设置会话轮数上限。原配置没有限制轮数，导致会话无限增长。按单轮平均约 4MB 计算，20K 窗口大约能支撑 500 轮，但如果设置 500 轮作为上限，内存峰值还是会很高。所以把轮数上限设成 200 轮，配合修剪策略，让内存稳定在一个区间内。
第三步，开启摘要压缩。配置里把摘要触发条件设为“会话轮数超过 150 轮时，对最早的一半消息做摘要”。这样既保住了早期上下文的大意，又不会让内存无限膨胀。
第四步，配置工具结果截断。我写了一个简单的策略规则：文本类工具返回超过 5000 字符时，只保留开头 500 字符和结尾 500 字符，中间用占位符替代。这个规则要谨慎，因为某些工具调用链条会依赖完整输出，建议先在非核心会话上测试。
第五步，把长期历史外置到磁盘。核心会话保留最近 200 轮的完整信息，更早的信息全部归档到本地存储。会话恢复时只加载摘要和最近 50 轮，按需读取更早的数据。
第六步，限制并发会话数。原本允许 20 个并发会话，按单会话 400MB 计算，峰值就是 8GB，这已经超过物理内存了。把并发数降到 6，并根据会话优先级做排队。
调整完以后，重新跑同样的业务场景。我那次的结果是：稳定运行 24 小时，RSS 峰值从 1.85GB 降到 820MB，内存曲线不再是持续上升的斜线，而是锯齿状的波动曲线，垃圾回收后能回到 600MB 左右的基线。
下面是调整前后的关键参数对比，具体数值因场景而异，但调整方向是通用的：
| 参数项 | 调整前 | 调整后 | 作用 |
|---|---|---|---|
| 上下文窗口 | 32K | 20K | 降低单会话内存天花板 |
| 会话轮数上限 | 不限 | 200 轮 | 限制历史消息总量 |
| 摘要压缩 | 关闭 | 150 轮触发 | 压缩早期上下文 |
| 工具结果截断 | 不截断 | 5000 字符内保留首尾 | 控制单条消息体量 |
| 会话持久化 | 关闭 | 开启，磁盘归档 | 把冷数据移出内存 |
| 最大并发会话 | 20 | 6 | 降低整体内存峰值 |
| 垃圾回收 | 默认 | 开启周期回收 | 主动释放已删数据 |
这个表格不是让读者照抄，而是提供一个思考框架：先看单会话内存构成，再定窗口和轮数边界，然后考虑压缩和截断，最后治理并发。
5. 常见问题与排查实录
这部分汇总一下我在实际使用中最常遇到的问题，以及排查思路。
5.1 设置了窗口限制，内存为什么还在涨
这是最常被问的问题。要区分“框架内存”和“模型进程内存”。OpenClaw 的上下文窗口参数只能管框架自己维护的消息数据，管不了模型推理时的 KV cache。如果你把框架和模型放在同一个进程里跑，那窗口限制对整体内存的影响会被模型推理的内存需求覆盖掉。
如果确认是框架内存还在涨，那大概率是某个会话的“不可修剪数据”太多。比如系统提示词固定占用一部分，工具定义占用一部分，这些都是常数，正常情况下问题不大。真正异常的是某些插件往会话里注入了自定义数据，而这些数据不在上下文修剪的范围内。
排查方法：打开 OpenClaw 的内存分析接口，按数据类型列出内存占用明细。如果没有现成接口，就遍历所有活跃会话，逐个查看消息数量和总 token 数，哪个会话的 token 数远超窗口上限，就往那个会话里查。
5.2 上下文修剪后，对话能力明显下降怎么办
修剪的本质是丢掉信息，丢信息肯定会影响能力，这个没办法完全避免，只能尽量减少损失。
第一个办法是优化摘要质量。摘要不是简单把消息压缩，而是要把关键约束、用户偏好、未完成事项单独提取出来，做成结构化的“记忆卡片”，比纯文本摘要更经得起后续引用。OpenClaw 的摘要配置一般支持自定义提示词，建议在提示词里明确要求保留这些内容。
第二个办法是缩小修剪范围。不是所有消息都适合修剪，工具执行结果里的错误信息往往比正常输出更有价值，因为这些错误可能在后续轮次里被反复讨论。可以把这类消息标记为“高优先级保留”。
第三个办法是延长摘要触发阈值。如果内存有富余，就把触发条件从 150 轮改为 300 轮，这样减少被摘要压缩的消息总量。
5.3 多会话场景下，如何让内存占用更可控
多会话场景的核心思路是“池化”。给会话按重要程度划分等级，核心会话分配大窗口，普通会话分配小窗口，临时会话直接用滑动窗口模式。这样总内存预算不变，但核心体验不会缩水。
运营人员经常用的一个做法是：创建会话时指定 profile，每个 profile 对应一套窗口和修剪配置。OpenClaw 的 profile 机制如果不支持，可以用命名空间或路由规则来实现同样效果。
还需要注意会话的空闲回收。很多内存占用来自那些已经不再活跃、但也没有被销毁的会话。设置一个空闲超时时间，超过时间没有新消息就把会话存档到磁盘并从内存中卸载。
5.4 重启进程后，内存仍然居高不下
如果服务刚启动 RSS 就很高，大概率不是会话数据的问题，而是启动过程中加载了太多常驻模块。逐个排查：加载了几个模型、几个 embedding 缓存、多少个插件。
有一种常见情况：embedding 模型启动时要加载词表和数据文件，如果用的是较大的模型，光这一项就能吃掉好几百 MB。如果业务不重度依赖向量记忆，可以考虑换一个小模型，或者干脆用外部向量库服务。
还有一种比较隐蔽的情况：配置文件里开了多个“监听器”或者“调度任务”，每个都会初始化独立的运行时。检查日志里的初始化记录，看有没有重复初始化的模块。
为了便于快速对照，我整理了一份排查速查表：
| 症状 | 可能原因 | 处理方式 |
|---|---|---|
| 内存持续上升不回落 | 上下文无界增长 | 设轮数上限开启修剪 |
| 修剪后 RSS 不下降 | 已删数据未触发回收 | 手动触发垃圾回收确认 |
| 单次调用后内存跳涨 | 工具返回体过大 | 设置工具结果截断 |
| 并发数不高内存很高 | 模型或 embedding 常驻 | 检查启动加载项 |
| 重启后仍高 | 插件或模块重复加载 | 精简插件配置 |
| 多会话内存叠加超限 | 缺少池化治理 | 按 profile 分配窗口 |
| 摘要后对话质量下降 | 摘要信息密度不足 | 优化摘要提示词 |
| 空闲会话占用过高 | 未做空闲回收 | 设置空闲超时时间 |
6. 我的一点实战心得
OpenClaw 这类常驻框架的内存管理，与其说是技术问题，不如说是“生命周期管理”问题。我跑了几个月之后最大的体会是：不要试图找一个万能参数，内存控制的本质是给每一条数据都规划好它的生命周期——什么时候进来、保存在哪里、什么时候被压缩、什么时候被丢弃。
我个人的建议是：新项目上手时，先把监控和日志里关于内存的部分配好，再调任何参数。没有数据支撑的调优都是猜，有了基线数据以后，每次改动的影响范围都能快速定位。
最后分享一个小技巧：把长会话拆成短会话，比任何内存参数都好使。OpenClaw 处理一个 3000 轮的巨型会话，不如处理 10 个 300 轮的短会话省内存，而且短会话间可以通过摘要或向量库共享记忆，既保住了上下文，又能让内存峰值维持在低位。如果业务允许，这个思路在架构初期就值得应用。
