OpenClaw内存暴涨3倍：188个幽灵会话拖垮网关

200MB起步，7分钟660MB，半小时后850MB——然后彻底卡死。没有报错，没有崩溃，只有无声的膨胀，直到运维手动杀死进程。

这是OpenClaw #55334号bug的真实轨迹。一个只在生产环境现形的幽灵：22个技能加载，12个定时任务，频繁的子代理（sub-agent）派生。网关用sessions.json追踪所有会话，每个条目都附带一份skillsSnapshot——全部技能的冻结副本。

三股暗流：数据如何变成债务

临时会话永不清理。子代理和定时任务会话完成后，永远留在sessions.json里。78个已完成子代理+40个cron:run会话，除了占地方，毫无贡献。

每份会话复制全套技能。skillsSnapshot单份41KB，188个会话叠加，6.4MB的重复技能定义在内存里躺平。

孤儿日志堆积成山。153个无对应会话的.jsonl文件（36.4MB），每次重启都触发警告，却无人认领。

0分钟约200MB，7分钟约660MB，30分钟约850MB，60分钟彻底无响应。这不是传统内存泄漏——是积累型泄漏。本该瞬时的数据，变成了永久负担。

状态机的黑洞：completed之后是什么？

会话有清晰的状态流：created → active → completed → ???。那个问号本该是pruned（清理），实际却是forever（永久）。

问题本质是上下文成本。每次会话快照一切，在会话少、生命周期长时运转良好。但在定时任务和子代理制造的大量短会话场景下，这套机制直接崩解。

开发者社区有人打了个比方：这就像餐厅给每位顾客永久保留一份完整菜单复印件，哪怕人已经走了三小时。菜单本身不贵，但架不住每小时来两百位只点一杯水的客人。

代理系统的隐性税

这个案例暴露了AI代理架构的一个设计张力。便利性与资源效率的权衡，在规模面前会被急剧放大。快照机制降低了开发心智负担——你不用操心技能状态同步——但代价是内存里的复利增长。

修复方向相对明确：给completed状态加过期策略，让skillsSnapshot引用而非复制，孤儿文件建立自动清理。但真正的难点在于，这类问题只在生产负载下暴露，测试环境很难模拟22个技能×188个会话的交叉压力。

该bug记录于AI代理可靠性系列的第34篇。作者持续追踪这类"没有崩溃的故障"——它们比显式错误更危险，因为监控指标往往一切正常，直到某个临界点突然断崖。

你的代理网关现在多少MB了？去检查一下sessions.json的行数，可能比你想的多一个数量级。