核心用法
Context Budgeting 是一套针对 OpenClaw 有限上下文窗口的系统化管理框架，主要解决三类场景：
- 会话上下文接近上限（>80%）时的主动管控
- 压缩后出现的"记忆丢失"修复
- 长任务运行中的Token成本与延迟优化
信息分区策略将上下文划分为四个功能区块：
- 目标层（10%）：核心任务指令与活跃约束
- 短期历史（40%）：最近5-10轮原始对话
- 决策日志（20%）：过往步骤的摘要化结果（"尝试X，因Y失败"）
- 背景知识（20%）：来自 MEMORY.md 的高相关片段
强制检查点机制要求任何压缩操作前必须：
1. 更新 memory/hot/HOT_MEMORY.md 记录当前进度、关键决策和下一步动作
2. 执行 scripts/gc_and_checkpoint.sh 完成物理清理
Heartbeat集成：每30分钟的心跳作为垃圾回收触发器，自动监控上下文使用率并执行清理。
显著优点
- 预防性架构：在危机发生前（80%阈值）主动干预，而非被动响应
- 可恢复性：检查点机制确保压缩后任务连续性，避免"失忆"导致的重复劳动
- 成本可控：通过信息分层保留高价值内容、丢弃冗余数据，直接降低API调用成本
- 自动化友好：脚本化清理与心跳集成，减少人工干预频率
潜在局限
- 分区比例固定：10/40/20/20 的静态分配可能不适应所有任务类型（如需要大量背景知识的深度研究）
- 检查点开销：高频任务可能需要频繁写盘，引入I/O延迟
- Heartbeat依赖：30分钟固定周期对突发上下文爆炸（如单次返回超大JSON）响应不够及时
- MEMORY.md质量敏感：背景知识层的有效性完全依赖外部记忆文件的相关性筛选
适合人群
- 运行长会话多轮任务的开发者（代码审查、复杂调试、持续性写作）
- 成本敏感型用户（需要精细控制Token消耗）
- 对状态可恢复性有要求的自动化工作流构建者
常规风险
- 检查点遗漏风险：若未严格执行"先写HOT_MEMORY再执行脚本"的顺序，可能导致状态不一致
- 过度压缩：自动化清理可能误删看似冗余、实则后续需要的中间数据
- 分区误判：短期历史与决策日志的边界模糊时，关键推理链条可能断裂
- 脚本权限：
gc_and_checkpoint.sh涉及文件系统操作，需确保执行环境权限配置正确