Agent 架构
Agent 记忆架构
Agent 的记忆架构，最好不要只按“存在哪里”来设计，而要同时考虑 记忆类型、存储层、写入机制、检索机制、更新/遗忘机制。
Agent 的记忆架构，最好不要只按“存在哪里”来设计，而要同时考虑 记忆类型、存储层、写入机制、检索机制、更新/遗忘机制。
一个比较完整的 Agent Memory Architecture 可以设计成下面这样：
┌───────────────────────┐
│ Agent Loop │
│ 感知→思考→行动→反馈 │
└──────────┬────────────┘
│
┌──────────▼───────────┐
│ Memory Manager │
│ 记忆管理器 │
└──────────┬───────────┘
│
┌──────────────────────────┼──────────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 工作记忆 │ │ 情景记忆 │ │ 语义记忆 │
│ Working Memory │ │ Episodic Memory │ │ Semantic Memory │
├─────────────────┤ ├─────────────────┤ ├─────────────────┤
│ 当前对话 │ │ 历史对话 │ │ 用户偏好 │
│ 当前任务 │ │ 历史任务 │ │ 人物关系 │
│ Tool Result │ │ Agent执行记录 │ │ 已知事实 │
│ 当前计划 │ │ 成功/失败案例 │ │ 实体/关系 │
└────────┬────────┘ └────────┬────────┘ └────────┬────────┘
│ │ │
▼ ▼ ▼
Context Window Vector / SQL Graph / SQL
短期存储 原始长期记忆 抽象长期记忆
│
▼
┌─────────────────────┐
│ Procedural Memory │
│ 程序记忆 │
├─────────────────────┤
│ Skills │
│ SOP │
│ Workflow │
│ Tool使用经验 │
│ 问题解决策略 │
└─────────────────────┘其中最关键的一点是：
记忆架构 ≠ Context + Vector DB + Graph DB。
这只是“存储架构”。真正的记忆系统核心其实是：
经历
↓
Memory Write
↓
记忆抽取
↓
记忆分类
↓
去重 / 合并 / 冲突处理
↓
持久化
↓
Memory Retrieval
↓
相关性排序
↓
注入 Context
↓
Agent 使用
↓
反馈
↓
更新 / 强化 / 遗忘1. 第一层：工作记忆 Working Memory
这是最短期的记忆，本质上就是 Agent 当前“脑子里正在想的东西”。
包括：
当前用户输入
当前对话
当前任务
当前计划
当前步骤
最近 Tool Result
临时变量
中间推理状态例如：
{
"goal": "帮用户设计RAG系统",
"current_step": "设计retrieval",
"constraints": [
"使用Milvus",
"需要hybrid search"
],
"tool_results": []
}主要放：
Context Window
Agent State
LangGraph State
Redis它的特点是：
生命周期：分钟 ~ 小时
容量：小
读取频率：极高
准确性：高2. 第二层：情景记忆 Episodic Memory
这是 Agent 的“经历”。
例如：
2026-08-20
用户问过 Milvus hybrid search
最终采用：
Dense + BM25 + RRF
2026-08-21
用户部署 Milvus 时出现：
DEADLINE_EXCEEDED
解决方法：
batch size 500 → 100
timeout 10s → 60s注意，这层不应该只是简单保存：
User: xxx
Assistant: xxx
User: xxx
Assistant: xxx更推荐保存成 Episode：
{
"time": "2026-08-21",
"topic": "Milvus写入失败",
"context": "...",
"problem": "DEADLINE_EXCEEDED",
"actions": [
"降低batch size",
"增加timeout"
],
"result": "success"
}也就是说：
Conversation 是原始日志，Episode 才是真正有价值的情景记忆。
存储可以用：
PostgreSQL
+
Vector DBVector DB 主要解决：
“有没有发生过类似事情？”
例如现在出现：
Milvus insert timeout就能召回以前：
Milvus DEADLINE_EXCEEDED3. 第三层：语义记忆 Semantic Memory
这是非常重要的一层。
Agent 不应该每次都检索几十次历史对话来知道：
用户使用 Python
用户正在学习 Agent
用户项目用了 Milvus
用户喜欢紧凑的技术笔记这些应该从 Episode 中不断抽取成 Semantic Memory：
Episode
↓
Memory Extraction
↓
Fact例如：
用户项目使用 Milvus
用户偏好 Python
用户正在开发 RAG 项目可以建成：
Entity:
User
Relation:
User --uses--> Milvus
User --learning--> Agent
User --developing--> RAG Project所以：
Conversation
↓
Episode
↓
Semantic Memory其实是一种逐级压缩：
100000 Token 原始对话
↓
100 个 Episode
↓
20 个稳定事实这才是长期记忆真正应该做的事情。
4. 第四层：程序记忆 Procedural Memory
这个经常被 Agent Memory 设计忽略。
它不是：
“我知道什么？”
而是：
“我知道怎么做。”
比如 Agent 曾经完成过很多次：
部署 FastAPI
分析 Bug
创建 RAG Pipeline
写技术方案逐渐可以形成：
Skill
SOP
Workflow
Playbook例如：
Skill: diagnose_milvus_timeout
1. 检查网络
2. 检查batch size
3. 检查grpc timeout
4. 检查Milvus日志
5. 尝试小批量insert下一次就不需要重新规划。
这也是为什么未来 Agent Memory 很可能和：
Memory
+
Skill逐渐融合。
一个比较推荐的完整架构
可以拆成 6 层：
┌──────────────────────────────────────┐
│ Agent │
│ LLM / Planner / Tools / Reflection │
└──────────────────┬───────────────────┘
│
▼
┌──────────────────────────────────────┐
│ ① Working Memory │
│ Context / State / Scratchpad │
└──────────────────┬───────────────────┘
│
▼
┌──────────────────────────────────────┐
│ ② Conversation Log │
│ 完整原始事件流 │
│ PostgreSQL / Object Storage │
└──────────────────┬───────────────────┘
│
Memory Pipeline
│
┌───────────┼───────────┐
▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│③ Episodic │ │④ Semantic │ │⑤Procedural│
│ 情景记忆 │ │ 语义记忆 │ │ 程序记忆 │
│ │ │ │ │ │
│ 做过什么 │ │ 知道什么 │ │ 怎么做 │
└─────┬──────┘ └─────┬──────┘ └─────┬──────┘
│ │ │
Vector DB Graph/SQL Skill Store
│ │ │
└──────────────┼──────────────┘
▼
┌──────────────────────┐
│ ⑥ Memory Retrieval │
│ 检索 / 排序 / 融合 │
└───────────┬──────────┘
▼
Context Injection但是到这里仍然不够。
真正决定这个 Memory System 好不好用的是 Memory Manager。
Memory Manager 才是核心
Memory Manager 至少负责 7 件事情：
1. Memory Write
2. Memory Extraction
3. Memory Consolidation
4. Memory Retrieval
5. Memory Ranking
6. Memory Update
7. Memory Forgetting例如一段对话：
用户：
我的 RAG 项目以后统一用 Milvus，
不要再推荐 Pinecone。Memory Manager 可以抽取：
{
"subject": "user",
"predicate": "preferred_vector_database",
"object": "Milvus",
"confidence": 0.98,
"importance": 0.9,
"source": "conversation_xxx",
"created_at": "...",
"last_accessed": "..."
}如果以前有：
user --preferred_vector_database--> Pinecone就不能简单新增一条：
user → Pinecone
user → Milvus否则记忆冲突。
需要做：
旧记忆：
Pinecone
confidence ↓
status = superseded
新记忆：
Milvus
status = active所以成熟的 Memory 其实还需要：
Version
Confidence
Importance
Timestamp
Source
Access Count
Decay
Superseded By记忆检索也不能只是 Vector Search
这是另一个常见误区。
实际应该是：
Query
│
┌──────────┼───────────┐
▼ ▼ ▼
Semantic Keyword Graph
Retrieval Retrieval Traversal
│ │ │
└──────────┼───────────┘
▼
Candidate
│
▼
Reranking
│
┌────────┼─────────┐
│ │ │
relevance importance recency
│ │ │
└────────┼─────────┘
▼
Top Memories
│
▼
Context例如最终评分：
Memory Score =
0.4 × Semantic Similarity
+ 0.2 × Importance
+ 0.15 × Recency
+ 0.15 × Confidence
+ 0.1 × Access Frequency具体权重当然可以调整。
还有一个非常重要的机制：记忆固化
可以借鉴人类：
短期记忆
↓
经历
↓
重复出现
↓
总结
↓
长期知识Agent 可以周期性做：
Memory Consolidation例如历史中出现：
Episode 1:
用户使用 Milvus
Episode 2:
用户 Milvus insert 报错
Episode 3:
用户询问 Milvus collection
Episode 4:
用户设计 Milvus hybrid searchAgent 可以固化：
Semantic Memory：
User Project
│
└── Vector DB → Milvus甚至进一步：
User
└── Project
└── RAG
├── Vector DB → Milvus
├── Retrieval → Hybrid Search
└── Sparse → BM25这时 Graph Memory 的价值才真正体现出来。
最后我会把 Agent Memory 总结成一个公式
Agent Memory
=
Working Memory
+
Episodic Memory
+
Semantic Memory
+
Procedural Memory
+
Memory Lifecycle其中：
Working
= 当前正在发生什么
Episodic
= 过去发生过什么
Semantic
= 我知道什么
Procedural
= 我知道怎么做而：
Memory Lifecycle
=
Write
→ Extract
→ Consolidate
→ Retrieve
→ Rank
→ Inject
→ Update
→ Forget所以如果真正设计一个生产级 Agent，我不会采用简单的：
Context
→ Vector DB
→ Graph DB而会采用：
Memory System
┌──────────── Working ────────────┐
│ │
Agent ←─┼──── Memory Retrieval ←──────────┤
│ │
└──────────────┬──────────────────┘
│
Memory Manager
│
┌─────────────┼─────────────┐
│ │ │
Episodic Semantic Procedural
│ │ │
Vector Graph Skills
│ │ │
└─────────────┼─────────────┘
│
Raw History
│
Conversation Log这里面真正的核心其实不是 Vector DB 或 Graph DB，而是中间这一层 Memory Manager / Memory Pipeline。数据库只是记忆的载体，什么时候记、记什么、怎么抽象、什么时候召回、什么时候覆盖、什么时候遗忘，才决定 Agent 是否真正具有“记忆”。