从 LLM Wiki 到 GBrain：我对 Agent 长期记忆的一些新理解

最新推荐文章于 2026-06-17 22:07:45 发布

原创最新推荐文章于 2026-06-17 22:07:45 发布 · 900 阅读

10 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#人工智能 #架构 #后端

在这里插入图片描述

最近看了几篇关于 Agent Memory、LLM Wiki、Obsidian-Wiki 和 GBrain 的文章，发现自己之前对 Agent 长期记忆的理解还是偏窄了。

以前我更容易把 Memory 理解成两类东西：一类是聊天记录，也就是把历史对话保存下来；另一类是 RAG，也就是把外部文档切成 chunk，查询时再检索出来塞给模型。

这两个理解当然不能说错，但它们好像都只解释了一部分问题。

如果一个 Agent 只是保存了很多聊天记录，它未必真的知道哪些内容重要、哪些已经过期、哪些经验下次还能复用。如果一个 Agent 只是接了一个向量数据库，它也未必真的把知识沉淀了下来，很多时候仍然是每次提问都重新检索、重新拼接、重新推理。

这也是我最近重新理解 Agent Memory 的一个切入点：长期记忆不只是“存东西”，更重要的是把过去的信息整理成下次还能用的状态。

1. 为什么最近大家又开始关注 Agent Memory

Agent 这两年的变化很快。

早期我们聊 Agent，经常会围绕几个关键词：Prompt、Tool Use、Function Calling、Planning、RAG。后来随着 Claude Code、Codex、OpenClaw、Hermes Agent 这类工具和框架出现，大家又开始讨论更长程的任务执行、更复杂的工作流、更稳定的运行环境，以及 Agent 如何在真实项目里持续工作。

这时候 Memory 的重要性就变得更明显了。

因为 Agent 一旦从“回答问题”变成“持续做事”，它就会遇到几个很现实的问题：

这个用户之前有什么偏好？
这个项目里有哪些约定？
上次任务失败在哪里？
哪些知识已经被验证过？
哪些文档已经过期？
哪些流程下次可以直接复用？

这些问题都不是单次问答能解决的。

比如写代码时，Agent 可能这次知道你喜欢先写测试、再改实现；但换一个会话后，它又忘了。再比如一个项目里已经踩过某个接口兼容问题，如果这个经验没有沉淀下来，下次遇到类似问题还会重新排查一遍。

这就是长期记忆的价值：它让 Agent 不只是“当下会推理”，还要能“把做过的事变成经验”。

在这里插入图片描述

2. Agent 的 Memory 到底在解决什么问题

如果简单说，Agent Memory 解决的是“信息如何跨任务、跨会话、跨时间复用”的问题。

我现在更倾向于把它拆成四类来看。

2.1 短期记忆

短期记忆主要对应当前上下文，比如当前用户的问题、前几轮对话、正在执行的任务、临时约束、已经调用过的工具结果。这部分信息通常会直接进入模型上下文窗口，也最容易受到 token 数量的限制。

2.2 工作记忆

工作记忆更像任务执行过程中的临时状态，比如当前计划做到第几步、哪些文件已经检查过、哪些测试已经跑过、哪些假设还没验证。它不一定需要长期保存，但在一个任务周期内很重要。

2.3 事件记忆

事件记忆记录过去发生过什么，比如某次排障过程、一次代码改动、一次用户反馈、一次失败案例。这类记忆的价值在于复盘和复用，它不一定是通用知识，但对某个用户、某个项目、某个团队很有意义。

2.4 语义记忆

语义记忆更接近知识库，比如某个概念的解释、某个系统的架构、某个业务领域的规则、某个开源项目的用法。RAG、Wiki、文档库、知识图谱，很多都可以归到这一类。

2.5 程序性记忆

还有一种容易被忽略的记忆，我觉得可以叫程序性记忆。它不是“知道什么”，而是“知道怎么做”。比如一个代码审查流程、一个排障 checklist、一个写作流程、一个数据分析步骤。现在很多 Agent Skill，本质上就在沉淀这种程序性记忆。

Agent Memory
├── 短期记忆：当前上下文和近期对话
├── 工作记忆：当前任务执行状态
├── 事件记忆：历史经历、反馈、偏好、失败案例
├── 语义记忆：概念、文档、领域知识
└── 程序性记忆：流程、Skill、检查清单、操作习惯

这样看 Memory，会比“保存聊天记录”更接近真实的 Agent 系统。

3. 传统 RAG 为什么还不够像“长期记忆”

RAG 很重要，但它和长期记忆不是一回事。

RAG 的典型流程是：先把资料切分、向量化、建立索引；用户提问时，根据问题检索相关 chunk；再把检索结果放进上下文，让模型生成答案。

这个流程很适合处理海量文档，也很适合做问答系统。但如果从“长期记忆”的角度看，它还有一些天然限制。

第一个限制是，每次查询都像重新查资料。

即使上一次已经综合过几篇文档，下一次遇到类似问题时，系统仍然可能重新检索、重新拼接、重新推理。中间产生的理解、对比、判断，如果没有被写回到某个稳定的知识层，就很难形成积累。

第二个限制是，chunk 不等于知识结构。

向量检索擅长找“相关片段”，但片段之间的关系、概念之间的层级、旧结论和新资料之间的冲突，通常不会自动整理好。模型每次都要在上下文里临时拼装这些关系。

第三个限制是，RAG 更偏“查询时增强”，Memory 更偏“持续状态维护”。

