這兩年在AI圈子里，真的是新名詞、新概念、新模型層出不窮，貌似隔段時間不出現(xiàn)一個新詞感覺整個行業(yè)都退步了一樣，大家都還在學(xué)習(xí)怎么使用好Prompt Engineering（提示詞工程）的時候，這不Context Engineering（上下文工程）這個新詞就出來了。

這篇內(nèi)容來分享一下關(guān)于Context Engineering（上下文工程）這個新詞的介紹、提示詞工程和上下文工程的區(qū)別、以及二者在實際工作中的作用是什么，畢竟，現(xiàn)在AI圈子里面的新東西還是要跟上節(jié)奏學(xué)習(xí)的。

首先還是要先說一下這個背景，也就是為什么會提出一個Context Engineering（上下文工程）概念，以及它所解決的問題是啥。

我們其實還是要回到AI應(yīng)用場景中來，對于AI Agents（AI 智能體）來說，簡單的可以認(rèn)為它是由多個工作流編排而生成的，而工作流編排中可能會設(shè)計到非常多環(huán)節(jié)，我們可以通過下圖來理解（基于n8n來構(gòu)建的Agent）。

圖片

這種流程需要管理構(gòu)成完整上下文的不同類型的信息：

• 系統(tǒng)指令，用于設(shè)定行為和規(guī)則
• 對話歷史記錄和用戶偏好
• 從文檔或數(shù)據(jù)庫中檢索信息
• 可用的工具及其定義
• 結(jié)構(gòu)化輸出格式和模式
• 實時數(shù)據(jù)與外部 API 響應(yīng)

對應(yīng)的技術(shù)架構(gòu)示意圖如下：

如果想讓 AI Agent 做某件事，我們需要在不恰當(dāng)?shù)臅r機以不恰當(dāng)?shù)母袷教峁┱_的上下文。

那其實就是上下文工程發(fā)揮作用的地方。

這不僅僅是與 LLM 對話；它還關(guān)于設(shè)置圍繞它的整個環(huán)境，以便它能夠做出好的決策。

實際操作中是這樣的：

1. 用戶輸入：他們正在詢問什么

2. 聊天歷史：AI 具有記憶

3. 用戶數(shù)據(jù)：偏好設(shè)置、歷史行為、個性化

4. RAG 上下文：從文檔、網(wǎng)站和向量數(shù)據(jù)庫中提取

5. Tool Function：API、搜索、計算器，需要什么就有什么

6.  理由：Agent可以規(guī)劃、反思和適應(yīng)

關(guān)于短期記憶（Short-Term Memory）和長期記憶（Long-Term Memory）。

• 短期記憶 ： 它主要是在當(dāng)前的上下文窗口中
• 長期記憶 ：存儲在獨立的向量數(shù)據(jù)庫中

對于大模型來說，提供給它完整結(jié)構(gòu)化的的信息（上下文內(nèi)容）比一個固定帶有話術(shù)/措辭的內(nèi)容（提示詞）要重要，因為模型首先要先完整的理解這些信息，才能給出準(zhǔn)備的答復(fù)，而完整的信息并不是一個簡單的提示詞，還包含了過去我們所溝通的歷史信息，以及前期所設(shè)定的內(nèi)容范圍。

所以，很多時候，模型返回的信息不準(zhǔn)確，通常不是模型的問題，而是我們給模型輸入的內(nèi)容缺少前后背景信息。

提示詞是起點，上下文就是系統(tǒng)。

上下文工程與提示詞工程的區(qū)別是什么？

提示詞工程簡單來說用于單次窗口對話，而對于復(fù)雜、系統(tǒng)化的工程來說，它不僅僅是一個單次對話那么簡單，而是要包含所有前面的對話內(nèi)容、內(nèi)置的提示詞信息等等

在上下文工程里面也是包含了提示詞內(nèi)容，可以說提示詞工程是上下文工程其中的一個子集，比如：

我們讓 ChatGPT “寫一封專業(yè)的電子郵件”，那這個就是一個提示詞，我們是在為單個任務(wù)編寫指令，但如果你正在構(gòu)建一個需要記住之前工單、訪問用戶賬戶詳細(xì)信息并在多次交互中保持對話歷史記錄的客戶服務(wù)機器人，那就是上下文工程。

上下文工程是構(gòu)建動態(tài)系統(tǒng)，以在正確的格式中提供正確的信息和工具，使得 LLM 能夠合理地完成任務(wù)。

大部分情況下，當(dāng)Agent表現(xiàn)不可靠時，根本原因在于適當(dāng)?shù)纳舷挛摹⒅噶詈凸ぞ邲]有傳達(dá)給模型。

與此同時，LLM 應(yīng)用正從單一提示詞模式發(fā)展到更復(fù)雜、動態(tài)的 AI Agent系統(tǒng)，因此，上下文工程正成為 AI 工程師可以發(fā)展的 最重要技能 

所以，在很多公司招聘中，除了提示詞工程時，還會有上文下工程師，這也是一項職業(yè)技能。

大多數(shù) AI 應(yīng)用都同時使用提示工程和上下文工程，在上下文工程系統(tǒng)中，我們其實仍然需要精心編寫的提示，而區(qū)別在于，這些提示現(xiàn)在與經(jīng)過仔細(xì)編排的前提和背景信息一起運行，而不是每次都從頭開始。

上下文工程在應(yīng)用中的實踐

當(dāng)我們開始構(gòu)建需要處理復(fù)雜、相互關(guān)聯(lián)信息的 AI 應(yīng)用時，上下文工程便從理論走向現(xiàn)實構(gòu)建 AI 應(yīng)用考慮一個需要支持內(nèi)部業(yè)務(wù)系統(tǒng)、當(dāng)前信息處理狀態(tài)，并參考產(chǎn)品文檔的客戶服務(wù)機器人，同時還要保持友好的對話語氣。這就是傳統(tǒng)提示方法失效而上下文工程變得必要的地方。

1. RAG 系統(tǒng)

上下文工程可以說始于檢索增強生成 (RAG) 系統(tǒng)。RAG 是最早讓 LLMs 接觸到其原始訓(xùn)練數(shù)據(jù)之外信息的技術(shù)之一。

RAG 系統(tǒng)使用先進的上下文工程技術(shù)來更有效地組織和呈現(xiàn)信息。它們將文檔分解為有意義的片段，按相關(guān)性對信息進行排序，并在令牌限制內(nèi)包含最實用的細(xì)節(jié)。

在 RAG 之前，如果你想讓 AI 回答關(guān)于你公司內(nèi)部文件的問題，你必須重新訓(xùn)練或微調(diào)整個模型。RAG 通過構(gòu)建能夠搜索你的文件、找到相關(guān)片段，并將它們與你的問題一起包含在上下文窗口中，改變了這一點。

這意味著 LLMs 突然能夠分析多個文檔和來源，以回答通常需要人類閱讀數(shù)百頁才能回答的復(fù)雜問題。

2. AI Agent

RAG 系統(tǒng)為外部信息打開了大門，但 AI 代理通過使上下文動態(tài)和響應(yīng)式，將這一點進一步推進。代理在對話過程中使用外部工具，而不僅僅是檢索靜態(tài)文檔。

AI 決定哪個工具最能解決當(dāng)前問題。一個代理可以開始對話，意識到需要當(dāng)前的股票數(shù)據(jù)，調(diào)用金融 API，然后使用這些最新信息繼續(xù)對話。

3. AI 編程助手

例如如 Cursor 代表了上下文工程最先進的應(yīng)用之一，因為AI編程助手處理高度結(jié)構(gòu)化、相互關(guān)聯(lián)的信息時，結(jié)合了 RAG 和AI Agent的技術(shù)。

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

當(dāng)你要求代碼助手重構(gòu)一個函數(shù)時，它需要了解該函數(shù)的使用位置、期望的數(shù)據(jù)類型以及更改可能如何影響項目的其他部分。

在此，上下文工程變得至關(guān)重要，因為代碼具有跨越多個文件甚至多個存儲庫的關(guān)系。一個好的編碼助手會維護關(guān)于你的項目結(jié)構(gòu)、你最近所做的更改、你的編碼風(fēng)格以及你正在使用的框架的上下文信息。

上下文工程可能存在的問題

好了，上面其實基本講清楚了關(guān)于上下文工程相關(guān)的內(nèi)容，以及在實際應(yīng)用場景中是怎么體現(xiàn)出上下文的作用的，那反過來說，這東西難道就沒有其它問題嗎？畢竟，如果我們要做一個很復(fù)雜的、超長鏈路的Agent服務(wù)時，中間要處理的上下文信息可能要非常龐大，Token數(shù)量也會用的非常龐大。

帶著這個疑問，找到了一篇關(guān)于上下文工程中異常/失敗問題的論述，博客放在文末了，該興趣的讀者可以直接查看原版，這里我總結(jié)歸納為幾點：

總體來說，會出現(xiàn)四個上下文異常/失敗問題：

第一：上下文污染

上下文污染是指幻覺或其他錯誤進入上下文，并被反復(fù)引用。

這個問題的一種特別嚴(yán)重的表現(xiàn)形式是“上下文中毒”——上下文（目標(biāo)、摘要）的許多部分被關(guān)于游戲狀態(tài)的錯誤信息“污染”，這通常需要很長時間才能糾正。結(jié)果，模型可能會執(zhí)著于實現(xiàn)不可能或不相關(guān)目標(biāo)。

第二：上下文干擾

上下文干擾是指當(dāng)上下文變得過長時，模型過度關(guān)注上下文，忽視了在訓(xùn)練過程中所學(xué)到的內(nèi)容。

在AI Agent工作流程中，隨著上下文增長，即模型收集更多信息并積累歷史，累積的上下文可能會變得令人分心，而不是有所幫助。 

第三：上下文混淆

上下文混淆是指模型在生成低質(zhì)量響應(yīng)時，使用了上下文中多余的內(nèi)容

如果把某些內(nèi)容放入上下文中 模型就必須關(guān)注它，這可能是無關(guān)緊要的信息或由無用的工具定義，但模型 會 將其納入考慮范圍。

大型模型，尤其是推理模型，在忽略或丟棄冗余上下文方面正變得越來越好，但我們持續(xù)看到無用的信息讓Agent陷入困境。

總之來說，越長的上下文能夠容納更多的信息，但這種能力伴隨著弊端，就是容易混淆。

第四：上下文沖突

上下文沖突是指你在當(dāng)前上下文中積累的新信息或工具與其他上下文中的信息發(fā)生沖突。

這是一個更麻煩版本的《 上下文混淆 》：這里的壞上下文并非無關(guān)緊要，它直接與其他提示中的信息沖突。

微軟和 Salesforce 團隊從多個基準(zhǔn)測試中獲取提示，并將他們的信息“分片”到多個提示中?？梢赃@樣理解：

有時，在按下回車鍵之前，你可能會坐下來在 ChatGPT 或 Claude 中輸入段落，考慮每一個必要的細(xì)節(jié)。

其他時候，你可能會從一個簡單的提示開始，然后在聊天機器人的回答不令人滿意時添加更多細(xì)節(jié)。微軟/Salesforce 團隊修改了基準(zhǔn)測試提示，使其看起來像這些多步驟的交流：

圖片