OpenClaw 篇七：lossless-claw 永不丢失的上下文和记忆

共计 6372 个字符，预计需要花费 16 分钟才能阅读完成。

在使用 OpenClaw 时，我们常面临的主要痛点是模型的上下文窗口。OpenClaw 默认的处理方式是直接压缩和截断，一旦信息没有被总结，就永久性丢失了。你和 Agent 聊了两三个小时，它对项目架构、之前讨论过的设计决策、踩过的坑都了如指掌。然后上下文窗口满了，旧消息被默默丢弃，Agent 突然像失忆了一样——刚才说过的关键决策、之前调试的错误原因，全都不记得了。这就是传统滑动窗口（sliding window）机制的根本缺陷：为了控制 token 用量，直接把历史对话截断丢弃。

lossless-claw 就是为了解决这个问题而生的。它是 [[Martian Engineering]] 开发的一个 OpenClaw 插件，实现了 Lossless Context Management（LCM，无损上下文管理）。核心理念很简单但很有力：永远不丢弃任何一条消息，而是把所有对话完整存入本地 [[SQLite]] 数据库，同时通过层级化的摘要压缩来控制实际进入模型上下文的 token 量。效果就像是和一个永不遗忘的 Agent 对话。

利用一套 DAG 有像无环图分层摘要系统，替换掉了原来的滑动窗口截断机制，将每一条消息都持久化存储。通过摘要再摘要的递归浓缩，让 Agent 保持 Token 预算的同时，理论上可以记住无限长的历史。

为什么需要无损上下文管理

传统的上下文管理方式有两种，都有明显缺陷。一种是滑动窗口截断——上下文满了就把最早的消息直接删掉，简单粗暴但会丢失重要的历史决策和调试记录。另一种是有损摘要——把旧消息总结成一段简短的摘要，然后删除原文。这种方式看起来好一些，但问题在于摘要过程中不可避免地会丢失细节，而那些被丢弃的细节往往在后续对话中变得至关重要。

LCM 走了第三条路：无损压缩。所有原始消息完整保留在数据库中，永远可以追溯；同时通过层级化的摘要来构建一个高效的上下文表示，让模型在每一轮对话中都能看到历史的全貌（以摘要形式）加上最近的完整对话。如果需要某段历史的细节，Agent 可以随时通过工具"展开"摘要，回到原始消息。

这就像是把一本书压缩成目录和摘要供快速浏览，但原书始终放在书架上，随时可以翻阅任何一页。

工作原理：DAG 摘要树

lossless-claw 的架构围绕五个核心步骤运转。

• 第一步是持久化存储（Persistence）。所有进入对话的消息都会被写入本地 SQLite 数据库，按会话组织。这一步是无条件执行的——无论消息多长、多短，都完整保存，不做任何裁剪。
• 第二步是摘要生成（Summarization）。当上下文使用量达到设定阈值（默认是上下文窗口的 75%）时，系统会把较早的消息分块，调用 LLM 对每个块生成叶子摘要（leaf summary）。这里有一个关键的设计选择：摘要目标大小（默认 1200 token）远小于源文本大小（默认 20000 token），实现了约十六倍的压缩比，同时保留了核心语义。
• 第三步是层级压缩（Condensation）。随着摘要不断累积，多个叶子摘要会被进一步压缩成更高层级的摘要节点，形成一个有向无环图（DAG）。这个 DAG 结构是 LCM 最精妙的设计——它让系统可以在不同粒度层级上表示历史，从高层概览到底层细节都有对应的节点。每个摘要节点都记录了它是由哪些源消息或下层摘要生成的，形成完整的溯源链。
• 第四步是上下文组装（Assembly）。每一轮对话前，系统把 DAG 顶层的摘要（代表全部历史的高度压缩版本）与最近的原始消息拼接在一起，构成输入给模型的上下文。这样模型既能看到最近对话的完整细节，又能通过摘要了解更早之前发生了什么。
• 第五步是按需检索（Tools）。Agent 可以使用三个专用工具来主动查询历史：lcm_grep 用于在历史消息中搜索关键词，lcm_describe 用于查看某段历史的概要描述，lcm_expand 用于将某个摘要展开回其源消息获取完整细节。

