AI Agent 記憶架構實戰指南：三條路徑，選對你的記憶方案

你的 AI agent 每次重啟都失憶嗎？換台電腦就得重新解釋一遍專案背景？這不是你的問題，是記憶架構的問題。2026 年 Q1，OSS Insight 報告顯示 agent memory 相關的開源專案累積超過 80,000 顆星，代表整個社群都在找答案。這篇文章幫你從 solo dev、startup 到企業部署，找到最適合你的 agent 記憶方案。

TL;DR

• Solo dev：Hmem 或 Engram，5 分鐘設定，SQLite 儲存，月費 $0，記憶量 <10 萬筆完全夠用
• Startup：Mem0 的分層記憶架構可省 90% token 成本（Mem0 自家 arXiv 論文 vs LOCOMO 資料集，非中立第三方測試），SQLite + 向量 DB hybrid 架構應對用戶增長
• Enterprise：agent-recall 的 scope-chain 架構實現專案級記憶隔離，Markdown-as-source-of-truth 讓稽核成為可能
• SQLite+FTS5 在 4,300 筆記憶的查詢速度 < 1ms，Pinecone p95 約 25-50ms（開發者社群獨立測試，非同一環境控制對比）——大多數 indie 專案不需要向量資料庫

注意：Mem0 論文中的 90% token 節省與 91% p95 延遲降低數據為論文自述結果，實際效果取決於你的使用情境與記憶量。

你不需要向量資料庫：SQLite 在多數 indie 場景下同時贏在速度與成本

「做 agent memory 就要用向量資料庫」是 2026 年最普遍的認知偏差。

根據多位開發者在 Dev.to 和獨立技術部落格發布的基準測試回報，當記憶量在數萬筆以內，SQLite+FTS5 的全文搜尋速度遠勝雲端向量 DB。SQLite+FTS5 在 4,300 筆記憶的 recall 速度低於 1 毫秒；同等規模下，Pinecone 的 p95 延遲約 25-50ms，Weaviate 約 8-35ms，Chroma 約 4-60ms（各項數據來自不同測試環境，非同一機器同一資料集的控制對比；實際延遲隨向量量級變化）。

成本差異更明顯：SQLite 是免費的本地檔案，Pinecone 付費方案最低月費 $50 起（含最低用量承諾，截至 2026 年 Q1；定價隨時可能調整）。對一個 side project 來說，這個價差足以決定選型方向。

但這不代表向量資料庫沒有價值。當你的查詢類型以語意相似度匹配為主（例如「找出跟這段描述最相關的記憶」），或記憶量超過 10 萬筆需要高維度索引時，向量資料庫確實是更好的選擇。關鍵是：先搞清楚你的查詢模式，再決定架構。

你是哪種 Agent 開發者？三條路徑，三種記憶架構

記憶架構的選型不是技術問題，是商業決策。你的用戶規模、隱私要求和預算限制決定了你該走哪條路：

維度	Solo Dev	Startup	Enterprise
用戶規模	1 人（自己）	10-1,000 用戶	內部團隊，多 agent
月預算	< $50	$50-500	不是主要考量
隱私要求	低	中（GDPR）	高（完全 on-prem）
推薦架構	SQLite MCP	Hybrid（SQLite + 向量 DB）	SQLite + scope-chain + local embedding
代表工具	Hmem、Engram	Mem0、LangGraph	agent-recall、Engram

接下來三個章節分別展開每條路徑的具體實作。

Solo 路徑：5 分鐘用 Hmem 或 Engram 幫 Claude Code 加上跨 session 記憶

如果你是一個人做 side project，用 Claude Code 或 Cursor 開發，你的第一需求就是：讓 agent 記住上次的對話。不需要 Docker，不需要 Python 環境，不需要申請任何 API key。

Hmem：分層記憶，啟動只載入 20 tokens

Hmem 是一個 MCP server，用 5 層階層式結構儲存記憶在本地 SQLite 檔案（.hmem）中。Agent 啟動時只載入 L1 摘要（300 筆記憶約消耗 5k tokens，每筆約 17 tokens），需要時才逐層展開到完整記憶。

