繼 Vibe Coding（氛圍編程） 火了之后，Andrej Karpathy 又帶火了一個詞：Context Engineering（上下文工程）。

那么，上下文工程（Context Engineering）和提示詞工程（Prompt Engineering）又有什么關聯和區別？

提示詞工程是通過巧妙設計指令（比如：“你是 X 領域專家，按 Z 方式做 Y”），讓大模型精準理解任務。適合創意任務或一次性對話，使用對象是普通用戶。

上下文工程則更深入，是構建大模型的“心智世界”，提供豐富背景，讓大模型全面理解需求，使用對象是開發者，如下圖所示包括：大模型能看到什么（文檔、RAG、歷史對話、示例、摘要）、怎么看（結構化還是雜亂的）、何時看（動態注入、靜態固定、基于記憶）。

在上下文工程只你要考慮的是 tokens，不只是指令：系統提示詞、記憶槽、工具輸出、歷史窗口，都在其范疇內。

總之，上下文工程是 AI 智能體架構落地的關鍵新技術，下文詳細剖析之。

一、AI 智能體架構中的上下文工程剖析

AI 智能體需要上下文來執行任務。上下文工程是一門藝術和科學，旨在在 AI 智能體的每一步中，通過上下文工程策略：寫（Write）、選（Select）、壓縮（Compress）和隔離（Isolate）將上下文窗口填充到剛剛好的信息量。

1、什么是上下文工程？

正如 Andrej Karpathy 所說，大語言模型（LLM）就像一種新的操作系統。LLM 就像 CPU，而它的上下文窗口就像 RAM，作為大模型的工作記憶。就像  RAM 一樣，LLM 的上下文窗口也有容量限制，無法處理各種來源的上下文。就像操作系統會管理哪些內容可以放入 CPU 的 RAM 中一樣，我們可以將“上下文工程”視為類似的角色。Karpathy 很好地總結了這一點：

[上下文工程是]“……將上下文窗口填充到下一步所需信息的微妙藝術和科學。”

在構建 LLM 應用時，我們需要管理哪些類型的上下文？上下文工程是一個涵蓋幾種不同上下文類型的總稱：

• 指令：提示詞、記憶、少量樣本、工具描述等；
• 知識：事實、記憶等；
• 工具：工具調用的反饋。

2、AI 智能體架構中的上下文工程

今年，隨著 LLM 在推理和工具調用方面變得更好，AI 智能體的熱度急劇上升。AI 智能體會交替調用LLM 和工具，通常用于長期任務。它們利用工具反饋來決定下一步。

然而，長期任務和工具調用的累積反饋意味著 AI 智能體經常使用大量的標記（tokens）。這可能會引發許多問題：它可能會超出上下文窗口的大小，增加成本/延遲，或者降低 AI 智能體的性能。上下文過長可能導致性能問題的幾種具體方式，包括：

• 上下文污染（Context Poisoning）：當幻覺內容進入上下文時；
• 上下文干擾（Context Distraction）：當上下文壓倒了訓練內容時；
• 上下文混淆（Context Confusion）：當多余的上下文影響響應時；
• 上下文沖突（Context Clash）：當上下文中的部分內容相互矛盾時；

工具調用的上下文會在多個 AI 智能體回合中累積。鑒于此，上下文工程的重要性如下：

“上下文工程”……實際上是構建 AI 智能體的第一要務。

Anthropic 也明確指出：

AI 智能體經常進行跨越數百個回合的對話，需要謹慎的上下文管理策略。

那么，在 AI 智能體企業級落地中是如何應對這一挑戰的呢？我們將常見的 AI智能體上下文工程策略分為四類：寫、選、壓縮和隔離，下文繼續剖析。

3、上下文工程的四種策略剖析

3.1、寫上下文（Write Context）

寫上下文意味著將信息保存在上下文窗口之外，以幫助 AI 智能體執行任務，分為：便簽處理和記憶處理兩種方式。

第一、便簽（Scratchpads）

當人類解決問題時，我們會做筆記并記住事情，以便用于未來的相關任務。AI 智能體也在獲得這些能力！通過“便簽”做筆記是一種在執行任務時持久化信息的方法。其想法是將信息保存在上下文窗口之外，以便 AI 智能體可以使用。Anthropic 的多智能體研究員舉了一個清晰的例子：

主研究員首先思考方法，并將其計劃保存到內存中以持久化上下文，因為如果上下文窗口超過200,000個標記，它將被截斷，而保留計劃非常重要。

