Andrej Karpathy 又帶火了一個詞——Context Engineering。

Shopify CEO Tobi Lütke 的一條推特引發了行業對此的廣泛討論，Andrej Karpathy 轉發并表示強烈認同。

這不是一個新概念，只是業內共識的逐漸形成：決定AI應用效果的關鍵，已經不是你怎么問，而是你給 AI 喂了什么料。

提供完整且恰當的上下文往往比編寫好的提示詞更重要。

到底什么是「上下文工程」，在應用的落地開發中怎么更好使用「上下文工程」？ 我們整理了 DeepMind 工程師 Philipp Schmi、以及 LangChain 對此的討論，希望在一篇文章里介紹清楚「上下文工程」的概念以及實操落地的問題。

超 8000 人的「AI 產品市集」社群！不錯過每一款有價值的 AI 應用。

邀請從業者、開發人員和創業者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準的AI產品曝光渠道

01Karpathy「上下文工程」既是科學也是藝術

圖：Andrej Karpathy 推特內容

支持「上下文工程」而不是「提示工程」。

人們通常將提示詞（prompt）與日常使用中給 LLM 的簡短任務描述聯系起來。但在每個工業級 LLM 應用中，上下文工程（Context Engineering）是一門精妙的藝術與科學——它需要精準地為上下文窗口填充恰到好處的信息。

說它是科學，因為這項工作涉及任務描述與解釋、少量示例、檢索增強生成（RAG）、相關（可能是多模態的）數據、工具、狀態與歷史記錄、信息壓縮...提供太少或形式不當，LLM 就缺乏最優表現所需的上下文；過量或相關性不足，則會導致成本上升性能下降。做好這件事絕非易事。

而稱之為藝術，則源于對人類心理與 LLM 行為之間微妙互動的直覺把握。

除了上下文工程本身，一個 LLM 應用還必須能夠實現：

• 將問題恰到好處地分解為（control flows）；

• 恰到好處地填充上下文窗口

• 調度類型和能力都合適的 LLMs

• 處理「生成-驗證」的用戶交互（UI/UX）流程；

• 還有很多方面 - 安全護欄、防護措施、評估機制、并行處理、數據預取......

因此，上下文工程只是新興復雜軟件層中的一小部分，這些軟件將單個 LLM 調用（以及更多內容）協調成完整的 LLM 應用。「ChatGPT 包裝器」（ChatGPT wrapper）這個說法已經過時，而且大錯特錯。

在交流中，Karpathy 表示：

我并不是要造新詞。只是覺得人們使用「prompt」這個詞時，往往（錯誤地）低估了這個相當復雜的組件。你給 LLM 一個提示讓它解釋天空為什么是藍色的。但應用程序會（精心）為 LLMs 構建上下文來解決它們的定制任務。

02什么是上下文工程

要理解上下文工程，我們首先得拓寬對「上下文」的定義。它不僅僅是發給大語言模型的一句提示詞，而是模型生成回答之前所看到的一切信息。

圖：上下文工程所包含的范圍

上下文工程包括：

• 指令 / 系統提示詞：定義模型整體行為的初始指令，可以（也應該）包含示例、規則等。

• 用戶提示詞：用戶提出的即時任務或問題。

• 當前狀態或對話歷史（短期記憶）：用戶和模型此前的對話內容，展現當前交流的背景。

• 長期記憶：跨多次對話積累的持久性知識庫，比如用戶喜好、歷史項目摘要、記住的特定事實。

• 檢索的信息（RAG）：外部的、最新的信息，包括從文檔、數據庫或 API 獲取的相關內容，用于回答特定問題。

• 可用工具：模型可以調用的所有函數或內置工具定義（如檢查庫存、發送郵件等）。

• 結構化輸出：明確定義模型輸出的格式，例如 JSON 格式的對象。

03提示詞工程、上下文工程到底啥區別？

提示詞、提示詞工程、上下文工程，三者的區別是什么？

提示詞（Prompt）

提示詞很好理解，就是用戶給 AI 模型的 輸入文本，直接向模型輸入的問題或指令。 比如用戶讓 ChatGPT 總結一段文本、調用模型 API 傳入提示詞去翻譯一篇文章等。簡單理解，提示詞是一段文本，有點像代碼。