方式	主要动作	优点	典型问题
RAG	查询时检索资料	适合海量文档，接入相对成熟	每次都重新找，知识不一定沉淀
聊天记录	保存历史对话	实现简单，保留上下文痕迹	噪音多，缺少结构化整理
Wiki Memory	把知识整理成页面	可读、可追溯、容易修改	需要维护索引、链接和一致性
GBrain 类系统	文件、检索、图谱组合	更适合复杂长期记忆	工程复杂度更高

所以我现在会把 RAG 看成 Memory 的一部分能力，而不是 Memory 本身。

4. LLM Wiki 的启发：让模型维护一套会生长的 Markdown 知识库

LLM Wiki 给我的最大启发，是它把知识管理从“查询时检索”往前推了一步。

它不是等用户提问时再从原始资料里找片段，而是让 LLM 在资料进入系统时，就把它整理成一套长期可读、可更新、可互相链接的 Markdown Wiki。

这个思路很像把知识先“编译”一遍。

原始文章、PDF、会议记录、笔记，都是输入材料。LLM 读取这些材料后，不只是把它们存起来，而是提取要点、更新相关主题页面、补充交叉引用、记录矛盾和变化。下次再问问题时，Agent 先读整理后的 Wiki，而不是每次都从原始资料重新开始。

层次	作用	类比
Raw Sources	保存原始资料，尽量不改动	原始输入和证据
Wiki Pages	LLM 维护的结构化知识页	经过整理的知识层
Schema / Instructions	告诉 Agent 如何命名、整理、更新、引用	知识库的维护规范

这个设计有几个很有意思的点。

首先，它保留了人类可读性。Markdown 文件可以直接打开、审查、修改，也可以放进 Git 做版本管理。相比完全黑盒的向量库，这种方式更透明。

其次，它强调知识之间的连接。一篇新资料可能不只生成一篇摘要，还会影响已有的概念页、人物页、项目页、对比页。也就是说，知识不是孤立堆放，而是在进入系统时就被放到已有结构里。

最后，它把“维护”也变成了 Agent 的任务。传统知识库最大的问题往往不是创建，而是维护。页面过时、链接断掉、重复内容越来越多、不同页面说法不一致，这些都很常见。LLM Wiki 里的 lint 思路，就是让 Agent 定期检查这些问题。

在这里插入图片描述

5. Obsidian-Wiki 的启发：知识库也需要工程化维护

如果说 LLM Wiki 更像一个思想原型，那么 Obsidian-Wiki 让我看到的是：这件事要真正用起来，还需要不少工程化细节。

因为只靠“让模型整理 Markdown”，很容易遇到几个问题：

哪些资料是新增的？
哪些资料被修改过？
同一份资料是否已经处理过？
哪些内容是原文提取，哪些是模型推断？
哪些信息涉及隐私，不应该进入公开知识库？
页面之间的链接是否足够完整？

这些问题如果不处理，长期记忆很容易从“知识沉淀”变成“知识堆积”。

这里面我觉得最值得借鉴的是四点：增量追踪、来源标记、交叉链接、隐私过滤。

长期记忆不是“记得越多越好”，而是要记得清楚、记得有边界、记得能更新。

6. GBrain 的启发：长期记忆可能需要“文件 + 检索 + 图谱”

GBrain 给我的启发更偏工程化。

如果知识量比较小，Markdown + index + grep 可能已经够用。但当资料越来越多，页面越来越多，单纯靠目录和全文搜索就会变得吃力。

这时候 GBrain 这类系统会走向一种组合架构：文件系统保存知识本体，搜索系统负责快速定位，图谱关系负责表达连接，LLM 负责理解和综合。

文件系统适合保存可读、可审查、可版本化的知识。

关键词和向量检索适合在大量资料里快速筛选候选内容。

图谱适合表达实体之间的关系，比如人、公司、项目、概念、事件之间的连接。

LLM 适合做阅读、解释、归纳、综合、判断。

代码适合做确定性维护，比如更新反向链接、检查引用格式、计算 hash、同步索引、执行图查询。

能力	更适合谁来做	原因
判断资料是否相关	LLM	需要语义理解
生成摘要和综合观点	LLM	需要归纳和表达
计算文件是否变化	代码	确定性强
更新反向链接	代码	规则明确
找候选页面	搜索系统	速度快
维护关系网络	图谱/数据库	适合结构化查询

我比较喜欢这种思路：不要让 LLM 做所有事情，也不要把所有知识都交给检索系统。长期记忆更像一个组合系统，每一层都做自己擅长的事情。

在这里插入图片描述

7. 如果自己做一个轻量版 Agent Memory，可以先从什么开始

如果只是个人学习或者个人工作流，我觉得不一定一开始就要上复杂系统。

一个很轻量的版本，可以先从 Markdown 目录开始：

memory/
  index.md          # 知识目录，告诉 Agent 有哪些页面
  log.md            # 记忆更新时间线
  profile.md        # 用户偏好和长期约定
  projects/         # 项目知识、架构、决策记录
  concepts/         # 概念笔记和学习资料
  incidents/        # 排障、失败案例、复盘
  skills/           # 可复用流程、检查清单、操作经验

再配几条简单规则：

第一，任务结束后不要保存完整聊天，而是保存“可复用结论”。

第二，区分事实、推断和偏好。

第三，给记忆加时间，避免过期知识被误用。

第四，定期 lint，检查过期、重复、冲突和孤立页面。

第五，不要一开始追求全自动。尤其是涉及项目决策、业务规则和个人隐私时，人最好仍然在环。

在这里插入图片描述