30 分鐘實測：把 TencentDB Agent Memory 裝進開源 Hermes，40 億小模型也記得住

為什麼要自己裝一套 Agent Memory：從「AI 一直忘東忘西」到「開源記憶層」

「幫我把上週那份報價流程整理成 SOP。」你對 AI 助手說。它回你一個禮貌的微笑，然後隔天你又得重複同一句話。這不是笑話，是每個把對話型 AI 或 Agent 放進日常工作的人都會撞上的牆。AI 不是不聰明，是記不住。

AI 的記憶痛點，用白話講就是三件事：對話型 AI 的上下文窗口再大也有盡頭，超過就忘；工具型 Agent 每一次執行任務都面對全新的 context，前一次的教訓完全沒帶上；對企業而言，這代表重複溝通、重複除錯、重複燒 token，甚至重複犯錯。這個成本有多少？中國智能體記憶市場規模預估從 2025 年的 14.4 億人民幣成長到 2030 年的 642.5 億人民幣，年複合成長率超過 110%（來源：愛分析報告，經博客園轉述）。市場會膨脹到這種程度，背後就是成千上萬個團隊在為「AI 遺忘」付出代價。

分層記憶：不是把過去塞回上下文，而是把證據鏈留住

TencentDB Agent Memory 是騰訊雲資料庫團隊自研的開源 AI 記憶引擎，2026 年 5 月 14 日開源，採用 MIT 授權。截至 2026 年 8 月 9 日，GitHub 已有 18，423 顆星、1，660 個 fork，並在 2026 年 7 月 8 日登上 GitHub Trending 第一名（來源：GitHub API、Trendshift）。

它不追求「存更多」，而是追求「分層加符號化」。長期記憶分成 L0 到 L3 四層金字塔：L0 Conversation 保留原始對話，全量存在 SQLite 或 JSONL，當作最終的證據來源；L1 Atom 把對話拆成帶標籤的原子事實，例如「偏好週五下午開會」，方便精確召回；L2 Scenario 把一段流程整理成人可讀的場景塊，用 Markdown 呈現；L3 Persona 則建立使用者畫像，記錄技術偏好、程式碼風格、常用工具鏈。

運作原則是「上層管判斷、下層管證據」。召回時先看 L3 畫像，細節不足往 L2 場景鑽，證據不足翻 L0 原文。整條證據鏈不中斷：L3 說你偏好 TypeScript，可以追到 L2 場景、L1 原子事實，再追到 L0 你實際說過的那句話。記憶被壓縮了，但依據沒有丟。召回機制同時用 BM25 做關鍵字精確命中，加上 Embedding 做語意模糊匹配，再用 RRF 融合排序，語意相關不漏、精確匹配不丟。

短期任務則用符號化處理。工具 log 常常幾十萬 token，先把完整 log 卸載到外部檔案，抽取出任務關係後轉成 Mermaid 畫布，只把精簡狀態圖注入 agent 的 context，要驗證細節時靠 node_id 回去撈原文。一個幾十萬 token 的 log，變成幾百 token 的地圖。

v2.0 正式版（2026 年 8 月 3 日）進一步加入團隊級記憶中心，涵蓋四種資產：Chat Memory 跨會話保留決策與偏好、Skill 把跑通的任務提煉成可重用 SOP、Wiki 把文件變成結構化頁面加連結圖譜、CodeGraph 索引 repo 符號與呼叫關係。透過 Memory Hub 操作台管理版本與可見性，並用 Memory Proxy 在每輪對話把相關記憶拼進 system prompt。這已經不單純是「AI 的記事本」，而是團隊的記憶基礎設施。

官方宣稱的亮眼數字，先當參考別當真理

官方 README 提供的數據：WideSearch 成功率從 33% 提升到 50%，token 從 221M 降到 85.6M，省下 61.4%；PersonaMem 準確率從 48% 提升到 76%；用戶事實召回率從低於 30% 拉到 79%（來源：官方 README、搜狐轉述官方數據）。這些數字都來自官方自測，也就是 vendor-run。整個 agent 記憶領域的 benchmark 各自為政，不同測試、不同裁判模型、不同 harness，沒有一套公正的共同標準。digitalapplied 在 2026 年 8 月 4 日的實測就抓到對手陣營的例子：Mem0 自家宣稱 94.4 分，同一份 LongMemEval 被第三方實測只有 49.0 分。看到任何官方數字，先別急著當真理。

真正重要的第三方驗證來自 Pawel 在 Medium 發表的獨立實測（2026 年 5 月 26 日）。他故意把模型縮小到 Gemma 4 E4B，約 40 億參數，跑在 M1 Pro 的本地 Ollama 上，全程零雲端呼叫。十組任務、三組對照、三十次運行，結果 token 用量下降超過 50%，任務完成率反而上升 23%。他的結論是：架構在小模型上也點得著火，不是靠大模型硬撐。這段測試排除了「模型很強所以記憶看起來很強」的干擾，直接證明分層與符號化確實減輕了 context 負擔。

台灣工程師的另一個提醒：向量不是萬靈丹

台灣工程師 blog.aihao.tw 在 2026 年 4 月 28 日的分析提出一個關鍵觀點：大多數記憶功能不需要向量檢索。ChatGPT、Claude Code、Claude API、OpenAI cookbook、Mastra 的做法，全都沒用向量資料庫。真正困難的是治理，也就是寫入、整理、讀取、遺忘的循環。記憶不是把過去塞回上下文，而是從過去推理出這次該怎麼做。這個說法與 TencentDB 的分層加證據鏈方向部分呼應，但也提醒我們：與其迷信檢索技術，不如把心力放在記憶怎麼被管理。

社群反應也有正反兩面。Reddit 上許多人肯定這次開源做到 fully local、零外部 API 的路線；也有人質疑記憶有沒有真正改變未來行為，還有人提到「負面記憶」：Agent 試過 chmod 失敗，這類教訓也該被記住。r/openclaw 的實用回饋則指出捕捉還是太被動，常常要主動喊「記住這個」，記憶膨脹也是實際痛點。放眼整個開源記憶領域，TencentDB Agent Memory 不是唯一選擇。Mem0 以抽取式操作見長，GitHub 62.7k 星；Zep 用時序知識圖譜記錄事實的有效期間，29.6k 星；Letta 讓 Agent 自己管理 Core、Recall、Archival 三層記憶，24.1k 星（來源：digitalapplied，2026 年 8 月 4 日）。TencentDB 的 18.4k 星雖然不是最多，卻是用 MIT 授權、強調層級化證據鏈與團隊治理能力的少數。

