上下文

每個代理都在上下文視窗中工作：其中持續記錄你的對話、它讀過的檔案，以及執行過的每個工具的輸出。短任務的記錄不大。長任務則不同，例如多步驟的鑑識審查、大規模重構，或一下午的來回對話，記錄會快速增加，而多數代理就在這裡悄悄失常。

為什麼長時間執行會偏離目標

隨著視窗填滿，模型會失去對原始指示的可靠存取。它開始忘記你一開始設定的限制、依賴過時的工具輸出，並偏向次要目標。關鍵是品質早在達到硬性 token 上限之前就已下降，而不是達到時才下降。代理看起來可能正常，但它所依據的上下文已經無法維持工作的脈絡。再往前推一點，它不只是品質下降，而是讓視窗溢位，導致呼叫直接失敗。

Perch 為長時間執行而設計，因此會在每一輪主動管理上下文視窗，而不是等到填滿並出錯。

壓縮整理流程

每次呼叫模型前，Perch 都會讓工作上下文通過有先後順序的處理流程。每個階段都比下一個階段成本更低、資訊損失更少，因此只有成本低且無損的步驟還不夠時，才會執行成本高且有損的步驟。

第一階段：一律先裁減大型成品

長時間執行會因體積龐大、價值不高的資料而膨脹，例如完整瀏覽器頁面快照與操作代理的螢幕截圖。Perch 每一輪都會先裁減這些內容，甚至在檢查預算之前就執行。頁面快照會縮減為可供操作的部分，也就是模型可能操作的控制項與結構，最舊的快照則縮成簡短佔位內容。螢幕截圖會移除或壓縮到硬性 token 上限內。這純粹是在移除多餘內容，因此無條件執行。一份原始 DOM 快照或螢幕截圖的成本，可能超過數十輪實際推理，而且幾個步驟後幾乎都不再需要。

第二階段：微幅壓縮過時工具輸出，不呼叫模型

如果執行仍超出預算，Perch 會清除較舊工具結果的內文，並原樣保留最近的結果。工具呼叫與結果的配對會維持完整，只有過時的結果內文會被簡短標記取代。這對 Perch 專門處理的工作負載尤其重要：讀取數十個檔案並執行多次沙箱檢查的鑑識工作，會累積大量工具輸出，而模型很少需要二十個步驟前讀過的檔案原文，只需要當時得出的結論。這個步驟成本低，不需要額外呼叫模型，而且往往能釋出足夠空間，完全略過昂貴的摘要步驟。它會在背景中執行，因為清除過時工具內文是例行的成本節省措施，不值得為此打斷你。

第三階段：只有仍超出預算時，才摘要較舊的輪次

只有在低成本步驟執行後仍超出預算時，Perch 才會將較舊的一段對話，摘要為精簡的記錄，保留發生的事與做出的決定，並整合先前的摘要，再據此繼續工作。這是唯一成本高且有損的步驟，因此最後才執行。執行時會顯示出來：對話記錄會標示當下時間點，並說明有哪些變化。

第四階段：強制執行的最後防線

作為最後的保障，Perch 會在送出前，強制確保實際酬載大小符合模型上限，從最舊的訊息開始裁減，同時保留一定量的近期輪次。這道安全網讓溢位失敗在結構上不可能發生：即使遇到特殊情況，到達模型的要求也一律符合容量。

衡量真正的視窗大小，不靠猜測

根據字元數估算 token，會系統性地低估高密度內容：CSV、JSON、程式碼，以及長長的數字欄。財務或文件工作恰好充滿這類內容。粗略估算會讓壓縮整理太晚觸發，甚至完全不觸發，導致酬載溢位。Perch 會用同一次執行中前一次呼叫由供應商回報的實際提示詞 token 數，校準估算，並以此設定壓縮整理的觸發點。壓縮整理依據真正的上下文大小觸發，而不是依據偏偏在有害方向上出錯的猜測。

保留當前脈絡

壓縮整理絕不會動到你目前正在處理的內容。Perch 一律逐字保留對話的近期部分，其大小依據實際 token 預算，而不是固定的訊息數量；它也會維持工具呼叫與結果的配對，讓近期記錄保持連貫。舊上下文會被壓縮，當前脈絡則保持原樣。

遵守模型的實際預算

Perch 會依據真正適用於這次執行的上下文上限壓縮整理，包括較高等級解鎖的較大視窗，而不是當輪底層模型的原始視窗大小。它也會以留有餘裕的實際工作預算為目標，而不是勉強擠在上限之下，下一步又填滿，讓模型在後續輪次仍有思考空間。

看得見，不會悄悄執行

真正的壓縮整理是你看得到的。上下文計量表會顯示視窗已使用多少空間；當 Perch 執行摘要時，會在對話記錄中標示時間點，並說明變化：釋出多少空間、摘要多少內容、摘要有多大，以及保留多少近期記錄。你不必猜測代理是否仍掌握脈絡。低成本的背景步驟保持安靜，唯一有損的步驟則一律顯示。

為什麼這很重要

這是能在五步任務中漂亮示範的代理，與能讓你信任它執行長時間、高風險工作的代理之間的差別。橫跨數十次檔案讀取與沙箱檢查的鑑識審查，必須全程以原始問題為依據，也不能因視窗溢位而中途失敗。Perch 透過設計，讓長時間工作保持準確且不超出範圍，因此最後的回答依據的仍是你一開始給的指示。