編輯 | 云昭

Prompt工程又“失效”了？！

之前是各種白領(lǐng)對(duì)它“喊打喊殺”，擔(dān)心它取代自己的工作，后來的口風(fēng)就變成了“大模型強(qiáng)大到不再需要Prompt工程了”，現(xiàn)在圈里又有谷歌的大佬拋出了神斷言，讓評(píng)論區(qū)炸鍋的那種。

今天一早，小編刷到一篇洗腦神文，差點(diǎn)以為這是新一輪的AI黑話洗腦包上線了。文章直呼：

“Prompt工程”格局小了，更大格局的“Context工程”才是大模型的王道。

不過細(xì)讀下來，小編并沒有作者其實(shí)是醉翁之意不在酒，更多還是再說構(gòu)建智能體時(shí)，上下文工程的重要性——

我們發(fā)現(xiàn)，決定智能體成敗的關(guān)鍵在于你賦予它的上下文的質(zhì)量。大多數(shù)智能體失敗不再是模型失敗，而是上下文失敗。

所謂“上下文工程”，它不是一句提示詞，它是一個(gè)系統(tǒng)工程。

一次廉價(jià)演示和一次神奇 AI 體驗(yàn)之間的差距，全在于——上下文的質(zhì)量。

Prompt不香了？Context Engineering又是哪個(gè)工程師發(fā)明的新名詞？

評(píng)論區(qū)一眾大廠和創(chuàng)業(yè)者都在喊“+1”。（后來小編搜了一下：新名詞的是Shopify CEO Tobi Lutke提出的，前OpenAI大神Karpathy也X轉(zhuǎn)帖了。）

這篇文章的作者也大有來頭，Google DeepMind的高級(jí)AI關(guān)系工程師Philipp Schmid。據(jù)悉，Schmid正在組建DeepMind的首個(gè)AI開發(fā)者關(guān)系團(tuán)隊(duì)，這個(gè)團(tuán)隊(duì)主要KPI就是輸出！而且輸出的是DeepMind的前沿AI研究成果！小編果斷關(guān)注了一波。

話不多說，直接上干貨。

1.大模型的新技能不是Prompt

原文標(biāo)題為《The New Skill in AI is Not Prompting, It's Context Engineering》，大體主張是：

與其再去研究“怎么寫提示詞（prompt）”，真正應(yīng)該關(guān)注的，是如何為 AI 組織一個(gè)完整、合適、動(dòng)態(tài)的上下文（context），這才是 Agent 成敗的關(guān)鍵。

可以說再一次把“Prompt”與“Contex”的引戰(zhàn)放到了明面上。當(dāng)然從評(píng)論區(qū)的效果上看，事實(shí)也的確如此。

相信大家都有這樣的“皺眉頭”經(jīng)歷：

費(fèi)勁寫了一段“完美Prompt”，希望AI給出精準(zhǔn)回答。（ps：想一想，你有沒有寫過這樣一個(gè)提示“做好這件事，獎(jiǎng)勵(lì)你1萬塊！”）但結(jié)果，AI模型卻就總是給出一個(gè)非常機(jī)械的、“缺少靈魂”的輸出。

對(duì)此，作者指出：為什么上下文比提示詞更重要了？

隨著 AI Agent（智能體）的崛起，我們輸入模型的“有限工作記憶”里到底裝了什么，變得比以往任何時(shí)候都更關(guān)鍵。（即：大模型就像一臺(tái)超強(qiáng)的語(yǔ)言引擎，但它的“記憶”有限，單靠一段話很難覆蓋復(fù)雜的業(yè)務(wù)需求和多維信息。結(jié)果就是，AI“答非所問”，或者機(jī)械死板，差強(qiáng)人意。）

現(xiàn)在，決定一個(gè) Agent 成敗的核心因素，不再是調(diào)用哪個(gè)大模型、寫了多花哨的提示詞，而是——你給它的上下文質(zhì)量夠不夠好。

2.Karpathy等許多大佬也認(rèn)同“上下文工程”

其實(shí)很多圈內(nèi)大神都贊同“上下文工程”而非“提示工程”。

前OpenAI、特斯拉的大神上個(gè)月就公開表示+1支持。

@karpathy

+1 支持“上下文工程（Context Engineering）”而非“提示工程（Prompt Engineering）”。

Karpathy 認(rèn)為，人們通常把“prompt”理解為日常使用LLM時(shí)輸入的一小段任務(wù)描述。而不同的是，在真正面向工業(yè)級(jí)應(yīng)用的 LLM 系統(tǒng)中，上下文工程是一門微妙而復(fù)雜的“填充上下文窗口”的藝術(shù)與科學(xué)。

