代理記憶

AI 擅長閱讀程式碼與對話,但工作階段一結束,就會忘記「在這個工作台上自己能做什麼」。 於是已經成功過一次的事(部署·建置·連接 DB),在下一個工作階段又會被誤判成「沒有憑證,做不到」。

代理記憶讓 AI 把已驗證的事實存入精確比對抽屜,並在下一個工作階段自動取出使用。它不與 RAG(語意近似搜尋)競爭,而是分擔職責 — 事實判斷交給抽屜,近似探索交給圖書館。

為什麼需要 — 從真實事故說起

Blyck 的部署原本就能在這台 PC 上直接執行(aws CLI 已設定、有直接部署的紀錄),程序也已寫成文件。然而代理每個工作階段都反覆誤判成「沒有憑證,無法部署」。原因是它只看了程式碼註解,就推論出「額外步驟 = 我做不到」。

診斷後發現薄弱環節不是回想,而是儲存。

階段	狀態	依據
回想(recall)	正常	只要有存下來,一定會被讀到
儲存(capture)	失敗	「這台 PC 可部署」從未被永久儲存過

也就是說,並非記不住,而是根本沒有建立要記住的項目。 行動(一次 s3 cp)看似揮發性,但它所證明的能力(「可部署」)卻是永久·可再利用的事實。沒能做出這個區分,正是盲點所在。

核心原則

記憶不丟進 RAG 湯裡。 事實/能力記憶不靠語意近似搜尋,而是以精確比對取出。
儲存不依賴自覺。 成功的行動會自動晉升為能力候選(但有核准閘門)。
回想自動注入。 相關記憶不需呼叫即進入脈絡。
斷言做不到之前先驗證。 說「做不到」之前先查記憶 + 用便宜的探針確認。

比喻 — 圖書館與書桌抽屜

📚 圖書館搜尋(RAG):把程式碼·對話·記錄全堆起來,「找相似的」。量大且為近似,會混進垃圾。→ 用於「之前那段相似的程式碼在哪?」。
🗂️ 書桌上的便條抽屜(記憶):只把幾條已驗證的核心事實整齊放好。精確且隨時可見。→ 用於「這台 PC 可部署」、「別動 PROD DB」。

RAG 與記憶不是競爭而是分工。事實判斷交給抽屜(第一順位),近似探索交給圖書館(輔助)。

型別化精確抽屜

記憶以型別化記錄存入 workspace.sqlite 的專用資料表。

欄位	說明
`type`	`capability` · `decision` · `rule` · `procedure` · `fact`
`scope`	`workspace`(預設) · `global`
`key`	精確比對識別碼(例:`deploy:blyck`)
`body`	給人閱讀的事實本文
`confidence`	0~1(已驗證=1.0)
`proof`	依據(例:「aws sts 通過;s3 cp 成功」)
`status`	`active` · `stale` · `retired`

儲存(capture)— 用三重機制補強薄弱環節

方式	觸發	垃圾阻斷
明確	`memory_write(key, body, type, scope)` MCP 工具	僅限刻意呼叫
自動晉升	從活動記錄偵測成功事件(部署·建置·認證·連接 DB)→ 產生候選	核准閘門
反思回合	聊天結束/里程碑時做工作階段摘要 → 萃取「學到的永久事實?」候選	核准閘門

三條路徑都只在核准後才進入抽屜,因此沒有 RAG 式自動吸入的雜訊。

自動晉升分類器會升為能力候選的成功事件範例:

外部認證/部署成功(aws … 成功、gh auth、deploy/publish)→ capability
建置/打包成功(npm run dist、測試通過)→ capability/procedure
DB/SSH 連接成功(憑證已驗證)→ capability
使用者以命令式給出的規則(「別動 PROD」)→ rule
太瑣碎或一次性(單純讀檔等)則排除 — 避免核准疲勞

回想(recall)— 自動注入

