| 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、什么只保留引用”的策略表
- 一份上下文溢出恢复梯子
