AI 記憶引擎選誰好？TencentDB Agent Memory vs Mem0 vs Zep vs Letta 星數與路線老實比較

開場：AI 怎麼老是忘記你交代的事？記憶引擎到底在解什麼問題

你是否有過這樣的經驗？打開 ChatGPT 或 Claude，開了新對話，然後花五分鐘向它重新介紹自己：「我是某某公司的產品經理，我們的產品是 SaaS 訂閱制，主要客戶在台灣，我們偏好用 Next.js 開發前端……」接著你發現，它依然會問你一些你上一輪才交代過的事情。這種「每次見面都像第一次」的體驗，已經成為許多人日常工作裡最煩躁的阻礙。

這不是錯覺。大型語言模型本質上是無狀態的，每一次對話都是全新的開始。模型不會記得你昨天在另一個視窗裡討論過的客戶名單，也不會記得你上週決定放棄哪一條技術路線。它連你自己都寫在個人資料裡的偏好，都要等你重新說一遍。這種失憶，是模型天生的設計，不是缺陷，因為它必須確保每個使用者都在乾淨的狀態下開始，才不會被前一個人的資訊污染。但代價就是，你得不斷重複自己的背景，客戶喜好、程式碼慣例、決策理由，全部重講。

對中小企業來說，這個代價格外沉重。老闆花錢訂閱 AI 工具，本來是要節省時間，結果團隊每天花半小時重新餵背景資料，等於變相吃掉人力成本。研究顯示，中國智能體記憶市場在 2025 年規模為 14.4 億人民幣，到了 2030 年預估成長到 642.5 億人民幣，年複合成長率超過 110%（來源：愛分析報告，經博客園轉述，2026）。這個數字背後代表的，正是無數企業被「AI 失憶」困擾，急著尋找解方。

有些團隊嘗試把整個對話歷史全部塞回上下文，以為這樣 AI 就能「想起來」。這個做法短期有效，長期卻會帶來更多問題。一是成本，幾十萬個 token 的歷史紀錄，每次呼叫都在燒錢。二是雜訊，當背景資料多到某個程度，模型反而抓不到重點，它會把五年前的一句閒聊，跟現在最重要的客戶決策混在一起。三是維護，你永遠不知道哪一段歷史該優先被模型看到。結果就是，與其花力氣整理舊對話，不如直接開新視窗重新講一次，至少結果是穩定的。

這就是「記憶引擎」想要解決的問題。它要解的不是「記住更多」，而是「在對的時候，拿出對的資訊」。理想中的記憶引擎，不是把整本對話紀錄丟回模型眼前，而是像一個有紀律的檔案管理員：把原始對話歸檔，從中抽出真正有用的原子事實，再把這些事實組合起來，形成對使用者行為的理解。整個過程都有證據鏈，當模型說「我記得你偏好 TypeScript」，它背後至少要能指出：「因為你在 2026 年 3 月的會議紀錄裡這樣說」。

這個領域在 2026 年開始快速升溫。以 TencentDB Agent Memory 為例，這是騰訊雲資料庫團隊在 2026 年 5 月 14 日開源的 AI 記憶引擎，7 月 8 日曾經登上 GitHub Trending 第一名，目前累積超過 18，000 顆星（來源：GitHub API，2026）。它的核心主張不是「存更多」，而是「分層與符號化」：長期記憶採用 L0 到 L3 的金字塔結構，底層保留原始對話原文，頂層形成使用者畫像，每一層都保有追溯能力；短期任務則把龐大的工具執行紀錄壓縮成結構化圖表，只把精簡的任務狀態放入模型的上下文。根據官方 README 的數據，這個架構在長程任務中讓 WideSearch 的 token 使用量節省 61.4%，成功率從 33% 提升到 50%（官方宣稱，2026）。獨立實測也印證了這個方向，Pawel 在 Medium 上把模型縮小到 40 億參數的 Gemma 4 E4B 本地運行，結果 token 使用量下降超過五成，任務完成率反而上升 23%（來源：Pawel，Medium，2026）。這代表架構本身有效，而不是靠昂貴的強模型硬撐。

不過，記憶引擎不是萬靈丹。台灣工程師 blog.aihao.tw 在 2026 年 4 月的文章〈大多數記憶功能不需要向量檢索〉中指出，連 ChatGPT、Claude Code 這些主流工具都沒有依賴向量資料庫來做記憶，真正的困難在於治理，也就是怎麼寫入、怎麼整理、怎麼讀取、怎麼遺忘。文章裡有句話說得很精準：記憶不是「把過去塞回上下文」，而是「從過去推理出這次該怎麼做」。這句話值得每個想導入記憶機制的團隊反覆思考。記憶引擎的成敗，不在於儲存技術多先進，而在於你能不能讓 AI 在正確的時刻，拿出正確的證據。

所以，當你再次抱怨 AI 為什麼老是忘記你交代的事，問題往往不在記憶體不夠，而在於缺少一個有紀律、可追溯、會管理的記憶層。記憶引擎的價值，不在於它記住了多少，而在於它能不能在正確的時刻，拿出正確的證據，並且讓你把整條推理鏈看個明白。接下來的系列文章，我們會逐步拆解記憶引擎的實際架構，也用真實的安裝與測試經驗，帶你親手體驗這個正在改變 AI 協作方式的新工具。你的 AI 不該每次都像剛認識你，它該記得的，你只需要說一次。

四強路線圖與星數實況：Mem0 / Zep / Letta / TencentDB Agent Memory 誰在走哪條路？

踏入 2026 年 8 月，agent 記憶這個領域已經從「要不要做」演變成「怎麼做才對」。我在這個時間點透過 GitHub API 逐一確認了四個熱門開源專案的星數，數字分別是：Mem0 六萬二千七百顆星、Zep 二萬九千六百顆、Letta 二萬四千一百顆、TencentDB Agent Memory 一萬八千四百顆。星數固然反映了社群關注度，但真正關鍵的差異不在人氣，而在它們各自選擇的架構路線。本節把星數實況與路線圖放在一起對照，幫你搞清楚這四個專案到底在走哪條路。