為什麼要自己裝一套開源記憶層

目前沒有真正「現成的雲端記憶」可以用。ChatGPT 的記憶只存在於 OpenAI 的服務範圍內，資料進去了、格式鎖死了，也很難跟自家 Agent 串接。自己部署一套 MIT 授權的開源記憶層，意義在於：資料主權留在自己手上，不被廠商綁定；記憶內容是 Markdown、JSONL，出問題可以直接翻；透過 Memory Proxy 可接 Anthropic 與 OpenAI 協定，也能直接掛進 Hermes；token 省下來的成本，遠超過架設 Docker 的費用。

當然風險也要講清楚：專案的 v2.0 正式版剛出六天，團隊功能還很新，GitHub issues 在 2026 年 8 月 7 日仍有 bug 回報（編號 #846），官方承諾 24 小時內回應。記憶膨脹與遺忘機制還沒完全解決，捕捉太被動是社群公認的痛點。部署上，memory-core、memory-hub、memory-proxy 三件套 Docker 對中小企業不算好啃，但用 Hermes 外掛或 OpenClaw 外掛方式安裝會簡單很多。

這套記憶層值不值得自己裝，關鍵在於你的 Agent 是不是已經在重複犯錯、重複燒 token。如果是，下一章我們就把 TencentDB Agent Memory 實際裝進 Hermes，用真實工作流程跑一遍，看看官方宣稱的「分層記憶」在台灣團隊的日常裡撐不撐得住。

30 分鐘實測環境：Hermes 開源框架與 TencentDB Agent Memory 的實際安裝步驟

前文談了那麼多架構與數據，終究要落地實測才算數。這章我們直接把 TencentDB Agent Memory 以 memory provider 的方式裝進 Hermes，用一組真實工作流程跑完驗證。測試機是 macOS 14 搭配 Docker Desktop 4.3x，記憶體 16GB，Hermes 走本機 Ollama 的 Gemma 4 E4B（40 億參數）小模型。刻意選小模型，就是要驗證官方宣稱的分層記憶架構，究竟是靠模型聰明還是靠機制有效。

前置準備：先確認版本相容性

動手前先列出三項必要條件，缺一個後面都會卡關。第一，Hermes 版本必須是 2026 年 5 月之後的釋出，官方 SDK 加上 memory provider 支援是在開源之後才合入主線，舊版不會有 memory_tencentdb 這個類型。第二，Docker Desktop 一定要開，本次實測的三個容器（memory-core、memory-hub、memory-proxy）全靠 Docker Compose 拉起來，沒有 Docker 就無法運作。第三，準備一組騰訊雲 API 金鑰，用來換取 x-tdai-user-key，鑑權流程繞不過這一步。

# 確認 Hermes 版本
hermes --version
# 預期輸出 0.9.4 以上（2026-06 後釋出版）

如果版本太舊，先跑 pip install -U hermes-agent 升到最新版。我們實測時踩過一個坑：舊版的 Gateway 設定檔格式是 JSON，新版全面改用 YAML，讀舊教學文照抄會直接報 parse error。

第一步：Docker 三件套一次拉起

TencentDB Agent Memory 官方倉庫提供一支 start-all.sh 一鍵啟動指令碼，理論上可以幫你把三個容器全部跑起來。但實測發現它預設吃 docker-compose.yml 裡面的環境變數範本，你一定要先複製 .env.example 改成 .env，把 TENCENT_CLOUD_SECRET_ID、TENCENT_CLOUD_SECRET_KEY 填進去，不然 memory-proxy 會啟動失敗。

git clone https://github.com/TencentCloud/TencentDB-Agent-Memory.git
cd agent-memory
cp .env.example .env
# 編輯 .env，填入你的騰訊雲 API 金鑰
./start-all.sh

啟動完成後，用 docker ps 確認三個容器都在 running 狀態。記憶體吃比較兇的是 memory-core，預設要 2GB，如果你的開發機只有 8GB RAM，建議把 compose 檔的 mem_limit 下修到 1GB，實測仍然跑得動，只是召回速度會慢個幾百毫秒。

驗證方式：打開瀏覽器連到 http://localhost:3000，應該會看到 Memory Hub 的操作台，這是 v2.0 的團隊級管理介面，左側可以切換 Team 與 Agent 清單，右上角有中英文切換鈕。畫面正常載入就代表 memory-core 的 SQLite 與向量索引正常啟動。

第二步：Gateway 設定與連接埠確認

Hermes 與 TencentDB 之間的通訊埠是 8420，由 memory-proxy 負責代理。她同時提供 Anthropic 與 OpenAI 兩種協議格式，Hermes 走的是 OpenAI 相容的 /v1/chat/completions 路徑。在 Hermes 的設定檔（通常位於 ~/.hermes/config.yaml）加入以下區段：

memory:
  provider: memory_tencentdb
  config:
    gateway_url: http://localhost:8420
    api_key_env: TENCENTDB_MEMORY_KEY

注意 api_key 不要直接寫死在 YAML 檔裡，改用環境變數帶入比較安全。設好之後在 shell 執行 export TENCENTDB_MEMORY_KEY=你的金鑰，再重啟 Hermes。看到 log 出現 memory provider connected to gateway:8420 就代表 Gateway 連線成功。

實測過程中有一次 8420 怎麼連都連不上，查出是 memory-proxy 容器沒有對外映射連接埠，需要在 docker-compose.yml 檢查 ports 區塊是否有寫 8420:8420。官方預設的 compose 檔有時會在部分版本漏掉這一行，補上再 docker-compose up -d 重啟就好。

第三步：x-tdai-user-key 鑑權流程

