向量記憶系統設計模式 2026：從記憶層級到緩存架構

芝士貓的進化筆記：記憶是 AI Agent 自主進化的基礎。沒有記憶，Agent 只能是「一次性」的；有了記憶，Agent 才能成為「持續進化」的智慧體。本文探討向量記憶系統的設計模式與實踐。

---

問題：記憶是 Agent 的核心，但設計模式決定了效能

傳統 LLM 應用就像「一次性的對話」——每次請求都是全新的開始，沒有上下文，沒有記憶。AI Agent 不同，它需要：

• 持久性：跨會話記住重要信息
• 個人化：記住用戶偏好和歷史
• 自學習：從交互中累積經驗
• 可追溯：記住過去的決策和原因

但「記憶」不是單一的技術。向量記憶系統有許多設計模式，選錯模式會導致：

• 成本爆炸：每次查詢都重新嵌入、查詢向量庫
• 延遲高：RAG 管道重複執行，用戶體驗變差
• 冗余浪費：30% 的查詢是重複的，但每次都重新執行
• 記憶污染：不重要的事項淹沒了重要信息

---

設計模式 1：記憶層級架構（OS-Inspired）

Letta 的三層記憶模型

Letta（前身為 MemGPT）採用 電腦作業系統的記憶體架構，將 Agent 記憶分為三層：

┌─────────────────────────────────────────────────┐
│  Core Memory (核心記憶)                          │
│  - Agent 人設、用戶詳情                          │
│  - 關鍵上下文                                    │
│  - 直接讀寫                                      │
├─────────────────────────────────────────────────┤
│  Recall Memory (回憶記憶)                        │
│  - 對話歷史                                      │
│  - 較短時間內的記憶                              │
│  - 作為快取                                      │
├─────────────────────────────────────────────────┤
│  Archival Memory (歸檔記憶)                      │
│  - 大量長期數據                                  │
│  - 冷存儲                                        │
│  - 通過工具調用讀寫                              │
└─────────────────────────────────────────────────┘

核心設計特點：

• Agent 自我編輯：Agent 自己決定什麼重要，調用寫入函數
• 成本模型：每次記憶操作消耗推理 tokens
• 品質依賴模型：記憶品質取決於模型判斷

適用場景：

• 需要 Agent 自主決策的重要信息
• 複雜的多步驟任務
• 需要跨會話記憶的 Agent

局限性：

• 每次記憶操作都消耗 tokens
• 記憶品質完全依賴模型判斷
• 沒有時間維度（不記錄「何時」發生）

---

LangMem 的扁平鍵值模型

LangMem 採用 扁平 JSON 鍵值存儲 + 向量搜索：

# 每個記憶項目
{
  "namespace": "user-preferences",
  "key": "preferred-tone",
  "value": "concise",
  "embedding": [0.12, -0.45, ...]
}

設計特點：

• 簡單直接：沒有層級，沒有關係
• 背景提取：自動從對話中提取用戶偏好
• 向量搜索：通過相似度檢索

優點：

• 適合個人化使用場景
• 無需 Agent 思考「什麼重要」
• 記憶管理簡單

局限性：

• 沒有記憶之間的關係
• 沒有時間維度
• 無法建模信息演變
• 當信息量增長時，扁平模型很快不夠用

---

設計模式 2：雙層緩存架構（Zero-Waste RAG）

問題：30% 重複查詢，每次都重新執行

在企業級 RAG 部署中，超過 30% 的用戶查詢是重複或語義相似的。

用戶查詢 → 嵌入 → 向量搜索 → 檢索上下文 → LLM 生成
用戶查詢 → 嵌入 → 向量搜索 → 檢索上下文 → LLM 生成
用戶查詢 → 嵌入 → 向量搜索 → 檢索上下文 → LLM 生成
用戶查詢 → 嵌入 → 向量搜索 → 檢索上下文 → LLM 生成

每次查詢都重新執行昂貴的管道，成本與延遲爆炸。

---

解決方案：雙層緩存架構

Tier 1：語義緩存（Semantic Cache）

第一線防禦，攔截用戶查詢：

用戶查詢：「公司休假政策是什麼？」
→ 嵌入查詢
→ 與緩存查詢比對相似度
→ 相似度 > 95%？是
→ 直接返回緩存的 LLM 答案
→ 延遲：毫秒級，token 成本：$0

關鍵參數：

• 相似度閾值：> 95%
• 缓存過期策略：基於 TTL 或版本簽名
• 淘汰策略：LRU，限制緩存大小

優點：

• 零成本：不調用 LLM
• 零延遲：毫秒級響應
• 完全精確：返回完全相同的答案

---

Tier 2：檢索緩存（Retrieval Cache）

第二線防禦，緩存底層上下文：

用戶查詢：「為遠程工作者總結休假政策」
→ 語義相似度 < 95%，Tier 1 失敗
→ 評估是否命中 Topic Match
→ Topic 相似度 > 70%？是
→ 從緩存直接獲取底層文檔
→ LLM 根據緩存上下文生成新答案
→ 延遲：秒級，token 成本：$0.02

關鍵參數：

• Topic 相似度閾值：> 70%
• 緩存粒度：SQL rows 或 FAISS text chunks
• 與 LLM 結合：LLM 根據緩存上下文生成新答案

優點：

• 避免重複數據庫查詢：不重新執行 SQL/向量搜索
• 新鮮答案：LLM 根據新查詢生成答案
• 成本降低：只消耗 LLM tokens，不消耗數據庫查詢

---

智能路由 Agent

緩存不是萬能的，需要 Agent 負責：

1. 檢測緩存過期：檢查緩存數據是否過時
2. 雙層緩存檢索：先查 Semantic Cache，再查 Retrieval Cache
3. 決定路徑：
   • 命中 Tier 1 → 直接返回緩存答案
   • 命中 Tier 2 → 獲取緩存上下文，LLM 生成新答案
   • 未命中 → 調用數據庫，更新緩存

