OpenClaw compaction 卡死怎么处理：恢复冻结会话与降低复发的实战指南

如果你的 OpenClaw 会话在长对话后突然不再响应，同时日志里反复出现：

cancelling compaction with no real conversation messages to summarize

那这篇就是写给你的。

这不是一篇 release notes 翻译，也不是泛泛而谈的“可能有 bug”。它更像一份把实战排障经验整理给用户看的恢复指南：怎么判断、先怎么恢复、复发后怎么修。

TL;DR

如果这几件事同时出现：

session 在长上下文后卡住，
日志里出现 compaction / compact / summarize，
删除 lock 文件没有恢复，
重启 gateway 后恢复，

那大概率可以按 compaction 卡死 处理。

最快的恢复顺序通常是：

先确认日志命中 compaction 信号
优先重启 gateway
不把删锁文件当主修复动作
如果 24–48 小时内复发，再进入配置修复

说明：本文会刻意区分“已观察到的现象”“经验性判断”和“建议配置”，避免把经验说成源码层已经证明的事实。

一、这篇适用于什么情况

适用：

长对话后突然卡住
日志里出现 compaction / compact / summarize
命中 cancelling compaction with no real conversation messages to summarize
当前 session 不再响应
删除 lock 文件无效，但重启 gateway 后恢复

不适用：

gateway 本身起不来
模型 API 整体超时
所有会话都不可用，且没有 compaction 相关日志
只是 openclaw.json 语法错误或权限问题

二、典型症状长什么样

这类问题最常见的现场是：

原本正常的会话突然不再回复
日志开始出现 compaction 相关内容
有时会反复刷这句：

Compaction safeguard: cancelling compaction with no real conversation messages to summarize.

删除 lock 文件后没有恢复
重启 gateway 后恢复正常

已观察到的现象

从运维角度看，最有价值的不是单条日志，而是这三个信号一起出现：

有 compaction 日志
会话无响应
gateway 重启后恢复

经验性判断

当这三个信号叠在一起时，更像是 会话在 compaction 过程中进入了无法自行退出的状态，而不只是某个 lock 文件单独卡住。

这里说的是运维经验判断，不是宣称源码已经 100% 证明了最终根因。

三、为什么优先重启 gateway，而不是先删锁

很多人第一反应是删锁文件。这很正常，但在这类故障里，往往不是最快恢复路径。

更务实的顺序是：

openclaw gateway restart

如果你是 systemd 管理服务，也可以：

sudo systemctl restart openclaw-gateway

为什么这样更有效

因为在这类案例里，lock 文件常常只是外部表象。

更关键的卡点，往往更像是 gateway 内部的会话状态、处理链路，或 compaction 流程没有正确退出。于是你会看到：

lock 看起来很可疑
但删了没用
重启 gateway 才真正恢复

所以更准确的说法不是“删锁一定没用”，而是：

不要优先把删锁文件当主修复动作。

四、先跑这些快速排查命令

1）先看整体状态

openclaw status

重点看：

Gateway service 是否 still running
是不是只有个别 session 卡住
当前 contextTokens 是否偏紧
gateway 活着但会话不响应的迹象

2）搜 compaction 相关日志

如果你平时用 systemd 跑 gateway：

journalctl -u openclaw-gateway -n 300 --no-pager | grep -iE 'compaction|compact|summar|timeout|stuck'

如果不确定服务名：

systemctl list-units | grep -i openclaw

3）精准搜关键报错

journalctl -u openclaw-gateway -n 500 --no-pager | grep -F 'cancelling compaction with no real conversation messages to summarize'

journalctl -u openclaw-gateway -n 500 --no-pager | grep -i 'compaction'

journalctl -u openclaw-gateway -n 500 --no-pager | grep -iE 'timeout|timed out'

五、什么时候要从“恢复”转向“修复”

如果只是偶发一次，先恢复再观察，通常就够了。

但如果满足下面任一条，就别只做重启了：

一两天内反复出现
恢复后很快又出现相同日志
多个 session 都中招
compaction 在上下文边缘反复触发
虽然日志变了，但仍然稳定卡超时

六、重点检查哪些配置

重点看这些：

agents.defaults.contextTokens
agents.defaults.compaction.mode
agents.defaults.compaction.maxHistoryShare
agents.defaults.compaction.reserveTokensFloor
agents.defaults.compaction.memoryFlush.enabled
agents.defaults.contextPruning

高风险组合通常长什么样

更容易出问题的组合，常见特征包括：

compaction.mode = "safeguard"
上下文余量过紧
历史占比过于激进
接近边界时反复自动压缩
一旦进入 compaction 就不容易正常退出

七、复发后更稳的建议基线

如果你已经明确遇到这类故障，一个更务实的起点是：

"agents": {
  "defaults": {
    "contextTokens": 100000,
    "compaction": {
      "mode": "default",
      "maxHistoryShare": 0.25,
      "reserveTokensFloor": 30000,
      "memoryFlush": {
        "enabled": false,
        "softThresholdTokens": 4000
      }
    }
  }
}

这些调整分别在解决什么

1）`safeguard -> default`

如果你已经看到：

空摘要迹象
no real conversation messages
compaction 超时或反复打转

那优先退出 safeguard 路径，通常是最有意义的一步。

2）`contextTokens -> 100000`

目的不是盲目调大，而是：

少一点“刚到边缘就压缩”
给会话更多缓冲区
降低 compaction 触发频率

3）`reserveTokensFloor -> 30000`

这一步的价值在于给：

系统提示
工具调用
最终回复生成

留下更稳定的空间，减少边界抖动。

