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

最近看一個(gè)播客是 Chroma 創(chuàng)始人兼 CEOJeff在 Len Space 播客的對(duì)話，對(duì)話的標(biāo)題就是關(guān)于“RAG is dead”的觀念，在視頻中很明顯的說(shuō)明了原本的RAG的局限性和現(xiàn)在context engnieer的重要性，今天我就想全面分析一下“上文工程”（context engnieer）為什么這么爆火？以及將來(lái)RAG的形態(tài)到底何去何從……

簡(jiǎn)單解釋一下Context Engineering (上下文工程)是近期AI領(lǐng)域的一個(gè)新概念。它關(guān)注的不是如何訓(xùn)練大型模型，而是如何精心設(shè)計(jì)和優(yōu)化給模型的輸入內(nèi)容。其核心思想是不改變模型的結(jié)構(gòu)，只改變模型看到了什么，目的是讓模型在有限的上下文窗口（Context Window）內(nèi)盡可能地理解得更準(zhǔn)確、回答得更好、花費(fèi)更少。

什么是Context ？什么是 Context Window？

Context (上下文)

Context就是模型“看到”的一切，模型其實(shí)并不是只根據(jù)我們輸入的prompt回復(fù)問(wèn)題，還有其余的信息配合生成回復(fù)。

上下文工程作為適用于幾種不同上下文類(lèi)型的總括：

1.Instructions（指令上下文）

• 系統(tǒng)提示詞（SystemPrompts）：定義AI的角色、行為準(zhǔn)則和響應(yīng)風(fēng)格
• 任務(wù)指令：具體的任務(wù)描述和執(zhí)行要求
• 少樣本示例（Few-shotExamples）：輸入輸出示例，幫助模型理解預(yù)期格式
• 工具描述：可用函數(shù)/工具的規(guī)范和使用說(shuō)明
• 格式約束：輸出格式、結(jié)構(gòu)化要求等

2. Knowledge（知識(shí)上下文）

• 領(lǐng)域知識(shí)：特定行業(yè)或?qū)I(yè)的事實(shí)性信息
• 記憶系統(tǒng)：用戶偏好、歷史交互、會(huì)話歷史
• 檢索增強(qiáng)生成（RAG）：從向量數(shù)據(jù)庫(kù)或知識(shí)庫(kù)檢索的相關(guān)信息
• 實(shí)時(shí)數(shù)據(jù)：當(dāng)前狀態(tài)、動(dòng)態(tài)更新的信息

3.Tools（工具上下文）

• 函數(shù)調(diào)用結(jié)果：API響應(yīng)、數(shù)據(jù)庫(kù)查詢(xún)結(jié)果
• 工具執(zhí)行狀態(tài)：成功/失敗反饋、錯(cuò)誤信息
• 多步驟工具鏈：工具間的依賴(lài)關(guān)系和數(shù)據(jù)傳遞
• 執(zhí)行歷史：之前的工具調(diào)用記錄和結(jié)果

Context Window (上下文窗口)

是指模型輸入中最多能夠容納的token數(shù)量的限制。

Token可以理解為文本被拆分成的最小單位，可能是一個(gè)字、一個(gè)詞，或者是一個(gè)標(biāo)點(diǎn)符號(hào)。例如，Gemin Pro的上下文窗口是100萬(wàn)個(gè)token，這意味著它最多能處理100萬(wàn)個(gè)token的輸入。一旦超過(guò)這個(gè)限制，前面的內(nèi)容就會(huì)被丟棄，只保留最后的100萬(wàn)個(gè)token。例如：“ChatGPT”可能會(huì)被拆分成 [“Chat”, “G”, “PT”] 三個(gè) token?！懊魈?去 吃飯”，中間的空格也會(huì)單獨(dú)占一個(gè) token。總共有7個(gè)token。

容量限制

• GPT-3.5的主流版本確實(shí)只有4Ktoken上下文窗口（大約2–3千個(gè)中文字符）。
• Claude3.5Sonnet：官方標(biāo)配200Ktoken上下文窗口（約15萬(wàn)漢字），可穩(wěn)定處理幾十萬(wàn)字的內(nèi)容。
• Google在2024年發(fā)布時(shí)，強(qiáng)調(diào)Gemin2.5Pro的上下文窗口可以達(dá)到100萬(wàn)token，而且是“實(shí)測(cè)可用”的，不是紙面數(shù)字。100萬(wàn)token大約對(duì)應(yīng)70–80萬(wàn)個(gè)英文單詞，換算成中文差不多能覆蓋整本專(zhuān)業(yè)書(shū)籍甚至多本論文合集。

什么是 Context Engineering？

之前我們一直在強(qiáng)調(diào)prompt engineer（提示詞工程），目標(biāo)是讓模型在既定約束下穩(wěn)定地產(chǎn)出期望格式與質(zhì)量的結(jié)果，把單步任務(wù)說(shuō)清楚（角色、目標(biāo)、格式、約束、示例）。

“如果說(shuō)Prompt Engineering（提示詞工程）是“如何問(wèn)問(wèn)題”，那么Context Engineering（語(yǔ)境工程）更進(jìn)一步，它關(guān)心的是“如何設(shè)計(jì)問(wèn)題背后的語(yǔ)境”?！?/p>

