Zep 的核心主張是：記憶的難題不是儲存，是時間。使用者三個月前說偏好 A、上週說偏好 B，一個只做語意檢索的系統會同時召回兩者並讓模型自行猜測；一個做衝突解決的系統會刪掉 A，從此無法回答「他什麼時候改變的」。Zep 的開源引擎 Graphiti 用**雙時間軸模型（bi-temporal）**同時保留兩者並標記各自的有效區間，這是本專欄裡技術上最獨特、也最值得抄的設計。
Zep 的架構論文為 arXiv:2501.13956（〈Zep: A Temporal Knowledge Graph Architecture for Agent Memory〉）。
核心機制：四個時間戳
Graphiti 在每一條邊（關係／事實）上記錄四個時間戳，分成兩個獨立的軸：
系統軸（transaction time）——這條紀錄在資料庫裡的生命週期
created_at：這條關係被寫入資料庫的時間。永遠存在，因為寫入時系統一定知道。expired_at：這條關係在資料庫層面不再成立的時間。當新的 episode 否證或取代了它，系統把這個欄位設為當下時間。
事實軸（valid time）——這件事在現實世界中為真的區間
valid_at：這件事開始為真的時間。invalid_at：這件事停止為真的時間。
後兩者是可選的，由 LLM 在處理 episode 時從內容中抽取——可能是明確的日期（「我從三月開始吃素」），也可能是相對時間（「上週改的」）需要換算。
兩個軸分開是整個設計的關鍵。 「系統什麼時候知道這件事」與「這件事什麼時候是真的」是兩個不同的問題，而且經常不一致：使用者今天告訴你他去年換了工作，created_at 是今天，valid_at 是去年。任何只有一個時間戳的記憶系統，都無法區分「這是舊資料」與「這是關於過去的新資料」——而這個混淆在實務上會產生非常難 debug 的錯誤行為。
Episode：不可變的原始事件
Graphiti 的寫入單位是 episode——一個事件或一則訊息。系統持續攝取 episode，從中抽取實體與關係，並立即對照既有節點做消解（resolution），判斷這個「Tommy」是否就是圖裡已有的那個 Tommy。
抽取出的實體與邊指回產生它們的 episode，形成 episode-level provenance（事件層級的溯源）。這解決了 分類學 裡提到的問題：語意事實被抽取後會失去脈絡，而 provenance 讓你能從一條事實回溯到它的原始出處。「為什麼系統相信這件事」變成一個可以回答的問題，這是舊專欄 證據鏈與治理記憶 所主張的原則的具體實作。
事實失效：保留而非刪除
新 episode 進來時，Graphiti 用語意檢索、關鍵字檢索與圖遍歷找出語意相關的既有邊，再用 LLM 比對是否矛盾。發現時間上重疊的矛盾時，它不刪除舊邊，而是把舊邊的失效時間設為新邊的生效時間。
這個做法的三個後果值得逐一理解：
歷史查詢變成可能。 「三個月前他的偏好是什麼」可以透過時間過濾直接回答。多數框架做不到這件事，因為舊值已經被覆寫了。
不需要大規模重算。 新事實進來只影響與它矛盾的那幾條邊，圖的其餘部分不動。這與「重建整個索引」的做法在成本上差一個量級。
代價是圖會單向成長。 失效的邊仍然留在圖裡，因此儲存與查詢成本隨時間累積。Graphiti 沒有提供自動的歸檔或清理機制，長跑系統需要自己設計歷史邊的封存策略——這是選用它時必須事先規劃的事。
儲存與檢索
Graphiti 以圖資料庫為後端（Neo4j 是主要支援對象，也有其他選項），並在圖之上提供混合檢索：語意（向量）＋ 關鍵字（BM25 之類）＋ 圖遍歷。三者結合的理由很直接——語意檢索找得到措辭不同但意思相近的事實，關鍵字檢索找得到專有名詞與代號，圖遍歷找得到「透過關係才能到達」的事實。
這個三路混合是目前召回設計的最佳實踐，不限於圖架構。純向量檢索在專有名詞（人名、代號、版本號）上表現很差，這是一個被反覆驗證的已知弱點；補上關鍵字檢索的成本很低、收益很高。實作見 藍圖 的召回管線。
Zep 的商業版把 Graphiti 包成託管服務，並強調「每個主體一個 context graph」的運行模型——大量的小型、多數時間冷卻的圖，這與「一個巨大共享圖」的傳統知識圖假設很不一樣，也是它 runtime 調優的方向。
寫入與召回策略
寫入時機：每個 episode 攝取時同步處理（抽取實體與關係、消解、比對衝突）。寫入成本高——每個 episode 都涉及多次 LLM 呼叫。
召回方式：混合檢索，可加時間過濾（「只要目前有效的事實」或「某個時間點有效的事實」）。
遺忘：透過失效標記，不真的刪除。這是設計選擇而非缺陷，但它把清理責任推給了使用者。
優缺點
優點：時間模型是整個生態裡最完整的；provenance 讓記憶可稽核；混合檢索的召回品質好；能做多跳關係推理；有公開論文可查證。
缺點：寫入成本與延遲最高（LLM 抽取＋消解＋衝突比對）；需要營運一個圖資料庫，運維複雜度高於向量庫；圖品質完全取決於實體抽取與消解的正確性，消解錯誤（把兩個不同的人合成一個節點）造成的污染比向量庫的錯誤更難發現與修復；失效邊累積，無自動清理。
適合場景：事實會隨時間改變且歷史有價值的領域（客戶關係、病歷、專案狀態、法規遵循）、需要多跳推理的應用、需要向稽核者證明「系統為什麼這樣判斷」的場合。不適合：記憶只是輕量個人化、寫入量極大而預算有限、團隊沒有圖資料庫運維能力。
可抽取的模式
Bi-temporal fact records（雙時間軸事實紀錄）——每一條記憶同時記錄「系統何時知道」與「現實中何時為真」。這是本專欄最強烈推薦的單一模式，而且它不需要圖資料庫：在一張 SQL 表上加四個時間戳欄位就成立。介面定義見 schema 草案。
Invalidate, don’t delete（標記失效而非刪除）——衝突解決的預設應該是把舊紀錄標記為在某個時點失效，而不是移除它。唯一該真的刪除的是使用者要求刪除的個資（見 PII），其餘都該保留。
Immutable episodes with derived facts（不可變事件 ＋ 衍生事實）——原始事件不可變、只 append；抽取出的事實可變、指回原始事件。這是 event sourcing 的模式套在記憶上，與 Event Sourcing 的推理完全一致：保留事件流，衍生狀態可以重算。它帶來一個很大的實務好處——抽取邏輯改進後，可以重跑整條管線，而覆寫式的設計做不到。
Hybrid retrieval as default（混合檢索作為預設）——語意 ＋ 關鍵字 ＋ 結構（圖遍歷或 metadata 過濾）三路合併。純向量是效果最差的預設值。