ContextEngine 集成

lossless-claw 的运行依赖 OpenClaw v2026.3.7 引入的 ContextEngine （上下文管理引擎）架构。ContextEngine 是一套插槽式（slot-based）的上下文管理框架，定义了七个生命周期钩子：

• bootstrap：插件初始化，加载持久化状态和数据库连接
• ingest：新消息到达时的预处理和重要性分类
• assemble：构建 prompt 前，决定哪些内容进入最终的上下文
• compact：接近 token 上限时，触发压缩或摘要
• afterTurn：每轮对话后的统计更新和清理
• prepareSubagentSpawn：子 Agent 启动前的上下文隔离
• onSubagentEnded：子 Agent 完成后的输出合并

lossless-claw 主要实现了前四个核心钩子。如果不安装任何 ContextEngine 插件，系统会回退到 LegacyContextEngine，保持与旧版本完全一致的行为，所以升级是无风险的。

Context Engine 主要负责会话上下文的管理，包括当前聊天中已有的历史内容的保存、压缩、检索和展开。 如果连续和 OpenClaw 对话上百回，大模型上下文不可能将所有的会话内容全量塞进去，这就需要 ContextEngine 来做决策，旧消息应该如何存储？历史记录如何生成摘要？以及如何找回这些信息？

关键配置与调优

lossless-claw 的默认配置可以直接使用，但要发挥最佳效果，有几个参数需要重点关注。

压缩深度

incrementalMaxDepth 这个参数至关重要。默认值是 0，意味着系统不会对已有的摘要进行二次压缩。在短会话中这没问题，但一旦进入长时间的工作会话，叶子摘要会不断累积，最终还是会撑满上下文。把这个值设为 -1 可以启用无限深度的自动压缩——当叶子摘要积累到一定量时，它们会被进一步压缩成更高层级的摘要，DAG 会按需生长到任意深度。这是使用 lossless-claw 后第一个应该修改的配置。

尾部保护

freshTailCount 默认值为 32，表示最近的 32 条消息不会被压缩。这个设计很有道理——模型需要足够的最近上下文来保持对话的连贯性。如果你的工作模式是频繁的短交互（一问一答式），32 条已经够用；如果你的对话轮次比较长（比如每次 Agent 会产生大量中间输出），可以适当调高这个值。

压缩阈值

contextThreshold 默认为 0.75，即上下文使用达到窗口的 75% 时触发压缩。留出 25% 的空间是为了给模型的响应预留 token。这个默认值通常不需要调整。

模型配置

这是 lossless-claw 一个非常实用的设计：你可以为摘要生成和历史展开分别指定不同的模型，不必使用主会话的昂贵模型。

summaryModel 负责把消息压缩成摘要。摘要质量直接影响未来的检索效果，所以最好使用一个智能程度不错的中端模型。本地可以用 Qwen3-8B 或 Llama 3.3-8B（需要 16GB 以上显存），通过 API 可以用中档价位的模型。

expansionModel 负责在 Agent 使用 lcm_expand 工具时从压缩历史中检索细节。这个任务对推理能力要求不高，但对速度很敏感——如果模型太慢会导致检索超时而静默失败。推荐使用轻量级的快速模型，本地可以用 Llama 3.2-3B 或 Phi-4-mini，API 层面使用 Haiku 级别或 GPT-4.1-mini 级别的模型就足够了。切记不要用大型推理模型做展开——速度会慢五到十倍，但质量没有任何提升。

展开 token 预算

maxExpandTokens 的默认值是 4000，但实际使用中发现这往往不够。真实的源内容可能有一万五到两万 token，过小的预算会导致截断或检索失败。建议至少设为 12000。

