核心觀點： 大多數 AI 智能體的失敗，其根源不在于模型本身的能力不足，而在于“上下文工程”（Context Engineering）的缺失。

“上下文工程”這個概念近期在 AI 大模型領域迅速升溫，它究竟是新瓶裝舊酒，還是真正揭示了構建強大AI應用的核心秘訣？它與我們熟知的提示工程（Prompt Engineering）和檢索增強生成（RAG）有何不同？

本文將深入探討上下文工程的“是什么”、“為什么”以及“如何做”，為你揭示其在構建魯棒、可擴展的AI應用中的關鍵作用。

下文詳細剖析之。

一、什么是上下文工程？ 

要理解上下文工程，首先要明白什么是“上下文”。

1、上下文的真正含義

上下文不是簡單的歷史聊天記錄。它是提供給大語言模型（LLM）用于完成下一步任務的全部信息集合。我們可以將其分為三類：

• 指導性上下文 (Guiding Context):告訴模型“做什么”和“怎么做”。這部分是提示工程的核心優化對象。

    a.系統提示詞 (System Prompt): 定義模型的角色和行為準則。

    b.任務描述 (Task Description): 明確當前需要完成的任務。

    c.少量樣本示例 (Few-shot Examples): 提供范例，指導模型輸出風格。

    d.輸出格式定義 (Output Schema): 規定模型必須遵循的輸出格式，如JSON。

• 信息性上下文 (Informational Context):告訴模型“需要知道什么”。這部分為模型提供解決問題所需的事實和知識。

    a.RAG: 從外部知識庫（比如：文檔、數據庫）中檢索相關信息。

    b.記憶 (Memory): 包括當前對話的短期記憶和跨對話的長期記憶（比如：用戶偏好）。

    c.狀態/草稿紙 (State / Scratchpad): 記錄模型在任務過程中的中間思考和計劃。

• 行動性上下文 (Actionable Context):告訴模型“能做什么”和“做了之后的結果”。這部分賦予模型與外部世界交互的能力。

    a.工具定義 (Tool Definition): 描述模型可以使用的工具（API、函數等）。

    b.工具調用記錄 (Tool Traces): 記錄模型調用了哪些工具以及返回了什么結果。

2、上下文工程的定義

基于以上分類，我們可以這樣定義上下文工程：

上下文工程是一門系統性學科，專注于設計、構建并維護一個動態系統。該系統能在 AI 智能體執行任務的每一步，為其智能地組裝出最優的上下文組合，從而確保任務能夠被可靠、高效地完成。

一個絕佳的類比是，如果 LLM 是計算機的 CPU，那么上下文窗口（Context Window）就是內存（RAM）。上下文工程就是這個系統中的“內存管理器”。它的任務不是簡單地把信息塞滿內存，而是通過精密的調度，決定在每個時刻加載什么、丟棄什么，以保證 CPU 高效運轉，最終產出正確結果。

3、與提示工程、RAG 的區別

• 提示詞工程 (Prompt Engineering):是上下文工程的子集，專注于優化“指導性上下文”，即如何下達清晰的指令。
• RAG (Retrieval-Augmented Generation):是實現上下文工程的關鍵技術手段之一，主要負責動態填充“信息性上下文”。

因此，上下文工程是一個更宏大、更系統的概念，它統籌管理所有類型的上下文，目標是構建一個最高效的信息供給系統。

二、為什么我們需要上下文工程？ 

當 AI 系統的表現不佳時，我們往往會怪罪于模型本身。但大多數情況下，問題出在上下文的供給上。

1、示例1：缺失上下文的代價

假設 AI 智能體收到郵件：“Hi, 明天有空聚一下嗎？”

• 上下文貧乏的 AI："感謝您的消息。我明天有空。請問您希望約在什么時間？" (無效回復，未推進任務)
• 上下文豐富的 AI：在回復前，它的上下文工程系統會自動組裝信息：
• 信息性上下文：檢索日歷發現明天已滿；識別發件人 Jim 是重要伙伴；分析歷史郵件確定應使用非正式語氣。
• 行動性上下文：知道自己有??send_calendar_invite ??這個工具。
• 最終回復："Hi Jim! 我明天日程完全滿了。周四上午有空，你看方便嗎？我發了一個暫定邀請，如果時間合適請確認。" (高效、智能)

這里的“魔力”并非來自更聰明的模型，而是來自一個能夠為任務動態組裝恰當上下文的系統。

2、示例2：上下文退化的挑戰

既然上下文如此重要，是不是把它全部塞給模型就行了？答案是否定的。對于長期、復雜的任務（比如：編程），簡單的信息累加會導致“上下文退化”：

圖片

第一、性能下降： 無關緊要的舊信息會干擾當前任務，造成“上下文干擾”。

第二、成本與延遲激增： 上下文越長，API 調用成本越高，響應越慢。

第三、最終崩潰： 當信息量超過模型的上下文窗口上限時，系統將直接報錯或因信息截斷而出錯。

結論： 上下文是一種需要被主動管理的、有限的資源。簡單的缺失或無腦的堆砌都無法構建出強大的 AI 智能體應用。因此，我們需要一套系統性的方法論——上下文工程。

三、如何實踐上下文工程？

上下文工程的實踐核心在于對上下文進行智能的寫入（Write）、選取（Select）、壓縮（Compress）和隔離（Isolate）。

1. 寫入 (Write): 將有價值的信息持久化，超越單次對話的限制。

• 會話內寫入：將中間思考和計劃寫入“草稿紙”，供當前任務使用。
• 持久化寫入：將用戶偏好、關鍵事實等存入外部記憶系統（比如：向量數據庫），實現跨會話的“學習”和“成長”。

2. 選取 (Select): 在每次調用 LLM 前，從所有可用信息中，動態拉取與當前子任務最相關的信息。

• 確定性選取：根據預設規則加載固定上下文（比如：啟動時加載項目配置文件）。
• 檢索式選取：通過相似度搜索從知識庫、記憶中拉取最相關的信息（RAG 的核心）。

3. 壓縮 (Compress): 在信息進入上下文窗口前，對其進行“降噪”，用更少的 Token 承載最核心的信號。

• 自動總結：當上下文過長時，自動總結歷史對話，只保留關鍵部分。
• 專用壓縮模型：使用一個專門微調過的“壓縮 LLM ”來對上下文進行提煉。
• 修剪策略：例如，直接截斷最早的歷史記錄。

4. 隔離 (Isolate): 在系統架構層面設置信息邊界，防止信息污染和干擾。

• 多智能體架構：這是最經典的隔離策略。讓多個“專家”子智能體并行處理各自領域的信息，然后只將最關鍵的結論“壓縮”并上報給主智能體。這極大地減輕了主智能體的認知負擔，提高了信息密度，避免了長上下文帶來的各種問題。
• 工具調用：將復雜的計算或操作隔離在沙盒環境中執行，只將最終結果返回到上下文中。

四、上下文工程總結

上下文工程標志著 AI 智能體應用開發的范式轉變。我們的重心正從“尋找那句完美的提示詞”，轉向“如何設計一個能夠為模型在每一步都動態組裝出完美上下文的、健壯可靠的系統”。

理解并熟練運用寫入、選取、壓縮、隔離這四大實踐，將是區分一個“有趣的演示”和一個“可靠的、可規模化的應用”的關鍵。歸根結底，所有努力都指向同一個目標：在模型做出決策前，為它準備好一份恰到好處的上下文。這，就是上下文工程的禪意所在。

好了，這就是我今天想分享的內容。

本文轉載自??玄姐聊AGI??  作者：玄姐