@aparnadhinak：Agent Harness 中的 Context 管理 每個 Agent harness 都會遇到相同的限制：Context window 對於模型可能需…

Agent Harness 中的 Context 管理 每個 Agent harness 都會遇到相同的限制：Context window 對於模型可能需要記住的所有內容來說實在太小了。隨著對話進行，讀取的檔案變多、Sub-agent 呼叫次數增加，以及工具輸出的堆積，harness 必須決定哪些內容保留在工作集 (working set) 中、哪些需要壓縮，以及哪些留待稍後再檢索。 過去兩年我們一直在開發 Arize 的產品內 Agent「Alyx」，並遭遇過這個問題的各種版本。我們看過對話長到讓模型遺失任務目標、檔案讀取佔用了 Context window 一半的空間，以及工具執行結果擠壓了實際對話內容。 重要的問題不再只是「什麼該放進 Prompt」，而是 harness 如何隨著時間管理 Context。最優秀的系統不會把 Context window 當作被動的對話紀錄緩衝區，而是主動進行管理：將高價值狀態保持在手邊、按需求分頁讀取資料、建立索引以搜尋所需內容（grep 就是這樣做的），並以能暗示還有哪些內容可存取的方式截斷內容。 Pi、OpenClaw、Claude Code 和 Letta 在這裡做了不同的選擇，但它們正趨向於相似的底層模式。Context 不再只是「塞得進對話紀錄的東西」，而是系統必須主動管理的資源。真正的設計問題在於：這種管理有多少是在 harness 內部完成的，又有多少是預期由模型自行處理的。 賭注：信任模型能自行管理 Context 每一個 Context 管理決策都隱含了對模型行為的假設。關鍵問題在於：harness 應該主動限制 Context 的使用，還是依賴模型自行正確管理預算？ 檔案讀取讓這個問題變得具體。當模型需要讀取的檔案超過 Context 容量時，必須有人決定保留什麼。這四個 harness 都支援分頁功能的 offset 和 limit 參數。 Pi (pi-mono) Pi 讀取檔案時有 2,000 行或 50KB 的硬性上限（以先達到者為準），即使模型沒有要求分片也是如此。內容會進行頭部截斷，且工具輸出會附加一個明確的接續提示：[Showing lines 1-2000 of 50000. Use offset=2001 to continue.]。工具說明也強化了這一點：「輸出被截斷為 2000 行或 50KB。對於大檔案請使用 offset/limit。」 Pi 的方法是「harness 優先」：harness 先保護你，再教導模型如何分頁。 OpenClaw OpenClaw 繼承了 Pi 的讀取工具及其 2K 行 / 50KB 的截斷規則。在一般檔案讀取時行為相同。除此之外，它還為引導檔案（bootstrap files，即對話開始時載入的一次性 Context 檔案）增加了額外上限：每個檔案 12,000 字元，總計 60,000 字元。當引導檔案超過預算時，它會採用 75% 頭部 / 25% 尾部的分割方式：你會看到開頭和結尾，中間被切掉。 工具結果有獨立的預算：16,000 字元或 Context window 的 30%（取較小者）。當尾部看起來「很重要」（如錯誤訊息、JSON 結束括號、摘要關鍵字）時，它會切換到「頭部+尾部」模式；否則就只保留開頭。 OpenClaw 的方法是「縱深防禦」：Pi 的截斷作為第一層，然後是引導檔案注入的額外上限，最後再加上工具結果的預算。 Claude Code Claude Code 對檔案讀取應用了兩層防禦。第一道關卡是 256KB 的位元組上限，在檔案開啟前透過 stat 呼叫進行檢查——如果檔案超過此限制，讀取會立即被拒絕，並顯示錯誤訊息引導模型使用 offset/limit 或 grep。第二道關卡在讀取後執行：輸出會針對 25,000 token 的預算進行計算，藉此攔截那些位元組數雖小但 token 密度高的檔案。這兩個限制都可以由 Anthropic 透過 GrowthBook 功能旗標 (feature flags) 遠端調整，無需發布新版本。 即使檔案在上限內，工具預設也只會回傳開頭的 2,000 行，且任何超過 2,000 字元的行都會被截斷。模型必須明確使用 offset 和 limit 參數來請求更多內容。 工具說明是一段完整的多段落 Prompt，解釋了分頁機制、提到大小上限、涵蓋圖片/PDF/筆記本支援，並鼓勵跨多個檔案進行平行讀取。offset 和 limit 參數有各自的說明，告訴模型它們是用於過大的檔案。還有一個條件式指令，會根據功能旗標直接在 Prompt 中顯示 256KB 的上限。 檔案去重 (dedup) 系統也值得一提。如果模型在相同的範圍內重新讀取同一個檔案，且檔案時間沒有改變，Claude Code 會回傳一個存根 (stub) 而非完整內容，避免在 Context 中產生重複的 token。 Claude Code 的方法是「具備遠端調整能力的 harness 優先」：包含預讀位元組閘道、讀後 token 閘道、行數與行長預設值、可操作的錯誤訊息、豐富的工具 Prompt、讀取去重，以及讓 Anthropic 能在伺服器端調整所有設定的功能旗標。 Letta Letta 採取了截然不同的方法。每個上傳的檔案都會被解析、分塊並嵌入 (embedded) 到向量資料庫中，因此 Agent 同時擁有精確搜尋和語意搜尋能力。這賦予它三種檔案工具：openfiles 用於直接檢視（讀取原始文字）、grepfiles 用於精確模式匹配（也是原始文字），以及 semanticsearchfiles 用於針對嵌入片段進行基於意義的檢索。 當檔案在 Agent 的 Context 中「開啟」時，其可見內容會被截斷為每個檔案的字元限制，該限制會隨模型 Context window 的五個等級而擴展：8K Context 為 5,000 字元、32K 為 15,000、128K 為 25,000，200K+ 為 40,000。同時開啟的檔案數量也會隨之擴展，小型模型為 3 個，大型模型最多 15 個，預設為 5 個。當超過限制時，會採用 LRU (最近最少使用) 策略來移除檔案。 Letta 的方法是「記憶優先」：檔案同時存在於原始文字和向量資料庫（嵌入區塊）中，Context window 只顯示受管理的視圖，模型則使用工具來存取更多內容。 真正的工程挑戰：對話修剪 (Session pruning) 隨著對話增長，每個 harness 都必須決定保留什麼、捨棄什麼。這是設計差異最顯著的地方，因為壓縮策略決定了長期運行的 Agent 是能保持連貫性，還是會逐漸退化。 Pi (pi-mono) Pi 使用壓縮：由 LLM 驅動的摘要功能，由 token 閾值觸發。 觸發條件：預估的 Context token 超過 contextWindow - reserveTokens（預設保留：16,384 tokens）。 保留內容：從對話末端往回走，保留最近約 20,000 個 token 的訊息 (keepRecentTokens)。 摘要內容：更舊的內容會傳送給 LLM 進行摘要。 摘要存放位置：成為一則合成的使用者訊息，置於保留的尾部之前。 工具呼叫安全性：絕不會在孤立的工具結果處截斷。會遍歷邊界以確保「工具呼叫/工具結果」對保持完整。 OpenClaw OpenClaw 在 Pi 的壓縮機制之上運行了兩種不同的 Context 管理機制： 觸發條件：歷史紀錄超過 Context window 的 50% (maxHistoryShare，預設 0.5)。 保留內容：將歷史紀錄分割成等量的 token 區塊；丟棄最舊的區塊，其餘部分保留，並修復工具呼叫/結果對。 摘要內容：被丟棄的內容會經過分階段的多輪 LLM 摘要，並包含合併步驟。 摘要存放位置：與 Pi 相同——合成訊息置於保留的尾部之前。 工具呼叫安全性：repairToolUseResultPairing 可修復區塊丟棄後任何孤立的工具結果；splitMessagesByTokenShare 避免在工具呼叫/結果對內部進行切割。 壓縮前刷新：一個靜默的 Agentic 轉向 (turn) 讓 Agent 在歷史紀錄消失前將狀態持久化到記憶檔案中。 第二層：工具結果的非破壞性記憶體內修剪（軟修剪，然後硬清除），快取 TTL 為 5 分鐘，在保護持久化對話的同時為當前請求回收 Context。 Claude Code Claude Code 透過查詢前最佳化 (pre-query optimization) 和 LLM 驅動的壓縮來管理 Context。 觸發條件：預估 token 超過有效 Context window 減去 13,000 token 的緩衝區（對於 200K Context 的模型，壓縮會在約 167K token 時觸發）。 摘要內容：將完整對話傳送給模型，並附帶一個結構化的 9 節 Prompt，涵蓋主要請求、關鍵技術概念、檔案與程式碼、錯誤與修復、問題解決、所有使用者訊息、待辦任務、當前工作以及選用的下一步。 摘要存放位置：成為一則使用者訊息，告知模型該對話是從先前因 C…