LLM 的 Context Window 有上限，长对话时如何保证 Agent 仍然能正常工作？OpenClaw 是怎么做的？

🏛 业务架构师

长对话下保证 Agent 正常工作，OpenClaw 的策略是"分层的上下文预算管理"，我也是这么给企业做设计的：

第一层·滑动窗口：只保留最近 N 轮完整对话，更早的直接出窗——最简单的基础策略。

第二层·滚动摘要：出窗的历史不丢弃，而是压缩成"会话纪要"（关键结论、待办、用户偏好）注入 System Prompt 附近——低成本保住长期脉络。

第三层·重要信息外置：关键事实（确认过的订单号、达成的共识）提取到结构化存储，需要时按需召回，不占常驻窗口。

第四层·Compaction 兜底：当上下文逼近窗口上限时，触发整体压缩——把全部历史重写为高密度摘要，腾出空间继续对话。用户无感知，但"记忆"从明细级降为摘要级。

配套机制：token 预算表（系统提示/历史/工具结果各占多少配额）、工具返回结果即时截断、循环步数熔断。

业务视角的取舍心法：上下文管理的本质是"有损压缩下的信息保值"——什么必须原样保留（合规承诺、用户确认过的关键数据）、什么可以摘要（过程性讨论）、什么可以丢弃（寒暄），这些按业务风险分级，而不是按技术方便一刀切。会话纪要同时是审计素材，摘要策略要兼顾这两重价值。

OpenClaw 应对长对话的策略是**"裁剪 + 摘要 + 压缩 + 外置"的组合拳**，我按激进程度递进：

滑动窗口裁剪（第一道）：只保留最近 N 轮原文，更早的丢弃——最简单但丢上下文，作为兜底策略；
滚动摘要（Summarization）：旧对话段异步摘要成"会话纪要"（关键决策、事实、承诺、未完成任务），替换原文占据头部位置——信息密度大幅提升，代价是细节有损；
Compaction（压缩整理）：窗口逼近上限时触发的系统性压缩——把"完整历史 + 摘要"重组为一份结构化状态快照（任务状态、已确认事实、待办、关键文件引用），等价于"把内存 dump 成精简的进程控制块"；
外部记忆（外置）：超出叙事需要的细节（工具结果、中间产物）落盘存储，上下文里只留指针/摘要，需要时再检索回来（记忆库回收）；
分层保留策略：System Prompt 与关键约束永远保留（不可压缩），工具结果超限时截断/转存，寒暄类内容优先丢弃。

工程要点：压缩是异步旁路（不阻塞用户当前交互）；压缩前后跑一致性检查（关键事实不丢失）；压缩触发点留余量（85% 窗口水位触发，不要 100% 才动）。

架构本质：这就是操作系统内存页换出（swap）的 Agent 版——窗口是 RAM，记忆库是磁盘，摘要就是页压缩。

长对话下保证 Agent 正常工作的核心是上下文预算管理，OpenClaw 的做法（也是我认可的工程方案）：

1. 分层裁剪（滑动窗口）：最近 N 轮保原文（短期连贯性优先），更早的逐层降级——先丢工具结果的原文只留摘要，再丢旧轮次细节。

2. Compaction（压缩重组）：当对话 token 触达阈值（比如窗口的 70%），触发压缩任务：用 LLM 把旧历史总结成结构化摘要——关键事实、已做决定、未完事项、用户偏好——替换原文区。压缩后上下文形态是：

[System Prompt]（永不压缩）
[会话摘要]（Compaction 产物，持续更新）
[关键事实列表]（外置记忆检索回来）
[最近 2~4 轮原文]
[当前消息]

3. 记忆外置：重要信息（用户说过的偏好、任务结论）在压缩前抽取写入长期记忆，需要时检索回来——压缩不是丢，是转存。

4. 预算仪表：每轮组装上下文前先计算各分区占比，超预算按优先级挤占（工具结果摘要 > 旧轮原文 > 检索记忆条数）。

踩坑提醒：压缩时机别等爆窗口才做（压缩本身也要 token，要在余量内完成）；压缩会丢细节，涉及精确数字/代码的任务把关键产物落盘成文件、上下文里只放文件引用；压缩后第一轮回复质量会抖动，prompt 里要求摘要保留「当前任务目标」原文，防目标漂移。