引言：Agent 系统的上下文窗口困境

在大语言模型（LLM）快速发展的今天，Agent 系统的能力边界不断拓展，然而上下文窗口（Context Window）始终是制约其发展的核心瓶颈之一。每个模型都有其固定的 token 容量限制——无论是 32K、128K 还是更长的上下文窗口，都会在漫长的多轮对话中逐渐耗尽。当上下文窗口被填满时，Agent 将面临一个两难境地：要么截断早期的重要信息，要么直接触发溢出错误导致对话中断。

传统的解决方案往往简单粗暴：直接丢弃最旧的消息，或在溢出时重启对话。这两种方式都会造成严重的信息丢失——用户之前的偏好设置、关键决策上下文、长期积累的知识都将化为乌有。对于需要持续学习和个性化交互的 Agent 系统而言，这种代价是不可接受的。

上下文压缩与记忆刷新机制正是为解决这一困境而设计的技术方案。它不是简单地丢弃旧数据，而是通过智能化的方式将历史对话压缩为紧凑摘要，同时在压缩前主动触发记忆刷新操作，确保重要信息能够持久化存储。这种机制既保证了对话的连续性，又实现了知识的长期积累。

本文将深入解析 OpenClaw 系统中上下文压缩与记忆刷新机制的实现原理、配置方法以及最佳实践，帮助开发者更好地理解和使用这一关键技术。

核心价值概述：

  • 避免信息丢失：通过智能压缩保留关键上下文
  • 主动记忆保护：在压缩前主动刷新重要信息到持久化存储
  • 无缝对话体验：用户感受不到压缩过程，对话持续流畅
  • 可配置策略：灵活的阈值和模式选择，满足不同场景需求

自动压缩触发条件

OpenClaw 的上下文压缩机制设计了两种自动触发条件，分别应对不同的场景需求。这两种模式相互配合，确保系统在各种情况下都能优雅地处理上下文溢出问题。

模式一：Overflow Recovery（溢出恢复）

当模型在处理请求时返回上下文溢出错误（Context Overflow Error），系统将自动触发压缩流程。这是一种被动响应式的触发机制。

触发流程：

用户消息 → 模型处理 → 返回溢出错误 → 压缩历史对话 → 重试请求

具体步骤如下：

  1. 错误检测：系统捕获模型返回的上下文溢出错误
  2. 自动压缩：对历史对话进行总结，生成紧凑摘要
  3. 重试请求：压缩完成后，自动重新发送原始请求

这种模式的优点是简单直接，能够在溢出发生的瞬间立即响应。但它的缺点也很明显：压缩发生在错误之后，用户需要等待压缩完成才能继续对话。如果频繁触发溢出恢复，会影响用户体验。

模式二：Threshold Maintenance（阈值维护）

这是一种主动预防式的触发机制，在上下文即将耗尽之前就提前进行压缩，避免溢出错误的发生。

触发条件：

当一个成功的对话轮次（turn）完成后，系统会检查当前的上下文使用量：

contextTokens > contextWindow - reserveTokens

其中：

  • contextTokens：当前会话的 token 估计值
  • contextWindow：模型的最大上下文窗口大小
  • reserveTokens：为系统提示词和下一次模型输出预留的空间

预留空间的作用：

reserveTokens 参数至关重要，它确保压缩后的上下文不会立即再次触发溢出。具体来说：

  • 系统提示词（System Prompt）需要占用一定空间
  • 下一次模型输出的初始部分也需要空间
  • 设置合理的 reserveTokens 可以避免压缩后立即溢出的尴尬境地

例如，对于 32K 上下文的模型，如果设置 reserveTokens = 4096，那么当已使用 token 超过 28K 时，系统就会自动触发压缩。

两种模式的对比

特性 Overflow Recovery Threshold Maintenance
触发时机 溢出错误发生后 溢出错误发生前
响应方式 被动响应 主动预防
用户体验 可能需要等待 无感知
适用场景 突发大量输入 常规长对话

配置说明

在 OpenClaw 中，可以通过配置文件调整压缩行为：

