Agent在處理複雜軟體工程任務時，往往會陷入一個尷尬困境：隨著交談歷史不斷增長，計算成本爆炸式上升，響應延遲線性增加，而且模型還會被過去的無關錯誤資訊干擾，推理能力嚴重退化。這種現象被稱為「上下文膨脹」(Context Bloat)。
論文提出了一個關鍵洞察：現有解決方案大多依賴被動的外部摘要機制，agent自身無法控制何時壓縮、壓縮什麼。能否讓agent像生物體一樣，主動管理自己的「記憶」？
從黏菌覓食中獲得的靈感
論文從一種名為多頭絨泡菌(Physarum polycephalum)的黏菌身上獲得啟發。這種生物在探索環境時，會從死胡同中物理性地收縮回來，同時留下化學標記以避免重複探索。生物系統不會保留導航迷宮時每一次肌肉運動的完整記錄，它們只保留「學到的地圖」。
類似地，一個探索程式碼庫的agent不需要記住十分鐘前50行ls -R命令的輸出，它只需要記住「設定檔不在/src目錄中」這個結論。
基於這一類比，論文提出了Focus Agent架構。該架構引入兩個核心原語：start_focus和complete_focus。關鍵在於，agent對何時呼叫這些工具擁有完全自主權——沒有外部計時器或啟發式規則強制壓縮。
Focus循環的四個階段
Focus架構的工作流程包含四個階段：
(1) 啟動聚焦：agent聲明正在調查的內容（如「除錯資料庫連線」），這會在對話歷史中標記一個檢查點。
(2) 探索：agent使用標準工具（讀取、編輯、執行）執行工作。
(3) 整合：當agent自然完成子任務或遇到死胡同時，它決定呼叫complete_focus，生成摘要，包括嘗試了什麼、學到了什麼（事實、檔案路徑、bug）、結果是什麼。
(4) 撤回：系統將摘要附加到上下文頂部的持久「知識」塊中，並刪除檢查點與當前步驟之間的所有訊息。
[圖2：上下文增長的概念性鋸齒模式]
論文展示了Focus（藍色）呈現週期性壓縮（下降），而Baseline（紅色）單調增長。透過激進提示，Focus每10-15次工具呼叫壓縮一次，在保留學習成果到持久知識塊的同時防止上下文膨脹。
這種設計將上下文從單調遞增的日誌轉變為「鋸齒」模式——探索期間增長，整合期間收縮。模型根據任務結構控制這個循環，而非任意的步數計數。
實驗設置與優化腳手架
論文在SWE-bench Lite基準上評估Focus架構，這是一個用於軟體工程agent解決真實GitHub問題的基準。論文使用claude-haiku-4-5-20251001模型，在N=5個上下文密集型實例上進行受控A/B對比實驗。
遵循Anthropic報告的SWE-bench最佳實踐，論文實現了一個最小化的雙工具腳手架：持久Bash（有狀態的shell會話，工作目錄和環境在呼叫間持久化）和字串替換編輯器（透過精確字串替換進行目標檔案編輯，避免容易出錯的全檔案重寫）。
初始實驗顯示，被動的Focus提示每個任務僅產生1-2次壓縮，token節省僅6%。論文修訂了Focus提示使其更具指導性：強制工作流要求「在任何探索之前始終呼叫start_focus...在10-15次工具呼叫後始終呼叫complete_focus」；每15次工具呼叫後無壓縮時，系統注入提醒；明確指導使用4-6個聚焦階段（探索→理解→實現→驗證）。
[表I：SWE-bench Lite上的A/B對比（Haiku 4.5，N=5困難實例）]
論文對比了Baseline和Focus在任務成功率、總token消耗、平均每任務token、平均壓縮次數和平均丟棄訊息數等指標上的表現。
核心發現：22.7%的節省與相同的準確率
實驗結果顯示，Focus實現了22.7%的總token減少（14.9M→11.5M），同時保持與Baseline相同的準確率（3/5 = 60%）。這與論文早期實驗形成對比——當時被動提示顯示準確率下降。關鍵區別在於：激進提示強制執行頻繁、結構化的壓縮（每任務6.0次 vs 之前的2.0次），防止上下文被陳舊的探索日誌污染。
[表II：每實例結果：Token節省vs準確率]
論文展示了五個實例的詳細對比，包括matplotlib-26020（-57%）、seaborn-2848（-52%）、pylint-7080（+110%）、pytest-7490（-18%）和sympy-21171（-57%）的token變化和壓縮次數。
Focus在5個實例中的4個上減少了token，節省範圍從18%到57%。最強的節省發生在需要大量探索的實例上：matplotlib-26020（-57%，4.0M→1.7M）、seaborn-2848（-52%，3.4M→1.6M）和sympy-21171（-57%，1.6M→0.7M）。
[圖1：Token消耗（Haiku 4.5，N=5困難實例）]
論文展示了5個困難實例的總token消耗對比。Focus透過激進的模型控制壓縮減少了22.7%的使用量，同時保持相同的準確率。
案例分析：最大節省與壓縮開銷
在matplotlib-26020上，兩個agent都通過了測試套件，但Focus實現了57%的token節省（4.0M→1.7M）。Focus在71次LLM呼叫中壓縮了5次，而Baseline使用了102次呼叫卻沒有壓縮。節省來自Focus高效地總結其探索階段——一旦定位到相關檔案並理解了bug，它就壓縮該上下文並直接進入實現。
然而在pylint-7080上，Focus比Baseline多使用了110%的token（4.3M vs 2.1M），儘管兩個agent都通過了測試套件。分析顯示Focus進行了136次LLM呼叫 vs Baseline的63次，8次壓縮丟棄了80條訊息。該問題需要大量試錯，Focus的壓縮偶爾丟棄了有用的上下文，迫使重新探索。這表明壓縮並非普遍有益：需要迭代細化的任務可能會因激進的上下文修剪而受損。
壓縮的認知稅與局限性
主動壓縮引入了「認知稅」——生成摘要所花費的token和管理聚焦階段的開銷。儘管有這種稅，Focus在實驗中仍實現了22.7%的淨token節省。這種稅在任務生命週期內被攤銷：每次壓縮花費幾百個token，但透過不重新處理陳舊歷史節省了數千個token。
論文指出了幾個局限性：樣本量僅N=5個困難實例，需要在完整SWE-bench Lite基準（N=300）上驗證；任務依賴性收益——Focus在探索密集型任務上顯示50-57%節省，但在一個迭代細化任務上顯示110%開銷；僅評估了Claude Haiku 4.5，其他模型的表現未知；結果依賴於優化的雙工具腳手架。
寫在最後
論文證明了激進的、模型控制的上下文壓縮可以在不犧牲任務準確率的情況下實現顯著的token節省。當前LLM似乎缺乏內在的成本意識——它們不會自然地優化token效率，需要使壓縮成為工作流一等公民的腳手架。
未來工作方向包括：在完整SWE-bench（N=300）上驗證以表徵任務類型依賴性；微調或強化學習方法以內化壓縮啟發式而無需顯式提示；結構化壓縮以保留特定工件（測試輸出、差異）而非自由文本摘要；跨模型評估（GPT-4、Gemini、開源模型）以評估泛化性。
隨著上下文視窗增長和agent任務變得更加複雜，主動壓縮對於管理自歸迴推理中固有的二次成本增長將變得越來越有價值。
論文標題：Active Context Compression: Autonomous Memory Management in LLM Agents