• PromptEngineering：側(cè)重在一句話或一段指令中，如何讓模型理解并執(zhí)行。
• ContextEngineering：不僅是提問(wèn)，還要設(shè)計(jì)整個(gè)對(duì)話、任務(wù)或信息流的上下文環(huán)境，讓模型在“正確的語(yǔ)境”里作答。

直白點(diǎn)說(shuō)，Prompt 是“單點(diǎn)觸發(fā)”（需要干啥），Context 是“完整背景”（如何干對(duì)干好）。

Prompt（提示）：用戶一句話——“我想退貨?！边@是模型要處理的直接任務(wù)，就像指令：識(shí)別意圖，生成一段回復(fù)。Context（語(yǔ)境）：退貨能否成功，取決于系統(tǒng)給模型的更多信息：用戶是誰(shuí)（新老客戶？VIP？黑名單？）訂單詳情（買(mǎi)的什么，是否在退貨期限內(nèi)？）商城規(guī)則（此商品是否支持7天無(wú)理由？）歷史對(duì)話（之前客服有沒(méi)有答應(yīng)過(guò)用戶什么條件？）如果模型只拿到 Prompt（“我想退貨”），它可能機(jī)械回答：“請(qǐng)?jiān)?天內(nèi)申請(qǐng)?！钡?Context 的支持下，它能更聰明地說(shuō)：“您購(gòu)買(mǎi)的耳機(jī)還在退貨期，我已為您提交退貨申請(qǐng)，快遞員將在2天內(nèi)上門(mén)取件。”

四個(gè)核心特征

??動(dòng)態(tài)系統(tǒng)，而非靜態(tài)模板

復(fù)雜AI應(yīng)用需要整合多源信息：開(kāi)發(fā)者指令、用戶輸入、歷史交互、工具反饋、外部數(shù)據(jù)。這些信息實(shí)時(shí)變化，因此構(gòu)建提示的邏輯必須是動(dòng)態(tài)的，能夠根據(jù)情況智能組裝上下文。

??信息質(zhì)量決定輸出質(zhì)量

“吃什么，拉什么” —— 這是AI領(lǐng)域的鐵律

LLM不會(huì)讀心術(shù)。很多智能體表現(xiàn)糟糕的根本原因是缺乏關(guān)鍵信息。你必須提供：

• 相關(guān)性高的背景知識(shí)
• 準(zhǔn)確性強(qiáng)的實(shí)時(shí)數(shù)據(jù)
• 完整性好的上下文線索

???工具賦能，突破純文本局限

僅憑文本輸入，LLM無(wú)法處理復(fù)雜的現(xiàn)實(shí)任務(wù)。正確的工具配置包括：

• 信息檢索接口（搜索、數(shù)據(jù)庫(kù)查詢(xún)）
• 操作執(zhí)行能力（API調(diào)用、文件處理）
• 分析計(jì)算功能（數(shù)據(jù)處理、邏輯推理）

??格式設(shè)計(jì)，影響理解效率

與人類(lèi)溝通一樣，怎么說(shuō)比說(shuō)什么同樣重要：

• 一句清晰的錯(cuò)誤提示>一堆混亂的JSON數(shù)據(jù)
• 結(jié)構(gòu)化的工具參數(shù)>模糊的功能描述
• 漸進(jìn)式的信息組織>信息堆砌

在設(shè)計(jì)上下文工程時(shí)的要求

?信息充分嗎？是否提供了完成任務(wù)的必要信息？

?工具合適嗎？是否具備解決問(wèn)題的關(guān)鍵能力？

?格式清晰嗎？AI能否輕松理解和使用這些資源？

為什么會(huì)出現(xiàn) Context Engineer？

隨著上下文窗口越來(lái)越長(zhǎng)，我們?cè)疽詾椤鞍阉袑?duì)話歷史和資料都丟進(jìn)模型”就能解決記憶問(wèn)題。但實(shí)驗(yàn)表明，現(xiàn)實(shí)遠(yuǎn)比想象復(fù)雜。隨著上下文長(zhǎng)度增長(zhǎng)，模型越來(lái)越難保持信息的準(zhǔn)確性與一致性，表現(xiàn)就像“記憶腐爛”。

這些現(xiàn)象在 Chroma 的研究中被稱(chēng)為Context Rot——即模型在長(zhǎng)語(yǔ)境下的性能“腐蝕”。這正是Context Engineer這一角色誕生的根本原因：需要有人去對(duì)抗和修復(fù)這種“語(yǔ)境腐爛”，通過(guò)裁剪、壓縮、重組和檢索增強(qiáng)，讓模型在有限的注意力資源中保持可靠表現(xiàn)。

在業(yè)界常見(jiàn)經(jīng)常使用Needle-in-a-Haystack（針堆測(cè)試）對(duì)模型上下問(wèn)能力進(jìn)行檢測(cè)。

可以理解為這個(gè)實(shí)驗(yàn)就是大海撈針，在海量的文章數(shù)據(jù)中放一部分我們需要的知識(shí)內(nèi)容。

市面上模型幾乎能拿到滿分，因此很容易讓人以為：它們可以在任意長(zhǎng)輸入下穩(wěn)定完成任何任務(wù)。

但事實(shí)是，模型之所以能在“針堆測(cè)試”上表現(xiàn)出色，是因?yàn)檫@個(gè)測(cè)試非常簡(jiǎn)單，本質(zhì)上是一個(gè)“識(shí)別任務(wù)”。我們只是把一個(gè)隨機(jī)事實(shí)插在長(zhǎng)文檔的中間，然后讓模型找出來(lái)。而且，這種設(shè)計(jì)往往存在詞面匹配（lexical match），模型幾乎只要做個(gè)字符串匹配就能答對(duì)，不需要推理或消解歧義。

