或許你已是一名AI應用提示工程高手，但隨著對話的推進，你的聊天機器人常常會忘記你最初且最重要的指令內容，你的代碼助手會丟失項目架構的線索，而你的檢索增強生成（RAG）工具無法在復雜文檔與不同領域間建立信息關聯。

隨著AI應用場景日益復雜，編寫精妙的提示詞只是更大挑戰中的一小部分——這個挑戰就是上下文工程。

在本指南中，我將闡釋什么是上下文工程、它如何運作、何時應替代常規提示工程使用它，以及能讓AI系統更智能、更具上下文感知能力的實用技巧。

一、什么是上下文工程？

上下文工程是指設計相關系統的實踐，該系統能決定AI模型在生成響應前應獲取哪些信息。

盡管這個術語是新興的，但上下文工程背后的原理早已存在。這種新的抽象概念使我們能夠思考AI系統信息流入與流出設計中一個核心且始終存在的問題。

不同于為單個請求編寫完美提示詞，上下文工程旨在構建能從多個來源收集相關細節，并在模型的上下文窗口內對這些細節進行整理的系統。這意味著你的系統會整合對話歷史、用戶數據、外部文檔和可用工具，然后對這些信息進行格式化處理，以便模型能夠利用它們。

這種方法需要管理構成完整上下文的多種不同類型信息，包括：

? 設定行為與規則的系統指令

? 對話歷史與用戶偏好

? 從文檔或數據庫中檢索到的信息

? 可用工具及其說明

? 結構化輸出格式與模式

? 實時數據與外部API響應

主要挑戰在于，要在上下文窗口的限制范圍內運作，同時長期維持連貫的對話。你的系統需要判斷每個請求最相關的信息是什么，這通常意味著要構建檢索系統，以便在需要時找到恰當的細節。

這涉及構建記憶系統，該系統既要跟蹤短期對話流程，也要記錄長期用戶偏好，同時還需刪除過時信息，為當前需求騰出空間。

當不同類型的上下文協同作用，構建出更智能、更具感知力的AI系統時，上下文工程的真正價值便得以體現。當你的AI助手能夠同時參考過往對話、訪問你的日程表并理解你的溝通風格時，互動不再顯得重復，反而會讓你感覺自己在與一個“記得你”的對象協作。

二、上下文工程與提示工程的對比

如果你讓ChatGPT“寫一封專業郵件”，這屬于提示工程——你在為單個任務編寫指令。但如果你正在構建一個客服機器人，它需要記住過往工單、訪問用戶賬戶詳情，并在多次互動中維持對話歷史，那么這就屬于上下文工程。

安德烈·卡帕西（Andrej Karpathy）對此有精辟的解釋：“人們通常將提示詞與日常使用大語言模型（LLM）時給出的簡短任務描述聯系在一起。但在所有工業級LLM應用中，上下文工程是一門精妙的技藝與科學，它旨在為上下文窗口填充下一步所需的恰好合適的信息。”

大多數AI應用會同時運用提示工程與上下文工程。在上下文工程系統中，你仍需編寫優質的提示詞，不同之處在于，這些提示詞如今會與經過精心管理的背景信息協同工作，而非每次都從零開始。

三、實際應用中的上下文工程

當你開始構建需要處理復雜、互聯信息的AI應用時，上下文工程便從理論走向實踐。以客服機器人為例，它需要訪問過往支持工單、查詢賬戶狀態、參考產品文檔，同時還要保持有幫助的對話語氣。在這種場景下，傳統提示工程會失效，而上下文工程則變得必不可少。

1. 檢索增強生成（RAG）系統

可以說，上下文工程起源于檢索增強生成（RAG）系統。RAG是最早能讓大語言模型（LLM）接觸到其原始訓練數據之外信息的技術之一。

RAG系統運用先進的上下文工程技巧，更高效地組織和呈現信息。它們會將文檔拆分為有意義的片段，按相關性對信息進行排序，并將最有用的細節納入令牌（token）限制范圍內。

在RAG出現之前，若想讓AI回答關于公司內部文檔的問題，你必須重新訓練或微調整個模型。而RAG通過構建能檢索文檔、找到相關片段，并將這些片段與你的問題一同納入上下文窗口的系統，改變了這一局面。

這意味著LLM能夠突然分析多個文檔和來源，回答那些通常需要人類閱讀數百頁內容才能解答的復雜問題。

2. AI智能體（AI Agents）

