今天 AI 记忆系统又进了一步：Engram、Claude Code、EdgeClaw 正在把“长期记忆”做成工程能力

今天 AI 记忆系统又进了一步：Engram、Claude Code、EdgeClaw 正在把“长期记忆”做成工程能力

最近一波关于 AI Agent 记忆系统的更新，很值得放在一起看。

一边，是面向开发者的开源图记忆库 Engram Memory SDK；一边，是 Claude Code 对长期任务记忆架构的极简重构；另一边，则是 OpenBMB 在 EdgeClaw 2.0 中把多级记忆能力正式产品化。

如果把这三者放在同一个坐标系里，你会发现：AI 记忆系统的讨论，正在从“能不能记住”转向“如何以更低成本、更强结构性、更可演进的方式持续记住”。

先说结论：记忆系统开始从功能点走向架构层

过去很多 Agent 的“记忆”，本质上还是向量库加检索片段。

这种方案在短任务里够用，但一旦进入长期任务、多轮协作、跨主题演进，问题会迅速暴露：

•上下文越来越长，成本越来越高

•老信息和新事实混在一起，噪声不断累积

•检索能找到相似文本，但未必能还原结构化关系

•写入容易，长期维护很难

这次三个方向的更新，恰好对应了三种工程答案：

•Engram：把记忆做成“图 + 向量 + 评分”的低成本基础设施

•Claude Code：把记忆约束成可维护的信息分层与写入纪律

•EdgeClaw 2.0：把多级记忆进一步做成可运行、可迁移、可治理的完整组件

Engram：把“摄入一次、低成本回忆很多次”做成现实

Engram Memory SDK 是一款面向智能体的开源图记忆开发库，核心思路非常直接：

在摄入阶段调用一次大模型，把实体与关系抽出来；之后回忆阶段不再依赖大模型，而是依靠向量搜索、图遍历和评分完成检索与召回。

这意味着什么？

意味着它把很多系统最贵的部分，尽量前置到了“写入时”。

一旦记忆被结构化进图里，后续 recall 就不需要每次重新调大模型“理解一遍”。如果开发者再进一步用小型本地模型做抽取，那么持续回忆的边际成本几乎可以视为零。

从工程角度看，这套设计对长期运行的 Agent 很友好：

•模型兼容性强：通过 LiteLLM 接入任意模型

•本地化友好：支持通过 Ollama、vLLM 等方式运行本地模型

•后端明确：异步 Python + Neo4j

•性能指标清晰：平均每次摄入约 735 词元，回忆延迟低至 95 毫秒

•系统具备演进能力：支持后台自我重构、记忆衰减与聚类

它代表的一种趋势是：

记忆系统不一定非要把“智能”全部压在读取那一刻，而是可以在写入阶段完成结构化，把回忆变成低成本工程过程。

这对于希望把 Agent 真正跑成“长期服务”的团队来说，非常关键。

Claude Code：长期记忆不是堆更多内容，而是减少熵增

Claude Code 这次提出的记忆系统架构，最值得关注的地方，不是“记得更多”，而是“如何防止越记越乱”。

它的核心是一个非常克制的三层设计：

•索引层：MEMORY.md，始终加载，但只做轻量指针

•主题文件层：按需读取，按主题组织有效记忆

•会话记录层：不整体加载，只通过 grep 搜索

这个设计背后的工程判断非常明确：

长期任务里，真正危险的不是记忆不够，而是上下文膨胀和信息噪声。

所以 Claude Code 对“写入纪律”的要求非常严格：

•每次更新后要立即刷新索引

•不允许直接 dump 大段内容进主记忆

•可推导事实不持久化

•如果旧记忆与当前代码冲突，应优先怀疑记忆已过时

这套规则其实非常像一个成熟工程团队的知识管理原则：

•主索引只放导航，不放正文

•主题信息按模块拆开

•原始记录保留，但只在需要时检索

•旧知识不是“资产”，很多时候反而是风险

更有意思的是它的 autoDream 机制。

这个后台子代理会在不打扰主流程的情况下，自动做几件事：

•合并重复信息

•解决矛盾内容

•修剪无用数据

•完成类似“睡眠巩固”的记忆整理

如果说 Engram 强调的是“低成本 recall”，那 Claude Code 强调的就是：

长期记忆必须可整理、可裁剪、可怀疑，否则系统最终会被自己的历史拖垮。

EdgeClaw 2.0：把多级记忆做成完整产品化能力

OpenBMB 发布的 EdgeClaw 2.0，则展示了另一条更完整的落地方向：

它不是只给一个记忆理念，而是直接把多级记忆做成了系统级能力，并通过 ClawXMemory 组件落地。