{
  agents: {
    defaults: {
      compaction: {
        mode: "safeguard",  // default | safeguard
        // 其他配置...
      },
    },
  },
}
  • default 模式：严格遵循上述两种触发条件
  • safeguard 模式：在 default 基础上增加更多安全保护机制

Threshold Maintenance 模式是保证对话连续性的关键设计，它让压缩过程对用户透明，实现了真正的"无缝"体验。

Pre-compaction 静默轮次：记忆刷新的核心机制

在自动压缩触发之前，OpenClaw 引入了一个关键的预压缩内存刷新（Pre-compaction Memory Flush）机制。这是一种主动式的信息保护策略，确保在上下文被压缩之前，重要的持久化信息已经安全写入磁盘。

为什么需要 Pre-compaction Flush？

传统的压缩机制存在一个致命缺陷：压缩过程中，历史对话中的重要信息（如用户偏好、关键决策、任务进度）可能会在未经确认的情况下被总结和丢弃。即使压缩算法尽力保留关键信息，也无法保证所有持久化需求都能被满足。

Pre-compaction Flush 的设计理念是：在压缩发生之前，给 Agent 一个主动整理和保存重要信息的机会。

实现原理

软阈值触发

Pre-compaction Flush 使用一个"软阈值"（softThresholdTokens）来提前触发内存刷新：

flush触发时机 = contextWindow - reserveTokensFloor - softThresholdTokens

这个阈值低于压缩触发的阈值，从而确保：

  1. 内存刷新先于压缩执行
  2. 有足够的时间完成持久化操作
  3. 压缩时可以使用刷新后的信息

静默执行机制

Pre-compaction Flush 通过静默轮次（Silent Turn）实现，具体流程如下：

检测到软阈值 → 发起静默 agentic turn → 
Agent 执行记忆刷新 → 用户无感知 → 
继续正常对话 → 触发压缩时使用刷新后的上下文

关键点在于：这个额外的对话轮次对用户是完全不可见的。

NO_REPLY 协议

为了实现真正的静默执行，OpenClaw 引入了 NO_REPLY 协议：

  1. 标记机制：助手输出以 NO_REPLY 开头时，表示"不向用户发送回复"
  2. 交付层处理：OpenClaw 在消息交付层自动剥离/抑制这类输出
  3. 流式输出抑制：自 2026.1.10 起，即使部分 chunk 以 NO_REPLY 开头，也会抑制 draft/typing 流式输出

默认配置下，Pre-compaction Flush 使用的提示词包含 NO_REPLY 指令：

{
  agents: {
    defaults: {
      compaction: {
        memoryFlush: {
          enabled: true,
          softThresholdTokens: 6000,
          systemPrompt: "Session nearing compaction. Store durable memories now.",
          prompt: "Write any lasting notes to memory/YYYY-MM-DD.md; reply with NO_REPLY if nothing to store.",
        },
      },
    },
  },
}

执行约束

Pre-compaction Flush 在以下条件下会跳过执行：

  • 仅对嵌入式 Pi sessions 执行：CLI 后端会跳过此机制
  • 仅执行一次 per 压缩周期：通过 sessions.json 中的 memoryFlushCompactionCount 追踪
  • workspace 只读时跳过：当 session workspace 为只读状态时，不执行刷新
  • 每压缩周期仅执行一次：防止频繁触发

Session Store 关键字段

系统通过以下字段追踪内存刷新状态：

{
  "compactionCount": 5,                    // 自动压缩完成次数
  "memoryFlushAt": 1705238400000,          // 最后一次预压缩内存刷新的时间戳
  "memoryFlushCompactionCount": 3          // 最后一次刷新时的压缩计数
}

这些字段确保：

  • 每次压缩周期只触发一次 flush
  • 可以追踪内存刷新的历史
  • 系统重启后能正确恢复状态

实际效果

通过 Pre-compaction Flush 机制：

  • 用户侧：完全无感知，对话流畅持续
  • 系统侧：主动保护重要信息，确保不丢失
  • Agent 侧：获得主动整理记忆的机会，提升长期服务能力

这是 OpenClaw 实现真正"可持续"对话的关键技术创新。