例如：

問(wèn)題：我大學(xué)同學(xué)給我的最佳寫(xiě)作建議是什么？

針（ Needle）：我大學(xué)同學(xué)給我的最佳寫(xiě)作建議是每周都寫(xiě)作。

然而，在實(shí)際使用過(guò)程中，任務(wù)遠(yuǎn)比這種詞面匹配復(fù)雜得多。

一旦我們加入一些模糊性（比如問(wèn)題和 needle 的表述不完全一致），或者放入一些干擾項(xiàng)（distractors），隨著輸入長(zhǎng)度增加，模型性能就會(huì)開(kāi)始顯著下降。以下是Context Rot： How Increasing Input Tokens Impacts LLMPerformance研究中針對(duì)上下文的token數(shù)對(duì)LLM模型輸出效果的研究多探討的幾個(gè)關(guān)鍵影響生成質(zhì)量點(diǎn)：

1. 長(zhǎng)對(duì)話推理困難

模型在面對(duì)數(shù)十萬(wàn) tokens 的輸入時(shí)，并不能像硬盤(pán)一樣均勻記住所有信息。實(shí)驗(yàn)發(fā)現(xiàn)，精簡(jiǎn)版輸入（僅幾百 tokens）反而比完整輸入（十幾萬(wàn) tokens）表現(xiàn)更好。研究結(jié)果顯示，模型在精簡(jiǎn)版上的表現(xiàn)顯著優(yōu)于完整版。這說(shuō)明當(dāng)輸入過(guò)長(zhǎng)、噪音過(guò)多時(shí)，即使是最先進(jìn)的模型，也很難抓住關(guān)鍵信息。

現(xiàn)象還原想象這樣的場(chǎng)景：你在對(duì)話初期提到”我現(xiàn)在住在北京”，

經(jīng)過(guò)數(shù)百輪對(duì)話后問(wèn)”我一會(huì)想找個(gè)好看的地方看日料”

理想情況下，AI應(yīng)該給出北京的地點(diǎn)推薦。但一個(gè)之前的方法是把完整對(duì)話歷史（幾百條消息）直接塞進(jìn) prompt，希望模型自己找。我們實(shí)驗(yàn)證明，這在實(shí)踐中效果并不好，輸出經(jīng)常不可靠。

研究通過(guò)LongMemEva基準(zhǔn)進(jìn)行了對(duì)比測(cè)試：

完整對(duì)話版本：約500條對(duì)話，總計(jì)12萬(wàn)tokens，模型的任務(wù)是找到相關(guān)的信息并且進(jìn)行回復(fù)

精簡(jiǎn)關(guān)鍵信息版本：測(cè)試關(guān)于濃縮版本的信息僅保留相關(guān)片段，總計(jì)300tokens，對(duì)比兩者恢復(fù)的質(zhì)量

這意味著：如何裁剪和組織上下文，直接決定了模型能否記住關(guān)鍵信息。當(dāng)輸入過(guò)于冗長(zhǎng)噪聲過(guò)多時(shí)就算是能力比較強(qiáng)的模型表現(xiàn)也一般，模型就像在信息海洋中迷航，難以準(zhǔn)確定位關(guān)鍵信息，出現(xiàn)了”記憶衰減”現(xiàn)象。

2. 長(zhǎng)輸入的模糊性使挑戰(zhàn)更加復(fù)雜

“模糊性”（ambiguity）指的是問(wèn)題（question）和針（needle）之間的對(duì)應(yīng)關(guān)系不再直接、明確，而是存在多種可能解釋或理解空間。

現(xiàn)實(shí)中，當(dāng)你提示模型修復(fù)代碼 bug，你通常不會(huì)告訴它精確的行號(hào)，而是會(huì)給一大段上下文代碼，讓它自己找原因。

我們改造了“針堆測(cè)試”，引入不同程度的模糊性（“High Similarity Needle”“l(fā)ow Similarity Needle”）其實(shí)就是干擾項(xiàng)（通過(guò) needle 與問(wèn)題的余弦相似度來(lái)量化）。編寫(xiě)了 8 個(gè)與長(zhǎng)文本主題相關(guān)的“needle”，分析了各種模型在 4 干擾條件下是否嘗試失敗，不容易被模型簡(jiǎn)單關(guān)鍵詞匹配找到。人工寫(xiě)這些 needle 是為了避免模型在訓(xùn)練時(shí)已經(jīng)見(jiàn)過(guò)，保證實(shí)驗(yàn)干凈。

原始問(wèn)題：我大學(xué)同學(xué)給我的最佳寫(xiě)作建議是什么？

相似度較高材料（High Similarity Needle）：

我大學(xué)同學(xué)給我的最佳寫(xiě)作建議是每周寫(xiě)一次

模糊的材料（low Similarity Needle）：

很少有人知道，我每周堅(jiān)持寫(xiě)作的習(xí)慣是大學(xué)時(shí)英語(yǔ)課上一位同學(xué)推薦的。

Question 問(wèn)題：

What was the best writing advice I got from my college classmate?

我從大學(xué)同學(xué)那里得到的最好的寫(xiě)作建議是什么?

High Similarity Needle 高相似度針頭：

