解構上下文工程:打造智慧 LLM 系統新視角

解構上下文工程:打造智慧 LLM 系統的全新視角

人工智能領域正歷經一場變革,重心從優化獨立的提示語轉向有系統地建構環繞大型語言模型(LLM)的資訊生態。隨著 AI 應用從簡單的聊天機器人進化為能夠執行複雜任務的智能代理,模型輸出的品質不再僅僅依賴於單一提示,而是更多地取決於所提供資訊的品質。

上下文工程的演進:從提示到系統的範式轉變

超越提示的時代

業界領袖普遍認為,為 LLM 提供完成任務所需的上下文資訊是關鍵技能。Andrej Karpathy 將「上下文工程」定義為「用恰當的資訊填充上下文窗口的藝術與科學」。這表明上下文工程在當前 AI 發展階段佔據核心地位。

本報告的核心觀點是:大多數智能代理的失敗並非源於模型本身,而是上下文的缺失。因此,AI 工程的核心挑戰已轉變為建構為模型提供資訊的支援系統。當智能代理表現不佳時,通常是因為模型缺乏做出正確決策所需的上下文、指令和工具。理解和掌握上下文工程已成為建構可靠、強大且能創造卓越用戶體驗的 AI 應用之前提。

上下文工程:一種系統性的學科

上下文工程不僅僅是提示工程的簡單升級,而是一門獨特的系統級學科。它關注建構一個動態的資訊供給系統,而非僅僅優化文本輸入。上下文工程可定義為:一門旨在以正確的格式、在正確的時間,為 LLM 提供完成任務所需的一切資訊和工具,從而確保其可靠完成任務的工程學科。

為了深入理解這一定義,我們可以將其分解為以下幾個關鍵組成部分:

  • 設計和建構動態系統:上下文工程是一項 工程 活動,而非一種溝通技巧。它關乎系統架構,而不僅僅是巧妙的措辭。上下文本身是主 LLM 調用 之前 運行的某個系統的 輸出。這意味著工程師需要建構數據管道、記憶體模組和資訊檢索機制,這些系統在運行時動態地為 LLM 準備其「工作記憶」。
  • 正確的資訊和工具:這涵蓋了兩個方面。資訊 指的是事實、數據、知識庫中的內容,例如通過檢索增強生成(RAG)獲取的文檔片段或用戶歷史偏好。工具 則指模型可以調用的能力,如 API 介面、函數或資料庫查詢功能。為模型同時提供知識和能力,是其完成複雜任務的基礎。
  • 正確的格式、在正確的時間:資訊呈現方式和時機非常重要。在 格式 上,一份簡潔的摘要通常優於原始的數據轉儲;一個清晰的工具模式(schema)比模糊的指令更有效。在 時間 上,按需提供上下文至關重要,避免在不需要時用無關資訊干擾模型,從而導致「上下文分心」。
  • 可靠地完成任務:這是上下文工程的最終目標。其價值在於將 AI 應用從不穩定的「廉價展示品」提升為能夠創造「神奇產品」的可靠系統。通過精確管理上下文,可以顯著提高輸出的一致性,減少幻覺,並支持複雜、長週期的智能代理工作流。

提示工程與上下文工程的系統性比較

儘管上下文工程與提示工程都旨在優化 LLM 的輸出,但二者在範圍、性質和目標上存在根本區別。我們可以從系統層面進行深入比較。

  • 範圍(Scope):提示工程通常聚焦於單次交互或單個文本字串的優化。其目標是為特定問題找到最佳的表述方式。相比之下,上下文工程關注的是整個智能代理工作流的資訊生態系統,涵蓋從任務開始到結束的完整生命週期。
  • 動態性(Dynamism):提示通常是靜態的模板,可能包含一些變數佔位符。而上下文是動態生成的,它根據當前任務的具體需求,在運行時即時組裝,並隨著對話的進行而不斷演變。例如,處理一封郵件可能需要動態查詢日曆、聯絡人和過往郵件記錄。
  • 輸入構成(Input Composition):對於提示工程師而言,其核心工作是圍繞用戶的查詢來建構輸入。但對於上下文工程師來說,用戶的查詢僅僅是需要建構的龐大「上下文包」(context package)中的一個組成部分。這個包還可能包括系統指令、檢索到的文檔、工具的輸出和對話歷史等。
  • 核心類比(Analogy):如果說提示是演員在舞台上說的一句台詞,那麼上下文就是整個電影的佈景、背景故事和劇本,是它們共同賦予了這句台詞深刻的含義和背景。