便簽（可以理解為短期記憶）可以通過幾種不同的方式實現。它可以是一個工具調用，簡單地將信息寫入文件。它也可以是運行時狀態對象中的一個字段，在會話期間持久化。無論哪種情況，便簽都允許智能代理保存有用的信息，以幫助它們完成任務。

第二、記憶（Memories）

便簽有助于 AI 智能體在給定會話（或線程）內解決任務，但有時 AI 智能體從多個會話中記住事情也會受益！可以引入了在每個 AI 智能體回合后進行反思并重用這些自動生成的記憶的方法。生成式 AI 智能體會定期從過去的 AI 智能體反饋中合成記憶。

這些概念已經被 ChatGPT、Cursor 和 Windsurf 等流行產品采用，它們都有機制根據用戶與 AI 智能體的互動自動生成長期記憶，這些記憶可以在會話之間持久化。

3.2、選上下文（Select Context）

選上下文意味著將上下文拉入上下文窗口，以幫助 AI 智能體執行任務，分為：便簽處理、記憶處理、工具處理、知識處理四種方式。

第一、便簽（Scratchpads）

從便簽中選擇上下文的機制取決于便簽的實現方式。如果是工具，則 AI 智能體可以通過工具調用來讀取它。如果是 AI 智能體的運行時狀態的一部分，則開發人員可以選擇在每一步將狀態的哪些部分暴露給 AI 智能體。這為在后續回合中將便簽上下文暴露給 LLM 提供了細粒度的控制。

第二、記憶（Memories）

如果 AI 智能體能夠保存記憶，它們也需要能夠選擇與它們正在執行的任務相關的記憶。這可能有幾個原因。AI 智能體可能會選擇少量樣本（情景記憶 episodic memories）作為期望行為的示例，指令（程序記憶 procedural memories）來引導行為，或者事實（語義記憶  semantic memories）作為任務相關的上下文。

一個挑戰是確保選擇了相關記憶。一些流行的 AI 智能體簡單地使用一組狹窄的文件，這些文件總是被拉入上下文。比如：許多代碼 AI 智能體使用特定文件來保存指令（“程序”記憶），或者在某些情況下，示例（“情景”記憶）。Claude Code 使用 CLAUDE.md。Cursor 和 Windsurf 使用規則文件。

但是，如果 AI 智能體存儲了大量事實和/或關系（比如：語義記憶），選擇就更難了。ChatGPT 是一個很好的例子，它存儲并從大量用戶特定的記憶中選擇。嵌入和/或知識圖譜通常用于記憶索引，以協助選擇。然而，記憶選擇仍然是一個挑戰。在 AIEngineer 世界博覽會上，Simon Willison 分享了一個選擇失敗的例子：ChatGPT 從記憶中獲取了他的位置，并意外地將其注入到請求的圖像中。這種意外或不期望的記憶檢索可能會讓一些用戶覺得上下文窗口“不再屬于他們”！

第三、工具（Tools）

AI 智能體使用工具，但如果提供過多工具，它們可能會不堪重負。這通常是因為工具描述重疊，導致大模型對使用哪個工具感到困惑。一種方法《???RAG-MCP 新架構設計解決大模型提示詞膨脹的工具選擇問題??》是將 RAG （檢索增強生成）應用于工具描述，以便只為任務獲取最相關的工具。一些最近的論文表明，這可以將工具選擇的準確性提高3倍。

第四、知識（Knowledge）

RAG 是一個豐富的話題，它可能是一個核心的上下文工程挑戰。代碼 AI 智能體是大規模生產中 RAG 的最佳例子之一。Windsurf 的 Varun 很好地捕捉了其中的一些挑戰：

