記憶系統運作大約三個月後，我發現它每次醒來要重讀的東西越來越肥——帳單先有感，反應也慢了半拍。

不是模型變笨，是它的「腦容量」爆了——DREAMS.md、MEMORY.md 這些長期記憶檔，隨著每天 dreaming 不斷寫入，悄悄長到了幾十 KB。每次 Agent 啟動都要把這些檔讀進 context，檔越大、每次醒來付的越多、開口也越慢。

昨天（Day 9）講 dreaming 怎麼把記憶寫進來。今天講相反的方向：記憶也得會減肥。

而這件事，框架沒有幫你做。它負責「把重要的事記住」，至於記到什麼時候該清、清哪些、清完怎麼還查得到——沒有預設答案。這一篇開始，講的都是我自己補上去的部分。

膨脹的症狀：不只是慢

記憶檔變大，表面是「載入變慢」，但底下有兩個更貴的問題：

• context 成本上升：每次 Agent 啟動都要把長期記憶讀進 context，檔案越大，每次喚醒的 token 成本就越高（還記得 Day 7 的 cache_write 嗎？檔越大，每次寫進快取的量也越大）。
• 重點被稀釋：這個更隱性。當 MEMORY.md 塞了三個月的瑣事，真正重要的決策會被埋在雜訊裡——對人是「找不到重點」，對 Agent 是「抓錯重點」。

記憶膨脹不只讓系統變慢，還會讓它變笨。

警戒值設計：什麼時候該減肥

我不想等到系統卡了才處理，所以設了幾條機械式的警戒線，寫進 workspace 的健康閘道：

數字不是拍腦袋來的：30KB 大約是「一次讀還能接受」的上限，50KB 就明顯拖慢且稀釋重點。dreaming 每日產出，累積到三位數就該把舊的收起來——所以檔數這條只設一道門檻，破百就動手。

50KB 聽起來很小？換個單位就不小了：50KB 的中文約一萬六千字、粗估兩萬 token。單看只是視窗的零頭——但它不是偶爾讀一次，是每次醒來都全文重讀，乘上一天幾十次喚醒、再乘三十天，檔案大小會直接寫在帳單上。所以這條警戒線量的從來不是硬碟空間，是每次醒來要繳的固定稅。

把這些設成可量測的閾值，而不是「感覺有點大了再說」，系統才能自己提醒我、甚至自動處理。

自動歸檔工具：dreams_archiver

光有警戒線不夠，還要有把舊記憶「收納」的工具。而做到後來我才發現，「肥胖」其實有兩種，得用兩把不同的刀：

這兩件事聽起來像同一回事，實作起來完全不同——前者要解析 Markdown 找出月份邊界，後者只要看檔名日期搬檔案。硬要用同一支腳本做，會寫出一個兩邊都不好用的東西。

刀一：切內容（管 DREAMS.md）

觸發條件是大小：超過 50KB 由每小時的健康守衛自動叫起來，低於 30KB 直接跳過不動作。它會把舊月份的內容整段切出來，寫進 memory/dreams/YYYY-MM.md，主檔只留近期。

跑完會印一行 60KB → 18KB（縮減 70%）這樣的結果——我刻意讓它報縮減比例而不只是報成功，因為「成功但什麼都沒搬」跟「成功且搬了七成」在維運上是兩種完全不同的事，而前者通常代表我的切割邏輯壞了。

實際的歸檔長什麼樣？我現在的倉庫裡，四月那份是 5.5KB、五月那份是 61KB——五月是系統最忙的一個月，那個檔的大小本身就是一份工作量紀錄。而現役的 DREAMS.md 維持在 42KB，還沒撞到紅線。

📌 補記（寫完這篇之後發生的事）：上面那句「還沒撞到紅線」，在我寫完的兩天後就失效了。
8/2 凌晨四點多，DREAMS.md 漲過 50KB，守門的排程照設計把歸檔工具叫起來，切出
六月那份 13KB、七月那份 25KB，主檔降到約 7KB（寫這段補記的今天，它已經又長回 16.5KB——
它本來就該一直長，這正是需要歸檔的原因）。