维度 提示工程 (Prompt Engineering) 上下文工程 (Context Engineering)
範圍 單次交互,單個輸入字串 整個智能代理工作流,完整的資訊生態系統
性質 靜態或半靜態,基於模板 動態,即時組裝,隨任務演進
目標 引導 LLM 給出一次高品質的回答 賦能 LLM 可靠、持續地完成複雜任務
核心產物 優化的提示模板、指令集 數據管道、RAG 系統、記憶體模組、狀態管理器
核心技能 語言學、邏輯推理、指令設計 系統架構、數據工程、軟體開發
核心類比 提出一個精準的問題 為研究員建造一座資訊完備的圖書館

AI 工程的重新定義

從提示工程到上下文工程的演變,重塑了「AI 工程師」的角色。提示工程的核心在於設計完美的 輸入字串,所需技能偏向於語言學和邏輯建構。而建構能夠從資料庫、API、記憶體等多個來源動態組裝輸入字串的 系統 時,核心技能便轉向了軟體工程和系統架構。

LangChain 和 LlamaIndex 等框架因此變得流行。它們並非簡單的「提示詞助手」,而是為 上下文工程 提供支援的框架。這些工具提供了建構動態上下文組裝系統所需的架構模式,如鏈(Chains)、圖(Graphs)和代理(Agents)。

上下文工程的興起標誌著 AI 開發從一個以模型為中心的、相對小眾的領域,走向了主流的軟體工程學科。核心挑戰不再僅僅是模型本身,而是環繞模型建構的整個應用技術堆疊。這要求 AI 工程師不僅要懂得如何調用 LLM 的 API,更要具備建構和維護其所需的全堆疊基礎設施的能力。

上下文的剖析與原則

上下文窗口的剖析

Andrej Karpathy 將 LLM 比作一種新型作業系統,其中 LLM 本身是 CPU,而其上下文窗口(Context Window)則相當於計算機的 RAM(隨機存取記憶體)。上下文窗口是模型在生成回應前所能「看到」或「記住」的全部資訊,是其有限的工作記憶。上下文工程的藝術,就在於精確地管理這塊「RAM」的內容。

一個完整的「上下文包」是提供給模型的所有資訊的總和,其構成要素可以分解如下:

  • 指令(Instructions / System Prompt):這是上下文的基礎層,是一組定義模型行為的初始指令。它設定了模型的角色(Persona)、行事風格、必須遵守的規則和約束,以及最終要實現的目標。這相當於智能代理的「憲法」或操作手冊。
  • 用戶提示(User Prompt):用戶提出的直接問題或任務指令。這是觸發智能代理工作的直接輸入。
  • 對話歷史(Conversation History / Short-Term Memory):在多輪對話中,之前的交流內容為當前交互提供了直接的語境。由於上下文窗口的限制,這部分內容通常需要通過修剪或摘要的方式進行管理。
  • 長期記憶(Long-Term Memory):這是一個跨會話的持久化知識庫,記錄了從多次交互中學習到的資訊,如用戶偏好、過往專案摘要或被明確告知需要記住的事實。
  • 檢索到的資訊(Retrieved Information / RAG):為了克服 LLM 的知識截止(Knowledge Cutoff)問題並使其回答基於事實,系統會動態地從外部知識源(如文檔、資料庫、API)中獲取相關資訊。這是上下文工程中至為關鍵的技術之一。
  • 可用工具(Available Tools):這部分內容定義了 LLM 可以調用的所有函數或內建工具的模式(Schema)和描述,例如 send_email 或 query_database。它賦予模型行動的能力,而不僅僅是知識。
  • 工具輸出(Tool Outputs):當模型調用一個工具後,其返回的結果必須被重新注入到上下文中,以便模型能夠基於該結果進行下一步的推理和行動。
  • 結構化輸出模式(Structured Output Schema):通過提供一個預期的輸出格式定義(如 JSON Schema),可以引導模型生成結構化、可預測且易於程式解析的結果。

