24｜五层递进式上下文防护：如何应对 Token 爆炸问题？
Henry
你好，我是 Henry，欢迎来到《OpenClaw 核心原理与实战》。
提到上下文压缩，我们过去最注意的是压缩什么时候触发、摘要怎么分块、标识符怎么保留。这节课我们要把视角切换到系统架构师的角度，深入解析 OpenClaw 从启动前检查、到运行时自动压缩、到溢出恢复、到超大结果截断、再到历史裁剪的完整防御纵深体系。OpenClaw 用五层递进式防护来应对 Token 爆炸问题，每一层都是上一层的兜底，代价逐层递增。
这里你可能会想，为什么把上下文防护作为“故障转移与高可用”模块的开篇？因为 Token 爆炸本质上就是一种“故障”，当上下文溢出时，LLM API 直接拒绝请求，Agent 瘫痪。上下文防护是 Agent 高可用的第一道防线。只有理解了这道防线，你才能理解为什么故障转移链会特殊处理上下文溢出。
Token 爆炸：为什么它是 Agent 的致命威胁
上下文窗口有多大？每个大语言模型都有上下文窗口限制，就像一个容量有限的“记忆容器”。
看起来很大，但在 Agent 场景下，Token 消耗速度比你想象的快得多。一个粗略的测算：
System Prompt：约 2K tokens
工具声明（Tools Schema）：约 5K tokens
10 轮对话历史：约 20K tokens
一次 bash("cat large-file.txt") 的结果：可能 50K+ tokens
一次浏览器截图的 base64 编码：可能 100K+ tokens
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《OpenClaw 核心原理与实战》，新⼈⾸单¥59
《OpenClaw 核心原理与实战》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论