OpenClaw上下文修剪与缓存TTL策略

前言

AI 模型的上下文窗口是有限的。即使是最先进的模型，上下文窗口也不过几十万 Token。当对话持续进行、消息不断累积时，如何管理上下文就成了一个至关重要的问题。OpenClaw 提供了一套精细的上下文修剪（Context Pruning）机制，结合基于 TTL（Time-To-Live）的缓存策略，在保证对话质量的同时最大化地节省 Token 消耗。

本文将详细解析这套机制的原理和配置方法。

上下文管理的挑战

在长对话中，直接将所有历史消息作为上下文传递给模型会面临几个问题：

Token 成本飙升：每次 API 调用都会发送全部历史，输入 Token 费用线性增长
上下文溢出：超过模型窗口限制后请求直接失败
噪声干扰：过早的消息可能与当前话题无关，反而干扰模型判断
延迟增加：输入 Token 越多，模型首次响应的时间越长

OpenClaw 通过多层修剪策略系统性地解决这些问题。

修剪策略层级

OpenClaw 的上下文修剪分为四个层级，从粗到细依次执行：

原始消息历史
    ↓
Layer 1: 消息数量限制（maxMessages）
    ↓
Layer 2: Token 数量限制（maxTokens）
    ↓
Layer 3: TTL 时间衰减（cache TTL）
    ↓
Layer 4: 智能压缩（compaction）
    ↓
最终上下文 → 发送给模型

Layer 1：消息数量限制

最基础的策略，限制保留的最大消息数：

{
  agents: {
    "my-agent": {
      context: {
        // 最多保留50条消息
        maxMessages: 50,
        // 按频道类型差异化
        channelOverrides: {
          dm: { maxMessages: 80 },
          group: { maxMessages: 20 }
        }
      }
    }
  }
}

超出限制时，最旧的消息会被丢弃（但仍保留在 JSONL 文件中，不会物理删除）。

Layer 2：Token 数量限制

更精确的控制，基于实际 Token 数：

{
  agents: {
    "my-agent": {
      context: {
        // 上下文最大Token数（不含系统提示词）
        maxTokens: 16000,
        // 为模型回复预留的Token数
        reservedOutputTokens: 4000,
        // Token计算方式
        tokenCounter: "tiktoken"  // 精确计算
      }
    }
  }
}

OpenClaw 会从最新的消息开始往回计算 Token，当累计超过 maxTokens 时停止，丢弃更早的消息。

Layer 3：TTL 时间衰减（核心特性）

这是 OpenClaw 最独特的上下文管理策略。基于消息的时间戳，对不同"年龄"的消息施加不同的保留策略：

{
  agents: {
    "my-agent": {
      context: {
        ttl: {
          enabled: true,
          // TTL 规则（从近到远）
          rules: [
            {
              // 最近5分钟内的消息：全部保留
              maxAge: "5m",
              keep: "all"
            },
            {
              // 5分钟-1小时的消息：保留最近20条
              maxAge: "1h",
              keep: 20
            },
            {
              // 1-6小时的消息：保留最近10条
              maxAge: "6h",
              keep: 10
            },
            {
              // 6-24小时的消息：仅保留摘要
              maxAge: "24h",
              keep: "summary"
            },
            {
              // 超过24小时的消息：不包含在上下文中
              maxAge: "inf",
              keep: "none"
            }
          ]
        }
      }
    }
  }
}

TTL 策略的设计思想

人类对话有一个天然的时间衰减特性：5 分钟前的对话内容几乎都是相关的，1 小时前的可能部分相关，昨天的对话大概率已经换了话题。TTL 策略正是模拟了这种自然衰减。

keep 选项说明

值	含义
`"all"`	保留该时间段内的所有消息
`数字`	保留该时间段内最近的 N 条消息
`"summary"`	将该时间段的消息压缩为一段摘要
`"none"`	完全不包含该时间段的消息

Layer 4：智能压缩

当 TTL 规则指定 keep: "summary" 时，OpenClaw 会自动对该时间段的消息执行智能压缩：