官方描述中，EdgeClaw 2.0 构建的是一套 四级记忆架构，覆盖从原始对话记录的细粒度溯源，到全局档案层面的个性化偏好管理。

这意味着它不是只解决“搜到哪段相关文本”，而是在尝试解决：

•什么信息应该进长期记忆

•不同层级的信息如何分工存储

•哪些内容该优先被路由到当前上下文

•个体偏好、任务历史、会话细节如何共同作用

更关键的是，它没有停留在传统向量检索范式，而是采用了模型驱动的主动推理策略：

•先通过全局画像做判断

•再进行层级路由

•再逐层下探

•最终动态构造上下文

这是一种明显更“主动”的记忆调度方法。

换句话说，系统不是等用户问了再去相似度匹配，而是先判断“当前任务最应该唤醒哪一层、哪一类记忆”。

在工程实现上，EdgeClaw 2.0 也体现出很强的产品化取向：

•记忆存储基于本地数据库，支持跨设备迁移

•内置可视化面板，便于观察和管理

•通过插件与钩子机制接管记忆生命周期

•支持全局安装或一键部署

•支持源码热重载开发

它和主程序的分工也很清晰：

•主程序负责端云协同与隐私分级

•记忆组件专注多级记忆与长期上下文

两者协同，试图同时解决三个现实难题：

•隐私安全

•成本优化

•上下文遗忘

三个方向放在一起看，值得注意什么？

如果把 Engram、Claude Code、EdgeClaw 放在一起看，我觉得至少有三点趋势已经很明确。

1. 记忆系统正在从“外挂检索”走向“原生架构”

过去的做法，常常是先有 Agent，再额外挂一个 RAG 或向量库。

现在的变化是：记忆已经不再是附加模块，而是开始进入系统设计的一开始。

Claude Code 直接把记忆写进工作流纪律，EdgeClaw 把记忆做成多级组件，Engram 则把记忆抽象成开发基础设施。

2. 成本意识成为核心约束

AI 记忆如果每次 recall 都重新跑大模型，长期一定会很贵。

Engram 的“摄入时抽取、回忆时免 LLM”是一种回答；EdgeClaw 的成本路由与分层上下文构造也是一种回答；Claude Code 的极简索引则是在源头减少无效上下文。

大家虽然路径不同，但都在回答同一个问题：

长期记忆必须成本可控，否则无法规模化。

3. 好记忆不是记得多，而是记得对、调得准、还能不断整理

这可能是这波更新里最重要的共识。

真正可用的记忆系统，不能只是“保存更多文本”，而必须同时具备：

•结构化能力：知道实体、关系、主题、层级

•调度能力：知道什么时候该唤醒什么记忆

•治理能力：知道哪些该保留，哪些该衰减，哪些该删除

从这个角度看，记忆系统已经越来越像数据库、检索系统、知识治理系统和 Agent 调度系统的混合体。

对开发者来说，最值得参考的不是结论，而是取舍

这三套方案不一定互相替代，反而更像三个不同层面的参考样本。

如果你是做基础设施，Engram 的意义在于：

•如何把 recall 成本压低

•如何让图结构真正为 Agent 服务

•如何把本地模型与生产链路接起来

如果你是做编码助手或长期 Agent 工作流，Claude Code 的意义在于：

•如何限制记忆熵增

•如何设计写入纪律

•如何让系统对“过时记忆”保持警惕

如果你是做完整产品或平台，EdgeClaw 的意义在于：

•如何把多级记忆做成产品能力

•如何让记忆和隐私、成本、路由协同工作

•如何为长期上下文提供可视化和生命周期管理

最后

AI Agent 的下一阶段竞争，可能不只是模型能力，也不只是工具调用能力，而是能否拥有一个真正可持续的长期记忆系统。

因为一旦任务进入长周期、多主题、多人协作、跨设备延续，记忆就不再是“锦上添花”，而是决定系统是否还能继续工作的基础设施。

Engram、Claude Code、EdgeClaw 这波更新，虽然路径各不相同，但都在回答同一件事：

AI 要想真正长期工作，就必须学会以工程化方式记住、怀疑、整理并重新调用过去。

这件事，才刚刚开始。

参考来源

•Engram Memory SDK：https://github.com/hackdavid/engram-memory[1]

•EdgeClaw：https://github.com/OpenBMB/EdgeClaw[2]

•Claude Code 新型记忆系统架构：基于用户提供信息整理

本文由山行整理自网络，如果对您有帮助，请帮忙点赞、关注、收藏，谢谢～

参考链接

[1] https://github.com/hackdavid/engram-memory: https://github.com/hackdavid/engram-memory

[2] https://github.com/OpenBMB/EdgeClaw: https://github.com/OpenBMB/EdgeClaw