Agent 上下文管理四大家族：殊途同歸的工程實踐 (Context Management in Agent Harnesses)

原始來源與檔名：20260512_2026-04-28T092549+0800-Agent 框架的上下文管理：四种实现，殊途同归.md

來源：[[@verysmallwoods]] / X (Twitter) — 2026-04-28 原始檔名：2026-04-28T092549+0800-Agent 框架的上下文管理：四种实现，殊途同归.md

NAPKIN | 餐巾紙

餐巾紙公式

Agent Context Management = File Truncation (Hard limits + Offset/Limit) + Session Compaction (LLM Summarization at 80% capacity) + Out-of-Context Persistence (Large outputs pushed to disk, leaving 2KB stubs) + Sub-agent Isolation (Blank slates or strictly filtered whitelists).

當 Agent 運行時間拉長，200K 的 Context 視窗也一定會被塞爆。本文從源碼層面拆解了 Pi, OpenClaw, Claude Code, Letta 四大框架的上下文管理策略。最驚人的發現是：它們在面對「大文件讀取」、「超長會話壓縮」與「子代理隔離」這三個問題時，獨立演化出了幾乎一模一樣的解法。Agent 框架的終極使命，不是把所有東西都丟給模型，而是像作業系統的記憶體管理（分頁、Swap）一樣，主動在幕後調度狀態。

一句話

這是一篇極硬核的 Agent 框架架構級分析文。作者對比了 Pi、OpenClaw、Claude Code、Letta 四套框架的源碼，發現它們都在解決同一個物理限制：上下文不夠用。於是所有框架都收斂到相似的防禦機制：讀檔時先截斷並要求模型翻頁；工具輸出過大時卸載到磁碟只留預覽；對話過長時呼叫 LLM 進行摘要壓縮（Compaction）並確保不切斷工具呼叫邊界。最好的上下文管理，是讓 Agent 感覺記憶無限，但框架在底層精準調度。

餐巾紙草圖

[ The Universal Agent Context Playbook ]

1. File Reading:
   [>256KB?] -> Reject -> Suggest `grep` or `limit/offset`.
   [<256KB?] -> Read -> Truncate at 2000 lines -> Prompt model to fetch next page.

2. Heavy Tool Outputs (e.g., massive JSON/Grep):
   Save full output to disk -> Inject 2KB preview into context window.

3. Session Compaction (When Context > 80%):
   Keep recent 20k tokens + Drop older turns -> Feed to LLM for Summary -> Inject Summary as a "User Message".

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

核心論證鏈

  1. 無限上下文的錯覺: 就算模型支援百萬 Token，填滿它的成本與延遲也是災難性的。因此，所有生產級 Agent 都必須回到 1970 年代作業系統的設計老路：虛擬記憶體與分頁機制 (Paging & Swap)。
  2. 防禦性設計 (Defensive Design): AI 的行為是不可測的，框架必須「假設 AI 會做蠢事」（例如一口氣讀取 10MB 的 Log 檔）。因此在工具調用前 (Stat 檢查)、調用中 (字節截斷)、調用後 (Token 壓縮)，都必須設置攔截閘門。
  3. 框架的終極收斂: Pi 和 Letta 的出發點不同，Claude Code 是寫碼的，Alyx 是看數據的。但當工程師們遇到 OOM (Out of Memory) 或 API 拒絕時，他們最終寫出來的防護邏輯竟然驚人地一致。這證明了「Agent 框架」這個軟體分類的底層抽象已經成熟。

關鍵證據

邊界條件

ROUND 3: SOUL | 靈魂提取

“還能怎么用”