「LLM 即作業系統」框架

「LLM 即作業系統」(LLM as an Operating System)這一類比,為理解和實踐上下文管理提供了一個堅實的理論框架。

  • LLM 作 CPU,上下文窗口作 RAM:Karpathy 的這一類比,將上下文窗口定位為一個有限且寶貴的資源,即模型的工作記憶。上下文工程的核心任務,就如同作業系統管理 RAM 一樣,是高效、精確地決定哪些資訊應該在何時被載入到這個工作記憶中。

  • 內核上下文與用戶上下文:Letta 公司提出的框架進一步深化了這一類比,將上下文劃分為兩個層面,類似於傳統作業系統中的內核空間和用戶空間。

    • 內核上下文(Kernel Context):代表智能代理的受管理、可變的持久狀態。它包含了核心的記憶體塊(Memory Blocks)和檔案系統(Files),LLM 可以觀察這些內容,但只能通過受控的「系統調用」(System Calls),即特定的特權工具,來進行修改。這一層為代理提供了穩定性和結構化的狀態管理。
    • 用戶上下文(User Context):代表「用戶空間」或消息緩衝區(Message Buffer),是動態交互發生的地點。它包含用戶消息、助手回復以及對非特權的「用戶程式」工具的調用。這一層為代理提供了與外部世界交互的靈活性。
  • 系統調用與自定義工具:這一區分清晰地界定了智能代理如何與其內部狀態和外部世界進行交互。系統調用(如 memory_append、open_file)用於修改內核上下文,從而改變代理的持久狀態。而 自定義工具(如 web_search、api_call)則負責將外部資訊引入用戶上下文,供模型在當前回合使用。這個分層模型為建構複雜且狀態一致的智能代理提供了清晰的架構指導。

上下文工程的指導原則

有效的上下文工程遵循一系列核心原則,這些原則主要源自 Cognition AI 等前沿實踐者的經驗總結,旨在建構可靠、一致的智能代理系統。

  • 原則一:連續與全面的上下文(Continuous and Comprehensive Context):也被稱為「看到一切」(See Everything)的理想狀態。該原則要求,智能代理在執行每一步操作時,都應能訪問其完整的操作歷史,包括之前的用戶交互、工具調用輸出、內部思考過程(即「代理軌跡」),以及所有中間結果。這能有效防止「對話遺忘症」,確保每一個決策都是在充分知情的基礎上做出的。
  • 原則二:避免無協調的並行(Avoid Uncoordinated Parallelism):讓多個子代理或子任務在沒有一個共享且持續更新的上下文的情況下並行工作,幾乎不可避免地導致輸出不一致、目標衝突和最終的失敗。每個並行的單元都在自己的資訊孤島中運作,它們的決策無法相互感知,最終導致結果的割裂。
  • 原則三:動態與演進的上下文(Dynamic and Evolving Context):上下文並非一成不變的靜態資訊塊。它必須根據任務的進展動態地組裝和演變。這意味著系統必須具備在運行時(runtime)按需獲取或更新資訊的能力,例如從知識庫中檢索最新文檔,或在對話中持續追蹤用戶的偏好變化。
  • 原則四:完整的上下文覆蓋(Full Contextual Coverage):必須為模型提供它可能需要的所有資訊,而不僅僅是用戶最新的問題。工程師需要將提供給 LLM 的整個輸入包(包括指令、資料、歷史記錄等)都視為需要精心設計的「上下文」。不應讓模型去猜測缺失的資訊,因為這會增加幻覺和錯誤的風險。

智能代理可靠性危机的解决方案

