当上下文管理变成“可插拔”OpenClaw Context Engine 的抽象设计与策略生态1. 引言为什么要给上下文管理“松绑”2. 为什么要做这层抽象—— 三个核心动机2.1 动机一告别“核心手术式”修改2.2 动机二让“不同场景”能用“不同策略”2.3 动机三把 OpenClaw 从“工具”变成“平台”3. 这个设计支持哪些策略—— Context Engine 的四种插件模式3.1 生命周期四个核心钩子3.2 两种压缩所有权模式4. 真实案例lossless-claw——“永不丢失上下文”4.1 工作原理4.2 效果对比5. 与 Memory 系统的关系分工而非替代6. 一张图看懂 ContextEngine 的抽象价值7. 结语从“黑盒”到“开放平台”The Begin点点关注收藏不迷路⬇ ⬇ 底部 ⬇ ⬇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 动机二让“不同场景”能用“不同策略”不同的使用场景对上下文管理的要求完全不同场景上下文管理需求日常聊天简单摘要即可成本优先代码开发需要完整保留文件修改历史不能丢失细节长周期项目需要跨会话召回关键决策需要向量检索复杂多步骤任务需要 DAG 结构化压缩保持决策链完整在旧架构中一套方案应对所有场景——要么牺牲细节换空间要么撑爆窗口。ContextEngine 抽象让每个场景都能挂载最合适的策略。2.3 动机三把 OpenClaw 从“工具”变成“平台”这个抽象的最大意义在于生态层面。它让 OpenClaw 从一个固定功能的 Agent 框架变成了一个允许社区贡献上下文管理方案的平台。开发者可以开发自己的上下文引擎插件并发布到 npm在 OpenClaw 中一键安装、切换不用等官方发版就能用上最新的上下文管理算法3. 这个设计支持哪些策略—— Context Engine 的四种插件模式ContextEngine 接口提供了完整的生命周期钩子开发者可以在不同阶段插入自定义逻辑。3.1 生命周期四个核心钩子新消息到达1. Ingest摄取/索引2. Assemble组装上下文3. Compact压缩历史4. After Turn后处理/持久化每个钩子的作用钩子触发时机可以做什么Ingest新消息添加到会话时存储消息到自定义数据源、建立索引Assemble每次模型运行前返回适配 Token 预算的消息列表、注入动态系统提示Compact上下文窗口满或用户运行/compact执行自定义压缩策略DAG 摘要、向量检索等After Turn一次运行完成后持久化状态、触发后台压缩、更新索引额外钩子还支持bootstrap会话初始化、prepareSubagentSpawn子 Agent 生成前准备、onSubagentEnded子 Agent 结束后清理等可选钩子全面覆盖了上下文管理的全生命周期。3.2 两种压缩所有权模式ContextEngine 设计中最精妙的是ownsCompaction标志它定义了两种不同的策略模式模式ownsCompaction行为拥有模式true引擎完全拥有压缩行为。OpenClaw 禁用内置自动压缩引擎的compact()负责/compact、溢出恢复和主动压缩委托模式false引擎的compact()调用delegateCompactionToRuntime()使用 OpenClaw 内置压缩行为关键约束对于一个活动的非拥有引擎compact()不能是空操作——否则会禁用该引擎槽位的正常/compact和溢出恢复压缩路径。4. 真实案例lossless-claw——“永不丢失上下文”社区第一个爆款的 ContextEngine 插件是lossless-claw由 Josh Lehman 开发。它展示了一种颠覆性的上下文管理思路。4.1 工作原理在传统 Agent 系统中一旦对话过长系统通常会直接丢弃旧内容。而 lossless-claw 的做法是持久化到 SQLite 数据库所有原始消息按对话组织完整保存生成摘要并构建 DAG对旧消息块生成摘要将摘要压缩为更高层级节点形成有向无环图每轮组合上下文将“摘要 最近原始消息”组合成模型输入提供回溯工具Agent 可以通过lcm_grep、lcm_describe、lcm_expand搜索和展开历史4.2 效果对比在OOLONG 基准测试中使用同一模型时方案得分lossless-claw74.8Claude Code70.3关键发现上下文越长差距越大。在所有测试的上下文长度下lossless-claw 的得分都高于 Claude Code。安装方式体现“可插拔”理念openclaw pluginsinstallmartian-engineering/lossless-claw// openclaw.json { plugins: { slots: { contextEngine: lossless-claw // 一行配置切换引擎 }, entries: { lossless-claw: { enabled: true } } } }5. 与 Memory 系统的关系分工而非替代ContextEngine 和 Memory 插件是两个独立的 Slot各有分工维度Memory 插件ContextEngine职责提供搜索/检索能力控制模型“看到”什么作用点跨会话的知识召回当前会话的上下文构建典型行为从向量库搜索相关记忆片段组装消息、注入系统提示、执行压缩它们可以协同工作ContextEngine 在assemble()阶段可以通过buildMemorySystemPromptAddition()将 Memory 插件的检索结果注入到系统提示中。6. 一张图看懂 ContextEngine 的抽象价值渲染错误:Mermaid 渲染失败: Lexical error on line 2. Unrecognized text. ...art TD subgraph “OpenClaw 核心” ----------------------^核心洞察OpenClaw 核心只定义“接口契约”具体策略由插件实现。用户通过plugins.slots.contextEngine一行配置即可切换整个上下文管理策略。7. 结语从“黑盒”到“开放平台”ContextEngine 抽象的设计价值可以从三个层面理解工程层面避免了“改核心代码才能换策略”的高风险操作让上下文管理变得可配置、可插拔策略层面支持从“简单摘要”到“DAG 无损压缩”再到“向量检索”的无限策略组合让不同场景选择最优方案生态层面把 OpenClaw 从一个固定功能的工具变成了一个允许社区贡献上下文管理方案的开放平台一句话总结ContextEngine 抽象把“上下文管理”从 OpenClaw 核心的一个黑盒变成了一扇可以自由插拔各种策略的开放接口。它回答了 Agent 系统中最根本的问题之一——当上下文窗口成为硬约束时谁来决定“哪些信息该留下、哪些该归档、如何归档”答案是你说了算通过插件。The End点点关注收藏不迷路⬆ ⬆ 顶部 ⬆ ⬆
当上下文管理变成“可插拔”：OpenClaw Context Engine 的抽象设计与策略生态
当上下文管理变成“可插拔”OpenClaw Context Engine 的抽象设计与策略生态1. 引言为什么要给上下文管理“松绑”2. 为什么要做这层抽象—— 三个核心动机2.1 动机一告别“核心手术式”修改2.2 动机二让“不同场景”能用“不同策略”2.3 动机三把 OpenClaw 从“工具”变成“平台”3. 这个设计支持哪些策略—— Context Engine 的四种插件模式3.1 生命周期四个核心钩子3.2 两种压缩所有权模式4. 真实案例lossless-claw——“永不丢失上下文”4.1 工作原理4.2 效果对比5. 与 Memory 系统的关系分工而非替代6. 一张图看懂 ContextEngine 的抽象价值7. 结语从“黑盒”到“开放平台”The Begin点点关注收藏不迷路⬇ ⬇ 底部 ⬇ ⬇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 动机二让“不同场景”能用“不同策略”不同的使用场景对上下文管理的要求完全不同场景上下文管理需求日常聊天简单摘要即可成本优先代码开发需要完整保留文件修改历史不能丢失细节长周期项目需要跨会话召回关键决策需要向量检索复杂多步骤任务需要 DAG 结构化压缩保持决策链完整在旧架构中一套方案应对所有场景——要么牺牲细节换空间要么撑爆窗口。ContextEngine 抽象让每个场景都能挂载最合适的策略。2.3 动机三把 OpenClaw 从“工具”变成“平台”这个抽象的最大意义在于生态层面。它让 OpenClaw 从一个固定功能的 Agent 框架变成了一个允许社区贡献上下文管理方案的平台。开发者可以开发自己的上下文引擎插件并发布到 npm在 OpenClaw 中一键安装、切换不用等官方发版就能用上最新的上下文管理算法3. 这个设计支持哪些策略—— Context Engine 的四种插件模式ContextEngine 接口提供了完整的生命周期钩子开发者可以在不同阶段插入自定义逻辑。3.1 生命周期四个核心钩子新消息到达1. Ingest摄取/索引2. Assemble组装上下文3. Compact压缩历史4. After Turn后处理/持久化每个钩子的作用钩子触发时机可以做什么Ingest新消息添加到会话时存储消息到自定义数据源、建立索引Assemble每次模型运行前返回适配 Token 预算的消息列表、注入动态系统提示Compact上下文窗口满或用户运行/compact执行自定义压缩策略DAG 摘要、向量检索等After Turn一次运行完成后持久化状态、触发后台压缩、更新索引额外钩子还支持bootstrap会话初始化、prepareSubagentSpawn子 Agent 生成前准备、onSubagentEnded子 Agent 结束后清理等可选钩子全面覆盖了上下文管理的全生命周期。3.2 两种压缩所有权模式ContextEngine 设计中最精妙的是ownsCompaction标志它定义了两种不同的策略模式模式ownsCompaction行为拥有模式true引擎完全拥有压缩行为。OpenClaw 禁用内置自动压缩引擎的compact()负责/compact、溢出恢复和主动压缩委托模式false引擎的compact()调用delegateCompactionToRuntime()使用 OpenClaw 内置压缩行为关键约束对于一个活动的非拥有引擎compact()不能是空操作——否则会禁用该引擎槽位的正常/compact和溢出恢复压缩路径。4. 真实案例lossless-claw——“永不丢失上下文”社区第一个爆款的 ContextEngine 插件是lossless-claw由 Josh Lehman 开发。它展示了一种颠覆性的上下文管理思路。4.1 工作原理在传统 Agent 系统中一旦对话过长系统通常会直接丢弃旧内容。而 lossless-claw 的做法是持久化到 SQLite 数据库所有原始消息按对话组织完整保存生成摘要并构建 DAG对旧消息块生成摘要将摘要压缩为更高层级节点形成有向无环图每轮组合上下文将“摘要 最近原始消息”组合成模型输入提供回溯工具Agent 可以通过lcm_grep、lcm_describe、lcm_expand搜索和展开历史4.2 效果对比在OOLONG 基准测试中使用同一模型时方案得分lossless-claw74.8Claude Code70.3关键发现上下文越长差距越大。在所有测试的上下文长度下lossless-claw 的得分都高于 Claude Code。安装方式体现“可插拔”理念openclaw pluginsinstallmartian-engineering/lossless-claw// openclaw.json { plugins: { slots: { contextEngine: lossless-claw // 一行配置切换引擎 }, entries: { lossless-claw: { enabled: true } } } }5. 与 Memory 系统的关系分工而非替代ContextEngine 和 Memory 插件是两个独立的 Slot各有分工维度Memory 插件ContextEngine职责提供搜索/检索能力控制模型“看到”什么作用点跨会话的知识召回当前会话的上下文构建典型行为从向量库搜索相关记忆片段组装消息、注入系统提示、执行压缩它们可以协同工作ContextEngine 在assemble()阶段可以通过buildMemorySystemPromptAddition()将 Memory 插件的检索结果注入到系统提示中。6. 一张图看懂 ContextEngine 的抽象价值渲染错误:Mermaid 渲染失败: Lexical error on line 2. Unrecognized text. ...art TD subgraph “OpenClaw 核心” ----------------------^核心洞察OpenClaw 核心只定义“接口契约”具体策略由插件实现。用户通过plugins.slots.contextEngine一行配置即可切换整个上下文管理策略。7. 结语从“黑盒”到“开放平台”ContextEngine 抽象的设计价值可以从三个层面理解工程层面避免了“改核心代码才能换策略”的高风险操作让上下文管理变得可配置、可插拔策略层面支持从“简单摘要”到“DAG 无损压缩”再到“向量检索”的无限策略组合让不同场景选择最优方案生态层面把 OpenClaw 从一个固定功能的工具变成了一个允许社区贡献上下文管理方案的开放平台一句话总结ContextEngine 抽象把“上下文管理”从 OpenClaw 核心的一个黑盒变成了一扇可以自由插拔各种策略的开放接口。它回答了 Agent 系统中最根本的问题之一——当上下文窗口成为硬约束时谁来决定“哪些信息该留下、哪些该归档、如何归档”答案是你说了算通过插件。The End点点关注收藏不迷路⬆ ⬆ 顶部 ⬆ ⬆