圖片

大神還進(jìn)一步解釋了為什么既是科學(xué)又是藝術(shù)？

為什么說是科學(xué)？因?yàn)樽龊眠@件事涉及：任務(wù)說明與解釋、Few-shot 示例、RAG 檢索、相關(guān)數(shù)據(jù)（可能是多模態(tài)的）、工具、狀態(tài)、歷史記錄、信息壓縮等。信息太少或格式不對(duì)，LLM 就拿不到做出好回應(yīng)的材料；信息太多或不相關(guān)，則會(huì)推高成本，反而拉低性能。

為什么說是藝術(shù)？因?yàn)槟阈枰揽繉?duì)“模型心理”的直覺來構(gòu)建合理的輸入。

除了上下文工程之外，Karpathy認(rèn)為大模型還有很多問題需要解決，比如：

• 正確地拆解問題形成控制流程
• 恰當(dāng)?shù)卮虬舷挛拇翱?/li>
• 調(diào)度不同類型和能力的模型
• 搭建生成與驗(yàn)證的 UI/UX 流程
• 還有更多：安全機(jī)制、性能評(píng)估、并行處理、預(yù)取緩存……

所以，Context Engineering 只是構(gòu)建一個(gè)完整 LLM 應(yīng)用所需的厚重軟件層中的一小部分而已。

Karpathy指出，“ChatGPT 套殼器”這個(gè)說法已經(jīng)過時(shí)，甚至是完全錯(cuò)誤的。

而Karpathy點(diǎn)贊的這則帖子正是另一位大佬——

白天當(dāng)CEO、夜間當(dāng)黑客的“通才”，Shopify 的掌門人Tobi，在X上，他發(fā)表了自己的看法：

我真的很喜歡“上下文工程”這個(gè)術(shù)語(yǔ)，而并非“提示工程”。

原因是，它更好地描述了核心技能：為大模型提供充分的上下文背景，使得 LLM 有可能合理地解決任務(wù)，這是一門藝術(shù)。

圖片

此外，許多評(píng)論者也分享了自己在實(shí)際應(yīng)用中的見解：

完全同意。現(xiàn)在你幾乎很難再靠那種“如果你答對(duì)我就給你 100 美元”之類的小聰明來提升模型性能了——本來就應(yīng)該如此。

真正的優(yōu)勢(shì)在于：你是否能精心構(gòu)建上下文，幫模型最大程度減少“戰(zhàn)爭(zhēng)迷霧”。它正在趨近于人類式的信息需求。

圖片

3.上下文沒那么簡(jiǎn)單，包含7部分

要理解“上下文工程”，我們得先重新定義“上下文”這個(gè)詞。

它不是你發(fā)給 LLM 的一句話。作者指出：

你可以把它想象成模型在生成回答之前，所能看到的一切信息：

作者將上下文的構(gòu)成分成了 7 部分：

• 系統(tǒng)指令 / 初始提示（System Prompt）：在對(duì)話開始時(shí)，預(yù)先定義模型行為的一組說明，可包含示例、規(guī)則等。
• 用戶提示（User Prompt）：用戶當(dāng)下發(fā)出的任務(wù)或問題。
• 短期記憶 / 對(duì)話歷史（State / History）：當(dāng)前對(duì)話中的來龍去脈，包括之前的提問與回應(yīng)。
• 長(zhǎng)期記憶（Long-Term Memory）：模型跨會(huì)話記住的持久信息，例如用戶偏好、項(xiàng)目摘要、背景知識(shí)等。
• 檢索信息（RAG）：來自外部文檔、數(shù)據(jù)庫(kù)或 API 的實(shí)時(shí)信息，用于增強(qiáng)模型回答。
• 可用工具（Available Tools）：模型可調(diào)用的函數(shù)或工具列表，如 ??check_inventory???、??send_email??。
• 結(jié)構(gòu)化輸出格式（Structured Output）：定義模型回答的格式，比如 JSON 模板或結(jié)構(gòu)體。

圖片

好的上下文 ≠ 靠 LLM 猜，而是靠系統(tǒng)主動(dòng)“喂”進(jìn)去該知道的一切。 

4.從“廉價(jià)Demo”到“神奇AI”的關(guān)鍵

真正打造出一個(gè)可靠、有用的 AI Agent，核心不在于代碼多復(fù)雜，也不在于使用了什么花哨的框架，而在于你給它什么上下文。

想象這個(gè)簡(jiǎn)單例子：

有人發(fā)來一封郵件：Hey, just checking if you’re around for a quick sync tomorrow.（嘿，想問問你明天能不能快速聊一下。）