安装与部署

安装过程非常简单。首先确保你的 OpenClaw 版本支持 ContextEngine 插件（v2026.3.7 及以上），以及 Node.js 22+ 环境。

openclaw plugins install @martian-engineering/lossless-claw

然后在 OpenClaw 的配置中将 contextEngine 插槽指向 lossless-claw 即可。数据库文件默认存储在 ~/.openclaw/lcm.db。

{
  "plugins": {
    "slots": {
      "contextEngine": "lossless-claw"
    }
  }
}

插件的配置

{
  "plugins": {
    "entries": {
      "lossless-claw": {
        "enabled": true,
        "config": {
          "freshTailCount": 32,
          "contextThreshold": 0.75,
          "incrementalMaxDepth": -1,
          "ignoreSessionPatterns": [
            "agent:*:cron:**"
          ],
          "summaryModel": "anthropic/claude-haiku-4-5",
          "expansionModel": "anthropic/claude-haiku-4-5"
        }
      }
    }
  }
}

会话管理

lossless-claw 支持灵活的会话排除策略。通过 ignoreSessionPatterns 可以设置完全忽略的会话模式——这些会话的消息既不存储也不压缩，适合临时性的调试会话。通过 statelessSessionPatterns 可以设置「只读」模式的会话——它们可以读取 LCM 中的历史记忆，但不会向其中写入任何内容，适合定时任务类的 Agent 会话。

session.reset.idleMinutes 控制会话的持久化时长。设为 1440 表示一天，10080 表示一周，43200 表示一个月。对于长期项目，设为一周或一个月可以让 Agent 在跨天工作时仍然记得之前的上下文。

实际使用中的一个关键教训

有一篇关于 LCM 实战部署的文章揭示了一个非常重要的发现：数据库里完美地保存了所有消息，但检索路径上存在三层格式化函数，会逐步剥离内容——第一层把消息截断为 200 字符的片段，第二层把正文替换为元数据占位符（类似「msg#28764, assistant, 362 tokens」），第三层直接从子 Agent 的 prompt 中丢弃了内容字段。

结果就是：存储完美，但检索为零。数据全在，就是拿不出来。

这个教训非常深刻——在配置 LCM 之后，一定要测试完整的检索路径，而不只是验证数据库里有没有数据。修复方法是补丁三个格式化文件并提高 token 预算，之后检索功能才真正跑通。

在整体记忆架构中的位置

lossless-claw 解决的是 AI Agent 记忆系统中的一个特定层面——会话级的上下文持续性。在更完整的记忆架构中，它通常作为第一层（工作记忆）存在，与其他层面配合使用：

• 第二层是 RAG（语义文件搜索），让 Agent 能够检索项目中的代码和文档
• 第三层是项目感知（R-Awareness），向 Agent 注入项目级别的上下文信息
• 第四层是长期记忆日志，用于故障分析和模式学习

lossless-claw、[[mem9]] 和 [[Mem0]] 这三个工具经常被放在一起讨论，但它们解决的其实是记忆系统中不同层面的问题。理解它们的差异，有助于根据自己的需求选择合适的方案，甚至将它们组合使用。

lossless-claw 解决的是单次长会话中的上下文管理问题，可以理解为「工作记忆的扩展」。它的核心价值在于：当你和 Agent 连续对话几个小时甚至跑 overnight 的自动化任务时，历史消息不会因为上下文窗口满了而被丢弃。所有消息完整保留在本地 SQLite 中，通过 DAG 摘要树实现层级压缩，Agent 随时可以通过 lcm_grep 和 lcm_expand 工具回溯任意历史细节。但一旦你关闭了 Agent、换了一台电脑，这些记忆就无法跟随你——它是会话级别的，不是跨会话的。