提示詞工程（Prompt Engineering）

提示詞工程是一個過程，系統化地設計、測試、優化提示詞的過程。

就像軟件工程，我們為了完成某個需求，要有一套科學的方法來幫助完成軟件開發的過程，有方法論（比如敏捷開發），要使用工具，要保證質量，不斷迭代，最終交付軟件，或者說代碼。

簡單來說，對翻譯提示詞「設計」、「測試」、「優化」的整個過程就是提示詞工程。

上下文工程（Context Engineering）

上下文工程是一門設計和構建動態系統的學科，能夠在正確的時間，以正確的格式，為大語言模型提供恰當的信息和工具，使其能夠完成任務。

上下文工程的特點包括：

• 它是個系統，而不是一句話：上下文并不僅僅是一條靜態的提示詞模板，而是在模型調用之前運行的完整系統的輸出。

• 動態生成：根據即時任務需求動態生成。例如，某個請求可能需要日歷數據，而另一個請求可能需要郵件內容或網絡搜索結果。

• 在恰當的時間提供正確的信息和工具：它的核心職責是確保模型不會遺漏關鍵細節（輸入錯誤，輸出必然錯誤）。這意味著只在需要時提供有用的知識（信息）和功能（工具）。

• 格式的重要性：信息的呈現方式至關重要。清晰簡潔的摘要好于雜亂無序的數據堆砌；明確的工具結構優于模糊的指令。

寶玉老師整理的一張圖，非常直觀地呈現了這三者之間的關系與區別。

圖：提示詞、提示詞工程與上下文工程的關系

04為什么「上下文工程」很重要？

構建真正有效的 AI Agent 的秘訣，不是取決于寫的代碼有多復雜，而是提供給 Agent 的上下文質量。

創建 Agent，真正關鍵的不是代碼或框架，而在于提供的上下文信息質量。舉個例子，假設你讓 AI 助手基于一封簡單的郵件來安排會議：

嘿，想確認一下，你明天方便快速碰一下嗎？

一個普通的Agent只有糟糕的上下文，它只看到了用戶的請求，盡管代碼完全正確——調用大語言模型并獲得了回應——但輸出卻呆板無用：

感謝您的信息。明天我可以，請問你想幾點碰面？

「神奇的」Agent則擁有豐富的上下文。它的主要任務并不是決定「怎么」回應，而是去「收集信息」，以讓大語言模型順利實現目標。在調用模型前，你需要擴展上下文，比如包括：

• 你的日歷信息（顯示明天已滿）。

• 你和發件人的歷史郵件（決定適當的隨意語氣）。

• 你的聯系人列表（識別對方是關鍵合作伙伴）。

• 可用的工具，比如發送邀請或郵件。

然后生成如下回應：

嘿，Jim！明天我的日程已經排滿了，一整天都是背靠背的會議。周四上午我有空，不知道你是否方便？我已經發了個邀請，看看是否合適。

這種效果，并不是來自更聰明的模型或更精巧的算法，而是來自提供了適合任務的正確上下文。這正是上下文工程的意義所在。Agent 的失敗不再只是模型問題，而是上下文的失敗。

05「上下文工程」的四種落地策略

Langchain 近期發布的一篇博客文章，總結了四種常見的上下文工程策略。

圖：上下文工程的一般類別

5.1寫入上下文 （Write Context）

寫入上下文，是指將信息保存到上下文窗口之外，以輔助 Agent 完成任務。

草稿板 （Scratchpads）

當人類在解決任務時，會做筆記并為未來相關的任務保留記憶。如今，Agent 也正逐步具備這些能力，通過「草稿板」做筆記，是在 Agent 執行任務期間持久化保留信息的一種方法。核心思想是將信息保存在上下文窗口之外，同時又能讓 Agent 隨時取用。

Anthropic 的多 Agent 研究員給出了一個清晰的例子：

LeadResearcher 首先會思考整個處理流程，并將計劃保存到內存中，以確保上下文的持久化，因為一旦上下文窗口超過 200,000 個 token，內容就會被截斷，而保留計劃至關重要。