對(duì)于一個(gè) Agent 而言，它能看到的上下文只有用戶剛發(fā)來的這句話，于是它冷冰冰地回應(yīng)：

Thank you for your message. Tomorrow works for me. May I ask what time you had in mind?（謝謝你的信息，明天對(duì)我來說可以。你想定幾點(diǎn)呢？）

邏輯沒錯(cuò)，但像極了“機(jī)器人在敷衍人類”，沒錯(cuò)這水平也就是個(gè)廉價(jià)的Demo。

但，如果有了足夠豐富的上下文，比如我們把日程表、對(duì)方的郵件來往記錄、聯(lián)系人信息、自動(dòng)回復(fù)郵件等工具都喂給它——

我們就可以見證奇跡：神奇 AI（Magical Agent）誕生了！它的回應(yīng)就像一個(gè)會(huì)來事兒的真人：

上下文包含：

• 你的日程表（顯示你明天全天爆滿）
• 你和對(duì)方以往的郵件記錄（判斷用語(yǔ)是否需要隨意一些）
• 聯(lián)系人信息（識(shí)別出對(duì)方是關(guān)鍵合作伙伴）
• 可用工具（比如發(fā)出邀請(qǐng)、自動(dòng)回復(fù)郵件）

最終生成的回應(yīng)是：

Hey Jim! Tomorrow’s packed on my end, back-to-back all day. Thursday AM free if that works for you? Sent an invite, lmk if it works.（嘿 Jim！我明天全天都排滿了。周四上午有空，合適嗎？我已經(jīng)發(fā)了個(gè)邀請(qǐng)，看看是否合適。）

神奇不是因?yàn)橛昧烁斆鞯哪Ｐ停且驗(yàn)?strong>上下文到位了。所以，Agent 的失敗，更多是上下文失敗，而不是模型失敗。

5.從提示工程轉(zhuǎn)向上下文工程，有何不同？

現(xiàn)在，我們可以回答兩者到底有什么不同了。

如果說提示詞工程是想寫出“一句話打動(dòng)模型”，那么上下文工程是一門系統(tǒng)工程學(xué)科。

首先，來看定義（更接地氣地講）：

上下文工程（Context Engineering）是設(shè)計(jì)和構(gòu)建動(dòng)態(tài)系統(tǒng)的一門學(xué)問，目標(biāo)是在正確的時(shí)間、以正確的格式，向大模型提供完成任務(wù)所需的一切信息和工具。

它的核心特征有 4 個(gè)：

• 系統(tǒng)，而不是字符串：不是靜態(tài)的模板，而是在調(diào)用 LLM 之前動(dòng)態(tài)生成的結(jié)果。
• 動(dòng)態(tài)、按需生成：對(duì)一個(gè)請(qǐng)求來說，也許上下文是日程表；另一個(gè)請(qǐng)求可能需要最近的網(wǎng)頁(yè)搜索或郵件往來。
• 信息與工具，剛剛好地送達(dá)：避免垃圾進(jìn)垃圾出（Garbage In, Garbage Out），只提供任務(wù)真正需要的信息與能力。
• 格式也很關(guān)鍵：與其丟一堆生肉數(shù)據(jù)，不如給出提煉后的摘要；工具調(diào)用格式清晰，勝過模糊提示。

即，作者提出，只有為 LLM 提供恰當(dāng)且動(dòng)態(tài)組合的信息、工具和指令，才能讓 AI 真正理解并高效完成復(fù)雜任務(wù)。所以，要構(gòu)建強(qiáng)大、穩(wěn)定的 AI Agent，不再是靠“提示詞魔法”或“換個(gè)大模型”，而是靠“上下文工程”：

在正確的時(shí)間，把正確的信息與工具，以正確的格式，放進(jìn)模型的腦子里。

而這是一項(xiàng)跨學(xué)科挑戰(zhàn)，既需要理解業(yè)務(wù)場(chǎng)景，也需要明確目標(biāo)輸出，更需要設(shè)計(jì)清晰的信息結(jié)構(gòu)，讓語(yǔ)言模型真正完成任務(wù)。

6.網(wǎng)友熱議：造新詞兒？

對(duì)于上下文工程，一位谷歌的同事（巧了，也叫菲利普，也是作者團(tuán)隊(duì)的人員，Google DeepMind AI 開發(fā)者關(guān)系負(fù)責(zé)人），開始在 Karpathy 的評(píng)論區(qū)下面調(diào)侃：上下文工程是新的“氛圍編程”！

圖片

Karpathy 回應(yīng)：哈哈，我不是想造個(gè)新詞什么的。