我是後來為了核對這篇的數字才發現它跑過的。翻紀錄才看到，它當時其實發過一則完成通知——
是我自己漏看了。工具安靜做完、留下一行紀錄，這正是我想要的樣子。

這也是這整個系列裡少數「我寫的東西後來真的被驗證了一次」的例子。
寫的當下它還是個設計；兩天後它變成一段有前後數字的實績：42KB → 7KB，我全程沒有介入。

刀二：搬整檔（管 dreaming 目錄）

這把刀的觸發條件是檔案數，因為 dreaming 每天固定產出三個檔（deep / rem / light 三層各一，Day 9 講過）。

數字算起來很嚇人：一個 workspace 一個月就是 90 個檔（3 層 × 30 天）。而我有七個 workspace（根目錄 + 六個角色），所以光一個月就是六百多個檔。放著不管，半年後就是四千個。

它的規則很單純：保留最近 30 天，更舊的整批搬走，依 <角色>/<層級>/YYYY-MM/ 分類擺好。目前歸檔庫累積八百多個檔，加上還在現役的，全部 dreaming 歷史約一千五百個——上千次「夜間整理」，一條都沒丟。

先回答一個你可能正想問的問題：**把記憶搬走，它會不會「失憶」？**不會——被搬的是幾乎從不被讀的冷層，而人格（SOUL）與現役記憶（MEMORY.md）從頭到尾不在歸檔範圍，主檔也永遠留著近期內容。歸檔是搬家不是刪除：要查的時候，檔案都在。真正的風險不在「搬」，在「搬錯」——所以才有下面這條紀律。

兩把刀共通的一件事：dry-run

實際動手前，兩支都能先跑「只列出會搬哪些、不真的搬」的預演。

**任何會動到記憶的自動化，都該先能 dry-run。**這不是潔癖——記憶檔沒有回收桶，搬錯了你不會馬上發現，等到某天 Agent 忘記一件重要的事，你已經想不起來是哪次歸檔幹的。

框架不會幫你檢查它寫下的東西

兩把刀治的是「太多」。還有一個治理缺口長在另一個方向——內容。這是我用了幾個月才發現的，剛好也落在「內建功能的邊界之外」，值得單獨講。

dreaming 的最後一步是晉升：把白天素材裡「值得長期記住的」寫進 MEMORY.md。這個晉升器在框架核心裡，我改不了它。問題是：它只判斷「這件事重不重要」，不判斷「這件事能不能寫下來」。

某次我翻 MEMORY.md，看到一條晉升進來的記憶長這樣：

- **設定調整**：把 XXX_TOKEN=ghp_xxxxxxxxxxxx 換掉之後就正常了

那是我白天跟它討論除錯時順口貼的憑證。它很盡責地判斷「這是解決問題的關鍵資訊，應該記住」——**完全正確的判斷，完全錯誤的結果。**而 MEMORY.md 是進版控、跨機同步、每次啟動都被讀進 context 的檔案：等於那串 token 被抄進了三個地方。

改不了晉升器，就在它後面加一層。一支清洗腳本每天在晉升完成後掃一次，移除三種東西：機密樣式（KEY=值、Bearer …、長串 hex/base64）、空碎片（晉升時被截斷的半條目）、逐字重複（內建去重是行級比對，換個標點就當成新記憶）。

還有一條鐵則是踩過才知道的：清洗時必須保留晉升器留下的標記註解。我第一版連標記一起清掉，晉升器認不出「這條已經處理過」，隔天又晉升了一次同樣的內容——把去重腳本寫成了複製機。

通則：用別人的框架，最容易受傷的地方不是它做錯了什麼，是它沒說它不做什麼。晉升器的職責是「挑重要的」，它從沒承諾過「順便過濾機密」——是我預設它會。預設別人幫你想到，是自架系統最貴的習慣（Day 26 還會再犯一次，那次更難看）。