记忆刷新提示词设计

Pre-compaction Memory Flush 的核心在于提示词设计。合理的提示词能够引导 Agent 正确识别需要持久化的信息，并按照预期的格式保存到 memory 文件中。

提示词的双层结构

OpenClaw 的 Pre-compaction Flush 使用双层提示词设计：

1. System Prompt（系统提示词）

系统提示词提供背景上下文，告诉 Agent 当前会话处于什么状态：

systemPrompt: "Session nearing compaction. Store durable memories now."

翻译：会话即将进行压缩，现在存储持久记忆。

这个提示词的作用：

  • 状态告知：让 Agent 知道即将发生压缩
  • 行动导向：明确指示需要"存储"记忆
  • 简洁明确：不包含复杂指令，降低理解成本

2. User Prompt（用户提示词）

用户提示词提供具体操作指令，告诉 Agent 具体要做什么：

prompt: "Write any lasting notes to memory/YYYY-MM-DD.md; reply with NO_REPLY if nothing to store."

翻译：将任何持久的笔记写入 memory/YYYY-MM-DD.md；如果没有需要存储的内容，回复 NO_REPLY。

这个提示词的作用：

  • 明确目标文件：指定写入路径（自动使用当天日期）
  • 操作指令：告诉 Agent 写入内容
  • 退出条件：如果没有需要存储的内容，回复 NO_REPLY

最佳实践

原则一：简洁明确

提示词应该简短清晰，避免复杂的指令结构。Agent 在执行 flush 时已经处于高负荷状态，复杂的提示词会增加失败风险。

推荐：

Write important notes to memory/YYYY-MM-DD.md

不推荐：

Please analyze the current conversation and identify any important information that should be persisted, such as user preferences, important decisions, task progress, or any other relevant context. Write these in a well-structured format to the daily memory file.

原则二：明确输出格式

如果需要特定格式，应该在提示词中明确说明：

prompt: "Extract key decisions and user preferences to memory/YYYY-MM-DD.md in bullet points. Reply with NO_REPLY if nothing critical."

原则三：提供退出机制

NO_REPLY 机制非常重要，它允许 Agent 在没有重要信息需要保存时快速退出，避免产生无意义的空文件。

原则四：考虑时间因素

文件命名使用 YYYY-MM-DD.md 格式是精心设计的选择：

  • 自动按日期组织，便于后续检索
  • 每日一个文件，文件不会过大
  • 符合人类自然的时间观念

自定义提示词示例

根据不同场景，可以自定义提示词：

场景一：强调用户偏好

{
  memoryFlush: {
    systemPrompt: "会话即将压缩。优先保存用户偏好和设置。",
    prompt: "将用户偏好、重要设置和关键决策记录到 memory/YYYY-MM-DD.md。格式：## 用户偏好\n- [偏好项]。回复 NO_REPLY 如无需保存。"
  }
}

场景二：强调任务进度

{
  memoryFlush: {
    systemPrompt: "Session nearing compaction. Focus on task progress.",
    prompt: "Document current task status, pending items, and important context to memory/YYYY-MM-DD.md. Reply with NO_REPLY if nothing urgent."
  }
}

场景三：多语言支持

{
  memoryFlush: {
    systemPrompt: " 会话即将压缩。保存重要信息。",
    prompt: "请将以下内容写入 memory/YYYY-MM-DD.md：\n1. 用户提供的重要信息\n2. 已完成的关键操作\n3. 待处理的任务\n如无重要内容请回复 NO_REPLY。"
  }
}

注意事项

  1. 避免与主对话混淆：flush 轮次在当前 session 上下文中执行，会继承对话历史；"独立"仅指输出不发送给用户（NO_REPLY）
  2. 文件路径正确性：默认使用当天日期文件，确保目录存在
  3. 错误处理：如果写入失败，Agent 应该能够感知并通过其他方式记录

通过精心设计的提示词，Pre-compaction Flush 机制能够高效、准确地将重要信息持久化，为压缩后的对话提供信息保障。

重要信息持久化策略：双层 Memory 架构

