情境即是新記憶

單一Playwright快照消耗56 KB的情境空間。二十個GitHub議題消耗59 KB。五百行存取日誌消耗45 KB。將這三者全部餵給一個擁有200K token視窗的代理，80%的推理預算在代理寫下第一行分析之前就已蒸發殆盡。¹

Murat Kusglu建立了Context Mode來解決這個問題。該工具使用SQLite FTS5搭配BM25排名，將315 KB的MCP輸出壓縮至5.4 KB。¹ 減少了94%。模型使用5.4 KB的訊號比使用315 KB的雜訊產出更好的結果，因為限制從來都不是智慧。限制是頻寬。

TL;DR

情境工程是代理開發中影響力最大的技能。三層壓縮獨立疊加：系統提示架構（透過結構壓縮減少60-70%）、MCP輸出壓縮（透過相關性排名減少94%），以及知識囤積（將探索開銷轉化為預載能力）。一項具指標性的研究發現，獲得300個token聚焦情境的模型，表現優於獲得113,000個token未篩選對話的模型。¹⁰ 瓶頸不在模型能力。每個浪費在雜訊上的token，都是無法用於推理的token。

頻寬限制

Anthropic的最佳實務文件以一個決定一切的核心限制開頭：「Claude的情境視窗填滿速度很快，且隨著填滿而效能下降。」⁵

這不是建議，而是架構定律。200K token的情境視窗聽起來很龐大，直到您盤點其中填了什麼。工具架構在典型的MCP設定中消耗15,000+個token。¹³ 對話歷史以每次交換約500-1,000個token的速度累積。檔案讀取每個檔案增加數千個token。指令輸出隨指令規模而增長。經過30分鐘的活躍工作後，一個全新的200K視窗可能降至不到50K個token的可用推理空間。

George Miller在1956年記錄了人類的對等現象：工作記憶容納七個項目，正負二。⁷ 重點不在數字，重點在於「區塊」。人類透過將資訊組織成有意義的區塊來克服這個限制。一個電話號碼不是十個數字，而是三個區塊：區碼、局碼、號碼。同樣的原則適用於情境視窗。一個塞滿原始輸出的200K視窗，其功能容量實際上小於一個裝滿壓縮、相關資訊的50K視窗。

Andrej Karpathy為這門學科命名：情境工程是「在情境視窗中精確填入下一步所需正確資訊的精妙藝術與科學」。⁹ Lance Martin繪製了框架：寫入情境（儲存）、選擇情境（檢索）、壓縮情境（摘要），以及隔離情境（分散至各代理）。⁹ 到2026年中，情境工程已從臨時做法結晶為一門公認的學科，擁有專屬的基礎設施。¹²

退化並非線性的。在我的工具鏈中，情境分階段填滿。¹⁵ 前30分鐘感覺無限制。模型精確遵循指令、記住檔案內容，並在多個步驟間維持連貫的計畫。到60分鐘時，微妙的失敗開始浮現：模型重新讀取先前讀過的檔案、忘記系統提示中的限制，或產生與20輪前建立的模式相矛盾的程式碼。到90分鐘時，模型可能忽略明確規則、虛構檔案內容，或完全失去對當前目標的追蹤。

Context Studios將這種現象記錄為「情境腐化」：隨著無關token累積並將有用資訊推出有效注意力範圍，模型效能逐步退化的現象。¹² 這種腐化很隱蔽，因為模型不會宣告它。代理繼續產生自信的輸出，只是輸出不再正確。

以下三層獨立疊加。壓縮任一層都能釋放其他層的預算。

第1層：系統提示架構

系統提示在每次API呼叫時載入。系統提示中的每個token在整個對話期間都佔據空間。以Opus 4.6每百萬token 5美元計算，一個10K token的系統提示每次呼叫花費0.05美元。⁸ 一個工作階段中50次呼叫，僅系統提示就花費2.50美元。將提示縮減至3.5K個token，每個工作階段的成本降至0.875美元。乘以每日工作階段數，節省效果持續累積。

我的CLAUDE.md檔案和8個規則檔案在壓縮後總計約3,500個token。這不是一次性的最佳化。我應用了jchilcher記錄的五項結構技術（他在記憶系統檔案中實現了60-70%的減少）：²