4）`maxHistoryShare -> 0.25`

这不是为了无限保留历史，而是让压缩后的会话仍然像连续对话，而不是被压得太碎。

八、标准修改流程

先备份：

cp -p ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.$(date -u +%Y%m%dT%H%M%SZ)

改完后验证 JSON：

python3 -m json.tool ~/.openclaw/openclaw.json >/dev/null

然后重启 gateway：

openclaw gateway restart

接下来观察 24–48 小时，重点看：

compaction 是否还频繁触发
触发后会话是否还能继续响应
那条 no real conversation messages 日志是否还在重复出现

九、这几件事不要做

不要 1：只删锁文件就当修复完成

很多时候这只是动了表面。

不要 2：卡住时反复猛发新消息测试

这通常会让现场更乱。

不要 3：同时改一堆无关配置

否则你很难知道到底是哪项生效。

不要 4：把升级当第一反应

升级适合用来验证上游修复；但在大多数一线排障现场，先做最小修复通常回报更快。

十、什么时候该继续追上游或看源码

满足任一条，再考虑继续深挖：

改成 default 后仍复发
提高 contextTokens 和 reserveTokensFloor 后仍频繁卡死
重启后只能短暂恢复
多个 session 在短时间内同时中招
不再报同一句，但同样的超时行为还在

十一、每次出问题后，至少记下这几项

建议留一份极简 incident 记录：

## Compaction incident
- Time:
- Session:
- Symptom:
- Key log:
- Recovery:
- Config at time:
- Reproduced again?: yes/no

这会直接影响你后面是：

继续本地调参
去提 issue
还是升级新版本做验证

常见恢复判断问题

什么时候应该把它当成 compaction 问题，而不是普通超时

如果你同时满足下面 4 个信号，基本就应该优先按 compaction 路线排：

会话是在长对话后卡住，而不是一启动就坏
日志里能搜到 compaction、compact、summarize
删锁文件没有恢复
重启 gateway 后会话链路恢复

如果缺少这些信号，比如所有模型请求都整体超时、gateway 本身起不来，或者所有 session 都同时坏掉且没有 compaction 日志，就不要把时间先浪费在这篇路径上。

什么时候该从“先恢复”升级为“必须调配置”

最实用的判断线很简单：

24 到 48 小时内再次复发
同一类日志短时间反复出现
多个 session 接连中招
你已经确认 restart 只能短暂止血

到了这一步，就别再把 gateway restart 当完整修复，而是直接进入 compaction.mode、contextTokens、reserveTokensFloor 这些配置位的调整。

升级给维护者前，直接复制这段交接说明

如果重启和配置收口都只能短暂恢复，不要继续靠感觉描述“session 又卡了”。把现场压缩成下面这段，维护者更容易判断是 compaction 本身、provider 超时，还是 gateway 恢复链路问题：

Compaction stuck handoff
- OpenClaw version:
- Install method:
- Session age / approximate turns:
- Last user-visible symptom:
- Exact compaction-related log lines:
- Config: compaction.mode / contextTokens / reserveTokensFloor:
- Tried: gateway restart / lock cleanup / config change:
- Result after second restart:
- Reproduces in a new session?: yes/no

这份交接说明的价值在于把“长对话卡住”拆成三个问题：压缩策略是否选错、上下文预算是否太紧、恢复动作是否只短暂止血。对搜索进来的高意图读者来说，这比继续盲目重启更接近可解决状态。

第二次复发时，直接启用这张 15 分钟防复发卡

如果同一个团队第二次遇到 compaction stuck，就不要再把它当单次事故处理。用 15 分钟把恢复动作升级成防复发动作：

冻结现场：保留当前日志、session 年龄、触发前最后 3 轮对话和当时配置。
只改一个旋钮：先改 compaction.mode 或上下文预算中的一个，不要同时改 provider、模型和 gateway 参数。
跑同一条长会话路径：用刚才卡住的任务继续 10 分钟，确认不是新 session 偶然正常。
写入默认模板：把有效配置写进团队安装模板或 runbook，避免下一台机器继续沿用旧阈值。
设复查闹钟：24 小时后检查是否还有 compaction 日志回流，而不是当天恢复就关闭事故。

这张卡面向已经复发的高意图读者：目标不是“又救回来一次”，而是把一次临时恢复变成可复制的稳定配置。

如果你是第二次卡住后从搜索进来，先快速选分支

很多搜索读者不是第一次遇到 compaction stuck，而是已经重启过一次，长会话又卡住了。这个时候不要继续重复同一个恢复动作，而要先换判断树。

动 provider 或模型配置之前，先按这四类拆开：

重启曾经恢复，但很快复发：从应急恢复切到防复发配置，优先看 compaction.mode、contextTokens 和 reserveTokensFloor。
重启完全没用：先别把它当普通 compaction 漂移，保留 gateway 日志、provider timeout 证据，并确认新 session 是否也失败。
只有一个旧 session 失败：保留 transcript 和 session 年龄，再和新 session 对比，让修复指向长上下文压力，而不是整个安装坏了。
多个 session 同时失败：跳出这篇 playbook，先查 provider 健康、gateway 进程健康和最近部署变更。

这样能避免高意图读者反复执行 gateway restart，而真正该做的是防复发配置或上游事故隔离。

最后一版一句话应急卡片

如果你只想记最短版本，就记这个：

看到 compaction 卡死
查日志确认
直接重启 gateway
不把删锁文件当主修复
若复发：把 compaction.mode 改成 default，提高 contextTokens，补 reserveTokensFloor

这不是最完整的答案，但通常是最快止血的答案。