RAG系統為AI獲取外部信息打開了大門，而AI智能體則更進一步，使上下文具備動態性和響應性。智能體不再只是檢索靜態文檔，而是會在對話過程中使用外部工具。

AI會判斷哪種工具最適合解決當前問題。一個智能體可以開啟對話，意識到需要最新股票數據后，調用金融API，然后利用這些實時信息繼續對話。

AI智能體簡介

LLM令牌成本的降低也使多智能體系統成為可能。你無需將所有內容硬塞進單個模型的上下文窗口，而是可以設置專門的智能體來處理問題的不同方面，并通過A2A或MCP等協議在它們之間共享信息。

3. AI編程助手

AI編程助手（如Cursor或Windsurf）是上下文工程最先進的應用之一，因為它們在處理高度結構化、互聯信息的同時，融合了RAG和智能體的原理。

這些系統不僅需要理解單個文件，還需掌握整個項目架構、模塊間的依賴關系以及整個代碼庫中的編碼模式。

當你要求編程助手重構一個函數時，它需要了解該函數的調用位置、期望的數據類型，以及修改可能對項目其他部分產生的影響等上下文信息。

此時上下文工程變得至關重要，因為代碼之間的關聯跨越多個文件，甚至多個代碼倉庫。一個優秀的編程助手會持續維護與項目結構、你最近的修改、你的編碼風格以及所使用框架相關的上下文信息。

這就是為什么像Cursor這樣的工具在項目中使用時間越長，效果越好。它們會逐步積累關于你特定代碼庫的上下文信息，并能根據你的模式和偏好提供更相關的建議。

四、上下文失效及緩解技巧

在閱讀本文的過程中，你可能會認為上下文工程是不必要的，或者隨著前沿模型的上下文窗口不斷擴大，在不久的將來會變得不必要。這種假設很自然，因為如果上下文窗口足夠大，你似乎可以將所有內容（工具、文檔、指令等）都塞進提示詞中，然后讓模型處理剩下的事情。

然而，德魯·布洛伊尼格（Drew Breunig）撰寫的這篇出色文章指出，即便模型支持100萬令牌的上下文窗口，上下文仍會以四種意想不到的方式失控。在本節中，我將簡要介紹德魯·布洛伊尼格提出的這些問題，以及能解決這些問題的上下文工程模式——強烈建議你閱讀布洛伊尼格的文章以獲取更多細節。

1. 上下文污染（Context Poisoning）

當幻覺信息或錯誤信息進入AI系統的上下文，并在后續響應中被反復引用時，就會發生上下文污染。DeepMind團隊在構建一個玩《寶可夢》（Pokémon）的智能體時，在其Gemini 2.5技術報告中發現了這一問題。當該智能體有時對游戲狀態產生幻覺時，這些虛假信息會污染其上下文中的“目標”部分，導致智能體制定無意義的策略，并在長時間內追求不可能實現的目標。

在信息不斷累積的智能體工作流程中，這個問題會變得非常嚴重。一旦被污染的上下文形成，修復起來可能需要很長時間，因為模型會持續將虛假信息當作真實信息來引用。

最佳解決方案是上下文驗證與隔離。你可以將不同類型的上下文隔離在單獨的線程中，并在信息被添加到長期記憶前對其進行驗證。上下文隔離指的是，當檢測到潛在污染時，開啟新的線程，從而防止不良信息擴散到未來的互動中。

2. 上下文干擾（Context Distraction）

當上下文規模擴大到一定程度，導致模型過度關注累積的歷史信息，而不再運用訓練期間學到的知識時，就會發生上下文干擾。玩《寶可夢》的Gemini智能體就體現了這一點——當上下文規模超過10萬個令牌后，該智能體開始重復其龐大歷史記錄中的行為，而非制定新策略。

Databricks的一項研究（非常有趣的研究，絕對值得一讀）發現，對于Llama 3.1 405B模型，當上下文規模達到約3.2萬個令牌時，模型的準確性就開始下降，而更小的模型會更早達到性能極限。這意味著，遠在上下文窗口實際填滿之前，模型就已經開始出錯，這不禁讓人質疑超大上下文窗口在復雜推理任務中的實際價值。

最佳方法是上下文總結。不要讓上下文無限擴大，而是可以將累積的信息壓縮成更簡短的摘要，保留重要細節的同時刪除冗余歷史。當你遇到干擾上限時，這種方法會很有幫助——你可以總結到目前為止的對話，在保持一致性的前提下重新開始。

