長執行 Agent
Session 不等於 Context Window
兩個最容易混淆的概念：Claude 當前能看到的，和所有發生過的事。它們必須分離。
兩個容易混淆的概念
臨時 / 有限
Context Window
Claude 當前能看到的 Token。就像人的工作記憶：容量有限，過了就忘。每次對話開始時構建，用完就丟。
當前推理所需的精選內容
永久 / 可回溯
Session
所有發生過的事件的持久日誌。就像完整的錄影：從頭到尾什麼都記著，永遠可以倒回去看。Append-only，只增不減。
所有原始事件的完整記錄
為什麼必須分離
上下文管理的不可逆性
- 1 Compaction（壓縮）和 Trimming（裁剪）都是不可逆操作，一旦壓縮，原始細節就丟了
- 2 壓縮時很難知道未來哪些 Token 重要，今天看似無關的資訊，可能是明天關鍵決策的依據
- 3 如果壓縮後原始資訊丟了，就永遠回不來了，這是資訊理論的基本約束
所以正確的做法是：原始事件永久儲存在 Session 裡，Context Window 只是從 Session 中臨時取景的一個視角。丟了 Context 沒關係，因為 Session 還在，隨時可以重建。
Session 作為持久上下文物件
getEvents() 介面
Session 提供一個類似資料庫的查詢介面：Brain 可以按需讀取任意範圍的事件，擺脫固定上下文視窗的限制。
// Brain 可以靈活查詢 Session
const recentEvents = session.getEvents({
from: position - 100, // 從某個位置開始讀
to: position // 讀到當前位置
});
// 可以倒回到某個時間點
const beforeDecision = session.getEvents({
from: decisionPoint - 20,
to: decisionPoint + 5
});
// 可以過濾特定型別的事件
const toolCalls = session.getEvents({
filter: "tool_use"
});
這就像 REPL 中的物件一樣，LLM 可以寫程式碼來查詢和過濾 Session 中的事件。Brain 從任意位置開始讀、倒回到某個時間點、重讀某個決策前後的上下文。
Harness 的靈活性
從 Session 取出的事件可以做任意變換
- 優化 Prompt Cache 命中率：保持前綴穩定，減少重複計算的 Token 開銷
- 做上下文工程：根據當前任務類型，選擇性地放入最相關的歷史事件
- Harness 是可換的：不同模型可能需要不同的上下文策略，換 Harness 不影響 Session
核心對比
| 維度 | Context Window | Session |
|---|---|---|
| 持久性 | 臨時，用完即丟 | 永久，持久化儲存 |
| 內容 | 精選後的 Token | 所有原始事件 |
| 操作 | 只讀（對 Claude 來說） | 可追加（append-only） |
| 大小 | 有限（模型上限） | 無限制 |
| 用途 | 當前推理 | 歷史回溯、狀態恢復 |
硬體類比
記憶體 (RAM)
Context Window
速度快、容量小、斷電即失。CPU 正在用的資料必須在記憶體裡，但記憶體不是用來長期儲存的。
硬碟 (Disk)
Session
速度慢、容量大、斷電不失。所有資料最終都存在硬碟上，需要時再載入到記憶體。
你不會把所有檔案同時載入到記憶體裡，那樣記憶體會爆。同樣的道理，你不應該把所有歷史事件都塞進 Context Window，那樣 Token 會爆。正確的做法是按需載入：Session 存全量，Context 取子集。
Session 是 Agent 的硬碟，Context Window 是記憶體，不要把記憶體當硬碟用。把所有原始事件存進 Session，讓 Harness 按需組裝 Context。這樣即使上下文壓縮了、模型換了，歷史永遠不會丟。