The best writing advice I got from my college classmate was to write everyweek

我從大學(xué)同學(xué)那里得到的最好的寫(xiě)作建議是每周寫(xiě)一次。

Ambiguous Needle 模糊的針頭：

One thing people may not know about me is that I write every week. It’s themost useful habit I’vedeveloped, and it started back in my college days when a random guy in my English corrected it to me

人們可能不知道的是，我每周都會(huì)寫(xiě)作。這是我養(yǎng)成的最有用的習(xí)慣，它始于大學(xué)時(shí)期，當(dāng)時(shí)英語(yǔ)課上的一位不認(rèn)識(shí)的同學(xué)向我提出了這個(gè)建議。

結(jié)果發(fā)現(xiàn)：

在短輸入下，即使 needle 很模糊，模型也能正確回答。

但隨著輸入變長(zhǎng)，模糊性顯著加劇性能下降。

這說(shuō)明模型具備處理歧義的能力，但這種能力在長(zhǎng)輸入下迅速崩潰。

這告訴我們：在冗長(zhǎng)語(yǔ)境下，需要人為幫模型消除歧義，強(qiáng)化關(guān)鍵信號(hào)。

3. 干擾項(xiàng)的影響

干擾項(xiàng)（distractors）就是在測(cè)試或任務(wù)里，看起來(lái)跟正確答案很相似，但其實(shí)不是真正答案的內(nèi)容。它們的存在會(huì)“干擾”模型，讓模型容易選錯(cuò)。

在“長(zhǎng)上下文”研究里，干擾項(xiàng)通常是：

語(yǔ)義相關(guān)：主題、關(guān)鍵詞、句式都跟 needle 很像。

不完全正確：內(nèi)容部分對(duì)齊，但回答的是另一個(gè)問(wèn)題。

真實(shí)對(duì)話和資料中，往往存在語(yǔ)義相似卻不相關(guān)的“噪音”。短上下文里模型能區(qū)分，但長(zhǎng)上下文時(shí)更容易被誤導(dǎo)。這要求有人來(lái)做上下文的篩選與去噪，讓模型聚焦真正相關(guān)的信息。在長(zhǎng)上下文里，模型不光要找到相關(guān)信息，還要能分辨“哪個(gè)才是正確的 needle，哪個(gè)只是干擾項(xiàng)”。

實(shí)驗(yàn)中測(cè)試的問(wèn)題是：

Question 問(wèn)題：

“What was the best writing advice I got from my college classmate?”

我從大學(xué)同學(xué)那里得到的最好的寫(xiě)作建議是什么?

Needle 針頭：

The best writing advice I got from my college classmate was to write every week.

我從大學(xué)同學(xué)那里得到的最好的寫(xiě)作建議是每周寫(xiě)一篇。

Distactor 分心者：

The best writing advice Igot from my classmate was towrite each essay in threedifferent styles, this wasback in high school.

我從同學(xué)那里得到的最好的寫(xiě)作建議是用三種不同的風(fēng)格寫(xiě)每篇論文，這是在高中時(shí)學(xué)到的。

??藍(lán)線是沒(méi)有干擾項(xiàng)，黃線是有1個(gè)干擾項(xiàng)，紅色是有4個(gè)干擾項(xiàng)

以下是不同模型的最終結(jié)果，從圖上可知隨著干擾項(xiàng)的增加隨著字?jǐn)?shù)的增加準(zhǔn)確度逐步遞減。

結(jié)果證明：

在短輸入下，模型可以區(qū)分 needle 與干擾項(xiàng)。

輸入越長(zhǎng)，性能下降越明顯。

4. 缺乏“計(jì)算機(jī)式”可靠性

我們希望LLM獲得一致質(zhì)量的輸出 即使是最簡(jiǎn)單的復(fù)制任務(wù)，模型在長(zhǎng)輸入下也會(huì)出錯(cuò)。它不是逐字逐位的符號(hào)處理器，而是概率驅(qū)動(dòng)的語(yǔ)言生成器。因此不能期望它像數(shù)據(jù)庫(kù)或計(jì)算機(jī)一樣精確地處理長(zhǎng)上下文，而必須借助結(jié)構(gòu)化設(shè)計(jì)來(lái)彌補(bǔ)。

讓模型重復(fù)一段字符串列表，并在某個(gè)特定位置插入一個(gè)獨(dú)特單詞。理論上，這只是機(jī)械復(fù)制任務(wù)，應(yīng)該百分百正確。

結(jié)果發(fā)現(xiàn)：

當(dāng)列表長(zhǎng)度達(dá)到 500 詞時(shí)，模型的表現(xiàn)開(kāi)始下滑，常常會(huì)多寫(xiě)、漏寫(xiě)，甚至輸出隨機(jī)內(nèi)容。這證明模型并不是“均勻處理上下文”的計(jì)算系統(tǒng)。

總結(jié)

即使你的模型擁有 100 萬(wàn) token 的上下文窗口，這也不意味著它能在 100 萬(wàn) token 下穩(wěn)定工作。即便是當(dāng)前最頂尖的模型，在長(zhǎng)輸入中處理簡(jiǎn)單任務(wù)時(shí)仍會(huì)掉鏈子。

因此，有效的上下文窗口管理和語(yǔ)境工程是必不可少的。

怎么實(shí)施 Context Engineer？

