AI 老是忘記你交代的事？TencentDB Agent Memory 開源記憶引擎，讓 AI 真正『記得』你

為什麼 AI 老是忘記你交代的事？，從日常痛點看記憶缺口

想像一個再熟悉不過的場景。你早上交代 AI 助理整理客戶報價單，特別叮嚀「金額一律用新台幣，不要用美元」，助理也爽快回應「好的」。到了下午，你請它彙整成簡報，它卻若無其事地把報價換算成美元，還附上一條過時的合作條款。你當下只想問一句：我不是講過了嗎？

這種「對話失憶」幾乎每個用過 AI 助理的人都碰過。明明上下文裡寫得清清楚楚，AI 卻像金魚一樣，轉個彎就忘了。今天我們不談複雜的模型架構，就從這些真實痛點出發，看看 AI 的記憶到底在哪裡出了問題。

你的一天，被 AI 的「失憶」中斷幾次？

把時間拉長到一天，你大概會遇到下面這些狀況：

• 長對話到了第十輪，AI 開始重複問你已經回答過的偏好，像是「您希望用繁體中文還是簡體中文」，明明第一輪就講過了。
• 上一週請 AI 記住的專案命名規則，這週它完全沒印象，你需要重新把規則貼一次。
• AI 引用了一則三個月前的價格資訊，卻不知道那已經被新的方案取代。

這些痛點的共同根源，在於 AI 的「記憶」沒有被當成一等公民來設計。大型語言模型本質上是無狀態的，每一次回應都是從當下的對話內容重新推導，沒有所謂的長期檔案。當對話長到某個程度，舊資訊自然被擠出視窗之外。

不是 AI 笨，是它的「記憶體」真的不夠

要理解這個限制，得先知道 token 與上下文視窗的概念。Token 是模型處理文字的基本單位，一個中文字可能佔一到三個 token，而模型每一次能「同時看到」的 token 總量就是上下文視窗，目前主流模型大概是幾萬到上百萬不等。

問題來了。長任務的過程紀錄、搜尋結果、程式碼錯誤軌跡，動輒累積數十萬 token。根據騰訊雲資料庫團隊發表的官方 README（2026 年）宣稱，在連續五十個任務的長程 session 中，基礎做法消耗了兩億兩千一百萬個 token，他們優化後降到八千五百六十萬個，省下 61.4%。這個數字背後的訊息是：長對話燒 token 的速度，遠比你想像的恐怖。

於是模型被迫做出取捨，要嘛截斷最舊的內容，要嘛摘要壓縮。不管是哪一種，你最初交代的那些細節，往往就是第一個被犧牲的對象。

為什麼把對話記錄塞回去也沒用？

有些人會想，那把完整歷史存下來，每次問問題時全部塞回去，總該記得了吧？實務上這個做法很快就會碰壁。

成本問題首當其衝。每一次呼叫都要處理幾十萬 token 的歷史，費用隨之暴漲，反應速度也變慢。更致命的是，當歷史裡面包山包海時，模型反而找不到重點。你的「報價一律用新台幣」被埋在三百則訊息裡，就像在大海撈針。資訊太多等於沒有資訊，這是注意力機制的先天限制。

台灣工程師部落格 blog.aihao.tw（2026 年 4 月）有篇文章點出關鍵，「大多數記憶功能不需要向量檢索」。作者觀察 ChatGPT、Claude Code 等主流工具，真正的難點不在檢索技術，而在治理，包含記憶的寫入、整理、讀取與遺忘。記憶不是「把過去塞回上下文」，而是「從過去推理出這次該怎麼做」。這句話一針見血，也呼應了近年記憶引擎的設計趨勢。

記憶的真正瓶頸：從「存」到「用」

既然單純把對話紀錄塞回去行不通，那該怎麼做？目前開源社群最有代表性的答案之一，是分層記憶架構。以騰訊雲的 TencentDB Agent Memory 為例，它把長期記憶分成四層：L0 保留原始對話全文，L1 抽出原子事實，L2 整理成可讀的場景塊，L3 建立使用者畫像。上層負責快速判斷，下層負責提供證據，細節不足時再往下一層追蹤。

這個專案 2026 年 5 月開源，7 月曾登上 GitHub Trending 第一名，目前累積超過 1.8 萬顆星（來源：GitHub API，2026 年 8 月）。更獨立實測的結果，Pawel 在 Medium（2026 年 5 月）把模型刻意縮小到 Gemma 4 E4B，大約 40 億參數，完全在本地跑，結果 token 用量下降超過五成，任務完成率反而提升 23%。這代表分層架構本身有效，不是靠大型模型的算力硬撐。

同樣的邏輯也適用在短期任務。長任務最燒 token 的其實是工具執行紀錄，像是搜尋結果、錯誤軌跡、程式碼輸出。新一代做法把完整紀錄卸載到外部檔案，只把精簡的關係圖注入模型，需要驗證細節時再去翻原文。這就像開公司不把每個月所有發票堆在桌上，而是放進檔案櫃，需要時再抽出來。

AI 記憶市場正在起飛

這股記憶熱潮不是空談。市場研究機構愛分析（2026 年）指出，中國市場的 AI 代理記憶規模將從 2025 年的 14.4 億人民幣，成長到 2030 年的 642.5 億人民幣，年均複合成長率超過 110%。企業開始把記憶當成 AI 基礎建設的關鍵環節，因為沒有記憶，AI 永遠只能回答當下，無法累積經驗。

當然，記憶引擎還有很多未解的難題。Reddit 上的 r/AI_Agents 社群就有人質疑，記憶有沒有真的改變未來的行為？r/openclaw 的用戶則抱怨捕捉機制太被動，常常要主動喊「記住這個」系統才存得下來。記憶膨脹也是一大隱憂，什麼都記的結果，就是什麼都模糊。這些都是真實存在的限制。

給台灣企業的小建議

站在替代方案有限公司的立場，我們建議台灣的中小企業不要急著追逐最貴的模型，而是先盤點自己的 AI 工作流程，找出哪些環節最常因「失憶」而重工。報價單、客戶偏好、內部命名規範、程式碼風格，這些都是記憶引擎最容易發揮價值的地方。選用工具時，優先考慮開放架構與本地部署選項，像 TencentDB Agent Memory 這類 MIT 授權專案，才能確保資料主權掌握在自己手上。記憶不是越高深越好，而是越貼近你的日常工作越好。