這些原則的提出,並非純粹的理論建構,而是對早期智能代理開發實踐中「可靠性危機」的直接回應。許多早期的智能代理設計,如 Auto-GPT,傾向於採用複雜的、並行的多代理架構,其核心假設是任務分解是解決複雜問題的關鍵。實踐證明,這些系統在現實場景中表現得極其脆弱和不可靠。

深入分析其失敗根源,可以發現核心問題在於 上下文碎片化(Context Fragmentation)。在並行架構中,每個子代理都在各自的資訊孤島中運作,缺乏對其他代理工作進展和決策的全局視野。

上下文工程的原則,特別是「連續與全面的上下文」和「避免無協調的並行」,正是對這種早期架構思潮的深刻反思和修正。它們揭示了一個根本性的道理:系統的可靠性源於資訊的一致性,而不僅僅是任務的分解

因此,業界逐漸轉向所謂的「單線程解決方案」(single-threaded solution),即採用擁有統一、持續演進的上下文的線性和圖狀工作流。LangGraph 這樣的框架正是為此而生,它通過顯式的狀態管理,確保了資訊在代理的各個執行節點之間順暢流動和共享。

綜上所述,智能代理架構從複雜的並行系統向更注重上下文共享的線性系統的演進,是上下文工程原則在實踐中應用的直接結果。這門學科為建構能夠在長週期任務中穩定、可靠運行的智能代理,提供了堅實的理論基礎和架構範式。

核心策略與技術實現

上下文管理的四大支柱

為了系統地管理上下文,我們可以借鑒 LangChain 提出的一个清晰且实用的框架,该框架将上下文管理策略分为四大支柱:写入(Write)、选择(Select)、压缩(Compress)和隔离(Isolate)。这个分类法为我们提供了一个全面的技术路线图。

  • 寫入(Write):持久化上下文

    該策略的核心是將資訊保存在即時的上下文窗口之外,以供未來使用,從而建構代理的記憶能力。

    • 暫存區(Scratchpads):用於儲存會話內的短期記憶。這就像人類在解決複雜問題時使用的草稿紙,代理可以在執行任務的過程中記錄中間步驟、觀察結果或臨時想法。
    • 記憶系統(Memory Systems):用於建構跨會話的長期記憶。這使得代理能夠「記住」過去的用戶偏好、專案歷史或關鍵事實。實現技術包括「反思」(Reflection)機制,即代理自我生成記憶並在後續任務中重用,以及基於用戶交互自動生成和更新的持久化記憶庫。
  • 選擇(Select):檢索上下文

    該策略旨在在正確的時間,將正確的資訊從外部儲存中拉取到上下文窗口中。

    • 從記憶/暫存區中選擇:當代理需要回憶過去的知識時,它必須能夠有效地查詢其持久化的記憶庫或暫存區。
    • 從工具中選擇:當代理擁有大量可用工具時,一次性將所有工具的描述都放入上下文會造成干擾和資源浪費。一種高效的方法是,對工具描述本身應用 RAG 技術,根據當前任務動態檢索並提供最相關的幾個工具。研究表明,這種方法可以将工具选择的准确率提高三倍。
    • 從知識中選擇:這是檢索增強生成(RAG)的核心功能,即從外部知識庫(如文檔、資料庫)中動態獲取事實資訊,以增強模型的回答能力。
  • 壓縮(Compress):優化上下文

    該策略的目標是在保留核心資訊的前提下,減少上下文所佔用的令牌(token)數量,以適應有限的上下文窗口。

    • 摘要(Summarization):利用 LLM 自身的能力,對冗長的對話歷史、大段的文檔內容或工具的詳細輸出進行總結,提煉出關鍵資訊。這可以是遞歸的或分層的,以處理極長的信息流。
    • 修剪(Trimming):採用基於啟發式規則的方法來刪減上下文。最常見的例子是,在對話歷史過長時,簡單地移除最早的幾輪對話。
  • 隔離(Isolate):分區上下文

    該策略通過將上下文分解到不同的部分,來提高模型的專注度並管理任務的複雜性。

    • 多代理系統(Multi-agent Systems):在精心設計的系統中,可以將一個大任務分解給多個子代理,每個子代理擁有自己專屬的、隔離的上下文、工具和指令。這使得每個代理都能更專注於其狹窄的子任務。
    • 沙盒環境(Sandboxed Environments):將消耗大量令牌的操作(如程式執行、檔案處理)在一個隔離的環境中運行,只將最終的關鍵結果返回到主 LLM 的上下文中。這可以有效隔離「重型」上下文物件,保持主上下文的整潔。