索引代碼≠上下文檢索……[我們正在做索引和嵌入搜索……[通過] AST 解析代碼并在語義上有意義的邊界進行分塊……隨著代碼庫規模的增大，嵌入搜索作為檢索啟發式方法變得不可靠……我們必須依賴于多種技術的組合，比如：grep/文件搜索、基于知識圖譜的檢索，以及……一個重新排序步驟，其中[上下文]按相關性順序排列。

在 LangGraph AI 智能體的每個節點（步驟）中，你可以獲取狀態。這讓你可以精細控制在 AI 智能體的每一步中向 LLM 展示哪些上下文。

此外，LangGraph 的長期記憶在每個節點中都是可訪問的，并支持各種類型的檢索（比如：獲取文件以及基于嵌入的對記憶集合的檢索）。

3.3、壓縮上下文（Compressing Context）

壓縮上下文涉及僅保留執行任務所需的 tokens，分為：上下文摘要、上下文修剪兩種方式。

第一、上下文摘要（Context Summarization）

AI 智能體的交互可能跨越數百個回合，并使用 token 密集型的工具調用。摘要是管理這些挑戰的一種常見方法。如果你使用過 Claude Code，你已經看到了它的實際應用。Claude Code 在你超過上下文窗口的95%后運行“自動壓縮”，它將總結用戶與 AI 智能體的完整軌跡。這種跨越 AI 智能體軌跡的壓縮可以使用遞歸或分層總結等各種策略。

摘要是 AI 智能體設計的一個關鍵技術。它可以用于后處理某些工具調用（比如：token 密集型搜索工具）。作為第二個例子：在 AI 智能體與 AI 智能體的邊界進行總結，以減少知識傳遞期間的 tokens。如果需要捕獲特定事件或決策，摘要可能會是一個挑戰。可以使用了一個微調模型來完成這一步，這突顯了這一步驟可能需要多少工作。

第二、上下文修剪（Context Trimming）

與摘要通常使用 LLM 提煉最相關的上下文片段不同，修剪通常可以過濾或者可以使用硬編碼的啟發式方法，比如：從列表中移除較舊的消息，上下文修剪往往使用規則，相對比較簡單和好落地。

3.4、隔離上下文（Isolating Context）

隔離上下文涉及將其拆分，以幫助 AI 智能體執行任務，分為：多 AI 智能體、使用環境隔離上下文、狀態等三種方式。

第一、多 AI 智能體（Multi-agent）

隔離上下文的最流行方法之一是將其拆分到子 AI 智能體中。OpenAI Swarm 庫的一個動機是分離關注點，一個 AI 智能體團隊可以處理特定的子任務。每個 AI 智能體都有特定的工具集、指令和自己的上下文窗口。

Anthropic 的多智能體研究員為這種方法提供了依據：具有隔離上下文的多個 AI 智能體通常優于單個 AI 智能體，主要是因為每個子 AI 智能體的上下文窗口可以分配給更狹窄的子任務。正如博客所說：

[子 AI 智能體]并行運行，每個 AI 智能體都有自己的上下文窗口，同時探索問題的不同方面。

然而，多 AI 智能體的挑戰包括 token 使用（比如：Anthropic 報告的比聊天多15倍的 tokens）、需要精心的提示詞工程來規劃子 AI 智能體的工作，以及子 AI 智能體的協調。

第二、使用環境隔離上下文（Context Isolation with Environments）

HuggingFace 的深度研究者展示了另一個有趣的上下文隔離例子。大多數 AI 智能體使用工具調用 API，這些 API 返回 JSON 對象（工具參數），可以傳遞給工具（比如：搜索 API）以獲取工具反饋（比如：搜索結果）。HuggingFace 使用了一個 CodeAgent，它輸出包含所需工具調用的內容。然后代碼在沙箱中運行。從工具調用中選擇的上下文（比如：返回值）然后被傳遞回 LLM。

沙箱可以將上下文從 LLM 中隔離出來。這允許上下文在環境中被隔離。Hugging Face 指出，這是一種隔離 token 密集型對象的好方法：

[代碼 AI 智能體允許]更好地處理狀態……需要稍后使用這個圖像/音頻/其他嗎？沒問題，只需將其作為變量分配到你的狀態中，你就可以[稍后使用它]。

第三、狀態（State）

值得注意的是，AI 智能體的運行時狀態對象（State Object）也可以是一個很好的上下文隔離方式。它可以起到沙箱的作用。狀態對象可以設計成具有可以寫入上下文的字段的模式。模式的一個字段（例如，消息）可以在 AI 智能體的每個回合中暴露給 LLM，但模式可以將其他字段中的信息隔離起來，以便更有選擇性地使用。

上下文工程正在成為一種 AI 智能體構建者應該努力掌握的關鍵技術。在這里，我們涵蓋了一些在當今許多流行 AI 智能體中看到的常見模式：

• 寫上下文：將上下文保存在上下文窗口之外，以幫助 AI 智能體執行任務。
• 選上下文：將上下文拉入上下文窗口，以幫助 AI 智能體執行任務。
• 壓縮上下文：僅保留執行任務所需的 tokens。
• 隔離上下文：將其拆分，以幫助 AI 智能體執行任務。

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