国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

在大模型時代，“上下文”不再只是輸入框里的幾句話，而是貫穿產品設計、交互策略與智能響應的核心工程。本文從產品視角出發(fā)，系統梳理上下文工程的關鍵構成與設計邏輯，結合真實案例，探討如何通過“構建上下文”來提升智能體的理解力、響應力與業(yè)務適配力。

預先聲明，為了確保我的文章內容正確，我提前參考了一些AI領域領軍工程師的博客及推文，如果你們對一手信息更感興趣，可以劃到文末，我將把我的參考文章列在最后。

記得在7月初的某一天，我在用cursor嘗試開發(fā)工作上的一個邏輯，當輸入一個提示詞（prompt）讓模型給我一個回復的時候，cursor的左下角彈出來了一個小窗口：

大致含義是：用戶更傾向于讓AI助手在回答的時候直接給出步驟，而不是詢問用戶是否執(zhí)行某些命令行指令。

也就是模型總結了我剛剛輸入給他的要求，并且問我是否保存這條“記憶”。

當時我看到這個窗口的時候虎軀一震，感覺事情有點不對，這好像是一個新的AI技術，但是又說不明白和我們熟知的提示詞工程（Prompt Engineering）有什么不同，因為說白了不就是詢問我的許可，然后每次都把我的要求拼接進prompt里面，讓模型記住嗎？

這么理解沒錯，但是又有錯。沒錯就沒錯在它確實只是“提示詞的一種補充”，而錯就錯在，這種技術，已經悄然地將我們和模型對話的“prompt”變成了一種動態(tài)地，可以自己更新的“上下文(context)”。Prompt Engineering已經悄然地從每次對話輸入的一句靜態(tài)的話，變成了一個動態(tài)地，能夠不斷獲取、壓縮信息的系統。這個系統很重要，甚至是模型表現下一次有所突破的關鍵點。

我沒有意識到這個系統的強大，直到manus發(fā)布了那篇博客，我才真正認識了我們今天的主角：Context Engineering。

鋪墊到這里我們可以正式開始了，而關于Manus博客的分析，我將放到最后，因為Mauns很貼心地給出了“如何做”的注意手冊，在此之前，我們先聊聊它是什么以及為什么這么重要。

什么是上下文工程（Context Engineering）

上下文工程（Context Engineering），顧名思義，也就是關于“上下文”（Context）的“工程”(Engineering)，我們先來討論下什么是上下文。

DeepMind的工程師Philipp Schmid對上下文工程的理解如下：

在他的博客中，他將系統提示詞（System Prompt）、指令(Instruction)、長期記憶(LongTerm Memory)、可用工具（Tools）、用戶提示詞(User Prompt)以及召回信息(Retrieved Infomation)、歷史對話等短時記憶（History）甚至是結構化的輸出(Structured Output)統稱為上下文。

而在Chroma的首席執(zhí)行官Hammad Bashir在他的一次演講中，將上下文的定義總結為下圖：

雖然和Philipp Schmid的圖不完全一樣，但是都大體的含義是一樣的，即：上下文不止包括用戶輸入的單多輪對話prompt與回答，也包括能夠調用的工具、能夠合作的智能體等“工具”，同時還包括“長期/短期記憶”、“環(huán)境狀態(tài)”等抽象的概念。

在上下文的概念火爆出圈之前，我們(至少我是這樣)對模型的理解停留在下圖的模式中：

當然，對于LLM我們有很多增強它的方式，比方說RAG，比方說Fine-Tuning。但是本質上模型的主要輸入還是一輪又一輪的對話。但是上下文工程將這樣一種“單調”的輸入獲取方式，變換成了一套總結，整理上下文的系統。

舉個例子，我們有一個廚師智能體，提示詞工程的概念，就像是我們向模型提出“請做一道糖醋里脊”的prompt，然后模型開始選擇鍋鏟、選擇食材開始做。而人類做的，就是給出一個開始的口令。

而上下文工程的概念，是我們發(fā)出“做一道糖醋里脊”的prompt之后，還要給出一個“完備”的上下文，比如說，我們要說清楚糖醋里脊中要放3斤還是4斤里脊、糖是白糖還是黑糖，要講清楚廚房在哪里，做的時候要不要開燈，甚至進廚房的時候要注意防滑等等信息。也就是要“完備”地描述一個“要求”，讓模型“盡可能”完美地完成這個任務。

沒錯，這件事非常復雜，因此我們需要一個系統，讓模型自己通過“插件”也好，分析也罷，盡量少人為干預地自行提取上下文，而這個系統如何做，就是Context Engineering的Engineering，也就是“工程問題”。

到此為止，我想我們對上下文工程是什么，有了一個初步對齊的理解，而關于上下文工程是什么，我們應該可以給出這樣的定義：

上下文工程就是構建一套智能體能夠根據用戶要求，自行補充完成任務所需的上下文信息的系統。

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

為什么上下文工程的概念會爆發(fā)？因為在AI領域，大家隱隱開始有了一個共識：AI的能力足夠完成大部分任務，而阻礙當前AI智能體做到那些復雜任務的，是上下文的“不完備”。

The secret to building truly effective AI agents has less to do with the complexity of the code you write, and everything to do with the quality of the context you provide.

Philipp Schmid在他的文章中如上說道：構建一個高效的AI智能體的秘密，和你寫的代碼多么復雜一點關系沒有，但是和你給的上下文質量密切相關?；蛘叻g成：AI 智能體的真實威力，并非源于算法的錯綜復雜，而是植根于上下文的精準與豐饒。–gemini

上面這段話，是Philipp Schmid說的，而這里面透露出的上下文工程的重要性，這是很多人的共識，Andrej Karpathy也在這其中之列：

gemini提供的翻譯如下：

卡帕西認為：上下文工程是以LLM為大腦的新型計算設備中微小的一環(huán)，在上下文工程的基礎上，我們還需要構建拆解控制流、組裝上下文、任務分發(fā)等等組件，最終形成一個強大的以LLM為中樞的智能體。某種程度上，上下文工程是這一切的基礎。

怎么做上下文工程？

舉了很多博客和發(fā)言做例證，是為了講清楚上下文工程是什么以及它為什么重要這兩件事。那么接下來，我們來借用兩篇文章，看看當下人們對于上下文工程的探索有哪些吧。

上下文工程面臨的問題

就在我們理解了什么是上下文工程，以及它有多么重要的時候，有一些企業(yè)，已經做過一些上下文工程的嘗試，并且遇到了一些問題。問題的本質是：我們不能把所有相關的“信息”一股腦全部丟進上下文里，上下文的窗口可以延長，但是并不是越長越好，上下文窗口，沒有所謂的“Scaling Law”。我們可以將問題分為以下四類：

1）上下文中毒（ContextPoisoning）

上下文中毒是一個針對“正確度”的概念：當我們錯誤地讓“幻覺”或者“錯誤”進入上下文之后，這些錯誤會被模型反復引用，導致模型固執(zhí)地追求不可能或者不相關的目標，并形成荒謬的策略。

在gemini2.5的技術報告中舉了一個例子，可以作為上下文中毒的示例：當技術團隊讓gemini2.5去玩《寶可夢 紅/藍》的時候，到了一個節(jié)點，在該節(jié)點，玩家需要買一瓶飲料提供給一個守衛(wèi)，守衛(wèi)才能放行讓玩家通過，而gemini的上下文在此時混入了一個錯誤的信息，認為需要提供給守衛(wèi)“茶”，而茶這個道具是《寶可夢 紅/藍》的重制版《寶可夢 火紅/葉綠》才有的特殊道具，導致gemini花費了很長的時間在尋找茶這個錯誤的目標。

2）上下文分散（ContextDistraction）

上下文分散是一個不好界定的概念，其含義是：當一個智能體隨著工作次數增多，積累了海量的歷史記錄，積攢了過多上下文之后，它的表現就會下降。而越小的模型這個表現下降的閾值越低。

舉個例子，支持1M tokens上下文長度的gemini大致在積累了100K上下文之后，逐漸失去指定新計劃的能力，反而傾向于重復之前做過的動作。而對于Llama 3.1 405b，這個較小的模型，它在32000tokens上下文之后就開始表現下降。

3）上下文混淆（ContextConfusion）

上下文混淆是一個針對“精度”的概念，其含義是：即使我們在上下文中填充的內容都是正確的，沒有錯誤的。如果有過多的與任務“無關”的信息混雜進上下文，智能體表現也將下降。這個概念有一個具體的例證：

Drew Breunig在他的文章《How Long Context Fail》中提到，用Llama3.1 8b的模型構建一個智能體的時候，當給它提供46種工具進行查詢時，它的查詢會失敗，而如果只提供19種工具，查詢則會成功。這個問題也在Manus的博客中提到，是的沒錯，一個例子被反復引用，說明現在對上下文工程的研究還是太少了。（手動狗頭）

4）上下文沖突（ContextClash）

這是一個容易和前面上下文工程的其他問題混淆的概念，我嘗試講清楚，上下文沖突指的是存放進上下文的信息互相沖突，引起的模型表現下降。這可能會引發(fā)一個爭議：沖突不就是有一個正確的信息和一個錯誤的信息，不就是上下文中毒的概念嗎？我們來看一個具體的例子，這個例子引自Microsoft和Salesforce的一篇論文：

研究團隊模擬了用戶與聊天機器人進行多輪對話的場景。用戶不是一次性給出所有信息，而是分階段補充細節(jié)，例如，先給出一個簡單提示，然后當機器人回答不盡如人意時，再分段添加更多信息，而上下文沖突指的是，在早期提供的信息“不完備”的時候，模型嘗試做出回答，會做出一些不令人滿意的“假設”，這些假設沒有對錯的判斷，因為它是假設，因此不算“中毒”，也與任務目標強相關，不算做“混淆”，更沒達到表現下降的閾值，不構成“分散”，但是當這些假設進入上下文，隨著用戶提供越來越完備的信息的時候，模型的表現卻出現了“崩潰”——OpenAI 的 o3 模型分數從 98.1 降至 64.1。

這種基于不完備的信息做出的假設性回答，隨著信息完備，而引起信息間沖突的上下文崩潰現象，被稱作上下文沖突。

上下文工程現行的技術

針對上下文分散的問題，上下文的窗口長度是一個需要維護的確保模型運行正常的指標，如何做呢？Manus提出可以構建一個ScratchPad(暫存板)或者是動態(tài)維護一個記憶系統，將部分存在于上下文中的重要內容提取出來，存放在其中，即使智能體關閉，上下文截斷，這部分內容都將長久保存。

Anthropic在LeadReaseracher中就是用這樣的方法來存儲模型一開始生成的計劃，使得即使模型意外中斷，也能隨時獲取到一開始它做出的計劃。

而cursor則是會將用戶喜好等內容存放在記憶系統中長久地記錄。（正如開頭的那張圖片）

• 針對上下文分散的問題，除了把部分上下文移出上下文窗口存放之外，還有別的方法可以使用，那就是壓縮上下文以及修剪上下文，前者顧名思義就是當上下文快要超限的時候將其壓縮，變成更精煉的部分內容，例如，gemini-cli會在上下文快要達到1000000tokens的時候將其壓縮為1000左右個token（我一直很好奇是怎么壓縮的）。而修剪上下文指的則是直接刪除和過濾上下文中比較舊的信息。
• 針對上下文混淆的問題，上下文中需要放足夠的能夠用于解決用戶問題的信息，而如何獲取這部分信息呢？答案就是RAG，我們既可以去檢索數據庫，也可以檢索暫存板或者是記憶系統來獲取精度較高的上下文。
• 除了以上方式，多智能體構建的思路，構建多個專職某種功能的智能體也是一個可行的，通過優(yōu)化上下文而提升智能體表現的方式，而這種優(yōu)化上下文的方式就叫做上下文隔離（將各個領域的上下文隔離開，構建互相獨立的上下文環(huán)境）

總之，針對目前的上下文問題，大致有上面這四種方式：寫入上下文、壓縮/修剪上下文、召回、隔離上下文。

到這里，這篇文章就要結束了，但是在此之前，還要引用Hammad Bashir的一個觀點做總結：當前人們對上下文工程的研究使得這個領域更像一門手藝“Craft”而不是工程“Engineering”，我們在真正地把對上下文的改變應用到對應的智能體身上之前，我們無法用工程化的思維“預測”會發(fā)生什么。但是一切在慢慢好轉，因為我們開始意識到，上下文工程是下一把鑰匙，用以打開智能體的又一扇大門。

感謝您的觀看。

文章來源

https://www.manusai.io/blog/context-engineering-for-ai-agents-lessons-from-building-manus

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

https://www.youtube.com/watch?v=vsfbplnJyA8

https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html

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

https://storage.googleapis.com/deepmind-media/gemini/gemini_v2_5_report.pdf