核心用法
context-clean-up 是 OpenClaw 生态的运维型技能，采用「审计→规划→应用」三段式工作流：
1. 审计阶段：通过 context_cleanup_audit.py 脚本扫描会话转录本，识别三大膨胀源——工具返回结果（exec/read/web_fetch 的冗长输出）、高频自动化噪音（Cron 心跳/定时任务的无意义日志）、以及重复注入的引导文档（MEMORY.md 等规则文件）。
2. 规划阶段：生成低风险的优化方案，核心杠杆包括：
- Lever A：将无操作的 cron 任务输出强制改为
NO_REPLY - Lever B：用户通知类任务采用「外部渠道投递 + NO_REPLY」模式，避免转录本污染
- Lever C：将低频使用的规则迁移至
memory/*.md，仅保留重启关键规则在 MEMORY.md - Lever D：运行
session_gc.py清理超过保留期的失效会话键和孤儿日志文件
3. 应用阶段（需用户显式确认）：执行带 .bak.<date> 备份的安全编辑，将高频噪音 cron 静默化，并采用「移动归档」而非硬删除的策略处理历史日志。
显著优点
- 成本直接可控：减少无效上下文可直接降低 LLM API 调用费用
- 防御 context overflow：系统性解决长周期代理最常见的失效模式
- 零侵入架构：
NO_REPLY模式与现有 cron/heartbeat 兼容，无需重构业务逻辑 - 可逆操作：所有变更带时间戳备份，支持快速回滚
潜在局限
- 人工确认门槛：实际清理操作需用户明确授权，无法全自动执行
- 边界识别依赖启发式：区分「必要日志」与「噪音」依赖规则匹配，可能误判某些边缘场景
- 对「报告类」任务处理保守：为避免漏掉用户真正关心的通知，默认保留非空输出
适合人群
- 运行超过 7 天的长期 OpenClaw 代理用户
- 高频依赖 cron/heartbeat 自动化但遭遇 Context Overflow 的团队
- 对 Token 成本敏感、需优化边际支出的生产环境
常规风险
- 误静默用户关心的通知：若 cron 任务同时承担「状态汇报」功能，强制
NO_REPLY可能导致信息黑洞，建议配合外部渠道（Telegram/Slack）投递 - 归档文件堆积：移动孤儿
.jsonl至备份目录后，长期不清理仍可能占用磁盘，需配合外部存储生命周期策略 - bootstrap 文档压缩过度：若将过多规则移出 MEMORY.md，可能导致代理重启后行为漂移，建议保留「重启临界规则」清单
安全等级说明
技能本身仅执行审计、备份、移动文件等只读或低危写操作，无网络外联、无代码执行漏洞；核心风险在于「误操作导致用户数据不可见」，已通过强制备份和 dry-run 机制缓释。