Memori：把 agent 的執行過程寫成可查詢狀態，而不是塞進 prompt
Memori is agent-native memory infrastructure. A LLM-agnostic layer that turns agent execution and conversation into structured, persistent state for production systems. Built for enterprise, Memori works with the data infrastructure you already run, no rip-and-replace, and deploys across managed cloud, single-tenant cloud, VPC, and on-premises.
秒懂
- 它是什麼？
- Memori 是 MemoriLabs 的 agent 記憶層，透過註冊 LLM client 攔截對話與工具呼叫，寫入外部資料庫後按需檢索。本文整理它的實際機制、安裝指令、LoCoMo 讀數、BYODB 與授權的不確定處，並說明什麼情況下它會是錯的工具。
- 適合誰用？
- Memori 適合已經在用 OpenAI 或相容 SDK、且願意把記憶放到自己資料庫的團隊，尤其是需要以 entity_id 區分終端使用者、以 process_id 區分 agent 角色的多租戶系統。若你的場景是單次無狀態推論、或你想完全掌握記憶抽取與檢索的每一段邏輯，它不適合，因為 .llm.register(client) 之後的行為由函式庫決定。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 12 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Memori 要解的是 agent 的失憶，不是模型的失憶
多數 agent 的記憶問題不在模型，而在呼叫端。每一輪把歷史訊息重新塞進 messages 陣列，token 成本隨對話長度線性上升，而且模型仍可能忽略中段內容。Memori 的定位寫在 README 的第一行標語裡：Memory from what agents do, not just what they say。它要捕捉的不只是對話文字，還包括工具呼叫、決策與結果。
目標讀者是已經有 production agent、正在為上下文長度與成本頭痛的團隊。README 反覆強調 LLM、datastore、framework 三者的 agnostic，並列出部署形態：managed cloud、single-tenant cloud、VPC、on-premises。這句話的實際含義是，Memori 假設你不會為了記憶功能更換既有資料基礎設施。
它不處理的事也要說清楚。Memori 不做 agent 編排，不做工具定義，也不取代你的向量檢索層。它是一層攔截與持久化，掛在你原本的 LLM client 上。
llm.register 與 attribution：兩行呼叫決定記憶歸屬
機制核心是註冊。Python 範例是 Memori().llm.register(client)，TypeScript 是 new Memori().llm.register(client)。註冊之後，client.chat.completions.create 的呼叫會被攔截，對話在背景被持久化，下一輪查詢時自動召回。README 的註解寫得很直白：Conversations are persisted and recalled automatically in the background。
歸屬由 mem.attribution 決定。Python 用關鍵字參數 entity_id 與 process_id，TypeScript 用位置參數 ('user_123', 'support_agent')。前者標識終端使用者，後者標識 agent 角色或流程。這個切分是多租戶系統能不能用的關鍵：同一個 process_id 下，不同 entity_id 的記憶必須隔離，否則客服 agent 會把 A 客戶的偏好回答給 B 客戶。
這裡有一個文件沒有回答的問題。召回發生在背景，那麼檢索是在送出請求前同步完成，還是非同步注入？README 只說自動，沒有描述時序。對於延遲敏感的服務，這個差異會直接影響 p99。要接正式流量之前，這一點必須自己量。
安裝與啟動：SDK、外掛、以及三種接入路徑
Python 走 pip install memori，TypeScript 走 npm install @memorilabs/memori。兩者都需要環境變數 MEMORI_API_KEY，加上你原本的 LLM key，例如 OPENAI_API_KEY。API key 從 app.memorilabs.ai 取得。
第二條路徑是 OpenClaw 外掛，README 稱其為 drop-in，不需要改動 agent 程式碼或 prompt。指令序列是 openclaw plugins install @memorilabs/openclaw-memori、openclaw plugins enable openclaw-memori、openclaw memori init 帶 --api-key、--entity-id、--project-id 三個參數，最後 openclaw gateway restart。外掛掛進 OpenClaw 的生命週期，每一輪之後捕捉工具呼叫、決策與結果。
第三條是 Hermes Agent 的記憶 provider。pip install hermes-memori 之後執行 hermes-memori install，再用 hermes config set memory.provider memori 切換 provider。金鑰寫進 $HERMES_HOME/.env，需要 MEMORI_API_KEY 與 MEMORI_ENTITY_ID。MEMORI_PROJECT_ID 是選填的，省略時 provider 會沿用 Hermes 當下的 project context 做 scoping。Hermes 另外提供 memori_recall 與 memori_recall_summary 兩個工具，讓 agent 自己決定何時召回。
三條路徑的取捨很明顯。SDK 給你最細的控制，但要改程式碼。OpenClaw 與 Hermes 外掛改動最小，代價是你被綁在那兩個 gateway 的生命週期上。
BYODB 是這套設計裡最值得細看的一塊
README 用一個提示框指向 BYODB 文件，即 bring your own database。這代表記憶可以寫進你自己維運的資料庫，而不是只能待在 Memori 的託管服務裡。文件另外提到 TiDB Zero 的 provisioning 指南，路徑是 docs/memori-byodb/databases/tidb.mdx，用途是開發階段的免洗資料庫。
這個設計的意義在資料主權。企業願意導入記憶層，通常卡在「對話內容要離開我的 VPC 嗎」。BYODB 加上 README 列出的 VPC 與 on-premises 部署形態，是對這個問題的回應。
但這裡有明顯的資訊缺口。我手上只有 README，看不到 BYODB 支援哪些資料庫引擎的完整清單，也看不到 schema 由誰管理、遷移如何處理。資料庫連線設定的 config key 同樣不在這份材料裡。如果你的團隊已經有嚴格的 schema 變更流程，這些是你必須先去文件確認的項目，不能靠 README 推測。
LoCoMo 的 87% 與 721 tokens：讀數要連著讀
README 引用的評測結果是 LoCoMo 基準上的 87% overall accuracy，平均每查詢 721 tokens，約為全上下文做法的 2.8%。同一段還宣稱相對於 Zep 減少約 67% 的 prompt 大小，相對於全上下文提示降低超過 36 倍的成本，並稱在檢索式記憶系統中優於 Zep、LangMem 與 Mem0。論文編號是 arXiv:2603.19935。
這些數字要一起看。87% 是準確率，721 tokens 是成本，兩者相乘才是實際價值。單看準確率會低估這類系統的意義，單看 token 節省會忽略答錯的代價。
必須標明的是：這些數字來自專案方自己的評測，我沒有重跑，也無法從這份材料驗證測試設定、baseline 版本或評分方式。README 提到有 benchmark overview、results 與論文可查，要採用的人應該去讀方法論章節，特別是 LoCoMo 的資料集切分與評分標準。把它當成方向性訊號，不要當成你環境裡的預期值。
什麼時候 Memori 是錯的工具
第一個不適用的場景是無狀態推論。如果你的服務每次呼叫都獨立、不依賴歷史，接上記憶層只是多一次網路往返與一份儲存成本。
第二個是記憶策略本身就是你產品核心競爭力的情況。Memori 的價值主張是「自動」：註冊之後，抽取、持久化、召回都由函式庫在背景完成。這對想快速上線的團隊是優點，對需要精細調控檢索排序、遺忘策略、衝突解決的團隊是黑箱。你無法從 README 得知記憶如何被抽取成結構化狀態，也無法得知兩條矛盾記憶同時存在時如何裁決。
第三個是延遲預算極緊的場景。背景召回的確切時序不在這份材料中，如果每次對話都要多一次檢索往返，對即時互動應用的影響需要先量測。
還有一個非技術性的門檻：託管路徑要求你把對話送到 Memori Cloud。README 提供了 VPC 與 on-premises 選項，但那些路徑的維運成本與 BYODB 的支援範圍，都不在這份材料裡。
替代方案：自己組裝與一體化記憶層的差別
最直接的替代不是另一個記憶產品，而是自己寫。做法是把每輪對話與工具結果寫進你自己的 Postgres，需要時用向量檢索或關鍵字檢索拉回相關片段，再注入 prompt。這個做法的差別在控制權：抽取邏輯、檢索排序、保留期限、刪除政策全部由你決定，除錯時你能看到每一段輸入輸出。代價是你得自己處理結構化、去重、衝突與召回品質，這是一條長尾的工程工作。
README 點名的 Zep、LangMem、Mem0 屬於同一類一體化記憶層。差別在路線：這些系統多以檢索為核心，把歷史切塊後用相似度取回；Memori 的敘述強調把 agent 執行轉成 structured, persistent state，並宣稱在相同準確率下 prompt 足跡更小。這個差異是否成立，取決於它的結構化抽取品質，而抽取邏輯並未在 README 中展開。
如果你的團隊已經有一套運作良好的 RAG 管線，先問一個問題：既有管線能不能加上一層寫入路徑就達到同樣效果？如果可以，引入新依賴的理由會變弱。
授權、維護節奏與導入前該確認的事
授權標示有落差。README 的 badge 連到 Apache 2.0，但 GitHub 回報的 license 欄位是 NOASSERTION，意思是無法自動判定。這不代表授權有問題，但代表你不能只看 badge。採用之前，請直接讀儲存庫根目錄的 LICENSE 檔，確認它與 Apache 2.0 是否一致，以及是否附帶額外條款。這一節不是法律意見。
維護節奏方面，最近三個版本是 v3.3.6（2026-05-28）、v3.3.5（2026-05-27）、v3.3.4（2026-05-20），最後一次推送是 2026-09-03，儲存庫未封存。patch 版號密集出現在五月下旬，其後有數月沒有新版本發布。這對照出一個實務問題：如果 SDK 是攔截層，LLM provider 的 API 變動會直接影響它。升級前應該在測試環境跑一輪既有對話，確認召回行為沒有改變。
導入前的確認清單很具體。你的資料庫是否在 BYODB 支援清單內，看 docs/memori-byodb/。雲端路徑的資料落地與合規要求，看 memori-cloud 文件。召回時序對延遲的影響，用 mem.attribution 指定測試用的 entity_id 與 process_id 實測。這三件事做完，再決定要不要把正式流量接上 .llm.register。
編輯結論
Memori 適合已經在用 OpenAI 或相容 SDK、且願意把記憶放到自己資料庫的團隊，尤其是需要以 entity_id 區分終端使用者、以 process_id 區分 agent 角色的多租戶系統。若你的場景是單次無狀態推論、或你想完全掌握記憶抽取與檢索的每一段邏輯，它不適合，因為 .llm.register(client) 之後的行為由函式庫決定。導入前先確認三件事：你的資料庫是否在 BYODB 文件列出的支援清單內、Memori Cloud 的資料落地與你所在產業的合規要求是否相容、以及儲存庫根目錄的 LICENSE 檔實際內容為何。這三點沒有確認之前，先把 mem.attribution 用在測試帳號上跑一輪，再決定要不要接上正式流量。
社群筆記