設定步驟（詳細說明見 Hmem GitHub）：

1. 從 GitHub releases 頁面下載 Hmem 並執行互動式安裝程式
2. 安裝程式會自動偵測你的 AI 工具（Claude Code、Cursor、Windsurf 等）
3. 選擇系統級安裝（記憶存在 ~/.hmem/）或專案級安裝（記憶存在當前目錄）

同一個 .hmem 檔案可以在 Claude Code、Cursor、Windsurf、Gemini CLI、OpenCode 之間共享，換工具不會丟失記憶。

Engram：Go 單一執行檔，sub-millisecond recall

Engram 走另一條極簡路線：一個 Go binary + 一個 SQLite 檔案，沒有任何外部依賴。它用 FTS5 全文搜尋取代向量匹配，查詢速度在 sub-millisecond 等級。詳細安裝說明見 Engram GitHub，從 releases 頁面下載對應平台的 binary 即可。

Engram 支援 CLI、HTTP API、MCP server 和 TUI 四種介面，所有資料存在 ~/.engram/engram.db。Agent 透過 mem_save 儲存記憶（包含標題、類型、What/Why/Where/Learned 結構），下次 session 透過搜尋取回相關 context。

什麼時候 Hmem 夠用？什麼時候選 Engram？

• 只用 Claude Code 做個人 agent：Hmem 是更直接的選擇，互動式安裝程式自動完成 MCP config，不需要手動設定
• 如果你需要在多個 AI 工具間共享記憶，Hmem 的跨工具 .hmem 檔案更方便
• 如果你偏好零依賴部署且需要 HTTP API 或 TUI 介面，Engram 的 Go binary 更適合
• 兩者都不需要 embedding model，都用 SQLite 本地儲存，月費都是 $0

記憶架構 101：四種記憶類型與對應的儲存模式

在選工具之前，先理解 agent 記憶的四種類型。這套分類法來自 LangChain 官方文件與 LangMem SDK，是目前社群最廣泛接受的框架：

記憶類型	說明	適合的儲存方式	工具範例
Working Memory	當前對話的 context window	LLM 原生 context	不需額外工具
Episodic Memory	過去的對話歷史、事件紀錄	SQLite / checkpointer	Hmem、LangGraph
Semantic Memory	知識庫、事實、概念	向量搜尋 / FTS5	Engram、Chroma、Pinecone
Procedural Memory	操作模式、SOP、learned patterns	Markdown 文件 / 規則檔	CLAUDE.md、agent-recall

大多數 indie maker 最需要的是 episodic memory（讓 agent 記住「我們上次討論了什麼」）和 procedural memory（讓 agent 記住「這個專案的 coding style 是什麼」）。如果你的需求僅限於此，SQLite MCP 就足夠了，完全不需要向量資料庫。

只有當你需要從大量非結構化知識中做語意搜尋（semantic memory），例如「找出所有跟 React Server Components 相關的記憶」，向量 embedding 才變得必要。

Startup 路徑：Hybrid 架構 + Mem0，服務 1,000 用戶還能控制 token 成本

當你的產品需要服務 10 到 1,000 個用戶，每個用戶都有自己的對話歷史和偏好，純 SQLite 方案會遇到兩個瓶頸：

1. Token 成本爆炸：naive 做法是把所有記憶塞進 prompt，1,000 用戶 x 平均 500 筆記憶 = 每次請求消耗大量 tokens
2. 跨用戶語意搜尋：FTS5 的關鍵字匹配在模糊查詢場景下不如向量搜尋

Mem0 的分層記憶策略

Mem0 的 arXiv 論文（ECAI 2025）提出了一套解決方案：動態萃取、整合並檢索對話中的重要資訊，而非全量注入。論文自述的基準測試結果顯示，相比 naive 全量記憶注入，Mem0 可降低 91% 的 p95 延遲並節省超過 90% 的 token 成本。

重要：這些數據來自 Mem0 團隊的論文自述，使用 LOCOMO 標準化資料集測試。實際效果取決於你的對話長度、記憶量與查詢模式。

