跳转至

第 11 篇 · 上下文压缩：让 Agent 在长会话中持续工作

Ch04.713 第 11 篇 · 上下文压缩：让 Agent 在长会话中持续工作

📊 Level ⭐⭐ | 4.1KB | entities/agent-context-compression-yexiaochai-11.md

第 11 篇 · 上下文压缩：让 Agent 在长会话中持续工作

Author: 叶小钗 | Source: 微信公众号

本文是叶小钗 Agent 系列教程的第 11 篇，聚焦于 Agent 上下文压缩的原理与实现。介绍了上下文窗口概念、Agent 上下文增长的原因、上下文过长带来的问题，以及上下文压缩的三种策略（消息丢弃、消息摘要、滑动窗口 + 摘要），并结合 mini-openclaw 项目源码说明了压缩触发时机、消息切分、摘要生成和上下文重建的实现。

上下文窗口与 Agent 上下文增长

每个大模型都有一个上下文窗口（context window），当前主流模型已普遍提升到 100 万 token 左右（DeepSeek V4 Flash/Pro: 1M, GPT-5.6: 1.05M, Claude Sonnet 5: 1M, Gemini 3.5 Flash: 1M）。每次模型调用时，上下文占用 = system prompt + user 消息 + assistant 历史消息 + tool definitions + tool 调用结果 + 多模态内容 + 模型本轮输出。

Agent 上下文增长迅速的原因在于：大模型是无状态的，每次调用需要重新组装全部历史消息；而工具调用结果（文件全文、搜索结果、命令行输出、API/MCP 返回值）通常比用户输入和模型输出占用更多 token。

上下文超过模型上限后，API 请求会直接失败，这是长会话 Agent 必须解决的工程问题。

三种压缩策略

1. 消息丢弃

对消息按重要性分级，保留关键消息（工具调用结果、关键回复），丢弃低优先级消息（问候语、确认性回复）。实现简单但可能丢失有用信息。

2. 消息摘要

对多轮历史消息生成摘要，仅保留摘要文本。优点是压缩比高（多轮→一段话），缺点是摘要会丢失具体细节（代码片段、API 返回值）。

3. 滑动窗口 + 摘要

综合方案：保留最近的 K 轮完整消息（滑动窗口），对更早的历史进行摘要压缩。兼顾了近期细节和远期上下文。

mini-openclaw 实现

在 mini-openclaw 项目中，上下文压缩在每次收到新的消息时进行判断。如果当前会话占用接近上下文窗口上限，则触发压缩流程：

  1. 消息切分：将历史消息分为保留区（最近的 N 轮对话）和压缩区（更早的消息）
  2. 摘要生成：对压缩区的消息逐段生成摘要，使用独立 LLM 调用进行压缩
  3. 上下文重建：将保留区完整消息 + 压缩区的摘要合并为新的 messages 数组，替换原有的全部历史消息

核心实现在 context_compressor.py 的 compress() 方法中，采用 LLM 驱动的摘要压缩策略。代码逻辑包括消息长度统计、压缩触发阈值判断、保留轮次配置和摘要 prompt 模板。

相关实体

相关概念