超越 OpenClaw 13.4%：LightClawACE 的“六层记忆”做对了什么？

前言

如果把这些分项放在一起看，会发现 LightClawACE 强的并不是某一个偶然分项，而是长期交互最关键的四件事：记住用户、记住偏好、更新知识、延续上下文。这也是为什么，这组结果更像是在回答“Memory 系统是否真的可用”，而不是只回答“系统有没有把一些历史存下来”。

图1: LongMemEval 评测结果总览

如果把这些分项能力往回推，会发现 LightClawACE 的优势并不是来自某个孤立模块，而是来自一条更完整的 Memory 链路：

在我们看来，LightClawACE 至少做对了五件事：

很多系统并不缺“存”和“查”的能力：会话历史可以存，向量库可以查，文件系统里也可以落盘。但问题在于，信息往往只是被堆在那里，并不会自然地从会话流入中期记忆，再从中期记忆演化成长期知识。

LightClawACE 更强调的是一条持续流动的链路：

图 2：LightClawACE 的记忆流动链路

每次对话结束→ 按周期提炼到 memory/YYYY-MM-DD.md → 再按更长周期蒸馏到 MEMORY.md

这个设计思路与 OpenClaw 公开文档中呈现出的“多层 Markdown memory 文件”方向有相通之处。 OpenClaw 官方文档明确将 memory/YYYY-MM-DD.md 定义为日常运行上下文 / 每日笔记层，将 MEMORY.md 定义为更稳定的长期记忆层，并强调这些 Markdown 文件是 memory 的 source of truth。

也就是说，真正被系统持续使用的记忆，不该只是临时塞在上下文里，而应该有明确、可审阅、可持续演进的落点。

但 LightClawACE 想推进得更远：不是“也有 daily memory 和 long-term memory”就够了，而是让这条链路持续增量运行。系统只处理新增或变化过的内容；重复内容在写入前进行相似度比对，避免反复沉淀；长期记忆膨胀到一定规模后，再做主题收敛与内容合并。这样，Memory 就不再是静态结果，而是一条随着交互持续演进的知识流。

图 3：多阶段压缩与质量守卫

长会话一定会遇到上下文压缩问题。最简单的方法是截断，代价也最明显：关键信息会被无差别丢弃。另一种常见做法，是在 token 逼近上限时做一次大摘要，但复杂会话里很容易出现语义塌缩：约束被遗漏，细节被模糊，多轮关系被压扁成抽象描述。

LightClawACE 在这里采用的不是“一次性 summarize”，而是更偏工程化的多阶段压缩：先按复杂度分块，再做局部摘要，再做全局合并，最后通过质量守卫做校验。它的目标不是“产出一个 summary”，而是把摘要本身纳入一条可审计的信息保真流程。

这也是它和很多简单 summarize memory 方案的差别所在。很多系统的问题并不是“没做压缩”，而是 做完压缩之后，重要信息已经悄悄流失，但系统自己不知道。如果说 Memory 的第一步是沉淀，那么第二步就必须是：在不得不压缩的时候，尽可能把信息损失控制在可治理范围内。

从结果上看，这类设计尤其容易反映在 single-session-user 和 single-session-preference 这类维度上。因为用户事实、偏好和长期约束，恰恰是最容易在粗暴压缩中优先流失的内容。

图 4：装配式上下文构建

存下来只是第一步，真正决定记忆价值的是：它能否在正确的时刻重新进入推理。

OpenClaw 的公开文档已经清楚说明，它并不是简单全文搜索，也不是把所有记忆全量塞进 Prompt。

官方文档明确给出了 memory_search / memory_get 这类工具接口，以及对 MEMORY.md 和 memory/**/*.md 的检索机制；在检索层，系统支持 hybrid BM25 + vector，并进一步支持 MMR 与 temporal decay 这类后处理策略。

这说明它的核心思路已经是：通过检索把相关信息拉回，而不是让全部历史常驻上下文。

LightClawACE 认同这条方向，但在使用方式上更进一步：我们把召回设计成一次装配式上下文构建。长期偏好和背景知识来自 MEMORY.md，近期连续性来自 daily memory，当次问题需要的跨期知识则来自混合检索。最终进入 Prompt 的，不是“系统现在一共有多少记忆”，而是“当前任务真正需要哪些记忆”。

这背后的核心判断很简单：长期记忆不是为了常驻 Prompt，而是为了按需回到 Prompt。

只有当 Memory 被装配成当前任务的有效输入，而不是一堆静态存量数据时，它才真正成为推理能力的一部分。

Memory 系统在理想环境里表现好，并不代表它在真实环境里就可用。向量检索、embedding 服务、外部 API、本地 sidecar、额外模型，这些组件都可能失败。

只要其中一环不稳定，整条高级召回链路就会受到影响。

OpenClaw 在这方面已经给出了很明确的工程参考。官方文档说明，memory 工具由当前 memory plugin 提供；同时，文档也明确提到其存在 QMD backend 与内建 SQLite 方案，并在相关说明中强调，当复杂后端不可用时，系统会退回到更基础的可用路径。

这类设计的核心哲学其实非常重要：高质量召回可以依赖复杂组件，基础记忆能力不能依赖它们。

LightClawACE 延续的是同一种工程判断，但更强调一条底线：embedding 可用时走 hybrid；embedding 或向量后端不可用时，自动退化为 FTS-only 路径，保证系统至少仍然具备基础的可检索、可召回、可延续能力。

这类设计不会让系统在最好环境下显得最“炫”，但它决定了系统在普通环境、受限环境和异常环境里还能保留多少能力。对于真正长期运行的 Agent 来说，这往往比峰值效果更重要。

图 5：六层记忆分离架构

随着系统变复杂，一个更根本的问题会出现：不同生命周期的数据，是否应该继续混在同一层里？

LightClawACE 更倾向于把记忆拆成六层：

这样做的意义，不是为了让结构“好看”，而是为了让系统在演化时边界更清楚：哪些内容只是阶段性摘要，哪些内容已经适合沉淀进长期记忆，哪些内容只是为了检索效率而存在的派生索引，哪些内容应该被提升为结构化事实。

OpenClaw 的公开设计已经证明，“Markdown 作为可读、可审阅、可检索的 memory source-of-truth”是一条成立的路线。LightClawACE 想再往前推进的是：让这些层不只是可见，而且可治理。 也就是说，Memory 不只是“有文件、有检索”，而是能在不同生命周期上承担不同职责。

如果只从表面看，很多 Agent 都能说自己“支持 Memory”：

但 LongMemEval 这类 benchmark 的价值恰恰在于，它逼着大家回答一个更难的问题：这些能力的存在本身，是否真的能支撑长期交互体验。

从这次内部评测结果来看，LightClawACE 的优势并不在某个单独技巧，而在于它把 Memory 设计成了一条完整链路：

这几件事叠加起来，带来的就不再只是“记得更多”，而是：

也正因为如此，LightClawACE 赢下的，不只是一个 benchmark 分数，而是对 Agent 长期记忆这件事的一种更完整的工程回答。