回到最初的場景。當 AI 助理再次忘記新台幣計價時，問題不在於它的算力不夠，而在於整個系統缺少一套主動的記憶機制。未來的 AI 不是記住每一句話，而是懂得從過去的互動中推理，知道哪些細節該被保存、哪些該被遺忘、哪些該在適當時機被召喚出來。

理解了記憶缺口的本質，下一步就是拆解那些號稱能解決記憶問題的技術，到底用了什麼魔法。下一章，我們要深入 L

TencentDB Agent Memory 是什麼？開源記憶引擎的初體驗

如果你用過 AI 助理處理長天期的專案，大概都有這種經驗：上週才交代過的報價規則，今天又問了一次；昨天確認過要用 Next.js，今天卻推薦你 Vue。模型的能力越來越強，記憶卻像金魚一樣，七秒就歸零。這不是使用者的問題，而是多數 AI 系統根本沒有設計一套「主動記憶」的機制。騰訊雲資料庫團隊開源的 TencentDB Agent Memory，正是衝著這個缺口而來。

我們先看客觀數據。這個專案在 2026 年 4 月 7 日建立，5 月 14 日正式開源，7 月 8 日登上 GitHub Trending 第一名（資料來源：Trendshift），8 月 3 日釋出 v2.0 正式版。截至 2026 年 8 月 9 日，GitHub 星數為 18，423、fork 數 1，660，授權條款是 MIT（資料來源：GitHub API）。不到四個月累積將近兩萬顆星，背後代表的是社群對「AI 記憶」這個題目的飢渴程度。

但真正讓這個專案在開源圈引起討論的，不是星數，而是它的核心主張。TencentDB Agent Memory 不做「把對話全部塞回上下文」這種暴力解，而是提出「分層＋符號化」的架構，把記憶拆成兩個支柱：長期記憶的 L0 到 L3 語意金字塔，以及短期任務的符號化畫布。我們一個一個看。

長期記憶分層 L0 到 L3：語意金字塔

長期記憶分四層，由下往上分別是：

• L0 Conversation：原始對話，全量保留，存在 SQLite 或 JSONL，作為最終的證據兜底，隨時可以回查。
• L1 Atom：從對話中抽出的原子事實，例如「用 Next.js」「偏好週五開會」，打上標籤，追求精確召回。
• L2 Scenario：把相關事實組成場景塊，例如一筆報價流程的來龍去脈，用 Markdown 寫成、人直接可讀。
• L3 Persona：使用者畫像，例如技術偏好、程式風格、常用工具鏈，寫成 persona.md。

四層之間不是各自獨立，而是「上層管判斷、下層管證據」的關係。agent 收到任務時先看 L3 的畫像，細節不夠就往 L2 鑽，證據不足再翻 L1 的原子事實，再不行才回到 L0 的原始對話。重點在於這條證據鏈是連續的：L3 說你偏好 TypeScript，可以一路追溯到 L2 的場景、L1 的事實，指向 L0 裡你說過的那一句話。壓縮了，但不丟失證據，這是跟「只存摘要」最大的不同。

短期符號化記憶：Mermaid 畫布

