Memmy Agent：讓多個 CLI agent 共用同一份本機記憶
🍙 A personal AI agent & local memory hub for all AI agents, gives every AI one shared, fully controlled memory and persistent context — all AI remember the same you. Now supports Claude Code, Codex, OpenClaw and Hermes Agent etc.
秒懂
- 它是什麼？
- Memmy Agent 把 Claude Code、Codex、Cursor 等工具的協作歷史寫進本機記憶服務，再透過 Skill 與 Hook 回灌給下一個工具。它解決的是換工具就斷線的問題，代價是你要接受一組常駐的 systemd user service 與自己的模型帳單。
- 適合誰用？
- 如果你同時使用兩到三種 CLI agent，而且願意讓一組 systemd --user 服務常駐在筆電上，Memmy 值得裝來試，因為它把記憶寫成可搜尋的本機服務，而不是散在各工具的私有狀態裡。如果你只需要單一 agent、或不想讓任何 daemon 常駐、或團隊政策禁止把協作歷史集中存放，那就不該採用。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
換一個 agent 就得重講一次背景，這是 Memmy 要處理的痛點
多數工程師現在不是只用一個 AI 工具。早上用 Claude Code 改後端，下午用 Codex 寫測試，週末再開 Cursor 補前端。每個工具都有自己的對話狀態與專案理解，切換的時候你要重述架構、慣例、上次改到哪裡。Memmy 的定位就是把這段重述工作抽出來，README 用三個字概括它的行為：remember、relay、react。remember 指把本機的協作歷史整理成結構化記憶，relay 指把專案背景、偏好與進度帶到下一個工具，react 指它本身也能當 agent 接手未完成的任務。
目標使用者寫得很明確：同時使用 DeepSeek Harness、OpenClaw、Hermes、Claude Code、Codex、Cursor、WorkBuddy、OpenCode、Pi 這類工具的人。反過來說，如果你的工作流只有一個 agent，Memmy 帶來的收益會小於它帶來的常駐服務成本。
記憶服務、Gateway 與 CLI 三層：資料怎麼流動
從 README 與安裝腳本可以看出三個元件。第一個是本機記憶服務，預設監聽 http://127.0.0.1:18960，由 memmy-memory CLI 存取，提供 init、health、search、add、get 這些子命令。第二個是 Gateway，由 memmy serve 啟動，提供 OpenAI 相容 API 於 :18990。第三個是 memmy 本身的 CLI 與 TUI，負責模型設定精靈、任務執行與互動介面。
關鍵在於記憶服務預設不會去改動你的 agent。安裝腳本只初始化記憶，README 明講「The installer initializes Memory without changing Codex, Claude Code, Cursor, or other agents」。要讓某個 agent 真的讀寫這份記憶，你得另外跑 memmy-memory init（全部偵測到的 agent）或 memmy-memory init --agent <agent>，它才會安裝對應的 Memory Skill 與 Hook 或 plugin。這個設計把「裝服務」和「改工具」拆成兩個明確步驟，對不信任安裝腳本的人來說是好事，代價是第一次設定要記得跑第二步，否則記憶服務會空轉。
Linux 上的安裝路徑與 systemd 使用者服務的實際行為
官方推薦桌面應用，CLI 路線則針對 Linux x64 或 arm64，前置條件是 Node.js 22 以上，以及一個可用的 systemd user session。安裝指令是：
curl -fsSL https://raw.githubusercontent.com/MemTensor/memmy-agent/main/scripts/install.sh | bash memmy
安裝器會立刻把本機記憶服務註冊成 memmy-memory.service。第一次直接執行 memmy 時，如果需要，會先開啟模型設定精靈，接著啟用 memmy-gateway.service、等待它就緒，然後進入 TUI。這兩個都是 systemd --user 服務，綁定在 localhost，TUI 或終端結束後仍然存活，之後登入也會再次啟動。README 特別註明安裝器不會啟用 linger，所以登出後服務是否持續，取決於你的系統設定。
還有一個容易被忽略的細節：只有安裝器版本的啟動器會啟用這套服務管理，自行從原始碼建置的 Linux CLI 維持原本行為。另外，每次啟動或重連 Gateway 之前，memmy 會刷新 ~/.memmy/systemd/gateway.env，權限設為 0600，內容包含設定檔引用到的環境變數、常見 Provider 憑證，以及終端的 PATH。這些值若變動，下一次執行 memmy 就會用新環境重啟使用者服務。檢查狀態用：
systemctl --user status memmy-memory.service systemctl --user status memmy-gateway.service
config.yaml 與 onboard：最小可用的設定長什麼樣
互動式設定走 memmy onboard，想直接吃預設值則用 memmy onboard --defaults，它會初始化 ~/.memmy/config.yaml 與工作區。檢查設定、模型與 provider 用 memmy status，單輪任務用 memmy agent --message "Introduce the current workspace"。README 給的最小 BYOK 設定是：
agents: defaults: model: openai/gpt-4.1 provider: openai timezone: "+08:00" providers: openai: apiKey: ${OPENAI_API_KEY}
這裡有兩件事值得注意。model 欄位用的是 provider/model 這種帶斜線的寫法，provider 區塊的鍵名必須跟它對應，寫錯的話 memmy status 是最快的驗證點。apiKey 用 ${OPENAI_API_KEY} 這種環境變數展開，而不是直接寫明文，這與前面提到的 gateway.env 刷新機制是同一套思路：憑證留在環境裡，設定檔只放引用。
試用方面，README 說明註冊會拿到 agent 任務的試用額度，餘額與用量顯示在應用程式內，額度用完就切到 BYOK 模式用自己的模型 API。它沒有公布任何具體的免費額度數字，所以不要預期一個固定值。
從原始碼建置，以及記憶服務的獨立用法
想自己編譯的話，README 給的流程是：
git clone https://github.com/MemTensor/memmy-agent.git cd memmy-agent cp .env.example .env npm install npm run build bash scripts/dev-start.sh
README 在 dev-start.sh 的說明處被截斷，所以腳本後續做了什麼無法從現有材料確認。這點在評估時要自己看過腳本再跑。
如果你只想用記憶層、不需要 TUI，可以單獨操作 memmy-memory：
memmy-memory init memmy-memory health memmy-memory search "memory policies in this project" memmy-memory add "a piece of knowledge worth saving" memmy-memory get <id>
它預設連到 http://127.0.0.1:18960，並提供 --url、--token、--config、--source、--user-id 來指定服務位址與命名空間。--user-id 與 --source 的存在意味著記憶可以按使用者與來源分區，這對一台機器上跑多個 agent 的情境是必要的，否則各工具的紀錄會混在一起。
真正的限制：常駐服務、Linux 優先與被截斷的文件
第一個限制是平台。CLI 與 TUI 的安裝說明明確寫 Linux x64 或 arm64，並且需要 systemd user session。macOS 與 Windows 使用者在這條路線上沒有對應說明，官方推薦的是桌面應用，那是另一套安裝方式。第二個限制是常駐性：兩個 systemd --user 服務綁在 localhost，TUI 關掉還在跑，而且安裝器不啟用 linger，行為會隨登入狀態改變。對不想在筆電上長期掛 daemon 的人來說，這是需要主動管理的東西，不是裝完就忘的工具。
第三個限制來自文件本身。README 在 scripts/dev-start.sh 的描述處中斷，Getting Started 的完整內容指向 docs/en/start/getting-started.mdx，不在這份材料裡。記憶的檢索策略、儲存格式、容量上限、多使用者隔離的實作細節，都無法從現有文字確認。在這種情況下，把它接進重要工作流之前，最好先跑 memmy-memory health 與幾次 search，確認它在你自己的資料上召回得準不準。
第四個是成本歸屬。試用額度用完後你要自備模型 API key，也就是說記憶服務本身是本機的，但推理成本落在你的 provider 帳單上，這一點在評估總持有成本時不能漏算。
跟直接寫 CLAUDE.md 或 AGENTS.md 的差別在哪
最直覺的替代方案是在專案裡放一份 CLAUDE.md 或 AGENTS.md，把背景與慣例寫成靜態文件讓每個 agent 讀。這個做法零依賴、可進版控、review 時看得到 diff。差別在於它是靜態且全量的：每次都要整份讀進 context，內容會隨時間膨脹，而且它記的是「你預先寫下的規則」，不是「你實際做過的事」。
Memmy 走的是另一條路。它把協作歷史轉成可搜尋的結構化記憶，需要時用 memmy-memory search 撈出相關片段，而不是每次塞整份文件。代價是你多了一個服務、一個儲存層，以及一個需要維護的檢索品質問題。兩者不是互斥的：把穩定不變的規範留在 AGENTS.md，把會變動的專案進度與決策交給 Memmy，是比較務實的分工。如果你的需求只是「讓 agent 知道這個 repo 用 pnpm 不用 npm」，靜態文件就夠了，不需要引入常駐服務。
授權、維護成本與升級時要看的地方
專案採 MIT 授權，預設分支為 main，主要語言是 TypeScript。MIT 允許商用與修改，但要保留著作權聲明；這裡不構成法律意見，若你要把它嵌進內部平台或對外產品，還是走一次法務確認。
維護節奏方面，從 release 列表看，v1.1.2 到 v1.1.4 集中在 2026 年 9 月的幾天內，屬於密集修補期。這代表介面與行為可能還在動，升級前值得先看 release notes，尤其是涉及 ~/.memmy/config.yaml 結構與 gateway.env 產生邏輯的變更，因為那兩處一改，你既有環境就得跟著調。
升級的實際成本主要落在兩件事：一是 systemd 服務需要重啟才會吃到新版本，二是記憶服務的資料在升級後是否仍可讀。README 沒有描述資料遷移流程，所以升級前先備份記憶服務的資料目錄是合理的自保動作。日常維運則靠兩個指令就夠：memmy status 看設定與 provider，memmy-memory health 看記憶服務本身是否正常。
編輯結論
如果你同時使用兩到三種 CLI agent，而且願意讓一組 systemd --user 服務常駐在筆電上，Memmy 值得裝來試，因為它把記憶寫成可搜尋的本機服務，而不是散在各工具的私有狀態裡。如果你只需要單一 agent、或不想讓任何 daemon 常駐、或團隊政策禁止把協作歷史集中存放，那就不該採用。動手前先確認三件事：Node.js 是否為 22 以上、systemd user session 是否可用、以及試用額度用完後你要接哪一家的 API key，因為那會直接決定 ~/.memmy/config.yaml 裡 providers 區塊怎麼寫。
社群筆記