第二週講的是同一件事的不同切面：怎麼讓一個本質上會失憶的 LLM，變成記得住事情的 Agent。
走到這裡，回頭看會發現這六天其實提煉出了五個可複用的設計模式。今天把它們收斂成一張表，再回答一個一定會被問的問題：那 RAG、向量資料庫呢？
先把這週的結論放最前面：大腦是耗材，記憶是本體——這六天都在為這句話鋪路，收尾再展開。
先擺正這一週的位置：三層記憶與 dreaming 是框架給的，不是我的發明（Day 8 交代過）。下面五點不是「我怎麼設計記憶系統」，是拿到一個內建記憶引擎之後，我用半年學到的五件事——多數讀者的處境會跟我一樣，是使用者不是作者，所以我覺得後者比前者有用。
| 模式 | 一句話 | 適用場景 | 這一週的實證 |
|---|---|---|---|
| ① 記憶分層 | 短期(session) / 長期(檔案) / 鞏固(dreaming) 各司其職 | 任何需要跨 session 記憶的 Agent | 整合層在錯的時區跑了不知道多久——功能全對、時間全錯（Day 9） |
| ② 仿生整合 | 仿照睡眠離峰自動整合：deep 記事實、rem 做夢串脈絡 | 持續產生日誌、需要提煉的系統 | 晉升器「盡責地」把一串 token 記進長期記憶（Day 10） |
| ③ 膨脹治理 | 設警戒值 + 自動歸檔，記憶要精煉不堆積 | 長期運行、記憶會無限增長的系統 | 寫完那篇的兩天後，歸檔真的自己跑了：42KB → 7KB（Day 10） |
| ④ 跨系統協作 | 共享單一真相 + 雙向同步 + 非同步交接 | 多個 Agent / 多台機器要協作 | 一次誤還原教我：交接檔是唯一的意圖紀錄（Day 11） |
| ⑤ 全檔案化持久層 | 記憶全存 Markdown、不上資料庫 | 個人規模、低併發的系統 | 「該換資料庫」的判準後來真的被觸發（Day 13） |
這五個模式背後其實是同一個哲學：把 AI 的「狀態」外化成人和機器都能讀寫、版控、同步的檔案。 一旦記憶不再是模型內部的黑盒，它就變成可以工程化治理的資產。
第四欄是我特別想留的。這張表如果只有前三欄，就是一篇教科書；第四欄那些出包現場，才是這一週真正的內容——模式是框架給的還是自己補的都好，要變成你的，都得先在你身上壞過一次。
講完「全檔案、沒資料庫」，最常被問的就是：那 RAG（檢索增強生成）和向量資料庫，不香嗎？
先花 30 秒把 RAG 講清楚，免得比較表變天書。RAG（Retrieval-Augmented Generation）的流程是：把文件切塊，每塊經 embedding 模型轉成向量（一串代表語意的數字）存進向量資料庫；提問時，問題也轉成向量，撈出語意最接近的幾塊塞進 context，再讓模型回答。所以問「持倉」能撈到寫著「部位」的段落——它比對的是意思，不是字面。
香，但解決的是不同問題。我的判斷是這樣分的：
| 我的檔案化記憶 | RAG / 向量資料庫 | |
|---|---|---|
| 擅長 | 個人化的、會演化的記憶（決策、偏好、狀態） | 大量、靜態的知識檢索（文件庫、知識庫） |
| 資料量 | 幾 MB，人類可讀範圍 | 幾 GB～TB，超出人類可讀 |
| 查詢 | grep / 全文，夠用 | 語意相似度檢索 |
| 「想起來」這步 | 靠 Agent 自覺去讀（Day 8 講過：被讀到才算記得） | 每次提問強制檢索，自動化 |
| 可改性 | 隨手編輯檔案 | 要重新嵌入 |
一句話：當你的「記憶」是幾百條會變動的個人決策，用檔案；當你的「知識」是幾千份不太變的文件，用 RAG。 兩者不衝突——成熟的系統常常是「檔案化記憶管狀態，向量庫管知識檢索」並存。
我目前的規模還在「檔案就夠」的這一側，所以沒上 RAG。等哪天知識庫真的大到 grep 撐不住，再加也不遲——這跟 Day 13 講的「個人系統不用資料庫」是同一個判斷。
這一年 token 單價大幅下降（比 2025 年降了約八成），「把資料直接塞進 context」的成本門檻低了很多，於是「RAG 已死」的說法又熱了一輪。我的看法是：降價改變的是分界線的位置，不是分界線的存在。
塞進 context 解決的是「放得下」，但 retrieval 真正的難題從來是「撈得準」——幾千份文件裡挑出對這個問題最相關的三段，這個精準度問題不會因為 context 變便宜而消失；相反地，全塞進去反而放大了「重點稀釋」（Day 10 講過的老症頭）。所以 RAG 仍有它的位置，只是引入門檻變高了：資料量要真的大到塞不下、或對訊號密度的要求真的高，才值得養那套嵌入、索引、重排的複雜度。對我這種幾 MB 的個人記憶，降價反而讓答案更明確——檔案就好。
| Day | 主題 | 核心 |
|---|---|---|
| 8 | 三層記憶架構 | 短期 / 長期 / dreaming |
| 9 | Dreaming 機制 | 仿睡眠的 deep/rem/light 整合 |
| 10 | 膨脹監控與歸檔 | 記憶要精煉不堆積 |
| 11 | 跨系統記憶協作 | 共享真相 + 同步 + 交接 |
| 12 | 治理系統自己也胖了 | 冷熱分層＋漂移對帳 |
| 13 | 全 Markdown 架構 | 持久層選型 |
Day 1 的角色表把 Clawrion 定位成 💾 持久化系統，那句「它不思考，它記得」當時讀起來像降級。這週講完，我覺得那其實是升級。
思考那側半年來換過好幾顆腦——模型升級、工具更迭，哪個好用換哪個，大腦是耗材。但這半年沉澱下來的決策、教訓、偏好，全部活在那疊 Markdown 檔裡，誰來當大腦，都得先讀它才知道「我們做到哪了」。哪天模型全換掉，只要記憶還在，這個系統就還是它；反過來，記憶檔丟了，換多聰明的模型來都不是它。
所以「框架給引擎、我補治理」這句話，治理的從來不只是幾支腳本——**是整套系統裡唯一換不掉的資產。**大腦可以外包，記得不行——這句話 Day 8 開頭立過，這一週用六天把它坐實，頭尾就此扣上。
第一週講「骨架」，第二週講「記憶」。一個有骨架、有記憶的 Agent，已經能記住你、理解脈絡了——但它還只是被動地等你問。
下週進入自動化實戰：讓這套系統真正「動起來」——盤前自動推播、家居條件觸發、排程怎麼設計，以及那些自動化才會遇到的坑。Week 3，我們讓 Agent 開始替我做事。
🔑 這篇的關鍵字
記憶設計五模式（記憶分層／仿生整合／膨脹治理／跨系統協作／全檔案化持久層）· RAG vs 長 context vs 精煉記憶的取捨 · 框架給引擎、你補治理 · 大腦是耗材、記憶是本體（模型可以換，記憶檔不能丟）——這是這一週的總結論
我是一名金融業資訊工程師，這是我半年來在家自架 AI Agent 系統的實錄。
iThome鐵人賽
看影片追技術