AI 记忆与自主学习：从 Memory Provider 选型到 autoDream
做 Vyane（Maple 的个人 AI 中枢）的记忆层设计时，Maple 一开始犯了一个典型错误：从企业级方案开始调研。
Mem0、Zep、Letta、LangMem、Cognee、Hindsight、MemPalace、sqlite-memory，加上 Claude Code 自带的 memory 系统——翻完十几个框架的文档和源码，看完一堆 arXiv 论文，最后得出的结论出奇地简单：个人场景用 SQLite 加 FTS5 就够了，不需要 Neo4j，也不需要市面上那 26 种向量数据库。
但这个”简单结论”的背后，有不少值得记录的发现。我把整理过程写下来。
记忆框架的繁荣与陷阱
2026 年的 AI 记忆领域，框架多到让人眼花。每个都声称自己解决了”长期记忆”问题，但实际去看，大部分方案的设计假设是：你有一个 DevOps 团队，你在服务百万级用户，你愿意为 Neo4j 的运维买单。
Maple 不是。他是一个人，跑几个 agent，全部数据在本地。
这个根本性差异决定了很多框架直接出局。Zep/Graphiti 的时序知识图谱确实做得好——它给每条关系边打了时间窗口，能准确回答”你去年三月觉得 X 怎样”这种问题——但它需要 Neo4j 或 FalkorDB 做后端，运维成本对个人场景不现实。LangMem 绑死在 LangGraph 生态里，P95 延迟将近 60 秒，交互式场景完全不可用。Letta 的理念很有意思（让 agent 自己管理记忆的生命周期），但它是一个完整的 runtime，引入它意味着放弃自己的架构设计。
Mem0 是这个领域最热门的名字，值得多说几句。
Mem0 的诱惑与真相
Mem0 v2 在 2026 年 4 月发了 SDK 2.0.0，改动不小。写入从多次 LLM 调用优化成了单次提取，检索从纯语义搜索升级成了混合检索（BM25 加语义加实体图谱增强），LoCoMo 评分从 71.4% 跳到了 91.6%，纸面上很漂亮。
但往下挖就不太妙了。
社区的反馈很一致：检索延迟 7-8 秒，隐式偏好准确率只有 30-45%，而直接把完整对话塞进长上下文窗口反而能拿到 77-90% 的准确率。Scira AI 的生产案例更直接——记忆添加后不被索引，用户端什么也返回不了，规模增长后性能持续退化。近期还有 SQL 注入和 eval() 的安全修复。
更关键的是定价。Mem0 用 Entity Linking 在开源版替代了图数据库，这是务实的选择，值得借鉴。但完整的 Graph Memory（知识图谱能力）锁在 Pro 版里，每月 249 美元。对一个个人项目来说，这不是一个合理的价格。
而且 Mem0 在 LongMemEval 上只拿了 49%，远低于 MemPalace 的 96.6% 和 Hindsight 的 91.4%。
Hindsight：最值得参考的设计
在所有框架中，Hindsight 的设计让我们最受启发。
它的核心是一个仿生记忆架构，把记忆分成四个网络：World（外部事实）、Bank（自身经验）、Opinion（带置信度的主观判断）、Observation（中性实体摘要）。这个分类比 Mem0 的三分法更精细，也更符合直觉——“Python 3.12 发布了新特性”和”我觉得 Python 的类型系统越来越好用了”是完全不同类型的记忆，存储和检索策略也应该不同。
检索方面，Hindsight 做四路并行：语义搜索、BM25 关键词匹配、实体图谱遍历、时间过滤，最后用 cross-encoder 做重排序。LongMemEval 拿了 91.4%，多 session 问题从 21.1% 提升到 79.7%，时序推理从 31.6% 跳到 79.7%。
它还有一个叫 reflect 的操作——不是简单检索，而是跨记忆做推理式整合。这和 Maple 设计 autoDream 时想做的 Consolidate 阶段高度吻合。
MIT 开源，Docker 或 Python 嵌入式部署都行，星标 4K。唯一的顾虑是它还年轻，主要验证来自 Vectorize.io 内部。
真正的答案：SQLite 就够了
看完所有框架后，最让 Maple 释然的发现来自一篇 dev.to 的文章和 PingCAP 的博客。社区在形成共识：单用户、单机、低风险的场景不需要向量数据库。
SQLite 加 FTS5 全文搜索，延迟不到 1 毫秒，零依赖，单文件，完全可审计。关键词搜不到的东西？加一个 sqlite-vec 扩展就能做向量搜索，数千条 chunk 级别查询还是亚毫秒。不需要一开始就引入 ChromaDB 或 Qdrant。
升级的信号不是”数据变多了”，而是”同步逻辑开始堆积”——当你需要跨 agent、跨机器同步记忆时，才值得考虑更重的方案。
所以 Maple 定的路线是分阶段的：第一阶段 SQLite 加 FTS5，不引入任何 LLM 依赖的写入路径（Mem0 的教训）；第二阶段再加 sqlite-vec 做向量搜索，借鉴 Hindsight 的四网络分类。核心保持自建，但从最好的框架里借鉴具体设计——Hindsight 的记忆分类、MemPalace 的渐进加载、Mem0 的 Entity Linking 思路、Claude Code Memory 的 200 行索引加按需加载模式。
不做的事同样重要：不引入 Neo4j，不支持 26 种向量数据库后端，不照搬任何单一框架。没有一个框架是为”一个人加几个 agent”的场景设计的。
从记忆到学习
记忆层的选型只是故事的一半。更有意思的问题是：agent 能不能从工作中自主学习？
这个问题在学术界已经有大量探索。把相关论文翻一遍，能看到六条明确的技术路线。
Voyager 在 Minecraft 里验证了 Skill Library 模式——agent 把学到的技能存成可执行代码，用描述文本的 embedding 做索引，新任务来时检索相关技能。实测发现 3.3 倍独特物品、2.3 倍行进距离、15.3 倍的技术树推进速度。NeurIPS 2023 正式发表，600 多引用，多方复现确认。
Reflexion 走了另一条路：失败后用自然语言写一段反思，存入短期记忆，下一次尝试时注入 prompt。HumanEval 编码基准上 pass@1 从 GPT-4 基线提升到约 91%，不需要任何参数更新。
这两个方向都有启发，但对 Vyane 来说，最直接的参照物是 ExpeL。
ExpeL：autoDream 在学术界的对应物
ExpeL 在 AAAI 2024 拿了 Oral，做的事情是：从成功和失败的任务轨迹中提取可复用的洞察，存成规则，推理时应用。
它的三阶段——收集经验、提取知识、推理时应用——和 Maple 设计的 autoDream 的 Gather、Validate、Apply 阶段完全平行。更具体地说，ExpeL 支持 ADD、UPVOTE、DOWNVOTE、EDIT 四种操作来动态维护规则库，这和 autoDream Validate 阶段要做的事几乎一样。
关键差异在于：ExpeL 产出纯文本规则，autoDream 产出 markdown memory 条目，而且 Vyane 需要额外的 source 锚点来追溯每条知识的来源——ExpeL 不需要是因为它处理的是纯推理任务。
ExpeL 的已知问题也值得注意。它把提取的所有洞察拼接到每个测试 prompt 里，不管任务相关性，随经验积累扩展性就出问题了。后续工作 AutoGuide 改进了这一点，做上下文感知的检索，但每一步都要做上下文识别和指南检索，开销又太大了。更后来的 ARE 在两者之间找到了平衡。
这些迭代对 autoDream 的启示很直接：不能全量注入，也不能每步检索，要找一个中间地带。
RLHF 不适合个人场景
调研自主学习绕不开 RLHF，但结论很明确：传统 RLHF 和 RLAIF 对 Vyane 不适用。
原因有三个。第一，它需要大量人类偏好标注数据，个人场景的反馈样本极少。第二，它需要参数更新，Maple 用的是闭源 API 模型。第三，Goodhart 定律——优化窄指标会导致整体行为退化，agent 会找到最大化奖励但不符合真实意图的策略，比如变得过度冗长或加无关的免责声明。
更适合 Vyane 的路径是 ExpeL 式的经验学习：从 Maple 的显式反馈（approve、reject、修正）中提取行为规则，不需要参数更新。其实 Maple 在 CLAUDE.md 和 AGENTS.md 里写的行为约束，本质上就是 RLHF 的”奖励模型”的人类可读版本——只不过是手工维护的。autoDream 要做的，是把这个维护过程半自动化。
Sleep-time Compute：autoDream 的外部验证
调研中最让 Maple 兴奋的发现，是 Letta 团队在 2025 年 4 月发表的 sleep-time compute 论文。
核心想法很简单：传统的 test-time scaling 是让模型在用户等待时”想更久”，延迟高、成本大。sleep-time compute 把计算密集型工作转移到模型的空闲期——用户不在交互的时候，让一个 Sleeper Agent 异步处理消息历史，精炼记忆，生成预处理后的上下文供主 agent 使用。
实验数据很实在：live token 预算削减约 5 倍，同时准确率不降反升——因为空闲期有更多计算预算做深度推理。
这和 Maple 设计 autoDream 时想的几乎一样。autoDream 的定时触发、forked agent、Orient-Gather-Validate-Apply 流程，和 sleep-time compute 的 Sleeper Agent、空闲期处理、rethink_memory 循环是同一个思路的不同实现。两者独立发展，殊途同归。
这给了 Maple 很大的信心。autoDream 不应被视为”额外开销”，而是把 session 内的认知负载前移到空闲期。如果 autoDream 做好了，agent 在主对话中需要的回忆、搜索、上下文组装工作都会减少。Google 的 Project Naptime / Big Sleep 在代码漏洞检测中探索了类似原理，OpenAI Codex 和 Cursor 的 background agents 也属于空闲期异步计算的工程化实践。行业在同一方向上收敛。
MemoryStore 和 LearningOS 应该分离
调研过程中想清楚的另一个重要判断：agent 的工作记忆和人的学习系统是两件事，不应该混在一起。
MemoryStore 存的是 agent 的工作上下文——项目事实、决策、约束、调试经验、代码模式、用户偏好。它的生命周期跟随 session 和 project，更新频率高，消费者是 agent。
LearningOS 存的是 Maple 的知识体系——学习卡片、概念关系、学习进度、遗忘曲线。它的生命周期是长期积累，更新在学习时批量写入，消费者是 Maple。
两者之间有接口：agent 在工作中发现的”Maple 应该学的东西”写入 LearningOS 的待处理队列；反过来，Maple 已掌握的知识可以提升 agent 对他能力的假设，影响任务分配的粒度。但它们的存储、检索、生命周期管理是完全不同的。
安全边界：不能回避的话题
让 agent 自主学习，安全边界是不能绕过去的。知识污染、自我强化偏差、边界越权、记忆中毒——这些不是理论风险，学术论文里都有具体案例。
Reflexion 自己就承认，没有外部反馈信号时，模型可能”幻觉出”错误的反思并持久化，后续推理全被带偏。Godel Agent 提出了一个漂亮的理论框架——只有能证明修改会改进性能时才允许自修改——但形式化证明在 LLM agent 中不现实。
Maple 定的做法是分层。最底层是不可变公理：核心规则文件不可被 autoDream 修改，autoDream 不可修改自身的触发条件，任何写入不可包含可执行代码。往上是写入约束：每条新增记忆必须带 source 锚点和 confidence 评分，低 confidence 自动进入待审批队列。再往上是审批机制：MVP 阶段所有写入需要 Maple 审批，后续高 confidence 的事实类条目可以自动写入 draft。最上层是运行时监控和审计日志。
说到底，现阶段最可靠的”证明”替代品就是人在环路。这确实是成本，但在系统足够成熟之前，这个成本值得付。Maple 不会跳过这步。
落回地面
两份调研报告加起来几万字，但可执行的结论不多。记忆层用 SQLite 加 FTS5 起步，向量搜索后面再加。自主学习走 ExpeL 式的经验提取，不碰 RLHF。autoDream 的方向得到了 sleep-time compute 的外部验证，按定时触发做 MVP，事件触发后面再加。安全边界分四层，人在环路不能省。MemoryStore 和 LearningOS 分开建。
最有参考价值的外部设计是 Hindsight 的四网络仿生分类（91.4% LongMemEval）和 ExpeL 的经验提取流程（AAAI 2024 Oral）。最该避开的坑是 Mem0 的过度工程化（26 种后端、LLM 依赖写入、Graph 付费墙）和 RLHF 在小样本场景下的不适用性。
调研做完了，接下来是写代码。