Agent 分层存储架构设计：从痛点出发到完整方案

1️⃣ 关键痛点：为何 Agent 需要分层存储？

当 Agent 从单轮对话 到跨会话、长期学习、任务恢复与合规审计时以下痛点会立刻浮现：

• 当前任务进度如何精准追踪？
• 哪些工具调用结果必须保留在上下文中？其实，
• 使用者偏好和业务事实该如何跨会话复用？
• 旧事实被新事实覆盖时如何避免检索过期答案？
• 失败经验能否被提炼成可复用的记忆？
• 原始证据应如何留存以满足合规与复盘需求？
• 数据量激增后检索延迟、Token 成本与存储成本如何控制？

2️⃣ 正确思路：用分层管理 Agent 的上下文与状态，让数据按策略流动。

3️⃣ 主流设计方法概览

：最昂贵但最快的“寄存器”

特点：

• 延迟最低——已在推理输入中。
• 成本最高——每次推理都可能重复携带。
• 容量有限——信息越多不一定效果越好。话说回来，
• 适合保存即时必需的数据。不适合保存完整历史，

MemGPT / Letta：虚拟内存式管理

Main Layers：

In-context memory: system instruction,always-visible memory blocks。recent messages Out-of-context memory: searchable historical messages & long-term archived memories memory blocks 保存使用者特点、Agent 身份、当前工作状态和共享规则 archival memory 保存需要按需搜索的大规模长期信息

Generative Agents：观察 → 检索 → 合成 → 策划记忆链路

Reflexion：将失败写入情景记忆以供后续复用

Voyager：成功经验固化为技能库，升级为程序记忆

LangGraph：区分 thread 状态与跨会话记忆；采用人类记忆分类作为业务数据模型

LlamaIndex：FIFO 短期 + 可组合长期块；短期 FIFO 消息队列 → flush 到长期块 → 再合并检索。

Mem0这方面，抽取、整合、召回 + 实体关联；区分 Conversation/Session/User/Organizational memories；怎么说呢，向量库内 entity linking 与混合检索。

说到时间图谱，建立时间感知知识图谱；处理“谁在什么时候知道什么”的关系。

遗忘 & 强化机制:

KPI：

TTL | Decay | Reinforcement | Supersede | Archive

5️⃣ 设计原则：按职责而非数据库来分层，而非先决定数据库再填充数据。

数据类别	典型内容	访问特点	一致性要求

6️⃣ 推荐六层存储架构

flowchart TB
A --> L0
A → L1
A --> E
E --> L2
E --> L3
E --> L4
E --> L5
L1 --> A
L2 --> A
L3 --> A
L4 --> A

6.1 L0: 上下文缓存层

保存内容：- 程序指令 - 当前任务摘要 - 最近若干轮消息 - 必须使用的工具结果 - 少量始终可见的使用者偏好 & 限制 建议：- 明确 Token budget - 按优先级装配上下文 - 对超长输出做结构化摘要并引用原始结果 位置：- 主是 Agent Runtime 内存，可从 Redis/PostgreSQL 恢复 痛点解决：- 避免把所有历史塞进上下文导致 Token 超限及噪声堆积。

6.2 L1: 热状态 & 检查点

L1 保存内容：- session_id/thread_id/task_id - 当前计划/步骤状态/游标/重试次数 - 临时工具调用结果引用 - 分布式锁 & 租约 - 短期对话缓存/TLL 推荐中间件：- 默认 Redis – 必须可靠恢复的最终状态落入 PostgreSQL 痛点解决：- 实时更新任务进度、锁竞争防止乱序执行。

6.3 L2: 长期记忆

L2 拆分为两部分： 存放权威事实、事件、作用域、时间、来源及版本。存放 embedding + metadata 用于快速召回。痛点解决：- 防止“旧事实被新覆盖”问题；说起来，提供事务保证 & 审计方法。**推荐中间件**： | 层 | 中间件 | 优势 | |---|---|---| | Canonical Store | PostgreSQL | ACID + JOIN + 时间恢复 | | Retrieval Index | pgvector 或 Qdrant | HNSW/IVFFlat 高速向量检索 | **建议 metadata**： sql memory_id tenant_id user_id agent_id session_id task_id memory_type semantic/episodic/reflection/documentscope contentsummary source_event_ids source_object_uri valid_from valid_to created_at updated_at importance confidence reinforcement_count last_accessed_at decay_policy superseded_by embedding_model embedding_version prompt_version

6.7 时间关系与知识图谱层

• 实体 • 关系 • 时间字段 • 来源链路 **推荐中间件**： * 默认 Postgres 表格建模，足够满足初步需求；不过，* 多跳关系或时间推理成为主要时引入 Neo​⁠​​⁠​⁠​⁠​⁠​⁠​Neo​​‑Neo。**何时引入图数据库**： * 经常查询 “谁在何时有什么关系” * 多跳方法推理是必需 * 同一事实频繁变化且需回答历史 **何时不引入**： * 单纯文本问答或偏好召回即可满足

6.8 程序记忆 & 自我进化层

# 保存内容 #:`Prompt` 模板 & version `Agent policy` 工具定义 `SOP` `评估集` `发布记录` 等。# 推荐中间件 #:- PostgreSQL -b Git -b Object Storage # 痛点解决 #:- 防止 Agent 自动篡改生产 Prompt 或代码，需要审核流程。话说回来，

6.9 原始证据 & 冷归档层

