记忆系统 on 卓琪的开发笔记

Agent 如何记住你：人脑记忆史与六大开源系统代码审计

Thu, 30 Jul 2026 00:00:00 +0000

几乎每个 Agent 项目都说自己有「长期记忆」。

有的意思是把聊天记录做 embedding，有的意思是维护一份用户画像，有的意思是让模型自己修改 Markdown，还有的已经做到了双时序知识图谱。它们都叫 memory，却不是同一种东西，也不该放在一张跑分榜上直接比较。

要判断一个系统是不是真的「会记」，我更愿意问三个问题：

一次经历之后，系统里的什么状态发生了变化？
这个状态存在哪里，谁能修改，什么时候失效？
下一次行动前，它如何被准确、合规地带回来？

这篇文章从这三个问题出发。前半段把人类记忆科学与 Agent 记忆技术放在同一条历史轴上；后半段直接读代码，对照 Mem0、Letta、Graphiti、LangMem、Cognee 与 MemoryOS 的宣传卖点、实际数据流、系统边界和对应的记忆范式。

先给结论： 今天主流的 Agent 并没有获得一种像人脑那样的统一「记忆器官」。工程上真正有效的是一条闭环：经历 → 写入门控 → 表征 → 存储 → 检索 → 上下文组装 → 行动反馈 → 巩固 / 修订 / 遗忘。不同开源项目，只是选择接管这条闭环的不同部分。

下面这张图不是某个产品的组件架构，而是全文共用的判断坐标系。它要回答的不是「数据放在哪」，而是「一次过去的经历如何真正影响下一次行动」。阅读时先沿中间的七步主环看信息如何从经历变成行动；再看左侧三种载体，区分当前任务、跨会话记忆与真实世界状态；右侧说明每一步完成的变换，底部则展示长期运行后必须发生的巩固、修订与遗忘。这样能避免把数据库、Context、缓存和真实状态都笼统地叫作“记忆”。

OpenClaw 记忆实战：从「向量搜索挂了也能用」到用 NVIDIA 免费 API 补全最后一块拼图

Sat, 20 Jun 2026 00:00:00 +0000

OpenClaw 记忆系统的向量检索默认不可用——但 BM25 文本搜索兜底让系统照常运转了两周。当你发现「不配 embedding 也能跑」，到底要不要修？怎么用 NVIDIA 免费 API 零成本补上？

OpenClaw 生产踩坑：当最先进的记忆系统遇到最静默的失败

Wed, 27 May 2026 00:00:00 +0000

从部署到排障，记录 OpenClaw 从启动失败、飞书消息静默吞回复到 production 稳定的全链路实战经验——compaction safeguard、五层排查法、model-harness-fit 与记忆系统对比。

什么时候用 RAG，什么时候用 LLM Wiki，什么时候用纯文本记忆——一个 Agent 记忆选型框架

Mon, 11 May 2026 00:00:00 +0000

做 Agent 系统的人迟早会撞上这个选择题：用户的数据往哪放，下次对话怎么记住？

目前工业界有三条主流路线——RAG（向量检索）、LLM Wiki（结构化知识注入）、纯文本上下文记忆（CLAUDE.md / Cursor Rules 模式）。三条路各有拥趸，但选错的代价很大：RAG 做轻了是噪音生成器，纯文本做重了是 token 焚化炉。

这篇给出一个可以直接用的决策框架。

先看三条路线的系统边界。它们的核心差异不是数据库品牌，而是检索发生在什么时候、多少内容进入 Context、写入和维护由谁负责。

三种记忆路线：RAG 擅长从大规模异构资料中按需召回；LLM Wiki 强调结构与审计；纯文本适合少量高价值、需要确定性注入的规则。没有一条路线在所有维度都占优。

三种方案一句话定义
#

方案	核心机制	代表产品/模式
RAG	向量检索 → top-k 片段 → 拼入 prompt	Mem0, Zep, LangChain RAG, Cursor Codebase Index
LLM Wiki	结构化文档 → 全量或按需注入 system prompt	Claude Projects, GPTs Knowledge, Notion AI
纯文本上下文	Markdown/文本文件 → 直接拼入 system prompt	CLAUDE.md, Cursor Rules, AGENTS.md, Devin Knowledge