當系統急著幫你「濃縮重點」，往往也把真正重要的脈絡一起刪掉
摘要很有用，但摘要不能取代記憶本身。 對 Agent 來說，真正重要的不只是結論，而是結論背後的理由、限制、例外與討論過程。
因為它很符合工程直覺：內容太多、token 太貴、上下文太小，所以先把長對話濃縮成幾句重點，之後再拿來用。這種做法在很多情境下確實有效，尤其是做會議紀要、文章摘要或短期回顧時。
但當我們要做的是 Agent 的長期記憶，問題就變了。長期記憶不是單純為了壓縮，而是為了讓未來的系統還能做對判斷。
很多關鍵決策並不是一句話就能說完。真正有價值的，通常是為什麼選 A、不選 B，曾經試過什麼、失敗在哪裡，以及哪些前提成立時這個決策才有效。
摘要傾向留下主幹，卻刪掉例外。但系統設計裡，往往正是這些例外決定成敗。像是「平常用 PostgreSQL，但這個高寫入事件流場景例外」，如果例外被刪掉，Agent 之後就容易做出錯誤的一刀切建議。
原始對話中，某些內容是猜測、某些是確認、某些只是暫時提案。摘要常常把這些不同強度都壓成一句陳述句，造成不必要的過度確定。
原始對話可能是：
「我們先不要上 event sourcing。不是它不好，而是現在團隊裡沒有人維護過，交接風險太高。等後面訂單模組穩定、監控補齊，再重新評估。」
但摘要後常常會變成：
「團隊決定不用 event sourcing。」
這句話雖然看似正確，卻少了三個極重要資訊：
這就是摘要式記憶最危險的地方：它留下結論，卻把可逆決策變成不可逆原則。
因為 Agent 不只是要「回憶」，它還要「行動」。一段失真的摘要，可能直接影響後面的判斷、建議、規劃甚至程式生成。
不是。真正成熟的做法不是反對摘要，而是把摘要放在正確的位置。
也就是說，摘要可以幫助 Agent 找路，但不能取代它真正要回去看的原始記憶。
MemPalace 比較接近這個思路：先盡量保存原始內容，再用結構化方式讓 Agent 能找到該看的地方。這樣做不是完全不要摘要，而是把摘要從「唯一事實來源」降級成「檢索輔助工具」。