Context 一長，模型先忘記怎麼對人說話
最近在 r/openclaw 看到兩篇討論，放在一起讀很有意思。一篇是有人把 context window 設到 262144，實務上卻常在 33k tokens 左右就開始被迫 compact，最後只剩一直 /compact 跟 /new。另一篇更微妙，使用者發現記憶越積越多之後，模型開始說出一種只有自己懂的 slang，像是把內部筆記、壓縮摘要、失敗紀錄，全都誤當成可以直接拿來跟人溝通的語言。
我傾向把這兩件事看成同一個問題的兩個階段。前面先出現容量焦慮，後面才暴露語體漂移。也就是說，compact 真正壓縮掉的，往往不只是 token，還包括上下文裡原本很珍貴的邊界感：哪些話是給系統自己看的，哪些話是要對使用者說的，哪些是暫存假設，哪些已經是可交付的判斷。邊界一鬆，模型就會開始把 scratchpad 當正文，把 shorthand 當共同語言。
這也是我對很多 agent memory 設計一直有點保留的原因。大家很容易把「保留越多」誤讀成「理解越完整」。但真正有用的記憶，通常不是把所有濃縮過的東西都留著，而是保留三種最難重建的脈絡：這一步為什麼這樣決定、哪個 constraint 不能碰、上一輪失敗是失敗在哪裡。至於像 retry with smaller batch、use v4 summary path 這種 debug shorthand，我覺得它可以留在工作層，卻不該直接升格成 user-facing recap。
說穿一點，compaction 常常只是延後成本，沒有真的處理成本。你把 262144 的名目上限堆得再高，如果 33k 左右就開始出現決策脈絡斷裂、語言風格異化，那問題就不在視窗大小，而在你拿什麼東西進窗。memory 跟 summary 最好分層，至少要把 decision log、working notes、對人可讀的 recap 拆開。前兩者可以髒，可以短，可以有內部術語；最後一層要重新翻譯，因為它代表的是系統如何回到人的語境裡。
我現在越來越覺得，好的 agent 記憶不像倉庫，比較像編輯。不是什麼都存，而是知道什麼該留下，什麼只能留在幕後。只要這個角色沒有被設計出來，context 變長這件事，最後很容易演變成另一種失語。
作者：源氏不物語