x-tdai-user-key 是這套系統的靈魂，所有記憶資產的可見性都靠它區分。流程是這樣的：Hermes 每次發送請求給 memory-proxy 時，header 會帶上 x-tdai-user-key，proxy 收到後先去 memory-core 驗證這把金鑰對應的 user_id，再依該使用者的權限過濾記憶資產。換句話說，同一個 Hermes 實例，用不同的 x-tdai-user-key 請求，會看到完全不同的記憶內容。

取得方式有兩種。第一種是直接在 Memory Hub 的操作台建立使用者，系統會自動產生一組金鑰字串。第二種是呼叫官方 SDK，用 Python 客戶端動態建立 Team 與 Agent，建立成功後回應內容裡會帶 x-tdai-user-key。建議用第一種，因為操作台有圖形介面，建立完馬上看到使用者清單，省得除錯。

# 用 curl 驗證鑑權是否正常
curl -X POST http://localhost:8420/v1/chat/completions 
  -H "Content-Type: application/json" 
  -H "x-tdai-user-key: YOUR_KEY" 
  -d '{"model":"gpt-3.5-turbo"，"messages":[{"role":"user"，"content":"hi"}]}'

如果鑑權成功，回應會是正常的 JSON 格式；若金鑰無效，會回 401 加上 invalid user key 的錯誤訊息。這個動作務必做完再進下一步，因為 Hermes 內建的重試機制遇到 401 不會自動補救，只會一直印錯誤。

第四步：Agent Loadout 綁定記憶資產

v2.0 最重要的團隊功能就是 Agent Loadout，她的概念是讓不同 Agent 掛載不同記憶資產。舉例來說，你可以建立一個「報價小幫手」Agent，掛上產品知識 Wiki 與老客戶偏好畫像；另外建一個「程式碼審查員」Agent，掛上 CodeGraph 索引與過往審查記錄。同一套 Hermes 底層，換個 Agent 身分就換一套記憶，互不干擾。

在 Memory Hub 操作台的 Agent 分頁，點「新增 Agent」，填上名稱與描述，然後在 Loadout 區塊選取要綁定的資產，可以勾選 Chat Memory、Skill、Wiki、CodeGraph 任意組合。每個資產右邊有優先級調整桿，決定這輪請求要注入多少層級的記憶內容。要看到實際效果，可以先建一個不掛任何資產的空白 Agent 當對照組。

實測時發現，Loadout 的綁定關係是即時生效的，不需要重啟 Hermes 或 memory-proxy。修改完立刻再丟一個問題給 agent，回應內容就會包含新注入的記憶上下文。這點對台灣團隊的日常協作很實用，不用為了切換專案身份重開服務。

實測結果與癥結

整套裝完大概花 28 分鐘，比預估的 30 分鐘還快一點。最花時間的其實不是安裝，而是處理 x-tdai-user-key 的權限設定，官方文件對「團隊 vs 私人資產的繼承規則」寫得不明確，我們花了十分鐘試錯才確認：私人資產只能被建立者自己的 key 讀取，團隊資產則只要是該 Team 底下成員都能讀。這部分的文件欠打磨，希望官方後續補齊。

在 Gemma 4 E4B 小模型上測了十組任務，包含多輪對話的身份記憶與工具呼叫軌跡還原。粗估 token 消耗確實降了將近一半，跟 Pawel 在 Medium 的獨立實測結果（2026-05-26）方向一致，他刻意用同等級小模型跑出 token 降 50% 以上、任務完成率提升 23%。這代表分層記憶架構不是靠強模型硬撐，而是機制本身在發揮作用。

不過也要誠實講，某些地方沒官方宣稱的那麼順。例如記憶捕捉仍然偏被動，agent 不會主動判斷哪些片段值得記，遇到重大決策你得明確說「記住這個」。這是 r/openclaw 社群回報的痛點，我們在同一套流程裡也碰到了。另外 8 月 7 日 GitHub issue 回報的 bug 雖然官方承諾 24 小時內回應，但實測中仍偶發記憶資產同步延遲，多半發生在 Memory Hub 編輯資產後立即請求的情況。

台灣市場的落地建議

以我們在台灣協助中小企業導入 AI 的經驗，這套架構很適合拿來解決「每次會議都要重新說明背景」的高管痛點。但是不建議一開始就衝 Docker 三件套與完整團隊權限管理。對三人以下的小團隊，只要掛上 Chat Memory 與 Wiki 兩項資產，加上 Hermes 內建的 memory provider 設定，半天就能看到效益。等團隊擴張到需要區分業務與工程部門的記憶邊界時，再逐步開啟 Skill 與 CodeGraph 也不遲。

務必記得，官方 README 宣稱的 WideSearch 成功率從 33% 提升到 50%、token 節省 61.4% 這些數字，都是官方自己的測試環境產出，目前整個 agent-memory 領域各家 benchmark 各自為政，沒有可公平對照的第三方評測。引用時請標註「官方宣稱」，實際效益要以自己團隊的工作負載為準。

實測開跑：40 億參數小模型搭配記憶層的對話與任務表現

前幾章談了不少架構與原理，這章把場景拉到實測現場。我們刻意選擇一顆只有約四十億參數的輕量模型，搭配 TencentDB Agent Memory 的分層記憶架構，在本地 Ollama 環境跑長程任務，記錄加入記憶層前後的對話品質、token 消耗與任務完成率。選擇小模型不是為了省成本而已，而是為了排除「模型本身太強」的干擾因素，讓架構的效果自己說話。若連四十億參數的模型都能因為記憶層而明顯進步，那架構的價值就不會只停留在「大模型才適用」的窄門裡。

為什麼偏偏是 Gemma 4 E4B，一顆四十億參數的模型

業界談 agent 記憶時，多半用 GPT-4o 或 Claude 這類旗艦模型示範，效果好容易被歸因於模型推理能力強，記憶層的邊際貢獻反而說不清楚。Gemma 4 E4B 是 Google 的輕量開源模型家族成員，參數量約四十億，可以在 M1 Pro 筆電上完整跑本地推論。選它有三個理由：第一，離線執行，整趟測試零雲端 API 呼叫，排除網路延遲與服務中斷的變數；第二，參數量小，任何效果差異更能歸因於記憶層的設計，而不是模型本身的理解力；第三，貼近台灣中小企業的真實處境，多數公司不會為了導入 AI 助理而立刻採購高階 GPU 伺服器，用現有筆電跑小模型才是常態。