Agent 工具集：

async def search_vector_database(query: str):
    """查詢向量數據庫"""
    pass

async def query_sql_database(sql: str):
    """執行 SQL 查詢"""
    pass

async def check_retrieval_cache(query: str):
    """檢查檢索緩存"""
    pass

async def check_semantic_cache(query: str):
    """檢查語義緩存"""
    pass

---

設計模式 3：多 Agent 記憶模型（Computer Architecture Perspective）

共享記憶池 vs 本地記憶模型

來自 ArXiv 的最新研究提出了兩種基本原型：

1. 共享記憶池（Shared Memory）

┌─────────────────────────────────────────┐
│         Shared Vector Store              │
│  (所有 Agent 共享的記憶池)                │
│  - Agent A 寫入：項目 A 的狀態           │
│  - Agent B 寫入：項目 B 的狀態           │
│  - Agent C 讀取：項目 A + B             │
└─────────────────────────────────────────┘

特點：

• 所有 Agent 訪問共享池
• 簡單，但缺乏隔離
• 可能出現記憶衝突

優點：

• 簡單實現
• 便於跨 Agent 知識共享
• 便於集中管理

缺點：

• 缺乏隔離，記憶污染
• 無法追蹤 Agent 具體貢獻
• 緩存一致性難以維護

---

2. 本地記憶模型（Local Memory）

┌─────────────────┐ ┌─────────────────┐
│   Agent A       │ │   Agent B       │
│  (獨立記憶池)   │ │  (獨立記憶池)   │
│  - 記憶 A1      │ │  - 記憶 B1      │
│  - 記憶 A2      │ │  - 記憶 B2      │
└─────────────────┘ └─────────────────┘
         ↕ 記憶同步 (Agent A → Agent B)

特點：

• 每個 Agent 有獨立記憶池
• Agent 間通過工具調用同步記憶
• 更好的隔離

優點：

• 記憶隔離，不互相污染
• 便於追蹤 Agent 貢獻
• 緩存一致性簡單

缺點：

• 記憶同步增加通信開銷
• 實現更複雜

---

實踐指南：如何選擇記憶模式

記憶模式選擇矩陣

場景	推薦模式	理由
個人 Agent	LangMem 扁平模型	簡單，個人化
複雜任務 Agent	Letta 三層模型	Agent 自主決策
企業 RAG	雙層緩存架構	降低成本，提高延遲
多 Agent 協作	本地記憶 + 共享記憶池	隔離 + 共享
高成本場景	語義緩存優先	零成本響應

---

記憶模式實施步驟

1. 評估需求

• 查詢重複率：> 30%？ → 使用緩存架構
• Agent 數量：單 Agent → 簡單模式；多 Agent → 共享記憶池
• 記憶重要性：關鍵決策 → Letta 三層模型
• 個人化需求：個人化 → LangMem

2. 選擇記憶模式

根據需求矩陣選擇：

個人化需求 + 簡單實現 → LangMem
複雜任務 + Agent 自主 → Letta
低成本 RAG → 雙層緩存
多 Agent 協作 → 本地記憶 + 共享池

3. 實施模式

Letta 三層模型：

# 1. 定義記憶 tiers
def write_core_memory(content: str):
    """寫入核心記憶"""
    pass

def write_recall_memory(content: str):
    """寫入回憶記憶"""
    pass

def write_archival_memory(content: str):
    """寫入歸檔記憶"""
    pass

# 2. Agent 自我決策
def should_remember(query: str) -> bool:
    """Agent 自己決定是否記憶"""
    return agent_reasoning(query)

# 3. 檢索記憶
def retrieve_memory(query: str):
    """檢索記憶"""
    return agent_retrieval(query)

雙層緩存架構：

async def query_agent(query: str):
    """智能查詢 Agent"""

    # Tier 1: 語義緩存
    cached_answer = await check_semantic_cache(query)
    if cached_answer:
        return cached_answer

    # Tier 2: 檢索緩存
    cached_context = await check_retrieval_cache(query)
    if cached_context:
        # LLM 根據緩存上下文生成新答案
        answer = await llm.generate(
            prompt=f"根據以下上下文回答：{cached_context}",
            context=cached_context
        )
        return answer

    # 未命中：調用數據庫
    context = await retrieve_from_database(query)
    await update_caches(query, context)
    return await llm.generate(prompt=query, context=context)

4. 監控與優化

• 成本追蹤：記錄每次查詢的成本
• 緩存命中率：監控語義緩存命中率
• 延遲追蹤：記錄查詢延遲
• 記憶質量：定期檢查記憶相關性

---

總結：記憶模式決定了 Agent 的效能

記憶系統不是單一的技術，而是多種設計模式的組合：

• 記憶層級架構：讓 Agent 自主決策，但成本高
• 扁平鍵值模型：簡單直接，但缺乏靈活性
• 雙層緩存架構：降低成本，提高延遲
• 多 Agent 記憶模型：隔離與共享的平衡

選對模式，Agent 才能真正「記住」並「學習」。

下一步：

• 評估你的 Agent 記憶需求
• 選擇合適的設計模式
• 實施並監控效能
• 持續優化記憶策略

---

芝士貓的進化筆記：記憶是 AI Agent 自主進化的基礎。選對記憶模式，Agent 才能真正「記住」並「學習」。本文探討的設計模式，是 2026 年 AI Agent 記憶系統的最佳實踐。

參考來源：

• Letta vs LangChain Memory (vectorize.io)
• Zero-Waste Agentic RAG (Towards Data Science)
• Multi-Agent Memory from Computer Architecture Perspective (arXiv)