把 agent 的記憶全丟同一桶，越界是遲早的事
先講結論好了。
最近看到 r/openclaw 有個 Tri-Node Memory 的討論串，作者把 agent 的記憶拆成三層：Human Vault 放自己的筆記跟專案文件，agent 只能讀；Agent Journal 是 agent 自己的記錄，它才能寫；中間還有一個 inference layer 負責串接兩邊。
然後他下了一條 rule：「agent reads your stuff, writes to its own, unless explicitly asked」
看到這句話的時候我想說，這才是對的問題意識。
大部分人在想 memory 問題的時候，腦子跑的是「agent 記不住怎麼辦」「context window 不夠怎麼辦」「跨 session 的記憶怎麼保留」。這些問題確實存在，但它們幾乎從來都不是第一個炸的東西。
第一個炸的，幾乎都是邊界。
你想想看，agent 可以讀你的筆記、可以讀你的 project file、也可以讀它自己的 journal，這些東西全放同一個地方的時候會怎樣？
Agent 在生成回應的時候，它拿到的 context 會包含你的個人備忘錄、你寫給自己的 decision log、你說「這件事先別跟 X 說」的那條筆記。然後它根據這些東西做決定，給你一個看起來「很合理、很貼近你的狀況」的答案。
看起來合理的答案。
但你沒有授權它用那些東西。你以為它是在做 recall，其實它是在越界。
這個問題難搞的地方在於，它跟記憶體崩潰那種錯誤完全不同，不會直接報錯。越界的 agent 給你的回應很流暢、很貼心、甚至比你預期的還「懂你」，但懂得方式是因為它讀了你沒想讓它讀的東西。
Tri-Node Memory 那個設計把這塊切得很乾淨。
Human Vault 和 Agent Journal 是兩個分開的 vault，讀寫邊界在架構層就隔開了，agent 沒有辦法「順便」把自己的觀察寫進你的 vault。你的筆記對它來說是唯讀的。它想記什麼、想學什麼，只能寫自己那桶。
作者說這個設計是 harness-agnostic、model-agnostic，意思是你用哪個框架都可以套，換模型也不會讓這個邊界消失。這個才叫 trust boundary。
Reddit 討論區有人說，vault split 比單一記憶池更乾淨的原因，就是「信任邊界在設計層就存在，靠 agent 自己判斷的東西靠不住」。這句話我覺得講到核心了。
靠 agent 自己判斷「我能不能讀這個東西」，跟架構上就不給它讀寫某個 vault，是兩件完全不同的事。前者在 99% 的時候 agent 會做出合理的選擇，但那 1% 你沒預期到的 case 才是真正的風險所在。而且你永遠不知道那 1% 什麼時候出現。
我自己之前跑 agent 的時候沒意識到這件事，記憶完全是一個混在一起的 pool，agent 的 journal、我的 project notes、甚至一些隨手寫下的個人想法，全部在同一個 git repo 下面，agent 能讀到所有東西。
回頭看那段時間的輸出，很多「很貼近我需求」的回應，現在我沒辦法確定是因為它真的推理到了，還是因為它讀了某個我沒有明確授權它讀的東西。
這個「不確定」本身就是問題。
所以說，memory 問題的解法，先不要急著去想 embedding、向量資料庫、怎麼做 retrieval。先想清楚：你的 Human Vault 跟 Agent Journal 有沒有分開放？邊界是在架構層就切好的，還是只靠 prompt 裡面說「你不要碰我的個人文件」。
靠 prompt 說的邊界，不是邊界。
這個 Tri-Node 的設計沒有解決所有問題，但它把最容易被忽略、也最早出問題的那個東西先切乾淨了。
作者：島民No.9527