上下文工程（Context Engineering），正是為了解決這個(gè)問(wèn)題的一整套方法論。它核心分為四個(gè)環(huán)節(jié)：寫(xiě)（Write）→ 選（Select）→ 壓（Compress）→ 隔（Isolate）。下面我們逐一拆解。

1.Write Context 寫(xiě)入上下文

寫(xiě)入上下文意味著把信息明確記錄下來(lái)，而不是依賴(lài)模型的“即時(shí)記憶”。在復(fù)雜的任務(wù)中，Agent 需要不斷產(chǎn)生中間結(jié)果、推理路徑、狀態(tài)信息，如果不把這些內(nèi)容寫(xiě)入持久化的存儲(chǔ)，就會(huì)在后續(xù)步驟中遺失，造成邏輯斷裂。

1.1 Scratchpads 便簽本

當(dāng)人類(lèi)解決任務(wù)時(shí)，一個(gè)臨時(shí)的工作區(qū)，記錄模型的中間推理，讓思考過(guò)程可見(jiàn)。例如在代碼生成時(shí)，模型會(huì)先在 scratchpad 上寫(xiě)出邏輯推理，再據(jù)此生成 SQL 或函數(shù)。

Anthropic 的多智能體研究人員舉了一個(gè)明顯的例子：

LeadResearcher的 Agent，它需要帶領(lǐng)團(tuán)隊(duì)探索某個(gè)研究方向。它在思考“下一步計(jì)劃”時(shí)，會(huì)把計(jì)劃寫(xiě)入內(nèi)存（memory）。這樣一來(lái)，即使上下文窗口后來(lái)被截?cái)?，Agent 仍然能通過(guò) memory 找回原本的計(jì)劃。

1.2 Memories 記憶

將跨對(duì)話的重要事實(shí)、用戶信息和環(huán)境狀態(tài)保留下來(lái)，以便后續(xù)復(fù)用。

Agent 不只是被動(dòng)存儲(chǔ)信息，而是像人類(lèi)一樣，在每次行動(dòng)后主動(dòng)反思，把經(jīng)歷轉(zhuǎn)化為“抽象記憶”，并在未來(lái)的任務(wù)中反復(fù)使用。這樣它就能在長(zhǎng)期交互中表現(xiàn)出連續(xù)性和成長(zhǎng)性。

Agent 會(huì)把新發(fā)生的上下文（new context）與已有的記憶（existing memories）結(jié)合，經(jīng)過(guò)處理后寫(xiě)成更新的記憶（updated memory），這樣它就能在未來(lái)的任務(wù)中調(diào)用“更完整、更抽象的知識(shí)”，而不是零散片段。

LLM 可用于更新或創(chuàng)建記憶，這些概念進(jìn)入了ChatGPT、Cursor和Windsurf等流行產(chǎn)品中，這些產(chǎn)品都具有自動(dòng)生成長(zhǎng)期記憶的機(jī)制，這些記憶可以根據(jù)用戶與Agent的交互在會(huì)話中持續(xù)存在。長(zhǎng)期記憶機(jī)制已經(jīng)落地在主流產(chǎn)品中，它讓 Agent 不再是“一問(wèn)一答的臨時(shí)工”，而是能在持續(xù)交互中逐漸了解用戶、形成上下文積累的“長(zhǎng)期助手”。

2.Select Context 選擇上下文

當(dāng)信息量越來(lái)越大時(shí)，如何選擇比如何存儲(chǔ)更重要。選擇上下文就是在每次調(diào)用模型時(shí)，從所有可用的信息源里，挑出真正相關(guān)的部分放入窗口。

2.1 Scratchpad 便簽本

從暫存器中選擇上下文的機(jī)制取決于暫存器的實(shí)現(xiàn)方式。如果它是一個(gè)工具，那么Agent可以通過(guò)進(jìn)行工具調(diào)用來(lái)簡(jiǎn)單地讀取它。如果它是Agent運(yùn)行時(shí)狀態(tài)的一部分，則開(kāi)發(fā)人員可以選擇在每個(gè)步驟中向Agent公開(kāi)哪些狀態(tài)部分。這為在以后的回合中向 LLM 公開(kāi)暫存器上下文提供了細(xì)粒度的控制級(jí)別。

2.2 Memories 記憶

即使 Agent 有了長(zhǎng)期記憶，它也不能把所有記憶一次性都塞進(jìn)上下文窗口（會(huì)超載、也會(huì)讓模型困惑）。 所以它必須像人一樣主動(dòng)篩選，只帶上和當(dāng)前任務(wù)相關(guān)的那部分記憶。

• 語(yǔ)義記憶(Semantic)選擇事實(shí)知識(shí)作為任務(wù)的背景。“醫(yī)生看病時(shí)，會(huì)調(diào)用自己記得的人體生理知識(shí)?！?/li>
• 情景記憶(Episodic)選擇過(guò)去的相似經(jīng)歷，作為行為的“示范案例”?！皩W(xué)生做題時(shí)，會(huì)想起自己以前做過(guò)的類(lèi)似題目。”
• 程序記憶(Procedural)選擇操作規(guī)則或執(zhí)行指令，用來(lái)引導(dǎo)行為。“人類(lèi)開(kāi)車(chē)時(shí)不需要重新學(xué)習(xí)“踩剎車(chē)”，而是直接調(diào)用程序性技能?！?/li>