OpenClaw 采用了精心设计的双层 Memory 架构来实现重要信息的持久化存储。这种架构既满足了短期快速访问的需求，又支持长期知识的积累和检索。

双层 Memory 架构

第一层：每日日志（Daily Notes）

文件位置：memory/YYYY-MM-DD.md

特点：

  • 每日创建一个新文件
  • 持续追加写入，不覆盖历史
  • 记录当天的所有重要事件、决策、上下文

适用场景：

  • 记录对话中的关键信息
  • 追踪任务进度和待办事项
  • 保存临时但重要的上下文

第二层：长期记忆（Long-term Memory）

文件位置：MEMORY.md

特点：

  • 全局单一文件（仅在主 session 加载）
  • 策展式更新，不频繁修改
  • 存储需要长期保留的核心信息

适用场景：

  • 用户偏好和设置
  • 重要决策和结论
  • 跨会话的持续知识

为什么要双层架构？

单层架构面临的挑战：

挑战 单层架构 双层架构
文件大小 无限增长，检索困难 分离管理，按需加载
加载策略 全部加载，内存压力大 按场景加载，灵活控制
更新策略 频繁覆盖，风险高 策展更新，稳定可靠
检索效率 全量搜索，速度慢 分层索引，精准定位

Memory 工具

OpenClaw 提供了两个核心的 Memory 工具：

1. memory_search（语义搜索）

用于在 Memory 文件中进行语义检索：

{
  // 自动将内容分块为 ~400 token
  // 相邻 chunk 之间有 80 token 重叠
  // 支持语义理解和关键词匹配
}

功能特性：

  • 语义理解：基于向量嵌入的语义搜索
  • 分块策略：自动将长文本分块，支持重叠
  • 混合搜索：结合 BM25 和向量搜索

2. memory_get（精确读取）

用于精确读取特定行范围：

{
  // 支持指定 from（起始行）和 lines（行数）
  // 适合已知位置的精确读取
  // 返回包含截断/继续信息
}

功能特性：

  • 精确访问：按行号精确读取
  • 边界处理：自动处理文件边界
  • 截断提示：告知是否有更多内容

向量搜索机制

OpenClaw 的向量搜索机制是其 Memory 系统的核心技术：

Provider 自动选择

系统按优先级自动选择向量搜索 provider：

local → openai → gemini → voyage → mistral

这确保了即使某些 provider 不可用，也能降级到其他选项。

搜索特性

  1. 混合搜索：结合 BM25（文本匹配）和向量搜索

    • vectorWeight + textWeight 自动归一化为 1.0

  2. MMR 重排序：使用 Maximal Marginal Relevance

    • lambda=0.7（默认）：平衡相关性和多样性

  3. 时间衰减：考虑信息的新鲜度

    • halfLifeDays=30（默认）：30天前的信息权重减半

  4. 实时监听：文件变化时自动更新索引

    • debounceMs 默认 15000ms（15 秒）：避免频繁更新

持久化信息的分类

通过 Pre-compaction Flush 写入的信息通常包括：

1. 用户显式提供的信息

  • 偏好设置（语言、风格、格式）
  • 特定要求（截止日期、质量标准）
  • 身份信息（角色、职务、背景）

2. Agent 推断的重要信息

  • 讨论主题和目标
  • 关键决策和结论
  • 任务进度和状态

3. 系统级别的信息

  • 对话历史摘要
  • 已完成的重要操作
  • 待处理的问题和任务

检索与复用

当新的对话开始时，系统可以通过以下方式复用持久化的信息：

  1. 自动加载：主 session 启动时加载 MEMORY.md
  2. 主动检索：通过 memory_search 搜索相关上下文
  3. 按需读取：通过 memory_get 读取特定信息

这种双层架构确保了：

  • 短期信息：快速访问，灵活更新
  • 长期信息：稳定存储，持续积累
  • 智能检索：语义理解，精准定位

为 Agent 提供了真正可持续的记忆能力。

技术要点详解

本章深入解析上下文压缩与记忆刷新机制的几个核心技术要点，帮助开发者理解实现细节并更好地进行配置。

1. Token 阈值管理