[[mem9]] 解决的是跨会话、跨设备的持久化记忆问题，可以理解为「长期记忆」。它由 [[PingCAP]] 团队开发，后端使用 [[TiDB]] 云数据库，通过混合搜索（向量 + 关键词）来检索历史知识。Agent 在 A 会话中学到的项目偏好和编码规范，可以在 B 会话中被自动调用，即使换了电脑也不受影响。mem9 的插件是无状态的，所有记忆都存储在服务端。但 mem9 不处理单次会话内部的上下文管理——它不关心你当前对话的第 50 轮和第 3 轮之间的连贯性问题。

[[Mem0]] 则是这个领域目前最成熟的通用方案。它获得了 Y Combinator 支持，融资 2400 万美元，拥有超过五万名开发者用户。Mem0 的定位比 mem9 更宽——它不只面向 AI Coding Agent，而是为所有 AI 应用提供记忆层，支持知识图谱构建、prompt 压缩（最高可减少 80% 的 token）、多种 LLM 框架集成。Mem0 提供 SaaS 服务（从免费到每月 249 美元不等），也支持自托管。它的优势在于生态更完善、功能更全面，但也意味着更高的复杂度和抽象层级。对于只需要解决 AI Coding Agent 记忆问题的开发者来说，Mem0 可能有些「大材小用」。

三方对比

维度	lossless-claw	[[mem9]]	[[Mem0]]
定位	会话内上下文管理（工作记忆）	跨会话持久化记忆（长期记忆）	通用 AI 应用记忆层（全场景）
核心问题	长会话上下文溢出丢失	Agent 跨会话失忆	AI 应用缺乏持久化记忆
存储后端	本地 SQLite	云端 TiDB/MySQL	云端托管或自托管
压缩方式	DAG 层级摘要（LLM 驱动）	混合搜索检索	知识图谱 + prompt 压缩
检索机制	lcm_grep / lcm_expand 工具	memory_search API	Memory API + 知识图谱查询
模型依赖	需要 LLM 做摘要和展开	需要嵌入模型做向量化	需要嵌入模型 + 可选 LLM
数据位置	完全本地	云端或自托管	SaaS 或自托管
目标用户	AI Coding Agent 重度用户	AI Coding Agent 团队	所有 AI 应用开发者
适用框架	OpenClaw ContextEngine 插件	Claude Code / OpenCode 等	LangChain / LlamaIndex / 多框架
价格	免费（本地运行 + LLM 调用费）	免费开源（TiDB 免费额度 25GiB）	免费 ~ $249/月
开源协议	MIT	Apache 2.0	Apache 2.0

三者的关系不是互斥而是互补的。一个理想的 AI Agent 记忆架构可以同时使用 lossless-claw 处理会话内的上下文连贯性，用 mem9 或 Mem0 处理跨会话的知识积累。lossless-claw 确保你当前的长对话不丢失任何细节，mem9/Mem0 确保会话结束后有价值的知识仍然可以被未来的会话调用。前者是「不忘记刚才说了什么」，后者是「记住上周学到了什么」。

最后

lossless-claw 代表了 AI Agent 上下文管理从「丢弃式」向「压缩式」的一个重要转变。它的 DAG 摘要树架构在理论上很优雅——通过层级化的无损压缩，在 token 效率和信息完整性之间找到了一个精妙的平衡点。在启用 LCM 后，上下文使用量通常稳定在三万到十万 token 的范围内，无论会话持续多久都不会再出现记忆断崖式丢失的情况。

对于那些经常需要进行长时间编程会话的开发者来说，lossless-claw 可能是目前最值得尝试的上下文管理方案。它不需要云服务、不需要复杂的基础设施，一个 SQLite 文件加上一个配置好的摘要模型，就能让你的 Agent 拥有「永不遗忘」的能力。配合 [[mem9]] 这样的跨会话记忆层，AI Coding Agent 的记忆系统正在从「金鱼记忆」进化为真正的「数字大脑」。

related

• [[mem9]]
• [[Claude Code]]
• [[SQLite]]
• [[Harness Engineering]]
• [[Context Engineering]]