核心用法
context-clean-up 是一个审计型运维工具，专为解决 OpenClaw 长期会话中的上下文膨胀（Context Overflow）问题设计。用户通过 /context-clean-up 触发只读审计，或使用 /context-clean-up apply 执行低风险修复。
工作流程分为四步：
1. 确定作用域：定位 OpenClaw 工作目录和状态目录（~/.openclaw）
2. 审计膨胀源：运行内置脚本分析 memory/context-cleanup-audit.json，识别三大类膨胀源——工具输出（exec/read/web_fetch 的长结果）、自动化噪音（Cron/Heartbeat 的重复输出）、引导文档冗余（过大的 MEMORY.md / SOUL.md）
3. 制定修复计划：按风险排序，优先采用三类标准手段：
4. 应用修复（可选）：在 apply 模式下，仅执行安全编辑（cron 静音），用户规则压缩需显式确认
- Lever A：将维护类 cron 作业的输出改为
NO_REPLY，彻底消除自动化噪音 - Lever B：定时报告改用带外投递（Telegram/Slack）+
NO_REPLY，保留通知能力但避免污染主会话 - Lever C：精简引导文档，仅保留重启关键规则，将低频内容移至
memory/或references/
显著优点
- 成本敏感：直接减少 token 消耗，降低长周期运行的 API 账单
- 非侵入式：默认审计模式零副作用，apply 模式带备份和可逆补丁
- 自动化友好：专为 cron/heartbeat 场景设计，解决高频自动化导致的历史记录爆炸
- 架构清晰：区分"交互式会话"与"带外通知"，符合生产级 agent 设计模式
潜在缺点与局限性
- 手动确认瓶颈：Lever C（引导文档压缩）需用户显式同意，无法全自动完成
- 依赖脚本可用性：审计依赖捆绑的 Python 脚本，若环境缺失需手动适配路径
- Telegram 误区：工具特别提示——聊天软件的"自动删除"功能仅影响前端显示，OpenClaw 本地会话日志和模型 prompt 仍保留内容，需配合本工具才能真正减负
- 验证滞后性：修复效果需等待下一次 cron 运行才能确认
适合人群
- 运行7×24 自动化工作流的 OpenClaw 长期会话用户
- 遭遇 "Context overflow error" 或发现 API 成本异常增长的开发者
- 需要同时保留"静默后台维护"和"主动通知"两种模式的多场景部署者
- 追求精益上下文管理的进阶用户（建议配合 openclaw-mem 等记忆层使用）
常规风险
| 风险类型 | 说明 | 缓解措施 |
|---------|------|---------|
| 误静默 | cron 故障时仍输出 `NO_REPLY` 导致告警丢失 | 保留错误/异常输出，仅对 success/no-op 路径强制 `NO_REPLY` |
| 备份丢失 | `.bak.<date>` 文件被清理后无法回滚 | 建议将 `*.bak.*` 纳入版本控制或独立备份策略 |
| 过度压缩 | 精简引导文档时误删重启关键规则 | 用户显式确认机制 + 分阶段验证 |
安全与可信度
来源可信度 T2：MIT 许可证开源工具，由 OpenClaw 生态系统维护，无外部商业依赖。安全等级 A：审计模式零写操作；apply 模式限制为低风险编辑，关键变更需用户确认，符合最小权限原则。