上下文工程是構建高效AI智能體的關鍵方法論。由于大模型存在上下文衰減和注意力預算限制，需要謹慎管理系統指令、工具、外部數據和消息歷史。核心策略是使用最少但信息量高的token，如采用即時上下文檢索、通過壓縮和結構化筆記應對長周期任務。

1. 上下文工程與提示詞工程

2. 為什么上下文工程對于構建強大的智能體至關重要

3. 高效上下文的結構

4. 上下文檢索與自主智能檢索

5. 長周期任務的上下文工程

6. 應對上下文污染的方法

6.1 壓縮

6.2 結構化筆記

6.3 子智能體架構

結論

原文：???https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents??

Context is a critical but finite resource for AI agents.（對 AI 智能體而言，上下文是一項關鍵卻稀缺的資源。）

1. 上下文工程與提示詞工程

上下文工程可以看作是提示詞工程的延伸。

提示詞工程說的是如何編寫和安排對大模型的指令，讓模型更容易給出理想的結果。

而上下文工程指的是，在模型推理時，怎樣挑選和管理進入上下文的一整套信息，這些信息不僅來自提示本身，也包括各種可能以其他方式（比如工具調用）被放進上下文的內容。

在用大模型做工程的早期，大部分工作都集中在提示詞上，因為除了日常對話之外，許多場景都需要專門為一次性分類或文本生成任務優化過的提示。顧名思義，提示工程關注的核心是怎樣把提示寫得有效，尤其是系統提示。

但隨著我們開始構建更強的智能體，這些智能體需要在多輪推理和更長時間尺度下運作（比如各種代碼開發IDE），光靠寫提示詞已經不夠了，我們還需要能管理整個上下文狀態的策略，包括系統指令、工具、Model Context Protocol（MCP）、外部數據、消息歷史等。

一個在循環中運行的智能體，會不斷產出可能對下一輪推理有用的新信息，而這些信息需要被持續整理和提煉。

上下文工程關注的，就是在上下文窗口有限的情況下，從這一整套不斷變化的內容里挑選出真正該放進去的部分，可以說既是一門技巧，也是一門方法論。

相比于寫提示這種相對獨立的任務，上下文工程是反復進行的；每次要決定把什么內容交給模型時，都要重新進行一輪整理和篩選。

2. 為什么上下文工程對于構建強大的智能體至關重要

盡管大語言模型處理速度快，能管理越來越多的數據，但我們觀察到，它們和人類一樣，在達到一定程度時會出現注意力分散或混亂的情況。

在“針撿干草堆”式的基準測試中，研究發現了“上下文退化”的現象：隨著上下文窗口中的 token 數量增加，模型從中準確回憶信息的能力會下降。

雖然不同模型的衰減速度不同，但幾乎所有模型都會表現出這一特性。

因此，上下文必須被視為一種有限資源，其邊際效益會遞減。

就像人類的工作記憶有限一樣，大模型在解析大量上下文時也有一個“注意力預算”。每增加一個 token，這個預算就會被消耗一部分，因此需要更加仔細地挑選可以提供給模型的 token。

這種注意力稀缺源于大模型的架構限制。

大模型基于 Transformer 架構，每個 token 都可以關注上下文中所有其他 token，這意味著 n 個 token 會產生 n2 的兩兩關系。

隨著上下文長度增加，模型捕捉這些兩兩關系的能力會被拉得很薄。

此外，模型的注意力模式是從訓練數據分布中形成的，而短序列通常比長序列更常見，這意味著模型在處理全上下文依賴關系時經驗不足，專門參數也較少。

模型在長上下文下仍然有很強能力，但在信息檢索和長程推理上可能不如短上下文時精確。

因此，要構建高效智能體，必須進行謹慎的上下文工程。

3. 高效上下文的結構

由于大模型的注意力預算有限，良好的上下文工程意味著找到最少數量但信息量高的 token，以最大化實現預期結果的可能性。

System prompts 應當非常清晰，使用簡單直接的語言，以適合智能體理解的高度呈現信息。這里的“高度”指的是避免兩種常見失敗模式的最佳平衡。

