OpenClaw 把 Context 管理抽象成了可插拔的 Context Engine，为什么要做这层抽象？这个设计能支持哪些不同的策略？

👨‍⚕️主页： gis分享者
👨‍⚕️感谢各位大佬 点赞👍 收藏⭐ 留言📝 加关注✅!
👨‍⚕️收录于专栏：AI大模型原理和应用面试题

一、🍀回答重点

做这层抽象的根本原因是 Context 管理没有万能方案。

通俗理解：Context Engine 就像手机的存储管理。有的人喜欢自动清理旧照片，有的人喜欢只删大文件，有的人喜欢全部存云端按需下载。

不同的应用场景、不同的模型上下文窗口大小、不同的任务类型，最优的 Context 策略差异巨大。

把 Context 管理抽象成接口（定义好"做什么"），让策略实现（“怎么做”）可以独立替换，既方便内部迭代，也方便社区扩展。

这就是经典的策略模式。

ContextEngine 接口定义在 src/context-engine/types.ts，覆盖了完整的生命周期：

这套接口覆盖了上下文管理的完整生命周期，核心有三大操作加上若干生命周期钩子：