昨天談多代理協作時，我們反覆撞上同一堵牆：協調者會被工作者回傳的脈絡淹沒，四個工作者以上就常撐爆視窗，成本也跟著失控。那堵牆有個正式的名字——它不是「代理怎麼分工」的問題，而是「脈絡怎麼管」的問題。這門把對的資訊、在對的時刻、以對的形式塞進視窗的手藝，2026 年有了公認的名字：脈絡工程（context engineering）。昨天談的是「多個代理如何分工」，今天談「每個代理的視窗裡到底該放什麼」——這是決定代理可不可靠的底層變數。
📖 學
脈絡工程和 prompt engineering 不是同一件事。 Prompt engineering 關心的是「怎麼把一句話問得漂亮」，而脈絡工程關心的是整個資訊流：系統提示、工具定義、歷史對話、檢索回來的文件、記憶、工作者的回傳——在代理每一步推理時，如何一起被組織進那個有限的視窗。Anthropic 在《Effective context engineering for AI agents》裡把它定義成一種「策展」（curation）：脈絡是稀缺資源，你的工作是持續判斷「這一步，模型真正需要看到什麼」，然後只放那些。隨著代理從一問一答走向多輪、長時間的自主任務，這件事的重要性已經超過單純把提示寫漂亮。
為什麼不能「把能塞的都塞進去」？因為模型會得『脈絡腐化』（context rot）。 這是 2026 年最反直覺、也最重要的一個發現。Chroma 測試了 18 個前沿模型，結論一致得驚人：每一個模型，隨著輸入變長，表現都會變差——而且不是等到視窗塞滿才變差，是遠在上限之前就開始掉。有分析指出，一個號稱 200K token 的視窗，可能在輸入才 50K 時就出現明顯的準確率損失，某些複雜任務上「有效脈絡」甚至比廣告數字低上一大截。原因之一是位置偏誤：模型對放在開頭和結尾的資訊記得最牢，埋在中間的東西最容易被忽略。這推翻了一個很多人的直覺——長視窗不等於你可以懶得整理。塞得愈滿，訊號愈可能被雜訊稀釋，反而更笨。
業界因此收斂出一套共通的操作框架：Write、Select、Compress、Isolate（寫入、選取、壓縮、隔離）。 這是 LangChain 整理、如今被廣泛引用的四支柱。**Write（寫入）**是把脈絡存到視窗「外面」：最典型的是 scratchpad（草稿板）和長期記憶，讓代理把中間發現寫下來，而不是全部堆在對話裡——這正好接上前天談的記憶系統。**Select（選取）**是需要時才把相關的東西拉進來，用相似度檢索、embedding、甚至語意化的工具選取，只挑當下這一步用得到的。**Compress（壓縮）**是只保留完成任務所需的 token，靠對話摘要、工具輸出壓縮來瘦身——這就是昨天要工作者「只回傳結論、別貼原始長文」的原理。**Isolate（隔離）**是把脈絡切開，讓不同子代理各自在獨立的視窗裡工作、互不污染——這正是昨天多代理架構之所以能省視窗的關鍵。四支柱其實把前幾天談的記憶與多代理，收進了同一張地圖。
2026 的一個重要轉向，是從「預先塞好」走向「即時取用」（just-in-time context）。 傳統 RAG 的做法是任務開始前，先把可能用到的文件一股腦檢索、塞進提示。新的做法反過來：讓代理拿著檔案路徑、查詢、API 這些「輕量識別碼」，在真正需要的那一刻才自己去把資料撈進來。這樣做的好處是視窗平時保持乾淨，只在推理到某一步時載入那一步真正相關的內容，天然避開脈絡腐化。Anthropic 把這比喻成人類的工作方式——我們不會把整個檔案櫃背進腦子，而是需要哪份就抽哪份。對開發者來說，這意味著「給代理好的工具去取資料」，往往比「事先塞好一大包資料」更有效。
還有兩個容易被忽略、但很實用的原則：系統提示的『高度』要對，以及長任務要靠『壓實』續命。 關於高度（altitude），Anthropic 的建議是系統提示既不要細到把每種情況都寫死成 if-else，也不要空泛到只剩口號，而要停在一個「夠具體能引導行為、又夠彈性讓模型自己判斷」的甜蜜點，並用 <background>、<instructions>、<tools> 這類結構化區塊把它分得清清楚楚。關於壓實（compaction），當一個代理任務跑很久、對話累積到快滿，做法是把前面的歷程摘要成一份精煉的狀態，丟掉冗長的原始往返、只留關鍵結論與待辦，然後帶著這份摘要繼續——等於幫代理的記憶「換氣」。這兩招合起來，就是讓代理能撐過長任務而不越跑越鈍的日常紀律。
把這幾天串起來看，會發現一條清楚的主線。 記憶系統讓單一代理跨 session 記得你；多代理讓大任務能被拆開平行處理；而脈絡工程，是這一切能不能「不爆炸、不變笨」的共同底座。它不是某個花俏的新架構，而是一種克制的工程紀律：預設不是「加更多」，而是「找出最小的一組高訊號 token」。2026 年真正在生產環境活下來的代理系統，靠的往往不是更大的視窗或更多的代理，而是把視窗裡的每一個 token 都當成稀缺資源來對待。
🧠 記
- 脈絡工程 ≠ prompt engineering：前者管的是系統提示、工具、歷史、檢索、記憶、代理回傳整條資訊流如何被策展進有限視窗，是決定代理可靠度的底層變數。
- 脈絡腐化（context rot）：Chroma 測 18 個前沿模型，全部隨輸入變長而變差，且遠在視窗上限前就開始掉（200K 視窗可能 50K 就明顯掉準）；位置偏誤讓「埋在中間」的資訊最易被忽略。長視窗不等於能懶得整理。
- 四支柱框架 Write / Select / Compress / Isolate：寫到視窗外（scratchpad、記憶）、需要時才選取、壓縮只留必要 token、用子代理隔離互不污染——把記憶與多代理收進同一張地圖。
- 即時取用（just-in-time）取代預先塞滿：給代理路徑、查詢、API 等輕量識別碼，需要時才撈資料，讓視窗平時保持乾淨。
- 系統提示要抓對「高度」（夠具體又夠彈性、用結構化區塊分段）；長任務靠「壓實」（compaction）把歷程摘要成精煉狀態再續跑。
✍️ 實踐
挑一個你最近跑得「愈聊愈笨」的長對話——可能是一份反覆修改的長文件、或一段拖了很久的除錯過程。做兩件事驗證今天的觀念。第一，親手做一次壓實：開一個新對話，把前面所有往返濃縮成一段「目前狀態＋關鍵決定＋待辦」的摘要當開頭，然後接著問你原本要問的下一步，比較看看回答有沒有變清楚。第二，做一次減法實驗：把你習慣塞給 AI 的那一大包背景資料，刻意砍掉一半你其實用不到的部分，只留跟這一題直接相關的，再問同一個問題。你多半會發現——答案沒變差，甚至更準。這就是脈絡腐化與「少即是多」最直接的體感。
🔗 延伸學習
- Effective context engineering for AI agents（Anthropic 官方指南）
- Context Engineering for Agents（LangChain：Write / Select / Compress / Isolate 四支柱原文）
- Context Rot: Why LLMs Degrade as Context Grows（Chroma 研究解析）
- Context engineering: memory, compaction, and tool clearing（Claude Cookbook 實作範例）
💬 問 AI
我有一段跑很久、愈來愈不精準的 AI 對話／任務：__（貼上或描述目前狀況與你要的下一步）。
請用「脈絡工程」的角度幫我整理，不要直接給最終答案：
1. 幫我做一次「壓實」：把前面的往返濃縮成一份「目前狀態＋關鍵決定＋待辦清單」的精煉摘要，作為之後對話的新開頭；
2. 用 Write / Select / Compress / Isolate 四支柱檢查我現在的做法，指出我把太多不相關資訊塞進視窗、或該存到視窗外的地方；
3. 針對我要問的下一步，告訴我「這一步真正需要哪些脈絡就夠了」，並列出哪些現有內容其實可以先移除；
4. 提醒我這個任務裡最可能發生「脈絡腐化」的環節，以及怎麼用即時取用（需要時才撈資料）來避開。