給14個AI Agent裝上共享記憶：MemOS踩坑實錄

我們有15個 Agent 在跑，每個都是孤島——同一件事各自記了一遍，或者完全沒記。問一個 Agent 上週發生了什麼，它一臉空白。這個問題拖了很久，直到我們把 memos-local-openclaw-plugin 接上去。

這篇是接入過程的完整踩坑記錄，三個 bug，每個都不算小。

為什麼要做共享記憶

當你有一個 Agent 的時候，記憶問題不明顯，上下文撐得住。但我們有14個。每個 Agent 負責不同的職能：內容、程式碼、部署、設計、SEO、社群……它們之間沒有共享狀態，每次召喚都是全新的。

真正讓我們下定決心做這件事的是一次具體事故：小蜜蜂在某台伺服器上部署了一個服務，但這件事沒有任何地方記錄。兩週後，另一個 Agent 被問到那台伺服器的狀態，回答說不知道。問小蜜蜂，它也忘了。

答案其實在，只是沒有地方存。

這是我們選的方案。本地執行，基於 SQLite，透過 OpenClaw plugin 介面暴露給所有 Agent。設計思路是：每個 Agent 都能讀寫同一個記憶資料庫，透過標籤和時間戳來管理和檢索記憶片段。

接上之後跑了兩天就開始出現隨機的寫入失敗。日誌顯示 database is locked。

根因是：多個 Agent 同時在寫記憶，SQLite 的 WAL 模式沒有開啟，預設的 journal mode 在並發寫入時會卡死。

解決：在初始化時加 PRAGMA journal_mode=WAL，問題消失。

發現 Agent 在讀記憶時，有時會優先拿到很舊的記錄，而不是最近的。

追查發現 plugin 的檢索邏輯是純向量相似度排序，沒有加時間衰減權重。語義相近的舊記憶會排在新記憶前面。

解決：在相似度分數上乘以時間衰減係數 score * exp(-lambda * days_ago)，lambda=0.1效果不錯。

不同 Agent 用了相同的標籤來記事，導致一個 Agent 的記憶被另一個 Agent 撈到。比如小蜜蜂和小章魚都用了 #deployment 標籤，但內容完全不同。

解決：在每條記憶記錄上強制加 agent_id 欄位，檢索時預設只查自己的記憶，除非明確要求跨Agent查詢。

跑了三週，共享記憶已經累積了2000多條記錄。最明顯的改善是：交接任務時不再需要重新說明背景，Agent能自己查到上次的進度。

還有一個意外收穫：有了共享記憶，我們發現了幾個以前沒注意到的重複工作——兩個 Agent 各自在做同一件事，只是沒有溝通過。