失敗模式一，在提示詞中硬編碼復雜、脆弱的邏輯來引導模型產生特定行為，這種做法增加了系統脆弱性和維護難度。

失敗模式二，提供過于模糊的高層指導，無法給模型具體信號。

最佳的高度應當兼顧這兩者：足夠具體以有效引導行為，同時又有一定靈活性，為模型提供強有力的啟發式規則來引導行為。

在一個極端，我們會看到脆弱的 if-else 硬編碼提示；而在另一個極端，則是過于籠統的提示，或者錯誤地假設雙方有共享的上下文。

可以將提示詞分成不同的部分（例如 <background_information>、、## 工具指南、## 輸出說明 等），并使用 XML 標簽或 Markdown 標題等方式來區分這些部分。不過，隨著模型能力的提升，提示的具體格式可能不再那么重要。

工具讓智能體能夠與環境交互，并在工作過程中引入新的上下文。

由于工具定義了智能體與信息或行動空間的契約，因此它們的效率非常重要，不僅要返回 token 高效的信息，還要促使智能體行為高效。

我們經常看到的失敗模式之一，是工具集合過于臃腫，覆蓋過多功能，或導致在選擇使用哪種工具時出現模糊的決策點。

如果人類工程師都無法明確指出在特定情況下應使用哪個工具，那么 AI 智能體更不可能做得比人類好。

提供示例，也就是少樣本提示，是一個公認的最佳實踐。

如果在提示詞中堆砌大量邊緣案例，試圖將 LLM 在特定任務上應遵循的每條規則都體現出來，并不推薦。應努力挑選一套多樣化、典型的示例，能夠有效展示智能體的預期行為。

我們對上下文各組成部分（系統提示、工具、示例、消息歷史等）的總體建議是：要謹慎、確保上下文信息充實，同時保持緊湊。

4. 上下文檢索與自主智能檢索

在anthropic另一篇文章《構建高效 AI 智能體》中，曾強調過基于 LLM 的工作流與智能體之間的區別。

智能體是循環中自主使用工具的大語言模型。

許多 AI 原生應用在推理前會采用基于嵌入的檢索方式，提前獲取重要上下文供智能體推理。

隨著智能體方法的發展，團隊越來越多地將這些檢索系統與“即時上下文”策略結合使用。

采用“即時上下文”方法的智能體，會保持輕量級的標識符（文件路徑、存儲查詢、網頁鏈接等），并在運行時利用工具動態加載數據到上下文中。

Anthropic 的智能體編程解決方案 Claude Code 就使用這種方式，可以在大數據量上執行復雜數據分析。

模型可以編寫針對性查詢、存儲結果，并使用 Bash 命令如 head 和 tail 分析大量數據，而無需將完整數據對象加載到上下文中。這種方法類似于人類認知：我們通常不會記住整個信息庫，而是通過文件系統、收件箱、書簽等外部組織和索引系統按需檢索信息。

這些標識符引用的元數據還能高效地指導行為，無論是顯式提供的還是直覺性的信息。對于在文件系統中操作的智能體來說，tests 文件夾中的 test_utils.py 文件與 src/core_logic/ 下同名文件的用途明顯不同。文件層級、命名規則、時間戳等都提供了重要信號，幫助人類和智能體理解信息的使用時機和方式。

智能體可以逐層構建理解，只在工作記憶中保留必要信息，并通過筆記策略進行額外持久化。這種自主管理的上下文窗口讓智能體專注于相關信息，而不會被龐大但可能無關的信息淹沒。

需要權衡的是：運行時探索比預取數據更慢，而且需要有經驗的工程設計，確保 LLM 擁有正確的工具和啟發式方法來有效導航信息空間。否則，智能體可能因工具使用不當、追蹤死胡同或未能識別關鍵信息而浪費上下文。

在某些情況下，高效的智能體可能會采用混合策略：預先檢索部分數據以加快速度，同時根據需要進行自主探索。

自主性“合適”程度的界限取決于任務。

