1. 引言：为什么要给上下文管理“松绑”？

在 AI Agent 工程中，上下文管理一直是最棘手的问题之一。当对话轮次一多，Token 就爆炸；信息一压缩，关键细节就丢——这是几乎所有 Agent 开发者都经历过的痛苦。

在 OpenClaw 的早期版本中，上下文管理逻辑是写死在核心代码里的。对话过长时如何压缩历史、如何拼接上下文、何时丢弃旧信息，全部由系统内部固定实现，插件几乎无法介入。这意味着每次你想优化上下文策略，都得修改核心源码——风险极高，维护成本巨大。

2026 年 3 月 7 日，OpenClaw 发布了 v2026.3.7-beta.1，这是其发展史上的一次分水岭式更新。核心亮点是推出了 ContextEngine 插件接口——把上下文管理从“写死在核心”变成了“可自由插拔”。

这层抽象的意义，用 PR 作者 Josh Lehman 的一句话可以概括：

“你其实不需要一个 Agent 记忆系统，你需要的是不会被重置的上下文。”

2. 为什么要做这层抽象？—— 三个核心动机

2.1 动机一：告别“核心手术式”修改

在旧架构中，上下文压缩、组装、修剪的逻辑全部内嵌在 Agent Runner 中。如果你想换一种压缩策略——比如从“简单摘要”换成“DAG 结构化压缩”——你只能去改 OpenClaw 的核心代码。

风险：改一处崩全程。每次升级 OpenClaw 版本，你还得重新合并你的定制代码。

解决：ContextEngine 接口把所有上下文相关的行为抽象为生命周期钩子。开发者只需实现这些钩子，就能完全自定义上下文处理逻辑，无需触碰核心代码。

开发者社区的反馈：项目 Issues 下面，有人评论说等这个接口等了快半年，点赞数秒过百。

2.2 动机二：让“不同场景”能用“不同策略”

不同的使用场景对上下文管理的要求完全不同：

在旧架构中，一套方案应对所有场景——要么牺牲细节换空间，要么撑爆窗口。ContextEngine 抽象让每个场景都能挂载最合适的策略。

2.3 动机三：把 OpenClaw 从“工具”变成“平台”

这个抽象的最大意义在于生态层面。它让 OpenClaw 从一个固定功能的 Agent 框架，变成了一个允许社区贡献上下文管理方案的平台。开发者可以：

• 开发自己的上下文引擎插件并发布到 npm
• 在 OpenClaw 中一键安装、切换
• 不用等官方发版，就能用上最新的上下文管理算法

3. 这个设计支持哪些策略？—— Context Engine 的四种插件模式

ContextEngine 接口提供了完整的生命周期钩子，开发者可以在不同阶段插入自定义逻辑。

3.1 生命周期四个核心钩子

每个钩子的作用：

额外钩子：还支持 bootstrap（会话初始化）、prepareSubagentSpawn（子 Agent 生成前准备）、onSubagentEnded（子 Agent 结束后清理）等可选钩子，全面覆盖了上下文管理的全生命周期。

3.2 两种压缩所有权模式

ContextEngine 设计中最精妙的是 ownsCompaction 标志，它定义了两种不同的策略模式：

关键约束：对于一个活动的非拥有引擎，compact() 不能是空操作——否则会禁用该引擎槽位的正常 /compact 和溢出恢复压缩路径。

4. 真实案例：lossless-claw——“永不丢失上下文”

社区第一个爆款的 ContextEngine 插件是 lossless-claw，由 Josh Lehman 开发。它展示了一种颠覆性的上下文管理思路。

4.1 工作原理

在传统 Agent 系统中，一旦对话过长，系统通常会直接丢弃旧内容。而 lossless-claw 的做法是：

1. 持久化到 SQLite 数据库：所有原始消息按对话组织，完整保存
2. 生成摘要并构建 DAG：对旧消息块生成摘要，将摘要压缩为更高层级节点，形成有向无环图
3. 每轮组合上下文：将“摘要 + 最近原始消息”组合成模型输入
4. 提供回溯工具：Agent 可以通过 lcm_grep、lcm_describe、lcm_expand 搜索和展开历史

4.2 效果对比

在 OOLONG 基准测试中，使用同一模型时：

关键发现：上下文越长，差距越大。在所有测试的上下文长度下，lossless-claw 的得分都高于 Claude Code。

安装方式（体现“可插拔”理念）：

openclaw plugins install @martian-engineering/lossless-claw

// openclaw.json
{
  plugins: {
    slots: {
      contextEngine: "lossless-claw"  // 一行配置，切换引擎
    },
    entries: {
      "lossless-claw": { enabled: true }
    }
  }
}

5. 与 Memory 系统的关系：分工而非替代

ContextEngine 和 Memory 插件是两个独立的 Slot，各有分工：

它们可以协同工作：ContextEngine 在 assemble() 阶段可以通过 buildMemorySystemPromptAddition() 将 Memory 插件的检索结果注入到系统提示中。

6. 一张图看懂 ContextEngine 的抽象价值

核心洞察：OpenClaw 核心只定义“接口契约”，具体策略由插件实现。用户通过 plugins.slots.contextEngine 一行配置即可切换整个上下文管理策略。

7. 结语：从“黑盒”到“开放平台”

ContextEngine 抽象的设计价值可以从三个层面理解：

• 工程层面：避免了“改核心代码才能换策略”的高风险操作，让上下文管理变得可配置、可插拔
• 策略层面：支持从“简单摘要”到“DAG 无损压缩”再到“向量检索”的无限策略组合，让不同场景选择最优方案
• 生态层面：把 OpenClaw 从一个固定功能的工具变成了一个允许社区贡献上下文管理方案的开放平台

一句话总结：ContextEngine 抽象把“上下文管理”从 OpenClaw 核心的一个黑盒，变成了一扇可以自由插拔各种策略的开放接口。它回答了 Agent 系统中最根本的问题之一——当上下文窗口成为硬约束时，谁来决定“哪些信息该留下、哪些该归档、如何归档”？

答案是：你说了算，通过插件。