數據來源是 GitHub API 實測（2026 年 8 月），競品路線分類參考 digitalapplied 於 2026 年 8 月 4 日發布的實測報告。四分天下的局面，表面上都是「幫 agent 記住東西」，骨子裡對於「記憶該用什麼形式存在」的答案完全不一樣。

Mem0：抽取式記憶的實用主義

Mem0 是目前星數最高的專案，路線是「抽取式」。它的核心動作是針對每次對話內容執行 ADD、UPDATE、DELETE、NOOP 四種操作，把值得記的訊息抽出來，寫進一個結構化的記憶庫。這種做法接近我們熟悉的資料庫思維：先定義要記什麼，再決定怎麼更新，處理遺忘。好處是實作直接、API 乾淨，開發者接入門檻低；代價則是抽取的正確性完全取決於模型能力，記憶雜訊一多，就需要一套嚴謹的清理機制。對多數團隊來說，這是最容易上手的起點，但把記憶品質綁在模型判斷力上，也意味著模型不夠強時，記憶庫裡會堆滿似是而非的內容。

Zep：把時間軸畫進知識圖譜

Zep 走的是另一條路，它的底層引擎 Graphiti 採用了「時序知識圖譜」。每一個事實都不只是孤立的節點，而是帶著 valid_at 與 invalid_at 兩個時間戳記，讓 agent 知道這條知識從什麼時候開始有效、什麼時候失效。對需要長期營運的 agent 來說，時間本身就是記憶的重要維度。使用者上個月偏好某種寫作風格，這個月轉變了，時序圖譜可以保留這種演化軌跡，而不是用新的覆蓋舊的。這種設計的彈性高，但圖譜的建構與查詢成本也相對昂貴，你需要為每一條關係付出圖結構的維護代價，換來的是對知識演變的完整掌握。

Letta：讓 agent 自己管理自己的記憶

Letta 的血統來自 MemGPT 研究專案，它的路線是「agent 自管理分層」。記憶被切成 Core、Recall、Archival 三個層級，agent 在運作過程中自己決定哪些內容要放進核心上下文、哪些要卸載到外部儲存、哪些該在背景被喚醒。再加上 sleep-time compute，agent 會在任務空檔主動整理記憶，把散落的線索收斂成可用的結構。這條路線最接近「把記憶當作 agent 的技能之一」，強調的是自主性。相對地，你要信任 agent 有能力做出好的記憶決策，如果 agent 判斷失準，記憶分層反而會變成一個難以除錯的黑盒子。

TencentDB Agent Memory：語意金字塔加上符號化

TencentDB Agent Memory 雖然星數在四者中暫時殿後，但它在 2026 年 7 月 8 日曾登上 GitHub Trending 第一名，8 月 3 日剛釋出 v2.0 正式版。它的路線是「語意金字塔加符號化」，長期記憶用 L0 到 L3 四層金字塔，從原始對話、原子事實、場景塊一路收斂到用戶畫像；短期任務則把龐大的工具 log 卸載到外部檔案，用 Mermaid 畫布抽出關係圖，只把精簡的任務拓撲注入 agent context。上層管判斷、下層管證據的設計，讓記憶壓縮之後仍然保有完整的證據鏈，這是四條路線裡少數把「可追溯性」當作第一優先的架構。

benchmark 的真相：官方數字都是 vendor-run

看到這裡，你可能會想問：四條路線哪一條的成績最好？答案是：目前沒有公平的答案。整個 agent 記憶領域的 benchmark 處於各自為政的狀態，每個專案用不同的測試集、不同的裁判模型、不同的評估框架，官方發布的數字全部都是 vendor-run，也就是廠商自己跑給自己看的。以 Mem0 為例，官方宣稱 LongMemEval 得分高達 94.4，但第三方的 digitalapplied 實測卻只有 49.0，落差將近一倍。同樣地，TencentDB Agent Memory 的官方 README 宣稱 WideSearch 成功率從 33% 提升到 50%、token 用量省下 61.4%，這些數據真實反映了自家測試環境的成果，但拿來跟其他專案直接比對，就會犯下方法論上的錯誤。

我引用這些數字時，一律標注「官方宣稱」，因為我們無法在相同條件下重現每個專案的測試。選型的時候，與其迷信單一 benchmark 分數，不如回頭檢視自己的使用場景：你的 agent 遇到的是長期用戶畫像、是帶時間演變的知識、還是需要大量縮短工具 log 的任務型運作？不同的路線，對應不同的痛點。

台灣工程師 blog.aihao.tw 在 2026 年 4 月的分析也提醒我們，大多數記憶功能根本不需要向量檢索，真正的困難在治理：寫入、整理、讀取、遺忘。這個觀點與 TencentDB 的分層方向有部分呼應，但強調的重點不同。記憶不是把過去塞回上下文，而是從過去推理出這次該怎麼做。選擇哪一條路線，取決於你的團隊願意為哪種治理方式買單。

整體來看，Mem0 是務實的抽取派，Zep 把時間變成記憶的座標，Letta 把記憶決策權交給 agent 自己，TencentDB Agent Memory 則是用金字塔與符號化換取可追溯性。四條路線沒有標準答案，只有適不適合。下一次我們會實際安裝其中一套，用真實的任務跑給你看，屆時你對這些架構的差異，會有更直接的感受。

TencentDB Agent Memory 深讀：L0-L3 語意金字塔＋Mermaid 符號化記憶怎麼運作

上一章我們把 Mem0、Zep、Letta、TencentDB Agent Memory 四條路線擺在一起比較，結論是沒有標準答案，只有適不適合。這章我們鑽進 TencentDB 的架構核心，看清楚它最特別的兩個設計：長期記憶的 L0 到 L3 語意金字塔，以及短期記憶的 Mermaid 符號化壓縮。這兩個機制加起來，回答了 AI 記憶領域最難的問題：壓縮了資訊，卻不丟失證據。

長期記憶四層：原文、事實、場景、畫像