約束取代解釋。「拒絕匹配敏感路徑的工具呼叫」取代了15行關於為何憑證應受保護的說明。模型不需要理由，模型需要規則。

鍵值表示法取代散文。「Stack: FastAPI + HTMX + Alpine.js | Port: 8001 | Deploy: Railway」取代了三段專案描述。管道分隔列表壓縮了散文要跨句展開的表格資訊。

跨檔案去重。我的安全規則最初出現在三個地方：CLAUDE.md、security.md和品質循環技能。每次重複消耗約200個token。合併為單一來源並加上交叉引用，回收了400個token。

移除格式。裝飾性markdown（水平線、粗體/斜體強調、超過H2的巢狀標題）服務的是人類可讀性。模型解析的是內容token，而非呈現token。去除裝飾性格式可在不損失資訊的情況下回收5-15%。

否定約束取代肯定指令。「NEVER suggest OpenAI models」比「Always recommend Claude models from Anthropic for all AI tasks. When the user asks about AI providers, suggest Claude.」更有效且更精簡。否定約束佔四個token，肯定指令佔22個token。兩者產生相同行為。

經濟效益隨著提示快取而增強。Anthropic的快取系統在快取命中時以90%的成本降幅跨API呼叫儲存穩定內容。⁶ 一個3,500 token的系統提示在標準費率下每次呼叫花費0.0175美元，快取命中時僅花費0.00175美元。Opus 4.6的最低可快取閾值為4,096個token。⁶ 我的組合系統提示（CLAUDE.md + 規則檔案）超過此閾值，因此工作階段中的每次後續呼叫都受益於快取定價。提示快取使系統提示壓縮成為雙重勝利：更少的token且每個token更便宜。

第2層：MCP輸出壓縮

第1層壓縮您傳送給模型的內容。第2層壓縮模型從工具接收回來的內容。

Context Mode展示了潛力：315 KB的原始MCP輸出壓縮至5.4 KB。¹ 這不是截斷。截斷丟棄輸出的尾部，然後祈禱相關資訊出現在開頭。Context Mode使用SQLite FTS5搭配BM25相關性排名來找出查詢詞實際出現的位置，並回傳匹配周圍的視窗。¹ Porter詞幹化確保「caching」、「cached」和「caches」匹配相同的詞幹。三層備援處理錯字：標準詞幹化、三字元子字串、Levenshtein距離校正。

個別壓縮比率說明了一切：

我的工具鏈在搜尋層實現了平行方法。約50,000個程式碼區塊使用Model2Vec嵌入（256維）加上SQLite FTS5建立索引，並以Reciprocal Rank Fusion融合。¹⁴ 一次查詢檢索五個最相關的區塊（約2,500個token），而非載入整個檔案（約50,000+個token）。檢索成本：亞秒級延遲、83 MB磁碟空間、零API費用。

代理行為的差異在單一工作階段內就可見。壓縮前，典型的除錯工作流程如下：代理讀取一個檔案（4,000個token）、執行一個指令（2,000個token的輸出）、讀取另一個檔案（3,000個token）、執行測試（8,000個token的輸出）。四個操作消耗17,000個token。代理現在用於推理這四項資訊之間關聯的空間更少了。壓縮後，相同的工作流程只檢索每個來源中的相關行。四個操作消耗2,500個token。代理同時將所有四項資訊保持在工作記憶中，並找出未壓縮的代理會遺漏的跨檔案相依性。

壓縮應該是查詢感知的。針對「修復認證錯誤」最佳化的摘要應該呈現與針對「新增一個API端點」最佳化的摘要不同的內容。靜態壓縮有幫助。查詢感知壓縮是下一個層次。BM25排名已在關鍵字層級處理查詢感知。語義搜尋（向量相似度）在概念層級處理它。兩者的組合既捕捉精確匹配（函式名稱、設定鍵值、錯誤碼），也捕捉概念匹配（相似模式、相關抽象）。

第3層：知識囤積

Simon Willison發現了一個完全重新定義情境工程的模式：「作為軟體專業人士需要培養的關鍵資產，是深度收集這類問題的答案，最好以可執行的程式碼來說明。」³