Claude Code 就采用這種混合模式：CLAUDE.md 文件在上下文中初始加載，而 glob、grep 等原語允許它在環境中即時檢索文件，有效規避過時索引和復雜語法樹的問題。

混合策略可能更適合內容不太動態的場景，如法律或金融工作。

隨著模型能力提升，智能體設計將傾向于讓智能模型自主智能地行動，人工干預逐漸減少。在這一快速發展的領域，“做最簡單可行的事情”仍然是基于 Claude 構建智能體的最佳建議。

5. 長周期任務的上下文工程

長周期任務要求智能體在操作序列中保持連貫性、上下文一致性和目標明確并持續的行為，這些任務的 token 數量可能超過 LLM 的上下文窗口。

對于持續幾十分鐘到數小時的任務，如大型代碼庫遷移或全面研究項目，智能體需要特殊技術來繞過上下文窗口的限制。

等待更大上下文窗口似乎是顯而易見的策略，但在可預見的未來，不論上下文窗口大小，都可能受到上下文污染和信息相關性問題的限制

6. 應對上下文污染的方法

6.1 壓縮

壓縮是指在對話接近上下文窗口極限時，將其內容總結，并用總結重啟新的上下文窗口。

壓縮通常是上下文工程中提升長期連貫性的首要手段。核心在于以準確的方式提煉上下文窗口內容，使智能體能夠在性能下降最小的情況下繼續工作。

以 Claude Code 為例，我們將消息歷史傳給模型，總結并壓縮最關鍵的細節。模型保留架構決策、未解決的 bug 和實現細節，同時丟棄冗余工具輸出或消息。智能體隨后在壓縮后的上下文加上最近訪問的五個文件繼續工作，用戶無需擔心上下文窗口限制而保持連續性。

壓縮的關鍵在于選擇保留和舍棄的內容。

過度壓縮可能導致丟失微妙但關鍵的上下文，其重要性可能在后續才顯現。工程師在實現壓縮系統時，應在復雜智能體軌跡上仔細調優提示。

首先保證最大化召回，確保壓縮提示捕獲軌跡中每條相關信息，然后迭代提高精確度，去掉冗余內容。

6.2 結構化筆記

結構化筆記，或稱智能體記憶，是指智能體定期寫筆記，并存儲在上下文窗口之外的記憶中。這些筆記可在之后重新調入上下文。

這一策略提供了低開銷的持久記憶。

例如 Claude Code 創建待辦事項列表，或自定義智能體維護 NOTES.md 文件，這種模式允許智能體在復雜任務中跟蹤進度，保持關鍵上下文和依賴關系，否則在多次工具調用后會丟失。

6.3 子智能體架構

與其讓一個智能體維護整個項目狀態，不如讓專門的子智能體處理聚焦任務，保持干凈的上下文窗口。

主智能體負責高層協調，子智能體執行深入技術工作或使用工具檢索相關信息。每個子智能體可能處理數萬 token 的探索，但只返回其工作的精煉總結（通常 1,000–2,000 token）。

這種方式實現了明確的職責分離，詳細搜索上下文保留在子智能體內部，而主智能體專注于綜合分析結果。

不同方法的選擇取決于任務特性：

• 壓縮適合需要頻繁交互的任務；
• 筆記適合迭代開發、有明確里程碑的任務；
• 多智能體架構適合復雜研究與分析，需要并行探索以獲得收益。

即便模型持續改進，長時間交互中保持連貫性的挑戰仍將是構建高效智能體的核心問題。

結論

上下文工程代表了構建 LLM 應用方式的根本轉變。

隨著模型能力提升，挑戰不僅是編寫完美提示詞，而是謹慎管理每一步進入模型有限注意力預算的信息。

指導原則始終是：找到最少的高信息量 token 集，以最大化實現預期結果的可能性。

技術會隨著模型進步持續演化，我們已經看到，更智能的模型需要的指導更少，使智能體能夠更自主地運行。但即便能力提升，將上下文視為珍貴且有限的資源，依然是構建可靠、高效智能體的核心。

本文轉載自??AI取經路??，作者：AI取經路