三十次運行的實驗輪廓，Pawel 怎麼設計對照

目前最值得參考的獨立第三方實測，來自開發者 Pawel 在 Medium 發表的文章，時間是 2026 年 5 月 26 日。他故意把模型縮到 Gemma 4 E4B，跑在 M1 Pro 的本地 Ollama 上，共設計十組工作簡報（brief）、三組對照條件、三十次完整運行，全程零雲端呼叫。實驗的核心問題很直接：同一顆小模型，有記憶層與沒有記憶層，在長程任務的 token 總量、任務完成率與對話連貫性上，到底差多少。Pawel 在文章裡用「The 20K → 3K moment」形容 token 大幅下降的關鍵瞬間，並下了「架構在小模型也點火」的結論。

實驗條件有幾個值得注意的細節：

• 每輪任務都包含多回合工具呼叫，模擬真實工作的搜尋、讀檔、改程式碼流程
• 任務長度刻意拉長，讓單一 session 的脈絡超過模型原生的上下文窗口
• 對照組不掛任何記憶層，實驗組掛 TencentDB Agent Memory 的分層記憶
• 評估方式以任務完成度為準，而不是模型回答得像不像

這組設定之所以可信，在於它把變因控制得很乾淨，小模型、本地執行、長任務，三項條件都指向同一個問題：記憶架構能不能讓小模型扛住大任務。

Token 消耗的變化，從 20K 到 3K 的關鍵瞬間