在電商客服場(chǎng)景中，用戶問(wèn)“訂單為什么還沒(méi)到”，Agent 只需要選擇訂單記錄和物流政策作為上下文，而不必把全部 FAQ 或促銷(xiāo)活動(dòng)一起輸入。通過(guò)這種精確的選擇，模型的注意力被鎖定在最關(guān)鍵的信息上，從而給出更聚焦的回答。

2.3 如何確保選取的記憶真的是相關(guān)的，而不是“亂選”或“越界”呢？

許多早期的 Agent 采取了簡(jiǎn)化的策略：它們并不真的從大量信息中動(dòng)態(tài)篩選，而是固定從一組狹窄的文件里拉取上下文。

例如，不少代碼 Agent 會(huì)把指令放在一個(gè)專(zhuān)門(mén)的文件中（這就是“程序性記憶”），Claude Code 使用CLAUDE.md，Cursor 和 Windsurf 則依賴(lài)規(guī)則文件。在某些情況下，它們也會(huì)附帶幾個(gè)示例，作為“情景記憶”的簡(jiǎn)化版本。

這種做法簡(jiǎn)單，但局限明顯：

隨著 Agent 開(kāi)始存儲(chǔ)更多事實(shí)與關(guān)系（也就是語(yǔ)義記憶），選擇的難度指數(shù)級(jí)增加。ChatGPT 是一個(gè)突出的例子：它能夠保存大量用戶特定的記憶，并在任務(wù)中進(jìn)行選擇。為了解決“選什么”的問(wèn)題，產(chǎn)品通常引入嵌入索引或知識(shí)圖譜，作為輔助檢索機(jī)制。

即便如此，記憶選擇仍然容易出錯(cuò)。

在一次公開(kāi)分享中，Simon Willison 就展示了一個(gè)令人尷尬的案例：ChatGPT 自動(dòng)從記憶中取出他的位置信息，并意外注入到圖像生成的提示詞里。這種“未預(yù)期的記憶注入”，會(huì)讓用戶覺(jué)得上下文窗口仿佛不再完全受控，甚至帶來(lái)隱私上的擔(dān)憂。

Tools 工具

過(guò)濾掉多余的返回，只保留必要數(shù)據(jù)。

在 Agent 系統(tǒng)里，工具本身就是一種上下文。當(dāng)模型調(diào)用 API、插件或外部函數(shù)時(shí)，它必須理解工具的描述，并在合適的場(chǎng)景下選擇正確的工具。問(wèn)題在于，如果給 Agent 提供的工具太多、描述彼此重疊，就會(huì)讓模型陷入“工具過(guò)載”：它不知道該用哪個(gè)，甚至可能錯(cuò)誤調(diào)用。

為了解決這一問(wèn)題，一種有效方法是將RAG（Retrieval-Augmented Generation，檢索增強(qiáng)生成）用于工具描述的選擇：

• 不再把所有工具內(nèi)容一次性丟給模型；
• 而是先用檢索機(jī)制篩選出與當(dāng)前任務(wù)最相關(guān)的少量工具，再交給模型使用。

研究表明，這樣的做法能顯著提升工具選擇的準(zhǔn)確性——部分最新論文顯示，準(zhǔn)確率甚至可以提升 3 倍。

把工具當(dāng)作上下文來(lái)處理，是現(xiàn)代 Agent 工程的重要課題：如果不加選擇，工具多到讓模型迷失，就會(huì)導(dǎo)致執(zhí)行效率低下；如果應(yīng)用 RAG，對(duì)工具進(jìn)行檢索和過(guò)濾，就能極大提升選擇準(zhǔn)確率。

尤其在代碼場(chǎng)景中，RAG 并不是“嵌入搜索萬(wàn)能藥”。它需要結(jié)合AST 分塊、知識(shí)圖譜檢索、傳統(tǒng)搜索、重新排序等手段，才能真正解決大規(guī)模代碼庫(kù)下的上下文選擇問(wèn)題。

換句話說(shuō)：RAG 不是終點(diǎn)，而是一個(gè)需要系統(tǒng)設(shè)計(jì)與多層次補(bǔ)充的工程方案。

3.Compressing Context 壓縮上下文

在真實(shí)應(yīng)用中，Agent 的交互可能跨越數(shù)百個(gè)回合，同時(shí)還會(huì)調(diào)用大量token 密集型工具（例如代碼搜索、數(shù)據(jù)庫(kù)查詢(xún)、長(zhǎng)文檔解析）。如果把這些內(nèi)容原封不動(dòng)放進(jìn)上下文窗口，不僅會(huì)迅速耗盡 token，還會(huì)讓模型難以聚焦。

壓縮上下文（Compressing Context）就是解決這個(gè)問(wèn)題的核心方法。它的基本思路是：對(duì)長(zhǎng)對(duì)話或冗長(zhǎng)的工具輸出，進(jìn)行摘要（summarization）或修剪（trimming），用更短的信息替代原始內(nèi)容。

在 LangGraph 的設(shè)計(jì)中，還特別支持將狀態(tài)（state）壓縮后再寫(xiě)入，從而減少 token 占用，同時(shí)保持任務(wù)的完整性。

3.1 Context Summarization 上下文摘要

