最近看了一張畫Agent記憶分類的圖

我覺得分類分的還可以，但是太淺了，于是就著它的邏輯，仔細得寫了一下在不同的記憶層，該如何設計和選型

先從流程，作用，實力和持續時間的這4個維度來解釋一下這幾種記憶：

1. 短期記憶（Short-Term Memory, STM）

 流程：Input（輸入）→ Encode（編碼）→ Store（存儲）→ Erase（清除）

 作用：在進行活動時保持臨時細節，類似于我們在對話中臨時記住的信息。

 示例：保存最近的交互信息，比如剛剛發送的聊天內容。

 持續時間：任務或對話結束后即被清除，不會保留。

2. 長期記憶（Long-Term Memory, LTM）

 流程：Receive（接收）→ Consolidate（整合）→ Store（存儲）→ Retrieve（提取）

 作用：維持持久的知識，跨多次交互都能訪問這些知識。

 示例：保存偏好設置、事實知識、歷史數據等。

 持續時間：會隨著AI不斷學習新信息而增加和演變。

3. 情節記憶（Episodic Memory）

 流程：Experience（體驗）→ Encode（編碼）→ Store（存儲）→ Recall（回憶）

 作用：記錄詳細的、事件性的經歷。

 示例：記住是和誰互動（這個不見的“who”代表的是user，也可能是agent）、討論了什么、何時發生等。

 好處：有助于AI根據過往經歷，個性化地回應當前請求。

4. 語義記憶（Semantic Memory）

 流程：Concepts（概念）→ Store（存儲）→ Retrieve（提取）→ Use（使用）

 作用：保存事實、概念、語言等一般知識，防止常識性幻覺

 示例：知道“倫敦是英國的首都”這種事實。

 特性：類似于人類從書本或知識學習中獲得并提取的常識。

5. 工作記憶（Working Memory）

 流程：Inputs & Goals（輸入和目標）→ Temp Ops Area（暫存操作區）→ Real-Time Ops（實時操作）→ Discard（丟棄）

 作用：處理即時信息，便于現場決策和解決問題。

 示例：臨時保存指令、目標或計算步驟。

 好處：對即時推理、計劃和執行任務至關重要。

6. 程序性記憶（Procedural Memory）

 流程：Learn（學習）→ Store（存儲）→ Practice（練習）→ Apply（應用）

 作用：保留已學會的操作和流程，可自動化執行。

 示例：自動知道如何格式化文檔、發郵件或跟隨既有流程。

 類比：“肌肉記憶”，讓AI能流暢地完成熟悉的任務。

以上六種記憶類型，分別服務于AI在不同場景下的存儲、處理和應用：從即時、臨時的信息處理，到持久、自動化的技能與知識運用。

但是這個概念要是落到紙面上其實還有很多工作要做吧，最起碼得知道用啥存儲組件吧，或者數據格式推薦？

那我們繼續。

下面我根據上面這個圖，整一個面向LLM Agent的存儲設計建議，目的是能說明 6 類記憶各自應選用的存儲類型、數據格式、關鍵組件及設計要點。

線說思路核心：  

1) 根據記憶的壽命（瞬時 ， 短期 ， 長期）、讀寫頻率、訪問延遲需求選介質；  

2) 根據查詢方式（鍵值檢索 ， 語義相似度 ， 結構化查詢 ， 順序重放）選數據庫模型；  

3) 最好能用統一的記憶編排層抽象讀寫接口，屏蔽底層異構存儲差異。

我就不按上面的順序來寫了啊，咱們就從短長開始設計，這樣看著邏輯性強一點。

1. 短期記憶 (Short-Term Memory, STM)  

? 典型訪問特征：生命周期 = 一次對話/任務，毫秒級讀寫，鍵值直取，不需要持久化。  

? 推薦組件的話呢？  

   首選：進程內緩存（Python Dict、Go map）或輕量化 KV 內存數據庫（Redis、Dragonfly）。  

   高并發多實例可用 Redis Cluster + TTL 到期刪除。  

? 數據模型/格式  

   結構簡單：

{conversation_id: [{role, content, ts}]}

 或者直接token 緩存。  

   若需少量向量召回，可把 embedding 作為 field 存 Hash/JSON 里，或附帶到本地 Faiss index（RAM），有錢Faiss可以上GPU，但是其實也沒太大必要。

? 設計要點  

   TTL 必須 小于 上下文窗口時間，其實這個挺好理解，如果你TTL設置得太長，超過了當前任務/對話上下文窗口，那么舊的短期記憶有可能被下一輪新的對話或任務意外掛載和復用，導致“前一個用戶/任務”的內容泄露進來（典型的“越權存取”風險）  

   關閉持久化 (AOF/RDB) 以獲得極低延遲；  

  同步刪除：對話結束立即 DEL / EXPIRE 0。

2. 工作記憶 (Working Memory)  

? 定義：Agent 正在推理時的scratchpad。持續幾秒～幾分鐘，需要頻繁更新、順序遍歷。 

? 推薦組件  

  直接放在 LLM 的 Prompt 構造器里（臨時 Python 對象 / JS 對象）；  

 如需多人協作或 DAG 工作流，可用內存流數據庫（Materialize、RisingWave）或流框架（Kafka + ksqlDB）暫存。  

? 數據模型  

JSON/Dict：