核心参数

参数 说明 默认值
contextWindow 模型的最大上下文窗口 因模型而异
reserveTokens 为提示词和输出预留的空间 16384
reserveTokensFloor reserveTokens 的安全底线 20000（配置示例常用 24000）
softThresholdTokens Pre-compaction Flush 软阈值 4000/6000

阈值计算公式

压缩触发阈值：

contextTokens > contextWindow - reserveTokens

Flush 触发阈值：

contextTokens > contextWindow - reserveTokensFloor - softThresholdTokens

安全底线机制

OpenClaw 强制实施安全底线：

// 如果 reserveTokens < reserveTokensFloor（默认 20000），系统会自动提升
compaction: {
  reserveTokens: 16384,  // 用户设置
  // 系统会自动提升到 >= 20000
}

禁用底线（谨慎使用）：

{
  agents: {
    defaults: {
      compaction: {
        reserveTokensFloor: 0  // 禁用安全底线
      }
    }
  }
}

2. 系统提示词注入

在触发 Pre-compaction Flush 时，系统会向静默轮次注入额外的提示词：

注入时机

正常对话轮次 → 检测到软阈值 → 
发起静默轮次 → 追加 systemPrompt → 
执行 flush → 正常压缩

注入内容

  1. systemPrompt：作为额外的系统提示词追加到 flush 轮次中，提供上下文
  2. prompt：作为用户消息，触发 Agent 行动
  3. NO_REPLY 标记：确保输出不发送给用户

与主对话的关系

静默 flush 轮次在当前 session 上下文中执行，会继承对话历史，但：

  • 追加了专用的 systemPrompt 和 prompt，引导 Agent 聚焦记忆刷新
  • 输出以 NO_REPLY 开头，在交付层被抑制，用户不可见
  • 每压缩周期仅执行一次，避免干扰正常对话

3. 记忆提取算法

Compaction 摘要生成

当触发压缩时，系统会：

  1. 收集待压缩内容：从 firstKeptEntryId 之前的所有消息
  2. 生成摘要：调用模型将历史总结为紧凑形式
  3. 存储摘要：以 compaction entry 形式保存到 JSONL
  4. 更新视图：压缩后的可见内容 = 摘要 + firstKeptEntryId 之后的消息

Memory 文件写入

当执行 Pre-compaction Flush 时：

  1. 分析当前上下文：识别需要持久化的信息
  2. 选择目标文件：memory/YYYY-MM-DD.md
  3. 格式化内容：按约定格式写入
  4. 静默确认：回复 NO_REPLY 结束轮次

4. Context Pruning（会话修剪）

Context Pruning 是与 Compaction 独立运行的另一种优化机制：

功能

修剪旧的 toolResult 消息，释放上下文空间：

修剪模式

模式 说明 示例
cache-ttl 基于 TTL 的修剪触发条件 上次 Anthropic 调用超过 TTL 后触发
软修剪 保留头部 + 尾部，中间插入省略号 保留 maxChars 部分内容
硬清除 替换整个 toolResult 为占位符 [Old tool result content cleared]

特点

  • 不修改磁盘历史：仅在内存层面操作，不修改 *.jsonl 文件
  • 与 Compaction 独立：可单独启用/禁用
  • 可配置策略：根据场景选择合适模式
{
  agents: {
    defaults: {
      contextPruning: {
        mode: "cache-ttl",
        ttl: "5m",
        keepLastAssistants: 3,
        softTrimRatio: 0.3,
        hardClearRatio: 0.5
      }
    }
  }
}

注意：配置键名为 contextPruning（不是 pruning），TTL 使用持续时间字符串格式（如 "5m"），不是 ttlMinutes

5. Session 状态追踪

系统通过 Session Store 追踪压缩和内存刷新的状态：

关键字段

{
  "compactionCount": 5,           // 累计压缩次数
  "memoryFlushAt": 1705238400000, // 最后一次 flush 时间戳
  "memoryFlushCompactionCount": 3 // flush 时的压缩计数
}

状态更新时机

