第十三章 Memory：从 RAG 到 AI Brain，Agent 如何拥有长期认知能力
目录
零基础认识大语言模型（LLM）工作原理目录 - GuZhenYin - 博客园
本章导读
上一章我们介绍了 Workflow。
我们知道了
MCP 解决了 Agent 如何连接外部能力
Workflow 解决了 Agent 如何组织复杂流程
但是，一个真正长期工作的 AI 助手，还缺少一个非常重要的能力：它必须能够积累经验。
想象一下：
如果一个程序员助手每天早上启动后，都忘记昨天看过的代码。
如果一个企业 AI 每次面对客户问题，都不知道过去的处理记录。
如果一个销售 Agent 不知道过去和客户沟通过什么。
那么它只能永远像一个"刚入职第一天的新员工"。
因此：没有 Memory 的 Agent，只是一个会思考但没有经历的 Agent。
13.1 LLM 为什么天生没有记忆？
这里我们首先需要纠正一个常见误解
很多人认为ChatGPT 为什么知道我之前说的话？
是不是因为模型已经学习了我的聊天内容？
其实并不是
我们重新梳理一下模型的运行过程
大语言模型运行过程：
用户输入
↓
Tokenizer
↓
Transformer
↓
预测下一个 Token
↓
输出结果可以看出来,模型本身只拥有：参数记忆（Parametric Memory）
也就是说,它只拥有训练阶段学习到的知识。
比如：
模型知道：
HTTP 是网络协议
Python 是编程语言。
地球绕太阳运行。
因为这些知识存在在模型参数里面。
但是,你的个人信息,比如：
我的项目使用 ABP。
我的数据库是 MySQL。
我的代码规范是 DDD。
我的团队成员有哪些。
这些则不会自动进入模型参数。
因为模型不会也不可能,因为一次聊天重新训练。
所以,LLM 更像一本训练完成的百科全书。
而不是一个认识你的私人助手。
13.2 Agent 为什么必须拥有 Memory？
因为现实任务不是一次性的。
比如用户说:
帮我优化订单系统。
一个普通 LLM可能会回答：
可以考虑缓存、消息队列、数据库优化。
这就结束了。
但是一个真正 Agent(智能体),它应该知道：
这个项目去年已经改过一次。
订单系统使用 Spring Boot。
数据库是 MySQL。
之前出现过库存一致性问题。
团队倾向使用 Outbox Pattern。然后应该给出结合历史背景的方案。
区别就在于普通 LLM只能**根据通用知识回答。**
而Agent(智能体)则可以**根据世界知识 + 个人经验回答。**
这,其实就是 Memory 的价值。
13.3 AI Memory 并不是"记住聊天记录"
很多人认为,Memory 其实等于保存聊天记录。
简单这么理解,倒是没问题,但是实际上这是非常低级和早期的实现。
比如保存下面这些信息,
用户：
你好。
AI：
你好。
用户：
今天怎么样？这些信息价值非常低,完全没有实际意义。
而真正有价值的信息,应该是从大量人与AI的交互中提炼出来的：
用户偏好
项目背景
业务规则
历史决策
经验总结
重要事实所以Memory 的目标并不是全部的保存过去。
而是提取过去有价值的信息，帮助未来决策。
13.4 Agent Memory 的三层结构
现代 Agent 系统通常可以分成三层。(当然,每个Agent 可能实现方式都有所不同)
第一层：Session Context（会话上下文）
这是最基础的记忆。
比如,当前聊天：
用户：
帮我修改登录接口。
AI：
好的。
用户：
增加 OAuth 支持。 这时候,AI 知道："增加 OAuth"指刚才那个登录接口。
原因是历史消息仍然在 Context(对话上下文)中。
但是,它存在明显限制。
因为Context 窗口有大小限制。
几十万 Token 甚至发展到现在百万级Token的上下文, 它始终也不是无限的。
所以这个时候,我们就需要第二层了。
第二层：Agent Memory（智能体记忆）
它负责保存Agent 工作过程中经常使用的信息。
比如,用户偏好：
喜欢 C#
喜欢 Markdown 文档
喜欢代码带注释当前任务的运行状态：
当前任务进行到第三步
已经调用 Git 工具这些都属于Agent 自己的运行记忆。
第三层：Brain（长期知识大脑）
这是未来 Agent 最重要的发展方向。(2026年新方向)
它负责则整理和保存知识图谱：
人物关系
企业信息
项目历史
业务知识
技术方案
会议记录
经验总结它不是简单存储。
而是形成一个持续成长的知识体系。
三者的关系我们可以简单归纳成下面这样：
Brain 个人长期知识图谱
↑
Agent Memory 工作状态和个人偏好
↑
Session Context 当前对话13.5 Vector Database(向量数据库)：传统搜索为什么不够？
既然我们需要保存Agent Memory(记忆),那么我们自然就碰到几个问题,如何本地存储?如何检索?
假设我们的知识库中有下面这些信息：
MySQL连接池异常分析
Redis锁设计方案
RabbitMQ消费优化
库存同步方案但是用户提问：
为什么数据库空闲后第一次访问很慢？这里面的关键词没有"连接池"。
但是语义接近：MySQL连接池异常分析
我们如果用传统的数据库+ SQL,只能写类似下面的语句：
where content like '%连接池%'那大概率就找不到相关信息了.
向量数据库,则支持向量检索,它寻找的是**距离最近的语义向量**
那么我们就能找到相关信息了。
其实这就是之前我们提到过的 RAG基础检索。
但是RAG也有自己的局限性.
13.6 RAG 的局限：它只是搜索，不是真正理解
假定我们的知识中存在：
张三负责 SPD 项目。
SPD 项目采用 Outbox。
Outbox 用于解决消息一致性。人类马上可以理解：
这些信息的关系：
张三
↓
SPD
↓
Outbox
↓
消息一致性但是普通 Vector Search(向量检索)：
只是找到几个相关文本。
它并不知道实体之间关系。
这就是Knowledge Graph（知识图谱）出现的原因。
13.7 Knowledge Graph：让 AI 理解关系
知识图谱的核心结构主要就是：实体``+``关系``+``属性
比如：
张三 --负责--> SPD系统
SPD系统 --采用--> Outbox Pattern
Outbox Pattern --解决--> 消息一致性这就构成了一个完整的知识图谱,比单纯文本更接近人类认知方式。
13.8 从 Memory 到 Brain：GBrain 的启发
GBrain是由 garrytan 最近的开源个人知识管理系统.
其实到这时候，我们可以理解 GBrain 代表的方向。
GBrain 的定位不是简单"聊天记录存储"。
而是为 Agent 构建一个长期知识大脑。
它强调：
- 知识沉淀；
- 实体关系；
- 混合检索；
- 信息综合；
- 持续维护。
GBrain 项目作者将其定位为 Agent 的 Brain Layer，用于连接 OpenClaw、Hermes 等 Agent，并通过知识页面、关系连接、混合检索等方式形成长期知识体系。
传统 RAG：
问题
↓
搜索几个文本片段
↓
回答更像搜索引擎。
Brain则是：
信息输入
↓
知识整理
↓
实体关联
↓
持续更新
↓
综合推理就更像人的长期记忆。
13.9 GBrain 的核心思想：知识不是存储，而是演化
传统RAG知识库：
上传文档
↓
建立索引
↓
查询问题就在于知识,它不会成长。
Brain则是：
获取信息
↓
分析
↓
建立关系
↓
发现冲突
↓
更新认知比如,
一月份:医院 A 使用 SPD 版本 V2
二月份:医院 A 升级 V3
Brain 则应该知道：
旧信息已经变化。
而不是两个答案同时存在。
这也是AI Agent 与普通搜索系统最大的区别。
13.10 企业 Agent 的未来架构
到这里,我们可以大胆猜测一下.未来的企业 AI的记忆体：
它不会只是**LLM``+``RAG**
而是会演变成：
Agent
|
Brain Layer
---------------------
文档
项目
人员
业务规则
历史决策
---------------------
Knowledge Graph
|
Vector + Search比如医院 SPD Agent：
用户：
为什么这个医院今天同步失败？它应该知道：
医院
↓
SPD版本
↓
接口变化
↓
历史Bug
↓
解决方案
↓
负责人最终给出的不是"搜索结果"。
而是一个结合历史经验的判断。
13.11 对未来 Agent 的大胆预测
我们可以大胆预测一下,未来 AI 的竞争不会只是谁的模型参数更多。
因为世界知识有限,各个模型其实基本都快吃透(训练)了,模型的能力只会越来越接近。
真正产生差异的其实是,Agent 是否拥有属于自己的 Brain(大脑)。
同一个 GPT、Claude、Qwen,连接或者使用不同 Brain。
表现其实可能就会完全不同。
本章总结
这一章，我们重新理解了 AI Memory。
我们明确了以下核心观点：
1.LLM 本身没有长期记忆。它只有训练得到的参数知识。
2.Agent Memory 不是保存聊天记录。而是管理有价值的信息。
3.RAG 解决："找到相关资料"。
4.Knowledge Graph 解决："理解信息关系"。
5.AI Brain 解决："让 Agent 持续积累认知"。
最后用一句话总结：LLM 负责推理，Tool 负责行动，Workflow 负责流程，而 Brain 负责让 AI 拥有过去。