{"goal": "...", "current_step": 3, "intermediate_results": [...]}

? 設計要點  

  可隨時丟棄原則；  

  若任務超長，用 Write-Ahead Log 落盤到本地 SSD 防節點故障。

  這倆沒啥特別可解釋的

3. 情節記憶 (Episodic Memory)  

? 定義：帶時間戳的交互事件流，需要按語義＋時間檢索。  

? 推薦組件（Hybrid Store）  

  1-事件日志：Append-only 列式或時序庫  Apache Iceberg / Parquet on S3、ClickHouse、TimescaleDB，這東西太多了，要我就clickhouse了，因為簡單，但是特別要注意時間上下文的，可能還得去找專門的TSDB來搞

  2-語義索引：向量數據庫 Milvus / Weaviate / pgvector / Pinecone。  

? 數據模型  

  基表的設計example：event_id, agent_id, user_id, timestamp, text, meta(json)

  向量表：event_id, embedding VECTOR(768看你處理的數據業務形態，768就是個建議值) + HNSW/IVF 索引  

? 設計要點  

  雙寫：事件落盤時同步寫入向量庫；  

  支持 “who/when/what” 過濾（涉及時間，事件和角色） + 近似向量檢索；  

  定期離線合并老分區、分層存儲 (hot ? cold)。

4. 語義記憶 (Semantic Memory)  

? 定義：事實、概念、知識圖譜，強調結構化關系和可推理。  

? 推薦組件  

  知識圖譜：RDF 三元組庫 (Blazegraph, Virtuoso) 或圖數據庫 (Neo4j, TigerGraph)；  

  補充全文/向量：Elasticsearch + KNN（有沒有估計能差點意思）、或者同上向量庫。  

? 數據模型  

  三元組：(entity, relation, entity)

  為每個實體存 description, embedding，支持 embedding 相似度 + Cypher（圖）/SPARQL（EDF） 查詢，當然也可以加上BM25座個hyberid，最后再rerank。  

? 設計要點  

  明確本體 / schema；  

  版本化知識 (snapshot + diff) 以便回溯；  

  支持批量導入（主要是產業和公司內部文檔這些玩意，對，還有wiki）。

5. 長期記憶 (Long-Term Memory, LTM)  

? 定義：用戶偏好、持久配置、歷次學習成果的總匯，需要可擴展、持久、多模式查詢。  

? 推薦組件（分層架構）  

  結構化偏好：PostgreSQL / MySQL  

  大文件/文檔：對象存儲 (S3類的)  

   語義檢索：統一指向上面的向量庫（可與情節/語義共用集群省點錢）。  

? 數據模型  

  偏好表：user_id, key, value(jsonb), updated_at  

  文檔索引：doc_id, s3_uri, summary, embedding  

? 設計要點  

  多租戶隔離、如果有強烈的compliance需求，那上面GDPR 啥的也可以在這個基礎上建設，總而言之就是不能混用了；  

  寫放大：批量 consolidate 后寫，減少頻繁小更新；  

  定期遷移冷數據到低成本存儲 ，比如類Glacier的純冷層，但是我其實還時更推薦放在溫層里面進行存儲，雖然長期記憶不見的總能用到，但是一旦用到，折騰Glacier還是挺麻煩的，另外一個必須做的工作就是，長期記憶的定期summary，短期記憶可以周期性的匯總形成長期記憶，長期記憶也可以定期匯總形成超長期記憶，來避免context和storage的雙重上限壓力。

6. 程序性記憶 (Procedural Memory)  

? 定義：可復用的技能 / 工作流 / 宏；更新頻次低、讀頻次高，需要版本控制和安全審計。 

? 推薦組件  

   Git 倉庫 (GitLab / GitHub Enterprise或者任何企業里面用的倉庫，愿意用啥都行) + CI；  

  若技能用 DSL/JSON 表示，可再加文檔數據庫 (MongoDB) 緩存可解析的 AST；  

  運行時加載：在容器或函數服務等serverless服務中按需調用。  

? 數據模型  

  代碼 / YAML / BPMN 文件；  

 元數據表：skill_id, name, version, checksum, entry_point, permissions.  

? 設計要點  

  版本標簽+語義化發布 (SemVer)；  

  審批/回滾鏈路；  

  延遲加載 + 本地 LRU 緩存，保證首調用體驗。 

跨層 Memory Orchestrator 設計要點  

1) 統一 API：store(memory_type, data, **meta)、retrieve(memory_type, query)  

2) 讀寫策略：  

   ? 寫入時自動路由到對應存儲；  

   ? 讀取時支持級聯：先 STM 到LTM 到 語義 / 圖譜。  

3) 安全合規：數據分級、加密 at-rest + in-transit，PII 脫敏。  

4) 指標觀測：每層暴露 QPS、延遲、命中率，Prometheus + Grafana。

5) 彈性伸縮：冷熱分層、Auto-Scaling、備份與災難恢復策略。  

如果按著我以上的設計來經營你的Agent記憶系統，那肯定既能保證超低延遲的對話體驗，又能讓 Agent 正確的調用長短期記憶的知識，演化技能，而且復雜度相當高，為了做AI自動化，手動創建了極其精密和復雜的存儲系統，就又可以借機會招人了，創造了就業機會。

本文轉載自??熵減AI?????，作者：周博洋