編輯 | 云昭

Prompt工程又“失效”了？！

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

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

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

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

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

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

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

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

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

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

話不多說，直接上干貨。

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

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

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

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

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

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

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

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

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

2.Karpathy等許多大佬也認同“上下文工程”

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

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

@karpathy

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

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

圖片

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

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

為什么說是藝術(shù)？因為你需要依靠對“模型心理”的直覺來構(gòu)建合理的輸入。

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

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

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

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

而Karpathy點贊的這則帖子正是另一位大佬——

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

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

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

圖片

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

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

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

圖片

3.上下文沒那么簡單，包含7部分

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

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

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

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

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

圖片

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

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

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

想象這個簡單例子：

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

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

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

邏輯沒錯，但像極了“機器人在敷衍人類”，沒錯這水平也就是個廉價的Demo。

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

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

上下文包含：

• 你的日程表（顯示你明天全天爆滿）
• 你和對方以往的郵件記錄（判斷用語是否需要隨意一些）
• 聯(lián)系人信息（識別出對方是關(guān)鍵合作伙伴）
• 可用工具（比如發(fā)出邀請、自動回復(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ā)了個邀請，看看是否合適。）

神奇不是因為用了更聰明的模型，而是因為上下文到位了。所以，Agent 的失敗，更多是上下文失敗，而不是模型失敗。

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

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

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

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

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

它的核心特征有 4 個：

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

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

在正確的時間，把正確的信息與工具，以正確的格式，放進模型的腦子里。

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

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

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

圖片

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

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

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

圖片

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

圖片

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

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

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

@The_Utility_Co（Web3自動化創(chuàng)業(yè)團隊）

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

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

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

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

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

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

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

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

一位開發(fā)者更是總結(jié)得很直白：“你完全可以把 context 整個打包成 prompt 發(fā)進去，對模型沒區(qū)別?！?/span>

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

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

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

圖片

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

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

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

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

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

圖片

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

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

當然，不管是提示詞工程，還是上下文工程，小編認為——哪個都不是萬能的！

“即使你有 memory bank，有 plugin，最終還是得人類自己寫代碼?！?/p>

參考鏈接：

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

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