Cognee 把記憶當成一條資料工程管線，而不是一個 agent 能力。它自我定位為 LLM agent 的「memory control plane」，核心是一條可組裝的 ECL（Extract, Cognify, Load）管線，把任意來源的原始資料轉成可查詢的知識圖加向量索引。這個定位讓它在「要把大量既有文件與互動紀錄一起變成記憶」的場景裡優勢明顯，而在「輕量對話個人化」的場景裡明顯過重。
核心機制：ECL 三階段
Extract（抽取）——從檔案、API、資料庫等來源攝取資料。官方宣稱支援三十種以上的來源，這是它與其他框架最大的功能面差異：多數記憶框架的輸入只有對話，Cognee 的輸入包含整個資料資產。
Cognify（認知化）——這是核心的轉換階段，也是它命名的來源。它是一條多步驟的子管線：文件分類 → 權限檢查 → 切塊 → 用 LLM 抽取實體與關係 → 生成摘要 → 產生 embedding 並寫入向量庫、把邊 commit 進圖。
這個階段裡有兩件事值得注意。 第一，權限檢查被放進管線內部而不是留給查詢時處理——這對多租戶或有存取控制需求的系統是正確的設計，因為它讓「不該被某人看到的資料不會進入他的記憶」變成結構性保證而非查詢時的過濾。第二，摘要生成與 embedding 是分開的步驟，這讓「用摘要做粗篩、用原文做精讀」的兩段式召回成為可能。
Load（載入）——把向量表示與圖的連結寫入後端儲存。
三階段是模組化的，可以替換各階段的實作與後端（向量庫、圖庫、關聯式）。「記憶寫入是一條可組裝的 ETL 管線」這個框架化，是 Cognee 最值得搬走的觀念。
Ontology：讓抽取有約束
Cognee 支援以 ontology（本體／schema）約束實體與關係的抽取。這解決了一個純 LLM 抽取的實際問題：在沒有約束的情況下，同一個概念會被抽成十幾種不同的關係名稱（works_at / employed_by / is_employee_of），圖因此無法被可靠地查詢。
給定 ontology 之後，抽取變成一個受限的分類問題而非開放生成，圖的一致性大幅提升，代價是需要事先定義領域模型。這是一個典型的取捨：泛用性換精確度。
這個取捨的判準很清楚：如果你的領域有穩定的實體型別（客戶、訂單、產品、工單），定義 ontology 幾乎總是值得的；如果你的記憶是開放領域的個人偏好，ontology 會變成一個持續追趕現實的負擔。
記憶分層
Cognee 把記憶分成兩層：session memory 作為 agent 的短期工作記憶，把相關的 embedding 與圖片段載入 runtime context 供快速推理；長期層則是持久化的圖加向量儲存。
它的召回結合圖遍歷與向量相似度，官方強調這使多跳推理成為可能——扁平檢索做不到「A 關聯到 B、B 關聯到 C，所以回答需要 C」這類問題。這個主張與 Graphiti 的混合檢索論證一致，兩者獨立收斂到同一結論。
儲存後端
向量庫（多種選項，包含檔案式的本地實作）＋ 圖庫 ＋ 關聯式。它刻意支援輕量的本地部署（不需要外部服務就能跑起來），也支援 Redis 之類的生產後端。這個「本地可跑、生產可換」的彈性降低了評估門檻，是它在開源社群獲得採用的實務原因。
寫入與召回策略
寫入時機：管線式，通常是批次或非同步觸發（攝取一批文件、或在對話後把新內容送進 cognify）。它不是設計成在 hot path 上同步寫入的——cognify 的多步驟成本太高。
召回方式：圖遍歷 ＋ 向量相似度的混合，可用 ontology 型別過濾。
遺忘：依賴管線重跑與資料集管理，沒有內建的時間衰減。時間模型明顯弱於 Graphiti——它在 cognify 階段加上時間脈絡（記錄資訊何時建立或修改），但沒有雙時間軸與自動失效。
優缺點
優點：輸入來源最廣，適合把既有資料資產一起納入記憶；ontology 提供了抽取品質的控制手段；權限檢查在管線內；管線模組化，各階段與後端可替換；本地部署門檻低。
缺點：cognify 成本高（多步驟、多次 LLM 呼叫），不適合逐輪同步寫入；概念與元件多，學習曲線陡；時間模型弱，處理「事實隨時間改變」不如 Graphiti；ontology 的維護是持續成本；生態與文件的成熟度低於 Mem0 與 Letta。
適合場景：知識密集型應用（把公司文件、工單、程式碼一起變成 agent 的記憶）、有穩定領域模型的垂直產品、需要多跳推理與存取控制的企業場景。不適合：純對話個人化、需要低延遲即時寫入、團隊規模小而不願承擔管線運維。
可抽取的模式
Memory ingestion as a pipeline（把記憶寫入當成管線）——不是一個 add() 函式，而是一條有明確階段、每階段可替換、可重跑的管線。可重跑這一點特別重要：抽取 prompt 改進之後，你希望能對歷史資料重新跑一次，而這只有在原始資料被保留且管線是純函式的情況下才可能。這與 Graphiti 的「不可變 episode ＋ 衍生事實」是同一個結論的兩種表述。
Schema-constrained extraction（受 schema 約束的抽取）——用 ontology 或 JSON schema 限制 LLM 抽取的輸出空間。這是提升記憶一致性最便宜的手段，而且在任何框架上都能做：把抽取 prompt 的自由生成換成受限的結構化輸出。
Permission check inside the write path（權限檢查放在寫入路徑）——不該被某個主體看到的資料，不應該進入該主體的記憶。在寫入時擋掉比在查詢時過濾更可靠，因為查詢過濾一旦有遺漏就是資料洩漏。
Summary layer for coarse retrieval（摘要層做粗篩）——為每個記憶單元同時保存摘要與原文，召回時先用摘要篩選再取回原文。這是控制召回 token 成本最有效的單一手段。