痛点引入
你有没有遇到过这种情况：
你让AI专家agent去处理一个复杂任务，它满口答应，开始干活。结果第二天你问它进展如何，它一脸茫然："什么任务？"
这就是我常说的AI Agent的"失忆症"。
更准确地说，它不是真的"失忆"，而是记忆系统设计缺陷导致的"信息丢失"。
2026年5月，深度研究了这个问题，部署了两套开源记忆系统，翻了大量论文和GitHub仓库，最终摸索出一套适合自己的轻量化方案。
今天把这段时间的思考和实践分享出来，供同样在探索AI Agent记忆系统的朋友参考。
我们的技术架构
先介绍一下当前知识管理+记忆管理的架构。
使用Obsidian + GBrain + 三层轻量记忆系统构建了AI Agent的协作架构：
- Obsidian作为知识沉淀库，所有重要的决策、经验、方法论都以双链笔记的形式持久化存储
- GBrain作为知识检索层，让AI在需要时能快速召回历史积累
- 三层轻量记忆作为事件追踪层，确保每个任务的进度、状态、阻塞点都有记录可查
这个架构的核心理念是：知识归知识，事件归事件。GBrain负责"学过什么"，轻量记忆负责"做过什么"。
第一部分：GBrain在我们的架构中扮演什么角色
先介绍第一个主角：GBrain。
GBrain（GitHub 17.2K Stars）是YC CEO Garry Tan维护的一套个人知识大脑操作系统。它的定位很有意思——不是简单地做知识存储，而是试图让AI拥有"连贯的思考能力"。
GBrain包含43个技能（Skills），覆盖：
- 知识存储与检索
- 任务规划与追踪
- 自我反思与改进
- 跨会话记忆传递
GBrain在我们的架构中，解决的是"学过什么"的问题：
- 当AI需要调用某个方法论时，GBrain能快速检索到历史沉淀
- 当需要参考之前的经验时，GBrain能召回相关知识卡片
- 当团队成员积累了新的经验，GBrain能确保这些知识不被遗忘
部署完GBrain后，知识层面的问题确实得到了很好的解决。
第二部分：三层轻量记忆系统——解决事件丢失问题
然而，仅仅有GBrain还不够。
如果问AI"昨天那个客户的方案改到第几版了"，GBrain无法回答，因为它只负责知识，不负责事件。
这就是三层轻量记忆系统存在的意义：解决"做过什么、进展到哪一步"的问题。
第一层：会话原文记录
所有会话的原始JSONL日志完整保留，不做任何压缩。
这是最底层的原始数据，包含完整的上下文信息。任何时候需要恢复历史会话，都可以从这里找回。
第二层：每日摘要
每天的会话结束后，自动生成MEMORY.md格式的摘要，包含：
- 今日完成：核心产出是什么
- 明日计划：下一步行动是什么
- 待决策项：需要人拍板的事情
这一层是对原文的结构化提炼，但仍然保留关键细节，不是压缩。
第三层：结构化沉淀
将重要决策、经验、方法论从MEMORY.md提取到Obsidian双链笔记中。
这是知识的最终归宿，与GBrain形成联动——GBrain负责检索，Obsidian负责沉淀。
三层之间的关系
| 层级 | 内容 | 定位 |
|---|---|---|
| 第一层 | 会话原文JSONL | 完整保留，不压缩 |
| 第二层 | MEMORY.md每日摘要 | 结构化提炼，保留关键细节 |
| 第三层 | Obsidian双链笔记 | 知识结构化沉淀 |
重要原则：不压缩原文
这里要特别说明一点：与某些记忆系统采用"压缩"策略不同，坚持不压缩原文的原则。
压缩虽然能节省token，但会导致严重失忆——关键细节在压缩过程中被丢弃，需要召回时发现信息已经不完整。
三层结构的设计，正是为了在"保留完整性"和"快速检索"之间找到平衡。
第三部分：腾讯TencentDB Agent Memory的创新与启示
在研究过程中，腾讯开源的TencentDB-Agent-Memory（3.3K Stars）进入了视野。
腾讯的这套系统在架构设计上有一个核心洞察：AI Agent的记忆需要分层处理，不同层级的信息应该用不同的方式压缩和检索。
腾讯的四个创新
创新1：Mermaid符号压缩
传统记忆系统直接存储自然语言，导致token消耗巨大。腾讯的做法是用Mermaid符号做结构化压缩——用箭头、节点、状态图来表示事件关系，而不是长篇叙述。
效果：Token节省最高达61.38%。
创新2：四层递进蒸馏
记忆不是一次性写入，而是经过四层处理：
- 原始记录层 → 完整保留所有原始信息
- 语义压缩层 → 提取核心语义，删除冗余
- 结构化层 → 用Mermaid等符号表示关系
- 索引层 → 建立检索索引，支持快速召回
创新3：node_id追溯机制
每个事件节点都有唯一ID，支持精确追溯。
好处是：当需要恢复某个任务的上下文时，不需要读取全部历史，只要沿着node_id链条回溯即可。
成功率因此提升了51.52%。
创新4：Hybrid混合检索
结合向量检索和关键词检索，在精确召回和语义理解之间找到平衡。
腾讯系统的测试数据：
| 指标 | 提升幅度 |
|---|---|
| Token节省 | 最高61.38% |
| 任务成功率 | 提升51.52% |
| Persona层准确率 | 48% → 76% |
但最终没有直接照搬腾讯系统。
为什么没有照搬腾讯系统
问题1：学习成本高
四层蒸馏+Mermaid符号化+混合检索，整套系统需要2-3周时间深度学习才能上手。
问题2：与GBrain功能重叠
GBrain已经有知识存储和检索的能力。腾讯系统强调的也是记忆的压缩和检索。两者叠加会导致信息冗余。
问题3：压缩策略不符合需求
腾讯的Mermaid压缩虽然能节省token，但压缩会导致失忆。不压缩原文是底线。
借鉴思想，不搬架构。
第四部分：借鉴腾讯思路，我们做了哪些优化
基于腾讯的思路，设计了一套轻量化方案，分两个Phase推进。
腾讯给的三点核心启示
启示1：记忆需要分层，不同层用不同方式处理
腾讯的四层架构验证了分层思想的正确性。落实到自己的系统，就是三层结构：原文→摘要→沉淀。
启示2：事件需要精确追溯，不能只靠语义检索
node_id机制让召回有路径可循，而不是让AI去"猜"。
启示3：分层是为了更好的召回，不是为了省token
分层的目的是让关键信息更容易被定位，而不是一味压缩。腾讯的方法论是正确的，但执行方式需要调整。
Phase 1：基础层（已完成）
① 追溯锚点机制（借鉴node_id）
每个任务分配唯一ID，所有相关讨论都标注这个ID：
任务 #2026-0518-001：天猫618大促方案
状态：🟡进行中
负责人：沈国章
下一步：等设计稿确认这样无论何时召回，都能快速定位任务上下文。
② 每日memory分层模板
不再是流水账式日志，而是分三层记录：
## 今日完成
- 核心产出是什么
## 明日计划
- 下一步行动是什么
## 待决策项
- 需要人拍板的事情简单清晰，5分钟写完，不增加负担。
③ 任务状态图
用简单的方式标注每个任务的当前状态：
- 🟢 正常推进
- 🟡 需要关注
- 🔴 遇到阻塞
- ✅ 已完成
一眼看清全局。
Phase 2：自动化层（规划中）
① brain-ops自动更新
当任务状态变化时，brain-ops技能自动更新MEMORY.md，不需要人工维护。
② signal-detector决策捕获
关键决策发生时，signal-detector自动捕获并写入记忆。
Phase 1上线后的效果：
| 改进前 | 改进后 |
|---|---|
| 任务进度靠口头同步 | 随时可查，有记录 |
| 跨session信息丢失 | 原文+摘要双保险 |
| 状态不透明 | 颜色标注一眼可见 |
| 记忆碎片化 | 统一沉淀到MEMORY.md |
虽然不像腾讯系统那样有61%的Token节省，但执行成本几乎为零，团队愿意用才是真的有效。
核心感悟
1. AI记忆的本质是"让机器记住该记住的"
不是存储越多越好，而是提取最关键的、在需要时能快速召回的。信息爆炸年代，遗忘比记忆更重要。
2. 工具不是万能的，执行意愿比工具更重要
再好的记忆系统，如果团队不愿意花时间维护，等于零。刻意降低维护成本——宁可少记一点，也要记牢一点。
3. 适合的才是最好的
腾讯的系统是为大规模AI应用设计的，复杂但强大。需要轻量、快速、上手即用。借鉴思路，不抄架构，这才是正确的开源学习姿势。
参考资料
- GBrain: https://github.com/garrytan/gbrain (17.2K Stars, 43 Skills)
- TencentDB-Agent-Memory: https://github.com/Tencent/TencentDB-Agent-Memory (3.3K Stars)
- 本文实践：MEMORY.md三层记忆 + self-improving heartbeat
如果你也在探索AI Agent的记忆系统，欢迎交流。记住，有时候少即是多。