每個回合組裝脈絡時,都會插入記憶回收階段。

以目前查詢·使用中面板·專案做 key 精確比對 + 輕量語意比對。
把前 k 個 active 記憶自動注入系統提示(不需另行呼叫)。
recency·importance 加權 + decay → 久未使用的記憶 stale→retired。

AI 工具(MCP)

工具	權限	職責
`memory_write(key, body, type, scope)`	確認	把事實明確存入抽屜(相同 key 覆寫)
`memory_read(key?/query?)`	讀取(自動)	以 key 精確比對或輕量語意比對查詢記憶

大多數回想都由自動注入處理,因此不需要逐一呼叫 memory_read。它用於補查自動注入遺漏的項目。

decay 與整理

為避免抽屜膨脹,會依 last_seen 整理久未使用的記憶。

capability · rule · procedure 免於自動消滅 — 目的就是防止上述§事故再犯。一旦驗證過的能力,即使不用也不會消失。
僅 decision · fact 在 90 天→stale、180 天→retired。
明確查詢時 stale→active 復活。

完整流程 — 今天的案例

[保存] 首次部署成功 → 活動日誌 "s3 cp blyck-releases 成功"
   → 晉升分類器偵測到 → 候選 {capability, key:"deploy:blyck",
      body:"本 PC 可直接部署:npm run dist → s3 cp → cloudfront invalidate",
      proof:"aws sts 通過;s3 cp 成功"} → [核准] → 釘入抽屜

[召回] 下一個工作階段 "部署" → 脈絡組裝自動注入 "deploy:blyck"
   → "無憑證" 的推斷本身不可能 → 事故零復發

與 Claude 檔案記憶的關係

本功能沿用 Claude Code 檔案記憶(MEMORY.md + *.md,每個工作階段自動載入)的精確·自動回想,並補強其弱點。

項目	Claude 檔案記憶	Blyck 落地抽屜
儲存位置	Markdown 檔案	workspace.sqlite 資料表
儲存觸發	代理判斷(手動)	手動 + 行動自動晉升 + 反思回合
自動儲存	✗	✓(成功事件晉升)
垃圾	少	近乎 0(UNIQUE key + 核准)
防重複	由人管理索引	`UNIQUE(scope, key)` 自動
decay/整理	手動	依 `last_seen` 做 stale/retire
領域認知	通用	專為 Blyck 活動(部署·DB·SSH)特化

決定性差異在於自動儲存。 上述事故是在 Claude 檔案記憶開啟的狀態下發生的 — 回想完好,薄弱環節在於「儲存依賴判斷」這一點。Blyck 因為有活動記錄這份行動紀錄,可以把成功事件自動晉升為能力候選,而這正是單靠檔案記憶在結構上做不到的部分。

安全性

跨聊天記憶預設為 scope=workspace + 敏感資訊過濾器,與全域工作階段不轉移·唯讀的原則並不衝突。
機密不存入記憶本文(OS 加密儲存區 + 自動遮罩走另一條路徑)。

FAQ

Q. 既然有 RAG,為什麼還需要記憶? → RAG 是語意近似,事實判斷會混進垃圾。「這台 PC 可部署」這種已驗證的事實,必須從精確比對抽屜 1:1 取出才安全。兩者分工。

Q. 我需要逐一說「記住」嗎? → 不用。雖然也能用 memory_write 明確儲存,但成功事件會浮現為自動晉升候選,只要核准即可。聊天結束時的反思回合也會自動萃取規則。

Q. 存錯的記憶會不會一直跟著我? → 相同 key 會被覆寫,decision/fact 則由 decay 整理。錯誤的能力記憶,可用 memory_write 更新或讓它 retire。

Q. 已驗證的能力若因不用而消失,不會又出事嗎? → 正因如此,capability·rule·procedure 免於自動消滅。一旦驗證過的能力,即使不用也會留在抽屜裡。