「上下文工程」硅谷爆火,Karpathy親自站臺(tái)!提示工程瞬間失寵
硅谷如今炙手可熱的,不再是提示詞工程,而是上下文工程(Context Engineering)!
就連AI大神Karpathy,都為「上下文工程」投下了一票。

還有Shopify CEO Tobias Lütke稱,自己更喜歡「上下文工程」,因其準(zhǔn)確描述了一個(gè)核心技能——
通過為任務(wù)提供完整的背景信息,讓大模型能夠合理解決問題的藝術(shù)。

一夜之間,「上下文工程」紅遍全網(wǎng),究竟是為什么?

上下文工程,一夜爆紅
這背后原因,離不開AI智能體的興起。
OpenAI總裁Greg Brockman多次公開表示,「2025年,是AI智能體的元年」。

決定智能體成功或失敗最關(guān)鍵的因素,是提供的「上下文質(zhì)量」。也就是說,加載到「有限工作記憶」中的信息愈加重要。
大多數(shù)AI智能體失敗的案例,不是模型的失敗,而是上下文的失??!
那么,什么是上下文?

要理解「上下文工程」,首先需要擴(kuò)展「上下文」的定義。
它不僅僅是你發(fā)送給LLM的單一提示,可以將其視為「模型再生成響應(yīng)之前,看到的所有內(nèi)容」,如下:
- 指令/系統(tǒng)提示:定義模型在對(duì)話中行為的初始指令集,可以/應(yīng)該包括示例、規(guī)則等。
 - 用戶提示:用戶的即時(shí)任務(wù)或問題。
 - 狀態(tài)/歷史(短期記憶):當(dāng)前對(duì)話,包括用戶和模型的響應(yīng),截至此刻。
 - 長(zhǎng)期記憶:跨多次之前對(duì)話收集的持久知識(shí)庫(kù),包含學(xué)習(xí)到的用戶偏好、過去項(xiàng)目的摘要或要求記住以備將來使用的事實(shí)。
 - 檢索信息(RAG):外部、實(shí)時(shí)的知識(shí),來自文檔、數(shù)據(jù)庫(kù)或API的相關(guān)信息,用于回答特定問題。
 - 可用工具:模型可以調(diào)用的所有功能或內(nèi)置工具的定義,比如check_inventory、send_email。
 - 結(jié)構(gòu)化輸出:模型響應(yīng)格式的定義,例如JSON對(duì)象。
 
可以看出,與專注于在單一本文字符串中,精心構(gòu)建完美指令的「提示詞工程」不同,「上下文工程」的范疇要廣泛得多。

簡(jiǎn)單來說:
「上下文工程」是一門學(xué)科,它致力于設(shè)計(jì)和構(gòu)建動(dòng)態(tài)系統(tǒng)。
這些系統(tǒng)能夠在恰當(dāng)?shù)臅r(shí)機(jī)、以恰當(dāng)?shù)母袷剑峁┣‘?dāng)?shù)男畔⒑凸ぞ?,從而讓LLM擁有完成任務(wù)所需的一切。
以下是「上下文工程」的所有特點(diǎn)
· 它是一個(gè)系統(tǒng),而非一個(gè)字符串:上下文并非一個(gè)靜態(tài)的提示詞模板,而是一個(gè)系統(tǒng)的輸出,這個(gè)系統(tǒng)在對(duì)LLM進(jìn)行主調(diào)用之前就已經(jīng)運(yùn)行。
· 它是動(dòng)態(tài)的:上下文是即時(shí)生成的,為當(dāng)前任務(wù)量身定制。比如,某個(gè)請(qǐng)求可能需要的是日歷數(shù)據(jù),而另一個(gè)請(qǐng)求則可能需要電子郵件內(nèi)容或網(wǎng)絡(luò)搜索結(jié)果。
· 它強(qiáng)調(diào)在恰當(dāng)時(shí)機(jī)提供恰當(dāng)信息與工具:其核心任務(wù)是確保模型不會(huì)遺漏關(guān)鍵細(xì)節(jié)(謹(jǐn)記「垃圾進(jìn),垃圾出」原則)。這意味著只在必要且有益的情況下,才向模型提供知識(shí)(信息)和能力(工具)。
· 它注重格式:信息的呈現(xiàn)方式至關(guān)重要。一份簡(jiǎn)潔的摘要遠(yuǎn)勝于原始數(shù)據(jù)的羅列;一個(gè)清晰的工具接口定義也遠(yuǎn)比一條模糊的指令有效。

是一門科學(xué),也是一門藝術(shù)
Karpathy長(zhǎng)文點(diǎn)評(píng)中,同樣認(rèn)為「上下文工程」是藝術(shù)的一種。
人們往往將提示詞(prompt),聯(lián)想為日常使用中——發(fā)給LLM的簡(jiǎn)短任務(wù)描述。
然而,在任何一個(gè)工業(yè)級(jí)的 LLM 應(yīng)用中,上下文工程都是一門精深的科學(xué),也是一門巧妙的藝術(shù)。
其核心在于,為下一步操作,用恰到好處的信息精準(zhǔn)填充上下文窗口。

