| name | context-hygiene-system |
| description | 面向 OpenClaw 的长上下文卫生系统技能。用于设计或审计 memory、skill 注入、工具输出预算、压缩、去重、恢复与长会话稳定性。 |
上下文卫生系统
这是什么
长会话不是“窗口快满时总结一下”那么简单。真正的问题是:
- 哪些内容应该进入上下文
- 哪些只该保留引用
- 哪些应该压缩
- 哪些要延迟注入
- 爆上下文后如何恢复,而不是直接报错
这个 skill 用来把长上下文管理做成一套持续清洁系统。
在 OpenClaw 里何时使用
- 会话很长,回答开始变笨
- 工具输出很大,塞满上下文
- memory / skills / tool results 混在一起太重
- 想优化长时间运行 agent 的稳定性
- 想设计压缩与恢复流程
核心原则
- 不是所有内容都值得进主上下文。
- 工具输出要先预算,不能先塞进去再后悔。
- 压缩要分层,不要一上来就全量总结。
- 最近的高价值细节通常比早期的大段粗摘要更重要。
- 错误先尝试恢复,再决定是否暴露给用户。
OpenClaw 中最常见的上下文来源
- system / workspace prompt
- skills 说明
- memory 片段
- 工具输出
- 历史消息
- 附件或外部抓取内容
- 子 agent 回传结果
实战建议
- 大工具输出优先保存在文件或引用路径里,不直接长贴进 prompt。
- skill 列表应短小高信号,别把整个技能库说明都塞进去。
- memory 只读必要片段,别每次全量载入。
- 长网页、长文档、长日志先提取摘要,再按需补读。
- 子 agent 回传只给摘要和产物路径,不灌完整 transcript。
推荐的压缩顺序
- 先删冗余
- 再缩局部工具输出
- 再把旧轮次做更粗粒度摘要
- 最后才考虑全局级 autocompact
恢复思路
当上下文太长或响应失败时:
- 优先减少工具结果体积
- 再减少低价值历史
- 再减少技能和附加上下文
- 再重建一个更轻的任务视图
- 只有恢复失败后,才把错误暴露出来
常见失败模式
- 把大段命令输出直接灌进 prompt。
- 每轮都重复注入几乎不变的技能说明。
- memory 读取过量,导致新任务预算被吃光。
- 一爆上下文就直接报错,没有恢复阶梯。
- 压缩后没重建预算,导致后续判断继续失真。
OpenClaw 落地建议
- 把大结果写文件,再给路径。
- 让技能说明保持短而准。
- 只在真正需要的时候读 memory 细节。
- 对多轮调试任务,定期给出阶段总结,减少重复历史依赖。
- 设计“轻上下文继续执行”的兜底策略。
你可以产出的东西
- 一张 OpenClaw 上下文来源图
- 一份“什么该进 prompt、什么只保留引用”的策略表
- 一份上下文溢出恢复梯子