哈哈我不是在發(fā)明新詞，只是覺得人們對(duì)“prompt”的理解太過簡(jiǎn)單化，低估了其復(fù)雜性。

“你提示 LLM 回答“天空為什么是藍(lán)色”，那是 prompt。但真正的 AI 應(yīng)用不是一句話提示，而是精心構(gòu)建一整個(gè)上下文環(huán)境，讓 LLM 去完成定制化任務(wù)。”

圖片

此外，相關(guān)評(píng)論還探討了“context rot”、動(dòng)態(tài)信息檢索、如何進(jìn)行有效評(píng)估以及 AI 項(xiàng)目的落地技巧。 

圖片

當(dāng)然，更多在做Agent產(chǎn)品開發(fā)的人表示深度認(rèn)可：上下文才是真正的杠桿！

@0xCapx（Agent 應(yīng)用創(chuàng)業(yè)公司）

當(dāng) Agent 來運(yùn)營(yíng)一家企業(yè)時(shí)，上下文就不再是“錦上添花”，而是“系統(tǒng)架構(gòu)”本身。

@The_Utility_Co（Web3自動(dòng)化創(chuàng)業(yè)團(tuán)隊(duì)）

100% 認(rèn)同。Prompt 只是“你好”，Context 是你的人生故事、Spotify 歌單、甚至銀行賬戶信息。

當(dāng)我們將 LLM 接入 Web3 自動(dòng)化系統(tǒng)時(shí)，大部分工作其實(shí)都在策劃好傳感器數(shù)據(jù)、DAO 信號(hào)、鏈上信息的上下文輸入，這樣模型才能“真正做事”，而不是只會(huì)“聊天”。

真正的杠桿在于上下文工程。

7.老瓶裝新酒？技術(shù)本質(zhì)都是黑盒巫術(shù)

不過，也有人為，prompt 和 context 有點(diǎn)強(qiáng)分彼此，區(qū)別不大，只是表達(dá)不同。（言外之意，老瓶裝新酒，為了造 buzz。）

所謂“context engineering”只是把 prompt 拆成多個(gè)來源組合而已，本質(zhì)還是 prompt engineering。

多位評(píng)論者指出：“prompt” 和 “context” 在技術(shù)上本質(zhì)是一回事，都是輸入模型的 Token 序列。

模型并不區(qū)分你是通過“用戶輸入”還是“上下文歷史”送進(jìn)來的內(nèi)容。

一位開發(fā)者更是總結(jié)得很直白：“你完全可以把 context 整個(gè)打包成 prompt 發(fā)進(jìn)去，對(duì)模型沒區(qū)別。”

還有網(wǎng)友強(qiáng)調(diào)：“magic”背后依然離不開編程和理解模型原理，也有人批評(píng)上下文工程很容易變成一種“玄學(xué)”炒作。

簡(jiǎn)單的理解，不管叫 prompt 還是 context，都是黑盒巫術(shù)本質(zhì)還是“try and see”。

還有網(wǎng)友調(diào)侃：LLM 是非確定性機(jī)器，結(jié)果不穩(wěn)定、重復(fù)性不強(qiáng)，所謂“工程”不過是“調(diào)參的藝術(shù)”。

圖片

8.寫在最后：Prompt 淡出或是必然

在小編看來，提詞工程的淡出（產(chǎn)品化），上下文工程興起，已經(jīng)是一種趨勢(shì)。

首先，產(chǎn)品側(cè)來看，隨著 RAG、Agent、AutoChain 等機(jī)制普及，開發(fā)者越來越依賴工具自動(dòng)構(gòu)建 prompt，而不是手寫 prompt。

“好 prompt” 越來越像產(chǎn)品的功能，而非用戶的技能。

其次，模型側(cè)來分析。模型 token window 增大，但 context 變長(zhǎng)后“腐爛”（context rot）問題日漸凸顯。

圖片

對(duì)于我們而言，如何管理、組織、剪裁 context 成為下一步挑戰(zhàn)。

正如一位Hackernews的網(wǎng)友 Drew Breunig 所提到了一些關(guān)鍵技術(shù)：Context Quarantine、Tool Loadout、Summarization 等。

當(dāng)然，不管是提示詞工程，還是上下文工程，小編認(rèn)為——哪個(gè)都不是萬能的！

“即使你有 memory bank，有 plugin，最終還是得人類自己寫代碼。”

參考鏈接：

??https://x.com/tobi/status/1935533422589399127??

??https://x.com/karpathy/status/1937909397180796982??

本文轉(zhuǎn)載自??51CTO技術(shù)棧??，作者：云昭