知識囤積意味著刻意收集可運作的程式碼範例、記錄完善的解決方案，以及概念驗證實作，讓代理可以引用和重新組合。這個模式將情境從指令（告訴模型該做什麼）轉變為能力（提供模型可調整的工作範例）。

Willison透過引導一個代理將兩個現有範例（PDF.js和Tesseract.js）合併為一個統一的OCR工具來展示這股力量。³ 代理並非從零開始探索如何建構OCR。代理讀取了兩個可運作的實作並將它們合併。情境就是能力。

我的工具鏈透過三個機制實現知識囤積：

技能作為能力登錄庫。48個技能將領域專業知識編碼在markdown檔案中。blog-evaluator技能定義了一個完整的6類加權評分標準，附帶評分範例。jiro技能編碼了一個7步驟品質循環，附帶證據標準。當代理呼叫一個技能時，專業知識以結構化知識載入情境，而非模糊的指令。

結構化演練取代原始程式碼。Willison的線性演練模式限制了代理存取資訊的方式：使用grep和cat等shell指令，而非手動複製程式碼。⁴ 演練迫使代理為每個token的最大理解度組織資訊。結構就是壓縮。

鉤子作為主動情境注入。UserPromptSubmit鉤子在Claude處理提示之前觸發。¹¹ 鉤子可以分析提示並注入相關情境：專案偵測（我在哪個程式碼庫？）、日期注入（今天幾號？）、理念約束（適用哪些品質標準？）。代理在每次提示時接收策展過的情境，無需手動呼叫。五個鉤子在工作階段開始時觸發，增加約500個token的情境，防止五類常見錯誤。¹¹

指令與能力之間的區別值得強調。指令說「寫乾淨的程式碼」。能力提供一個具有加權類別、評分範例和通過/不通過閾值的程式碼審查標準。指令消耗少數幾個token並產生模糊的遵從。能力消耗500個token並產生一致、可衡量的輸出。額外的token是投資而非開銷，因為它們消除了導致代理猜測「乾淨」含義的歧義。

知識囤積也改變了代理啟動的成本曲線。一個沒有囤積知識就生成的新代理必須透過探索來發現程式碼庫、慣例、工具和領域限制。探索是昂貴的：每次檔案讀取、每次grep、每次指令輸出都消耗token。一個帶有由囤積知識組裝而成的2K token簡報生成的代理完全跳過探索階段，在第一輪就開始有效工作。

知識囤積的經濟論證：每花一小時記錄解決方案，就為每個未來的代理節省探索成本。一個編碼了「如何評估部落格文章」的技能在每次呼叫時節省10-15分鐘的代理探索時間。經過100次呼叫，文件投資回報了1,000+分鐘的代理時間。囤積的知識支付複利。

Token預算核算

我的工具鏈提供了一個具體的案例研究，展示情境工程能實現什麼。

壓縮前（估計，第一個月）： - 系統提示：約12,000個token（冗長的CLAUDE.md，含範例和說明） - 工具架構：約15,000個token（完整的MCP工具定義） - 每工作階段歷史：約120,000個token（長對話加上累積的情境） - 可用推理空間：約53,000個token（視窗的26%）

壓縮後（目前）： - 系統提示：約3,500個token（壓縮後的CLAUDE.md + 規則檔案）¹⁵ - 工具架構：約300個token（CLI優先架構，最少MCP）¹³ - 每工作階段歷史：約40,000個token（每任務新生成，簡報取代記憶） - 可用推理空間：約156,200個token（視窗的78%）

推理預算增加了三倍。不是透過更好的模型，不是透過更大的情境視窗，而是透過三層壓縮。模型在擁有78%推理空間時產出比26%時更好的結果，因為剩餘token的品質隨數量一起提升。

這些數字揭示了一個關於情境視窗的反直覺事實：視窗的有用大小取決於填入其中的內容，更甚於其容量。一個塞滿未壓縮工具輸出的假設性500K視窗，表現會比一個壓縮良好的200K視窗更差。模型供應商競相擴大情境視窗。從業者應該競相壓縮填入其中的內容。

