企業級 AI Agent 共享記憶層：架構設計與開源專案盤點
這個構想本質上是要建立一個「企業知識圖譜 + 向量記憶庫」的中介層，讓多個 AI Agent（無論是寫 Email、開會記錄，或是產品開發場景）都能讀寫同一份公司知識。目前業界已有多個開源專案在做類似的事，可以作為架構參考或直接整合使用，不需要完全從零打造。
系統架構的核心組成
一個可行的架構通常會拆成四層：擷取層、標準化層、儲存層、服務層。擷取層對應你提到的 local Claude Code Agent，負責從 Email、會議記錄、Slides 中萃取結構化知識；標準化層將萃取結果轉換成統一格式（例如 entity-relation-observation 的知識圖譜結構，或是帶 metadata 的文字片段）；儲存層則是向量資料庫加上關聯式資料庫的混合儲存，向量負責語意搜尋，關聯式資料庫負責溯源與權限控管；服務層則透過 MCP 或 REST API 對外暴露讀寫介面，供所有 Agent 呼叫。
值得注意的是，多數現有 MCP Memory 專案（如 modelcontextprotocol 官方的 memory server）預設是「知識圖譜」模式，用 entities、relations、observations 三種物件描述知識，這種結構特別適合企業知識，因為可以清楚標註「這個決策是誰在哪次會議提出的」，具備溯源能力。
現成開源專案盤點
以下是目前 GitHub 上與你構想高度相關的開源專案，涵蓋從單純的 MCP 記憶伺服器到完整的企業級記憶平台：
| 專案名稱 | 定位與特色 |
|---|---|
| mem0ai/mem0 | 目前最主流的「通用 AI 記憶層」，支援多用戶、多 Agent 共享記憶，具備自我優化（self-improving）機制，也有企業版提供 audit log 與 workspace 治理。 |
| getzep/zep | 建立「時間性知識圖譜（temporal knowledge graph）」，能追蹤事實隨時間的變化，適合企業決策這種會隨時間更新的知識。 |
| modelcontextprotocol/servers | MCP 官方參考實作的 Memory Server，用知識圖譜（entities/relations/observations）儲存記憶，是理解 MCP 記憶協定最好的起點。 |
| doobidoo/mcp-memory-service | 支援多客戶端（Claude Desktop、VS Code 等 13+ 種 AI 應用）共用同一組語意記憶，具備自主整併記憶的機制，架構上很接近「全公司共享」的需求。 |
| MehulG/memX | 專為「多 Agent 系統」設計的即時共享記憶層，支援 CRDT 式狀態同步、Pub/Sub 更新、JSON Schema 驗證，適合多個 Agent 同時協作寫入的場景。 |
| sdimitrov/mcp-memory | 用 PostgreSQL + pgvector 實作，提供 RESTful API，適合想要自建、資料完全掌控在自家主機的方案。 |
| alioshr/memory-bank-mcp | 支援「遠端」記憶庫管理，概念上就是把記憶從 local 搬到共用伺服器，跟你想解決的痛點（Obsidian/CloudMate 只能 local）直接對應。 |
其中 mem0 和 zep 都提供「Cloud 版」與「開源自架版」兩種模式，如果不想維運基礎設施，也可以先用雲端版驗證流程，之後再考慮是否遷移到自架的 PostgreSQL/pgvector 方案。
落地時建議先想清楚的問題
在動手畫架構圖之前，有幾個維度會直接決定技術選型：
- 知識更新頻率與版本控管：公司知識會不斷修正（例如產品策略調整），是否需要像 Zep 那樣的「時間性」記憶，能區分「舊事實」和「新事實」而不是互相覆蓋。
- 權限與隔離範圍：不同部門的敏感知識（例如財務、HR）是否需要記憶隔離，而不是全公司無差別共享，這會影響儲存層要不要做 namespace 或 row-level 權限設計。
- 擷取自動化程度：Local Claude Code Agent 擷取知識後，是全自動上傳，還是需要人工審核再入庫，避免錯誤或敏感資訊污染共享記憶庫。
- 主機自架 vs 用現成雲服務：是否有資料落地台灣或內網隔離的合規要求，這會決定你是選 mem0/zep 的雲端 API，還是必須用 pgvector 自架方案。
這幾點裡，知識更新與版本控管這件事會最大程度決定你要選「知識圖譜型」（zep、MCP 官方 memory server）還是「向量記憶型」（mem0）架構，因為兩者在「同一件事情被多次提及、內容互相矛盾」時的處理邏輯完全不同。
你們公司內部的知識，多數情況下屬於「一次性紀錄很少更動」，還是「同一主題會被反覆修正、版本迭代」的類型？