大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



本文出自 AI Agent 记忆系统逆向工程 项目 —— 我们逆向拆解了 OpenClaw、nanobot、NullClaw、OpenFang 4 个开源 AI Agent 框架的记忆系统，源码级记录每一个设计细节。30+ 篇文档、全架构图，全部开源。如果觉得有价值，欢迎 ⭐ Star 支持。

导读： OpenClaw 3.7 beta 更新了 89 项代码提交，其中最重磅的一条是 ContextEngine 插件接口上线。社区有人评论“等这个接口等了快半年”，点赞数秒过百。这篇文章不讲概念，直接拆源码，带你看清楚这个接口到底解决了什么问题、怎么解决的、以及你能从中学到什么。

---

你跟 AI 对话，每一轮历史消息都作为“上下文”送给模型。模型需要看到之前聊了什么，才知道你现在在问什么。

问题出在这里：模型的上下文窗口有大小限制。

128K token 的窗口，你聊了 200 轮，加上工具调用的返回值，token 早就爆了。这时候系统得做决策——

• 哪些消息留下？最近的肯定要，但“最近”的边界在哪？
• 旧消息怎么处理？直接砍掉，还是压缩成摘要？
• 送给模型时怎么排列？系统提示 + 历史 + 工具 schema，顺序和内容怎么组装？

这就是上下文管理（Context Management）。每个实用的 AI Agent 框架都绕不开。

关键在于：这些处理逻辑一旦写死在核心代码里，日后每次调整都是高风险手术。

---

我们逆向了 OpenClaw v2026.3.7 之前的源码，旧的上下文管理是一条完全硬编码的流水线，散布在 5+ 个文件里，没有任何抽象层：

GPT plus 代充 只需 145

2.1 sanitize 有多复杂？

这个函数叫 ，名字平平无奇，里面塞了大约 10 个处理步骤：

1. 标注跨会话用户消息
2. 清理/缩放图片（不同模型有不同图片限制）
3. 删除 块
4. 规范化工具调用的名称和 ID
5. 修复孤立的 tool_use → tool_result 配对
6. 删除工具返回值中的冗余字段
7. 清理过期的 assistant usage 快照
8. 记录模型快照元数据
9. 降级 OpenAI 推理格式（仅 OpenAI Responses API）
10. 修复 Google/vLLM 的轮次顺序约束（仅 Google provider）

2.2 压缩逻辑是最大的坑

当 token 快要超限时，系统有个“压缩”机制——把旧对话总结成摘要，删掉原始消息。

这个逻辑在 （约 763 行），是最大的痛点。为什么？因为压缩需要调模型来生成摘要，而调模型需要完整的上下文环境，于是 把 里大量环境构建代码复制了一遍：

改一处忘了改另一处？上线即 bug。

2.3 三种压缩触发方式，全是硬编码

旧架构有三种压缩触发方式：

• SDK 自动检测：Agent 运行期间检测到即将超限，主动触发
• 用户手动 ：用户在对话中输入命令
• Overflow 重试：模型返回 token 超限错误，自动重试（最多 3 次）

问题不在于触发方式不够多，而在于——你无法通过插件替换这些策略。想自定义“什么时候该压缩”的判断逻辑？只能改核心代码。

2.4 痛点总结

微信文章里说的“改一处崩全程”，指的就是这些。

---

OpenClaw 3.7 的 ContextEngine 接口（PR #22201，44 个文件改动），解决方案其实很经典——定义一组接口，让核心运行时只关心“要做什么”，具体“怎么做”交给可替换的引擎。

用官方的话说，这叫零阻碍接入。

翻译成人话：以后换个上下文处理算法，像换插件一样简单。

3.1 七个生命周期钩子

ContextEngine 定义了 7 个钩子，覆盖了上下文的完整生命周期：

GPT plus 代充 只需 145

用人话对照一下变化：

3.2 接口定义（精简版）

3 个必选方法覆盖了上下文管理最本质的三件事：消息怎么存、上下文怎么组、太多了怎么压。4 个可选方法提供增强能力，不实现也不影响基本运转。

这个设计非常克制——不多不少，刚好够用。

---

引入新接口最怕什么？Breaking change。