草稿板可以通過幾種不同方式實現。它可以是一個僅將內容寫入文件的工具調用；也可以是運行時狀態對象中的一個字段，保持在整個會話期間保持不變。但無論是采用哪種方式，草稿板都讓 Agent 能夠保存有用信息，從而更好地完成任務。

記憶 （Memories）

草稿板幫助 Agent 在單次會話（或線程）中解決任務，但有時，Agent 需要跨越多個會話來記憶信息，這會帶來更大地助益。Reflexion 引入了在 Agent 每一輪行動后進行反思，并復用這些自我生成記憶的理念。而「生成式 Agent」（Generative Agents）則會從過往的 Agent 反饋集合中，周期性地合成記憶。

圖：LLM 可用于更新或創建記憶

這些概念已經被 ChatGPT、Cursor 和 Windsurf 等熱門產品所應用，這些產品都擁有能夠根據用戶與 Agent 的交互，自動生成可跨會話持久化的長期記憶的機制。

5.2篩選上下文 （Select Context）

篩選上下文，是指將所需信息拉入上下文窗口，來輔助 Agent 完成任務。

草稿板 （Scratchpad）

從草稿板中篩選上下文的機制，取決于草稿板的具體實現方式。如果它是一個工具，那么 Agent 只需通過工具調用便可讀取內容。如果它是 Agent 運行時狀態的一部分，那么開發者則可以在每一步選擇將狀態的哪些部分公開給 Agent。這些在為之后地后續回合中向 LLM 提供草稿板上下文提供了精細化的控制。

記憶 （Memories）

如果 Agent 具備保存記憶的能力，它們也需要能夠篩選出與當前執行任務相關的記憶。這樣做有幾個好處：Agent 可以篩選出少樣本示例（情景記憶）作為期望行為的范例；可以篩選出指令（程序性記憶）來引導自身行為；或者可以篩選出事實（語義記憶）作為與任務相關的上下文。

圖：幾種記憶類型

挑戰之一是確保篩選出來的記憶是相關的。一些主流的 Agent 僅使用一小部分固定文件，并能將它們拉入到上下文中。例如，許多編碼 Agent 使用特定文件來保存指令（「程序性」記憶），或在某些情況下保存示例（「情景」記憶）。Claude Code 使用CLAUDE.md文件，Cursor 和 Windsurf 則使用規則文件。

但是，如果 Agent 存儲了大量的記憶（例如語義記憶），包括事實或關系，篩選就更難了。ChatGPT 就是一個很好的例子，這款主流產品能夠從大量用戶專屬記憶中進行存儲和篩選。

使用嵌入（Embeddings）或知識圖譜進行記憶索引，是一種輔助篩選的常用方法。盡管如此，記憶篩選仍然充滿挑戰。在 AI Engineer World's Fair 大會上，Simon Willison 分享了一個篩選出錯的案例：ChatGPT 從記憶中獲取了他的位置信息，并意外地將其注入到一張他要求的圖片中。這種意料之外或不希望出現的記憶檢索，會讓一些用戶感覺上下文窗口「不再屬于他們自己」了！

工具 （Tools）

Agent 需要使用工具，但如果提供的工具過多，可能會不堪重負。通常是因為工具描述之間存在重疊，導致模型在選擇使用哪個工具時感到困惑。一種方法是對工具描述采用 RAG 技術，以便只檢索與任務最相關的工具。一些近期的論文表明，這種方法可以將工具選擇的準確率提升 3 倍。

知識 （Knowledge）

RAG 是一個內容豐富的話題，也可能成為上下文工程中的一個核心挑戰。編碼 Agent 是在大規模生產環境中應用 RAG 的最佳范例之一。來自 Windsurf 的聯創兼 CEO Varun Mohan 很好地概括了其中的一些挑戰：

「代碼索引 ≠ 上下文檢索，我們正在進行索引和嵌入搜索，包括對代碼進行 AST 解析，并沿著有語義意義的邊界進行分塊。隨著代碼庫規模的增長，嵌入搜索作為一種檢索啟發式方法變得不再可靠，我們必須依賴多種技術的組合，例如 grep/文件搜索、基于知識圖譜的檢索，以及一個重排序步驟，在此步驟中，上下文會按相關性進行排序。」

5.3 壓縮上下文 （Compressing Context）

壓縮上下文，指的是僅保留執行任務所必需的 token。

