三亩地 三亩地SAN MU DI · CODE DIARY
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天,欢迎挑你感兴趣的翻一翻。

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

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

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

文章目录

  • 一、🍀回答重点
  • 二、🍀扩展知识
    • 2.1 ☘️内置的 legacy 引擎
    • 2.2 ☘️可以实现的高级策略
    • 2.3 ☘️插件注册机制
  • 三、🍀追问

一、🍀回答重点

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

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

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

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

这就是经典的策略模式。

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

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

阶段方法做什么
初始化bootstrap会话首次创建时做初始化(比如导入历史)
← 返回列表