作者 @wquguru 認為真正難的記憶，是記住結論的「來源」。這是他整套架構裡最有工程分量、也最容易被「向量庫存對話」這種簡化敘事掩蓋的一層。
作者的論點：記住結論不夠，得記住憑什麼
他指出 agent 太容易把一次總結當事實、把一次猜測當經驗、把一次臨時 workaround 當長期規則。記憶一旦長期化，錯誤也跟著長期化——而且是那種越久越難發現、越自信越難糾正的錯誤。
由此他主張一份合格的 bug memory 不該只寫「已修復」，而該像一份微型 postmortem：問題是什麼、證據在哪、影響了什麼、怎麼修的、怎麼驗證的、還有什麼沒解決。原文舉的例子很具體：某個資金費率欄位實際來自 fundingInfo 而非 premiumIndex response，導致 4 小時 symbol APR 低估 2 倍、1 小時低估 8 倍；修了之後仍標註「last-settled 與 predicted funding 語義仍不一致」這個未解問題。相比普通筆記，這更像可審計的工程記憶。
更進一步，他從交易 agent 的例子引出「治理記憶（governance memory）」這個類別：一個長跑 agent 必須在記憶裡寫清楚權限邊界、風險紅線、環境拓撲、部署流程、驗證閘門、當前運行狀態，以及上一次決策為什麼成立。他舉的紅線包括 demo 與真實帳戶的邊界、費用符號、結算不變量、deploy 拓撲、以及「只允許本地 commit、不允許 push」這類授權限制。理由是：一個 code 能力再強的 agent，若不知道「哪些改動涉及資金結算必須升級確認」，就會在錯誤邊界上行動；一個自治 loop 若不知道「只能 commit 不能 push」，就可能把技術正確、流程錯誤的改動推上遠端。
他下的第四條設計原則很尖銳：Agent memory 同時也是治理系統——它要管理來源、置信度、過期性、權限與可刪除性。這類記憶不能只靠向量召回，它需要清晰結構、顯式狀態與可人工審計的來源。
客觀檢視：哪些是洞察，哪些是主張
「治理記憶」是這篇文章相當有價值的觀察：把權限、紅線、狀態當成一等公民的記憶內容，而非散落在程式碼或人腦裡，確實能降低長跑 agent 在高風險邊界上犯錯的機率。這與安全工程裡「把約束顯式化、可審計化」的通則一致。
需要持平標示的是：「memory 同時是治理系統」目前仍主要是設計原則層面的主張，而非已被廣泛驗證的成熟工程範式。如何在實作上強制 agent 遵守記憶裡的紅線（而不是「讀到了但忽略」）、如何標記與更新置信度與過期性、如何讓「可刪除性」真正可逆——這些都還是開放問題。把治理寫進記憶是必要條件，但不是充分條件；真正的執行還需要 harness 層的硬性閘門（例如工具權限白名單、需人工確認的動作清單），而不只是寄望模型自覺。這層「文字紅線 vs 系統性強制」的落差，作者文中著墨較少，是讀者該自己補上的一塊。
延伸
- recall 之上是 self-evolution：把成功路徑沉澱成技能 → 反思與技能沉澱：記憶的複利
- 記憶長期化帶來的新風險（含過期、投毒）→ 客觀檢視：作者主張 vs 業界共識
- 全景與閱讀路徑 → AI memory 專欄首頁