上下文摘要 （Context Summarization）

Agent 的交互可能長達數百輪，并使用消耗大量 token 的工具調用。摘要是應對這些挑戰的一種常見方法。如果你用過 Claude Code，應該見過這個功能的實際應用。當上下文窗口超過 95% 時，它會運行「自動壓縮」（auto-compact）功能，總結用戶與 Agent 交互的整個軌跡。這種貫穿 Agent 執行軌跡的壓縮可以采用多種策略，如遞歸或分層摘要。

圖：摘要技術可以應用的幾個環節

在 Agent 設計的特定環節加入摘要功能也可能很有用。例如，它可以用于后處理某些工具調用（如消耗大量 token 的搜索工具）。再比如，Cognition 提到在 Agent 之間進行知識傳遞時進行摘要，來減少 token 的消耗。如果需要精準捕捉特定的事件或決策，摘要可能會成為一項挑戰。Cognition 為此使用了一個精調模型，這也突顯了這一步可能需要投入的大量工作。

上下文修剪 （Context Trimming）

如果說摘要通常是利用 LLM 來提煉上下文中最相關的部分，那么修剪則通常是過濾或（如 Drew Breunig 所指出的）「裁剪」（prune）上下文。這可以采用硬編碼的啟發式規則，比如從列表中刪除較早的消息。此外，Drew 還提到了一個為問答任務訓練的上下文裁剪器「Provence」。

5.1 隔離上下文 （Isolating Context）

隔離上下文，指的是通過拆分上下文來輔助 Agent 完成任務。

多 Agent （Multi-agent）

將上下文分散到不同的子 Agent 中，是隔離上下文最主流的方法之一。OpenAI 的 Swarm 庫的動機之一是實現「關注點分離」（separation of concerns），即讓一個 Agent 團隊處理特定的子任務。每個 Agent 都擁有一套特定的工具、指令和自己的上下文窗口。

圖：將上下文分散到多個 Agent 中

Anthropic 的多 Agent 研究員也為此提供了論據：多個擁有獨立上下文的 Agent 的表現優于單個 Agent，這很大程度上是因為每個子 Agent 的上下文窗口都可以分配給一個更專注的子任務。正如其博客文章所說：

「 子 Agent 在各自的上下文窗口中并行運作，同時探索問題的不同方面。」

當然，多 Agent 也面臨挑戰，包括 token 使用量（據 Anthropic 報告，最高可達聊天模式的 15 倍）、需要精心的提示工程來規劃子 Agent 的工作，以及子 Agent 之間的協調問題。

利用環境隔離上下文 （Context Isolation with Environments）

HuggingFace 的 Deep Researcher 項目展示了另一個有趣的上下文隔離示例。大多數 Agent 使用工具調用 API，這些 API 返回 JSON 對象（工具參數），參數被傳遞給工具（如搜索 API）以獲取工具反饋（如搜索結果）。而 HuggingFace 使用的是一個 CodeAgent，它會輸出包含所需工具調用的代碼。然后，這些代碼在一個沙盒（sandbox）中運行。從工具調用中篩選出的上下文（如返回值）再被傳回給 LLM。

圖：沙盒可以將上下文與 LLM 隔離開來

這使得上下文可以在環境中與 LLM 隔離開來。Hugging Face 指出，這是一種隔離消耗大量 token 的對象的好方法：

「代碼 Agent 可以更好地處理狀態，那如果需要存儲這個圖像/音頻/或其他內容以備后用呢？沒問題，只需在你的狀態中將其賦值給一個變量，你就可以稍后使用它。」

狀態 （State）

值得一提的是，Agent 的運行時狀態對象本身也是一種隔離上下文的好方法。這可以起到與沙盒相同的作用。可以為狀態對象設計一個包含多個字段的模式（schema），上下文可以寫入這些字段中。模式中的一個字段（如消息）可以在 Agent 的每一輪交互中暴露給 LLM，但模式可以將信息隔離在其他字段中，以供更有選擇性地使用。

參考來源：

https://x.com/karpathy/status/1937902205765607626

https://www.philschmid.de/context-engineering

https://blog.langchain.com/context-engineering-for-agents/

轉載原創文章請添加微信：founderparker