字段 更新时机
compactionCount 每次成功压缩后 +1
memoryFlushAt 每次执行 flush 时
memoryFlushCompactionCount 执行 flush 时的 compactionCount 值

用途

  • 防止同一压缩周期内重复 flush
  • 审计和调试
  • 性能分析和优化

6. 错误处理与边界情况

常见边界情况

  1. Flush 失败

    • 检测到失败后不阻断主流程
    • 记录错误日志供调试

  2. Workspace 只读

    • 自动跳过 flush 操作
    • 不影响正常压缩

  3. 文件写入冲突

    • 使用原子写入操作
    • 避免部分写入

  4. Provider 不可用

    • 向量搜索自动降级
    • 降级到纯文本搜索

通过这些技术要点的深入理解，开发者可以更好地配置和调优 OpenClaw 的上下文压缩与记忆刷新机制。

配置示例

本章提供几个实际的配置示例，帮助开发者快速上手并根据自身需求进行定制。

1. 基础配置

适用于大多数场景的默认配置：

{
  agents: {
    defaults: {
      compaction: {
        // 压缩模式：default | safeguard
        mode: "default",
        
        // reserveTokens 安全底线（默认 20000）
        reserveTokensFloor: 24000,
        
        // 标识符保留策略
        identifierPolicy: "strict",
        
        // 预压缩内存刷新
        memoryFlush: {
          // 是否启用（默认 true）
          enabled: true,
          
          // 软阈值（低于此值时触发 flush）
          softThresholdTokens: 6000,
          
          // 追加的系统提示词
          systemPrompt: "Session nearing compaction. Store durable memories now.",
          
          // 触发 flush 的用户提示词
          prompt: "Write any lasting notes to memory/YYYY-MM-DD.md; reply with NO_REPLY if nothing to store."
        }
      }
    }
  }
}

2. Pi 运行时内部参数

Pi 运行时（Pi coding agent）有自己的 compaction 设置，独立于 OpenClaw 配置：

// Pi 内部 settings（非 openclaw.json 配置）
{
  compaction: {
    // 是否启用压缩
    enabled: true,
    
    // 为提示词和输出预留的 token 数
    reserveTokens: 16384,
    
    // 保留最近消息的 token 数
    keepRecentTokens: 20000
  }
}

关键说明

  • 这些参数是 Pi 运行时内部设置，不是 OpenClaw 的 openclaw.json 配置
  • reserveTokens 默认 16384，但 OpenClaw 会通过 reserveTokensFloor（默认 20000）强制提升
  • keepRecentTokens: 20000 确保压缩后保留足够的最近消息
  • 设置 agents.defaults.compaction.reserveTokensFloor: 0 可禁用 OpenClaw 的安全底线

3. memoryFlush 自定义示例

根据业务需求自定义内存刷新行为：

场景 A：强调任务追踪

{
  memoryFlush: {
    enabled: true,
    softThresholdTokens: 8000,
    systemPrompt: "会话即将压缩。优先保存任务进度和待办事项。",
    prompt: "将当前任务进度、已完成事项和待办列表写入 memory/YYYY-MM-DD.md。格式：\n## 任务进度\n- [任务]: [状态]\n如有重要更新请详细记录，否则回复 NO_REPLY。"
  }
}

场景 B：强调用户偏好

{
  memoryFlush: {
    enabled: true,
    softThresholdTokens: 5000,
    systemPrompt: "Session nearing compaction. Preserve user preferences.",
    prompt: "Extract and save user preferences, explicit requests, and important context to memory/YYYY-MM-DD.md. Focus on: language, style, format requirements. Reply NO_REPLY if nothing important."
  }
}

场景 C：简洁模式

{
  memoryFlush: {
    enabled: true,
    softThresholdTokens: 4000,
    prompt: "Save any important context to memory/YYYY-MM-DD.md. Reply NO_REPLY if nothing to store."
  }
}

注意：OpenClaw 的 memoryFlush 不支持 shell 变量展开，请使用固定的 YYYY-MM-DD 格式，系统会自动解析为当天日期。

4. safeguard 模式

safeguard 模式提供更保守的压缩策略：