# 保存内容 #:`完整对话` `工具原始输出` `上传文件快照` `日志快照` 等。# 推荐中间件 #:S3/Multi‑Cloud object storage。# 痛点解决 #:- 合规审计需要不可变长期保留；生命周期自动转移减少成本。

7️⃣ 写入链路：先保留。再异步加工，避免主请求阻塞。

mermaid sequenceDiagram participant U as User participant A as Agent Runtime participant R as Redis participant P as PostgreSQL participant Q as Qdrant participant G as Graph Store participant O as Object Storage participant W as Memory Worker

从U->>A来看，新消息或任务 从A->>R来看，更新 session/checkpoint/TLL 从A->>P来看，Append message_event 再看A->>O。Save long raw or attachment

A-->U的观点是，在线响应

至于P-->W，Trigger async memory processing

W->>P这方面，Extract facts,scenes,reflection with source event IDs

W->>Q的观点是，Write embeddings & metadata

opt need time relation: W->>G这方面，Update entities/rels/effective time

end

在线链路做什么？

• 保留原始事件； 说起来，
• 更新热状态；
• 保存大对象引用；
• 在预算内召回少量相关记忆。

异步 Worker 做什么？

• 抽取事实；
• 去重+合并；
• 冲突检测；
• embedding；
• 索引关键词；
• 权重计算；
• 把旧记忆降权或归档。

这样就不会把复杂抽取放进使用者请求关键方法。

8️⃣ 读取链路：混合检索比单一向量搜索更可靠。

常见信号组合的观点是，

信号类型	示例
Scope filter	tenant/user/project/session 权限
Semantic similarity	向量相似度
Lexical match	键词、错误码
Recency/time validity	时间衰减、新旧有效期
Importance/confidence	使用者确认度

说到评分公式示例。text score = semantic_similarity * α + lexical_relevance * β + recency * γ + importance * δ + confidence * ε; 实际权重集调优。对关系型问题再加入图查询结果，再通过 Reciprocal Rank Fusion 或 reranker 合并。而不是直接比较不同检索器原始分数。

在注入上下文前还要三件事：

1. 去重 – 避免同一事实多次出现。
2. 冲突裁决 – 优先选最新可信来源。
3. Token 压缩 – 删去无关冗余只保留回答所需。

9️⃣ 推荐中间件组合 — 按团队成熟度选择方案

职责范围	默认推荐组件	理由
热状态/TLL/短期缓存	Redis PostgreSQL	低延迟、高吞吐、ACID保障*
权威业务数据&事件流水 *	PostgreSQL+Outbox Kafka**	事务性、一致性、多租户支持*
语义检索+metadata过滤 *	Qdrant/pgvector*	专门向量检索能力、多租户支持*
时间关系&多跳推理	Necto*	Eager graph queries。可视化、更直观表达实体关联*
程序记忆 *	Pgit+PostgreSQL +离线评估脚本 *	Cohesive audit trail 与发布流程*
原始证据与冷归档	S3/Mini‑O*	TCO 节省，备份安全，可持续合法合规 *

注解说明这方面，上述组件顺序是“从 MVP 到生产”的渐进路线。在 MVP 阶段可以将所有功能压缩到单机 PostgreSQL＋pgvector＋Local Object Directory；当吞吐提高且跨程序同步成为瓶颈再逐步拆解成上述多组件程序。

10️⃣ 常见反模式汇总

"把所有历史都塞进向量库": 向量库擅长召回，却不具备事务和审计能力。

"保存所有对话却不抽取事实": 完整记录不是高质量记忆，需要异步提炼去重冲突管理。

"每轮都把全部记忆塞进 Prompt": Token 成本暴涨且噪声增加，建议先过滤再压缩。

"一开始就引入 Kafka／图 DB／多套向量库": 增加运维复杂度，应由明确瓶颈驱动。说起来，

"让 Agent 自动修改生产 Prompt 与代码": 必须经过审核流程才能生效。否则破坏治理闭环，

"忽略删除和撤回": 所有派生数据均应支持统一删除，以符合法规要求。

11️⃣ 最终建议

如果你现在要搭建一个通用 Agent 的分层存储，请按以下默认方案启动，并随业务成长逐步演进：

text L0 上下文缓存 ：Agent Runtime 内部装配，严格 Token budget L1 热状态 ：Redis Cluster L2 权威业务数据及事件流水 ：PostgreSQL 主库 L2 向量检索 ：Qdrant 集群 L3 时间关系 ：初期 PostgreSQL 表格。后面如需复杂推理则引 Neo‑Joo L4 程序记忆 ：Git 存储代码版本 + PostgreSQL 元数据 + 离线评估集 L5 原始证据 ：MinIO/S3 对象存储，并配置生命周期自动迁移至 Glacier 或 Cold Tier

主要原则是 “边界清晰”

● Redis 管快而短的数据。

● PostgreSQL 管权威状态和可审计的长久记录。

● Qdrant 专门负责高效语义召回。

● Neo‑Joo 像一个“加速器”，只有当多跳查询变得不可避免才加入。

● Git 为程序变更提供版本轨迹和回滚能力。

● S³/MinIO 为不可变的大对象提供低成本冷归档，并实现生命周期策略。

● Kafka 成为事件驱动解耦的最终手段，仅在吞吐极限或横向 明确需求后才启用。

---

这样，你既能让 Agent 在实时交互里保持低延迟。又能保证长期学习与治理的一致性，为未来进一步 AI 能力迭代奠定坚实基础。

---