100K 上下文就夠了：壓縮記憶，而不是買一個更大的視窗

視窗大小不是問題

每隔幾個月，就有實驗室推出上下文視窗更大的模型，然後討論重新洗牌：二十萬 token，然後一百萬，然後兩百萬。言下之意是，記憶是個硬體問題，總有人會把它做得更大。

billion-context 是 ranxianglei 的 TypeScript 專案，從九月下旬開始一路往上爬，它的標語站到了反面：100K 上下文就夠了。不是"目前夠用"，是夠了——前提是你別再把對話當成一份只能追加的日誌。

它是一個代理，夾在你的編碼 agent 和模型 API 之間。請求經過它，被壓縮，再轉發出去。回應在回來的路上被改寫。模型本身一點沒變。它想說的是：貴的那部分從來不是視窗大小，而是我們一直往裡塞的東西。

壓縮是怎麼做的

代理依 Anthropic 或 OpenAI 的格式解析每個請求，對整段對話跑一遍它的壓縮核心，然後注入四個模型可以自己呼叫的工具：把一段訊息壓縮成摘要，在需要確切細節時把某一段解壓縮回來，依關鍵字搜尋壓縮後的摘要和可見訊息，以及查看上下文用量。

關鍵的設計選擇是：什麼時候壓縮由模型自己決定，而不是一道硬門檻。宿主內建的摘要器通常在視窗填滿時觸發，把切點之前的一切換成一個無法復原的摘要。billion-context 按小段壓縮，保持可逆，並且不破壞前綴快取。

最後這點才是值得在意的工程細節。前綴快取是長 agent 工作階段能負擔得起的原因；如果每次壓縮都改寫對話開頭，快取就失效，你得為整段歷史再付一次全價。專案聲稱健康的工作階段前綴快取命中率能維持在 95-97%，壓縮本身的開銷不超過 2%。這些是它自己給的數字，同時它提供了指令，可以把命中率下降歸因到具體原因，通常是上游快取 TTL 過期，或者換了模型。

讓這個說法可信的那個數字

廠商天天都在宣稱省 token。這裡不尋常的是隨程式碼一起發布的一份縱貫研究：四個半月，三個宿主，174,327 次模型呼叫，單一宿主累計輸入 18.76B token，所有宿主加起來約 24.7B。報告說最長的工作階段跑了 8,584 到 12,049 次呼叫，在 204,800 token 的模型上零次上下文視窗違規。

零視窗違規才是關鍵的那句話。它意味著沒有任何一個工作階段是因為對話長過模型而死掉的。研究裡其他的一切，都在這句話的下游。

它也重新定義了"長工作階段"是什麼意思。大多數人對上下文上限的體驗是緩慢的退化：agent 越來越含糊，忘掉兩小時前的一個限制條件，開始重讀已經讀過的檔案。等到視窗真的滿了，這個工作階段通常已經糟了一陣子。持續執行的壓縮處理的是退化，而不只是那個硬性中斷。

至於它在你的工作負載上是否真如宣傳所說，是另一個問題。這些說法是自報的，基準就是作者自己的使用情況，而"token 少 5 倍"完全取決於你的工作階段有多重複。一個讀了四十個檔案、改了三處的工作階段會被壓得很漂亮。一個讀了一個巨大的檔案、然後逐行推理的工作階段，可摺疊的冗餘就少得多。

它改變了日常循環裡的什麼

實際的差別出現在一個長任務無聊的中段。一個正在做重構的 agent 有三種記憶：它決定了什麼，它讀了什麼，它試過又放棄了什麼。原始紀錄把這三者放在同一個解析度上，這就是為什麼一次四十個檔案的重構，會用早就不重要的堆疊追蹤把視窗填滿。

壓縮讓 agent 把決策保持在全保真度，把證據摺進摘要，只在需要時回去取確切的那幾行。這大致就是人工作的方式：你記得你把驗證挪進了中介層，你不記得之前失敗的六次嘗試。

失敗模式也一樣人性化。如果摘要漏掉了唯一重要的那個限制條件——"這個端點必須保持向後相容"——agent 會在四十分鐘後興高采烈地把它破壞掉，而壓縮層替你省了錢，同時送你一個 bug。可逆性讓這件事還撐得住：你可以解壓縮，看看摘要當時到底說了什麼。

為什麼這現在成了一種類別

至少有三種不同的路線在爭同一個問題。一種是實驗室的答案：造一個更大的視窗。另一種是框架的答案：檢索，而不是記憶，上下文裡只留一個工作集。第三種，也就是 billion-context 代表的：保留對話，就地壓縮，可逆。

取捨是真實的。更大的視窗最簡單，也最不可控；你每次呼叫都要為它付錢，不管那段歷史相不相關。檢索最便宜，但失去連續性，因為 agent 不知道自己忘了什麼。就地壓縮想同時保住連續性和低成本，代價是坐在你的請求路徑裡。

最後這個代價才是要想清楚的。一個夾在中間的代理，看得到每一個提示和每一次補全。對獨立開發者來說沒問題。對有資料處理規定的公司來說，這是一場合規對話，而"我們讀過原始碼，沒問題"和一次稽核不是一回事。

還有授權這件小事。技術論文是 MIT 的，放在儲存庫裡。儲存庫本身的授權據報是"Other"，而不是一個標準的 OSI 授權。如果你要在公司內部佈署，這個區別早晚會冒出來。

那個讓人不舒服的推論

如果壓縮做得夠好，100K 就夠了，那麼大量關於上下文視窗的行銷，瞄準的是一個用軟體就能更便宜解決的問題。這不代表更大的視窗沒用——一份 400 頁的文件總得有地方放——但它確實意味著"我們有一百萬 token"這個賣點，比聽起來要弱。這就像宣傳油箱更大，而不是油耗更低。

它也改變你該怎麼寫一個 agent。如果記憶是可壓縮的，就該鼓勵 agent 用結構化的形式把學到的東西寫下來，因為結構化的筆記比原始日誌好壓縮得多。一句"認證中介層從 header 讀租戶，不是從 cookie"，抵得上一千行堆疊追蹤。壓縮層獎勵良好的記帳習慣，對一個工具來說，這是個不錯的屬性。

這個專案有一千多顆星，npm 月下載量約 400,000，還有二十多個用戶端的徽章。這不是業餘規模的裝機量。它說明這個痛點是真實的，而且大家都疼，也說明人們伸手去搆的答案，不是在視窗大小後面再加一個零。

這就是那個有用的結論，不管你最後用哪個工具。上下文是預算，不是容器。這樣看待它的團隊，每一塊錢會做成更多事；等著更大視窗的那些，會繼續為"不用決定什麼重要"這件事買單。