第二個支柱解決的是長任務的 token 燃燒問題。agent 跑一個複雜任務時，工具 log（搜尋結果、錯誤軌跡、程式碼片段）累積起來動輒幾十萬 token。TencentDB Agent Memory 的做法是：把完整 log 卸載到外部檔案 refs/*.md，只抽取其中的關係，畫成一張帶 node_id 的 Mermaid 圖，圖只有幾百 token，然後只把這張圖注入 agent 的 context。當 agent 需要驗證某個細節時，用 node_id 反向 grep 撈出原文。等於用極少的 token 換來一張具備狀態、依賴關係、可尋址索引的任務拓撲圖，而不是一段線性的流水帳。

在召回機制上，官方採用 BM25（關鍵字精確命中）與 Embedding（語意模糊匹配）雙路召回，再用 RRF 融合排序，兼顧精確與語意。至於效果，必須強調以下數字皆為官方宣稱：WideSearch 的成功率從 33% 提升到 50%（+51.5%），token 用量從 221M 降到 85.6M（省 61.4%），SWE-bench 通過率從 58.4% 升到 64.2%，PersonaMem 準確率從 48% 升到 76%（資料來源：官方 README）。這些數字是專案方自己跑的 benchmark，沒有第三方公正對照，讀的時候請當作參考值。

比較有說服力的是獨立實測。開發者 Pawel 在 2026 年 5 月 26 日發表於 Medium 的測試中，刻意把模型縮小到 Gemma 4 E4B（約 40 億參數），跑在 M1 Pro 的本地 Ollama，完全不呼叫雲端 API，結果 token 用量下降超過 50%，任務完成率反而上升 23%（資料來源：Pawel/Medium，2026-05-26）。這代表架構本身在小模型也能點火，不是靠強模型硬撐。十組實測、三組對照、三十次運行，樣本數雖不算大，但方向明確。

社群反應也不是一面倒。Reddit r/AI_Agents 有人質疑記憶是否真的改變了後續行為，也有人提到「負面記憶」的缺口，例如 agent 試過 chmod 失敗，這種失敗經驗也應該被記錄；r/openclaw 的用戶則回饋捕捉機制還是太被動，常常要主動喊「記住這個」。台灣工程師 blog.aihao.tw 在 2026 年 4 月 28 日的文章也點出：「大多數記憶功能不需要向量檢索」，真正難的是治理，包含寫入、整理、讀取與遺忘（資料來源：blog.aihao.tw，2026-04-28）。這些聲音提醒我們，分層方向對了，但距離「完美記憶」還有很長的路。

整體來看，TencentDB Agent Memory 的初體驗可以用一句話總結：它嘗試把記憶從「塞回上下文」的土法煉鋼，升級成一套有結構、有證據鏈、可追溯的工程系統。MIT 授權的自由度、四個月內登上 Trending 第一的社群熱度，再加上小模型也能驗證的獨立實測，都讓它值得花一個下午好好研究。至於實際裝起來跑的效果如何，以及團隊版本的四大記憶資產怎麼運作，我們留到接下來的章節慢慢拆。

長期記憶怎麼運作？L0-L3 語意金字塔的實戰拆解

前一章我們談到，記憶的關鍵不在於把過去全部塞回上下文，而在於怎麼治理。TencentDB Agent Memory 提出的解法，是一套名為語意金字塔的 L0 到 L3 四層結構。這套結構把記憶拆成四個不同抽象程度的層級，讓 AI 面對使用者時，先看最上層的判斷，證據不足就往下挖，直到翻出最原始的對話紀錄。這一章我們用「你說過偏好 TypeScript」這條具體例子，拆解每一層的真實作用，以及背後的設計邏輯。

L3 人物畫像，先回答「你是誰」

L3 是人物畫像，官方檔案名稱是 persona.md。它記錄的是使用者長期的技術偏好、程式碼風格、常用工具鏈。當 AI 準備回應一個請求時，第一件事就是讀取 L3，快速判斷眼前這個人屬於哪一種開發者，過去習慣用什麼語言、什麼框架。官方宣稱 PersonaMem 的準確率能從 48% 提升到 76%（官方 README，2026），這組數字雖然亮眼，但它是官方自測的結果，參考時要抱持保留態度。更值得在意的，是 L3 這個層級存在的意義：它讓 AI 不用每次從零開始認識使用者，而是先從畫像出發，做出比隨機猜測更好的判斷。

L2 場景塊，把決策放回脈絡

L2 是場景塊，以 Markdown 格式寫成，人可以直接閱讀。假設使用者前一次對話中討論了估價流程，L2 就會把整個流程的來龍去脈整理成一個區塊，包含需求來源、討論過程、的決定。場景塊有點像會議紀錄，但不是流水帳，而是有結構的摘要。AI 在 L3 畫像中看到「這是一個重視估價效率的人」之後，下一步會到 L2 找出相關場景，理解當下這個請求是在什麼脈絡下產生，避免斷章取義。少了這個層級，AI 可能會記住結論，卻忘了結論背後的情境，判斷就容易出錯。

L1 原子事實，可精確召回的節點

再往下是 L1 原子事實。它把場景中的關鍵結論拆成最小單位，例如「使用 NextJS」「偏好週五開會」「不接受直接操作資料庫」。每一條事實都帶有標籤，方便檢索。在召回階段，系統同時跑 BM25 關鍵字比對與 Embedding 語意比對，再用 RRF 演算法融合排序，確保精確命中的事實不會被漏掉，語意相近的模糊結果也能被撈出來。這個機制回應了先前台灣工程師提到的質疑：記憶不一定需要靠向量檢索，關鍵字與結構化標籤反而更直接（blog.aihao.tw，2026-04-28）。L1 正是把這件事落到實作的層級。

L0 原始對話，永遠的兜底

金字塔的最底層是 L0，完整保留原始對話，存放於 SQLite 或 JSONL。這一層不做任何摘要或壓縮，就是原封不動的紀錄。當 L3 畫像與 L2 場景的判斷互相矛盾，或是 L1 的原子事實找不到足夠根據時，AI 會直接翻閱 L0，回到使用者當初講的那句話。有了 L0 兜底，整個金字塔就算壓縮得再厲害，都不會真正失去原始證據。這正是「壓縮了但不丟證據」這句話的具體實踐。

沿著證據鏈回溯，一個 TypeScript 的例子

把四個層級串起來，就是一條完整的證據鏈。假設 AI 想要確認使用者是否偏好 TypeScript，它會這樣回溯：先看 L3 人物畫像，裡頭寫著「偏好 TypeScript」；接著往 L2 場景塊鑽，找到某一次討論「把前端重寫成 TypeScript」的專案紀錄；場景裡的結論連結到 L1 原子事實「偏好 TypeScript」；一路下探 L0，翻出使用者當時親口說出的那句話，例如「我寧可全部改成 TypeScript，也不要再碰 JavaScript」。這四個步驟一氣呵成，每一層都指向下一層，任何一個環節都可以驗證，而不是模型憑空生成的幻覺。整個回溯路徑，就是「L3 說偏好 TypeScript，追溯到 L2 場景塊，場景結論追溯到 L1 原子事實，原子事實指向 L0 你說過的那句話」。

上層管判斷、下層管證據，為何重要

這套設計的核心原則，是上層管判斷、下層管證據。L3 跟 L2 負責讓 AI 快速做出合理的回應，L1 跟 L0 負責在需要時提供可追溯的證明。它解決了兩個痛點：第一，壓縮記憶後不會失真，因為所有摘要都保有回到原文的路徑；第二，AI 可以證明自己記得對，而不是用似是而非的內容呼攏使用者。獨立開發者 Pawel 的實測也支持這個方向，他刻意把模型縮小到 Gemma 4 E4B，約四十億參數，在本地端跑完整測試，結果 token 消耗下降超過一半，任務完成率反而提升百分之二十三（Pawel，Medium，2026-05-26）。這說明分層架構本身就有價值，不是靠大型模型的威力硬撐。

理解 L0 到 L3 的運作邏輯之後，下一步就是實際安裝，看看這套記憶系統在日常工作流程中是否真的能派上用場。下一章我們將它裝進 Hermes，用真實任務驗證分層記憶的表現。

短期任務怎麼省 token？Mermaid 符號化記憶的具體機制

長任務最燒 token 的地方，往往不是對話本身，而是工具 log。搜尋結果、錯誤軌跡、程式碼輸出，這些內容累積起來動輒數十萬 token。如果每一輪請求都把完整 log 塞進上下文，成本與延遲都會失控。TencentDB Agent Memory 的短期符號化記憶機制，把這個問題拆成四個步驟：卸載、抽取、注入、回溯。這個流程不追求「少存」，而是追求「存得聰明」，讓 agent 平常只看精簡的狀態圖，需要證據時再回頭翻原文。

把 log 卸載到外部檔案，先離開上下文

第一個動作是卸載。agent 執行任務時產生的完整 log 不再留在對話上下文，而是寫入外部檔案的 refs/*.md。這些檔案同時保留時間戳、來源段落與原始輸出，等同於長期記憶中 L0 的定位，原文全量保存，任何時刻都可以翻回最原始的資料。關鍵差異在於，這批檔案佔的是磁碟空間，不是 token 配額。 agent 的上下文因此被大幅清空，只留下任務真正需要的判斷依據。

抽出關係，壓成 Mermaid 畫布

第二步是抽取。系統不會把冗長 log 直接摘要成一段文字，而是抽取出其中的狀態、事件與依賴關係，重組成 Mermaid 畫布。每個節點都帶有 node_id，作為可尋址的索引。原本數十萬 token 的搜尋記錄與錯誤軌跡，可以被壓縮成幾百個 token 的圖形描述。以搜尋結果為例，完整 log 會是一長串網頁標題、摘要與內文片段，但畫布上只需要留下搜尋關鍵字、來源與結論的關係結構。Mermaid 語法本身就是極度精簡的表示方式，搭配中文標籤後，人與 AI 都能一眼讀懂任務拓撲。

錯誤軌跡的壓縮方式類似。agent 反覆試錯時，每次失敗的堆疊與錯誤訊息都會被抽成一個節點，記錄錯誤類型、觸發動作與解決狀態。畫布上可以看到哪些路徑走不通、哪些嘗試已經收斂，而不需要重讀每一段堆疊。以下是一個簡化範例：

graph TD
  A[搜尋: semgrep rule] --> B[NodeJS 官方文檔]
  A --> C[GitHub 範例]
  B --> D[採用 NodeJS 格式]
  C --> E[規則 v2 語法]
  D --> F[選定 v2 格式]
  E --> F

這段畫布描述只有幾十字，卻足以讓 agent 掌握「搜尋過程收斂到哪個結論」。相比之下，原始搜尋結果可能多達數千行。

只注入精簡狀態圖，出事再撈原文

第三步是注入。agent 每輪請求的 context 只放精簡狀態圖，而不是完整 log。當任務需要驗證細節，例如確認某個規則語法的正確寫法，agent 就依據畫布上的 node_id，用 grep 反向撈取 refs 中的原文段落。這個按需查詢的模式，讓 agent 平常看到的內容很薄，但需要時可以取得完整的證據鏈。回溯動作本身也是低成本操作，因為 node_id 指向的檔案路徑與行號是明確的，不需要重新掃描整份 log。

以搜尋結果為例，實際省下多少 token

具體數字可以這樣估算。假設一個長時任務中，agent 需要查詢十個技術關鍵字，每個搜尋結果包含網頁標題、摘要與內容片段，可能耗費五萬 token。符號化之後，畫布上只留下搜尋關鍵字、來源與結論的關係圖，可能只要五百 token。根據官方 README 宣稱的數據，WideSearch 在連續五十任務的長程 session 測試中，token 消耗從二點二一億降到八千五百六十萬，節省百分之六十一點四（來源：官方 README，2026）。這是官方自測數據，獨立實測也支持同樣方向。Pawel 在 Medium 發表的測試中，刻意把模型縮小到 Gemma 4 E4B，約四十億參數，在本地端運行，結果 token 消耗下降超過一半，任務完成率反而提升百分之二十三（Pawel，Medium，2026-05-26）。這說明符號化架構本身就有價值，不是靠大型模型的威力硬撐。

以錯誤軌跡為例，維持可追溯性

錯誤軌跡比搜尋結果更需要符號化，因為失敗次數會隨任務拉長而快速累積。社群討論中也提到負面記憶的價值，agent 試過 chmod 失敗，下一次就應該避開相同的路徑（Reddit r/AI_Agents，2026）。當錯誤節點被標記為已解決，agent 後續不需要再看該錯誤的完整堆疊。一旦問題再次出現，只需靠 node_id 撈回當時的失敗記錄，甚至能對比兩次錯誤是否為同一個根因。這種可追溯性讓壓縮不損失證據，每一層節點都保有回到原始 log 的路徑。

記憶治理才是真正的關鍵

符號化記憶看似只解決 token 成本，背後其實是記憶治理的思維。台灣工程師 blog.aihao.tw 指出，大多數記憶功能並不需要向量檢索，ChatGPT、Claude Code、Claude API、OpenAI cookbook 與 Mastra SOTA 全都沒有使用向量。真正困難的是寫入、整理、讀取與遺忘的治理（blog.aihao.tw，2026-04-28）。Mermaid 符號化的做法，正是把治理落實在卸載、抽取、注入、回溯四個步驟，讓 AI 不是把過去塞回上下文，而是從過去推理出這次該怎麼做。對台灣的開發者與中小企業來說，這套機制最直接的價值是降低 API 成本，同時讓 agent 的決策過程可以被稽核。下次當你看到 agent 又快又準地完成任務時，背後可能就是一張幾百 token 的 Mermaid 畫布在默默撐腰。

獨立實測：40 億參數小模型也能「記得」？從 20K→3K 的 token 奇蹟

上一章我們談了記憶架構的治理邏輯，但一個最常見的質疑立刻浮上檯面：那些漂亮的記憶機制，是不是只在大模型身上才跑得動？如果換成參數只有 40 億的小模型，記憶架構會不會瞬間失靈？這個問題非常關鍵，因為台灣多數中小企業不會有預算呼叫 GPT-4 等級的旗艦模型，在地端跑一個輕量模型才是常態。若記憶架構只能在強模型上運作，那對台灣企業來說就只是個昂貴的展示品。

2026 年 5 月 26 日，一位獨立開發者 Pawel 在 Medium 發布了名為「The 20K → 3K moment」的實測報告，直接回應了這個疑問。他刻意把模型縮小到 Gemma 4 E4B，約 40 億參數，跑在 Apple M1 Pro 的本地 Ollama 環境，全程零雲端呼叫。實驗設計包含 10 組任務 brief、3 組對照、30 次運行，並搭配 TencentDB Agent Memory 的記憶架構來驗證效果。結果出乎意料：token 使用量從原本的 20K 降到 3K 等級，降幅超過 50%，任務完成率反而上升了 23%。

實驗怎麼設計：把模型能力壓到最低，才能看出架構的真本事

要理解這項實驗的價值，得先看 Pawel 怎麼安排對照。他刻意選了 Gemma 4 E4B 這顆 40 億參數的模型，而不是市面上更強悍的 70B 或 400B 等級。理由很直接：小模型在推理能力上本來就比較弱，如果記憶架構能讓這種「弱模型」表現得比裸跑更好，那就證明了效果來自架構，而不是來自模型本身的硬實力。對照組則是完全不掛載任何記憶系統，讓 agent 用原生的上下文視窗直接處理任務。

實驗情境也不是簡單的問答，而是模擬真實工作場景的長程任務，包括多步驟的程式除錯、跨 Session 的專案背景追蹤、以及需要引用先前決策來完成後續工作的連續任務。每一組任務都被設計成必須「記得」前面發生過什麼，才有辦法把後面做好。他在 10 組 brief 中更混入了「誤導性資訊」，刻意在前一輪對話中埋下看似相關、實際上不該採納的內容，來測試記憶系統是否會不分青紅皂白地把垃圾也記進去。

Pawel 在 Medium 的報告指出，整個實驗過程完全在本地進行，沒有任何外部 API 呼叫，這也排除了「其實偷偷呼叫了雲端模型」的作弊嫌疑。他貼出完整的 Ollama 設定與執行紀錄，讓其他開發者可以用相同條件重現。這種透明程度在第三方實測中並不多見，也讓他的結論更有可信度。

數字會說話：token 降逾五成，完成率反升 23%

實驗結果最亮眼的不是單一指標，而是兩者同時發生：token 大幅下降的同時，任務完成率沒有跟著往下掉，反而往上走。這代表記憶架構不是靠著「把更多東西塞進 context」來唬弄任務，而是用更少的資訊達成更好的判斷。Pawel 在文中寫道，他原本預期 token 省下一些、完成率持平就很不錯了，結果完成率反升，讓他不得不回頭檢查是不是實驗設計出了問題。反覆確認後，他得出一個結論：架構在小模型身上也會點火。

這項結果與騰訊雲官方實驗室宣稱的數據方向一致，但測試條件完全不同。官方 README 的數據是跑在具備充足算力的環境，搭配效能較好的模型；Pawel 則是刻意用最陽春的設備、最小的模型，在完全不依賴雲端的條件下測試。兩者互相印證，反而讓記憶架構的有效性更具說服力。要知道，官方宣稱的數據常見的質疑就是「用強模型硬撐」，但 Pawel 的實驗直接繞開了這種批評。

更值得玩味的是 token 從 20K 降至 3K 的意義。20K token 對現代模型來說其實不算特別長，許多模型都能處理 128K 甚至 200K 的上下文。但長上下文不代表有效利用，模型在面對超長內容時，往往會忽略中段資訊，或者被無關細節干擾判斷。Pawel 實驗中的記憶系統把 20K 的原始內容壓縮成 3K 的結構化摘要，等於強迫 agent 只看真正重要的部分，也減少了注意力分散的機率。這正好呼應了前章提到的治理概念：與其給 agent 更多資料，不如給它更精準的資料。

為什麼這項實測重要：記憶架構不是強模型的專利

把這項實測擺回整個 AI 記憶領域來看，它的價值在於打破了「記憶＝模型夠強」的迷思。過去很多開發者認為，只要模型參數夠多、上下文夠長，AI 自然就會「記得」事情。但 Pawel 的實驗證明，當模型本身不夠強時，記憶架構反而更能展現價值。因為小模型的推理能力有限，更需要外部機制幫它篩選資訊、整理脈絡，讓它把有限的運算資源集中在真正的任務判斷上。

對台灣的軟體團隊來說，這項發現格外實用。台灣有大量接案公司、內部工具開發團隊，他們不可能每一案都租用頂級 API。多數時候，他們需要的是一個能在本地端穩定運作的 agent，處理像是整理客戶往來紀錄、追蹤專案決策變更、或者從舊程式碼中找出修改影響範圍之類的工作。這些任務不需要世界最強的推理能力，但非常依賴對「之前發生過什麼」的正確理解。記憶架構補上的正是這一塊。

成本面也很有感。假設一個團隊每天跑 200 次 agent 任務，每次省下 15K token，一天就省下 300 萬 token。以目前主流 API 的計價方式，長期下來是相當可觀的數字。更別提完全本地部署的版本連 API 費用都省了。Pawel 的實測直接點出了一條降低營運成本的路徑，而且這條路不需要犧牲任務品質，甚至可能做得更好。

誠實面對限制：這不是萬靈丹

當然，Pawel 的實驗也有它的限制。40 億參數的模型雖然證明架構有效，但碰到需要高度創造力或複雜推理的任務時，小模型的天花板依然存在。記憶架構能讓小模型「記得」，但不代表它能讓小模型「變聰明」。此外，Pawel 的實驗任務偏向結構明確的工作流程，如果換成開放式探索任務，記憶系統的幫助幅度可能沒有那麼大。

Reddit 的 r/AI_Agents 討論串也點出另一個問題：記憶有沒有真的改變未來的行為，還是只是把過去的事實重新翻出來？記憶系統做得好，應該要能影響 agent 之後的決策品質，而不是變成一個被動的查詢工具。這點在 TencentDB Agent Memory 的設計中透過 L0 到 L3 的分層結構來處理，但實際效果仍需要更多長期測試驗證。r/openclaw 的實用回饋也提到，記憶捕捉還是偏被動，常常要使用者主動喊「記住這個」，這代表記憶系統的主動性還有進步空間。

台灣工程師 blog.aihao.tw 在 2026 年 4 月的觀點也提供了另一種思考角度：大多數記憶功能其實不需要向量檢索，真正的難題在於治理，也就是寫入、整理、讀取與遺忘的機制。Pawel 的實測某種程度上呼應了這個看法，因為他測試的記憶系統核心是結構化壓縮與符號化，而不是堆疊更大的向量資料庫。當 40 億參數的小模型都能靠架構撐起記憶表現時，我們更有理由相信，AI 記憶的勝負關鍵在於機制設計，而不在於砸多少算力。

台灣觀點：記憶不是向量檢索，而是治理與推理

台灣工程師 blog.aihao.tw 在 2026 年 4 月提出一個在 AI 記憶領域格外清醒的觀點：「大多數記憶功能不需要向量檢索。」這句話乍聽之下很反直覺，因為過去兩年向量資料庫幾乎成為 AI 記憶的代名詞。但他接著指出，ChatGPT、Claude Code、Claude API、OpenAI cookbook、Mastra SOTA 這些實際運作的系統，全都不依賴向量檢索。真正的困難在於治理，也就是寫入、整理、讀取、遺忘這四個環節的機制設計。記憶不是「把過去塞回上下文」，而是「從過去推理出這次該怎麼做」。

記憶的本質不是儲存，而是判斷：什麼該記、什麼該忘、什麼時候該拿出來用。

TencentDB Agent Memory 的分層設計，恰好為這個觀點提供了具體的實作範例。我們可以從治理的四個維度，一一對照它的架構，並從台灣開發者與企業使用者的角度，找出真正有價值的部分。

寫入：決定什麼值得記得

人類的大腦不會記得每天的早餐內容，但會記得重要的談判細節。AI 記憶系統的寫入機制就是在做類似的價值判斷。TencentDB 的設計中，L0 層保留全部原始對話當作兜底，但 L1 層只抽取原子事實，例如「使用者偏好 TypeScript」「專案部署在 AWS 新加坡機房」。從 L0 到 L1 的過程就是寫入治理：什麼要被提煉，什麼留在原地當證據。

如果所有對話都被同等對待，系統很快就會被雜訊淹沒。台灣中小企業常用的 LINE 客服群組就是最佳例子，每天訊息量龐大，但真正重要的決策往往只有幾則。一套好的記憶系統必須自動辨識哪些是值得長期保存的決策，哪些只是日常寒暄。這正是台灣團隊導入 AI 助理時最常忽略的環節，大家急著串 API，卻沒想清楚記憶的來源品質。

整理：讓未來的自己看得懂

寫入之後是整理。TencentDB 的 L2 層把原子事實組合為場景塊，用 Markdown 格式記錄來龍去脈，例如「報價流程」這個場景，會包含客戶需求、報價歷史、的成交條件。L3 層則是使用者畫像，整理出技術偏好、代碼風格、常用工具鏈。上層管判斷、下層管證據，整條證據鏈從 L3 一路追溯到 L0 原始對話，壓縮了卻不丟失依據。

這種分層設計在台灣團隊協作中特別實用。假設一位新工程師加入團隊，他不需要翻閱過去一年的對話紀錄，只要看 L3 畫像和 L2 場景塊，就能快速理解團隊的慣例與偏好。這正好回應了台灣新創團隊長期的知識傳承難題。過去我們常看到團隊用 Notion 或 HackMD 手動整理共筆，但文件一多就散亂失修，AI 記憶系統有機會把這份整理工作自動化，而且整理結果還保留原始證據可以回溯。

讀取：在對的時機撈出對的資訊

記憶系統最怕的是把所有資訊一股腦塞回上下文。TencentDB 用 BM25 加上 Embedding 兩路召回，關鍵字精確命中與語意模糊匹配互補，再用 RRF 融合排序。這比單靠向量檢索更貼近真實使用情境。台灣工程師習慣中英混雜表達，例如「那個 endpoint 的 response 格式」這種句子，純語意檢索可能找不到精確的變數名稱，但 BM25 可以。反之，當使用者用「上次那個跟金流有關的問題」這種模糊描述，語意檢索又能派上用場。

官方 README 宣稱 WideSearch 成功率從 33% 提升到 50%，token 用量節省 61.4%，連續 50 個任務的長程 session 測試結果。這些數據雖然是官方自測，方向卻值得參考。對台灣開發者而言，token 成本節省不只是帳單數字下降，更代表 agent 可以在更長的任務鏈中保持專注，不會因為上下文爆掉而迷失方向。

遺忘：最被低估的治理環節

Reddit 的 r/openclaw 社群成員提出尖銳觀察：目前記憶系統捕捉還是太被動，常常要使用者主動喊「記住這個」。記憶膨脹更是所有長期運作系統的痛點。官方宣稱用戶事實召回率從不到 30% 提升到 79%，這同時也意味著有 21% 的事實被遺漏，而且沒有人能保證記憶不會愈來愈臃腫。

遺忘機制之所以困難，是因為系統需要判斷什麼資訊已經過時。競品 Zep/Graphiti 採用時序知識圖譜，用 valid_at 與 invalid_at 標記事實的有效區間，這是值得參考的方向。但目前整個 AI 記憶領域，還沒有一家廠商能完美解決遺忘的課題。對於台灣企業來說，這意味著導入記憶系統時，不能只評估「記得多不多」，還要追問「忘得對不對」。

獨立實測方面，Pawel 在 Medium 發表的實測刻意把模型縮小到 Gemma 4 E4B，約 40 億參數的本機模型，完全不呼叫雲端 API。結果 token 用量下降超過 50%，任務完成率反而提升 23%。這個實測的意義在於，記憶系統的成效主要來自架構，而不是背後的大模型。對台灣中小企業而言，這代表即使預算有限、沒有 GPU 叢集，靠好的架構也能改善 AI 助理的記憶能力。

平衡看待：優點與限制

我們必須誠實指出，TencentDB Agent Memory 雖然架構設計出色，仍有幾個限制必須放在心裡。

• 官方數字都是自測：WideSearch、PersonaMem、SWE-bench 這些數據都來自官方 README，整個領域沒有公平的第三方對照基準。不同專案用不同測試集、不同裁判模型，跨專案比較意義有限。
• 專案太新：GitHub 上顯示專案建立於 2026 年 4 月，v2.0 正式版在 8 月 3 日釋出，團隊級功能上線不到一週，生產環境的穩定性尚未經大規模驗證。官方在 GitHub issues 承諾 24 小時內回應，但這不代表軟體本身已經成熟。
• 部署複雜度：三件式 Docker 部署對台灣中小企業不算友善。不過直接整合進 Hermes 的方式相對簡單，memory provider 設定加上 Gateway 指向 :8420 就能啟用。

此外，整個 AI 記憶領域的 benchmark 各自為政，不同測試、不同裁判模型、不同 harness，官方數字都是 vendor-run。digitalapplied 在 2026 年 8 月的實測中，甚至發現 Mem0 自家宣稱 94.4 分，第三方實測卻只有 49.0 分，同樣是在 LongMemEval 上。台灣團隊在比較開源記憶引擎時，必須把這些數據當作參考線索，而不是採購依據。

台灣企業的落地觀察

從台灣市場的角度來看，我們認為 AI 記憶系統最適合導入的場景，是那些需要長時間跨專案協作的團隊。例如軟體外包公司，客戶偏好、技術決策、驗收標準散落在不同的對話與文件中，一套有治理機制的記憶系統可以大幅減少重複溝通的成本。另一類是垂直領域顧問服務，例如法律與會計，每次案件都有大量背景知識需要延續。

導入時建議從一個小團隊、一個明確場景開始試行。例如讓記憶系統記錄一個月內的技術決策，然後檢視三件事：召回的正確率是否足夠、遺忘的判斷是否合理、團隊成員是否願意信任這套系統的輸出。記憶系統是長期投資，不是安裝後就立刻見效的工具，需要一到兩個月的調校期才能看到真正的回報。

替代方案有限公司觀點

我們在台灣協助企業導入 AI 工具多年，觀察到一個普遍現象：多數團隊急著追求「更聰明的模型」，卻忽略了「更有效的機制」。AI 記憶正是機制勝過算力的典型案例。我們認為台灣企業在評估記憶引擎時，不應該只比較星數與 benchmark 分數，而應該實際測試四件事：寫入時能不能自動判斷什麼值得記、整理後能不能讓團隊成員快速理解、讀取時能不能在對的時機撈出對的資料、以及最容易被忽略的，記憶系統有沒有辦法健康的遺忘。TencentDB Agent Memory 的 L0 到 L3 分層設計，確實是目前開源專案中治理架構最完整的實作之一，它把證據鏈的概念導入記憶，讓 AI 的判斷有所依據。但我們也必須提醒，官方宣稱的效能數據仍停留在自測階段，台灣團隊必須自己驗證。我們的建議是，選一個真實的長期專案，例如三個月的客服紀錄或半年的開發歷程，實際跑一輪記憶系統，比較導入前後團隊找回資訊的時間成本。唯有真實數據，才能判斷這套工具是否適合你的團隊。開源的好處就在這裡，你可以自由的測試、檢視、修改，不需要先付出任何授權費用。但自由也伴隨責任，記憶品質的好壞，最終還是掌握在使用者自己的手上。

替代方案有限公司觀點：開源記憶引擎對台灣中小企業的意義

我們在協助台灣中小企業導入 AI 的實務經驗中，反覆看到一個窘境：老闆花了錢訂閱各種 AI 工具，團隊也認真用了三個月，但 AI 永遠記不住客戶上次改過什麼規格、報價單哪一版才算數、哪位老客戶偏好電話溝通而非郵件。每一次新對話都是從零開始，員工被迫把歷史脈絡重新打一遍，這不是效率問題，而是信任問題。當 AI 連「上次我們講好的事情」都無法掌握，團隊很快就會放棄它，回到 Excel 和通訊軟體的老路。

因此我們持續關注開源記憶引擎的發展。TencentDB Agent Memory 在 2026 年 5 月開源後，我們實際讀過架構文件、追蹤社群討論、也看了獨立開發者的實測紀錄。這不是一篇單純的產品歌頌文，我們想誠實說說：這套工具對台灣中小企業到底意味著什麼，以及哪些地方我們持保留態度。

MIT 授權與可自架，回應台灣企業最敏感的資料主權

先講最實際的。TencentDB Agent Memory 採用 MIT 授權，GitHub 上星數 18，423、fork 1，660（來源：GitHub API，2026 年 8 月 9 日查詢）。MIT 代表企業可以自由使用、修改、商用，不需要付授權費，也不需要回饋原始碼。對預算有限的中小企業來說，這是零成本起步的優勢。更重要的是可自架，記憶引擎可以完全部署在自己的伺服器或雲端帳號內，對話紀錄、客戶偏好、專案歷史全部留在自己手上，不經過任何第三方平台。

這是台灣中小企業特別在意的事。我們接觸過幾家做國際貿易的公司，他們的客戶名單與報價策略是高度機密，根本不可能接受這些資料送到外部 AI 服務處理。也有一些公司雖然本身不是受管制產業，但客戶要求簽訂資料處理協議，任何外流的風險都直接影響接單資格。本地部署讓記憶引擎成為公司內部基礎設施的一部分，就像自家機房裡的 NAS，而不是把金庫鑰匙交給別人。

另外要稱讚的一點是，它的核心架構確實有獨到之處。官方 README 提出了 L0 到 L3 的分層記憶金字塔：L0 保留原始對話全文、L1 萃取原子事實、L2 組織成場景脈絡、L3 建立用戶畫像。設計原則是上層管判斷、下層管證據，AI 先看畫像判斷方向，細節不足往下挖場景，證據不夠就翻原始對話。這條證據鏈是連續的，每一層的結論都可以追溯到源頭。我們認為這是正確認知，記憶系統的價值不在於「塞得多」，而在於「判斷時有據」。獨立開發者 Pawel 在 Medium 上的實測也支持這個方向（來源：Pawel，Medium，2026 年 5 月 26 日），他故意把模型縮小到 Gemma 4 E4B 約 40 億參數、跑在 M1 Pro 本地 Ollama，結果 token 用量降低超過 50%、任務完成率反而提升 23%。這說明架構本身有效，不是靠強模型硬撐。

我們必須誠實指出的三個風險

但這不代表我們建議台灣中小企業立刻全面導入。有幾個風險必須擺在檯面上。

第一，部署複雜度對中小企業並不友善。官方提供的是 Docker 三件套：memory-core、memory-hub、memory-proxy。雖然有 start-all.sh 一鍵啟動腳本，但這假設使用者的伺服器已經具備 Docker 環境、懂得管理容器、會看 log、能處理網路埠衝突。台灣多數中小企業沒有專職 IT 人員，總經理特助兼 MIS 是常態。要他們自行維運三件套，坦白說門檻偏高。比較可行的路徑是透過 Hermes 這類 Gateway 直接接上記憶提供者，把複雜度藏起來，但這又牽涉到額外工具的學習成本。好消息是官方已經支援 Hermes 的原生整合，這條路比從零部署簡單許多。

第二，記憶膨脹與遺忘機制尚未完全解決。Reddit 的 r/openclaw 討論區有使用者回饋，捕捉機制還是太被動，常常要主動喊「記住這個」，而且隨著記憶累積，系統回應變慢、token 消耗增加（來源：Reddit r/openclaw，2026 年 6 月）。官方宣稱的效能數據，包含 WideSearch 成功率從 33% 提升到 50%、token 節省 61.4%、PersonaMem 準確率從 48% 提升到 76%（來源：官方 README），這些都是官方自測的結果，不是第三方公正基準。實際上整個記憶領域的 benchmark 各自為政，不同測試、不同裁判模型、不同 harness，根本無法公平比較。我們不能把任何一家的官方數字當成真理。

第三，團隊級功能才剛推出。v2.0 正式版在 2026 年 8 月 3 日發布，距離本文撰寫不到一週。Skill 提煉、LLM-Wiki、CodeGraph、記憶資產的可見性權限管理，這些都是團隊協作的核心功能，但正因為太新，生產環境的穩定性還需要時間驗證。GitHub issues 上 8 月 7 日仍有 bug 回報（例如 issue #846），官方承諾 24 小時內回應，但對企業來說，一個不穩定的記憶系統比沒有記憶系統更危險，因為團隊會開始依賴它，然後在關鍵時刻出錯。

我們的立場：記憶是推理的依據，不是對話的錄音

我們的觀點是，好的記憶架構不是把對話全部塞回去，而是讓 AI 懂得依據證據鏈做出判斷。這個立場與台灣工程師 blog.aihao.tw 在 2026 年 4 月的觀察一致：大多數記憶功能其實不需要向量檢索，ChatGPT、Claude Code、官方 cookbook 都不用向量，真正難的是治理，包含寫入、整理、讀取、遺忘。記憶不是「把過去塞回上下文」，而是「從過去推理出這次該怎麼做」。TencentDB Agent Memory 的分層設計確實往這個方向走，它用 BM25 與 Embedding 雙路召回、RRF 融合排序，兼顧精確命中與語意模糊匹配，這是務實的做法。但台灣企業導入時必須理解，工具只是半套，剩下的一半在使用者自己。

具體落地建議，我們認為有三個場景最適合先試。

第一個是客服紀錄整理。把三個月的客戶對話丟進去，讓 AI 自動建立客戶畫像與偏好，之後每次客服回覆前先查記憶，至少可以省下「客戶已經講過三次的需求」這類尷尬。第二個是報價與專案歷史。過去報價的來龍去脈、客戶殺價的底線、成交的條件，這些都是 L2 場景與 L3 畫像的典型應用，適合貿易商與接案公司。第三個是法規與內部文件查詢。把 ISO 文件、SOP、合約範本結構化，讓 AI 在回答時附上依據來源，員工可以追溯到原始文件，這正是證據鏈精神的直接受益場景。

但我們也要勸告，不要一開始就追求大而全。選一個真實的長期專案，例如三個月的客服紀錄或半年的開發歷程，實際跑一輪記憶系統，比較導入前後團隊找回資訊的時間成本。官方宣稱的數據只能當作參考，台灣團隊必須自己驗證。開源的好處就在這裡，你可以自由的測試、檢視、修改，不需要先付出任何授權費用。但自由也伴隨責任，記憶品質的好壞，最終還是掌握在使用者自己的手上。我們相信，願意腳踏實地驗證的團隊，才會真正從記憶引擎中獲得競爭力。

結語：從「忘記」到「記得」，你可以怎麼開始

這趟探索從一個很實際的痛點出發：為什麼 AI 助手總是忘記你交代過的事？我們一路拆解了 TencentDB Agent Memory 的設計哲學，看見它如何把「記憶」從對話紀錄的附屬品，提升為一套有治理機制的基礎設施。整個系列讀到這裡，你可能已經掌握了 L0 到 L3 的分層邏輯，也理解了 Mermaid 符號化如何壓縮短期任務的軌跡。但知道原理還不夠，真正的挑戰在於：你願不願意花一個下午，把這套開源引擎裝進自己的環境，親手驗證那些號稱的數字？

先讓我們把這個系列最重要的幾件事收攏在一起。長期記憶方面，L0 保留原始的每一句話，L1 提煉出可精確召回的原子事實，L2 把情境組織成人類可讀的場景塊，L3 則累積成穩定的用戶畫像。記憶的召回路徑不是單向搜尋，而是沿著金字塔上下探索。需要判斷時從 L3 的畫像出發，細節不足就往下鑽，直到 L0 找到最原始的證據。這是整條證據鏈不斷線的核心設計。

短期任務的處理同樣有巧思。工具執行產生的搜尋結果、錯誤訊息、程式碼片段，動輒幾十萬 token。與其全部塞進模型上下文，不如先卸載到外部檔案，再抽取關係繪製成 Mermaid 狀態圖，只把這張圖放進 Agent 的視野。遇到需要驗證的細節，就用圖上的 node_id 回到原文去查。如此一來，Agent 既能掌握任務全貌，又不會被雜訊淹沒。

v2.0 正式版把觸角延伸到團隊協作。Chat Memory、Skill、Wiki、CodeGraph 四大資產，分別對應對話沉澱、流程標準化、知識結構化與程式碼影響分析。Memory Hub 提供統一的操作介面，並用 private、team、restricted 三級可見性來管理資產的存取權限。這些功能加在一起，讓記憶引擎從單人工具長成團隊基礎建設。

原理說得再好，終究要看數據。我們在系列文裡反覆強調，官方發布的數字都是自家環境的測試結果，不是第三方公正單位給的。把它們當作參考，不當作真理。下表把官方宣稱與獨立實測放在一起對照。

對照之後可以看到一個令人安心的現象：官方宣稱的方向，在獨立實測中得到部分印證。Pawel 刻意用了只有約四十億參數的 Gemma 4 E4B，在 M1 Pro 的 Mac 上完全離線運行，結果 token 用量下降了超過一半，任務完成率反而提升兩成三（來源：Pawel 實測，Medium，2026-05-26）。這代表分層與符號化的架構確實有效，不是靠頂級模型硬撐出來的成績。當然，樣本數與測試情境都有限，任何團隊要導入之前，都該用自己的資料重跑一遍。

另一方面，社群的聲音我們也不能忽略。Reddit 上有人肯定完全離線的路線，也有人質疑記憶是否真的改變了未來行為。r/openclaw 的使用者抱怨捕捉仍偏被動，常常要主動喊「記住這個」，記憶膨脹的問題也沒有完全解決。GitHub issues 到了 2026 年 8 月 7 日仍有人回報錯誤。這些都不是致命傷，但提醒我們這仍是個快速演進的年輕專案，v2.0 推出至今才幾天，生產環境要自己扛起驗證責任。

台灣工程師 blog.aihao.tw 在 2026 年 4 月的文章就點出，大多數記憶功能其實不需要向量檢索，真正難的是治理，包含寫入、整理、讀取與遺忘。這個觀點與 TencentDB 的分層證據鏈方向一致，也補上了重要的平衡思考。記憶不是把過去全部塞回上下文，而是從過去推理出這次該怎麼做。

那麼，看完這些，你該從哪裡開始？我們建議最務實的第一步行動，是拿起手上現有的 Hermes 環境，把 Memory Proxy 接上去。Memory Proxy 同時支援 Anthropic 與 OpenAI 兩種協定，啟動之後它會在第一輪引導你選定團隊、Agent 與任務，後續每一輪自動把相關的 L2、L3 記憶、技能與 Wiki 內容組進提示詞。你不需要改寫現有程式的呼叫方式，只要把端點指向 Proxy，就能觀察記憶注入前後的行為差異。

如果你不想動任何程式碼，那就直接打開 騰訊雲的 GitHub 頁面，從官方專案的 README 開始讀起。裡面有完整的架構說明、部署指令與範例。花一個小時把設計文件讀完，勝過亂猜十個設定參數。更重要的是，開源專案的原始碼就在眼前，你可以親眼確認資料寫入的格式、被誰讀走、存放在哪裡。

我們在前一章提過，不要一開始就追求大而全。從一個真實的長期專案下手，例如三個月的客服紀錄或半年的開發歷程，讓系統實際跑一輪，比較導入前後團隊找回資訊的時間成本。這種腳踏實地的驗證，才是導入開源軟體的正確姿態。如果這一系列文章對你的導入決策有幫助，歡迎來信與我們交流你的實驗結果。無論是踩到什麼坑，或是量測出什麼有趣的數字，我們都很想聽。來信請寄到 [email protected]。

📩 有任何問題或需要協助，歡迎聯絡我們：[email protected]