3. 上下文混淆（Context Confusion）

當你在上下文中包含額外信息（即便這些信息與當前任務無關），而模型卻利用這些信息生成不良響應時，就會發生上下文混淆。伯克利函數調用排行榜（Berkeley Function-Calling Leaderboard）的數據證明了這一點——當為所有模型提供不止一個工具時，它們的性能都會下降，而且模型有時會調用與任務無關的工具。

模型越小、工具越多，這個問題就越嚴重。最近的一項研究發現，當為量化后的Llama 3.1 8B模型提供全部46個可用工具時，即便上下文規模遠在1.6萬令牌的窗口限制內，該模型在Geo Engine基準測試中仍以失敗告終。但當研究人員只為該模型提供19個工具時，它的表現卻十分良好。

解決方案是利用RAG技術進行工具加載管理。甘甜甜（Tiantian Gan）和孫啟堯（Qiyao Sun）的研究表明，將RAG應用于工具說明能顯著提升性能。通過將工具說明存儲在向量數據庫中，你可以為每個任務只選擇最相關的工具。他們的研究發現，將工具選擇數量控制在30個以內，工具選擇的準確率能提升兩倍（即達到原來的三倍），且提示詞長度也會大幅縮短。

4. 上下文沖突（Context Clash）

當你在上下文中收集的信息和工具與已存在的其他信息直接沖突時，就會發生上下文沖突。微軟（Microsoft）和Salesforce聯合開展的一項研究證明了這一點：研究人員將基準測試提示詞的信息“分片”到多個對話輪次中提供，而非一次性給出所有信息。結果十分顯著——模型的平均性能下降了39%，其中OpenAI的O3模型性能從98.1降至64.1。

產生這個問題的原因是，當信息分階段輸入時，整合后的上下文中會包含模型在獲取全部信息前對問題做出的初步回答嘗試。這些不正確的初步回答會留在上下文中，并在模型生成最終響應時對其產生影響。

最佳解決方案是上下文修剪與卸載。上下文修剪指的是，隨著新細節的輸入，刪除過時或沖突的信息。上下文卸載（如Anthropic的“思考”（Think）工具）為模型提供了一個獨立的工作空間來處理信息，而不會占用主上下文的空間。這種“草稿本”式的方法通過防止內部矛盾干擾推理，在專門的智能體基準測試中能將性能提升高達54%。

五、結論

上下文工程代表了AI發展的下一階段，在這一階段，重點從編寫完美提示詞轉向構建能長期管理信息流動的系統。能否在多次互動中維持相關上下文，決定了你的AI給人的感覺是智能的，還是僅僅能給出優質的一次性響應。

本指南涵蓋的技術——從RAG系統到上下文驗證與工具管理——已被應用于服務數百萬用戶的生產級系統中。

如果你正在構建的系統比簡單的內容生成器更復雜，那么你很可能需要運用上下文工程技術。好消息是，你可以從基礎的RAG實現入手，從小規模開始，然后隨著需求的增長，逐步添加更復雜的記憶管理和工具管理功能。

六、常見問題（FAQs）

1. 何時應開始使用上下文工程而非僅依賴提示詞？

當你的AI需要在對話之間記住信息、處理多個信息來源，或維持長期運行的任務時，就應開始使用上下文工程。如果你正在構建的系統比簡單的內容生成器更復雜，那么你很可能需要這些技術。

2. 上下文工程與提示工程的主要區別是什么？

提示工程專注于為單個任務編寫指令，而上下文工程則旨在設計能跨多個互動管理信息流動的系統。上下文工程構建記憶與檢索系統，而提示工程則編寫單個請求的提示詞。

3. 能否用更大的上下文窗口替代上下文工程？

更大的上下文窗口無法解決核心問題。研究表明，即便使用百萬令牌規模的上下文窗口，由于上下文干擾和混淆，模型性能在約3.2萬個令牌時就會開始下降。無論上下文窗口規模多大，你仍需運用總結、修剪和智能信息選擇等技術。

4. 為什么為AI模型提供更多工具或信息后，其性能會下降？

這被稱為上下文混淆——模型會被無關信息干擾，并可能使用與任務不匹配的工具。解決方案是工具加載管理：利用RAG技術為每個特定任務只選擇最相關的工具，并將選擇的工具數量控制在30個以內。

參考資料

? Context Engineering: A Guide With Examples, Bex Tuychiev, https://www.datacamp.com/blog/context-engineering

本文轉載自??旺知識??，作者：旺知識