說它是科學(xué),是因?yàn)橐龊眠@一點(diǎn),需要綜合運(yùn)用一系列技術(shù),其中包括:
任務(wù)描述與解釋、少樣本學(xué)習(xí)示例、RAG(檢索增強(qiáng)生成)、相關(guān)的(可能是多模態(tài)的)數(shù)據(jù)、工具、狀態(tài)與歷史記錄、信息壓縮等等。
信息太少或格式錯(cuò)誤,LLM就沒有足夠的上下文來達(dá)到最佳性能;
信息太多或關(guān)聯(lián)性不強(qiáng),又會(huì)導(dǎo)致LLM的成本上升、性能下降。
要做好這一點(diǎn)是頗為復(fù)雜的。
說它是藝術(shù),則是因?yàn)槠渲行枰蕾囬_發(fā)者對(duì)大模型「脾性」的直覺把握和引導(dǎo)。
除了上下文工程本身,一個(gè)LLM應(yīng)用還必須做到:
- 將問題恰到好處地拆解成控制流
 - 精準(zhǔn)地填充上下文窗口
 - 將調(diào)用請(qǐng)求分派給類型和能力都合適的LLM
 - 處理「生成-驗(yàn)證」的UIUX流程
 - 以及更多——例如安全護(hù)欄、系統(tǒng)安全、效果評(píng)估、并行處理、數(shù)據(jù)預(yù)取等等…
 
因此,「上下文工程」只是一個(gè)正在興起的、厚重且復(fù)雜的軟件層中的一小部分。
這個(gè)軟件層負(fù)責(zé)將單個(gè)的LLM調(diào)用,以及更多其他操作整合協(xié)調(diào),從而構(gòu)建出完整的LLM應(yīng)用。
Karpathy表示,把這類應(yīng)用輕率地稱為「ChatGPT的套殼」,這種說法不僅老掉牙了,而且大錯(cuò)特錯(cuò)。
有網(wǎng)友對(duì)此調(diào)侃道,上下文工程,是全新的「氛圍編程」。
Karpathy回應(yīng)稱,「我倒不是想自創(chuàng)個(gè)新詞什么的。我只是覺得,大家一提到「提示詞」,就容易把一個(gè)其實(shí)相當(dāng)復(fù)雜的組件給想簡(jiǎn)單了」。
你會(huì)用一個(gè)提示詞去問LLM「天空為什么是藍(lán)色的」。但應(yīng)用程序呢,則是需要為大模型構(gòu)建上下文,才能解決那些為它量身定制的任務(wù)。

智能體成敗,全靠它了
其實(shí),打造真正高效的AI智能體秘訣,關(guān)鍵不在于編寫的代碼有多復(fù)雜,而在于你所提供的上下文有多優(yōu)質(zhì)。
一個(gè)效果粗糙的演示產(chǎn)品,同一個(gè)表現(xiàn)驚艷的智能體,其根本區(qū)別就在于提供的上下文質(zhì)量。
想象一下,一個(gè)AI助理需要根據(jù)一封簡(jiǎn)單的郵件來安排會(huì)議:
嘿,想問下你明天有空簡(jiǎn)單碰個(gè)頭嗎?
「粗糙的演示」智能體獲得的上下文很貧乏。它只能看到用戶的請(qǐng)求,別的什么都不知道。
它的代碼可能功能齊全——調(diào)用一個(gè)LLM并獲得響應(yīng),但輸出的結(jié)果卻毫無幫助,而且非常機(jī)械化:
感謝您的消息。我明天可以。請(qǐng)問您想約在什么時(shí)間?
接下來,再看看由豐富的上下文加持的驚艷智能體。
其代碼的主要任務(wù)并非是思考如何回復(fù),而是去收集LLM達(dá)成目標(biāo)所需的信息。在調(diào)用LLM之前,你會(huì)將上下文擴(kuò)展,使其包含:
代碼的主要工作,不是決定如何響應(yīng),而是收集LLM完成目標(biāo)所需的信息。
在調(diào)用LLM之前,你會(huì)擴(kuò)展上下文,包括:
- 日歷信息:顯示你全天都排滿了
 - 與此人的過去郵件:用來判斷應(yīng)該使用何種非正式語氣
 - 聯(lián)系人列表:用來識(shí)別出對(duì)方是一位重要合作伙伴
 - 用于send_invite或send_email的工具
 
然后,你就可以生成這樣的回復(fù):
嘿,Jim!我明天日程完全排滿了,會(huì)議一個(gè)接一個(gè)。周四上午我有空,你看方便嗎?邀請(qǐng)已經(jīng)發(fā)給你了,看這個(gè)時(shí)間行不行哈。
這種驚艷的效果,其奧秘不在于模型更智能,或算法更高明,而在于為正確的任務(wù)提供了正確的上下文。
這正是「上下文工程」將變得至關(guān)重要的原因。
所以說,智能體的失敗,不只是模型的失敗,更是上下文的失敗。
要構(gòu)建強(qiáng)大而可靠的 AI 智能體,我們正逐漸擺脫對(duì)尋找「萬能提示詞」,或依賴模型更新的路徑。
這一點(diǎn),深得網(wǎng)友的認(rèn)同。

其核心在于對(duì)上下文的工程化構(gòu)建:即在恰當(dāng)?shù)臅r(shí)機(jī)、以恰當(dāng)?shù)母袷?,提供恰?dāng)?shù)男畔⒑凸ぞ摺?/span>
這是一項(xiàng)跨職能的挑戰(zhàn),它要求我們深入理解業(yè)務(wù)用例、明確定義輸出,并精心組織所有必要信息,從而使LLM能夠真正「完成任務(wù)」。
最后,借用網(wǎng)友一句話,「記憶」才是AGI拼圖的最后一塊。
















 
 
 

















 
 
 
 