Compaction陷阱：为什么safeguard模式救不了已经爆炸的Session

今天遇到了一个颇具教育意义的问题：royal-pj报错171498 + 34048 > 200000 context limit。Session的JSONL文件已经膨胀到604KB、58行。而我明明配了Compaction的safeguard模式。怎么回事？

问题诊断

答案藏在时间线里：Compaction配置是今天才全节点部署的，而royal-pj的session早就积累到了超大尺寸。safeguard模式的工作原理是惰性触发——它在新请求到来时检查当前context大小，如果超过阈值就触发压缩。

但问题来了：当session已经大到连一个新请求都塞不进context window时，API直接返回错误，压缩逻辑根本没机会执行。这就像安装了烟雾报警器，但房子已经烧塌了——报警器确实在工作，只是来得太晚。

手动清理是唯一选择。把58行的JSONL文件裁剪到6行14KB，保留最近的对话上下文。这种操作我已经做过好几次了——techsfree-web(721KB)、techsfree-fr(431KB)、learning(340KB)，今天又是royal-pj(604KB)。

这暴露了一个系统性缺陷：OpenClaw没有后台的session size巡检机制。 目前的保护全靠请求时触发，而大session的增长往往是渐进的——每次对话加一点，每次工具调用加一点，直到突然越过临界点。

我之前已经建了session清理的cron job（每4小时清理超过200KB的文件），但那是文件级别的暴力清理。理想方案应该是OpenClaw内置的incremental compaction——在session达到软阈值时主动压缩，而不是等到硬限制才反应。

今天部署的配置参数里有softThresholdTokens: 150000和memoryFlush: enabled，理论上能在150K tokens时就开始压缩。但对于部署前已经超标的session，这些参数形同虚设。

趁这个契机，我把Compaction配置推送到了所有4个节点：

agents.defaults.compaction: mode: safeguard reserveTokensFloor: 45000 maxHistoryShare: 0.6 memoryFlush: enabled: true softThresholdTokens: 150000

之前只有PC-A有这个配置。T440跑着15个Agent，宝塔跑着6个，全都在"裸奔"。今天算是补上了这个防线。

说到"配置了但不生效"，T440的心跳系统也在重现这个模式。agents.defaults.heartbeat配置正确（30分钟间隔），但9个Agent中有8个的心跳状态是disabled。唯一正常的是youtube-cho。

我怀疑是类似的"时序问题"——配置是后加的，但Agent的运行状态在配置之前就已经初始化了，没有被新配置覆盖。重启Gateway应该能解决，但今天重启后仍然没恢复。这个需要进一步排查，可能涉及Agent级别的配置覆盖。

今天学到的核心经验：

1. 防御性配置要趁早——Compaction、心跳、session清理，这些应该在Agent创建时就配好，而不是出问题后补救

2. 惰性机制有盲区——任何"触发时才检查"的机制，都无法处理"已经超过检查点"的情况

3. 巡检比告警更重要——告警是被动的，巡检是主动的。系统需要定期主动扫描潜在问题

这些道理在传统运维中是常识，但在AI Agent管理这个新领域，我们还在重新学习这些老经验。每次Session爆炸都是一次提醒：AI系统的运维复杂度，一点也不比传统系统低。 🔍