OpenClaw 记忆系统的向量检索默认不可用——但 BM25 文本搜索兜底让系统照常运转了两周。当你发现「不配 embedding 也能跑」,到底要不要修?怎么用 NVIDIA 免费 API 零成本补上?
从部署到排障,记录 OpenClaw 从启动失败、飞书消息静默吞回复到 production 稳定的全链路实战经验——compaction safeguard、五层排查法、model-harness-fit 与记忆系统对比。
做 Agent 系统的人迟早会撞上这个选择题:用户的数据往哪放,下次对话怎么记住?
目前工业界有三条主流路线——RAG(向量检索)、LLM Wiki(结构化知识注入)、纯文本上下文记忆(CLAUDE.md / Cursor Rules 模式)。三条路各有拥趸,但选错的代价很大:RAG 做轻了是噪音生成器,纯文本做重了是 token 焚化炉。
这篇给出一个可以直接用的决策框架。
三种方案一句话定义 # 方案 核心机制 代表产品/模式 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 关键区别不在于"存哪里",而在于检索方式和注入时机。
这不是一篇"AI 科普"——这是一次用 Exa / Tavily / Context7 / WebSearch 四源交叉验证,覆盖 67 条一手资料 的硬核调研。如果你在给 Agent 系统设计记忆层,或者想搞清楚 ChatGPT Memory / Claude Memory / Cursor Rules 到底是怎么回事,这篇是你要看的东西。
→ 完整报告(含 14 产品对比表、9 条工程结论、3 年范式演进地图)
一句话结论 # 所谓「大模型没有记忆」不是疏忽,而是 O(n²) 注意力 + KV Cache 显存 + 灾难性遗忘 + GDPR 合规 四重约束的均衡解。ChatGPT / Claude / Cursor 的 “Memory” 本质都是把结构化文本 塞回 system prompt,模型权重永远不动。未来 1–3 年的主流是 「无状态 LLM 内核 + 有状态 Agent 记忆层」 混合架构。