大模型雖然功能強大，但其輸入長度（即上下文窗口）始終存在限制，這意味著它們在會話過程中無法記住所有交互內容。如果我們能為模型構建一個獨立、可移植的“記憶層”，作為其長期記憶的補充，并且這一層運行于本地、由用戶完全掌控數據，是否會讓 AI 的使用更高效、更安全？
OpenMemory MCP 正是這樣一種嘗試。它基于 Mem0（專為 AI Agent 設計的記憶系統）構建，是一個私有的、以本地優先為核心的 LLM 記憶層。通過 OpenMemory MCP，用戶可以在各種支持 MCP 協議的客戶端之間（如 Cursor、Claude Desktop、Windsurf、Cline 等），實現持久化、上下文感知的 AI 交互體驗。這不僅增強了 AI 的連貫性與個性化能力，也為數據隱私和控制權提供了更強保障。
一、什么是 OpenMemory？
OpenMemory MCP 是一個面向 MCP 客戶端的私有、本地優先的內存層，旨在為 AI 提供持久化的記憶能力。它提供了一套完整的基礎設施，用于存儲、管理和利用 AI 生成的記憶數據，并確保所有信息始終保留在本地系統中，不對外泄露。簡而言之，它就像一個基于標準 MCP 協議構建的向量支持型存儲層，專為 LLM 客戶端設計，并且可以與 Mem0 等工具無縫集成、開箱即用。
其核心能力包括：
- 跨會話記憶存儲支持任意文本塊的長期保存與調用，使 AI 在每次交互中都能“記住”之前的內容，無需從零開始。
- 智能檢索機制借助 Qdrant 向量數據庫，實現基于語義相關性的高效檢索，超越傳統關鍵字匹配的限制。
- 完全本地部署整個系統基于 Docker、PostgreSQL 和 Qdrant 構建，所有數據均在本地處理和存儲，不會向外發送任何信息，保障隱私安全。
- 精細訪問控制可在客戶端或內存級別隨時暫停或撤銷訪問權限，同時記錄每一次讀寫操作的審計日志，提升透明度與安全性。
- 可視化管理界面配套提供基于 Next.js 與 Redux 構建的儀表盤，實時展示誰在訪問內存、進行了哪些更改，便于監控與追蹤。
在實際使用中，用戶只需通過一個 docker-compose 命令即可啟動整個 OpenMemory 系統，包括 API 服務、Qdrant 向量數據庫和 Postgres 數據存儲。其中，API 進程托管了一個基于 Mem0 實現的 MCP 服務器，并通過 SSE（Server-Sent Events）協議提供符合標準的 MCP 接口。
當 LLM 客戶端連接到 OpenMemory 的 /mcp/... 接口時，會建立一條 SSE 流式通信通道，并調用如 add_memories()、search_memory() 或 list_memories() 等方法來操作記憶內容。而其余諸如向量索引管理、訪問控制和審計日志記錄等復雜任務，則全部由 OpenMemory 服務自動完成，極大簡化了開發者的集成負擔。
penMemory MCP 為構建具備持久上下文感知能力的 AI 應用提供了一個安全、可控、可擴展的本地化解決方案。更多細節和演示視頻可參考官方頁面 mem0.ai/openmemory-mcp。
二、設置和運行 OpenMemory MCP指南
該項目由兩個核心組件組成，需同時運行以實現完整功能：
api/ 目錄：這是系統的后端部分，集成了 API 服務和 MCP 服務器。它負責處理客戶端請求、管理記憶數據的存儲與檢索，并通過標準的 MCP 協議與其他 AI 工具和服務進行通信。整個后端采用 Docker 容器化部署，結合 PostgreSQL 和 Qdrant 向量數據庫，確保高效的數據處理與本地化存儲。
ui/ 目錄：這是一個基于 React 構建的前端應用，作為用戶交互的核心界面，提供直觀的可視化儀表盤。通過該界面，用戶可以實時查看內存訪問情況、操作記錄以及各客戶端的狀態變化，同時還可對權限設置、審計日志等進行管理，大大提升了系統的可觀測性與可控性。
這兩個組件協同工作，共同構建了一個具備持久記憶能力、上下文感知且安全可控的 AI 助手平臺。
2.1. 系統先決條件
在開始之前，請確保系統安裝了以下內容：
- Docker 和 Docker Compose
- Python 3.9 + ーー后端開發所需
- Node.js — 前端開發所需
- OpenAI API Key ー用于 LLM 交互
- GNU Make 是一個組建自動化工具，將在安裝過程中使用它。
在進行下一步之前，請確保 docker desktop 正在運行。
2.2. 克隆repo并設置 OpenAI API 密鑰
使用以下命令克隆 github.com/mem0ai/mem0 可用的repo。
git clone <https://github.com/mem0ai/mem0.git>
cd openmemory接下來，將 OpenAI API 密鑰設置為環境變量。
export OPENAI_API_KEY=your_api_key_here此命令僅為當前終端會話設置密鑰，只持續到關閉該終端窗口為止。
2.3.設置后端
后端在 Docker 容器中運行。要啟動后端，請在根目錄中運行以下命令：
# Copy the environment file and edit the file to update OPENAI_API_KEY and other secrets
make env
# Build all Docker images
make build
# Start Postgres, Qdrant, FastAPI/MCP server
make up其中，.env.local文件將具有以下約定。
OPENAI_API_KEY=your_api_key一旦設置完成，API 將在 http://localhost:8000 上線，還應該看到在 docker desktop 中運行的容器。
下面是一些可以使用的其他后端命令：
# Run database migrations
make migrate
# View logs
make logs
# Open a shell in the API container
make shell
# Run tests
make test
# Stop the services
make down2.4.設置前端
前端是一個 Next.js 應用程序：
# 使用 pnpm 安裝依賴項并運行 Next.js 開發服務器
make ui安裝成功后，可以導航到 http://localhost:3000 檢查 OpenMemory 儀表盤，在 MCP 客戶端安裝 MCP 服務器。
MCP 客戶端打開 GET /mcp/{client_name}/sse/{user_id}的 SSE 通道，該通道連接兩個上下文變量 (user_id、 client_name)。在儀表盤上，可以找到一行命令，根據所選擇的客戶端 (如 Cursor、 Claude、 Cline等) 安裝 MCP 服務器。
在 Cursor 中安裝命令如下所示：
npx install-mcp i https://mcp.openmemory.ai/xyz_id/sse --client cursor打開Cursor設置并檢查側欄中的 MCP 選項以驗證連接。
在 Cursor 中打開一個新的聊天，并給出一個示例的提示詞，這將觸發 add_memories()調用并存儲內存。刷新儀表盤并轉到 Memories 選項卡來檢查所有這些記憶的內容。類別是為內存自動創建的，類似于可選的標記 (通過 GPT-4o 分類)。
每個 MCP 客戶端可以 “調用” 四個標準操作之一：
add_memories(text)→ 在 Qdrant 存儲文本，插入 / 更新記憶行和審計條目search_memory(query)→嵌入查詢，使用可選的 ACL 過濾器運行向量搜索，記錄每次訪問list_memories()→ 檢索用戶存儲的所有向量 (通過 ACL 過濾) 并記錄清單delete_all_memories(): 清除所有內存記憶
所有響應都通過相同的 SSE 連接流，儀表盤顯示所有活動的連接，以及哪些應用程序正在訪問內存和讀 / 寫的詳細信息。
三、儀表盤中可用的特性
OpenMemory 控制面板包括三個主要路徑：
- /–dashboard/- 儀表盤
- /memories – 查看和管理存儲的記憶內容
- /apps – 查看連接的應用程序
簡而言之，查看儀表盤中的所有可用特性可以了解基本概念。
下面是一些重要的前端組件：
- ui/app/memories/components/MemoryFilters.tsx : 處理搜索輸入、過濾器對話框觸發器、諸如 archive/pause/delete 之類的批量操作，還管理行的選擇狀態。
- ui/app/memories/components/MemoriesSection.tsx : 加載、分頁和顯示內存列表的主容器。
- ui/app/memories/components/MemoryTable.tsx – 呈現實際的內存表 (ID、內容、客戶端、標記、創建日期、狀態)。通過 MemoryActions (編輯、刪除、復制鏈接) ，每一行都有自己的操作。
對于狀態管理和 API 調用，它使用干凈的鉤子：
- useStats.ts : 加載高級統計數據，比如總內存和應用程序數量。
- useMemoriesApi.ts : 處理獲取、刪除和更新內存。
- useAppsApi.ts : 檢索應用程序信息和每個應用程序的內存細節。
- useFiltersApi.ts : 支持獲取類別和更新篩選器狀態。
總之，這些部分創建了一個響應，實時儀表盤，控制AI內存層的每一個方面。
四、安全、訪問控制和架構
在使用 MCP 協議或任何 AI Agent 系統時，安全性已不再是可選項，而是必須優先考慮的核心要素。OpenMemory 正是基于“隱私優先”的設計理念構建而成，確保所有記憶數據始終保留在本地基礎設施中，不向外部泄露。
該系統依賴一系列容器化組件（如 FastAPI、PostgreSQL 和 Qdrant）運行，所有記憶內容都存儲在本地環境中。為防止常見的安全威脅，例如注入攻擊，敏感輸入通過 SQLAlchemy 進行參數化綁定處理，確保數據操作的安全性。同時，每一次內存的添加、檢索或狀態變更都會被詳細記錄在 MemoryStatusHistory 和 MemoryAccessLog 表中，實現完整的審計追蹤能力。
盡管身份驗證機制并未直接內置，但所有 API 接口均要求提供 user_id，并通過外部認證網關（如 OAuth 或 JWT）進行保護。開發環境下，FastAPI 的 CORS 設置對本地調試完全開放（allow_origins = ["*"]），但在生產部署時應限制訪問來源，以增強安全性。
4.1 細粒度訪問控制：安全與靈活性并重
OpenMemory 的一大核心優勢在于其細粒度的訪問控制機制。系統通過 access_controls 表定義應用程序與特定記憶之間的允許/拒絕規則，并由 check_memory_access_permissions函數執行權限判斷。這一函數會綜合考量多個因素，包括當前記憶的狀態（如活動、暫停）、應用是否啟用，以及具體的 ACL 規則配置。
這意味著你可以靈活地控制訪問權限——例如，暫停某個應用程序的寫入功能，歸檔或臨時禁用某條記憶內容，甚至根據用戶或類別設置過濾策略。對于處于暫停或非活動狀態的記憶條目，它們將對工具調用和搜索接口不可見，從而有效防止未授權訪問。這種分層式的訪問模型，使得系統可以在應用、用戶、記憶等多個維度上實現精準控制。
4.2 技術棧詳解
為了更好地理解 OpenMemory 的運作方式，我們可以從其代碼庫出發，深入了解其系統架構：
1. 后端服務（FastAPI + FastMCP over SSE）
后端采用 FastAPI 構建，公開了標準 REST 接口（如 /api/v1/memories、/api/v1/apps、/api/v1/stats），同時也提供了基于 MCP 協議的“工具”接口（如 /mcp/messages、/mcp/sse/<client>/<user>），供 AI Agent 通過 SSE 流式連接調用相關方法（如 add_memories()、search_memory()、list_memories()）。這些接口連接至 PostgreSQL 用于管理結構化元數據，并與 Qdrant 集成以支持語義級向量搜索。
2. 向量存儲（Qdrant via mem0 客戶端）
所有記憶內容都會在 Qdrant 中建立語義索引，支持高效的相似性檢索。查詢時，系統會自動應用針對用戶和應用程序的過濾器，確保返回結果的準確性和權限合規性。
3. 關系型元數據管理（SQLAlchemy + Alembic）
通過 SQLAlchemy ORM 和 Alembic 數據遷移框架，系統維護了用戶、應用、記憶條目、訪問日志、分類標簽及訪問控制等關鍵信息。默認使用 SQLite（文件為 openmemory.db），但也支持切換為 Postgres，以適應更復雜的應用場景。
4. 前端儀表盤（Next.js）
前端采用 Next.js 框架構建，結合 Redux 實現全局狀態管理，利用 Hooks 和 Axios 與后端 API 進行通信。界面中集成了 Recharts 圖表庫、React Hook Form 表單組件以及輪播圖等 UI 元素，幫助用戶直觀查看記憶內容、訪問記錄及系統狀態變化，實現真正的“可觀測性”。
5. 基礎設施與開發流程
整個系統通過 docker-compose.yml 文件統一編排，包含 Qdrant 向量數據庫和 API 服務。同時，項目還提供 Makefile 腳本，簡化了遷移、測試和熱重載等常見操作。后端邏輯與測試代碼共存，便于持續集成與質量保障。
OpenMemory 提供了一個完整、自托管的 LLM 記憶管理系統，具備以下核心能力：
- 在關系數據庫與向量索引中持久化、版本化聊天記憶內容；
- 基于每個應用的 ACL 和狀態控制（活動 / 暫停 / 歸檔）實現精細化權限管理；
- 利用 Qdrant 支持高效語義搜索；
- 通過豐富的 Next.js 儀表盤實現可視化監控與交互。
無論你是希望為 AI Agent 添加長期記憶能力，還是尋求一個符合企業級安全與合規要求的記憶解決方案，OpenMemory 都是一個值得深入探索的選擇。
五、應用示例
OpenMemory可以用于AI交互中的任何地方。
5.1 示例1: 具有內存層的多智能體研究助理
設想構建一個工具，其中不同的 LLM Agent 分別專注于特定的研究領域，例如：一個Agent專門處理學術論文，另一個負責分析GitHub倉庫，還有一個專注于新聞報道。每個子Agent通過 add_memories(text) 方法將從其專注領域檢索到的數據摘要添加到共享的記憶庫OpenMemory中，并使用自動分類（如GPT模型）對這些記憶內容進行標記，以便于后續檢索和管理。
主Agent則充當協調者角色，它通過打開一個SSE（Server-Sent Events）通道與OpenMemory交互，并利用 search_memory(query) 方法查詢所有先前由子Agent存儲的相關上下文信息。這種架構不僅使得跨領域的知識整合成為可能，同時也確保了數據的連貫性和一致性。
此外，該系統還配備了一個儀表盤界面，用于展示各個Agent存儲的具體內容，并允許管理員基于ACL（訪問控制列表）限制不同Agent之間的內存訪問權限。這一步驟對于維護系統的安全性及數據隱私至關重要。
為了進一步增強系統的功能性和透明度，我們可以引入一個名為LangGraph的編排層。在這個框架下，每個Agent都被視為網絡中的一個節點，能夠追蹤隨時間變化的內存讀寫操作。這樣一來，不僅可以可視化知識流的動態過程，還能清晰地識別出信息來源及其演變路徑，從而為每一個研究線索提供詳細的背景支持。這種方法極大地促進了跨學科研究的合作效率，同時也為深入挖掘和理解復雜問題提供了有力的技術支撐。通過這種方式，我們不僅實現了高效的AI協作，還為未來的研究工作奠定了堅實的基礎。
5.2 示例2：具有持久跨會話內存的智能會議助理
我們可以創建一個類似于Zoom會議筆記記錄器的系統，該系統不僅能通過LLM自動提取會議摘要，還能記住每次會議中的操作項，并在未來會議中自動檢索相關的上下文信息。
在每次會議結束后，系統會調用 add_memories(text) 方法將會議內容及其摘要添加到記憶庫中。這些記憶內容會被適當分類并標記，以便于后續檢索和管理。例如，在下一次會議開始之前，系統可以運行 search_memory("open items for Project X") 來獲取與項目X相關的未解決問題或待辦事項，確保團隊能夠迅速回顧并跟進相關議題。
為了增強系統的透明度和可追溯性，所有被標記的記憶內容不僅會在用戶界面（UI）中顯示，還會記錄在審計日志中，詳細追蹤哪些內存被讀取以及何時被讀取。這有助于維護數據的完整性和安全性，同時也方便用戶隨時查閱歷史記錄。
此外，該系統還可以與多種工具集成，如Google Drive、Notion和GitHub等，使得存儲的操作條目可以直接鏈接到實時文檔和任務。這樣一來，團隊成員可以在熟悉的平臺上直接訪問會議紀要和行動項，極大地提高了工作效率和協作便利性。
通過這種設計，我們不僅實現了高效、智能的會議記錄和管理，還為跨平臺的數據同步和任務跟蹤提供了強有力的支持，確保每個團隊成員都能及時獲取所需的信息，推動項目的順利進行。這一解決方案特別適合需要頻繁開會討論并跟蹤進展的企業和組織使用。