{
  agents: {
    defaults: {
      compaction: {
        mode: "safeguard",
        
        // 提高安全底线，留更多空间
        reserveTokensFloor: 32000,
        
        // 降低软阈值，更早触发 flush
        softThresholdTokens: 8000,
        
        memoryFlush: {
          enabled: true,
          softThresholdTokens: 10000
        }
      }
    }
  }
}

safeguard vs default 对比

特性 default safeguard
安全保护 标准 增强（chunked summarization 处理长历史）
保留空间 标准 更大
Flush 触发 标准阈值 更早触发
安全性 标准 增强

5. 高级配置：完全自定义

{
  agents: {
    defaults: {
      compaction: {
        // 压缩模式
        mode: "safeguard",
        
        // 自定义标识符保留策略
        identifierPolicy: "custom",
        identifierInstructions: "保留所有以 [重要] 开头的消息和所有用户提供的配置信息",
        
        // reserveTokens 配置
        reserveTokensFloor: 28000,
        
        // 内存刷新配置
        memoryFlush: {
          enabled: true,
          softThresholdTokens: 7000,
          systemPrompt: "⚠️ 会话即将压缩！请立即保存以下内容：\n1. 用户偏好\n2. 关键决策\n3. 任务状态",
          prompt: "将重要信息写入 memory/YYYY-MM-DD.md，使用以下格式：\n\n## 用户偏好\n- [偏好项]\n\n## 关键决策\n- [决策内容]\n\n## 任务状态\n- [任务]: [进度]\n\n如无需保存请直接回复 NO_REPLY。"
        }
      },
      
      // 会话修剪配置（与压缩独立）
      contextPruning: {
        mode: "cache-ttl",
        ttl: "10m"
      }
    }
  }
}

通过这些配置示例，开发者可以根据具体场景灵活调整 OpenClaw 的上下文压缩与记忆刷新机制，实现最优的性能和用户体验平衡。

总结

核心价值回顾

上下文压缩与记忆刷新机制是 OpenClaw 实现可持续对话的关键技术创新。通过本文的深入解析，我们理解了以下核心要点：

1. 智能压缩，避免中断

  • Overflow Recovery：被动响应溢出错误
  • Threshold Maintenance：主动预防，提前压缩
  • 两种模式相互配合，确保对话持续流畅

2. 主动记忆保护

  • Pre-compaction Flush：在压缩前主动刷新重要信息
  • 软阈值设计：提前触发，给足准备时间
  • NO_REPLY 协议：静默执行，用户无感知

3. 持久化存储

  • 双层 Memory 架构：每日日志 + 长期记忆
  • 向量搜索：语义理解，精准检索
  • 混合搜索：BM25 + 向量，时间衰减

4. 灵活配置

  • 多种模式：default / safeguard
  • 参数可调：阈值、策略、提示词
  • 场景适配：任务追踪、用户偏好、简洁模式

最佳实践建议

  1. 理解业务场景：根据对话长度和复杂度选择合适模式
  2. 合理设置阈值：平衡压缩频率和保留信息量
  3. 精心设计提示词：让 Agent 知道需要保存什么
  4. 监控与调优：关注 compactionCount 和 memoryFlushAt 指标
  5. 测试验证：在生产环境前充分测试各种边界情况
# RAG # 人工智能
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

第2课：LangSmith账号注册｜权限介绍｜计费规则与免费版使用限制详解

avatar AtomGit开源社区
cover

详细讲解一下epoll

avatar AtomGit开源社区

RAG优化系列：基于 TF‑IDF 的相关句子提取——轻量级文本压缩与精炼

本文介绍了一种基于TF-IDF的句子提取方法，用于优化RAG系统中的文本检索。该方法通过计算句子与查询的TF-IDF向量相似度，筛选出最相关的句子，从而减少冗余信息并提高回答准确性。文章详细讲解了TF-IDF原理、代码实现流程（包括句子分割、向量化和相似度计算），并提供了AI评估方法（使用LLM进行相关性打分）。此外，还总结了面试常见问题及解答，如TF-IDF优缺点、top_k选择策略等。该方法轻

avatar AtomGit开源社区