Hybrid 架構的實作建議

對 startup 來說，我建議的架構是：

• Episodic layer：用 SQLite（或 PostgreSQL）儲存精確的對話歷史和用戶偏好，支援精確查詢（「這個用戶上次的訂單是什麼？」）
• Semantic layer：用向量 DB（Chroma 自建或 Pinecone 託管）處理語意搜尋（「找出這個用戶可能感興趣的話題」）
• Hierarchical loading：仿照 Hmem 的分層策略，startup 時載入摘要，需要時才 drill down

Mem0 提供 managed service 選項，如果你不想自建 hybrid 架構，可以直接使用。但要注意：managed service 的定價隨用量變動，早期可能划算，規模增長後需要重新評估成本。

從 SQLite 升級到 Hybrid 的門檻

根據社群回報與工具文件，以下是建議的升級時機：

• 記憶總量超過 10 萬筆
• 需要跨用戶的語意相似度搜尋
• 單次查詢的 FTS5 結果不夠精準（召回率下降）
• 需要服務多個並發用戶（SQLite 的寫鎖會成為瓶頸）

Enterprise 路徑：全 On-Prem + agent-recall scope-chain，記憶完全可稽核

企業環境有三個 solo dev 通常不用擔心的需求：資安合規（資料不能傳到外部雲端）、資料隔離（不同專案的記憶不能混用）、可稽核性（能回答「agent 的記憶裡存了什麼？」）。

agent-recall 的 scope-chain 架構

agent-recall 是一個 SQLite-backed 知識圖譜，用 scoped entities、relations 和 slots 管理記憶，MCP server 提供 9 個工具讓 agent 主動儲存事實。它的核心設計是 scope-chain with inheritance：

• 同一個人在不同專案中可以有不同角色
• 每個 agent 只讀寫自己 scope chain 內的記憶
• MCP server 自動強制執行隔離，不需要應用層邏輯

根據 agent-recall 的 GitHub 文件，它已在 30 多個 agent 的生產環境中每日使用。所有資料存在 ~/.agent-recall/frames.db，單一 SQLite 檔案，完全離線。

Markdown-as-Source-of-Truth：反脆弱的記憶設計

memweave 和 sqlite-memory 專案共同體現了一個重要的設計哲學：Markdown 是人類可讀、可版本控制、永遠可移植的真相層，SQLite index 只是加速查詢的衍生層。

這對企業的意義是：

• 可稽核：打開 Markdown 檔案就能看到 agent 記住了什麼，不需要特殊工具
• 可重建：如果 SQLite 檔案損毀，從 Markdown 重建 index 即可，不存在永久資料遺失風險
• 零 vendor lock-in：不依賴任何雲端服務，遷移成本趨近於零

成本全貌：$0 到生產環境的費用階梯

階段	方案	月費	適用記憶量	適用用戶數
入門	Hmem / Engram（SQLite MCP）	$0	< 數萬筆	1 人
成長	Chroma 自建	$0（自建 infra 成本另計）	< 100 萬筆	10-100
規模	Pinecone Standard	$50+/月	無上限（按用量計費）	100-1,000+
託管	Mem0 Managed Service	按用量計費	無上限	依方案而定

升級的觸發條件不是「記憶變多了」，而是以下三個訊號同時出現：

1. FTS5 的查詢精準度無法滿足業務需求
2. SQLite 的單寫鎖造成用戶體驗延遲
3. 需要跨用戶的語意相似度搜尋功能

在這些訊號出現之前，多花的每一分錢都是浪費。

隱私優先設計：三個場景，local-first 記憶的不可替代優勢

很多開發者把「local-first」當作「便宜的替代方案」，但在以下三個場景中，local-first 不是妥協，而是唯一正確的選擇：

場景一：個人財務助理

你的 agent 需要記住用戶的收入、支出、投資組合。這些資料傳到雲端向量 DB 意味著財務隱私風險，而且可能違反當地個資法。SQLite 本地儲存讓資料永遠不離開用戶的設備。

場景二：醫療記錄整理

