⚡ Context 管理🛠 OpenClaw🧠 Agent 配置

Session 卡死修复方案

一次调研任务撑爆 Context 的完整排查复盘

⏱ 阅读约 8 分钟  后续有彩蛋，可以直接给你的龙虾配置上哦

1故障现场：session 跑着跑着就不动了

那天我让 OpenClaw 帮我做一个竞品调研：搜十来个工具，每个抓主页、读文档、整理对比，最后输出一份报告。

前几轮跑得挺顺，能看到工具调用在一条条执行——web_search、web_fetch、read……然后，第七轮左右，画面突然定格了。

没有报错，没有输出，光标停在那儿一动不动。等了三分钟，还是一样。

跑去查 session 状态：

$ openclaw session listID          STATUS    TURNS  LAST_ACTIVEa3f9d2e1    running   7      3 min ago

还是 running。但 agent 完全没有任何动静。只能手动 kill 掉。

事后排查下来，从现象看大概率不是网络抖动，而是 context 堆积和执行链阻塞共同触发的卡死。具体来说，三个问题叠在一起：context 无上限堆积 + 无输出预留空间 + 无超时兜底。每一条单独拎出来不至于挂死，但三个撞在一起就很难扛住。

下面我把五条根因逐一拆开讲，每条都有对应的修复配置。

2五条根因 & 修复配置

严格来说，真正把 session 推向卡死的核心问题只有前两条，后三条更多是加重因素和兜底缺失。但实际场景里它们通常一起出现，所以一并列出。

先看一眼整体分类——

没有预留输出 token 空间

调研任务要抓大量网页，每次 web_fetch 都往 context 里塞几千字。跑着跑着，context 窗口被工具结果越来越挤。如果没有额外的输出预留策略，工具结果会持续挤占可用空间，任务一长就更容易把模型的回复空间吃掉——这次排查里就是这个情况。

✦ 修复： 配置 reserveTokensFloor: 80000，强制在 context 里预留 8 万 token 给输出，给模型留出回复空间。

没有 context 自动清理机制

第一轮搜的网页内容，第七轮还原封不动地躺在 context 里。旧工具结果永远不消失，context 只涨不缩。

这其实是所有 context 爆炸问题的根本原因——没有垃圾回收机制。

✦ 修复： 新增 contextPruning，策略选 cache-ttl。超过 10 分钟没再被引用的工具结果，先软裁剪（保留头尾各 2500 字），context 占用超 50% 时直接硬清理替换为占位符。

单轮执行没有超时上限

没有 timeoutSeconds 的情况下，一轮可以跑无限久。context 卡住后，session 就这么挂着，永远等不来响应，CPU 和内存也就这么占着。

✦ 修复： 新增 timeoutSeconds: 1800，单轮最多跑 30 分钟，超时自动终止，避免资源无限泄漏。

流式输出阻塞后续处理

在我的配置里，blockStreamingDefault 当时是默认的 "on"。这意味着每个流式响应必须等完全结束才能继续下一步。调研任务并发了多个 web_search 和 web_fetch，全部变成了串行等待——某个慢请求一卡，后面全排队，拖慢了整条链路。

✦ 修复： 调整为 blockStreamingDefault: "off" 后，长任务链路明显更顺了，至少减少了流式等待带来的串行阻塞问题。

阻塞的 session 永远不释放资源

在没有显式配置的情况下，空闲 session 可能不会自动回收（取决于版本默认值）。一旦出现上面的 context 卡死，这个 session 就会长期占着资源，直到你手动 kill。

✦ 修复： 改为 idleTimeoutSeconds: 600，空闲超过 10 分钟自动回收，至少保证资源不会无限泄漏。

3contextPruning 深入讲解

这是整次修复里最值得多说几句的配置。很多人第一次见 contextPruning 搞不清楚两个阶段到底怎么触发——我简单解释下，并且把最终配置放出来，大家可以直接抄作业。

整套修复后的完整配置如下，直接贴进你的 openclaw 配置文件就行：

{    "contextPruning": {        "strategy": "cache-ttl",      // 超 TTL 的工具结果自动清理        "ttlMs": 600000,               // 10 分钟未被引用即可清理        "softTrimThreshold": 30000,   // 超过 3 万字符才触发软裁剪        "softTrimHeadChars": 2500,    // 保留头部 2500 字        "softTrimTailChars": 2500,    // 保留尾部 2500 字        "hardClearContextFraction": 0.5// context 超 50% 时硬清理    },    "reserveTokensFloor": 80000,     // 强制保留 8 万 token 给输出    "timeoutSeconds": 1800,          // 单轮最长 30 分钟    "idleTimeoutSeconds": 600,       // 空闲 10 分钟自动回收    "blockStreamingDefault": "off"   // 非阻塞并发模式}

4Agent 行为规范：第一道防线

配参数是被动防御，主动防御是在 agent 行为层控制 context 增速。三条最关键的：

5三层防御体系总结

所有修复归纳起来其实就是三层，每层负责不同的防线：

后记

这次排查花了大概两个小时，收获是把 OpenClaw context 管理的整个链路摸了一遍。

每个根因单独拎出来都不难理解，难的是它们在调研场景——大量并发工具调用 + 长时间运行——下同时触发，叠加效应把问题放大了好几倍。这些排查结论是基于我自己的环境和配置，不同版本或 runtime 下细节可能有出入，欢迎对照自己的情况调整。

如果你也碰到过 session 跑着跑着就不动的情况，把上面五条配置核查一遍，大概率能解决问题。有疑问欢迎在评论区讨论。