Agent 跑長任務，上下文佔到窗口八成，壓縮觸發，從最早的內容開始扔。十分鐘後它又去讀了一個剛讀過的檔案，重復問了一個剛回答過的問題。
這條閾值只知道你快裝不下了，完全不知道你能安全丟什麼。
這是長程 Agent 設計手記系列的第三篇，起因是我們精讀了 BEACON（浙江大學，arXiv:2605.06078）。第一篇講防止打轉，第二篇講里程碑設計。
先說我們自己的實現
Orkas 是個多 Agent 桌面客戶端，長任務是這裡的常態，壓縮天天遇到。我們的實現就是按 token 閾值觸發，上下文佔到窗口八成左右開始壓。寫這篇之前，我們沒覺得這裡有什麼問題。
業界常見的邊界大概三種：按窗口佔比、按對話輪次、讓模型寫一段摘要蓋掉舊內容。我們屬於第一種。
前兩種壓根不看內容。第三種看了，但把「什麼該留」整個交給了模型。
三種都在回答什麼時候必須扔東西。可我們真正要問的是哪些東西可以不要了。到點就砍，砍掉的是最早的內容，不是最不重要的內容。
里程碑邊界，以及它底下壓著的那條假設
上一篇講的里程碑，本來能給出一個比這三種都好的邊界。但這裡有個坑，上一篇講得太順了。
BEACON 里有條假設叫里程碑馬爾可夫性。翻譯成人話：到了某個里程碑之後，後面怎麼走只看還剩哪些子目標，跟你之前怎麼摸到這兒的沒關係。拿到鑰匙以後，要緊的是拿它開哪扇門，你怎麼找到它的不重要了。
聽起來正好能拿來壓縮：過了里程碑，前面那段過程就能折疊掉。
但它是假設，不是事實。論文原話是「約等於」，作者還專門討論過它什麼時候不成立。
訓練里夠用，拿到壓縮里就不夠了
同一條假設，兩種用法，嚴格程度差著一個量級。
訓練的時候，它只要統計上成立就行。幾千次嘗試里有幾十次不符合，偏差會被平均掉。訓練里還壓著一層軌跡級信號兜底，把那層去掉，ALFWorld 的成績從 91.4 掉到 23.4，比什麼都不做還差一大截。
壓縮不一樣，它得逐點成立，對眼前這一次運行成立。丟錯一回，這個任務就廢了，沒有幾千次可以平均。
所以論文用了這條假設，不代表你能把它搬到壓縮上。兩邊對它的要求根本不在一個檔次。
四種情況下它不成立
想壓縮策略的時候，我們拿這四條當檢查表。
1. 前面積累下來的隱性認知。某一步試出來「這個介面返回的時間戳是 UTC」。這條認知不屬於任何里程碑，可後面每一步都得用。
2. 已經燒掉的資源。token 預算、呼叫配額、剩餘時間。里程碑不記我已經花掉六成，可這個數決定了後面還敢不敢重試。
3. 路徑留下的痕跡。里程碑上寫著重構完成。但一旦開始調試，你得知道具體動了哪五個檔案。
4. 里程碑本身就說不清楚。這條最麻煩。論文里的里程碑是環境給的完整狀態，拿到鑰匙就是拿到鑰匙，一點歧義都沒有。而計劃里的一步只是一句自然語言，「完成資料清洗」這六個字，根本兜不住那一段裡到底發生了什麼。
那該帶什麼過去
別只留一段摘要。摘要是模型寫的，它憑感覺決定什麼重要。
要留一組固定的字段，由人定死。至少四類：
- 工作區現在什麼樣：哪些檔案動過，動成了什麼樣。
- 還剩多少額度：token、呼叫次數、時間。
- 前面已經搞清楚的事：那條 UTC，以及所有會影響後面決策的同類結論。
- 還沒搞清楚的事：卡過一次、繞開了、但可能還會撞上的。
跟上面那四種失效情形對著看，正好一一對上。這個對應關係，是判斷一套壓縮策略夠不夠用的最簡單方法。
其中一半幾乎是白撿的。上一篇說過，宿主側在每次工具呼叫結束時都會記一批確定性事實：檔案有沒有真被改寫、命令跑沒跑成。那批資料本來是為了驗證里程碑做的，但它就是工作區快照，壓縮時直接帶過去就行，不用再讓模型總結一遍。
難的是另外兩類。已經搞清楚的和還沒搞清楚的，眼下只有模型自己寫下來才存在，這也正是它們在壓縮里最先陣亡的原因。
這事不用爭，能測
壓縮之後，如果 Agent 又去讀了已經被壓掉的檔案，或者重復問了前面回答過的問題，那就是這條假設在這個任務上失效了，證據擺在那兒。
埋點也簡單：把壓縮點之後讀過的檔案路徑，跟壓縮點之前的記錄求個交集。
有了這個數，「哪類任務能激進壓縮、哪類不能」就是查資料的事，不再是設計階段的互相說服。這跟系列第一篇是同一個路子：先量，再改。
哪些地方得打折
這套東西還沒上線，目前只到設計和埋點。
具體保留哪些字段、粒度多細，得看真實資料里哪類資訊最常被重新撈回來。現在拍板容易拍錯。
而且這只是一種做法。換個產品形態，邊界畫在哪、字段怎麼定，答案可能完全不一樣。那四條檢查表能帶走，具體答案不能。
系列的最後一篇聊自我反思：為什麼 Agent 總結出來的經驗，永遠是「要更仔細」這種廢話，以及關於它的輸入裡有什麼、沒有什麼的一個挺意外的發現。