{
  agents: {
    "my-agent": {
      context: {
        compaction: {
          enabled: true,
          // 压缩使用的模型（可以用更便宜的模型）
          model: "gpt-4o-mini",
          // 摘要的最大Token数
          summaryMaxTokens: 512,
          // 压缩提示词
          summaryPrompt: "请将以下对话内容压缩为简洁的摘要，保留关键信息和用户偏好：",
          // 缓存压缩结果
          cacheSummary: true,
          // 摘要缓存TTL
          summaryCacheTTL: "1h"
        }
      }
    }
  }
}

缓存机制详解

上下文缓存

OpenClaw 会缓存已经构建好的上下文，避免每次请求都重新计算：

{
  agents: {
    "my-agent": {
      context: {
        cache: {
          enabled: true,
          // 缓存失效条件
          invalidateOn: [
            "new_message",     // 有新消息时失效
            "config_change"    // 配置变更时失效
          ],
          // 缓存存储方式
          storage: "memory",   // memory / redis
          // 最大缓存条目数
          maxEntries: 1000
        }
      }
    }
  }
}

Prompt 缓存（Provider 级别）

部分 AI 提供商支持 Prompt Caching（如 Anthropic、OpenAI），OpenClaw 会自动利用这一特性：

{
  agents: {
    "my-agent": {
      context: {
        providerCache: {
          enabled: true,
          // 系统提示词设为可缓存（因为它很少变化）
          cacheSystemPrompt: true,
          // 将最近N条消息标记为可缓存前缀
          cacheableMessageCount: 10
        }
      }
    }
  }
}

Prompt Caching 可以将重复的上下文前缀的费用降低最多 90%，非常适合系统提示词较长的场景。

实际配置示例

个人助手（长对话、深度记忆）

{
  context: {
    maxMessages: 100,
    maxTokens: 32000,
    ttl: {
      enabled: true,
      rules: [
        { maxAge: "30m", keep: "all" },
        { maxAge: "4h", keep: 30 },
        { maxAge: "24h", keep: "summary" },
        { maxAge: "inf", keep: "none" }
      ]
    },
    compaction: { enabled: true, summaryMaxTokens: 1024 }
  }
}

客服机器人（短对话、快速响应）

{
  context: {
    maxMessages: 30,
    maxTokens: 8000,
    ttl: {
      enabled: true,
      rules: [
        { maxAge: "10m", keep: "all" },
        { maxAge: "1h", keep: 10 },
        { maxAge: "inf", keep: "none" }
      ]
    }
  }
}

群聊机器人（高频消息、低上下文需求）

{
  context: {
    maxMessages: 15,
    maxTokens: 4000,
    ttl: {
      enabled: true,
      rules: [
        { maxAge: "5m", keep: "all" },
        { maxAge: "30m", keep: 5 },
        { maxAge: "inf", keep: "none" }
      ]
    }
  }
}

监控与调优

查看上下文使用情况

# 查看某Agent的上下文统计
openclaw agent stats my-agent --context

# 输出示例：
# 当前会话数: 45
# 平均上下文Token: 8,234
# 最大上下文Token: 28,102
# 压缩执行次数: 12
# 缓存命中率: 73%

上下文使用告警

{
  monitoring: {
    alerts: [{
      name: "context-overflow-warning",
      condition: "context_tokens > maxTokens * 0.9",
      action: "log_warning"
    }]
  }
}

小结

上下文管理是 AI Agent 运营中最影响成本和质量的环节之一。OpenClaw 的四层修剪策略——消息数限制、Token 限制、TTL 时间衰减和智能压缩——为你提供了从粗到细的精确控制。其中 TTL 时间衰减策略是 OpenClaw 的独特设计，它模拟了人类对话的自然时间衰减特性，在保证近期上下文完整性的同时大幅降低了远期消息的 Token 消耗。结合 Prompt 缓存和上下文缓存机制，你可以在不影响对话质量的前提下，显著优化 Token 成本。