Agent交互可以跨越數(shù)百個(gè)回合，并使用token密集型工具調(diào)用。摘要是管理這些挑戰(zhàn)的一種常見(jiàn)方法。如果您使用過(guò) Claude Code，您就會(huì)看到這一點(diǎn)。Claude Code 在您超過(guò) 95% 的上下文窗口后運(yùn)行“ 自動(dòng)壓縮 ”，它將總結(jié)用戶與Agent交互的完整軌跡。這種跨Agent軌跡的壓縮可以使用各種策略，例如遞歸或分層摘要。

壓縮上下文的兩大核心策略：

1. 對(duì)話摘要：管理長(zhǎng)時(shí)間的多輪交互。
2. 工具摘要：管理冗長(zhǎng)的外部調(diào)用結(jié)果。

二者的目標(biāo)一致：減少 token 占用，保留關(guān)鍵上下文，讓 LLM 聚焦在真正重要的信息上。

可以應(yīng)用摘要的幾個(gè)地方。除了對(duì)長(zhǎng)對(duì)話和工具輸出做整體壓縮之外，摘要還可以插入到 Agent 流程的特定節(jié)點(diǎn)，幫助系統(tǒng)更高效地傳遞信息。

a. 工具調(diào)用后的后處理

有些工具本身返回的信息極其龐大，比如搜索引擎、代碼搜索、文檔檢索。

如果直接把這些結(jié)果交給模型，不僅浪費(fèi) token，還可能讓模型分心。

在調(diào)用完成后做一次“摘要”，只保留與任務(wù)相關(guān)的關(guān)鍵信息，可以顯著降低負(fù)擔(dān)。

b. Agent-Agent 邊界的知識(shí)交接

在多 Agent 協(xié)作場(chǎng)景里，不同 Agent 需要傳遞信息。

Cognition 的實(shí)踐提到：在 Agent 之間交接時(shí)，先做摘要，再傳遞，可以減少 token 占用。

相當(dāng)于把“原始記錄”精簡(jiǎn)成“交接筆記”，既高效又避免上下文污染。

c. 特定事件或決策的捕捉

有時(shí)我們并不是要壓縮所有信息，而是只想捕捉某些關(guān)鍵事件或決策。

這類(lèi)摘要往往比“通用總結(jié)”更難，因?yàn)橐羞x擇性地保留對(duì)未來(lái)有影響的細(xì)節(jié)。

Cognition 的做法是使用一個(gè)微調(diào)模型（fine-tuned model）來(lái)生成這類(lèi)定制化摘要，保證準(zhǔn)確性。

3.2 Context Trimming 上下文修剪

摘要通常使用 LLM 來(lái)提煉最相關(guān)的上下文片段，而修剪通?？梢赃^(guò)濾，或者正如 Drew Breunig 指出的那樣，“修剪”上下文。

啟發(fā)式修剪（Heuristic Trimming）

Drew Breunig 的觀點(diǎn)是：修剪有時(shí)比摘要更直接、成本更低。

例如在聊天場(chǎng)景中，可以簡(jiǎn)單規(guī)定：

只保留最近 10 條消息；

或只保留包含關(guān)鍵字的消息，其余刪除。

這種方式雖然粗糙，但能避免 token 膨脹。

摘要是“提煉”，修剪是“裁剪”。摘要需要 LLM 來(lái)生成濃縮內(nèi)容，而修剪通常用規(guī)則或?qū)ｉT(mén)模型來(lái)刪除不必要的上下文。兩者常常配合使用：先修剪掉最沒(méi)用的部分，再對(duì)剩余的內(nèi)容做摘要。

4. Isolating Context 隔離上下文

在復(fù)雜任務(wù)中，如果把所有信息都塞進(jìn)一個(gè) Agent 的上下文窗口，很容易造成沖突、過(guò)載和混亂。隔離上下文的目標(biāo)，就是通過(guò)“分區(qū)管理”，讓不同類(lèi)型的信息保持邊界清晰。這樣不僅能避免信息干擾，還能讓系統(tǒng)結(jié)構(gòu)更清晰。

4.1 Multi-agent 多智能體

隔離上下文最常見(jiàn)的方式就是多智能體架構(gòu)。

代表性實(shí)踐是 OpenAI 的Swarm 庫(kù)：它的設(shè)計(jì)動(dòng)機(jī)是關(guān)注點(diǎn)分離，把大任務(wù)拆成子任務(wù)，每個(gè)子 Agent 各自處理。

每個(gè)子 Agent 擁有：一組特定的工具、自己的系統(tǒng)說(shuō)明（instructions）、獨(dú)立的上下文窗口

Anthropic 的研究也支持這一點(diǎn)：當(dāng)智能體被拆分成多個(gè)子代理，每個(gè)子代理只處理自己專(zhuān)屬的窄任務(wù)時(shí)，整體性能往往優(yōu)于“一個(gè)大而全的單智能體”。

他們?cè)诓┛屠飳?xiě)道：

子代理在各自獨(dú)立的上下文窗口中并行運(yùn)行，同時(shí)探索問(wèn)題的不同方面。

這就像一個(gè)團(tuán)隊(duì)開(kāi)會(huì)時(shí)，每個(gè)人只帶自己相關(guān)的筆記，而不是所有人都要讀完整個(gè)文件夾。

不過(guò)，多 Agent 架構(gòu)也帶來(lái)挑戰(zhàn)：

token 成本增加：Anthropic 報(bào)告顯示，多代理模式下的 token 使用可能比單 Agent 多出15 倍。

提示工程復(fù)雜：需要設(shè)計(jì)好每個(gè)子 Agent 的分工和指令。

