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

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

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

一、什么是上下文工程？

上下文工程是指設(shè)計相關(guān)系統(tǒng)的實踐，該系統(tǒng)能決定AI模型在生成響應(yīng)前應(yīng)獲取哪些信息。

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

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

圖片

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

? 設(shè)定行為與規(guī)則的系統(tǒng)指令

? 對話歷史與用戶偏好

? 從文檔或數(shù)據(jù)庫中檢索到的信息

? 可用工具及其說明

? 結(jié)構(gòu)化輸出格式與模式

? 實時數(shù)據(jù)與外部API響應(yīng)

主要挑戰(zhàn)在于，要在上下文窗口的限制范圍內(nèi)運作，同時長期維持連貫的對話。你的系統(tǒng)需要判斷每個請求最相關(guān)的信息是什么，這通常意味著要構(gòu)建檢索系統(tǒng)，以便在需要時找到恰當(dāng)?shù)募?xì)節(jié)。

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

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

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

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

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

大多數(shù)AI應(yīng)用會同時運用提示工程與上下文工程。在上下文工程系統(tǒng)中，你仍需編寫優(yōu)質(zhì)的提示詞，不同之處在于，這些提示詞如今會與經(jīng)過精心管理的背景信息協(xié)同工作，而非每次都從零開始。

三、實際應(yīng)用中的上下文工程

當(dāng)你開始構(gòu)建需要處理復(fù)雜、互聯(lián)信息的AI應(yīng)用時，上下文工程便從理論走向?qū)嵺`。以客服機器人為例，它需要訪問過往支持工單、查詢賬戶狀態(tài)、參考產(chǎn)品文檔，同時還要保持有幫助的對話語氣。在這種場景下，傳統(tǒng)提示工程會失效，而上下文工程則變得必不可少。

1. 檢索增強生成（RAG）系統(tǒng)

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

RAG系統(tǒng)運用先進(jìn)的上下文工程技巧，更高效地組織和呈現(xiàn)信息。它們會將文檔拆分為有意義的片段，按相關(guān)性對信息進(jìn)行排序，并將最有用的細(xì)節(jié)納入令牌（token）限制范圍內(nèi)。

在RAG出現(xiàn)之前，若想讓AI回答關(guān)于公司內(nèi)部文檔的問題，你必須重新訓(xùn)練或微調(diào)整個模型。而RAG通過構(gòu)建能檢索文檔、找到相關(guān)片段，并將這些片段與你的問題一同納入上下文窗口的系統(tǒng)，改變了這一局面。

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

2. AI智能體（AI Agents）

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

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

AI智能體簡介

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

3. AI編程助手

AI編程助手（如Cursor或Windsurf）是上下文工程最先進(jìn)的應(yīng)用之一，因為它們在處理高度結(jié)構(gòu)化、互聯(lián)信息的同時，融合了RAG和智能體的原理。

這些系統(tǒng)不僅需要理解單個文件，還需掌握整個項目架構(gòu)、模塊間的依賴關(guān)系以及整個代碼庫中的編碼模式。

當(dāng)你要求編程助手重構(gòu)一個函數(shù)時，它需要了解該函數(shù)的調(diào)用位置、期望的數(shù)據(jù)類型，以及修改可能對項目其他部分產(chǎn)生的影響等上下文信息。

此時上下文工程變得至關(guān)重要，因為代碼之間的關(guān)聯(lián)跨越多個文件，甚至多個代碼倉庫。一個優(yōu)秀的編程助手會持續(xù)維護與項目結(jié)構(gòu)、你最近的修改、你的編碼風(fēng)格以及所使用框架相關(guān)的上下文信息。

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

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

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

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

1. 上下文污染（Context Poisoning）

當(dāng)幻覺信息或錯誤信息進(jìn)入AI系統(tǒng)的上下文，并在后續(xù)響應(yīng)中被反復(fù)引用時，就會發(fā)生上下文污染。DeepMind團隊在構(gòu)建一個玩《寶可夢》（Pokémon）的智能體時，在其Gemini 2.5技術(shù)報告中發(fā)現(xiàn)了這一問題。當(dāng)該智能體有時對游戲狀態(tài)產(chǎn)生幻覺時，這些虛假信息會污染其上下文中的“目標(biāo)”部分，導(dǎo)致智能體制定無意義的策略，并在長時間內(nèi)追求不可能實現(xiàn)的目標(biāo)。

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

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

2. 上下文干擾（Context Distraction）

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

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

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

3. 上下文混淆（Context Confusion）

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

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

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

4. 上下文沖突（Context Clash）

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

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

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

五、結(jié)論

上下文工程代表了AI發(fā)展的下一階段，在這一階段，重點從編寫完美提示詞轉(zhuǎn)向構(gòu)建能長期管理信息流動的系統(tǒng)。能否在多次互動中維持相關(guān)上下文，決定了你的AI給人的感覺是智能的，還是僅僅能給出優(yōu)質(zhì)的一次性響應(yīng)。

本指南涵蓋的技術(shù)——從RAG系統(tǒng)到上下文驗證與工具管理——已被應(yīng)用于服務(wù)數(shù)百萬用戶的生產(chǎn)級系統(tǒng)中。

如果你正在構(gòu)建的系統(tǒng)比簡單的內(nèi)容生成器更復(fù)雜，那么你很可能需要運用上下文工程技術(shù)。好消息是，你可以從基礎(chǔ)的RAG實現(xiàn)入手，從小規(guī)模開始，然后隨著需求的增長，逐步添加更復(fù)雜的記憶管理和工具管理功能。

六、常見問題（FAQs）

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

當(dāng)你的AI需要在對話之間記住信息、處理多個信息來源，或維持長期運行的任務(wù)時，就應(yīng)開始使用上下文工程。如果你正在構(gòu)建的系統(tǒng)比簡單的內(nèi)容生成器更復(fù)雜，那么你很可能需要這些技術(shù)。

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

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

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

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

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

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

參考資料

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