你的 AI Agent 在前 10 步表現完美。
然後在大約第 15 步左右，它開始變得馬馬虎虎。
工具呼叫錯誤。忘記你最初的指令。輸出品質低落。
大多數人會歸咎於模型。
但問題幾乎從來不在模型。
而是在於模型所看到的內容。
組織模型所看到的內容，稱之為上下文工程。
這正迅速成為任何建構 AI Agent 的人最重要的技能。
以下是完整的操作手冊。
提示工程已死。上下文工程才是現在的重點。
你聽過提示工程。
撰寫清晰的指令、提供好的範例、告訴模型扮演什麼角色。
這在聊天機器人上效果完美。
但當你開始建構 Agent 時，它就失效了。
原因如下。
聊天機器人回答一個問題就停下來。
Agent 則會執行多個動作——瀏覽網頁、呼叫 API、撰寫程式碼、執行指令——一步一步又一絲，有時多達數十個步驟。
每一個步驟的輸出都會被加到模型的上下文中。
而這個上下文是有限的。
Anthropic 的工程團隊這樣定義：
「上下文是當你從 LLM 取樣時所包含的一組 token。上下文工程就是最佳化這些 token 的效用，以持續達成預期的結果。」
簡單來說：確保你的 Agent 在正確的時間，以正確的格式，看到正確的資訊。
提示工程是上下文工程的一個子集。
上下文工程才是一切。
你的 Agent 的上下文視窗就是 RAM。而且它正在被填滿。
LangChain 對這個比喻很到位。
把 LLM 想像成一種新的作業系統。
模型是 CPU——負責思考。
上下文視窗是 RAM——運算時所有模型能看見並推理的資訊所在的工作記憶體。
就像你的電腦在 RAM 被填滿時會變慢一樣，當上下文視窗變得擁擠時，你的 Agent 的推理能力也會下降。
這被稱為上下文腐化。
Chroma 進行了一項研究，評估了 18 個前沿模型——GPT-4.1、Claude 4、Gemini 2.5、Qwen3 等。
每個模型的效能都隨著輸入長度增加而下降。
不是在硬性限制處，而是遠在此之前。
一個擁有 200K token 視窗的模型，可能在 50K token 時就出現顯著的效能衰退。
衰退是連續的，不是懸崖式的。
為什麼？Transformer 的工作方式是每個 token 都與其他每個 token 互動——創造出 n 平方的關係。隨著上下文增長，模型維持所有這些關係的能力就會稀釋。
還有「遺失在中間」的問題。
LLM 呈現 U 形的注意力曲線。
→ 上下文開頭：記憶良好
→ 上下文結尾：記憶良好
→ 中間：大部分被忽略
研究人員測量到，當相關資訊從上下文開頭移到中間時，準確度下降了 30 個百分點以上。
你最初的指令——被埋藏在 50,000 個 token 的工具輸出之下——實際上會消失。
Claude Code 的使用者發現，當上下文容量達到 40–60% 時，輸出品質就會下降。遠在任何硬性限制之前。
實際上在爭奪 Agent 上下文空間的是什麼
有 7 個類別。全部在同一個有限的視窗中競爭。
1. 系統提示
Agent 的身分。行為規則。控制流程邏輯。不同任務類型的指令。在 Agent 中，這不只是「要有幫助」。它可以定義整個架構。
2. 工具定義
Agent 可能呼叫的每個工具都需要一個 schema 來描述它的功能、它接受哪些參數、以及何時使用它。
3. 工具呼叫結果
每次工具呼叫都會將其輸出加入上下文。一次網頁擷取：5,000–10,000 token。一次檔案讀取：差不多。這些累積得很快。
4. 檢索知識（RAG）
從向量資料庫取出的文件、搜尋結果、API 回應——任何用來告知 Agent 決策的檢索內容。
5. 對話歷史
所有發生過的事情的完整記錄。使用者訊息、Agent 回應、推理過程、先前的決定。隨著每次互動線性增長。
6. 記憶
當前會話的短期記憶。之前會話的長期記憶——使用者偏好、先前的結果、學到的模式。
7. Agent 狀態
當前計劃、待辦事項清單、進度標記、備忘筆記。記錄 Agent 在多步驟任務中位置的後設資訊。
全部 7 項在同一個視窗中競爭。
上下文工程就是決定誰勝出。
4 大核心策略
LangChain 發表了一個框架，將所有上下文工程技術歸納為 4 個類別。
你將學到的每一項技術都屬於其中之一。
寫入。選取。壓縮。隔離。
策略 1 —— 寫入（Agent 會忘記。給它們一個方法來記住。）
當 Agent 的上下文被填滿並壓縮時，它會遺失資訊。
如果 Agent 在那之前沒有寫下任何東西——那些資訊就永遠消失了。
寫入意味著給 Agent 方法，將資訊持久化儲存在上下文視窗之外。
有三種形式：
備忘筆記
給 Agent 一個工具，讓它在任務過程中做筆記。中間發現、做出的決定、它知道之後會需要的資訊。
Anthropic 建立了一個「思考」（think）工具——一個專屬空間讓 Claude 解決問題。
在 tau-bench 基準測試中，這在某些任務上提升了高達 54% 的效能。
規則檔案
持續性的程序記憶。
如果你用過 Claude Code，你應該看過 CLAUDE.md。
在每次會話開始時載入的指令——專案架構、慣例、如何執行測試、需要注意什麼。
Agent 每次啟動時都會讀取它。
它永遠不會忘記基本原則。
記憶提取
Agent 儲存事實、使用者偏好和學到的模式，以便在跨會話時檢索。
完全存在於上下文視窗之外。
Agent 明天需要的資訊，到了明天就在那裡等著。
策略 2 —— 選取（不要給 Agent 全部的東西。給它現在需要的東西。）
一個擁有 40 個工具、大型知識庫和好幾個會話歷史的 Agent，無法一次全部載入。
必須有人決定當前步驟中什麼是相關的。
傳統 RAG：系統決定。
使用者提問 → 檢索文件 → 塞進提示 → 完成。
靜態的。一次性。模型沒有發言權。
代理式 RAG：Agent 決定。它搜尋它需要的東西、優化查詢、選擇工具、判斷何時有足夠的資訊。
將檢索視為一個迭代過程，而不是一次性管線。
這很重要，因為相關性在每個步驟都會改變——而且只有 Agent 知道它下一步需要什麼。
工具選擇問題是最常讓人絆倒的。
如果你的 Agent 有超過 40 個工具，那在開始任何工作之前，可能就有高達 10,000 個 token 的工具定義佔據在上下文中。
解決方法：對工具描述進行 RAG。
與其每次呼叫都傾倒所有工具定義，不如使用語義搜尋來只浮現與當前步驟相關的工具。
一篇名為 RAG-MCP 的論文測試了這個方法。
工具選擇準確率：從 14% 提升到 43%（改善了 3 倍）。Token 用量：大約減少了一半。
Anthropic 稱之為混合策略：預先載入必要的上下文（例如 CLAUDE.md），讓 Agent 即時檢索其他所有東西。
預先載入基礎。其餘按需檢索。
策略 3 —— 壓縮（上下文會累積。保留意義，減少 token。）
即使有良好的選取，上下文還是會累積。
每一次工具呼叫、檢索到的文件、做出的決定，都會留在視窗中。
想像你的 Agent 已經進行了 20 次工具呼叫。
上下文：80,000 個 token 的累積工具輸出、對話歷史、推理軌跡。
其中大部分已經不再相關。Agent 已經根據它們採取行動了。
但它們仍然在那裡，佔據空間，削弱注意力，推高成本和延遲。
你可以在 3 個點進行壓縮。
在資訊進入上下文之前：
→ 在檢索之前將大型文件切成連貫的區塊
→ 重新排序，讓只有最有用的區塊進入
→ 在進入主要上下文之前，即時摘要工具輸出
當 Agent 正在工作時：
→ 對話歷史的滾動摘要——持續更新
→ 常見的混合做法：保留最近 10 條訊息的原貌，並摘要所有更早的訊息
→ 硬性修剪：當上下文達到某個大小閾值時，移除較舊的訊息
→ Claude Code 自動壓縮：在 95% 容量時觸發，自動摘要完整軌跡
在 Agent 已經對某件事採取行動之後：
→ 工具結果清除：一旦工具結果在 15 步之前被使用過，就丟棄它
→ 用一行摘要取代，或完全移除
→ Agent 不需要它在 20 步之前抓取的完整網頁文字
目標：減少 token 數量。保留真正重要的東西。
策略 4 —— 隔離（最強大的策略。實現多 Agent 系統。）
這裡是長時間 Agent 運行的更深層問題。
不只是空間問題。還有污染問題。
當 Agent 轉而開始寫程式碼時，研究階段詳細的檔案搜尋結果仍然留在上下文中。
那個舊的研究上下文現在變成了雜訊。它在一個 Agent 需要專注於乾淨實作的階段中干擾模型。
隔離意味著將工作的不同部分分配給各自獨立的上下文視窗。
子 Agent
一個父 Agent 將一個重點子任務——「搜尋程式碼庫找出所有與認證相關的檔案」——委派給一個子 Agent。
子 Agent 在自己的乾淨上下文視窗中工作。
當它回報時，只回傳一個精簡的摘要。
所有雜亂的搜尋操作都保留在子 Agent 的上下文中隔離起來，永遠不會污染父層。
狀態 schema 隔離（LangGraph 的方法）
設計 Agent 的狀態，讓不同的欄位儲存不同類型的上下文。
LLM 只看到與當前步驟相關的欄位。
工具結果存放在「後台」欄位中——對模型不可見，直到明確被浮現出來。
無需啟動獨立的子 Agent，就能對 Agent 在每個步驟看到的內容進行精細控制。
隔離讓複雜的多步驟工作流程真正可靠。
不同的工作。不同的上下文視窗。沒有污染。
Agent 失敗的 4 種方式（找出失敗。修正它。）
Drew Breunig 確定了隨著 Agent 上下文增長時出現的四種不同失敗模式。
你見過的任何故障 Agent 都屬於其中之一。
失敗 1：上下文中毒
一個幻覺或錯誤進入了上下文。
Agent 在後續步驟中一再引用它。
來自第 5 步的錯誤資料，在之後的每一步中不斷累積放大。
修正：在工具輸出進入上下文之前進行驗證。從錯誤中恢復後，壓縮失敗嘗試的歷史記錄。當只有解決方案重要時，不要留下 10 步的死胡同除錯記錄可見。
━━━
失敗 2：上下文分心
上下文變得過長，模型開始過度依賴最近的歷史。
它不再綜合出一個新計劃，而只是重複它最近做過的事。
它停止思考。它開始重複。
修正：積極地摘要和修剪。即使你有很大的上下文視窗可用。大視窗不意味著要填滿它。
━━━
失敗 3：上下文困惑
多餘的內容導致模型做出低品質的決策。
經典例子：一個模型在給予 46 個工具時在基準測試中失敗——儘管上下文遠在限制之內——但只給 19 個工具時卻運作良好。
工具並不是多到上下文無法容納。
而是多到模型無法清晰地推理。
修正：動態工具管理。使用 RAG-MCP 只浮現與當前步驟相關的工具。讓工具組與當前階段匹配。
━━━
失敗 4：上下文衝突
新的資訊與上下文中已有的資訊矛盾。
系統提示說一件事。一份檢索到的文件說另一件事。
Agent 無法調和這個矛盾。產生不一致的行為。
修正：建立清晰的權威順序。系統提示 > 檢索事實 > 對話歷史。在注入新資訊之前，根據現有上下文進行驗證。使用 XML 標籤和清晰的標題，讓模型知道該信任哪個來源。
如何為 Agent 撰寫系統提示（不是聊天機器人。是 Agent。）
聊天機器人的系統提示設定語氣。
「你是一個有用的助手。請簡潔友善。」
Agent 的系統提示則定義架構。
它指定控制流程——如何處理任務類型、何時使用哪些工具、出錯時該做什麼、要遵守哪些護欄。
這比較像為一個自主員工撰寫職位描述，而不是一個個性提示。
Anthropic 稱之為在「正確的高度」寫作。
過於指令式：「如果使用者提到計費，並且提到退款，並且金額超過 $100，就呼叫工具 X。」太脆弱。在你沒預料到的每一個邊緣案例上都會崩潰。
過於模糊：「要有幫助，並使用適當的工具。」沒有給 Agent 任何東西。沒有具體信號，它無法做出好的自主決策。
最佳甜蜜點：具體到足以引導自主行為。靈活到讓模型能在新情況下運用判斷力。強效的啟發式規則。不是僵化的規則。
實用技巧：
→ 使用 XML 標籤或 Markdown 標題來組織——背景、指示、工具指南
→ 從最小開始，並根據失敗迭代——不要試圖預先預測所有邊緣案例
→ 最小不代表簡短——一個複雜的 Agent 系統提示可能長達數千個 token，只要每個 token 都值得存在，那就沒問題
→ 使用少樣本範例——向 Agent 展示良好行為的樣子，而不是試圖用文字描述每一條規則
KV-Cache：值得關心上下文順序的 $$$ 原因
大多數 Agent 建構者不知道這個存在。
當你將 token 發送給 LLM 時，模型會為每個 token 計算鍵值表示。
計算成本很高。
所以推理提供者會快取這些表示。
如果你的上下文開頭——前綴——在 API 呼叫之間保持不變，提供者就會重複使用快取的計算，只處理結尾的新 token。
快速。便宜。
但如果你在呼叫之間重新排列或改變上下文的早期部分——你就會使快取失效。提供者會從頭開始重新計算所有東西。
Claude Sonnet 的成本差異：
→ 快取的輸入 token：每百萬個 $0.30
→ 未快取的輸入 token：每百萬個 $3.00
相差 10 倍。
對於一個每次任務進行 30–40 次 API 呼叫的 Agent 來說，這很快就累積起來。
KV-Cache 效率的實用規則：
→ 穩定的內容放在上下文的最上方——系統提示、工具定義、任何在回合之間不變的東西
→ 動態的內容放在最下方——對話歷史、當前步驟、Agent 狀態 → 不要在對話中動態新增和移除工具——這會使快取失效
→ 使用工具遮蔽（tool masking）而不是工具移除——保持所有工具定義在前綴中穩定（快取），只需將不相關的工具標記為當前階段不可用
7 小時產出 35,000 行程式碼的工作流程
Dex Horthy（HumanLayer 的 CEO）在 AI Engineer Code Summit 上展示了這個。
據報導，他的團隊在一個 7 小時的時段中，用它向一個大型 Rust 程式碼庫提交了大約 35,000 行程式碼。
方法：頻繁的有意壓縮。
將 Agent 的工作結構化為多個階段。每個階段產生一個壓縮的產物。每個新階段都從一個新的上下文視窗開始，只包含那個產物。
始終刻意保持在上下文視窗的 40–60% 以下。
第 1 階段 —— 研究
子 Agent 探索程式碼庫。讀取檔案。追蹤資料流。繪製架構圖。
所有雜亂的 grep 結果和檔案內容都留在子 Agent 的上下文中。永遠不會觸及父層。（隔離）
輸出：一個壓縮的 research.md——檔案路徑、函式簽名、模式、陷阱。（寫入）
上下文重置：原始研究使用了 60–80% 的視窗。研究產物將其壓縮到 15–20%。（壓縮）
第 2 階段 —— 規劃
新的上下文視窗。只包含：研究文件＋問題定義。
Agent 產生一個詳細的實作計劃。
這是最重要的人類審查檢查點。
在這裡發現邏輯錯誤，修正起來簡單又免費。稍後修正要花數小時。
第 3 階段 —— 實作
另一個全新的上下文視窗。只包含：計劃。
Agent 逐步執行。
對於複雜任務：一個 progress.md 會追蹤已完成和待完成的事項。（寫入）
結果：每個階段都有一個乾淨、專注的 Agent。沒有污染。沒有上下文腐化。沒有「第 20 步變馬虎」。
頂尖平台如何以不同方式處理這個問題
Claude Code
混合檢索。預先載入 CLAUDE.md。像 glob 和 grep 這樣的工具負責即時程式碼庫導航。
在 95% 時自動壓縮——保留架構決策和最近存取的 5 個檔案。
可以為複雜的子任務產生子 Agent，每個都有自己的乾淨上下文。
哲學：「做最簡單有效的事。」讓模型聰明地知道自己需要什麼，並給它工具去找到它。
Manus
KV-Cache 感知的上下文排序：穩定的前綴，動態的後綴。使用工具遮蔽而不是移除。
觀察壓縮管線——每次工具輸出在進入 Agent 上下文之前都會被處理。
用於狀態追蹤的持續待辦事項清單。
檔案系統作為被驅逐上下文的溢位記憶體。
專為規模而建。服務數十萬使用者，效率是商業成本問題。
ChatGPT Agent
視覺優先的方法。Agent 與 GUI 瀏覽器互動。
截圖作為視覺快照加入上下文。模型根據它所看到的進行推理。
視覺 token 很昂貴，所以 Agent 會選擇性地使用截圖數量。
使用強化學習來學習最佳工具使用策略，而不是明確編寫程式。
Google ADK
最有架構原則的方法。
三個設計原則：
- 分離儲存與呈現——持久狀態並不等於每次 API 呼叫中出現的內容
- 明確的轉換——命名、有序的處理器，以可測試、可組合的步驟轉換上下文
- 預設限定上下文範圍——每次模型呼叫只看到最少的必要資訊
工程紀律勝過提示撰寫。
通用的 Agent 回合管線
每個嚴肅的平台都收斂到每回合 Agent 的相同 5 步驟循環：
→ 收集——使用者輸入、對話歷史、工具結果、檢索文件、Agent 狀態
→ 選取——在剩餘 token 預算內，當前步驟的相關內容
→ 壓縮——摘要、截斷或重組以符合上下文 → 排列——穩定內容優先（快取），動態內容最後
→ 組合並呼叫——最終上下文 → API 呼叫 → 取得輸出 → 循環
這就是你曾經用過的每一個生產環境 Agent 內部運行的循環。
理解它，是區分能交付可靠 Agent 的建構者，與那些困惑為什麼他們的 Agent 在第 15 步會變馬虎的建構者的關鍵。
總結
上下文腐化是真實存在的，而且遠在你的上下文限制之前就開始了。
修正它的 4 個策略：
→ 寫入——將資訊持久化在上下文之外，讓 Agent 不會忘記
→ 選取——只引入當前步驟需要的內容
→ 壓縮——減少 token，保留意義，主動而非被動
→ 隔離——不同任務使用不同的上下文，沒有污染
要注意的 4 種失敗模式：
→ 中毒——錯誤資料透過每個步驟累積放大
→ 分心——長歷史讓 Agent 重複而非思考
→ 困惑——太多工具降低決策品質
→ 衝突——矛盾產生不一致的行為
KV-Cache 能節省 10 倍的成本。將穩定內容放在前面。
最佳工作流程：研究 → 壓縮 → 規劃 → 壓縮 → 實作。每個階段都有全新的上下文。
對於嚴肅的 Agent 工作來說，上下文工程不是選項。
它就是工作的核心。
如果這篇文章對你有幫助：
→ 轉發分享給你認識的每一位 Agent 建構者
→ 追蹤 @sairahul1 獲取更多在你睡覺時也能運作的系統
→ 收藏這篇——你會回來參考這 4 個策略框架
我撰寫關於 AI、產品建構以及實際有效運作的系統。
