很多團隊做 AI agent memory，第一個直覺是把更多聊天紀錄塞進向量資料庫。

這個做法很自然，也常常能撐過 demo。問題是，真正進入長期使用後，麻煩不只是「記不記得」，而是「現在還是不是事實」、「這句話從哪裡來」、「使用者後來有沒有改口」、「不同資料來源互相衝突時該信誰」。

Graphiti 值得看的地方就在這裡。它不是把 agent memory 做成更大的聊天紀錄，而是把對話、文件與業務資料整理成會隨時間變化的 context graph。對需要長期服務使用者、追蹤客戶狀態、保留來源與時間線的 agent 來說，這個方向比單純加大 context window 更接近實際問題。

English TL;DR

Graphiti is worth evaluating when agent memory needs temporal facts, provenance, and relationships instead of a larger pile of chat history. It is especially relevant for customer-facing agents, sales assistants, internal copilots, and workflow agents that operate on evolving real-world information. The adoption risk is also clear: once memory becomes a graph, teams must own data modeling, ingestion quality, governance, and retrieval behavior.

Graphiti 在解的不是「記憶容量」，而是「事實會變」

傳統 RAG 比較像查文件。你把資料切塊、做 embedding、搜尋相似片段，再把結果丟回模型。這對知識庫問答很有用，但它不一定適合 agent memory。

agent memory 的麻煩是資料一直變。

使用者昨天說預算有限，今天可能說預算通過了。客戶上週還在試用，本週可能已經轉付費。某個 API 昨天還能用，今天被團隊棄用了。只把每次對話都存成文字片段，系統可以搜尋到很多東西，但不一定知道哪個事實是最新的，也不一定知道舊事實為什麼被取代。

Graphiti 的定位是 temporal context graph。它把 entities、relationships、facts、episodes 和時間有效性放在一起處理。簡單講，它試圖回答的不是「哪些文字片段跟問題相似」，而是「這個人、這件事、這個關係在什麼時間點成立，現在應該怎麼被理解」。

這個方向很適合 AI agent，因為 agent 真正需要的不是資料越多越好，而是要在執行任務時拿到可用、可信、沒有過期得太離譜的上下文。

哪些團隊會真的需要它？

第一類是客服與客戶成功團隊。

如果 agent 只是回答公開文件，那普通 RAG 就夠了。但如果它要記得某個客戶的部署環境、歷史問題、合約狀態、偏好、限制與已解決事件，扁平聊天紀錄很快會變成垃圾山。Graphiti 這種 context graph 比較適合把「客戶 A 正在用哪個版本」、「上次問題跟哪個模組有關」、「哪個 workaround 已經失效」這類資訊整理成可查詢的關係。

第二類是銷售與顧問型 agent。

銷售不是只有聊天摘要。它有公司、聯絡人、需求、預算、競品、反對理由、決策者、下一步、時間線。這些資訊彼此有關係，而且會更新。用 Graphiti 這類工具，價值不是讓 agent 假裝更懂客戶，而是讓它在跟進時比較不會把半年前的狀態當成今天的現實。

第三類是內部營運助理。

內部 agent 如果要跨專案、跨會議、跨文件協助整理決策，就會遇到同樣問題：某個決策什麼時候成立？後來有沒有被推翻？誰提出的？跟哪個專案、哪個客戶、哪個限制有關？這些不是單純 semantic search 最擅長的題。

不適合的情境也很明確

Graphiti 不適合所有 AI 應用。

如果你只是做一次性文件問答，或資料基本不變，用普通 RAG 可能更簡單。多引入 graph database、entity extraction、關係建模與時間邏輯，未必划算。

如果你的 agent 還停在原型期，也不一定要急著上。很多團隊會太早把 memory 架得很複雜，結果真正缺的其實是清楚任務邊界、可靠工具呼叫、人工審核和可回滾流程。記憶層再漂亮，也救不了責任邊界混亂的 agent。

還有一種情況更該小心：資料本身品質很差。

Graphiti 可以幫你把資訊組成圖，但它不能神奇地判斷所有輸入都可信。如果 CRM 欄位亂填、會議紀錄含糊、客服標籤不一致、內部文件沒有版本觀念，graph 只會把混亂整理成看起來比較高級的混亂。

真正的採用問題：誰負責記憶？

Graphiti 這類工具會逼團隊面對一個以前容易躲掉的問題：agent 的 memory 到底是產品能力、資料平台能力，還是某個 prompt 裡的附屬品？

如果 memory 只放在 prompt 或聊天 thread 裡，產品團隊可以很快試。但只要進入多使用者、多資料來源、多流程，memory 就會變成系統能力。它牽涉到：

• 哪些資料可以被寫入長期記憶？
• 哪些事實需要來源與時間戳？
• 哪些記憶可以被使用者刪除或修正？
• agent 查記憶時，是自己判斷，還是有固定 retrieval policy？
• 記憶錯了，誰能審計與回滾？

這些問題聽起來很麻煩，但它們正是 agent 從玩具走向產品時避不掉的成本。

Graphiti 的價值，是把這些問題變得比較可以工程化，而不是把它們消除。

跟被動收入有什麼關係？

對 Glenn 的內容資產目標來說，Graphiti 這種題目不是只拿來追工具流量。它更適合接到一條可轉換的內容路徑：AI agent 要進公司，下一個缺口不是更會聊天，而是記憶、權限、審計與治理。

這類文章的價值在於它能吸引比較成熟的讀者。不是只想看「今天又有什麼新工具」的人，而是正在思考客服 agent、銷售 agent、內部助理、企業知識系統怎麼落地的人。

這種讀者比較接近未來可轉換的客群：他們會搜尋工具，但真正需要的是選型判斷、導入路線、風險清單與架構取捨。只要站內能把 Graphiti、mem0、RAGFlow、LiteLLM、MCP、agent workflow 這些題目串起來，就不是孤立工具文，而是一組 AI agent 導入資產。

結論

Graphiti 值得看，因為它把 agent memory 的問題從「存更多文字」拉回「管理會變動的事實」。

但它不是輕量萬靈丹。導入前要先確認你的問題真的需要 temporal memory、provenance、relationship retrieval，而不是只需要更好的 RAG、較短的摘要，或更清楚的工作流設計。

比較務實的看法是：如果你的 agent 需要長期理解使用者、客戶、專案或企業資料，而且這些事實會變，Graphiti 可以進選型清單。如果你的 agent 還只是單次問答或短流程自動化，先把任務邊界、工具權限和 eval 補好，通常更有 ROI。

參考

• Graphiti GitHub repo: https://github.com/getzep/graphiti
• Graphiti platform page: https://www.getzep.com/platform/graphiti/
• Zep temporal knowledge graph paper: https://arxiv.org/abs/2501.13956