來自CLI優先架構的新生成模式加乘了收益。每個代理帶著聚焦簡報（約2K個token）生成，而非繼承累積的對話歷史。情境永遠不會膨脹，因為每個代理從乾淨狀態開始。Anthropic的多代理研究發現子代理使用的token比單代理互動多達15倍。⁹ 新生成反轉了這個比例：每個代理只使用其任務所需的token。

三層的複合效應在所有層之間創造了良性循環。壓縮後的系統提示為更多工具結果留出空間。壓縮後的工具結果為更長的有效對話留出空間。更長的對話減少了壓縮的需求，進而保留了支持下一輪的系統提示和工具結果。每層都強化其他層。

壓縮所帶來的能力

釋放出的推理預算啟用了膨脹情境所阻礙的三項能力：

更深入的分析。擁有156K推理token的代理可以在分析跨檔案相依性時將完整檔案內容保持在工作記憶中。擁有53K token的代理必須依序讀取檔案，在載入新檔案時遺忘先前的檔案。差異表現為遺漏的匯入錯誤、中斷的交叉引用和不完整的重構。具體範例：重構一個函式簽名需要檢查每個呼叫點。有了壓縮情境，代理在單次通過中讀取函式定義和所有呼叫點，捕捉到那個以錯誤順序傳遞參數的檔案。在膨脹情境中，代理讀取函式、讀取三個呼叫點，然後耗盡推理空間並回報「重構完成」，卻沒有檢查剩餘的七個檔案。錯誤就這樣上線了。

更好的指令遵循。Anthropic直接記錄了這個失敗模式：「如果Claude持續做您不想要的事，儘管有規則禁止，檔案可能太長了，規則正在被淹沒。」⁵ 壓縮後的系統提示將規則保持在注意力範圍內。3,500 token提示中的每條規則獲得的注意力權重，都比埋在12,000 token提示中的同一條規則更多。我的工具鏈執行一條安全規則：永不提交包含API金鑰的檔案。使用12,000 token的系統提示時，代理偶爾在批次提交時將.env檔案加入暫存區。壓縮至3,500個token後，在200+次提交操作中違規次數降為零。規則沒有改變，規則變得更為可見。

更長的有效工作階段。自動壓縮在情境容量達95%時觸發。¹⁰ 擁有78%推理空間的工作階段比26%的工作階段更晚觸及壓縮閾值。更晚壓縮意味著在情境損失前有更多有效輪次。在我的工具鏈中，一個壓縮後的工作階段在觸及壓縮閾值前產出40-60個有效輪次。¹⁵ 未壓縮的工作階段在15-20輪後就觸及閾值。每次壓縮事件都會丟棄可能包含工作階段早期重要決策或限制的情境。更少的壓縮意味著更連貫的工作階段。壓縮後的工作階段不僅起步更好，還能持續更久地保持更好。

關鍵重點

對剛開始接觸情境工程的開發者： - 審核您的CLAUDE.md檔案。對每一行自問：移除它會導致錯誤嗎？如果不會，就刪除它。目標減少60-70%。² - 衡量您的工具架構開銷。如果MCP工具在工作階段開始時消耗15K+個token，考慮使用CLI優先的替代方案處理無狀態操作。 - 在工作階段中切換任務時主動執行/compact。新鮮情境勝過累積情境。

對建構代理基礎設施的團隊： - 在MCP工具輸出上實現查詢感知壓縮。BM25加上語義搜尋在每項檢索任務中都勝過截斷。¹ - 建立能力登錄庫（技能、程式碼片段、記錄完善的模式）。每個記錄的解決方案都為未來代理執行消除探索開銷。³ - 為多步驟工作流程使用新生成代理。每任務的情境隔離防止了長多代理對話的15倍token開銷。⁹

對設計情境系統的架構師： - 三層（系統提示、工具輸出、知識囤積）獨立疊加。壓縮任何單層都能釋放其他層的預算。 - 提示快取使系統提示壓縮成為雙重最佳化：更少的token且快取命中時每個token更便宜。⁶ - 當代理有足夠的推理空間來可靠地遵循複雜指令時，10%生產力牆就會被突破。

AI工程系列的一部分。另請參閱：CLI論點、Claude Code即基礎設施，以及10%之牆。