Context Hygiene System

上下文卫生系统

这是什么

长会话不是“窗口快满时总结一下”那么简单。真正的问题是：

1. 哪些内容应该进入上下文
2. 哪些只该保留引用
3. 哪些应该压缩
4. 哪些要延迟注入
5. 爆上下文后如何恢复，而不是直接报错

这个 skill 用来把长上下文管理做成一套持续清洁系统。

在 OpenClaw 里何时使用

1. 会话很长，回答开始变笨
2. 工具输出很大，塞满上下文
3. memory / skills / tool results 混在一起太重
4. 想优化长时间运行 agent 的稳定性
5. 想设计压缩与恢复流程

核心原则

1. 不是所有内容都值得进主上下文。
2. 工具输出要先预算，不能先塞进去再后悔。
3. 压缩要分层，不要一上来就全量总结。
4. 最近的高价值细节通常比早期的大段粗摘要更重要。
5. 错误先尝试恢复，再决定是否暴露给用户。

OpenClaw 中最常见的上下文来源

1. system / workspace prompt
2. skills 说明
3. memory 片段
4. 工具输出
5. 历史消息
6. 附件或外部抓取内容
7. 子 agent 回传结果

实战建议

1. 大工具输出优先保存在文件或引用路径里，不直接长贴进 prompt。
2. skill 列表应短小高信号，别把整个技能库说明都塞进去。
3. memory 只读必要片段，别每次全量载入。
4. 长网页、长文档、长日志先提取摘要，再按需补读。
5. 子 agent 回传只给摘要和产物路径，不灌完整 transcript。

推荐的压缩顺序

1. 先删冗余
2. 再缩局部工具输出
3. 再把旧轮次做更粗粒度摘要
4. 最后才考虑全局级 autocompact

恢复思路

当上下文太长或响应失败时：

1. 优先减少工具结果体积
2. 再减少低价值历史
3. 再减少技能和附加上下文
4. 再重建一个更轻的任务视图
5. 只有恢复失败后，才把错误暴露出来

常见失败模式

1. 把大段命令输出直接灌进 prompt。
2. 每轮都重复注入几乎不变的技能说明。
3. memory 读取过量，导致新任务预算被吃光。
4. 一爆上下文就直接报错，没有恢复阶梯。
5. 压缩后没重建预算，导致后续判断继续失真。

OpenClaw 落地建议

1. 把大结果写文件，再给路径。
2. 让技能说明保持短而准。
3. 只在真正需要的时候读 memory 细节。
4. 对多轮调试任务，定期给出阶段总结，减少重复历史依赖。
5. 设计“轻上下文继续执行”的兜底策略。

你可以产出的东西

1. 一张 OpenClaw 上下文来源图
2. 一份“什么该进 prompt、什么只保留引用”的策略表
3. 一份上下文溢出恢复梯子