很多 agent 之所以越做越乱，不是因为上下文窗口不够大，而是把“上下文装配、状态续航、长期记忆”三件事混成了一件事。OpenViking、lossless claw 和基于 QMD 的记忆管家，真正合理的关系不是三选一，而是分层协同。

很多人一看到 agent 总失忆，第一反应都是：是不是上下文不够大。

但真做过长任务的人都知道，很多时候不是装不下。

而是系统一路都在丢。

它忘了前面已经确认过的约束。
它忘了这轮任务真正的目标。
它忘了上一阶段为什么放弃某个方案。

更糟的是，它有时不是单纯忘了，而是把旧状态、新状态和错误召回的信息混在一起，然后非常自信地继续往下做。

如果你做过 agent、个人工作流，或者任何需要长期协作的系统，这种场景大概率都见过。

所以我最近一直在想一个问题：

OpenViking 对上下文管理很强。
lossless claw 能明显减少长链路里的失忆。
而我自己的记忆管家，是依托 QMD 做索引的长期记忆系统。

那这三者，到底应该结合，还是互相替代？

我现在的答案很明确：

不是替代，是分层组合。

因为它们解决的，根本不是同一层问题。

“模型失忆”这个词，本身就太粗了。

至少要拆成三件事。

第一件，是当前任务需要什么上下文。
这些上下文怎么组织，怎么加载，怎么知道自己拿对了没有。

第二件，是模型在长链路执行里，状态怎么不断。
不是这一轮知道，下一轮靠摘要猜。
不是任务做了一半，一压缩就开始重新理解目标。

第三件，是长期记忆怎么沉淀。
什么值得记，怎么索引，怎么更新，怎么回溯，怎么让它最后不是一堆没人敢信的日志。

如果不把这三件事拆开，你就会进入一种很常见的假进展：

上下文越来越多。
历史越来越长。
记录也越存越全。

但系统并没有真正变得更可靠。

它只是看起来像“记住了很多”。

这也是为什么，我现在更愿意把 OpenViking 理解成“上下文控制面”。

它真正重要的地方，不是替模型永久记住什么，而是把本来碎片化的上下文重新组织起来。

记忆在一处。
资源在一处。
技能在一处。
历史又在另一处。

这本来就是大多数 agent 系统的常态。

这种结构下，agent 每次工作都像在黑箱里抓材料。你以为它理解了全局，实际上它常常只是碰巧拿到了看起来像答案的那部分内容。

OpenViking 这类思路的价值，在于，它不把上下文当成一堆扁平文本，而是试图把资源、记忆、能力和材料组织成可定位、可浏览、可调试的结构。

这件事听上去不性感，但很关键。

因为很多所谓“记忆失败”，根本不是模型没记住，而是它从一开始就没拿到该拿的上下文。

或者它拿到了一大堆，但没有层次，不知道什么该优先，什么只是噪音。

所以 OpenViking 更像在解决一个问题：

当前这次任务，到底该把什么带进来。

这不是长期记忆。

这是上下文装配。

再看 lossless claw。

我越来越觉得，它解决的也不是同一个问题。

如果说 OpenViking 负责“怎么把材料拿对”，那 lossless claw 更像在解决“怎么别在中途掉状态”。

很多人把 agent 的失忆归因于 context window 不够大，这只说对了一半。

真正让人崩溃的，往往不是装不下，而是压缩之后变形了。

做过长任务的人应该都懂这种感觉。

系统明明已经工作了一段时间。
也有摘要，也有中间状态。
也不是完全没有保存。

但一到关键节点，它突然不理解你们前面共同确认过的东西了。

它记得结论，不记得依据。
它记得表面任务，不记得隐藏约束。
它记得最新摘要，不记得为什么这个摘要会长这样。

这不是传统意义上的“长期记忆缺失”。

这是工作状态在传递过程中被损耗了。

所以我会把 lossless claw 放在“会话续航层”。

它的价值，不在于让 agent 拥有了永久记忆。

它的价值，在于尽可能让任务状态、工作记忆和执行脉络，在 compaction、阶段切换和长链路推进中不要断得太厉害。

你可以把它理解成一句更直白的话：

OpenViking 解决的是“拿什么进来”。
lossless claw 解决的是“别在中途丢掉”。
QMD 记忆管家解决的是“什么值得长期留下”。

这三个问题不一样，所以它们也不该互相替代。

这也是为什么，lossless claw 依然不是长期记忆层。

因为长期记忆要回答的问题，完全不同。

几周之后，这个系统还能不能知道某个用户稳定的偏好？
还能不能还原某个项目之前做过的判断？
还能不能说清一条规则是怎么演化来的？
还能不能区分“临时状态”和“长期事实”？

这才是长期记忆真正要解决的事。

而这也是为什么，我更愿意把自己的 QMD 记忆管家放在第三层来理解。

它更适合承接长期记忆层。

这一层不追求每轮都塞进模型。
也不追求替代运行时上下文装配。
它真正要做的，是把值得长期保留的信息，沉淀成可读、可索引、可审计的知识资产。

这也是我为什么一直偏向 Markdown 加索引的路线。

长期记忆如果完全黑箱化，最后一定会出问题。

你不知道哪些信息为什么被记住。
你不知道某个偏好是什么时候改的。
你不知道一个结论来自哪次对话、哪份文档、哪个项目阶段。

系统表面上有记忆，实际上只有一堆越来越不可验证的痕迹。

Markdown 的价值，在于它始终是人能读、能改、能审的。
QMD 的价值，在于它让这些原始记录不会因为越积越多就失去可用性。

它不是替模型“多记住一点”。

它是在帮系统把长期记忆从日志堆，变成资产库。

所以这三者的位置，其实很清楚：

OpenViking 负责上下文控制面。
lossless claw 负责会话续航层。
QMD 记忆管家负责长期记忆层。

它们分别回答三个问题：

这次任务，什么应该进入当前上下文？
哪些状态在 compaction 之后绝对不能丢？
哪些信息值得成为长期记忆，而不是一次性的聊天残留？

这三个问题不分开，你就会一直被一个伪问题困住：

到底该做更强的上下文系统，还是更强的记忆系统？

但其实两者不在同一层。

中间还隔着一个最容易被忽略的续航层。

这也是我现在对这个题目的核心判断：

OpenViking、lossless claw、QMD 不是三选一。

它们更像是三层拼图。

只靠 OpenViking，不足以保证长链路状态不漂。
只靠 lossless claw，不足以让长期知识变成可维护资产。
只靠 QMD 记忆管家，也不足以处理运行时的上下文装配和任务续航。

如果真要做一个更可靠的记忆系统，方向不是“找一个万能模块”。

方向是承认：记忆本来就不是一个单点功能。

它至少包括三层：

上下文是装配。
状态是续航。
记忆是沉淀。

这句话，我觉得可以直接拿来检查自己的系统。

你现在解决的，到底是哪一层问题？
你缺的，到底是更大的上下文，还是更少损耗的续航，还是一套能长期沉淀的记忆底座？

很多时候，答案不是“换一个更强的工具”。

而是先别再把三种问题，当成一种问题。

如果你身边也有正在被 agent 失忆折磨的人，这篇可以转给他。

也欢迎你留言告诉我，你现在最痛的是哪一层：上下文拿不准，压缩后会漂，还是长期记忆根本管不起来。

#OpenViking #losslessclaw #QMD #AI记忆系统 #Agent失忆 #上下文工程