編輯 | 云昭
Prompt工程又“失效”了？！
之前是各種白領對它“喊打喊殺”，擔心它取代自己的工作，后來的口風就變成了“大模型強大到不再需要Prompt工程了”，現在圈里又有谷歌的大佬拋出了神斷言，讓評論區炸鍋的那種。
今天一早，小編刷到一篇洗腦神文，差點以為這是新一輪的AI黑話洗腦包上線了。文章直呼：
“Prompt工程”格局小了，更大格局的“Context工程”才是大模型的王道。
不過細讀下來，小編并沒有作者其實是醉翁之意不在酒，更多還是再說構建智能體時，上下文工程的重要性——
我們發現，決定智能體成敗的關鍵在于你賦予它的上下文的質量。大多數智能體失敗不再是模型失敗，而是上下文失敗。
所謂“上下文工程”，它不是一句提示詞，它是一個系統工程。
一次廉價演示和一次神奇 AI 體驗之間的差距，全在于——上下文的質量。
Prompt不香了？Context Engineering又是哪個工程師發明的新名詞？
評論區一眾大廠和創業者都在喊“+1”。（后來小編搜了一下：新名詞的是Shopify CEO Tobi Lutke提出的，前OpenAI大神Karpathy也X轉帖了。）
這篇文章的作者也大有來頭，Google DeepMind的高級AI關系工程師Philipp Schmid。據悉，Schmid正在組建DeepMind的首個AI開發者關系團隊，這個團隊主要KPI就是輸出！而且輸出的是DeepMind的前沿AI研究成果！小編果斷關注了一波。
話不多說，直接上干貨。
1.大模型的新技能不是Prompt
原文標題為《The New Skill in AI is Not Prompting, It's Context Engineering》，大體主張是：
與其再去研究“怎么寫提示詞（prompt）”，真正應該關注的，是如何為 AI 組織一個完整、合適、動態的上下文（context），這才是 Agent 成敗的關鍵。
可以說再一次把“Prompt”與“Contex”的引戰放到了明面上。當然從評論區的效果上看，事實也的確如此。
相信大家都有這樣的“皺眉頭”經歷：
費勁寫了一段“完美Prompt”，希望AI給出精準回答。（ps：想一想，你有沒有寫過這樣一個提示“做好這件事，獎勵你1萬塊！”）但結果，AI模型卻就總是給出一個非常機械的、“缺少靈魂”的輸出。
對此，作者指出：為什么上下文比提示詞更重要了？
隨著 AI Agent（智能體）的崛起，我們輸入模型的“有限工作記憶”里到底裝了什么，變得比以往任何時候都更關鍵。（即：大模型就像一臺超強的語言引擎，但它的“記憶”有限，單靠一段話很難覆蓋復雜的業務需求和多維信息。結果就是，AI“答非所問”，或者機械死板，差強人意。）
現在，決定一個 Agent 成敗的核心因素，不再是調用哪個大模型、寫了多花哨的提示詞，而是——你給它的上下文質量夠不夠好。
2.Karpathy等許多大佬也認同“上下文工程”
其實很多圈內大神都贊同“上下文工程”而非“提示工程”。
前OpenAI、特斯拉的大神上個月就公開表示+1支持。
@karpathy
+1 支持“上下文工程（Context Engineering）”而非“提示工程（Prompt Engineering）”。
Karpathy 認為，人們通常把“prompt”理解為日常使用LLM時輸入的一小段任務描述。而不同的是，在真正面向工業級應用的 LLM 系統中，上下文工程是一門微妙而復雜的“填充上下文窗口”的藝術與科學。
圖片
大神還進一步解釋了為什么既是科學又是藝術？
為什么說是科學？因為做好這件事涉及：任務說明與解釋、Few-shot 示例、RAG 檢索、相關數據（可能是多模態的）、工具、狀態、歷史記錄、信息壓縮等。信息太少或格式不對，LLM 就拿不到做出好回應的材料；信息太多或不相關，則會推高成本，反而拉低性能。
為什么說是藝術？因為你需要依靠對“模型心理”的直覺來構建合理的輸入。
除了上下文工程之外，Karpathy認為大模型還有很多問題需要解決，比如：
- 正確地拆解問題形成控制流程
- 恰當地打包上下文窗口
- 調度不同類型和能力的模型
- 搭建生成與驗證的 UI/UX 流程
- 還有更多：安全機制、性能評估、并行處理、預取緩存……
所以，Context Engineering 只是構建一個完整 LLM 應用所需的厚重軟件層中的一小部分而已。
Karpathy指出，“ChatGPT 套殼器”這個說法已經過時，甚至是完全錯誤的。
而Karpathy點贊的這則帖子正是另一位大佬——
白天當CEO、夜間當黑客的“通才”，Shopify 的掌門人Tobi，在X上，他發表了自己的看法：
我真的很喜歡“上下文工程”這個術語，而并非“提示工程”。
原因是，它更好地描述了核心技能：為大模型提供充分的上下文背景，使得 LLM 有可能合理地解決任務，這是一門藝術。
圖片
此外，許多評論者也分享了自己在實際應用中的見解：
完全同意。現在你幾乎很難再靠那種“如果你答對我就給你 100 美元”之類的小聰明來提升模型性能了——本來就應該如此。
真正的優勢在于：你是否能精心構建上下文，幫模型最大程度減少“戰爭迷霧”。它正在趨近于人類式的信息需求。
圖片
3.上下文沒那么簡單，包含7部分
要理解“上下文工程”，我們得先重新定義“上下文”這個詞。
它不是你發給 LLM 的一句話。作者指出：
你可以把它想象成模型在生成回答之前，所能看到的一切信息：
作者將上下文的構成分成了 7 部分：
- 系統指令 / 初始提示（System Prompt）：在對話開始時，預先定義模型行為的一組說明，可包含示例、規則等。
- 用戶提示（User Prompt）：用戶當下發出的任務或問題。
- 短期記憶 / 對話歷史（State / History）：當前對話中的來龍去脈，包括之前的提問與回應。
- 長期記憶（Long-Term Memory）：模型跨會話記住的持久信息，例如用戶偏好、項目摘要、背景知識等。
- 檢索信息（RAG）：來自外部文檔、數據庫或 API 的實時信息，用于增強模型回答。
- 可用工具（Available Tools）：模型可調用的函數或工具列表，如
check_inventory、send_email。 - 結構化輸出格式（Structured Output）：定義模型回答的格式，比如 JSON 模板或結構體。
圖片
好的上下文 ≠ 靠 LLM 猜，而是靠系統主動“喂”進去該知道的一切。
4.從“廉價Demo”到“神奇AI”的關鍵
真正打造出一個可靠、有用的 AI Agent，核心不在于代碼多復雜，也不在于使用了什么花哨的框架，而在于你給它什么上下文。
想象這個簡單例子：
有人發來一封郵件：Hey, just checking if you’re around for a quick sync tomorrow.（嘿，想問問你明天能不能快速聊一下。）
對于一個 Agent 而言，它能看到的上下文只有用戶剛發來的這句話，于是它冷冰冰地回應：
Thank you for your message. Tomorrow works for me. May I ask what time you had in mind?（謝謝你的信息，明天對我來說可以。你想定幾點呢？）
邏輯沒錯，但像極了“機器人在敷衍人類”，沒錯這水平也就是個廉價的Demo。
但，如果有了足夠豐富的上下文，比如我們把日程表、對方的郵件來往記錄、聯系人信息、自動回復郵件等工具都喂給它——
我們就可以見證奇跡：神奇 AI（Magical Agent）誕生了！它的回應就像一個會來事兒的真人：
上下文包含：
- 你的日程表（顯示你明天全天爆滿）
- 你和對方以往的郵件記錄（判斷用語是否需要隨意一些）
- 聯系人信息（識別出對方是關鍵合作伙伴）
- 可用工具（比如發出邀請、自動回復郵件）
最終生成的回應是：
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！我明天全天都排滿了。周四上午有空，合適嗎？我已經發了個邀請，看看是否合適。）
神奇不是因為用了更聰明的模型，而是因為上下文到位了。所以，Agent 的失敗，更多是上下文失敗，而不是模型失敗。
5.從提示工程轉向上下文工程，有何不同？
現在，我們可以回答兩者到底有什么不同了。
如果說提示詞工程是想寫出“一句話打動模型”，那么上下文工程是一門系統工程學科。
首先，來看定義（更接地氣地講）：
上下文工程（Context Engineering）是設計和構建動態系統的一門學問，目標是在正確的時間、以正確的格式，向大模型提供完成任務所需的一切信息和工具。
它的核心特征有 4 個：
- 系統，而不是字符串：不是靜態的模板，而是在調用 LLM 之前動態生成的結果。
- 動態、按需生成：對一個請求來說，也許上下文是日程表；另一個請求可能需要最近的網頁搜索或郵件往來。
- 信息與工具，剛剛好地送達：避免垃圾進垃圾出（Garbage In, Garbage Out），只提供任務真正需要的信息與能力。
- 格式也很關鍵：與其丟一堆生肉數據，不如給出提煉后的摘要；工具調用格式清晰，勝過模糊提示。
即，作者提出，只有為 LLM 提供恰當且動態組合的信息、工具和指令，才能讓 AI 真正理解并高效完成復雜任務。所以，要構建強大、穩定的 AI Agent，不再是靠“提示詞魔法”或“換個大模型”，而是靠“上下文工程”：
在正確的時間，把正確的信息與工具，以正確的格式，放進模型的腦子里。
而這是一項跨學科挑戰，既需要理解業務場景，也需要明確目標輸出，更需要設計清晰的信息結構，讓語言模型真正完成任務。
6.網友熱議：造新詞兒？
對于上下文工程，一位谷歌的同事（巧了，也叫菲利普，也是作者團隊的人員，Google DeepMind AI 開發者關系負責人），開始在 Karpathy 的評論區下面調侃：上下文工程是新的“氛圍編程”！
圖片
Karpathy 回應：哈哈，我不是想造個新詞什么的。
哈哈我不是在發明新詞，只是覺得人們對“prompt”的理解太過簡單化，低估了其復雜性。
“你提示 LLM 回答“天空為什么是藍色”，那是 prompt。但真正的 AI 應用不是一句話提示，而是精心構建一整個上下文環境，讓 LLM 去完成定制化任務。”
圖片
此外，相關評論還探討了“context rot”、動態信息檢索、如何進行有效評估以及 AI 項目的落地技巧。
圖片
當然，更多在做Agent產品開發的人表示深度認可：上下文才是真正的杠桿！
@0xCapx（Agent 應用創業公司）
當 Agent 來運營一家企業時，上下文就不再是“錦上添花”，而是“系統架構”本身。
@The_Utility_Co（Web3自動化創業團隊）
100% 認同。Prompt 只是“你好”，Context 是你的人生故事、Spotify 歌單、甚至銀行賬戶信息。
當我們將 LLM 接入 Web3 自動化系統時，大部分工作其實都在策劃好傳感器數據、DAO 信號、鏈上信息的上下文輸入，這樣模型才能“真正做事”，而不是只會“聊天”。
真正的杠桿在于上下文工程。
7.老瓶裝新酒？技術本質都是黑盒巫術
不過，也有人為，prompt 和 context 有點強分彼此，區別不大，只是表達不同。（言外之意，老瓶裝新酒，為了造 buzz。）
所謂“context engineering”只是把 prompt 拆成多個來源組合而已，本質還是 prompt engineering。
多位評論者指出：“prompt” 和 “context” 在技術上本質是一回事，都是輸入模型的 Token 序列。
模型并不區分你是通過“用戶輸入”還是“上下文歷史”送進來的內容。
一位開發者更是總結得很直白：“你完全可以把 context 整個打包成 prompt 發進去，對模型沒區別。”
還有網友強調：“magic”背后依然離不開編程和理解模型原理，也有人批評上下文工程很容易變成一種“玄學”炒作。
簡單的理解，不管叫 prompt 還是 context，都是黑盒巫術本質還是“try and see”。
還有網友調侃：LLM 是非確定性機器，結果不穩定、重復性不強，所謂“工程”不過是“調參的藝術”。
圖片
8.寫在最后：Prompt 淡出或是必然
在小編看來，提詞工程的淡出（產品化），上下文工程興起，已經是一種趨勢。
首先，產品側來看，隨著 RAG、Agent、AutoChain 等機制普及，開發者越來越依賴工具自動構建 prompt，而不是手寫 prompt。
“好 prompt” 越來越像產品的功能，而非用戶的技能。
其次，模型側來分析。模型 token window 增大，但 context 變長后“腐爛”（context rot）問題日漸凸顯。
圖片
對于我們而言，如何管理、組織、剪裁 context 成為下一步挑戰。
正如一位Hackernews的網友 Drew Breunig 所提到了一些關鍵技術：Context Quarantine、Tool Loadout、Summarization 等。
當然，不管是提示詞工程，還是上下文工程，小編認為——哪個都不是萬能的！
“即使你有 memory bank，有 plugin，最終還是得人類自己寫代碼。”
