今天在使用 OpenClaw(一个本地 AI Agent 框架)的过程中,我的 session 上下文直接撞上了 200K token 的硬顶,Claude API 返回了 503 错误,整个对话直接挂掉。
这不是理论问题,是真实踩坑。记录一下发生了什么,以及怎么解决的。
TL;DR:长对话 + 图片 + 工具调用 = 上下文爆炸。解决方案是自动压缩 + 主动压缩 + 把重要信息写入文件而不是靠上下文记忆。
发生了什么
Claude 的上下文窗口是 200K token。听起来很大,但在实际的 Agent 工作流中,消耗速度远超你的想象:
• 每次工具调用(读文件、执行命令、搜索)的输入输出都会计入上下文
• 图片是 token 大户,一张截图可能吃掉几千 token
• 系统提示词(system prompt)+ 工作区文件注入,开局就占了 20K+
• 长对话中每一轮的历史消息都在累积
今天的场景是:一个 session 里连续做了多个任务——搭项目、调试代码、搜索信息、截图分析——上下文在不知不觉中逼近 200K,最终 API 直接返回 503,session 崩溃。
为什么 200K 不够用
简单算一笔账:
• 系统提示词 + 工作区注入:~20K token
• 每轮对话(用户消息 + AI 回复 + 工具调用):平均 2-5K token
• 一张图片:1-5K token
• 读一个文件:几百到几千 token
一个活跃的 Agent session,30-50 轮对话就能轻松吃满 200K。如果中间有大量图片或长文件读取,可能 20 轮就到顶了。
解决方案
1. 自动压缩(Safeguard Compaction)
这是踩坑之后配置的第一道防线。在 OpenClaw 的配置文件 openclaw.json 中,可以设置自动压缩策略:
{
"compaction": {
"mode": "safeguard",
"reserveTokensFloor": 30000
}
}
reserveTokensFloor: 30000 的意思是:当上下文剩余空间不足 30K token 时,系统自动触发压缩。不用人工干预,不用盯着 token 数,系统自己兜底。
压缩效果相当可观。实测一次 compaction 可以把 175K 压到 21K,释放 88% 的空间:
⚙️ Compacted (175k → 21k) • Context 21k/200k (10%)
代价是丢失一些对话细节,但核心信息和决策会被保留。
2. 主动压缩(Manual Compaction)
除了自动兜底,你也可以随时手动触发压缩。在 OpenClaw 中输入 /compact 命令即可。适合在你意识到当前 session 已经很长、接下来还有大量工作要做的时候,主动清理一波。
3. 文件 > 记忆
这是最重要的原则:不要依赖上下文来"记住"东西,把重要信息写到文件里。
上下文是易失的——压缩会丢细节,session 重启会全部清空。但文件是持久的。具体做法:
• 做完一个任务,把结论写入 memory 文件
• 重要的决策和偏好写入长期记忆(MEMORY.md)
• 项目配置、账号信息等写入专门的文件
这样即使上下文被压缩或 session 重启,Agent 也能通过读文件恢复状态。
4. 图片密集任务用 Sub-agent
图片是上下文杀手。如果需要批量处理图片、反复截图对比,应该 spawn 一个子 session(sub-agent)来做,避免主 session 被图片撑爆。
子 session 有独立的上下文空间,爆了也不影响主 session。
5. 一个 Session 一个任务
不要在一个 session 里做太多不相关的事。搭项目是一个 session,写文章是另一个 session。用 /new 开新 session 的成本很低,但上下文爆炸的代价很高。
给 AI Agent 用户的建议
• 配置自动压缩:设一个合理的 reserveTokensFloor(推荐 30K),让系统自动兜底
• 关注上下文用量:大多数 Agent 框架会显示当前上下文占用,养成看一眼的习惯
• 写文件不写脑子:让 Agent 把重要信息持久化到文件,而不是全靠上下文扛
• 拆分任务:大任务拆成多个 session 或 sub-agent
• 少发图片:能用文字描述的就别截图,图片是 token 黑洞
写在最后
上下文窗口是当前 LLM 的硬约束,200K 听起来很大,但在真实的 Agent 工作流中消耗极快。与其祈祷模型厂商把窗口开到 1M、10M,不如现在就养成好习惯:主动管理上下文,把记忆外化到文件系统。
毕竟,人类也不是靠大脑记住一切的——我们有笔记本、日记、备忘录。AI Agent 也一样。
Member discussion: