上下文工程中的上下文
圖片
今天我們要探討一篇非常有前瞻性和系統性的論文:《上下文工程2.0:上下文工程的“上下文”》(Context Engineering 2.0: The Context of Context Engineering)。現在都在玩各種大模型、AI Agent,天天都在說“Prompt Engineering”,感覺這是個很新的東西。
但這篇論文告訴我們,我們可能只看到了冰山一角。它把我們的視野從當下的“技術熱點”拉到了一個更宏大、更深刻的“歷史演進”和“理論框架”的層面。
第一部分:“上下文工程”不是新事物

這篇論文的核心論點:上下文工程(Context Engineering)并非誕生于LLM時代,而是一門已經發展了二十多年的、伴隨機器智能水平不斷演進的學科。
我們現在做的所謂“提示詞工程”、“RAG(檢索增強生成)”等等,都只是“上下文工程”在當前這個時代(也就是論文定義的2.0時代)的具體實踐形式。
那到底什么是“上下文工程”呢?
1.什么是“上下文”(Context)?
論文給出了一個非常經典且寬泛的定義:“任何可以用來描述‘實體’(人、地點、物體)狀況的信息,只要這些實體與用戶和應用的交互相關,都算上下文。”
這個定義非常重要。不要把“上下文”狹隘地理解為對話歷史記錄。你當前所在的文件夾路徑、你的操作系統、你正在使用的軟件、甚至你過往的偏好、外部可調用的API工具……這些都是上下文。它是情境的總和。
2.什么是“上下文工程”(Context Engineering)?
它是指系統性地設計、收集、存儲、管理和使用上下文信息,以增強機器對人類意圖的理解和任務執行能力的過程。關鍵詞是“系統性地”。
它不是零敲碎打的技巧,而是一整套方法論。它的根本目的始終沒變:彌合人類的高熵、模糊意圖與機器所能理解的低熵、結構化指令之間的鴻溝。
第二部分:上下文工程的四個時代
這篇論文最具洞見的地方,就是提出了一個“四階段”的演化模型,把上下文工程的發展和機器智能的等級牢牢綁定在了一起。
?1.0 時代:原始計算時代 (1990s - 2020)
特征:機器智能水平低,只能理解結構化、低熵的輸入。
人機關系:“人適應機器”。
實踐:我們用圖形界面(GUI)的菜單、按鈕,或者早期的環境感知計算(比如手機進入會議室自動靜音),這些都是把復雜的意圖“翻譯”成機器能懂的簡單指令。設計師是“意圖翻譯官”。
?2.0 時代:智能體時代 (2020 -至今)
特征:以LLM為代表,機器開始具備理解自然語言和處理模糊信息的能力。
人機關系:“機器開始適應人”。
實踐:這就是我們現在所處的時代。我們用自然語言寫Prompt,用RAG給模型“喂”知識,設計復雜的Agent工作流。上下文變成了給一個有能力的“智能體”下達的指令(Instruction)。
3.0 時代:人類水平智能時代 (未來)
?特征:AI達到與人類相當的推理和理解能力。
?人機關系:人機成為真正的協作者(Collaborator)。
?暢想:AI能像人一樣感知社交氛圍、情緒狀態等高熵信息。交互會變得極其自然,不再需要費盡心思地“設計”上下文,AI能自己“領悟”。
4.0 時代:超人類智能時代 (暢想)
?特征:機器智能超越人類。
?人機關系:發生反轉,機器成為啟發者(Master)。
?暢想:AI不再是被動地理解我們給它的上下文,而是能主動為我們構建全新的上下文,揭示我們自己都未曾意識到的深層需求。就像AlphaGo下出了人類棋手從未想過的棋路一樣。
可以看到,從1.0到4.0,機器的智能水平越高,處理上下文的能力越強,我們人類需要付出的“翻譯成本”就越低。這就是整個演進的核心驅動力。
第三部分:上下文工程的三大支柱
講完了宏觀歷史,我們來看看具體的“工程實踐”。論文從三個維度系統地梳理了上下文工程的技術要點,這部分對大家做實際項目非常有指導意義。
1. 上下文的收集與存儲 (Context Collection & Storage)
?怎么收集?從1.0時代的GPS、時鐘等簡單傳感器,進化到2.0時代的多模態、多設備(手機、可穿戴設備、IoT)的持續信息流。
?怎么存儲?從1.0時代的本地日志文件,進化到2.0時代的分層存儲架構。這很像我們計算機的存儲體系:
短期內存(RAM):對應模型的上下文窗口,快速但有限。
長期內存(硬盤):對應外部數據庫(向量數據庫、SQLite等),持久且海量。
2. 上下文的管理 (Context Management)
這是整個工程的“大腦”,也是最復雜、最核心的部分。如何把原始、雜亂的上下文變得井井有條、易于使用?
?上下文的組織:
分層記憶架構:明確區分短期記憶和長期記憶。重要的、反復使用的信息,要從短暫的上下文窗口沉淀到長期的知識庫里。
上下文隔離 (Context Isolation):這個思想非常巧妙。比如論文提到的子智能體(Subagent)。讓一個主Agent負責統籌,把特定任務(如代碼分析、文件讀寫)交給擁有獨立上下文的子Agent處理。這樣做的好處是,防止不同任務的上下文互相“污染”,也讓系統更加模塊化、穩定可靠。
- 上下文的抽象,或者叫“自我烘焙” (Self-Baking)
這是一個非常形象的比喻。Agent不能只是被動地存儲信息,它必須能主動地“消化”和“吸收”自己的經歷,把原始上下文“烘焙”成更緊湊、更結構化的知識。這才是從“記憶”到“學習”的關鍵。
方法1:自然語言總結。定期讓模型自己寫個工作小結,總結最近發生了什么。簡單直接,但不夠結構化。
方法2:固定模式提取。將關鍵信息提取到一個預設的結構(Schema)里,比如任務樹、實體關系圖。這讓信息變得可查詢、可推理。
方法3:漸進式向量壓縮。把信息編碼成向量(Embedding),并隨著時間推移,將舊的向量融合成更抽象的、更高層次的語義記憶。
3. 上下文的使用 (Context Usage)
管理好的上下文,最終要為任務服務。
?上下文的選擇:上下文窗口是寶貴的資源,不能什么都往里塞。必須有一套有效的篩選機制,論文稱之為“注意力之前的注意力”。你需要根據語義相關性、邏輯依賴性、新近度等因素,動態地選擇最關鍵的信息放入窗口。
?上下文的共享:
系統內共享:多個Agent如何協作?可以通過Prompt傳遞、結構化消息交換,或者一個共享的“黑板”(Shared Memory)來通信。
跨系統共享:你的AI助手如何與Office套件協同?需要通過適配器(Adapter)或者統一的上下文表示協議來實現。
?主動的用戶需求推理:最高級的用法是,系統能通過分析長期上下文,主動預測你的潛在需求。比如,發現你總是在下午搜索咖啡店,就主動在下午推薦附近的優惠。

最后,論文指出了當前面臨的挑戰:比如長上下文處理的性能瓶頸、上下文收集的效率低下、模型對復雜邏輯的理解不足等。
并提出了一個非常宏大的終極構想——“上下文的語義操作系統”(Semantic Operating System for Context)。
這是什么概念?想象一下,未來會有一個系統,它能管理一個人一生的數字痕跡(對話、決策、行為),像一個動態的、有生命的個人知識庫。它能實現真正的長期記憶、持續學習、甚至具備遺忘機制。到那時,我們的“數字孿生”或者說“數字存在”,將不再是科幻,而是由我們一生的上下文所定義的現實。
本文轉載自????芝士AI吃魚????,作者:芝士AI吃魚

















