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

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

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

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

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

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

 示例：保存最近的交互信息，比如剛剛發(fā)送的聊天內(nèi)容。

 持續(xù)時間：任務(wù)或?qū)υ捊Y(jié)束后即被清除，不會保留。

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

 流程：Receive（接收）→ Consolidate（整合）→ Store（存儲）→ Retrieve（提?。?/p>

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

 示例：保存偏好設(shè)置、事實知識、歷史數(shù)據(jù)等。

 持續(xù)時間：會隨著AI不斷學(xué)習(xí)新信息而增加和演變。

3. 情節(jié)記憶（Episodic Memory）

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

 作用：記錄詳細(xì)的、事件性的經(jīng)歷。

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

 好處：有助于AI根據(jù)過往經(jīng)歷，個性化地回應(yīng)當(dāng)前請求。

4. 語義記憶（Semantic Memory）

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

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

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

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

5. 工作記憶（Working Memory）

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

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

 示例：臨時保存指令、目標(biāo)或計算步驟。

 好處：對即時推理、計劃和執(zhí)行任務(wù)至關(guān)重要。

6. 程序性記憶（Procedural Memory）

 流程：Learn（學(xué)習(xí)）→ Store（存儲）→ Practice（練習(xí)）→ Apply（應(yīng)用）

 作用：保留已學(xué)會的操作和流程，可自動化執(zhí)行。

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

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

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

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

那我們繼續(xù)。

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

線說思路核心：  

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

2) 根據(jù)查詢方式（鍵值檢索 ， 語義相似度 ， 結(jié)構(gòu)化查詢 ， 順序重放）選數(shù)據(jù)庫模型；  

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

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

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

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

? 推薦組件的話呢？  

   首選：進程內(nèi)緩存（Python Dict、Go map）或輕量化 KV 內(nèi)存數(shù)據(jù)庫（Redis、Dragonfly）。  

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

? 數(shù)據(jù)模型/格式  

   結(jié)構(gòu)簡單：

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

 或者直接token 緩存。  

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

? 設(shè)計要點  

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

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

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

2. 工作記憶 (Working Memory)  

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

? 推薦組件  

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

 如需多人協(xié)作或 DAG 工作流，可用內(nèi)存流數(shù)據(jù)庫（Materialize、RisingWave）或流框架（Kafka + ksqlDB）暫存。  

? 數(shù)據(jù)模型  

JSON/Dict：

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

? 設(shè)計要點  

  可隨時丟棄原則；  

  若任務(wù)超長，用 Write-Ahead Log 落盤到本地 SSD 防節(jié)點故障。

  這倆沒啥特別可解釋的

3. 情節(jié)記憶 (Episodic Memory)  

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

? 推薦組件（Hybrid Store）  

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

  2-語義索引：向量數(shù)據(jù)庫 Milvus / Weaviate / pgvector / Pinecone。  

? 數(shù)據(jù)模型  

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

  向量表：event_id, embedding VECTOR(768看你處理的數(shù)據(jù)業(yè)務(wù)形態(tài)，768就是個建議值) + HNSW/IVF 索引  

? 設(shè)計要點  

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

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

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

4. 語義記憶 (Semantic Memory)  

? 定義：事實、概念、知識圖譜，強調(diào)結(jié)構(gòu)化關(guān)系和可推理。  

? 推薦組件  

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

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

? 數(shù)據(jù)模型  

  三元組：(entity, relation, entity)

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

? 設(shè)計要點  

  明確本體 / schema；  

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

  支持批量導(dǎo)入（主要是產(chǎn)業(yè)和公司內(nèi)部文檔這些玩意，對，還有wiki）。

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

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

? 推薦組件（分層架構(gòu)）  

  結(jié)構(gòu)化偏好：PostgreSQL / MySQL  

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

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

? 數(shù)據(jù)模型  

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

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

? 設(shè)計要點  

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

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

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

6. 程序性記憶 (Procedural Memory)  

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

? 推薦組件  

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

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

  運行時加載：在容器或函數(shù)服務(wù)等serverless服務(wù)中按需調(diào)用。  

? 數(shù)據(jù)模型  

  代碼 / YAML / BPMN 文件；  

 元數(shù)據(jù)表：skill_id, name, version, checksum, entry_point, permissions.  

? 設(shè)計要點  

  版本標(biāo)簽+語義化發(fā)布 (SemVer)；  

  審批/回滾鏈路；  

  延遲加載 + 本地 LRU 緩存，保證首調(diào)用體驗。 

跨層 Memory Orchestrator 設(shè)計要點  

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

2) 讀寫策略：  

   ? 寫入時自動路由到對應(yīng)存儲；  

   ? 讀取時支持級聯(lián)：先 STM 到LTM 到 語義 / 圖譜。  

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

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

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

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

本文轉(zhuǎn)載自??熵減AI?????，作者：周博洋