長程任務最燒 token 的地方，通常不是對話本身，而是工具 log。搜尋結果、錯誤軌跡、程式碼片段，累積起來動輒數十萬 token，塞進上下文既浪費又稀釋注意力。TencentDB Agent Memory 的做法是先把完整 log 卸載到外部檔案 refs/*.md，再抽取出關係結構，用 Mermaid 畫布呈現任務拓撲，帶上 node_id 之後只有幾百 token。Agent 在 context 裡只看精簡的狀態圖，需要驗證細節時才用 node_id 回去撈原文，這正是官方宣稱 token 能大幅下降的架構基礎。

Pawel 的實測數據印證了這條路徑：token 總量直降超過百分之五十。官方 README 宣稱 WideSearch 的 token 消耗從 221M 降到 85.6M，節省百分之六十一點四。兩組數字來自不同環境，但方向一致，都顯示記憶層對 token 的壓縮效果不是微小改善，而是數量級別的變化。對照「20K 到 3K」的瞬間，節省的不只是成本，更是讓原本會被截斷的長任務有了完整執行的空間。

任務完成率與召回準確度的對照

省 token 如果犧牲任務品質，那就只是省錢而已。Pawel 的三十次運行顯示，任務完成率不但沒有下降，反而上升百分之二十三。這與官方 README 宣稱 WideSearch 成功率從百分之三十三提升到百分之五十，方向吻合。兩個來源都指向同一個現象：記憶層讓 Agent 在長程任務中更不容易遺失關鍵脈絡。

召回準確度方面，官方宣稱 PersonaMem 的準確率從百分之四十八提升到百分之七十六，使用者事實召回率從低於百分之三十提升到百分之七十九。其中運作的機制是 BM25 關鍵字精確命中加 Embedding 語意模糊匹配的雙路召回，再用 RRF 融合排序，語意相關不漏，精確匹配不丟。Pawel 的實測沒有單獨揭露召回準確度，但任務完成率的提升，間接說明記憶層回傳的資訊有足夠品質支撐決策。

擺在表格裡容易產生錯覺，好像兩組數字可以直接比較。實際情況要分開看。官方數字都是 vendor-run，由騰訊雲團隊在自己的測試環境產出，目前整個 agent-memory 領域各家 benchmark 各自為政，沒有公平的第三方對照，因此官方 README 的數據只能標記為「官方宣稱」。Pawel 的實測反而是目前少數可以放心引用的獨立數據，因為他公開了模型、環境與運行次數，具備可重現的基礎。

放下數字之後，小模型實測的啟示與限制

這組實測最有價值的訊息，不是準確率從多少變多少，而是「架構本身有效」這件事被獨立驗證了。四十億參數的小模型，在本地機器上，靠記憶層的設計補足了上下文不足的弱點，這打破了「效果好全靠大模型」的迷思。對於資源有限的使用者，這代表不需要先砸大錢買頂規硬體，就能從記憶架構得到可量測的改善。

不過，測試結果也有不能忽視的陰影面。Reddit 上有開發者回饋，記憶捕捉還是太被動，常常要使用者主動喊「記住這個」，Agent 才會把資訊寫入記憶層，距離理想中的自動記憶還有段距離。記憶膨脹也是實際痛點，跑久了累積太多低價值紀錄，反而增加檢索雜訊。v2.0 正式版推出僅數天，團隊級資產管理功能缺乏長時間生產環境的考驗，導入前必須用自己的工作負載重新驗證，不能直接把官方宣稱當成保證。

台灣工程師 blog.aihao.tw 在 2026 年 4 月的文章提出一個平衡觀點：大多數記憶功能其實不需要向量檢索，真正的難關在治理，也就是寫入、整理、讀取與遺忘的規則。記憶不是把過去塞回上下文，而是從過去推理出這次該怎麼做。這個觀點與 TencentDB 的分層加證據鏈方向部分呼應，但提醒我們別被華麗的檢索技術分散注意力，記憶系統能不能在團隊裡長期運作，取決於脈絡是否完整、權限是否清楚、過期記憶有沒有淘汰機制。

把這章收束成一句話：四十億參數的小模型搭配記憶層，確實能跑出接近大模型的長程任務表現，這對台灣多數預算有限的中小企業是好消息。但好消息不等於可以盲目複製，實測數字終究要回到自己的場景重跑一遍，確認記憶層在你們的工作流程裡，也能點起那把火。

深入探討：L0-L3 分層記憶與 Mermaid 符號化在實測中如何運作

上一章提到，真正的記憶系統必須從過去推理出這次該怎麼做，而不是把歷史整段倒回上下文。TencentDB Agent Memory 的實驗設計正好回應了這個挑戰，它把記憶拆成兩條路徑：長期記憶用 L0 到 L3 的語意金字塔，短期任務的工具記錄則用 Mermaid 圖壓縮。兩者加起來，回答了記憶系統最核心的問題，壓縮之後，證據還找不找得回來。

長期記憶四層金字塔：上層管判斷，下層管證據

L0 是最底層的原始對話記錄，系統採用 SQLite 或 JSONL 格式全量保留，不做摘要、不做清洗，保留每一次對話的完整內容。這層的定位很明確，就是兜底，當上層記憶互相矛盾、資訊不足，或是 agent 需要確認使用者實際說過的原始語句時，隨時可以翻回 L0。很多人以為記憶系統的價值在於篩選與丟棄，但 TencentDB 的設計恰恰相反，先保留全部原文，才有資格談壓縮。

L1 是原子事實層，從對話中抽取出「使用 NextJS」「偏好週五開會」這類單一、可驗證的事實，並且逐一打上標籤，讓精確檢索可以命中。L2 是場景塊，把一段任務的來龍去脈整理成 Markdown 檔案，比方說一次報價流程的完整脈絡，包括決策過程、遇到的困難與最終結論，人類直接開啟檔案就能讀懂。L3 是人物畫像層，對應 persona.md，累積使用者的技術偏好、程式碼風格、常用工具鏈等長期穩定的屬性。

這四層之間的運作邏輯，官方文件用一句話點明：上層管判斷，下層管證據。召回時先看 L3 的人物畫像，細節不足就往 L2 的場景塊鑽，場景結論再往下對到 L1 的原子事實，證據還是不夠，才翻 L0 的原文。舉例來說，系統判斷使用者偏好 TypeScript，這個判斷來自 L3；L3 的結論可以追溯到 L2 某個專案場景的技術選型記錄；場景結論在 L1 有對應的原子事實陳述；而這條鏈的最末端，是 L0 裡使用者實際說過的那句話。

這條證據鏈最大的意義，是回應記憶系統常見的誠信危機。很多抽取式記憶會把對話摘要成一行文字，之後的 agent 只知道結論，不知道結論從哪裡來，一旦摘要錯誤或脈絡失真，整個判斷就跟著歪掉。TencentDB 用可追溯的機制解決這個問題，壓縮了，但不丟證據。官方宣稱 PersonaMem 準確率從 48% 提升到 76%，用戶事實召回率從不到 30% 提升到 79%，這些數字出自官方 README（2026），屬於開發團隊自測，讀者參考時應留意數據來源。

短期任務的 Mermaid 畫布：幾十萬 token 縮成幾百 token

另一條路徑處理的是長任務中最燒 token 的工具記錄。搜尋結果、錯誤軌跡、程式碼片段，累積下來動輒幾十萬 token，直接塞進 agent context 既不現實，也會稀釋模型對當前任務的注意力。TencentDB 的做法是把完整 log 卸載到外部檔案 refs/*.md，再從中抽取任務的關係結構，畫成一張帶有 node_id 的 Mermaid 圖，只把這張圖注入 agent context，大小大約只有幾百 token。

這張 Mermaid 圖不是線性摘要，而是帶狀態、依賴關係與可尋址索引的任務拓撲圖。每個節點都有自己的 node_id，當 agent 需要驗證某個細節時，可以用 node_id 反查對應的原始記錄。等於把幾十萬 token 的線性文字，重組成一份可以索引、可以追蹤的任務地圖。

這樣的設計對長程任務特別重要。任務進行到一半，agent 必須記得之前做過哪些嘗試、哪些環節互相依賴、下一個動作從哪裡接續，Mermaid 圖用極少的 token 保留了這些結構性資訊，讓 agent 的注意力集中在當前步驟，而不是整個對話歷史。關鍵字是「可尋址」，它把記憶從被動的文字，變成主動的索引，這是單純摘要做不到的事。

雙路召回：BM25 精確命中配上 Embedding 語意匹配

記憶寫入之後，考驗的是讀取。TencentDB 採用兩路召回，BM25 負責關鍵字精確命中，Embedding 負責語意模糊匹配，用 RRF 融合排序。這個組合在真實情境下的意義是，使用者搜尋「上次那個案子怎麼報的」這種語意相近但不含關鍵字的句子，可以透過 Embedding 撈回相關場景；而使用者明確提到某個專有名詞時，BM25 可以精確定位，不會因為語意向量化的些微偏差而漏掉。

雙路召回搭配前述的證據鏈，在真實查詢中形成完整的閉環。先由 RRF 排序找出最相關的記憶層級，再順著 L3 到 L0 的鏈路往下驗證，確保交給 agent 的每一條記憶都有原文撐腰。官方宣稱 WideSearch 成功率從 33% 提升到 50%，token 用量節省 61.4%，出自官方 README（2026），同屬開發團隊自測數據，參考時須區分官方宣稱與第三方實測的差別。

獨立實測：四十億參數的小模型也能點火

架構說得再好，終究要經過實測。獨立開發者 Pawel 在 Medium 發表實測文章（2026-05-26），刻意把模型縮小到 Gemma 4 E4B，約四十億參數，跑在 M1 Pro 的本地 Ollama 環境，全程零雲端呼叫。實驗涵蓋 10 組 brief、3 組對照、共 30 次運行，結果 token 用量下降超過 50%，任務完成率反而上升 23%。

這項測試最值得參考的地方，在於排除了模型本身能力的干擾。四十億參數的模型原本在長程記憶任務上表現平平，加入記憶層之後卻能與大模型一拚，代表架構本身確實有效，不是靠強模型硬撐出來的。台灣多數中小企業不可能為了記憶功能維護一個超大模型，Pawel 的實驗證明了可行的替代路徑。

不過台灣工程師 blog.aihao.tw 的分析（2026-04-28）也提醒我們，大多數記憶功能不需要向量檢索，ChatGPT、Claude、Mastra 的實作都不用向量，真正困難的是治理。分層方向與證據鏈的設計值得肯定，但向量檢索不是萬靈丹，記憶系統能不能長期運作，取決於寫入規則、整理時機、權限控管與過期淘汰機制有沒有被認真對待。此外，Reddit 社群的實務回饋也點出記憶膨脹與捕捉被動的問題，使用者常要主動喊「記住這個」，遺忘機制至今仍未完全解決。

替代方案有限公司觀點

我們認為 TencentDB Agent Memory 對台灣市場的價值，不在於它用了多先進的技術，而在於它把小模型長程任務的可能性攤開來給大家看。台灣中小企業的日常營運，從報價、客服到訂單追蹤，多半是重複性高、流程固定，卻橫跨多個會話的工作，過去的 assistant 每次對話都像失憶，老闆必須重複交代任務脈絡，這才是導入 AI 最痛的環節。L0 到 L3 的分層設計讓我們看到一條務實的路，對話先全量保留，再逐步提煉成事實、場景與畫像，每一層都有明確用途，不是為了炫技。

我們建議有興趣的團隊先從 Hermes 外掛方式開始試，不要急著部署三件式 Docker 架構。用現成的 agent 框架掛上 memory provider，挑一兩個真實的工作流程丟進去跑，觀察記憶分層是否真的能讓 agent 記住客戶偏好、專案決策與歷史脈絡。同時要對官方宣稱的效能數字保持合理懷疑，所有 benchmark 都是開發團隊自測，回到自己的場景重跑一遍，才是負責任的導入方式。

Mermaid 符號化壓縮對台灣開發者還有一層額外意義：這些圖是人類可讀的，團隊成員可以直接開啟記憶檔案，檢視 agent 到底記了什麼，不需要理解向量或嵌入的運作細節。這種透明性對建立信任很有幫助，老闆不用把記憶系統當黑盒子。我們認為，這正是分層記憶比起純向量檢索更適合台灣中小企業的原因，證據透明，決策才安心，導入的門檻也相對低。

台灣觀點：記憶功能真的需要向量檢索嗎？從 blog.aihao.tw 的反思看記憶治理

當各家的記憶系統都把「向量檢索」掛在嘴邊，台灣工程師在部落格 blog.aihao.tw（2026-04-28）發表的觀點顯得很不合時宜，卻令人玩味。他直接點名：ChatGPT、Claude Code、Claude API、OpenAI cookbook、Mastra SOTA，這些實際運作的記憶功能，沒有一個依賴向量資料庫。真正困難的地方不在於用哪種技術把資料撈回來，而在於治理。具體來說是四個動作：寫入、整理、讀取、遺忘。這段話值得我們停下來想，因為它把問題從「怎麼查」拉回到「怎麼管」。

延續部落格的反思：記憶不是塞回上下文，而是推導出做法

blog.aihao.tw 對記憶的定義很精準：記憶不是「把過去塞回上下文」，而是「從過去推理出這次該怎麼做」。如果只是把對話歷史一股腦丟給模型，那叫暫存，不叫記憶。真正的記憶系統應該在寫入時就決定什麼值得記，整理時將零散事實歸納成可用的脈絡，讀取時只撈出當下需要的片段，遺忘時則要判斷哪些資訊已經過期或不再適用。這四個動作環環相扣，任何一個環節失靈，記憶不但幫不上忙，還會變成雜訊的來源。

這個觀點與 TencentDB Agent Memory 的設計理念存在有趣的共鳴。該專案在 2026 年 5 月開源，7 月曾登上 GitHub Trending 第一名，截至 8 月 9 日獲得 18，423 顆星（來源：GitHub API，2026）。它的核心並非「存更多」，而是把記憶分層：L0 保留原始對話，L1 抽取出原子事實，L2 組織成場景塊，L3 建立使用者畫像。官方 README（2026）宣稱，用戶事實召回率從不到 30% 提升到 79%。這個數字固然是官方自測，但架構思路確實呼應了「治理優先」的邏輯，它先把記憶分門別類，再決定如何取用。

兩條路線的異同：分層方向一致，向量卻不是必需品

將 blog.aihao.tw 的觀點與 TencentDB 的方案對照，可以發現兩者都拒絕把記憶系統做成「大型全文檢索」。TencentDB 雖然採用 BM25 與 Embedding 雙路召回，再用 RRF 融合排序，但向量僅是選配的檢索工具，記憶的主體是金字塔內部的結構化關係。L3 畫像說使用者偏好 TypeScript，可以一路追溯到 L2 的專案場景、L1 的原子事實，再到 L0 使用者親口說出的那句話，證據鏈完整且透明。這種設計讓記憶可以「被檢查」，而不是一個只會吐出相似內容的黑盒子。

兩條路線的差異在於複雜度。blog.aihao.tw 主張大多數場景用簡單的檔案、標籤與規則就能達成記憶效果，只有少數語意模糊的查詢才需要向量。TencentDB 則將治理流程產品化，提供 Chat Memory、Skill、Wiki、CodeGraph 四種資產，並透過 Memory Hub 讓團隊管理可見性與版本。前者適合個人或小型團隊快速上手，後者則為企業級規模設計，但也因此背負了更高的部署成本與學習門檻。

獨立第三方實測提供了一個參考點。Pawel 在 Medium（2026-05-26）發表實測，刻意將模型縮小到 Gemma 4 E4B、約 40 億參數的規模，在 M1 Pro 上本地執行，結果 token 消耗下降超過五成，任務完成率反而提升 23%。他的結論是「架構在小模型也點火」，代表分層與符號化記憶的有效性不依賴頂尖模型。這也間接支持了 blog.aihao.tw 的想法：記憶的品質來自治理流程，而不是檢索技術的先進程度。

實測中仍然存在的治理問題

方向對了，並不代表問題解決。我們在 Reddit 社群與 GitHub issues 的討論中，看到幾個尚未克服的治理痛點。第一是寫入的被動性。多位 r/openclaw 使用者回饋（2026），目前的記憶捕捉機制仍偏被動，使用者常需要主動說「記住這個」，agent 才願意寫入，這與人腦自動記憶的習慣相去甚遠。第二是記憶膨脹。長期運作的 agent，L0 原始資料持續堆疊，官方聲稱的 token 省 61.4%（官方 README，2026）並未完全消除儲存成本，整理與濃縮工作依然沉重。第三是遺忘機制幾乎空白，目前系統能做的就是刪除或標記過期，卻沒有主動判斷「哪些記憶該被淡忘」的智慧。第四，官方宣稱的 benchmark 都是開發團隊自測，例如 WideSearch 成功率從 33% 提升到 50%（官方 README，2026），真實環境能否重現，需要自己驗證。

替代方案有限公司的觀點：先治理，再談向量

我們的觀察是，台灣多數中小企業的導入困境，根本不是「向量檢索不夠快」，而是記憶的寫入規則、整理流程與遺忘策略根本還沒建立。許多團隊買了向量資料庫，卻發現記憶反而變得更亂，因為什麼都塞進去，撈出來的片段缺乏脈絡。因此我們建議，導入記憶系統的第一步不該是比較哪家向量效能好，而是先盤點自己的業務流程，定義「什麼值得記」，並設計寫入的規範，例如強制標註時間、來源與分類。第二步，從規模最小的場景開始，例如客服對話的客戶偏好記錄，用 TencentDB 的 L0 到 L3 分層，或甚至單純的 Markdown 檔案加標籤即可。我們也必須誠實指出，TencentDB Agent Memory 的 v2.0 才剛發布、團隊功能仍有 bug 回報（GitHub issues #846，2026-08-07），且三件套 Docker 部署對中小企業並不友善，比較務實的路線是從 Hermes 外掛或是 OpenClaw 這類既有工具開始。我們認為，記憶治理終究要回到人，工具只是輔助，能把「寫入、整理、讀取、遺忘」四個環節理清楚的團隊，就算只用最樸素的技術，也能讓 agent 真正記住該記的事。

替代方案有限公司觀點：SME 導入開源記憶引擎的務實建議

過去兩個月，我們持續把 TencentDB Agent Memory 裝進 Hermes 實際運行，也試著在 OpenClaw 上掛載同一套記憶引擎。這篇文章不打算重複官方架構說明，而是回到台灣中小企業（SME）的現場，誠實評估導入開源記憶引擎的效益與維護成本。我們看過太多團隊急著裝新工具，卻忘了先回答一個根本問題：你要這套記憶系統幫你記住什麼？

先講結論：導入這套工具，最難的往往不是安裝，而是記憶治理的紀律。記憶引擎只是容器，裝進去的內容決定了它有沒有價值。我們建議從三個方向開始，這三個方向分別對應：定義記憶範圍、控制功能規模、建立清理習慣。

建議一：先想清楚要記什麼

TencentDB Agent Memory 的 L0 到 L3 分層設計，從原始對話、原子事實、場景塊到用戶畫像，理論上很完整。官方 README 宣稱，PersonaMem 準確率可以從 48% 提升到 76%（官方 README，2026），用戶事實召回也從不到 30% 拉高到 79%（搜狐轉述官方，2026）。但這些數字是官方自測，我們實測的感受是，架構確實有效，前提是你知道自己要記哪些東西。

以台灣常見的客服場景為例，真正的記憶痛點往往是：客戶上次專案做到哪裡、報價有沒有被否決、窗口偏好用電子郵件還是電話。這些屬於 L1 原子事實和 L2 場景塊，不需要動用完整的 L3 用戶畫像。我們建議，先列出十個你希望 agent 記得的事情，再反推要用哪一層記憶。反過來做，只會得到一個塞滿雜訊的資料庫，檢索效率反而比不裝還差。

建議二：只用必要模組

v2.0 正式版在 2026-08-03 推出，一口氣端出 Chat Memory、Skill、Wiki、CodeGraph 四大記憶資產，外加 Memory Hub 三件套 Docker 部署。對台灣多數十人到五十人的中小企業來說，全上絕對不是好主意。CodeGraph 需要完整的程式碼倉儲索引，Wiki 需要團隊持續維護結構化文件，這些都是隱性人力成本。

我們的建議是，從 Hermes 外掛方式開始，只開 Chat Memory 與基本檢索功能。官方 SDK 提供 TypeScript 與 Python 雙客戶端，接進既有 agent 的難度不高。跑兩週，記錄實際改善的任務完成率，再決定要不要往 Skill 或 Wiki 推進。我們看過太多團隊在第一週就急著把所有功能打開，結果一個月後記憶庫亂到沒人敢讀，只能砍掉重練。

建議三：建立定期清理記憶的習慣

Reddit r/openclaw 的用戶回饋（2026）點出兩個真實痛點：捕捉太被動，以及記憶膨脹。前者的意思是，agent 不會主動判斷什麼值得記，常常要人類開口說「記住這個」；後者則是，記憶只進不出，久了系統回應速度與品質都會下降。TencentDB Agent Memory 的遺忘機制還沒有完全解決這個問題，GitHub issues 到 2026-08-07 仍有 bug 回報（issue #846），官方承諾 24 小時內回應，但這代表它仍在快速迭代。

務實的做法是，把清理記憶排進每週維護工單。我們的做法是每週五下午花三十分鐘，檢查 L1 原子事實是否過期、L2 場景塊是否還有參考價值，刪掉重複的條目。記憶治理的本質是資料治理，沒有定期清理，再好的架構也會被雜訊淹沒。

關於官方數字，我們必須誠實提醒：官方 README 宣稱 WideSearch 的 token 消耗從 221M 降至 85.6M，節省 61.4%（官方 README，2026）；獨立實測者 Pawel 在 Medium 上以 Gemma 4 E4B 約 40 億參數的本地模型測試，也得到 token 降低超過 50%、任務完成率提升 23% 的結果（Pawel，Medium，2026-05-26）。方向一致，但幅度有落差，而且測試情境完全不同。我們的建議是，別拿官方數字去跟老闆保證投資報酬率，先用自己的業務情境跑一輪小型實驗再說。

替代方案有限公司的立場

我們認為，TencentDB Agent Memory 在架構上確實是目前開源記憶引擎裡少數把「證據鏈」講清楚的專案。L0 到 L3 的分層，讓上層判斷可以追溯到下層原始證據，這個設計比只靠向量檢索的抽取式方案更適合台灣企業的稽核需求。但我們也要說實話：官方宣稱的數據都是 vendor-run，整個領域的 benchmark 各自為政，Mem0 自家宣稱的分數與第三方實測相差甚遠（digitalapplied，2026-08-04），所以任何數字都要打折看。

對於台灣中小企業，我們的落地建議很直接：不要急著部署三件套 Docker，那只會讓 IT 人力有限的團隊陷入維護地獄。先從 Hermes 或 OpenClaw 的既有環境掛載記憶引擎，只記錄真正會影響決策的客戶偏好與專案狀態，為期一個月，讓團隊實際感受記憶帶來的改變。我們相信，記憶工具終究只是輔助，能把寫入、整理、讀取、遺忘四個環節理清楚的團隊，就算用最樸素的 Markdown 檔案，也能讓 agent 真正記住該記的事。

中國智能體記憶市場預估從 2025 年的 14.4 億人民幣成長到 2030 年的 642.5 億人民幣，年複合成長率超過 110%（愛分析報告，經博客園轉述），這塊市場確實會快速膨脹。但台灣中小企業不需要搶先導入所有新功能，反而應該挑選成熟、穩定、社群回饋透明的方案。我們的建議是，先小規模試用三個月，用真實業務驗證記憶引擎的價值，再決定是否擴大。

結論：動手實測的收穫與下一步（歡迎聯絡我們）

這系列文章從 AI 記憶的痛點開始，一路走到架構拆解、安裝實作、團隊功能與競品比較，現在該是收束成果的時候。前面章節提到許多官方宣稱的數據，但真正值得信賴的，往往是第三方動手實測的結果。我們特別看重一場規模不大卻設計嚴謹的獨立實驗，它用實際數據回答了多數台灣企業最關心的問題：記憶架構是不是只靠強大模型撐場面？

架構在小模型身上依然有效

這場實驗刻意把模型縮小到 Gemma 4 E4B，參數量約 40 億，跑在 M1 Pro 筆電的本地 Ollama 環境，全程零雲端呼叫。作者準備了 10 組任務簡報、3 組對照條件，共 30 次運行，結果 token 消耗減少超過 50%，任務完成率反而提升 23%（來源：Pawel，Medium，2026-05-26）。這項結果打破了「記憶工具只是強模型的附屬品」的直覺，證明分層記憶與符號化壓縮的架構本身就能獨立貢獻價值。對台灣開發者來說，這代表不需要採購昂貴的 GPU 主機，也不必承擔雲端 API 的持續費用，一台 MacBook 或普通工作站就能重現這套實驗，親手驗證記憶引擎的效果。

我們從中歸納出第一個清楚收穫：記憶架構把「記住」這件事從模型能力中抽離出來，讓小模型也能靠架構優勢改善任務表現。這種特性對預算有限的中小企業特別有吸引力，因為落地成本大幅下降。同時，這也證明了記憶市場的競爭本質不在模型大小，而在於寫入、整理、讀取、遺忘這四個環節有沒有被妥善設計。

捕捉機制仍舊偏被動

社群回饋揭示了第二個收穫：目前的捕捉機制還是偏被動。Reddit 的 r/openclaw 討論區有使用者反映，agent 常常需要人類主動喊「記住這個」，否則關鍵資訊不會自動進入長期記憶（來源：Reddit r/openclaw）。這讓我們重新思考「寫入」環節的設計，TencentDB Agent Memory 的分層金字塔能妥善保存已捕捉的內容，但捕捉的起點仍依賴對話內容，而人類在實際協作時，許多重要資訊並非以對話形式出現。例如工程師從終端機下指令、設計師在 Figma 上調整版型，這些行為都是脈絡，卻不會自然流入記憶引擎。這正是台灣工程師 blog.aihao.tw 所提醒的：真正難的不是向量檢索，而是寫入、整理、讀取、遺忘四個環節的治理（來源：blog.aihao.tw，2026-04-28）。

換句話說，記憶工具能解決「記得牢不牢」的問題，卻還沒有完全解決「該記什麼」的問題。Reddit 的 r/AI_Agents 討論區也出現過類似的質疑：記憶真的有改變 agent 未來的行為嗎？還是只是把過去的對話塞回上下文而已。我們認為，這個質疑點出了整個領域的共同功課，也提醒台灣企業在導入時，不要只盯著記憶容量，要先想清楚哪些資訊值得被記住。

記憶膨脹與遺忘機制尚未收斂

第三個收穫來自記憶膨脹的痛點。即使透過 Mermaid 符號化把幾十萬 token 的 log 壓縮成數百 token 的任務拓撲圖，長期累積下來，記憶資產仍會持續增長，而系統目前的遺忘機制還沒有完全解決這個問題。官方在 2026-08-03 才釋出 v2.0 正式版，距離我們撰寫這篇文章僅六天，團隊級功能仍在快速迭代，GitHub issues 上 2026-08-07 仍有 bug 回報（來源：GitHub issues）。換句話說，記憶膨脹不是架構缺陷，而是需要時間驗證與調校的成熟度問題。我們也必須誠實提醒讀者，官方 README 中的 WideSearch token 省 61.4%、PersonaMem 準確率從 48% 提升到 76% 等數據，都是官方自測結果（來源：官方 README），並非第三方公正 benchmark，參考時要留一分餘地。

回到台灣市場的落地場景，我們建議企業不要急著把整套 Docker 三件套搬進生產環境。先挑選一條重複性高的流程，例如專案提案的客戶偏好記錄或客服歷史查詢，把 agent 部署在一次性任務上，觀察記憶的寫入品質與召回準確度。試用期設定三個月，每週固定檢視記憶資產的內容，確認是否有過時或互相矛盾的資訊，再考慮擴大範圍。這個循序漸進的節奏，能讓團隊在不影響日常營運的前提下，實際感受記憶引擎帶來的改變。

動手實測的收穫，說穿了就是三件事：架構在小模型身上證明有效、捕捉機制有待改進、記憶膨脹需要靠時間驗證。記憶工具終究只是輔助，能把寫入、整理、讀取、遺忘四個環節理清楚的團隊，才能讓 agent 真正記住該記的事。如果你在安裝或試用過程中遇到任何問題，或者想分享自己的實測經驗，歡迎隨時寫信到 [email protected]，我們會親自回覆，一起討論最適合台灣中小企業的記憶方案。