MyOpenClaw 的上下文管理思考
本页目录
如果只说我最近对 myopenclaw 最核心的一个判断，那就是：不要轻易丢上下文。
我最近为 myopenclaw 的上下文管理试过不少方案。基于窗口的裁剪试过，基于窗口的裁剪加压缩试过，裁剪加压缩再接一层 LLM 试过，RAG 也试过。每一种方案都有自己看起来合理的地方，但最后我都不太满意。
因为这些方案都绕不开同一个问题：
在固定的 token budget 下，你凭什么知道什么该丢，什么不该丢？
这件事我现在越来越觉得是无解的。不是暂时无解，而是它本身就很难被彻底解决。因为你无法预知用户下一句会和什么相关。你今天以为无关紧要的一段失败尝试，明天可能正好就是防止 Agent 再次犯错的关键上下文。你今天觉得可以被压缩掉的一段工具调用细节，明天可能恰好就是判断为什么某个路径不该再走一次的依据。
所以我现在很难再相信那种“只要上下文裁剪得够聪明，问题就解决了”的说法。裁剪本质上就是删除，而删除上下文对 Agent 来说是一种非常昂贵的操作。因为一旦你把它丢掉了，你通常就无法保证它还能被完整找回来。
为什么我开始偏向“先存，再检索”
正因为这样，我后来越来越偏向一种更保守、但我觉得也更可靠的思路：先把上下文原样存下来，再去想怎么检索，而不是先想着怎么删。
这件事会直接改变问题的形状。
如果你的前提是“窗口装不下，所以我要先删掉一部分”，那你关注的永远是压缩、裁剪、摘要和取舍。可一旦你把前提改成“对话先完整存储，以 session 为单位保留”，那么问题就会从“预先删什么”变成“当前到底该取什么”。
这两种思路看起来很像，实际上差别很大。前者是在不可逆地做减法，后者是在已有的材料里做选择。对 Agent 来说，我越来越相信后者更稳。因为你至少保留了回头检索、再解释、再比较的机会。
当然，这并不意味着检索很容易。你把东西都存下来了，不等于上下文管理自动就变简单了。只是说，真正困难的地方不再是假装自己能提前做出完美取舍，而是承认你做不到，然后把系统做成一个更擅长按需调取的结构。
我为什么会去看 OpenViking
也是在这个背景下，我开始认真看 OpenViking。
按照它的 GitHub 说明，它把自己定义成一个面向 AI Agent 的 Context Database。对我来说，它最有意思的地方不是“又一个 RAG 系统”，而是它尝试把上下文管理抽象成一个更接近文件系统的东西。它会把 memory、resources、skills 这些内容组织成显式层级，再通过 L0/L1/L2 的摘要和递归检索去完成渐进式披露。
我很喜欢这个抽象。因为传统 RAG 给我的感觉往往是：所有东西都被打平了，然后丢进一个向量池里，再靠检索把相关块捞出来。它当然有用，但也非常黑箱。OpenViking 更像是在说：上下文本身是有结构的，而这个结构应该能被 Agent 和人一起理解。
这点非常重要。因为上下文管理最怕的不是“不够智能”，而是“你根本不知道它在干什么”。一旦检索路径是不可见的，系统就很难调，很难 debug，也很难积累真正稳定的经验。OpenViking 在这方面给了我很大启发，它至少试图让上下文管理变成一个更显式、更可观察的系统。
但我为什么最后没有让它接管实时主上下文
尽管如此，我最后还是没有把 OpenViking 直接拿来做 myopenclaw 的实时主上下文管理器。
原因也很明确。
第一，它解决的是“怎么更高效地检索”，但并没有替你解决“为什么现在应该这样检索”。检索系统本身再漂亮，也仍然需要意图识别，需要策略，需要决定当前这一次到底该往哪一层、哪一类内容上搜。
第二，它很多收益建立在分层摘要和显式整理之上，而实时对话型 Agent 恰恰最讨厌在主链路里塞进太重的延迟。你每多一层摘要、每多一次检索、每多一次意图判断，都会直接吃掉交互体验。
第三，一旦你为了实时性采用混合方案，你就会得到双重抽象。一边是你本地的窗口策略，一边是外部上下文系统的检索与摘要机制。到了最后，你往往很难判断到底是哪一层真的在起作用，也很难知道收益到底来自哪里。
这也是为什么我后来反而越来越克制。我不再想让某个单一系统“统一接管一切”，而是更愿意承认实时链路和深度检索链路是两种不同的问题。
我现在更相信一种双轨结构
所以我现在对 myopenclaw 的判断，越来越偏向一种双轨结构：
本地轻量窗口管理负责实时性，外部上下文系统负责按需深挖。
这意味着，我不想让 OpenViking 直接成为当前会话的主上下文来源。我更愿意把它做成一个 skill，让 Agent 在真正需要的时候主动去调用它，比如做知识库问答、跨会话回忆、用户偏好召回，或者需要沿着历史记录深挖某个模式的时候。
这样它的价值反而更稳定。因为渐进式披露、分层摘要和结构化检索，本来就更适合那些“值得慢一点，但要更深一点”的场景；而不是适合所有实时对话都无差别地走一遍。
换句话说，我现在并不相信一个完美的统一上下文系统。我更相信快慢分层，相信实时链路和深度链路应该用不同的抽象来处理。
为什么我反而觉得“进化”更适合放在这一层
也正因为如此，我后来反而会想：OpenClaw、Hermes 那种“技能沉淀”“经验复用”“自我进化”的思路，真正更适合落地的地方，可能不是实时对话主链路，而是像 OpenViking 这样的外部上下文层。
原因很简单。因为这一层天然就在管理对话、技能、工具和资源，还天然适合做摘要、嵌入、关系记录和统计。无论是模式识别、skill 生成、skill 调用记录，还是用户偏好追踪，放在这里都更自然。
如果再往前想一步，我甚至会觉得 Agent 应该拥有一个专门管理这层上下文仓库的 git。因为一旦上下文不只是被读写，而是能被版本化、比较、回滚和审计，那么它对 Agent 就会友好得多。到那个时候，“上下文管理”就不再只是给模型凑 token，而更像是在给 Agent 建一个真正可演化的操作系统。
我现在对 myopenclaw 的结论
如果把这些想法压成一个结论，那就是：
我越来越不相信“聪明裁剪”会是上下文管理的终局。因为裁剪的前提，是你真的知道什么以后不重要；而我觉得在开放式对话和 Agent 执行里，这种自信通常是不成立的。
我现在更愿意接受一个更朴素的现实：上下文应该尽量先被保存，再通过结构化检索按需调用。实时链路应该尽可能轻，而深度上下文应该放到一个更适合做分层、做检索、做沉淀、做版本化的外部系统里。
所以 myopenclaw 现在最让我在意的，不是怎样找到一个完美的上下文压缩技巧，而是怎样把本地窗口策略和外部上下文系统拼成一个真正可用、可回溯、可演化的基础设施。
这件事显然还远没有结束，但至少现在，我已经不太相信“删得更聪明”这条路了。我更相信的是：别轻易丢上下文。