长期运行时，如何管理会话、记忆与压缩

短期试用 OpenClaw 时，很多问题都还不明显。

但一旦开始长期运行，系统很快会遇到另一类问题：

• 会话越来越长
• 记忆越来越杂
• 压缩越来越频繁
• 团队开始说不清“当前上下文到底算哪一段”

这时候最该补的不是更多功能，而是治理顺序。

第一层：先分清 session 和 memory

最常见的误区，是把 session 和 memory 当成同一件事。

更稳的理解是：

• session 负责当前对话和连续性
• memory 负责跨会话保留下来的长期信息

如果这两层边界不清，后面就会出现：

• 该重置的内容没重置
• 不该长期保存的内容却进了记忆
• 明明换了任务，行为还被旧上下文拖着走

第二层：把 compaction 当成治理动作，不当成魔法

很多团队把 compaction 理解成“系统会自动收好一切”。

更现实的做法是把它看成一次带损压缩：

• 它能延长连续性
• 但不等于不会丢失细节
• 也不等于所有任务都适合同一种压缩节奏

所以更稳的原则通常是：

• 长任务前先确认上下文是否还干净
• 关键节点前主动收束任务边界
• 不把 compaction 当成无限上下文的替代品

第三层：要提前定义重置时机

长期运行最容易积累的问题，不是某一次大故障，而是“系统越来越能跑，但越来越难判断”。

比较值得预先定义的重置时机包括：

• 任务已经彻底切换
• 角色或使用人已经变化
• 渠道上下文已经失真
• 压缩后输出质量明显下降
• 长期记忆开始污染当前决策

如果没有重置规则，团队最后通常会陷入两种极端：

• 该重置时不敢重置
• 一出问题就整套重置

第四层：不同入口要有不同连续性预期

长期运行里，最忌讳所有入口都共用同一种会话预期。

更稳的方式通常是：

• 管理面入口：更偏检查和控制，不承担长对话
• 日常聊天入口：承担连续性，但要有明确 session 键和边界
• 自动化或外部触发入口：默认更短、更可回收

只有把入口和连续性拆开，session 才不会越跑越糊。

第五层：把“长期连续”拆成可观察的信号

长期运行不是感觉系统“最近怪怪的”，而是要能看出信号：

• 压缩频率是否变高
• 重试和投递异常是否变多
• 模型输出是否更容易失焦
• 哪类任务更容易被旧上下文拖偏

当这些信号稳定出现时，通常就不是单个 prompt 的问题，而是治理边界已经该调整。

中文站建议的治理顺序

对多数长期运行环境来说，更稳的顺序通常是：

1. 先明确 session 键和入口边界
2. 再明确哪些信息该进入 memory
3. 再决定 compaction 的容忍度
4. 最后补重置和清理规则

这样会比一开始就追求“永不断线”更容易长期维护。

最适合沉淀成规则的 4 件事

• 哪些任务完成后必须重置 session
• 哪些记忆可以长期保留，哪些不该进 memory
• 哪些入口只允许短会话
• 当输出开始失焦时，先检查什么

下一步推荐

• Session 与配对机制
• 记忆系统
• 系统提示、上下文与压缩
• Session 重置策略