OpenClaw 用了一个经典的架构模式——Strangler Fig（绞杀者模式）：在旧系统外面包一层新接口，旧逻辑原封不动跑在新接口里。

就是这个包装器：

结果：不配置任何 context engine 插件时，系统行为和升级前 100% 一致。零风险升级。

这就是为什么 89 项代码提交能顺利上线的原因——不是蛮力堆功能，是架构上保证了不破坏已有行为。

---

5.1 进程全局注册表

GPT plus 代充 只需 145

5.2 Slot 机制

一个坑位只能站一个人。两个插件都声明 ，只有被配置选中的那个加载。

5.3 一行配置搞定切换

GPT plus 代充 只需 145

不配这一行 → 默认 → 行为不变。

这就是“像换插件一样简单”的实现原理。

---

这不是空谈，看代码：

三个核心方法，加起来不到 20 行。但效果是什么？你把上下文管理从“暴力截断”变成了“语义检索”，而且没有改动 OpenClaw 的任何核心代码。

---

很多人会混淆这两个概念。简单区分：

它们之间的桥梁是 Memory Flush——在 ContextEngine 执行压缩之前，先触发一个静默 Agent 回合，提醒 Agent 把值得保留的对话内容写入记忆文件。

上下文管理决定“模型这次能看到什么”，记忆系统决定“Agent 下周还记得什么”。两者协同但独立。

---

不管你用不用 OpenClaw，这次的 ContextEngine 设计有几个通用的工程模式值得带走：

8.1 绞杀者模式（Strangler Fig）

新接口包装旧逻辑，渐进式替换。不一口气重写，而是让新旧共存，逐步迁移。这在任何大型系统的重构中都适用。

8.2 接口 + 注册表 + 配置驱动

定义接口 → 工厂函数注册到全局注册表 → 配置文件选择用哪个引擎 → 运行时动态解析。这套模式在Java 的 SPI、Python 的 entry_points、Rust 的 trait 中都有对应。

8.3 Best-effort 回调

子 Agent 生命周期回调失败只记日志不阻断主流程。在分布式系统中，“让非关键路径的失败不影响主路径”是基本原则。

8.4 必选 + 可选方法分离

3 个必选方法保证核心能力，4 个可选方法扩展增强能力。实现者可以从最简开始，逐步增加功能。

---

我们的项目（AI Agent 记忆系统逆向工程）做的事就是这个——逆向拆解 4 个火爆的开源 AI Agent 框架的记忆系统，源码级记录每一个设计细节。

ContextEngine 只是 OpenClaw 分析的一部分。完整的文档覆盖了：

从 2 个 Markdown 文件到 10 种存储后端、从暴力截断到 9 阶段检索管线——4 种完全不同的设计哲学，让你一次看透 AI Agent 记忆系统的全貌。

适合谁？

• 正在构建 AI Agent 的工程师：直接参考已经验证过的架构
• 想理解“记忆”到底怎么实现的研究者：源码级拆解，不是概念堆砌
• 想在 LangGraph / LangChain / 自研框架中做上下文管理的开发者：每个框架都有复刻指南

完整文档 + 架构图 + 代码分析，全部开源：

👉 GitHub 仓库： https://github.com/breath57/how-ai-agents-remember

如果觉得对你有帮助，给个 ⭐ 吧。我们还在持续更新。

---

OpenClaw 3.7 的 ContextEngine 接口，核心价值用一句话概括：

以后换个上下文处理算法，像换插件一样简单，不用再担心改一处崩全程。

它不是一个“多了个功能”的小更新，而是一次架构层面的升级——把 AI Agent 中最头疼的上下文管理问题，从“硬编码在核心代码里”变成了“可插拔的标准接口”。

7 个生命周期钩子、绞杀者模式的向后兼容、全局注册表 + Slot 机制的引擎管理——这些设计模式不仅适用于 OpenClaw，同样适用于你正在做的任何 AI Agent 系统。

不论你用什么技术栈，上下文管理的核心问题是一样的。理解它、借鉴它、在你的项目中用好它。

---

本文基于 AI Agent 记忆系统逆向工程项目 中对 OpenClaw 的源码分析撰写。项目持续更新中，欢迎 Star 和 PR。