TencentDB Agent Memory 的長期記憶不是一團混亂的向量資料庫，而是四層金字塔，每一層負責不同抽象程度。

• L0 Conversation，原始對話：全量保留，存在 SQLite 或 JSONL 檔。這層不做任何壓縮，是整套系統的兜底，任何時候想回查都能撈到原句。
• L1 Atom，原子事實：把對話拆成一條條獨立事實，例如「使用者採用 Next.js 開發」「偏好週五下午開會」。每條事實都打上標籤，方便精確召回。
• L2 Scenario，場景塊：把同一個任務的來龍去脈整理成一塊，例如一次報價流程的完整脈絡，用 Markdown 呈現，人可以直接閱讀。
• L3 Persona，用戶畫像：彙整成 persona.md，記錄技術偏好、程式碼風格、常用工具鏈。這層最精簡，負責給 agent 判斷方向。

這四層的核心設計原則是「上層管判斷、下層管證據」。判斷指的是 agent 回應時的策略選擇，L3 告訴它面對的是什麼樣的人；證據指的是每一次結論背後的原始出處。當 L3 的畫像與實際行為出現落差時，系統能逐層下探，找出是哪一層的歸納出了問題。這套證據鏈完整保留追蹤路徑：L3 說使用者偏好 TypeScript，可以追溯到 L2 的場景塊，場景塊的結論追溯到 L1 的原子事實，原子事實指向 L0 裡使用者親口講過的那句話。壓縮了，但不丟證據，這正是企業場景最需要的可稽核性。

跟 Zep 的時序知識圖譜、Mem0 的 ADD 與 UPDATE 抽取式寫入相比，這個金字塔的優勢在於每一層都有明確的產物格式。L2 是 Markdown 文件，L3 是 persona.md，這些都是工程師熟悉的檔案格式，而不是藏在資料庫裡看不見的向量。除錯或稽核時，打開檔案就能理解 agent 為什麼這樣判斷，記憶不再是黑盒子。

短期記憶：Mermaid 畫布把幾十萬 token 壓到幾百 token

長任務最耗 token 的往往不是對話本身，而是工具執行的 log，搜尋結果、錯誤軌跡、程式碼片段，累積起來動輒幾十萬 token。TencentDB 的做法不是想辦法塞進 context，而是反過來卸載。