長 context 時代，還需要記憶治理嗎？

寫這篇的時候，一定會有人想問：2026 年的模型 context window 已經從十萬 token 級走向百萬 token 級，把所有記憶整包塞進去不就好了，還需要瘦身嗎？

我的答案是：短期記憶的問題確實被大 context 解掉了一大半，但長期記憶的治理一點都沒有變少。

先講被解掉的部分：以前一個 session 聊久了會「忘記開頭」，現在百萬 token 的視窗下，單次對話幾乎不可能塞爆——「這一場對話內的失憶」已經接近死語。

但有三件事，context 再大也不會自動解決：

一、跨 session 的長期脈絡。context window 只管「這一次」，上週為什麼做那個決策、上個月改了哪條規則，模型關掉視窗就忘了——這些還是得外化成檔案，還是得治理。

二、成本。context 塞得越滿，每次呼叫的 token 費用越高；對一個每天被喚醒幾十次的排程系統，「塞得下」和「塞得起」是兩回事。就算單價降了，乘上喚醒次數之後，肥大的記憶檔仍然是帳單的放大器。

三、訊號密度。這就是前面講的「重點稀釋」——就算塞得下也塞得起，一份塞滿三個月瑣事的記憶，模型抓錯重點的機率依然上升。大 context 給了你堆積的能力，不代表堆積是好策略。

所以我的結論是：大 context 讓記憶治理從「不做就跑不動」變成「不做只是又貴又笨」——門檻降了，價值沒降。

設計哲學：記憶要「精煉」，不是「堆積」

這一篇的核心其實是一個觀念：好的記憶系統，不是記得越多越好。

人腦會主動遺忘——這不是缺陷，是特性。記得每一個細節的人反而無法正常生活。Agent 的記憶也一樣：價值在於留下該留的、收起不常用的，讓現役記憶保持精煉。

dreaming 負責「寫進來並提煉」，archiver 負責「把舊的收起來」，兩者一進一收，記憶系統才能長期健康地運作，而不是三個月就胖到走不動。

小結

記憶系統會膨脹，治理它跟設計它一樣重要：

• 症狀：檔案變大 → context 成本上升 + 重點被稀釋（變慢又變笨）
• 警戒值：單檔 30KB 黃 / 50KB 紅；dreaming 檔數破百觸發搬移
• 兩種肥胖兩把刀：單檔變胖 → 切內容（報縮減比例）；檔數爆炸 → 搬整檔（保留 30 天）
• 共通紀律：動記憶的自動化一律先能 dry-run——記憶檔沒有回收桶
• 內容缺口：晉升器不過濾機密——晉升後再掃一次是你的責任（清洗要保留晉升標記，否則變複製機）
• 大 context 時代：解掉的是單場對話的失憶；跨 session 脈絡、成本、訊號密度仍需外化治理
• 哲學：記憶要精煉不是堆積，主動遺忘是特性不是缺陷

明天換個維度：到目前為止講的都是「單一系統的記憶」。但我其實有兩個 AI——桌面端和 NAS 端，它們怎麼共用一顆腦？

🔑 這篇的關鍵字
記憶治理的兩種肥胖：單檔膨脹（切內容、按月分割）vs 檔數爆炸（搬整檔、保留 N 天）· 可量測閾值（黃燈/紅燈）而非「感覺有點大」· dry-run（不可逆操作的基本紀律）· 歸檔報縮減比例而非只報成功 · 記憶晉升（promotion）機制 · 晉升器不會幫你過濾機密——清洗三樣（機密樣式／空碎片／逐字重複）＋鐵則：保留晉升標記· 長 context 的討論：塞得下 ≠ 塞得起 ≠ 訊號密度夠

我是一名金融業資訊工程師，這是我半年來在家自架 AI Agent 系統的實錄。