高級記憶架構

記憶是建構能夠學習和適應的智能代理的關鍵。實現複雜記憶系統的架構是「寫入」和「選擇」策略的高級應用。

  • 短期記憶:短期記憶主要通過對話歷史緩衝區和暫存區來實現,其目標是維持單個任務或對話會話中的狀態一致性。例如,在一個多步驟的預訂流程中,代理需要記住用戶之前選擇的日期和目的地。

  • 長期記憶:長期記憶的目標是讓代理超越單次會話的限制,實現持久化的學習和個性化。

    • 實現技術

      • 自動記憶生成:系統可以根據用戶與代理的交互自動生成並儲存記憶。例如,如果用戶多次詢問關於某個特定主題的問題,系統可以生成一條記憶,記錄「用戶對 [主題] 感興趣」。像 ChatGPT 和 Cursor 等產品已經內建了此類機制。
      • 反思機制:代理在完成任務後,可以自我反思其行為和結果,並將學到的經驗教訓合成為新的記憶,供未來使用。
      • 對話摘要:定期對過去的對話進行摘要,並將摘要作為長期記憶的一部分儲存起來,以便在未來的交互中快速回顧關鍵資訊。
    • 結構化記憶(時間知識圖譜):這是一種時間知識圖譜架構,它不僅儲存事實,還儲存各事實之間的關係,並為每個資訊點附加時間戳。這種 **時間知識圖譜(Temporal Knowledge Graph)**能夠讓系統區分資訊的時效性,例如,用戶的地址在去年是 A,但今年更新為了 B。通過這種方式,系統可以避免使用過時的資訊,從而顯著減少上下文衝突和矛盾,提高代理在長時間跨度內的行為一致性。

檢索增強生成(RAG):上下文工程的基石

檢索增強生成(RAG)是上下文工程中用於「選擇」外部知識的核心技術。它通過將 LLM 與外部知識庫連接,極大地擴展了模型的能力。

RAG 的基礎架構

一個典型的 RAG 系統包含三個核心階段:

  1. 索引(Indexing):這是一個離線預處理階段。首先,將原始文檔(如 PDF、網頁)分割成更小的、語義完整的文本塊(Chunks)。然後,使用一個嵌入模型(Embedding Model)將每個文本塊轉換為一個高維向量。最後,將這些向量及其對應的原始文本塊儲存在一個專門的向量資料庫(Vector Database)中。
  2. 檢索(Retrieval):當用戶提出查詢時,系統首先使用相同的嵌入模型將用戶查詢也轉換為一個向量。然後,在向量資料庫中進行相似性搜尋,找出與查詢向量最接近的 N 個文本塊向量。這些文本塊被認為是與查詢最相關的內容。
  3. 生成(Generation):最後,系統將用戶的原始查詢和檢索到的 N 個相關文本塊一起組合成一個新的、內容豐富的提示,並將其提交給 LLM。LLM 基於這個增強的上下文來生成有事實依據的回答。

高級檢索與排序策略