流程是這樣的：完整 log 寫入外部檔案 refs/*.md，系統從中抽取關係，畫成一張帶 node_id 的 Mermaid 圖，這張圖只有幾百 token，只需要把圖注入 agent 的 context。當 agent 需要驗證某個細節時，靠 node_id 回頭 grep 原始 log，把原文撈回來。等於把線性的大量文字摘要，重組成一份帶狀態、帶依賴關係、帶可尋址索引的任務拓撲圖。

這個設計解決了兩個問題。第一個是 context 爆炸，幾十萬 token 的 log 不再佔據寶貴的 context 空間，agent 可以專注在任務狀態與下一步決策。第二個是除錯能力，傳統的摘要壓縮會把細節揉掉，一旦出錯根本不知道是哪個環節的問題，Mermaid 圖保留 node_id，出錯時可以精準回溯，這對我們這種要自己維運工具鏈的團隊特別有感。

兩路召回與小模型實測

記憶要能派上用場，召回機制是關鍵。TencentDB 同時採用 BM25 關鍵字精確命中與 Embedding 語意模糊匹配，再用 RRF 融合排序。關鍵字不會漏掉精確的專有名詞，語意檢索負責處理說法不同但意思相近的表述，兩路互補，語意相關不漏、精確匹配不丟。

獨立實測的結果格外有說服力。Pawel 在 Medium 發表的測試（2026-05-26），刻意把模型縮小到 Gemma 4 E4B，大約 40 億參數，跑在 M1 Pro 的本機 Ollama 上，執行 10 組 brief、3 組對照、共 30 次運行，全程零雲端呼叫。結果 token 用量下降超過 50%，任務完成率反而上升 23%。這證明這套架構是本身有效，而不是靠強模型撐起來的。官方 README（2026）宣稱的數據，WideSearch 成功率從 33% 提升到 50%，token 省下 61.4%，PersonaMem 準確率從 48% 提升到 76%，這些是官方自測，參考時要記得標注是官方宣稱。

要提醒的是，這個領域的 benchmark 目前各自為政，每套專案用不同的測試集、不同的裁判模型、不同的 harness。數位媒體 digitalapplied（2026-08-04）甚至抓到某競品自家宣稱 94.4 分，第三方實測只有 49.0 分，同一個 LongMemEval 測試，兩套結果。所以看任何官方數字都要打折，這是整個產業的現況，不是單一專案的問題。

台灣市場的聲音也值得聽。部落格 aihao.tw 的工程師（2026-04-28）提出，大多數記憶功能其實不需要向量檢索，真正的困難是治理，寫入、整理、讀取、遺忘。這個觀點與 TencentDB 的分層方向部分呼應，但也提醒我們，分層與符號化不是萬靈丹，團隊還是要有能力維護這些記憶資產，否則記憶照樣會膨脹變質。

整體來看，金字塔與 Mermaid 畫布把 AI 記憶從黑盒子變成可查閱、可追溯、可除錯的證據鏈。對台灣的中小企業來說，這意味著導入 AI agent 時多了一個可驗證的選擇，不再只能全盤相信模型內部看不見的「記性」，而是可以實際翻開文件，檢查它記了什麼、怎麼歸納、從哪裡得出結論。下一章我們會實際安裝這套架構，用真實任務跑一遍，看看證據鏈在實戰中是不是真的這麼可靠。

實戰與社群回饋：獨立實測數據、Reddit 正反意見、台灣工程師的一記當頭棒喝

上一章我們從架構面拆解了 TencentDB Agent Memory 的設計邏輯，金字塔分層與 Mermaid 符號化在理論上確實漂亮，但理論終究要經過實戰的考驗。尤其對台灣的技術團隊來說，看到官方 README 上陳列的效能數據，第一個反應往往是：那是騰訊雲自己測的，換成我們的機器、我們的工作負載，結果還是一樣嗎？這個疑慮非常合理，因為官方發布的 benchmark 本質上是 vendor-run，廠商自己當選手又當裁判，任何有經驗的工程師都不應該照單全收。

正因為如此，獨立的第三方實測與社群的真實回饋，反而比官方數字更有參考價值。這一個章節，我們要檢視三組關鍵材料：波蘭開發者 Pawel 在 Medium 發表的獨立實測、Reddit 各板對這個專案的正反意見、以及台灣工程師部落格對整個記憶領域的尖銳提醒。這三組材料拼湊起來，才是 TencentDB Agent Memory 在真實世界中的完整樣貌。

獨立實測：40 億參數的 Gemma 4 E4B，架構照樣點火

官方宣稱的數據大多建立在頂尖大型語音模型的基礎上，強模型本身的記憶與推理能力就很好，記憶架構的邊際貢獻容易被稀釋。要驗證架構本身有沒有料，最直接的方法，就是刻意把模型縮小，讓架構獨自扛起記憶與推理的重擔。

Medium 作者 Pawel 在 2026 年 5 月 26 日發布的實測文章《The 20K → 3K moment》正是這個思路。他刻意選用 Gemma 4 E4B，約 40 億參數的小型模型，跑在 M1 Pro 筆電的本地 Ollama 環境，全程零雲端 API 呼叫。實驗設計包含 10 組 brief、3 組對照、30 次運行，試圖在可重複的條件下比較「有記憶架構」與「無記憶架構」的實質差異。

結果相當戲劇化。啟用 TencentDB Agent Memory 之後，token 消耗直接下降超過 50%，更令人意外的是任務完成率反而上升了 23%。也就是說，模型變小了，記憶架構接手處理過往對話與工具呼叫紀錄，agent 不再需要把大量歷史上下文硬塞進模型視窗，反而能把注意力集中在當前任務的判斷上，效能因此不降反升。

Pawel 在文中給了一句很有畫面的結論：「架構在小模型也點火。」這句話背後的意義是，TencentDB Agent Memory 的效果不是靠強模型撐出來的，而是分層記憶與符號化設計本身的功勞。對預算有限、無法租用大型模型的台灣中小企業來說，這個訊號格外重要，如果記憶架構能在 40 億參數的模型上發揮作用，本地部署的可行性就大幅提高了，不需要為了記憶功能而被迫升級到昂貴的雲端運算資源。

當然，獨立實測也有其限制。Pawel 的測試集中在特定類型的長程任務，不一定能代表所有 agent 應用場景，30 次運行的樣本數也談不上大規模統計。但至少在「架構本身是否有效」這個核心問題上，這份實測提供了比官方 README 更可信的第三方證據，資料來源為 Pawel 於 Medium 的獨立實測（2026 年 5 月）。

Reddit 正反意見：記憶有沒有真的改變未來行為？

獨立實測的數據令人振奮，但社群的反應從來不會一面倒。TencentDB Agent Memory 在 2026 年 5 月開源之後，Reddit 上陸續出現多個討論串，呈現了實務工作者對這個專案又愛又疑的複雜情緒。

在 r/LovingOpenSourceAI 討論串（約 40 票）中，不少使用者對 fully local、零外部 API 的路線表達肯定。在企業資料隱私日益受到重視的時代，能讓 AI agent 的記憶完全留在本地，不需要把對話紀錄送給第三方雲端服務，對金融、醫療、法律等高度監管的產業特別有吸引力。這個肯定來自實際部署的痛點，不是對架構理論的抽象讚美。

但在 r/AI_Agents 討論串，質疑聲浪明顯更尖銳。最核心的問題是：「記憶有沒有真的改變未來行為？」意思是，系統或許記錄了大量事實，但當 agent 面對一個全新的任務時，這些記憶是實際影響了決策，還是只是躺在資料庫裡裝飾品？有使用者因此推薦了 Cognee 作為替代方案，理由是 Cognee 採用知識圖譜搭配原始憑證的設計，在可追溯性上可能更扎實。

另外，有使用者提出了「負面記憶」的概念，agent 嘗試過某個指令卻失敗，例如 chmod 權限設定錯誤，這種失敗經驗也應該被記錄下來，避免下次重蹈覆轍。這個意見點出了當前記憶系統的一個盲區：多數架構傾向記住「使用者說了什麼」與「任務做了什麼」，但對於「什麼做法行不通」這類負面經驗，往往缺乏有效的沉澱機制，而這些失敗教訓對 agent 的長期表現其實至關重要。

r/openclaw 討論串則從實際使用者的角度反映了兩個痛點。第一，捕捉機制還是太被動，使用者常常要主動喊「記住這個」，agent 才會把關鍵資訊寫入記憶，缺乏主動辨識重要資訊的能力。第二，記憶膨脹開始成為問題，系統運作一段時間後，累積的記憶量愈來愈大，要如何判斷哪些記憶該保留、哪些該遺忘，目前還沒有完善的解決方案。

這些正反意見其實很健康。獨立實測證明了架構的潛力，社群質疑則提醒我們，從「能記住」到「記得聰明」還有很長的路要走。官方 GitHub issues 在 2026 年 8 月 7 日仍有 bug 回報，例如編號 #846，官方承諾 24 小時內回應，顯示專案仍在高速迭代，距離成熟穩定階段還有段距離。

台灣工程師的一記當頭棒喝

在技術社群的喧囂中，台灣部落格 aihao.tw 在 2026 年 4 月 28 日發表了一篇文章，標題直白地寫著：「大多數記憶功能不需要向量檢索」。文章作者是台灣工程師，他逐一回顧了 ChatGPT、Claude Code、Claude API、OpenAI cookbook、Mastra SOTA 等主流工具，發現它們的記憶功能全都沒有使用向量檢索。這個觀察與 TencentDB Agent Memory 的分層設計方向部分呼應，但切入點截然不同。

該文作者的核心論點是，記憶的真正困難不在於「怎麼找」，而在於「怎麼治理」。寫入、整理、讀取、遺忘，這四個環節才是讓記憶系統從原型走向可維護的關鍵。向量檢索擅長處理語意模糊的查詢，但在多數 agent 記憶場景中，需要的是精確的事實回溯與結構化的決策脈絡，這些需求用傳統的關鍵字查詢或結構化儲存反而更直接、更容易除錯。

文章裡更精闢的一句話是：「記憶不是把過去塞回上下文，而是從過去推理出這次該怎麼做。」這句話直接點破了當前許多記憶系統的迷思。如果記憶只是把對話紀錄丟回模型視窗，那只是窮人版的長上下文，沒有真正的智慧。真正的記憶系統應該能從過去的經驗中提煉規則、偏好與教訓，在面對新任務時主動套用，這正是 TencentDB Agent Memory 分層設計想要達成的目標。

我們怎麼看這個觀點？老實說，它與 TencentDB Agent Memory 的分層設計並不衝突，兩者都認為「精確的事實」與「可追溯的來源」比模糊的語意相似更重要。但 aihao.tw 的文章提供了一個重要的提醒：分層與符號化不是萬靈丹。如果團隊沒有能力維護這些記憶資產，沒有定期清理失真的推論、沒有為記憶建立明確的擁有者與生命週期，再漂亮的金字塔架構，最終也會因為記憶膨脹而失去價值。

這個當頭棒喝對台灣市場格外受用。台灣的軟體團隊規模普遍不大，導入新工具時往往缺乏專職的 AI 工程師來維護記憶資產。在這種資源條件下，與其追求功能最豐富的記憶系統，不如務實地選擇治理成本最低的方案。TencentDB Agent Memory 的 L0 到 L3 分層，至少讓記憶有了清晰的檔案櫃，團隊可以定期打開櫃子檢查記憶內容是否過時，但會不會真的打開櫃子、有沒有紀律去整理，終究取決於團隊自己的營運習慣。

綜合這三組材料，獨立實測給了架構一個有說服力的背書，Reddit 的回饋讓我們看到實務上的坑洞，而台灣工程師的觀點則把話題拉回根本：工具只是工具，治理才是關鍵。對台灣的技術決策者來說，這三個面向構成一個完整的評估框架：架構有沒有底氣、實務上有哪些坑、團隊有沒有能力維護。三者都想清楚了，才適合把 TencentDB Agent Memory 放進生產環境。

替代方案有限公司觀點：台灣市場的落地建議

看完獨立實測與社群回饋，我們想從替代方案有限公司的角度，談談台灣市場的落地建議。我們長期協助台灣中小企業導入 AI 工具，最常遇到的狀況是，廠商被漂亮的官方數據吸引，急著把新架構搬進生產環境，卻忽略了背後的維護成本與營運紀律。

TencentDB Agent Memory 的架構確實有料，獨立實測也證明它在小模型上能發揮作用，但我們要誠實地說，v2.0 正式版在 2026 年 8 月 3 日才發布，到現在不到兩週，團隊級功能才剛剛出爐。對台灣多數中小企業而言，直接上三件式 Docker 部署，包含 memory-core、memory-hub、memory-proxy，維護成本可能超出預期。我們建議的做法是，先從 Hermes 或 OpenClaw 的 plugin 方式開始，用最小的成本把記憶功能接進現有流程，先跑一兩個月的真實任務，確認證據鏈的追溯性符合需求，再考慮是否要導入完整的 Memory Hub 團隊治理功能。

另一個務實的建議是，不要把「記憶」當成 AI 專案的核心目標。先盤點企業內部的使用情境，哪些流程真的需要跨會話的記憶能力？報價流程需要記住客戶偏好，客服機器人需要記住合約內容，程式開發需要記住技術決策的來龍去脈。這些場景才是記憶系統能創造實質價值的地方。如果只是為了「讓 AI 變聰明」而導入記憶功能，很容易陷入為了記憶而記憶的資源浪費。

，我們想呼應 aihao.tw 的觀點：治理比技術更重要。無論選擇哪一套記憶系統，企業都應該為記憶資產指定負責人，定期檢查記憶內容是否過時、是否失真、是否需要刪除。工具可以替我們記住事情，但判斷什麼值得記、什麼該遺忘，永遠是人的責任。

場景化比較表：客服機器人、程式開發助手、團隊知識庫分別該選哪一套？

記憶引擎的選擇，向來不是「哪一套最強」，而是「哪一套最適合當下的工作負載」。過去幾個月，我們實際跑了 TencentDB Agent Memory、Mem0、Zep 與 Letta 的架構對照，也讀了多份獨立實測，得到一個明確結論：客服機器人、程式開發助手、團隊知識庫這三種場景，對記憶架構的要求截然不同。以下用三組真實場景來拆解，並附上比較表供讀者直接對照。

場景一：客服機器人，要的是精確事實召回與自動化 SOP

客服機器人的痛點，通常不是模型不夠聰明，而是它在半年前記錯了一條合約條款，或在報價流程中漏掉客戶指定的折扣規則。這類任務要求記憶系統具備「證據鏈」：當 AI 回答「貴公司在去年十月已同意延長保固期限」時，系統必須能一路追溯到原始的對話紀錄，而不是只靠向量檢索打模糊仗。

TencentDB Agent Memory 的 L0 到 L3 分層架構，正好對應這個需求。L0 保留原始對話，L1 拆出原子事實，L2 整理成場景，L3 建立用戶畫像。召回時先看 L3，細節不足就往 L1 鑽，證據不足就翻 L0 原文。這種「上層管判斷、下層管證據」的設計，搭配 BM25 關鍵字命中與 Embedding 語意比對的雙路召回，在需要精確回答合約內容、保固條款、折扣規則的客服情境，遠比單純的抽取式記憶可靠。

相對地，Mem0 的 ADD、UPDATE、DELETE 抽取式架構，處理單一事實的更新很俐落，但在長達數十輪的客服對話中，容易把「客戶曾要求什麼」跟「客戶最終接受了什麼」混在一起。Zep 的時序知識圖譜能記錄事實的有效區間，例如「此折扣自三月一日起生效」，但要把 SOP 流程轉成可執行的步驟，還需要額外加工。若團隊目前還沒有任何記憶系統，且客服量體不大，Mem0 可以快速上手；但若客服涉及合約對答與流程自動化，TencentDB 的分層加上 Skill 資產，能直接從跑通的任務中提煉出可重用的報價步驟，這正是 Mem0 與 Zep 目前缺少的環節。

部署上，TencentDB 提供 Memory Proxy，可同時相容 Anthropic 與 OpenAI 協議，台灣團隊無論原先接哪一套 API，都能在 Gateway 層直接替換，無需改寫客服機器人的主要程式。官方宣稱 WideSearch 的 token 使用量可節省 61.4%（來源：官方 README，2026），用戶事實召回率也從不到三成提升到 79%（來源：官方 README／搜狐，2026）。但在實際導入前，我們建議先用自家客服語料跑一輪小型測試，因為官方數字皆為自測，跨場景不一定適用。

場景二：程式開發助手，重點是 impact analysis 與程式碼脈絡

程式開發助手的記憶需求，與客服機器人完全不同。開發者要的是「改了這個函式，會影響哪些模組」，以及「三個月前為什麼決定用 Next.js 而非 Vue」。前者需要程式碼結構索引，後者需要技術決策的來龍去脈。只靠對話記憶無法回答這類問題，必須把記憶系統與儲存庫綁在一起。

TencentDB 的 CodeGraph 資產，會自動索引 repo 內的符號、檔案、呼叫關係與影響路徑。開發者問「重構 authService 前，先幫我列出所有呼叫端」，CodeGraph 可直接給出影響範圍。官方宣稱 SWE-bench 通過率從 58.4% 提升到 64.2%（來源：官方 README，2026），雖然這是 vendor-run 的數字，但獨立實測也支持方向：Pawel 在 Medium 上故意把模型縮小至 Gemma 4 E4B 約 40 億參數並在本地執行，結果 token 使用量下降超過 50%，任務完成率反而上升 23%（來源：Pawel／Medium，2026-05-26），代表架構本身就是有效的，不是靠強模型撐場面。

相較之下，Letta 的分層記憶（Core、Recall、Archival）能幫開發者記住 coding session 的上下文，但沒有符號層級的程式碼索引，回答影響分析時需要依賴模型自行推斷。Zep 的知識圖譜對「這個專案用了哪些套件」這類事實有幫助，但對呼叫路徑的掌握不如 CodeGraph 直接。台灣的開發團隊若常維護大型 monorepo，或需要嚴格遵守變更影響評估流程，TencentDB 的 CodeGraph 是我們目前看到最貼近需求的實作。

部署上要注意，CodeGraph 需要與 repo 維持同步，官方提供定時自動同步機制，但初次索引大型儲存庫仍需耗費運算資源。若團隊採用 Hermes 或 OpenClaw，可以透過 plugin 方式掛載，比 Docker 三件套更輕量。

場景三：團隊知識庫，核心是跨成員資產治理

團隊知識庫的情境最複雜，因為它不只服務一個人，而是服務多個部門、多個 agent，還必須處理「誰可以看什麼」的權限問題。一個銷售 agent 不該讀到研發部門的機密架構圖，而一個共用知識庫必須避免成員互相覆蓋彼此的記憶資產。

TencentDB v2.0 的 Memory Hub 就是針對這個問題設計的。團隊可以建立不同的 Team 與 Agent，每項記憶資產都有 Owner、版本、狀態與可見性標記，可見性分為 private、team、restricted 三級，restricted 還能指定 User、Role 或 Agent 的 ACL。Agent Loadout 則讓不同 agent 綁定不同資產並調整優先級，避免「全部記憶塞進一個 prompt」的混亂。台灣企業常有跨部門協作需求，例如業務團隊報價時需要引用產品部門的最新規格，過去靠文件管理系統人工更新，現在可以透過 Memory Hub 讓產品規格自動沉澱為 Wiki 資產，業務 agent 在對答時直接讀取。

Zep 的時序知識圖譜在「版本演進」上有優勢，例如事實的生效與失效時間，但它的權限管理遠不如 Memory Hub 細緻。Mem0 與 Letta 則偏向個人記憶，缺乏團隊層級的治理介面。這裡要誠實提醒，TencentDB Agent Memory 的 v2.0 正式版於 2026 年 8 月 3 日才發布，團隊功能僅上線六天，官方 GitHub issues 中仍有多個待修復項目（來源：GitHub issues，2026-08-07），生產環境導入前必須自行驗證。另外，根據愛分析報告，中國智能體記憶市場從 2025 年的 14.4 億人民幣，預計成長到 2030 年的 642.5 億人民幣，年複合成長率超過 110%（來源：愛分析報告，經博客園轉述，2026），這也解釋了為什麼各大記憶引擎都在加速補齊團隊治理功能。

場景選擇比較表

三個場景看下來，TencentDB Agent Memory 在客服、開發、知識庫三個方向都有對應的內建資產，是我們目前測試過的記憶引擎中，涵蓋最完整的選擇。但這不代表它是萬靈丹。對於只想要輕量記住客戶偏好的小型客服團隊，Mem0 的快速導入可能更務實；對於需要精確事實版本管理的法務或保險場景，Zep 的時序圖譜仍值得考慮。

選定引擎只是第一步，真正決定成敗的是治理。我們呼應 aihao.tw 的觀點：記憶最重要的不是儲存技術，而是寫入、整理、讀取、遺忘這四個管理動作。無論選哪一套系統，企業都應該指定記憶資產的負責人，定期檢查過時或錯誤的內容，並建立明確的遺忘機制。工具負責記住，但判斷什麼值得記、什麼該丟棄，永遠是人的責任。

替代方案有限公司觀點：記憶引擎的勝負不是星數，而是治理與證據鏈

過去一個月，我們被問到最多次的問題，就是 TencentDB Agent Memory 在 GitHub 上累積了 18，423 顆星（來源：GitHub API，2026 年 8 月 9 日），這套記憶引擎是不是目前最值得導入的選擇。星數確實是開源世界裡真實的注意力貨幣，但我們認為，以星數決定記憶引擎的去留，是把複雜的工程決策簡化成排行榜競賽，而這個競賽的參考價值遠比多數人想像的低。

把四個主流專案擺在一起，Mem0 的 62.7k、Zep 的 29.6k、Letta 的 24.1k 都在 TencentDB Agent Memory 的 18.4k 之上（來源：digitalapplied 比較報告，2026 年 8 月 4 日）。但這四個專案的設計路線差異極大，Mem0 走抽取式更新，Zep 做時序知識圖譜，Letta 讓 agent 自己管理分層記憶，TencentDB 則用金字塔加符號化壓縮。把它們放在同一個排行榜上比星數，就像拿蘋果比橘子。更麻煩的是，整個領域的 benchmark 各自為政，每家都用不同的測試集、不同的裁判模型、不同的 harness，官方數字全是 vendor-run，目前沒有公平的第三方對照組。這意味著你看到的任何漂亮數字，都只能當作官方宣稱，不能當作選型依據。

分層金字塔的價值：證據鏈不中斷

我們之所以對 TencentDB Agent Memory 感興趣，不是因為它拿到 GitHub Trending 第一名，而是因為它的 L0 到 L3 分層設計，解決了生成式 AI 最難交代的問題：你的結論從哪裡來。L0 保留原始對話，L1 萃取原子事實，L2 組織場景脈絡，L3 歸納使用者畫像。上層負責快速判斷，下層負責保留證據，當 L3 說使用者偏好 TypeScript，你可以沿著場景塊跟事實節點，一路追回 L0 那一句原始對話。證據鏈不中斷，這對台灣企業非常重要。我們在導入專案時最常被問的問題不是「AI 準不準」，而是「AI 為什麼這樣判斷」，沒有證據鏈的系統，即使準確率很高，也很難被信任。

另有一項獨立實測值得參考。Pawel 在 Medium 發表的測試（2026 年 5 月 26 日）故意把模型縮小到 Gemma 4 E4B，只有約 40 億參數，跑在 M1 Pro 本機端，十組任務加上三十次運行無任何雲端呼叫，結果 token 消耗下降超過一半，任務完成率反而提升 23%。這代表架構本身有效，不是靠強模型撐場面。對預算有限的台灣中小企業來說，這是個務實的好消息。

向量不是萬靈丹，治理才是真正的戰場

不過我們要誠實提醒，分層金字塔再漂亮，也不會自動解決記憶管理的核心痛苦。台灣工程師部落格 aihao.tw 在 2026 年 4 月 28 日發表了一篇文章，標題直接點出「大多數記憶功能不需要向量檢索」，內容分析 ChatGPT、Claude Code、OpenAI cookbook、Mastra 的實作都不依賴向量庫，真正難的是寫入、整理、讀取、遺忘這四個治理動作。我們在輔導客戶的過程中反覆看到同一個劇本：團隊裝好記憶引擎後，第一週很興奮，第二週開始發現記憶內容混亂，第三週就放棄了。原因不是工具不好，而是沒有人負責治理。

Reddit 社群的反饋也印證了這件事。r/openclaw 的開發者抱怨捕捉機制太被動，記憶仍需要主動喊才會留下。r/AI_Agents 的討論則提出負面記憶的概念，agent 試過 chmod 失敗這類錯誤經驗也該被記錄。這些聲音點出同一個事實：記憶引擎的真正考驗不在儲存技術，而在有沒有設計一套讓記憶被正確寫入、定期整理、精準讀取、而且敢於遺忘的管理流程。

我們認為，記憶引擎的導入不是安裝專案，而是建立一套記憶治理的制度。工具負責記住，但判斷什麼值得記、什麼該丟棄，永遠是人的責任。

給台灣中小企業的落地建議

以我們輔導台灣中小企業的經驗，最常見的錯誤是從技術出發，先裝系統再想用途。我們建議反過來做，先定義你想回答的問題，再決定記憶分層的深度。一家做進出口報關的公司，真正需要的是客戶去年走過哪些流程、卡過哪些關，這只需要 L1 事實萃取與 L2 場景重組，不需要做到 L3 使用者畫像。一家軟體外包公司想讓新人快速接手專案，才需要動用 CodeGraph 程式碼關係索引。記憶架構應該是問題的答案，不是技術的展示品。

部署層面我們據實以告：Docker 三件套對中小企業並不友善，memory-core、memory-hub、memory-proxy 三個容器要管理版本、網路與權限，start-all.sh 一鍵啟動雖方便，正式上線的監控與備份仍需要人力。如果團隊只有一兩位工程師，建議先走 plugin 路線，裝在原有的 Hermes 或 OpenClaw 環境，用最小成本驗證價值。

中國智能體記憶市場從 2025 年的 14.4 億人民幣成長到 2030 年的 642.5 億人民幣，年複合成長率超過 110%（來源：愛分析報告，經博客園轉述）。市場正在快速膨脹，但市場規模與企業實際受惠是兩回事。我們看過太多團隊導入新工具後，反而被工具的複雜度拖垮。記憶引擎的勝負，從來不是星數競賽，而是你能不能把證據鏈變成團隊的日常紀律。

作為替代方案有限公司，我們在台灣輔導中小企業導入 AI 的真實體悟是：開源專案的星數無法取代組織內部的營運紀律。TencentDB Agent Memory 提供了完整的骨架，但骨架需要血肉，血肉就是企業自己的治理流程。我們會這樣建議客戶：第一個月先指派記憶資產負責人，第二個月建立每週回顧機制，第三個月才開始談擴展場景。台灣製造業與服務業的流程知識非常深厚，把這些知識結構化地餵給記憶層，就能產生比單純堆疊模型更大的槓桿。而這個優勢，剛好需要證據鏈與治理來兌現。這才是我們眼中，記憶引擎真正的勝負所在。

結論：先定義你的記憶需求，再選引擎，以及我們能幫你驗證什麼

把四套引擎攤開來比，我們看到的是四種完全不同的記憶哲學。Mem0 用抽取式指令決定記憶的寫入與刪除，Zep 與 Graphiti 用時序知識圖譜捕捉事實的有效區間，Letta 讓 agent 自己管理分層記憶並在睡眠時段整理，TencentDB Agent Memory 則用 L0 到 L3 的金字塔加上 Mermaid 符號化，把原文、事實、場景與人物畫像串成完整的證據鏈。這些差異不是版本號的差別，而是對「記憶是什麼」的根本理解不同。

星數差距很明顯，Mem0 逼近六萬三千顆，TencentDB Agent Memory 只有一萬八千顆（來源：digitalapplied 實測，2026-08-04），但我們必須說，星數代表的是社群關注度，不代表它能解決你的問題。真正該問的是：你最痛的記憶問題是什麼？是 agent 忘記用戶偏好？是長任務燃燒大量 token？是團隊成員之間無法交接脈絡？每一套引擎對這些問題的回答都不一樣，答錯方向，裝了也只是增加系統複雜度。

官方數字，請當作參考而非真理

這個領域的 benchmark 目前各自為政。每一家都用自己設計的測試題、自己的裁判模型、自己的執行環境來宣稱成績，而且這些數字都是廠商自己跑的，沒有第三方公正單位背書。TencentDB Agent Memory 官方宣稱 WideSearch 成功率從 33% 進步到 50%、token 節省 61.4%、PersonaMem 準確率從 48% 提升到 76%（來源：官方 README，2026 年），這些數字值得參考，但最好把它理解成「這套系統在自己設計的場景下表現良好」。更極端的例子是 Mem0，digitalapplied 在 2026-08-04 的交叉實測發現，Mem0 自家宣稱 LongMemEval 拿到 94.4 分，第三方實測卻只有 49.0 分，差距將近一倍。這不表示 Mem0 虛報，而是測試條件完全不同，拿來橫向比較只會得到錯誤結論。

先定義需求，再談引擎選型

所以我們建議你，把「哪一套最強」改成三個實際問題，答案會自己浮現。

1. 你的 agent 需要跨會話記住用戶的偏好與決策嗎？如果需要，TencentDB 的 L3 Persona 畫像與 Mem0 的抽取式都能做到，差別在於前者保留完整的證據鏈，每一條畫像結論都可以回溯到原始對話，後者則以指令操作為主，遺忘與更新的效率較高。
2. 你的長任務是不是常常被工具 log 淹沒？搜尋結果、錯誤軌跡、程式碼輸出往往動輒數十萬 token，TencentDB 的 Mermaid 符號化把這些內容壓縮成幾百 token 的任務拓撲圖，而且獨立實測證實這個架構在小模型上依然有效，Pawel 用 Gemma 4 E4B 在本地運行，token 降了超過 50%、任務完成率上升 23%（來源：Pawel，Medium，2026-05-26），這不是靠強模型硬撐出來的成績。
3. 你需要的是單人工具還是團隊資產？若你要多人共享記憶、區分權限、管理資產版本，TencentDB 的 Memory Hub 提供 private、team、restricted 三級可見性，是目前四套之中團隊治理最完整的；相對地，若你只是個人開發者想要輕量方案，Mem0 與 Letta 的社群資源會更豐富。

驗證的唯一標準：記憶有沒有改變行為

選定引擎之後，真正要驗證的不是「它記住了什麼」，而是「記憶有沒有改變未來的行為」。Reddit 的 r/AI_Agents 討論中，已經有人質疑許多記憶系統只是把過去塞回上下文，卻沒有證據顯示這些記憶影響了 agent 的決策。台灣工程師 blog.aihao.tw 也在 2026-04-28 的文章提醒，大多數記憶功能其實不需要向量檢索，真正困難的是寫入、整理、讀取與遺忘的治理，記憶的價值不在儲存，而在從過去推理出這次該怎麼做。這兩股聲音剛好幫我們校正了看待記憶引擎的方式：分層與符號化是對的方向，但向量檢索不是萬靈丹，官方自測數字更不該當成採購依據。

我們的具體建議是：挑一個小型專案，在 Hermes 或 OpenClaw 上把候選引擎裝起來，設定一個月的驗證週期，然後只追蹤三個訊號。第一，同樣的任務第二次執行，是不是不用再重複交代背景脈絡？第二，agent 犯過的錯誤，下一次是否真的避開了？第三，團隊另一個人接手同一個專案，能不能接續上一回的討論進度？這三個訊號的答案，比任何 benchmark 數字都更能代表你的真實收益。若答案都是肯定的，再談規模化；若答案是否定的，那就代表這套引擎的記憶格式與你的工作流程對不上，換一套比硬撐更省成本。

我們能幫你驗證什麼

作為替代方案有限公司，我們在台灣輔導中小企業導入 AI 的經驗是，記憶引擎導入失敗很少因為技術不夠好，多半是因為需求沒有先被定義。很多團隊看到星數高就安裝，裝完才發現那套引擎的記憶格式跟自己的工作流程對不上。所以我們的服務流程，第一步永遠是陪客戶盤點痛點，到底是遺忘、重工、還是無法交接；第二步才挑引擎；第三步用小型專案驗證行為改變；才談規模化。我們不會替客戶預設哪一套最好，因為每一家企業的流程知識與治理文化都不一樣。台灣製造業與服務業的隱性知識非常深厚，把這些知識結構化地交給記憶層，產生的槓桿遠比出動更強的模型更大。我們能做的，是幫你設計驗證清單、搭建測試環境、解讀測試結果，讓記憶系統不只是儲存工具，而是真正改變 agent 行為的基礎建設。

若你對四套引擎的取捨有任何疑問，或者想先做一個小型 PoC，驗證記憶是否真的改變行為，歡迎寫信到 [email protected] 與我們聊聊你的場景。先定義需求，再選引擎，用行為改變來驗證，這條路雖然沒有捷徑，但絕對比盲目追星數走得長遠。