一張圖搞懂 AI 記憶金字塔：TencentDB Agent Memory 如何用 L0-L3 分層壓縮又不丟證據
目錄
共 39 個章節
為什麼 AI Agent 一直忘記你交代的事：從痛點看記憶分層的必要性
你是否有過這樣的經驗：花了二十分鐘把公司產品的定價邏輯、目標客群、常用語氣一次交代給 Claude 或 ChatGPT，窗口才剛關掉，下一次開新對話，它就問你「請問貴公司的產品主打什麼？」這不是使用者的操作失誤，而是當代 AI Agent 普遍存在的記憶缺陷。尤其在跨多輪、跨任務的長流程裡，遺忘不是偶發，而是結構性問題。
根據 TencentDB Agent Memory 的深度研究報告（2026-08-09），這個痛點已經不是單一產品的瑕疵，而是整個 agent 生態的共同挑戰。還沒看過這個工具是什麼的讀者，可以回頭讀上一篇 AI 老是忘記你交代的事？TencentDB Agent Memory 開源記憶引擎，讓 AI 真正『記得』你，這篇直接拆解它的記憶分層；本文則從實際場景出發，拆解 AI 為何頻繁遺忘、token 為何爆量，再看分層記憶架構如何從根本上回應這個問題。
痛點一：使用者偏好被當成一次性資訊
多數對話型 AI 的記憶方式，是將全部歷史壓進一個線性上下文。當對話長度逼近上限，最早的內容會被悄悄丟棄，或被壓縮成一段概括。你上週才告訴它「我們公司不接十萬元以下的案子」，這週開新任務時，它卻把五百萬的預算寫進提案。原因很簡單：那條偏好訊息已經被滾出窗口了。
重複犯錯是另一個訊號。使用者反覆修正同一種錯誤，agent 卻在下一次任務中重蹈覆轍。官方 README 中提到的 PersonaMem 指標，正是量測模型對使用者畫像的掌握程度，官方宣稱其準確率從 48% 提升到 76%，提升了 59%；用戶事實召回率從不到 30% 拉到 79%（來源：官方 README、搜狐轉述）。這組數字反向說明了，在沒有記憶架構的狀況下，agent 對使用者的理解有多麼脆弱。
痛點二：工具 log 把 token 預算吃光
現代 agent 幾乎都要呼叫外部工具：搜尋、讀檔、執行程式、抓取網頁。每一次工具呼叫都會留下完整 log，錯誤軌跡、搜尋結果、程式碼片段，動輒幾十萬 token。官方 README 指出，在一次長程任務的基準測試 WideSearch 中，原始方案的 token 消耗高達 2.21 億，而使用記憶壓縮後降到 8，560 萬，省下 61.4% 的 token（來源：官方 README）。
這些 log 佔據的空間，排擠了真正重要的使用者指令與任務目標。更糟的是，多數 agent 並沒有能力判斷哪些 log 值得保留，哪些只是雜訊。於是「記得多」與「記得住重點」之間，形成明顯的落差。
痛點三：壓縮過頭，證據鏈斷裂
有些系統意識到 token 壓力，改用摘要方式壓縮記憶。摘要的問題在於，它把證據變成結論，把「你上次說偏好用 Next.js 開發」壓縮成「使用者偏好現代前端框架」。當 agent 只依賴摘要做判斷，一旦摘要本身失真，錯誤會被放大，而且追不回原始依據。
台灣工程師部落格 blog.aihao.tw（2026-04-28）也點出類似觀察：記憶的重點不是「把過去塞回上下文」，而是「從過去推理出這次該怎麼做」。若壓縮過程丟失原始證據，推理就會失去支撐。
為什麼「存更多」不是答案
直覺上，記憶不足就加大記憶體，把對話歷史買好買滿。但線性堆疊只會加重問題：token 越多，模型越難在龐大噪音中鎖定關鍵資訊，搜尋與推理成本同步上升。研究報告中的獨立實測提供了有力佐證：Pawel 在 Medium（2026-05-26）故意把模型縮小到 Gemma 4 E4B，約 40 億參數，在 M1 Pro 上本地跑 30 次測試，結論是架構本身在小模型也「點火」成功，token 消耗下降超過五成，任務完成率反而上升 23%（來源：Pawel/Medium）。這代表問題的根源不在模型大小，而在記憶被結構化的方式。
分層壓縮，保留一條完整證據鏈
TencentDB Agent Memory 給出的解法不是「存更多」，而是「分層壓縮」。它把長期記憶切成四個層級，L0 到 L3。L0 保留原始對話全文，SQLite 與 JSONL 格式，作為兜底查詢的依據；L1 是原子事實層，把「使用 Next.js」「偏好週五開會」拆成可標籤、可精確召回的最小單位；L2 是場景層，把同一件任務的來龍去脈組織成人可讀的 Markdown 文件；L3 則凝聚成用戶畫像，描述技術偏好、程式碼風格與常用工具鏈（來源：官方 README）。
這個設計的中心思想是：上層管判斷、下層管證據。agent 判斷時先參考 L3 的畫像，細節不足就往下鑽到 L1，證據出現爭議時還能翻回 L0 的原始文字。整條證據鏈不中斷：「L3 說偏好 TypeScript，追溯到 L2 場景塊，場景結論追溯到 L1 原子事實，原子事實指向 L0 你說過的那句話」。壓縮了，但不丟證據。
短期任務的部分，它用 Mermaid 圖畫布取代線性 log。工具 log 被卸載到外部檔案，抽取出關係圖，只把精簡的任務拓撲圖注入 agent 的 context，要驗證細節時再透過 node_id 往回撈。這套做法讓 agent 在 context 裡看到的不是一條長長的 log 流水帳，而是一張具有狀態與依賴關係的任務地圖（來源：官方 README）。
結語：記憶的下一步是結構
AI Agent 的記憶問題，本質上是資訊組織的問題。線性塞入、暴力堆疊的做法已經觸到天花板，而分層壓縮加符號化索引，提供了另一條可行的路徑。以 TencentDB Agent Memory 為例，開源不到三個月已在 GitHub 累積超過 1.9 萬顆星與 1,700 次 fork（來源：GitHub，2026-08），社群討論的熱度，印證了這不是少數工程師的焦慮，而是整個產業正在面對的基礎課題。
下一次當你發現 agent 又忘記你的要求時，先別急著責怪模型不夠聰明。真正的問題，可能出在它根本沒有一套分層記憶，把「重要的事」與「發生過的事」分開存放。
L0-L3 記憶金字塔總覽：原文、事實、場景、畫像四層各管什麼
這一章我們把鏡頭拉近，直接拆解 TencentDB Agent Memory 的核心架構。用一句話概括它的設計哲學：記憶不是「存更多」，而是「分層管」。官方把長期記憶切成四個層級，從最底層的原始對話紀錄，一路抽象到最頂層的用戶畫像，每一層各有職責、各自存放、彼此咬合，形成一條完整的證據鏈。
這個架構是 2026-05-14 開源的，到了 8 月 3 日釋出 v2.0 正式版，7 月 8 日曾登上 GitHub Trending 第一名（來源：Trendshift）。截至 2026-08-09，GitHub 星數 18，423、fork 1，660、MIT 授權（來源：GitHub API）。數字本身不代表一切，但社群關注度確實反映了一個訊號：大家在 agent 記憶這題上，迫切需要一個有系統的答案。
我們把四層攤開來逐一檢視。
L0 Conversation：原文全保留，隨時可回查
最底層是 L0 Conversation，也就是原始對話紀錄。它不做事先加工、不做摘要、不做重點抽取，就是把每一輪 user 與 agent 之間的對話完整存下來，實作上以 SQLite 或 JSONL 格式存放。這一層的定位很明確：兜底。當任何上層判斷出錯、證據不足、或者需要查證某一件事的原貌時，L0 都是最終的仲裁者。
舉例來說，假設 L3 畫像層記錄「使用者偏好 TypeScript」，但某天使用者對一個專案要求用 JavaScript 實作。這時 agent 該聽誰的？答案不是猜，而是往下鑽到 L0，翻找原始對話，確認那條「偏好 TypeScript」的結論，是使用者親口說的，還是 agent 自己推論的。如果是親口說的，那是穩定偏好；如果是推論的，可能只是單次專案的巧合。這個差別，只有保留原文才分辨得出來。
L0 的代價顯而易見，它最占空間，保存的是未經壓縮的內容。但它換來的回報是：整條記憶鏈的源頭始終可追溯。沒有 L0，上層的推論就失去了事實地基。
L1 Atom：原子事實，打上標籤的精確彈藥
再往上一層，是 L1 Atom，原子事實層。這層做的事情是從 L0 原文中抽取獨立的事實片段，像是「使用者使用 Next.js 框架」「使用者偏好週五下午開會」「這個專案的部署環境是 K8s」，每一條都是一個可獨立引用的事實單位。官方稱之為 Atom，意思是不可再分割的最小知識單元。
L1 與 L0 的關鍵差異在於：L0 是流水帳，L1 是提煉過的情報。每個 Atom 都會被加上標籤（tag），作為檢索的索引鍵。這層的職責是精確召回。當 agent 需要知道一個具體事實時，直接命中 L1 就拿到答案，不需要回頭讀整段對話。
例如使用者說「我上次跟你說過，我們公司用 AWS 不是 GCP」。這句話落在 L0 是一段對話，落在 L1 就是一筆結構化事實：「公司雲端平台偏好 = AWS」。下次 agent 在規劃部署架構時，這筆 Atom 就被撈出來，直接影響它的決策。
L1 的缺點也很明顯：事實是碎片化的，缺乏脈絡。「公司用 AWS」這個事實，若脫離「公司規模、既有服務、成本結構」等背景，可能被誤用。所以 L1 不能獨立運作，它必須被上一層組織起來。
L2 Scenario：場景塊，人讀得懂的 Markdown 脈絡
第三層是 L2 Scenario，場景塊。它把 L1 的原子事實重新組裝成有意義的情境片段，例如一次報價流程的來龍去脈、一次技術選型的決策過程、一次客戶溝通的完整脈絡。存放格式是 Markdown，刻意設計成「人可以直接閱讀」的形式。這點很關鍵：場景塊不只是給 agent 看的，也是給人看的。
想像一個情境：某位使用者過去三週陸續跟 agent 討論過一個新產品的技術架構，包含選型、預算、時程、團隊能力。這些內容分散在好多段對話裡，各自是零散的 L1 事實。L2 做的事，就是把它們收斂成一份完整的「新產品技術規劃」場景文件，記錄了整個討論的來龍去脈、做了哪些決定、還有哪些未決事項。下次使用者說「我們繼續討論那個新產品的架構」，agent 不必從零開始，直接載入這份場景塊，就能接續上下文。
L2 是本層級結構中，兼顧「壓縮率」與「可讀性」的平衡點。它比 L0 精簡，比 L1 有脈絡；agent 靠它理解來龍去脈，人類靠它檢驗 agent 的理解是否正確。這就是為什麼官方選擇 Markdown，而不是結構化 JSON 或資料庫表格：人要能看懂，才有辦法監督。
L3 Persona：用戶畫像，persona.md 的頂層判斷
金字塔頂端是 L3 Persona，用戶畫像。它凝結了對一個使用者的整體理解：技術偏好、程式碼風格、常用工具鏈、溝通習慣、決策模式。存放形式是一份 persona.md 檔案。這層管的是全域判斷：agent 在面對不確定情境時，先參考 L3 來決定「這個人通常會怎麼想、怎麼做」。
官方 README 宣稱，加入 PersonaMem 後準確率從 48% 提升到 76%（+59%），用戶事實召回率從不到 30% 提升到 79%（來源：官方 README，經搜狐轉述）。這些是官方自測數字，寫文章時必須標明「官方宣稱」而非事實，但方向值得參考：畫像層對記憶品質的提升確實有顯著貢獻。
舉例說明 L3 的運作方式：使用者對某個技術方案提出兩個選項，A 方案是穩定成熟的舊技術，B 方案是新潮但風險較高的框架。若 L3 畫像顯示這是一位「偏好新技術、願意承擔風險、追求簡潔寫法」的工程師，agent 就會傾向推薦 B 方案，且用符合使用者習慣的簡潔方式說明。若 L3 顯示這是一位「重視穩定性、討厭花俏、要求文件完整」的資深主管，agent 就會調整立場與溝通風格。
L3 的威力在於它讓 agent 的每一次回應，都能「投其所好」。但風險也在此：若畫像錯誤，agent 會往錯的方向一路錯下去。所以 L3 的正確性，必須依賴下層的證據鏈來校正。
上層管判斷、下層管證據的協作邏輯
這四層的關係，官方用一句話說得很清楚：上層管判斷、下層管證據。
換句話說：agent 在收到任務時，先讀 L3 畫像，理解「這個人是誰、他要什麼」；接著載入 L2 相關場景，掌握「這件事的來龍去脈」；若發現具體細節不足，往下鑽到 L1 原子事實，確認「這個專案確實用某個技術」；再不夠，翻開 L0 原始對話，親眼驗證「他當時到底怎麼說的」。
這是一條不中斷的證據鏈。官方架構的巧妙之處在於，它把「壓縮」與「可追溯」同時做到：每一層都是下一層的摘要，但每一層都留下指回下層的索引。L3 說「使用者偏好 TypeScript」，你可以追溯到 L2 的某個技術選型場景；那個場景的結論，可以追溯回 L1 的原子事實；那個事實，又可以指向 L0 裡使用者說過的那句話。
用一個實際情境串起來會更清楚：
- L3 畫像：「使用者偏好 TypeScript、React、重視可維護性」
- L2 場景：「三個月前討論過會員系統重構，決定用 React + TypeScript，並建立 component 共用庫」
- L1 事實：「使用者說『我們前端一律用 TypeScript，不接受 JS』」
- L0 原文：那段對話的完整紀錄，包含語氣、上下文與其他細節
當使用者今天丟來一個新的前端需求，agent 先讀 L3 確認方向，載入 L2 了解歷史脈絡，再用 L1 驗證具體限制。若還是拿不準，回頭翻 L0。整個過程，agent 不是靠猜，而是沿著證據鏈往上爬。
這正是官方架構與傳統「把所有對話都塞進 context」路線最大的分野。線性塞入只會讓 token 帳單暴漲，而且塞進去的內容彼此沒有結構、沒有優先序。分層金字塔讓 agent 用最少量的資訊做出判斷，需要細節時才往下挖掘，兼顧成本與品質。
檢索機制：BM25 與 Embedding 雙路回召
金字塔的資料結構講完了，接下來是怎麼把對的記憶撈回來。官方採用兩路檢索並行：BM25（關鍵字精確命中）與 Embedding（語意模糊匹配），用 RRF（Reciprocal Rank Fusion）融合排序。
這個設計的邏輯很務實。BM25 負責處理精確的、有明確關鍵字的查詢，例如「上次討論的預算數字是多少」，它能夠精準命中含特定字詞的記憶片段。Embedding 則負責處理語意相似但用字不同的查詢，例如「我們之前評估過的那個雲端服務」與「我們討論過的 GCP 遷移方案」，字面上完全不同，語意上卻是同一件事。
兩路互補，誰也不搶誰的功勞。只有 BM25 會漏掉換句話說的查詢，只有 Embedding 會在精確數字上出錯。RRF 融合排序把兩路的結果合併，讓「精確命中」與「語意相關」同時進入最終結果集。這個機制的意義在於：記憶不是硬碟裡的檔案，而是能依情境彈性取用的知識庫。
獨立實測：小模型也能運作，架構本身的價值
分層架構聽起來合理，但它真的有效嗎？還是只是紙上談兵？獨立開發者 Pawel 做了一組實測，發表在 Medium（2026-05-26），標題是「The 20K → 3K moment」。他刻意把模型縮小到 Gemma 4 E4B（約 40 億參數），跑在 M1 Pro 的本地 Ollama 環境，零雲端 API 呼叫，共 10 組 brief、3 組對照、30 次運行。
結果令人意外：token 使用量下降超過 50%，任務完成率反而上升 23%（來源：Pawel / Medium，2026-05-26）。意思是，模型縮小了，但因為記憶架構把資訊組織得夠好，小模型不需要靠巨大的 context window 硬撐，反而能把注意力放在真正重要的事上。
這組實測的價值在於，它證明分層金字塔的效用不依賴於強模型。如果這套架構只在 GPT-5 等級的模型上有效，那可能是模型本身夠聰明，架構只是錦上添花。但它在 40 億參數的小模型上也點火了，代表架構本身的組織方式，才是記憶效果的關鍵。
記憶不是把過去塞回去，而是從過去推論現在
台灣工程師部落格 blog.aihao.tw 在 2026-04-28 發過一篇文章，提出一個值得深思的觀點：「大多數記憶功能不需要向量檢索」。他觀察 ChatGPT、Claude Code、OpenAI cookbook、Mastra SOTA 等主流方案，全都不靠向量資料庫。他主張：記憶不是「把過去塞回上下文」，而是「從過去推理出這次該怎麼做」，真正的難題在治理，也就是寫入、整理、讀取、遺忘。
這個觀點與 TencentDB 的分層架構方向部分呼應，但路線不同。TencentDB 選擇用金字塔結構＋符號化索引來組織記憶，aihao.tw 則提醒我們向量不是萬靈丹。兩者放在一起看，結論其實一致：記憶系統的成敗，不在於用了多昂貴的檢索技術，而在於資訊如何被分層、被組織、被賦予意義。
回到 L0-L3 金字塔，它真正的價值，是迫使設計者回答一個最基本卻最常被跳過的問題：這筆記憶在未來哪個時刻、哪個情境會被用到？L0 回答「需要查證時」，L1 回答「需要精確事實時」，L2 回答「需要理解脈絡時」，L3 回答「需要判斷方向時」。四層各管一件事，不多不少，每一層都有它存在的理由。
下一章，我們會把手弄髒，實際安裝這套系統，用真實的任務來驗證這座金字塔，是否真的撐得起 agent 的長期記憶。
證據鏈不斷線：從 L3 畫像追溯到 L0 原文的具體機制
想像一個實際場景：某家軟體公司的技術主管，每週五下午都會跟 AI 助手開一次專案檢討會。連續幾週之後，AI 突然在非會議時間主動提醒：「你上次提到新功能的前端要用 TypeScript，但團隊目前的程式碼基底都是 JavaScript，要不要先開個技術債單？」這個提醒之所以精準，不是因為 AI 把整段對話背了下來，而是它從 L3 畫像中讀到「技術偏好 TypeScript」這條結論，再沿著索引一路追溯回原始對話，確認這不是幻覺。
這條追溯路徑，就是 TencentDB Agent Memory 對外宣稱的「證據鏈不斷線」核心機制。官方 README 中描述的分層設計，可以拆成四個可驗證的步驟來理解。L3 的 persona.md 檔案中寫著「偏好 TypeScript」，這不是一個孤立的標籤，而是一個帶有出處指標的結論。當系統需要驗證這條結論時，它會往下鑽到 L2 的場景塊，找到產生這條結論的對話脈絡，例如「2026 年 7 月 12 日的週五檢討會，團隊討論到前端框架選型」。L2 場景塊是一段 Markdown 格式的人類可讀文件，描述事件的來龍去脈，它本身也不負責保存原始字句，而是繼續指向更底層的 L1 原子事實。
L1 原子事實是最小單位的精確資訊，例如「主管說：新功能用 TypeScript 開發」「團隊現有程式碼以 JavaScript 為主」。每一條原子事實都帶有標籤與時間戳，更重要的是，它記錄了「這句話是誰說的、在哪一次的哪一段對話中說的」這類來源資訊。L1 的每一筆記錄都對應到 L0 的原文索引。L0 層保留的是未經修改的完整對話紀錄，存放在 SQLite 或 JSONL 檔案中，系統不會對這層做任何壓縮或摘要，它的存在意義就是「兜底」。任何一層的結論產生疑義時，最終都能回到 L0 找到那句話的原貌。
壓縮了，但證據沒有消失
很多人會問：既然 L3 和 L2 都是壓縮後的產物，為什麼還能保證追溯得到原文？關鍵在於，這套系統的每一次壓縮，都不是把舊資料丟掉，而是建立「指向下一層的指標」。官方 README 對 L0 的設計描述是「全量保留」，這意味著壓縮只發生在上層的 24KB 或更少的 token 預算內，而底層的原始紀錄永遠存在。每一層的壓縮結果都帶有可尋址的識別碼，L3 畫像中的每一條偏好，都記錄了對應的 L2 場景 ID；L2 場景塊中的每一個結論，都記錄了對應的 L1 事實 ID；L1 事實則記錄了 L0 對話的區間位置。這條鏈不會因為中間某一層的摘要生成而斷裂，因為摘要本身不是替代品，而是入口。
紅迪（Reddit）r/openclaw 討論串中有使用者反映，部分 agent 記憶系統「捕捉太被動」，必須主動說「記住這個」才會存。TencentDB 的分層機制試圖解決的正是這類問題。它的召回方式不是先搜原文，而是先從 L3 畫像判斷「這個使用者大概想要什麼」，再往下確認細節。這種「上層管判斷、下層管證據」的設計，讓 agent 在推論時不需要每次都翻閱海量原始對話，但一旦需要查證，隨時可以沿著鏈條下鑽。
與純向量檢索的差異
如果只用向量檢索，系統通常是將所有對話切成片段、算出 embedding 向量，然後在使用者提問時找出語意最相近的片段。這種做法有兩個先天限制。第一，檢索結果的相關性取決於向量品質，而向量對「精確的關鍵詞」與「事實性的陳述」並不總是敏感。舉例來說，使用者可能在某次對話中說「我不太喜歡 Java」，但這不代表他「討厭所有 JVM 語言」。向量檢索可能把「Java」與「JVM」混為一談，導致畫像失真。第二，向量檢索只會回傳片段，不會告訴你這個結論是怎麼推導出來的，缺乏可解釋性。
TencentDB 的做法是採取「雙路召回」：一路用 BM25 做關鍵字精確匹配，一路用 Embedding 做語意模糊匹配，透過 RRF（Reciprocal Rank Fusion）融合排序。官方 README 宣稱，這樣可以做到「語意相關不漏、精確匹配不丟」。但需要強調的是，這組數據是官方自測結果，根據官方 README 的說明，WideSearch 成功率從 33% 提升至 50%，token 用量從 2.21 億降至 8560 萬，節省約 61.4%。這些數字來自連續 50 個任務的長程 session 測試，屬於 vendor-run 的宣稱，目前還沒有第三方以相同條件重現。
值得參考的是獨立開發者 Pawel 在 Medium 上於 2026 年 5 月 26 日發表的實測，他刻意將模型縮小到 Gemma 4 E4B（約 40 億參數）跑在 M1 Pro 本地 Ollama，完全不呼叫雲端 API，進行了 10 組 brief、3 組對照、共 30 次運行。結果顯示 token 量下降超過 50%，任務完成率反而上升 23%。這份實測的重要意義在於，它證明了分層與追溯機制的有效性並不完全依賴模型強度。就算是最小的模型，只要架構設計正確，記憶與查證能力依然能發揮作用。
台灣工程師的另一種觀點
台灣工程師 blog.aihao.tw 在 2026 年 4 月 28 日的文章中提到一個值得深思的觀點：「大多數記憶功能不需要向量檢索」。他觀察到 ChatGPT、Claude Code、Claude API、OpenAI cookbook 與 Mastra 的官方實作，全都沒有使用向量資料庫。他認為真正的難題在於治理，包含寫入、整理、讀取與遺忘的循環，而不是檢索技術本身。這與 TencentDB 的分層方向部分呼應，但路線不同。分層加上證據鏈的設計，確實比單純的向量檢索更有機會回答「這筆記憶是怎麼來的」這個問題，但它仍然沒有完全解決記憶膨脹與主動遺忘的議題。紅迪 r/openclaw 的實用回饋也提到，使用者必須手動觸發才能捕捉關鍵資訊，這顯示目前的機制還不夠主動。
把這些素材放在一起，可以歸納出具體的運作樣貌。L3 告訴你「應該往哪個方向思考」，L2 告訴你「這個方向從哪段脈絡長出來」，L1 告訴你「構成脈絡的最小事實是什麼」，L0 告訴你「事實的原始憑證在哪裡」。每一層各司其職，壓縮不是為了節省儲存空間，而是為了讓 agent 在有限的上下文預算內，做出更有根據的判斷。當你需要向老闆說明「為什麼 AI 認為你偏好 TypeScript」時，你可以沿著這條鏈，一路追溯到三個星期前你說出的那句原話。這才是證據鏈的真正價值：壓縮的是篇幅，不是來龍去脈。
短期任務記憶的 Mermaid 符號化：把幾十萬 token 的工具 log 壓成幾百 token 的任務拓撲圖
長任務燒 token 的元凶，往往不是對話本身，而是工具呼叫留下的一長串 log。搜尋結果、錯誤軌跡、程式碼片段、API 回傳，累積起來輕鬆突破幾十萬 token。把這些全部塞進 context，不但浪費預算，還會稀釋 agent 的注意力，讓它分不清哪些資訊對當下決策真正重要。TencentDB Agent Memory 的解法很乾脆：不要讓 agent 讀 log，讓它讀一張圖。這張圖不是示意圖，而是帶有明確索引、可以隨時回溯原文的任務拓撲圖。
第一步：完整 log 卸載到外部檔案
log 本身不能丟，它是證據的源頭。實作上先把完整 log 寫入外部檔案 refs/*.md，每個任務階段各自成檔。這個動作類似長期記憶 L0 層的保留策略，全量保存，隨時可回查。卸載之後，agent 的 context 立刻空出大半，但這只是前置作業，真正的關鍵在第二步：從 log 裡萃取出有意義的結構。
第二步：從 log 抽取關係，建立任務拓撲
log 是線性的時間流，agent 讀起來只能用「然後、然後、然後」串接。但任務的本質不是線性的，它是由狀態、依賴關係、分支決策組成的結構。舉例來說，你搜尋到某個套件、安裝失敗、查了錯誤碼、決定改用另一個方案，這四個事件在 log 裡只是先後順序，但它們其實是「失敗」與「替代」的因果關係。符號化要做的事，就是抽出這些關係，重新組成一張任務拓撲圖，讓 agent 一眼看出哪些步驟已經完成、哪些結果被依賴、哪些決策是當前的分岔點。
第三步：Mermaid 畫布帶上 node_id
拓撲圖用 Mermaid 語法畫出來，每個節點都帶一個 node_id。node_id 不是隨機亂碼，它對應回 refs/*.md 裡的段落位置，例如 node_07 對應 refs/task_03.md 中搜尋結果那段。一張幾百 token 的圖，可以承載原本幾十萬 token log 的結構資訊。哪個步驟依賴哪個結果、哪個決策導致哪條岔路，一眼就能讀懂。
第四步：只注入圖進 context
agent 在 context 裡看到的，就只有這張精簡的任務狀態圖。它知道現在進行到哪、哪些環節卡過、下一步有哪些選擇。當它需要驗證細節，例如某個錯誤碼的完整訊息，就依照 node_id 把對應段落從 refs/*.md 撈回來。這個動作只在需要時發生，平時 context 保持輕盈，不會被大量 log 淹沒。
為什麼這套設計有效？因為 agent 多數時候只需要知道「任務走到哪了」，不需要重讀每個中間產物。人也是這樣工作的，你看專案進度表不會把每封 email 都重看一遍。符號化的本質，是讓 agent 擁有「索引」而不是「全文」。官方 README 宣稱這套架構在連續五十個任務的長程 session 中，把 token 消耗從 221M 降到 85.6M，省下 61.4%，同時 WideSearch 成功率從 33% 提升到 50%（來源：官方 README）。不過這些數字是官方自測，實務上採用前需要自行驗證。
獨立實測也支持這個方向。Pawel 在 Medium 發表的測試把模型縮小到 Gemma 4 E4B，約四十億參數，在 M1 Pro 上完全本地運行三十次，token 消耗下降超過五成，任務完成率反而上升 23%（來源：Pawel／Medium，2026-05-26）。這個結果說明，符號化的效益不依賴於強模型，架構本身就能帶來改善。
不過，Reddit r/openclaw 的社群回饋指出，捕捉機制還是太被動，使用者常要主動喊「記住這個」才不會漏掉關鍵資訊（來源：Reddit r/openclaw）。這個批評點出了符號化的瓶頸：關係抽取的品質決定圖的品質，如果抽出來的是錯誤的依賴關係，agent 看到的就是一張誤導人的圖。台灣工程師 blog.aihao.tw 也提出另一個角度的提醒，認為大多數記憶功能其實不需要向量檢索，真正難的是治理，包括寫入、整理、讀取和遺忘（來源：blog.aihao.tw，2026-04-28）。
以台灣中小型企業導入的觀點來看，Mermaid 符號化的好處在於它不挑剔模型大小。小模型運算資源有限，更需要在 context 裡只看重點。把工具 log 壓成任務拓撲圖後，即使是四十億參數的本地模型，也能維持一定的任務完成率，這對重視資料落地的台灣企業特別有吸引力。我們建議導入時先挑一兩個高重複性的流程試跑，例如客戶報價或技術支援的排查，觀察 log 卸載後 agent 的決策品質是否下降，再逐步擴大到更複雜的任務。同時要留意官方數字都是自測結果，評估時應以自家工作的實際表現為準，不要直接採信宣傳數據。
回歸本質，這四步流程的意義不在省 token，而在改變 agent 看任務的方式。從線性閱讀 log，變成讀一張有狀態、有依賴、可尋址的拓撲圖。壓縮的是篇幅，保留的是結構，需要證據時隨時可以沿著 node_id 回到原文。這正是短期任務記憶應該有的樣子。
雙路召回機制：BM25 精確命中與 Embedding 語意匹配如何融合排序
在三段式 agent 記憶架構裡，召回環節決定 agent 能從記憶庫中拿出什麼。檢索增強生成（RAG）的標準作法多半只選一種檢索策略，但 TencentDB Agent Memory 官方 README 給出不同的設計：BM25 與 Embedding 雙路並行，再用 RRF 融合排序，目標是達到「語意相關不漏、精確匹配不丟」的效果。為什麼要繞這條路？因為 agent 的記憶查詢往往同時混著兩種截然不同的類型：一種是「上次那個錯誤碼是多少」這種要求一字不差的精確事實，另一種是「上次客戶抱怨流程太繁瑣的那次討論」這種連關鍵字都想不起來的模糊意圖。單一檢索策略無法同時滿足這兩種需求。
單靠向量檢索的三個盲點
近年 RAG 熱潮讓許多人直覺認為，把記憶全部轉成向量，再用語意相似度搜尋就好。實務上這條路會踩到幾個坑。其一，精確的事實很容易被模糊化。使用者問「React 19 的 hydration error 當時怎麼解的」，向量檢索可能找出所有與 React 相關的對話，反而把最關鍵的那一句淹沒在相似的雜訊裡。其二，版本號、日期、函式名稱、錯誤代碼這類 token 在向量空間中沒有明顯的語意距離，「2026-08-03」與「2025-08-03」在數學上可能非常接近，但在實際意義上是完全不同的日子。其三，向量檢索的結果好壞強烈依賴 embedding 模型的品質，如果模型沒見過該領域的專有名詞，檢索品質等於沒有保障。台灣工程師 blog.aihao.tw（2026-04-28）甚至直言「大多數記憶功能不需要向量檢索」，他觀察 ChatGPT、Claude Code、OpenAI cookbook 等主流產品都不以向量檢索為核心，真正的難點在記憶的治理，而不是檢索工具本身。這段話不是否定向量，而是提醒我們應該依照查詢的性質選擇檢索方法。
BM25：以關鍵字為尺的精確命中
BM25 是傳統資訊檢索領域的經典方法，核心想法很樸素：計算查詢詞在文件中的出現頻率，並用逆文件頻率懲罰那些到處都是的常見詞。這種稀疏檢索對專有名詞、版本號、程式語言的識別特別敏銳，只要記憶庫中某一段文件完整包含「React 19」「hydration error」這些詞，它就有機會被推到排名前列。在 TencentDB Agent Memory 的分層架構中，L1 原子事實恰好是最適合 BM25 的資料型態：原子事實被打上明確的標籤，格式乾淨、詞彙集中，命中就是命中，不必猜語意。BM25 的先天限制也很清楚，它看不到同義詞，也無法理解換句話說。使用者問「要怎麼讓容器在伺服器重開機之後自動起來」，記憶庫裡只有「docker restart policy: always」這段筆記，兩者詞彙幾乎沒有重疊，BM25 就會完全失靈。
Embedding：以語意為繩的模糊匹配
Embedding 檢索把文字投影到高維向量空間，意圖相近的句子即使詞彙不同，向量距離仍然接近，正好補上 BM25 的缺口。同樣的問題交給向量檢索，「容器自動重啟」與「docker restart policy: always」在語意上高度相關，它就能把這段筆記取出。這個特性讓它特別適合模糊記憶的召回，例如「之前討論過的那個客戶抱怨」這類沒有具體關鍵字的查詢。然而向量檢索的另一面是，它對數值與事實的敏感度不足，也容易受到語意漂移影響。當記憶庫不斷膨脹時，新舊文件在向量空間中的分布可能逐漸偏離原本的語意，檢索品質會隨時間緩慢劣化，需要定期重新評估模型的適用性。
RRF 融合排序：不比分數，比排名
雙路召回各自產生一份候選清單之後，接下來的問題是如何合併。直覺的作法是將兩邊的分數加權平均，但 BM25 的分數與 embedding 的相似度在尺度上完全不可比，直接加權只是把兩個不同單位的東西硬湊在一起。RRF（Reciprocal Rank Fusion）提供另一種思路：完全不看原始分數，只看每份文件在兩份排名清單中的位置。對於每一份文件，RRF 累計它在兩條召回路徑中的排名貢獻，排名越前面，貢獻越大。這種作法的好處是穩健，即使兩路檢索的分數分布天差地遠，只要排名合理，融合後的結果就不會失真。舉例來說，某段記憶在 BM25 中排名第一，但在 embedding 中完全沒進榜；另一段記憶在兩路中都排名第八。兩相比較，後者的融合分數反而更高，因為它同時被兩種不同的視角認定為重要，可信度更充足。實際使用時，RRF 的參數需要依記憶庫的規模與語言特性調整，不是一個固定值能適用在所有情境。
<h3
獨立實測驗證：縮到 40 億參數的 Gemma 4 E4B 本地跑，架構依然有效
前一個章節談完了 BM25 與 Embedding 兩路召回背後的 RRF 融合邏輯，那些都是架構上的設計抉擇。但設計理念再完整，也需要實證檢驗。TencentDB Agent Memory 官方宣稱的數據，像是 WideSearch token 省 61.4%、成功率從 33% 拉到 50% 等等，都是在官方環境下測得的 vendor-run 數字。整個 agent memory 領域的基準測試各自為政，不同的測試集、不同的裁判模型、不同的 harness，缺乏公平的第三方對照。在這種情況下，一篇由外部研究者執行的獨立實測，就成了判斷這套架構是否真的有效的重要依據。
2026 年 5 月 26 日，一位署名 Pawel 的作者在 Medium 發表了題為「The 20K → 3K moment」的實測報告。他的做法相當極端：故意把模型縮小到 Gemma 4 E4B，約 40 億參數，跑在 M1 Pro 筆電的本地 Ollama 上，全程零雲端呼叫。背後的理由很單純，如果 TencentDB Agent Memory 的分層記憶架構真的有效，那麼即使搭配一個參數量極小的模型，任務完成率也不該
替代方案有限公司觀點：記憶的真正難題是治理，不是向量檢索
過去兩年，我們在台灣協助客戶導入 AI 助理與客服機器人時，最常聽到的抱怨不是「模型不夠聰明」，而是「它怎麼又忘了」。客戶明明在前一次對話中交代過公司統編、偏好用 LINE 通知、報價單要含稅，下一次對話卻全部歸零，彷彿從來沒發生過。多數團隊的第一反應是「那就把對話紀錄全部塞進向量資料庫吧」，彷彿把每個字都變成 embedding，問題就能解決。但事實並非如此。
部落格 blog.aihao.tw 的作者，一位台灣工程師，在 2026 年 4 月 28 日發表了一篇觀點鮮明的文章，標題直指「大多數記憶功能不需要向量檢索」。他逐一檢視了 ChatGPT 的記憶功能、Claude Code 的專案記憶、Claude API 的系統提示詞設計、OpenAI 官方 cookbook 的建議作法，以及 Mastra 框架的 SOTA 記憶實作，結論是一致的：這些主流方案沒有一個把向量檢索當作核心。ChatGPT 用的是結構化的記憶片段，Claude Code 用的是檔案與規則的組合，OpenAI cookbook 教的也是怎麼把記憶整理成結構化的內容。向量檢索在這些產品裡頂多扮演輔助角色，有時候甚至完全缺席。
這篇文章的核心論點讓我們印象深刻。作者說，記憶的真正難題不是「怎麼找回來」，而是「怎麼治理」。治理包含四個動作：寫入、整理、讀取、遺忘。寫入要判斷什麼值得記，什麼不值得記，不是每句對話都該沉澱成記憶。整理要決定記憶的層次與關聯，單一事實跟完整脈絡應該分開存放。讀取要在對的時刻把對的記憶放回上下文，而不是每次把全部歷史都塞進去。遺忘則是最常被忽略的一環，過時的偏好、錯誤的推論、已經沒有效力的決策，如果永遠留在記憶裡，反而會污染未來的判斷。作者說得直接：記憶不是「把過去塞回上下文」，而是「從過去推理出這次該怎麼做」。這句話點出了本質，記憶的目的不是重播，而是指導行動。
我們之所以在系列文章中特別安排這個章節，是因為 TencentDB Agent Memory 的設計方向恰好呼應了這位台灣工程師的判斷，只是走了一條不同的路線。騰訊雲資料庫團隊在 2026 年 5 月開源的這個記憶引擎，核心主張不是「存更多」，而是「分層＋符號化」。長期記憶用 L0 到 L3 的金字塔結構，L0 保留原始對話全文，L1 抽取原子事實並打上標籤，L2 組織成場景區塊，L3 凝聚成使用者畫像。上層管判斷，下層管證據，從畫像一路可以追溯到原始對話的某一句話，證據鏈完整不中斷。短期記憶則用另一套作法，把動輒幾十萬 token 的工具紀錄卸載到外部檔案，只把精簡的 Mermaid 圖注入 agent 的上下文，需要驗證細節時再用 node_id 回去撈原文。
這個設計的巧妙之處在於，它把「治理」變成了架構的一部分，而不是事後的補救措施。寫入階段有明確的分層規則，什麼進 L1、什麼進 L2、什麼進 L3，不是全部倒進同一個桶子。整理階段有原子事實與場景塊的分工，事實歸事實，脈絡歸脈絡。讀取階段有金字塔的召回順序，先看畫像，不夠再往下追細節，從不在每一輪對話都把所有記憶塞進上下文。遺忘階段目前還不完整，這是我們在後續風險段落會提到的重點，但至少架構上已經為「如何判斷哪些記憶該退場」留下了思考空間。
然而，我們必須誠實指出，TencentDB Agent Memory 的官方數據都帶有先天限制。官方 README 宣稱 WideSearch 成功率從 33% 提升到 50%，token 用量減少 61.4%，SWE-bench 通過率從 58.4% 提升到 64.2%，persona 記憶準確率從 48% 提升到 76%。這些數字看起來漂亮，但都是官方自己跑的測試，用的是自己設計的測試集、自己的裁判模型、自己的評估流程。整個 agent 記憶領域目前缺乏公平的第三方對照基準，不同專案各說各話，我們在系列第五天的競品比較中會深入討論這個問題。digitalapplied 在 2026 年 8 月 4 日的實測就抓到一個誇張的例子：Mem0 官方宣稱 LongMemEval 得分 94.4，第三方獨立測試卻只有 49.0。差距將近一倍，這種情況在整個領域屢見不鮮。
比較可信的證據來自獨立第三方。Medium 作者 Pawel 在 2026 年 5 月 26 日發表了題為「The 20K → 3K moment」的實測報告，他刻意把模型縮小到 Gemma 4 E4B，大約 40 億參數，跑在 M1 Pro 筆電的本地 Ollama 上，全程零雲端呼叫。十組測試任務、三組對照、三十次運行，結果 token 用量下降超過五成，任務完成率反而上升了 23%。這個實測的價值在於，它證明了 TencentDB Agent Memory 的架構在小模型上也能發揮作用，不是靠強模型硬撐出來的成績。
另一個我們觀察到的現實問題是，記憶的捕捉機制仍然太被動。Reddit 的 r/openclaw 討論區有使用者反應，系統常常需要你主動喊「記住這個」，它才會真的把重要資訊沉澱進去。記憶膨脹也是具體的痛點，記憶越積越多，但系統缺乏有效的主動清理機制，舊的、錯的、過時的記憶沒有自動退場的設計。GitHub issues 上也還有未解的 bug 回報，v2.0 正式版上線到我們撰寫本文的此刻僅八天，團隊級功能才剛推出，穩定性有待時間驗證。
我們的觀點：治理才是記憶系統的成敗關鍵
我們認為，TencentDB Agent Memory 最值得台灣團隊學習的，不是它的向量檢索技術，也不是它的 Mermaid 圖壓縮技巧，而是它把「治理」放進架構核心的思維方式。台灣多數企業導入 AI 助理時，最大的痛點從來不是「找不到舊資料」，而是「資料太多、太雜、不知道哪些該用」。這個問題在本質上是治理問題，不是檢索問題。向量資料庫可以幫你快速找到語意相似的片段，但它無法判斷這段記憶是否已經過時、是否與當前的任務真正相關、是否值得寫入長期的使用者畫像。這些判斷需要結構化的分層設計，需要人為定義的規則，也需要系統在寫入與讀取之間取得平衡。
我們對台灣市場的落地建議是：先從單一業務場景開始，不要急著部署完整的團隊級記憶中心。舉例來說，如果你的公司經常用 AI 協助撰寫報價單，那就先讓記憶系統專注於記錄客戶的產業別、預算區間、過去偏好的報價格式、常見的議價空間。用 TencentDB Agent Memory 的 L1 原子事實來存「這個客戶偏好含稅報價」這樣的事實，用 L2 場景塊來存「上次報價的完整脈絡與客戶回饋」，用 L3 畫像來凝聚「這個客戶的整體輪廓」。跑一個月，看看系統在協助你準備下一份報價單時，是不是真的比以前更貼近客戶的需求。如果這個單一場景驗證有效，再逐步擴展到客戶服務、內部知識管理、程式開發輔助等其他領域。切記不要一開場就追求「什麼都記」，記憶的價值在於精準，不在於數量。
同時，我們也建議台灣的技術團隊在採用任何記憶架構之前，先建立自己的評估基準。不要直接引用官方宣稱的數據，那些數據都是廠商在自家實驗室跑出來的，缺乏可再現性。時間允許的話，用自己公司的真實業務資料跑一輪測試，測量三個指標：記憶寫入是否正確、任務完成率是否提升、token 成本是否下降。把這三個數字當作決策依據，遠比參考任何官方 benchmark 來得可靠。至於記憶膨脹與被動捕捉這兩個尚未解決的問題，我們會密切關注 TencentDB Agent Memory 的後續版本，也期待台灣開源社群有人投入這個方向的改進。
總結來說，記憶系統的技術門檻正在快速下降，向量檢索、知識圖譜、分層架構都是成熟可用的工具。真正的差異化來自於治理紀律：你怎麼決定記什麼、怎麼整理、怎麼在對的時機讀取、怎麼讓過時的記憶優雅退場。TencentDB Agent Memory 的分層設計讓我們看到了一個值得追蹤的方向，但它不是終點，就像那位台灣工程師說的，記憶的意義不在於記住一切，而在於每一次都能做出更正確的決策。這正是我們在替代方案有限公司持續關注這個領域的原因。
結論：這套 L0-L3 架構適合誰、有哪些風險、下一步可以怎麼做
這個系列的六篇文章，從 AI 老是忘記你交代的事？TencentDB Agent Memory 開源記憶引擎，讓 AI 真正『記得』你 的痛點談到原理，從安裝實作談到競品比較，我們花了不少篇幅拆解 TencentDB Agent Memory。現在到了收尾的時候，與其堆疊更多技術細節，不如把焦點放在三個實際的問題上：這套架構到底解決了什麼、你用了會有什麼風險、接下來該怎麼踏出第一步。前面的章節我們談了很多治理紀律與記憶本質的辯證，這一章我們把話說白，給出我們對台灣企業落地這套系統的真實判斷。
壓縮但不丟證據，是整套設計的靈魂
回頭看整個系列，L0-L3 分層金字塔與 Mermaid 符號化畫布，其實都在回應同一個矛盾：AI 的上下文窗口再大，也裝不下真實工作留下的痕跡。工具呼叫的 log 動輒幾十萬 token，全塞進去既浪費又干擾判斷，全部丟掉又讓 agent 失去記憶。TencentDB Agent Memory 的解法是讓上層管判斷、下層管證據。L3 的用戶畫像負責快速決策，L1 的原子事實負責精確召回，L0 的原始對話負責最終兜底。Mermaid 圖則用幾百個 token 把幾十萬 token 的工具軌跡壓縮成帶狀態、帶依賴、可尋址的任務拓撲圖，出事的時候靠 node_id 回頭撈原文。資訊被壓縮了，但證據鏈從未中斷，這是整套架構最值得肯定的地方，也是它與其他記憶工具最本質的差異。
誰適合現在導入，誰應該再等等
以台灣中小企業的現況來看，適合導入的場景有幾個共同特徵。第一是內部知識累積成本高，例如顧問服務、軟體外包、系統整合商，專案做完經驗就散在每個人腦子裡，沒有結構化的沉澱。第二是既有流程仰賴長時間對話，例如客服、業務開發、專案管理，agent 若能記住客戶偏好與歷史決策，每一次互動品質都會明顯提升。第三是團隊規模不大但同時維護多個自動化流程，三件式 Docker 部署對資訊人員的負擔還在可接受的範圍，不需要動用大型平台團隊。
反過來說，如果你的工作主要是高度結構化的表單作業，或者你對資料治理還沒有明確規範，那這套系統的效益不會太明顯。記憶系統不會憑空創造價值，它放大的是你原本就有的協作紀律。團隊內部連工作日誌都沒有人在寫，導入再先進的記憶架構也只是把混亂自動化。
風險不是技術問題，是信任問題
我們在系列文章裡反覆提醒，官方 README 上的 benchmark 數字都是 vendor-run，也就是騰訊自己跑出來的結果。WideSearch 成功率從 33% 提升到 50%、token 節省 61.4%、PersonaMem 準確率從 48% 提升到 76%，這些數據雖然亮眼，但沒有第三方在公平環境下重測（來源：官方 README，2026）。整個記憶領域的 benchmark 各自為政，digitalapplied 在 2026-08-04 的測試中甚至發現某競品自家宣稱的分數與第三方測出的結果差距將近一倍，我們對任何單一廠商的宣稱都該保留判斷空間。
第二個風險是 v2.0 正式版在 2026-08-03 才發布，距離今天只有八天。團隊級記憶中心、Memory Hub、Memory Proxy 這些新功能都還很年輕，GitHub issues 上仍看得到 bug 回報，官方雖然承諾 24 小時內回應，但這不代表生產環境可以無腦上線。第三是記憶膨脹與被動捕捉的問題，Reddit 社群已經有人反映，agent 常常要等到你主動喊「記住這個」才願意寫入記憶，長時間運作後儲存量也會持續增長。第四是依賴關係的透明度，這套系統把記憶放在外部檔案，一旦檔案結構變動或版本升級，既有的 node_id 索引可能要重新建立，這在長線營運中是隱形成本。
接下來的三步建議
- 先在測試環境跑兩週：用 Hermes 的 plug-in 方式接入，不需要一次上三件套，用小規模的真實任務觀察記憶召回的正確率，也順便感受一下記憶膨脹的速度。
- 選一個非關鍵流程做 PoC：例如內部 FAQ 問答、專案週報整理、客戶往來摘要，這類任務失敗成本低，但能明顯看出記憶系統的效益。
- 建立自己的驗證基準：不要只信官方數字，學 Pawel 的做法，用自己的資料、自己的提示詞、連續 50 個任務跑一個長程 session，紀錄 token 消耗與完成率變化（參考來源：Pawel 於 Medium 的獨立實測，2026-05-26）。
替代方案有限公司的觀點
作為一家台灣的開源顧問公司，我們對這套架構的態度是謹慎樂觀。謹慎的原因是，任何號稱能解決 AI 遺忘問題的工具，最終都要回到治理紀律這件事上。就像我們在系列文章中引用的台灣工程師觀點，記憶的意義不在於記住一切，而在於每次都能做出更正確的決策。TencentDB Agent Memory 的分層設計提供了一個很好的基礎架構，但寫入什麼、何時遺忘、怎麼防止誤用，這些決策仍然需要人來定義。目前光是 GitHub 上就有超過 12 個開源專案在做同一件事（來源：blog.aihao.tw，2026-04-28），解法百花齊放，也代表市場上會出現大量良莠不齊的解決方案，企業更需要具備獨立判斷的能力。
我們認為台灣企業導入時，可以跳過自行訓練模型的環節，直接把資源投入在記憶治理流程的設計上，這才是最務實的路線。樂觀的原因是，開源社群的反應讓我們看到這個方向正在快速成熟，Reddit 上的討論、Medium 的實測、GitHub 上持續增長的星數，都證明這個問題確實困擾著許多人。我們接下來會持續追蹤 v2.0 的後續版本，也歡迎讀者把實測經驗分享給我們，一起把這個領域的知識累積起來。台灣市場規模不大，但正因為如此，我們更需要在開源社群中發出自己的聲音，而不是永遠跟在別人的架構後面跑。
📩 如果你對導入方式有任何疑問，或者想討論哪個流程適合先做 PoC，歡迎隨時聯絡我們：[email protected]，替代方案有限公司會為你提供在地化的建議。我們會依照你的團隊規模、產業別、既有系統架構，協助你判斷 L0-L3 分層記憶到底能不能在貴公司產生實質效益，也會誠實告訴你哪些場景其實不需要這套系統。技術選型沒有標準答案，但有比較適合你的答案，我們的角色就是幫你找到那個答案。
Related
