
ACM 論文的 context 管理元件,對到我自己的 agent 記憶系統
七月底 CMU 放出一篇叫 ACM(Agentic Context Management)的論文,講的是怎麼讓 agent 自己管理 context。我維護一套 agent 記憶系統已經幾個月,看到題目的第一反應是想知道學術界處理同一個問題的做法跟我摸索出來的差多少。 對照下來的結果比我預期有意思:元件幾乎一一對得上,但兩邊解的其實是不同軸向的問題,而且論文裡有一組數據,反過來替我當初一個靠直覺做的設計決定提供了證據。 論文在做什麼 論文是 arXiv 2607.23809,程式碼在 lixiaochuan2020/agentic-context-management,MIT 授權。網路上不少轉述寫成「CMU 與 Meta 開源」,但論文首頁腳註寫得很明白:Meta 只擔任顧問角色,沒有實驗、資料收集或處理是在 Meta 的機器上跑的。這是 CMU 的工作。 ACM 的做法是給 agent 兩個工具,然後不設外部監控器: manage_context:agent 自己在推理途中決定要壓縮,由 summarizer LLM 產出摘要放回 context,被壓掉的原始訊息全部存到外部 workspace,每份摘要配一個 ID。 query_memory:帶著 summary ID 加一句自然語言問題,由 querier LLM 到存起來的原文裡撈回細節。 論文一直強調「lossless」,準確的意思是原文不刪、可回查。壓縮這個動作本身仍然有損,回查也要靠另一顆 LLM 去檢索,這條路徑會不會漏,論文沒有量測。 比工具設計更關鍵的是後訓練。他們用 Qwen3.5-9B 當學生、Qwen3.5-397B-A17B 當老師,讓學生同時跑「有工具」和「沒工具」兩種軌跡,再由老師雙向標註:對前者刪掉太早壓縮的呼叫、改成實際動作;對後者插入該壓卻沒壓的點。所以模型學的是「何時該壓」跟「何時不該壓」兩件事。 元件對照 我這套系統的骨架放在 openclaw-workspace-template,下面提到的檔案路徑都能在那個 repo 裡找到。 ACM 元件 我這邊的對應物 實作 manage_context 壓縮 curate-memory skill + journal rotation LLM 判斷內容該進 journal、notes/ 還是 MEMORY.md 索引;scripts/memory-archive.py --mode rotate-journal 把超過 5 天的日誌搬進 memory/archive-YYYY-MM/ 摘要落盤、原文不刪 同一組 rotation 原始日誌整份保留在 archive 目錄,--mode archive-timeline 另外把 MEMORY.md 裡過期的月份區塊搬到 timeline-archive.md 摘要 ID ↔ 原文映射 MEMORY.md 索引行 每條長期記憶就一行,附著指回 notes/ 或 memory/ 的檔案路徑 query_memory 回查 scripts/memory-search-hybrid.py BM25 加 jieba 分詞,再套時間衰減與 hall type 加權;輸出每一筆都附 verify: Read <path> 讓 agent 自己回原文核對 壓縮時機由誰決定 hook 與 cron templates/.claude/hooks/memory-search-trigger.py 掛 UserPromptSubmit;歸檔走 launchd 排程 後訓練 沒有 全部靠 prompt 加 hook 前四列基本上是同一件事的兩種寫法。後兩列是分歧點,也是這篇文章真正想講的。 ...