Agent Memory:长期记忆实现原理,一文讲透 AI 为什么能够“越用越聪明“

大家好,我是 展菲,目前在上市企业从事人工智能项目研发管理工作,平时热衷于分享各种编程领域的软硬技能知识以及前沿技术,包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。
图书作者:《ESP32-C3 物联网工程开发实战》
图书作者:《SwiftUI 入门,进阶与实战》
超级个体:COC上海社区主理人
特约讲师:大学讲师,谷歌亚马逊分享嘉宾
科技博主:华为HDE/HDG
我的博客内容涵盖广泛,主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告,同时也会提供产品优缺点分析、横向对比,并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。
展菲:您的前沿技术领航员
👋 大家好,我是展菲!
📱 全网搜索“展菲”,即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文,从新兴框架的剖析到运维实战的复盘,助您技术进阶之路畅通无阻。
文章目录
-
- 引言
- 一、为什么 LLM 没有真正的记忆?
- 二、Memory 到底是什么?
- 三、企业级 Memory 的整体架构
- 四、第一层:Working Memory
- 五、第二层:Session Memory
- 六、第三层:Episodic Memory
- 七、第四层:Semantic Memory
- 八、第五层:Procedural Memory
- 九、Memory Manager 如何组织所有记忆?
- 十、Memory Retrieval:记忆如何被找回来?
- 十一、Memory Consolidation:为什么 Agent 会"越来越聪明"?
- 十二、Memory Forgetting:为什么 AI 也需要"遗忘"?
- 十三、鸿蒙 App 如何设计 Memory Center?
- 十四、企业级 Memory Center 还需要哪些能力?
- 十五、Agent Memory 的终极架构
- 总结
引言
如果你一直在关注 AI Agent,你会发现一个非常有意思的现象。
传统 ChatBot 基本都是这样的:
用户:
你好。
AI:
你好,请问有什么可以帮助你?
关闭窗口之后:
再次打开
↓
一切重新开始。
而越来越多的 Agent 却开始表现出另一种能力:
记住你的习惯
记住你的工作
记住你的偏好
记住历史任务
甚至还能做到:
根据过去经验
主动调整未来策略。
于是很多人认为:
Agent 已经拥有了"长期记忆"。
事实上,事情远没有这么简单。
很多开发者一开始都会把 Memory 理解成:
聊天记录
+
向量数据库
但真正的企业级 Agent Memory,远远不是一个 Vector Database 就能解决的。
从 Runtime 的角度来看:
Memory 不是数据库,而是一套持续感知、持续组织、持续检索、持续演化的记忆系统(Memory System)。
它不仅决定:
AI 记住什么?
更决定:
什么时候记?
什么时候忘?
什么时候重新学习?
今天,我们就从系统架构角度,彻底讲透 Agent 长期记忆的实现原理。
一、为什么 LLM 没有真正的记忆?
很多人第一次使用大模型都会觉得:
它什么都知道。
实际上模型知道的是:
训练知识。
而不是:
与你发生过什么。
例如,第一次聊天:
我喜欢 HarmonyOS 开发。
第二天重新打开:
推荐一些学习路线。
模型:
不知道你昨天说过什么。
因为,LLM 的工作方式始终都是:
Prompt
↓
Inference
↓
Response
推理结束之后:
Context
立即销毁。
因此:
LLM 天然没有长期记忆。
真正保存记忆的是 Runtime。
二、Memory 到底是什么?
一句话定义:
Memory 是 Runtime 对历史信息进行存储、组织、检索和更新的一套系统能力。
它不是:
聊天记录。
更不是:
数据库。
真正的 Memory 包括:
事实(Facts)
经验(Experience)
偏好(Preference)
任务(Task)
策略(Policy)
技能(Skill)
因此,Memory 更像:
人的大脑。
而不是:
聊天历史。
三、企业级 Memory 的整体架构
一个完整的 Agent Memory Center 通常包含七层:
Runtime
│
▼
Memory Manager
│
┌────────┬────────┬────────┬────────┐
▼ ▼ ▼ ▼
Working Session Episodic Semantic
Memory Memory Memory Memory
│
▼
Vector Index
│
▼
Storage Layer
Memory Manager 负责统一调度不同类型的记忆,而不是让所有数据都进入同一个存储。
四、第一层:Working Memory
这是 Agent 当前最重要的一块记忆,它保存:
当前任务
当前 Context
当前 Tool
当前状态
例如:
用户:
帮我生成 PPT。
Working Memory:
当前章节
当前模板
图片列表
生成进度
生命周期:
任务结束
立即释放。
类似于:
CPU Cache
速度最快,容量最小。
五、第二层:Session Memory
保存:
当前聊天
最近几轮上下文
Tool 调用结果
例如:
用户:
继续刚才那个方案。
Runtime 从 Session Memory 恢复:
刚才讨论内容。
生命周期:
一次会话。
六、第三层:Episodic Memory
这是很多 Agent Framework 容易忽略的一层,它保存的是:
发生过什么。
例如:
昨天:
帮用户生成了日报。
今天:
继续修改日报。
Memory 可以恢复:
昨天任务。
它记录的是:
时间
地点
任务
结果
而不是:
Embedding。
因此,它更适合:
任务恢复
Workflow
长期项目
七、第四层:Semantic Memory
这一层保存:
稳定知识。
例如:
用户:
主要开发 HarmonyOS。
喜欢 ArkTS。
长期使用 DevEco Studio。
Runtime 会抽象成:
{
"skill":"HarmonyOS",
"language":"ArkTS",
"IDE":"DevEco"
}
下一次无需再次询问。
八、第五层:Procedural Memory
这是未来 Agent 最重要的一类记忆,也是很多文章很少介绍的一层。
它记录的不是"知道什么",而是:
知道怎么做。
例如:
每周五
↓
自动生成周报
↓
发送团队
↓
同步知识库
Runtime 会将整个执行流程沉淀为一套可复用的操作模式,而不是简单保存聊天内容。
可以抽象成:
Trigger
↓
Workflow
↓
Action
↓
Verification
以后遇到相似任务时,无需重新规划直接复用。
这其实已经非常接近人类形成"技能"的过程。
九、Memory Manager 如何组织所有记忆?
很多团队会把所有数据全部写入向量数据库,这是非常低效的。
真正的 Memory Manager 会根据数据类型,自动分类:
Working Memory
↓
Session Memory
↓
Episodic Memory
↓
Semantic Memory
↓
Procedural Memory
不同 Memory 拥有不同:
生命周期
存储方式
检索方式
更新策略
统一由:
Memory Manager
负责调度。
十、Memory Retrieval:记忆如何被找回来?
Memory 最大的问题不是:
怎么存。
而是:
怎么找。
企业 Runtime 通常采用,多阶段 Recall。
Query
↓
Intent Analysis
↓
Memory Filter
↓
Hybrid Recall
↓
Ranking
↓
Context Builder
其中 Hybrid Recall,通常结合:
关键词检索(BM25)
+
Embedding 检索
+
Graph Recall
+
Metadata Filter
而不是,只做向量搜索。
最终只返回:
最相关 Memory。
十一、Memory Consolidation:为什么 Agent 会"越来越聪明"?
真正优秀的 Agent 不会保存所有内容。
而会不断:
总结
归纳
压缩
抽象
例如,连续十次:
用户:
喜欢深色主题。
Runtime 不会保存十条,而是生成:
{
"preference":"Dark Theme"
}
这就是:
Memory Consolidation
(记忆固化)
也是 Memory Center 最重要的一步。
十二、Memory Forgetting:为什么 AI 也需要"遗忘"?
很多人认为 Memory 越多越好。
实际上并不是,无限增长会导致:
Recall 变慢
Token 增长
推理成本增加
错误记忆污染
因此 Runtime 必须支持:
TTL(过期时间)
LRU(最近最少使用)
Priority(优先级)
Confidence(可信度)
Decay(记忆衰减)
例如:
临时验证码
↓
5 分钟后删除。
而:
长期职业信息。
永久保留。
Memory 真正需要的是:
会遗忘。
十三、鸿蒙 App 如何设计 Memory Center?
建议采用模块化架构:
src/
├── runtime/
│
├── memory/
│ ├── manager.ts
│ ├── working.ts
│ ├── session.ts
│ ├── episodic.ts
│ ├── semantic.ts
│ ├── procedural.ts
│ ├── recall.ts
│ ├── summarize.ts
│ ├── storage.ts
│
├── vector/
├── planner/
├── tools/
统一入口:
interface MemoryCenter {
store(memory: Memory): void
recall(query: Query): Memory[]
summarize(): void
forget(policy: ForgetPolicy): void
}
所有 Agent 都通过:
Memory Manager
访问记忆,而不是直接操作数据库。
十四、企业级 Memory Center 还需要哪些能力?
真正上线后的 Agent,还需要进一步增强 Memory 系统。
1、Memory Version
同一条用户偏好允许:
Version 1
↓
Version 2
↓
Version 3
支持历史追溯和回滚。
2、Memory Confidence
每条 Memory 增加:
Score
Source
Timestamp
避免错误信息长期影响决策。
3、Memory Graph
不同 Memory 不是孤立存在,而应该形成:
用户
↓
项目
↓
任务
↓
技能
↓
工具
构建关联关系,加快复杂推理和跨任务检索。
4、Memory Sync
在 HarmonyOS 全场景生态下,手机、平板、PC、车机等设备可以共享部分长期记忆。
Runtime 可以根据:
设备类型
用户身份
安全策略
动态同步不同层级的 Memory,实现真正的跨设备连续体验。
十五、Agent Memory 的终极架构
综合全文,一个企业级 Memory Runtime 可以设计为:
Runtime
│
▼
Memory Manager
│
┌──────────┬──────────┬──────────┬──────────┬──────────┐
▼ ▼ ▼ ▼ ▼
Working Session Episodic Semantic Procedural
Memory Memory Memory Memory Memory
└──────────────┬───────────────┘
▼
Hybrid Recall Engine
│
┌─────────────┼──────────────┐
▼ ▼ ▼
Keyword Recall Vector Recall Graph Recall
│
▼
Ranking & Filtering
│
▼
Context Builder
│
▼
LLM
整个 Memory 系统形成了:
存储(Store)
↓
组织(Organize)
↓
检索(Recall)
↓
总结(Consolidate)
↓
遗忘(Forget)
↓
再学习(Learn)
的完整闭环。
总结
很多人认为:
Agent Memory = 向量数据库。
实际上:
Vector Database
只是 Storage。
真正的 Agent Memory,是一套完整的 Runtime 能力。
它不仅负责:
记住什么。
更负责:
什么时候记?
什么时候找?
什么时候忘?
什么时候形成经验?
一句话总结全文:
Agent Memory 的核心不是"存数据",而是构建一个能够持续学习、持续演化、持续支撑决策的 Memory System。Working Memory、Session Memory、Episodic Memory、Semantic Memory 和 Procedural Memory 共同组成了企业级 Agent 的长期记忆体系,而 Memory Manager 则是连接 Runtime、Decision Engine 与 LLM 的关键枢纽。
这也是为什么越来越多企业开始将 Memory Center 视为 AI Agent 架构中与 Planner、Decision Engine、Tool Runtime 同等重要的核心基础设施。
更多推荐


所有评论(0)