協(xié)調(diào)難度：子 Agent 的結(jié)果必須由調(diào)度者整合，否則會(huì)各說(shuō)各話。

4.2 Context Isolation with Environments 與環(huán)境的上下文隔離

HuggingFace 的深入研究者展示了上下文隔離的另一個(gè)有趣的例子。大多數(shù)代理使用工具調(diào)用 API，它返回 JSON 對(duì)象（工具參數(shù)），這些對(duì)象可以傳遞給工具（例如搜索 API）以獲取工具反饋（例如搜索結(jié)果）。

Hugging Face 的研究團(tuán)隊(duì)給出了一個(gè)典型案例：CodeAgent。

流程是：

LLM 生成工具調(diào)用（例如調(diào)用一個(gè)搜索 API），以 JSON 形式描述參數(shù)。

這些調(diào)用被送入工具，在一個(gè)沙盒環(huán)境中執(zhí)行。

工具執(zhí)行結(jié)果（例如搜索結(jié)果）再被挑選后傳回給 LLM。

這種方式的關(guān)鍵是：執(zhí)行環(huán)境和 LLM 上下文隔離。

LLM 不需要直接接觸所有工具輸出，而是只接收處理過(guò)的結(jié)果。

Hugging Face 指出，這種方法尤其適合處理token 密集型對(duì)象（比如龐大的 JSON、長(zhǎng)代碼輸出），因?yàn)樗鼈兿仍谏澈兄小案綦x”，然后只把必要內(nèi)容帶回主上下文。

隔離上下文就是給不同的信息設(shè)置“邊界”和“專(zhuān)屬空間”。無(wú)論是子 Agent 分工，還是工具沙盒執(zhí)行，都是在避免上下文混亂，讓每個(gè)環(huán)節(jié)的信息干凈、可控。

總結(jié)

上下文工程的四個(gè)動(dòng)作——寫(xiě)、選、壓、隔——并不是零散的技巧，而是一套系統(tǒng)方法。它們分別解決了信息丟失、信息冗余、信息過(guò)載和信息沖突的問(wèn)題。

當(dāng)這四個(gè)策略被系統(tǒng)化執(zhí)行，Agent 就能在復(fù)雜環(huán)境中穩(wěn)定運(yùn)行，從“看似聰明的 demo”成長(zhǎng)為“可靠的企業(yè)級(jí)系統(tǒng)”。這不僅僅是 prompt 的升級(jí)，而是大模型應(yīng)用走向工程化的必經(jīng)之路。

綜述

“上下文工程是一種觀念，而不是單一技術(shù)”

上下文工程（Context Engineering）并不是某一項(xiàng)具體的技術(shù)實(shí)現(xiàn)，它更像是一種貫穿整個(gè) Agent 設(shè)計(jì)與開(kāi)發(fā)的思想和方法論。它背后折射的是技術(shù)圈，尤其是一線工程師們，對(duì)未來(lái) AI 系統(tǒng)架構(gòu)趨勢(shì)的判斷。

正如 Dex Horthy 所說(shuō)：

“Even as models support longer and longer context windows, you’ll ALWAYS get better results with a small, focused prompt and context.”“即使模型支持越來(lái)越長(zhǎng)的上下文窗口，你仍然總是能用小而聚焦的提示與上下文獲得更好的結(jié)果?！?/p>

“長(zhǎng)上下文 ≠ 終極答案”

大模型的長(zhǎng)上下文窗口確實(shí)緩解了很多開(kāi)發(fā)難題：

你不必頻繁丟棄信息；也可以在更長(zhǎng)的對(duì)話中保持上下文。

但這遠(yuǎn)不是解決方案的全部。上下文工程提出的核心觀點(diǎn)就是：我們不應(yīng)該單純追求窗口更長(zhǎng)，而應(yīng)該追求上下文管理更聰明。

真正理想的系統(tǒng)，是能夠在發(fā)送給 LLM 的上下文里：

不多不少，恰到好處；

既不過(guò)載模型，也不遺漏關(guān)鍵信息。

“RAG 的新生命”

在這一點(diǎn)上，RAG（檢索增強(qiáng)生成）技術(shù)也并未過(guò)時(shí)，反而將在上下文工程的框架下迎來(lái)“第二春”。

如果說(shuō) LLM 是強(qiáng)大的推理引擎，那么 AI 應(yīng)用開(kāi)發(fā)的本質(zhì)，就是在海量信息中找到最合適的一小部分，并將其適配進(jìn)上下文窗口。

這個(gè)過(guò)程就像一個(gè)信息漏斗：

• 檢索：從海量數(shù)據(jù)中找到候選信息；
• 過(guò)濾：剔除冗余或無(wú)關(guān)內(nèi)容；
• 排序：把最相關(guān)的部分優(yōu)先送進(jìn)上下文。

上下文工程提供的正是這套完整的“信息篩選與注入機(jī)制”。

“微妙的藝術(shù)與科學(xué)”

因此，Context Engineering 既是一門(mén)工程技術(shù)，也是一門(mén)微妙的藝術(shù)。它要求我們?cè)趶?fù)雜的信息洪流中，精準(zhǔn)決定：

• Write —— 哪些信息該寫(xiě)入？
• Select —— 哪些信息需要選擇？
• Compress —— 哪些必須壓縮？
• Isolate —— 哪些應(yīng)該隔離？

正如 LangChain 博客中所總結(jié)的：