agent 處理用戶的健康數據和就醫紀錄。即使雲端服務聲稱加密，法規合規的舉證責任在你身上。local-first 架構從根本上消除了資料外洩的可能性。

場景三：企業程式碼審查

agent 需要記住程式碼庫的架構決策和技術債。公司的原始碼不能傳到 Pinecone 或任何外部服務。agent-recall 的 scope-chain + SQLite 讓每個專案的記憶完全隔離，IT 部門可以放心。

三個場景的共同點：資料不離機 = GDPR 合規 + 斷線可用 + 零 vendor 依賴。雲端方案無法同時滿足這三個條件。

工具選型決策表

用例	推薦工具	成本	離線能力	擴展上限
個人 coding agent	Hmem	$0	完全離線	單用戶，數萬筆
個人生產力工具	Engram	$0	完全離線	單用戶，數萬筆
多 agent 協作（企業）	agent-recall	$0	完全離線	30+ agents（已驗證）
B2C 聊天產品	Mem0	按用量	需網路	千級用戶
大規模語意搜尋	Pinecone	$50+/月	需網路	無限制
自建語意搜尋	Chroma（自建）	$0 + infra	可離線	取決於硬體
對話狀態管理	LangGraph checkpointer	$0	可離線	取決於後端 DB

提醒：這張表的「擴展上限」是基於工具文件與社群回報的保守估計，不是硬性限制。實際上限取決於你的硬體、查詢模式和資料結構。

上線前 Checklist：10 個問題確認你的 Agent 記憶架構準備好了

在把記憶功能推上生產環境之前，根據社群常見踩坑經驗，逐一確認以下 10 個問題：

1. 備份策略：SQLite 檔案有定期備份嗎？如果用 Markdown-as-source-of-truth 模式，能從 Markdown 重建 SQLite index 嗎？
2. 記憶上限：你預期的記憶量會超過 10 萬筆嗎？如果會，你的升級路徑是什麼？
3. 多 agent 衝突：如果多個 agent 同時寫入同一個記憶庫，你有衝突解決機制嗎？（agent-recall 的 scope-chain 天然解決這個問題）
4. 記憶品質：你有機制定期清理過時或錯誤的記憶嗎？agent 的記憶會隨時間腐化（memory decay）
5. 隱私分級：哪些記憶可以傳到雲端？哪些必須留在本地？你有明確的分級標準嗎？
6. 查詢模式：你的 agent 主要做精確查詢（「用戶 A 的偏好」）還是語意搜尋（「跟 React 相關的記憶」）？這決定了 FTS5 vs 向量 DB 的選擇
7. 冷啟動：新用戶的 agent 沒有任何記憶時，體驗會受到多大影響？你有 default memory 策略嗎？
8. 成本監控：如果用雲端向量 DB 或 managed service，你有設定用量告警嗎？token 成本和查詢成本容易在不知不覺中增長
9. embedding model 選擇：如果需要向量搜尋，你選擇了哪個 embedding model？OpenAI embedding API 是最簡單的選擇，但企業場景可能需要 self-hosted model
10. 可觀測性：你能查看 agent 在每次 session 中儲存和檢索了哪些記憶嗎？記憶系統的 debug 比你想像的更重要

結論：從最簡單的方案開始，需要時再升級

Agent 記憶架構不是一次性決策，而是隨產品成長逐步演進的過程。我的建議很簡單：

如果你是 solo dev：今天就裝 Hmem 或 Engram，5 分鐘後你的 agent 就不會再失憶。等記憶量真的超過 10 萬筆，或你需要語意搜尋時，再考慮升級。

如果你在做 startup：從 SQLite 開始，當用戶規模和查詢需求真正增長時，再引入 Mem0 或 Chroma 做 hybrid 架構。別在只有 10 個用戶時就搞 Pinecone。

如果你在企業環境：agent-recall 的 scope-chain + Markdown-as-source-of-truth 是目前最符合資安與稽核需求的組合。

記住一個原則：premature optimization 是 agent 記憶架構最常見的錯誤。 先解決「agent 會失憶」的問題，再慢慢優化架構。