memweave，由 Sachin Sharma 開發的開源 Python 函式庫，本週出現在 Towards Data Science 上，定位為「零基礎設施」的 agent 記憶體——不用 Pinecone、不用 Weaviate、不用任何托管向量資料庫。只要一個 markdown 資料夾加一個 SQLite 索引。時機很有意思：市面上大多數 agent 記憶體基礎設施都在追規模——向量儲存、圖資料庫、分散式 embedding——而大多數 agent 實際上並不需要規模。它們需要的是持久化、可審閱性，以及一個在精確匹配查詢上不掉鍊的檢索訊號。memweave 下的賭注是：預設值一直選錯了。
架構由三部分組成。資料夾裡的 markdown 檔案是真理源，人與 agent 都可讀可寫。SQLite 持有派生索引，裡面有三樣東西：FTS5 用於 BM25 關鍵字匹配，sqlite-vec 擴充套件用於 SIMD 加速的 embedding 相似度，還有一個以內容 SHA-256 為鍵的 embedding 快取——這樣重寫檔案不會觸發多餘的 API 呼叫。預設檢索是混合式的：0.7 × 向量 + 0.3 × BM25，再用 MMR 重排求多樣性。時間衰減按檔案年齡給舊記憶降權，長青檔案（無日期前綴）與日期型檔案（YYYY-MM-DD.md）按不同曲線老化。Agent 命名空間來自子目錄。README 連結了兩個可執行的 notebook——一個讀書會範例，一個會議紀錄 agent——但沒有公開基準測試，這值得點出來：這個函式庫還新，規模化未經驗證。
函式庫底下其實藏著一個關於「agent 記憶體到底需要什麼」的真實論證。大多數 agent 操作的是千級條目，不是百萬級；SQLite 加上 sqlite-vec 無需網路跳轉就能處理。BM25+向量的混合預設也大概率是對的：單用 embedding 會在精確匹配場景翻車——「我給服務 X 的 API key 是什麼」這類使用者就把字面值寫出來的情形；單用 BM25 又會在語義表達上失手。但真正值得留意的操作面優勢是另一個：跑 git diff memory/ 就能看出 agent 在兩次執行之間學到了什麼，一個 commit 一個 commit 可追。這是沒有任何向量資料庫能給你的除錯原語，也正是你凌晨三點想弄清楚「它當時為什麼那樣決定」時最想要的東西。把版本控制當作記憶體上的一等操作，而不是事後貼著資料庫匯出補上去的念頭。
這套模式就算不用這個函式庫本身也可複製。對於那些記憶體規模本質上沒到百萬級條目的 agent——就是開發者實際交付的大多數 agent——值得偷過來的範本是：把一個 markdown 資料夾當作真理源；派生出一個任何時候都能從頭重建的索引；用混合檢索而非純向量；把記憶體納入版本控制，這樣任何變動都可稽核。誠實的註腳：真到向量資料庫確實值回票價的規模——海量文件語料、帶上百萬使用者記憶體的多租戶生產——這套方案多半會崩，作者也沒有跑出失敗模式的基準。對於個人 agent、研究 agent、內部工具——這也是被打造出來的絕大多數無聊但真實的東西——這套 lo-fi 模式就是個好起點。讀一下那兩個 notebook 範例，判斷它合不合，總之把想法偷走再說。