基礎的 RAG 架構雖然有效,但在生產環境中往往需要更複雜的策略來提升檢索品質。

  • 混合搜尋(Hybrid Search):該策略結合了兩種搜尋範式:語義搜尋(基於向量)和 關鍵詞搜尋(如傳統的 BM25 算法)。語義搜尋擅長理解概念上的相似性,而關鍵詞搜尋則能確保精確匹配專有名詞或特定短語。將兩者結合,可以取長補短,獲得更全面和精準的檢索結果。

  • 上下文檢索(Contextual Retrieval):由 Anthropic 公司提出的一項創新:傳統 RAG 直接對孤立的文本塊進行嵌入,可能導致上下文資訊的丟失。上下文檢索則在嵌入之前,先使用一個 LLM 為每個文本塊生成一個簡短的摘要,描述其在 整個文檔中上下文。然後,對這個「文本塊 + 上下文摘要」的組合進行嵌入。這種富含上下文的嵌入極大地提高了檢索的準確性。

  • 重排序(Re-ranking):在檢索階段之後、生成階段之前增加一個重排序步驟。重排序模型會精細地評估每個文檔與查詢之間的相關性,從而將最關鍵的資訊排在最前面,為最終的生成模型提供一個更高品質的輸入。

RAG 與微調:一個戰略決策框架

對於 AI 架構師來說,選擇 RAG 還是微調(Fine-tuning)來定制 LLM 是一個戰略決策。這並非一個「非此即彼」的選擇,而是根據具體需求使用正確工具的問題。

  • RAG 的優勢

    • 知識更新:非常適合整合實時、動態變化的知識。當外部知識庫更新時, RAG 系統能立即獲取最新資訊,而無需重新訓練模型。
    • 減少幻覺:通過提供可驗證的事實依據, RAG 顯著降低了模型捏造事實的可能性。
    • 數據隱私:允許企業將專有或敏感數據保留在安全的內部資料庫中,只在查詢時按需檢索,避免了將數據用於模型訓練帶來的洩露風險。
    • 成本與技能:實現成本相對較低,對數據工程和基礎設施技能的要求高於對深度學習專業知識的要求。
  • 微調的優勢

    • 教授新技能/風格:最適合用於教模型一種新的行為模式、說話風格或特定領域的專業術語(如法律、醫學)。微調改變的是模型的「內在能力」,而不是它所知道的「事實」。
    • 嵌入品牌聲音:可以使模型的輸出在語氣、格式和風格上與組織的品牌形象保持高度一致。
  • 混合方法:最強大的系統往往是兩者的結合。首先,通過 微調 來讓模型掌握特定領域的語言和風格(學會「如何說」)。然後,在運行時使用 RAG 為其提供最新的事實資訊(告訴它「說什麼」)。

決策標準(需要問的問題) 優先考慮 RAG 優先考慮微調 考慮混合方案
回答是否必須包含實時/動態數據?
目標是教授新的風格或領域語言嗎?
數據隱私和安全是否至關重要? 相對次要
運行時計算資源是否受限? 否(RAG 增加運行時開銷) 是(微調增加訓練開銷) 取決於具體實現
團隊具備何種技能? 強於數據/基礎設施工程 強於機器學習/深度學習 具備兩種技能

上下文優化與過濾

即使有了強大的檢索機制,管理有限的上下文窗口並避免常見的「上下文失敗模式」仍然是一個挑戰。

上下文失敗模式

根據研究,常見的上下文失敗模式包括:

  • 上下文投毒(Context Poisoning):當幻覺或錯誤的事實被引入上下文後,會「毒化」後續的生成過程,導致模型基於錯誤的假設進行推理,產生一連串錯誤。
  • 上下文分心(Context Distraction):當上下文中充滿了大量資訊, 尤其是與核心任務不太相關的細節時,模型可能會「分心」,忽略了最初的關鍵指令。
  • 上下文混淆(Context Confusion):無關或多餘的上下文資訊可能會對模型的回答產生意想不到的負面影響,使其偏離正確的方向。
  • 上下文衝突(Context Clash):當上下文中的不同部分包含相互矛盾的資訊時,模型會感到困惑,不知道應該相信哪一部分,最終可能導致邏輯混亂或不一致的回答。

解決方案

為了應對這些失敗模式,工程師需要採用一系列優化和過濾技術。總的來說,確保進入 LLM 工作記憶(RAM)的每一條資訊都是經過精心篩選、高度相關且格式優化的。