「上下文工程」矽谷爆火，Karpathy 親自月臺，提示工程瞬間失寵

矽谷如今炙手可熱的，不再是提示詞工程，而是上下文工程（Context Engineering）！

就連 AI 大神 Karpathy，都為「上下文工程」投下了一票。

還有 Shopify CEO Tobias Lütke 稱，自己更喜歡「上下文工程」，因其準確描述了一個核心技能——

通過為任務提供完整的背景資訊，讓大模型能夠合理解決問題的藝術。

一夜之間，「上下文工程」紅遍全網，究竟是為什麼？

  上下文工程，一夜爆紅

  這背後原因，離不開 AI 智慧體的興起。

OpenAI 總裁 Greg Brockman 多次公開表示，「2025 年，是 AI 智慧體的元年」。

決定智慧體成功或失敗最關鍵的因素，是提供的「上下文品質」。 也就是說，載入到「有限工作記憶」中的資訊愈加重要。

大多數 AI 智慧體失敗的案例，不是模型的失敗，而是上下文的失敗！

  那麼，什麼是上下文？

要理解「上下文工程」，首先需要擴展「上下文」的定義。

它不僅僅是你發送給 LLM 的單一提示，可以將其視為「模型再生成回應之前，看到的所有內容」，如下：

指令/系統提示： 定義模型在對話中行為的初始指令集，可以/應該包括示例、規則等。

使用者提示： 用戶的即時任務或問題。

狀態/歷史（短期記憶）： 當前對話，包括使用者和模型的回應，截至此刻。

長期記憶： 跨多次之前對話收集的持久知識庫，包含學習到的使用者偏好、過去專案的摘要或要求記住以備將來使用的事實。

檢索資訊（RAG）： 外部、實時的知識，來自文檔、資料庫或 API 的相關信息，用於回答特定問題。

可用工具： 模型可以調用的所有功能或內置工具的定義，比如 check_inventory、send_email。

結構化輸出： 模型回應格式的定義，例如 JSON 物件。

可以看出，與專注於在單一本文字符串中，精心構建完美指令的「提示詞工程」不同，「上下文工程」的範疇要廣泛得多。

  簡單來說：

「上下文工程」是一門學科，它致力於設計和構建動態系統。

這些系統能夠在恰當的時機、以恰當的格式，提供恰當的資訊和工具，從而讓 LLM 擁有完成任務所需的一切。

  以下是「上下文工程」的所有特點

· 它是一個系統，而非一個字串 ：上下文並非一個靜態的提示詞範本，而是一個系統的輸出，這個系統在對 LLM 進行主調用之前就已經運行。

· 它是動態的 ：上下文是即時生成的，為當前任務量身定製。 比如，某個請求可能需要的是日曆數據，而另一個請求則可能需要電子郵件內容或網路搜尋結果。

· 它強調在恰當時機提供恰當資訊與工具 ：其核心任務是確保模型不會遺漏關鍵細節（謹記「垃圾進，垃圾出」原則）。 這意味著只在必要且有益的情況下，才向模型提供知識（資訊）和能力（工具）。

· 它注重格式 ：信息的呈現方式至關重要。 一份簡潔的摘要遠勝於原始數據的羅列; 一個清晰的工具介面定義也遠比一條模糊的指令有效。

  是一門科學，也是一門藝術

Karpathy 長文點評中，同樣認為「上下文工程」是藝術的一種。

人們往往將提示詞（prompt），聯想為日常使用中——發給 LLM 的簡短任務描述。

然而，在任何一個工業級的 LLM 應用中，上下文工程都是一門精深的科學，也是一門巧妙的藝術。

其核心在於，為下一步操作，用恰到好處的資訊精準填充上下文視窗。

說它是科學 ，是因為要做好這一點，需要綜合運用一系列技術，其中包括：

任務描述與解釋、少樣本學習範例、RAG（檢索增強生成）、相關的（可能是多模態的）數據、工具、狀態與歷史記錄、資訊壓縮等等。

資訊太少或格式錯誤，LLM 就沒有足夠的上下文來達到最佳性能;

資訊太多或關聯性不強，又會導致 LLM 的成本上升、性能下降。

  要做好這一點是頗為複雜的。

說它是藝術 ，則是因為其中需要依賴開發者對大模型「脾性」的直覺把握和引導。

  除了上下文工程本身，一個 LLM 應用還必須做到：

  將問題恰到好處地拆解成控制流

  精準地填充上下文視窗

  將調用請求分派給類型和能力都合適的 LLM

  處理「生成-驗證」的 UIUX 流程

以及更多——例如安全護欄、系統安全、效果評估、並行處理、數據預取等等...

因此，「上下文工程」只是一個正在興起的、厚重且複雜的軟體層中的一小部分。

這個軟體層負責將單個的 LLM 調用，以及更多其他操作整合協調，從而構建出完整的 LLM 應用。

Karpathy 表示，把這類應用輕率地稱為「ChatGPT 的套殼」，這種說法不僅老掉牙了，而且大錯特錯。

有網友對此調侃道，上下文工程，是全新的「氛圍程式設計」。

Karpathy 回應稱，「我倒不是想自創個新詞什麼的。 我只是覺得，大家一提到「提示詞」，就容易把一個其實相當複雜的元件給想簡單了」。

你會用一個提示詞去問 LLM「天空為什麼是藍色的」。 但應用程式呢，則是需要為大模型構建上下文，才能解決那些為它量身定製的任務。

  智慧體成敗，全靠它了

其實，打造真正高效的 AI 智慧體秘訣，關鍵不在於編寫的代碼有多複雜，而在於你所提供的上下文有多優質。

一個效果粗糙的演示產品，同一個表現驚豔的智慧體，其根本區別就在於提供的上下文品質。

想像一下，一個 AI 助理需要根據一封簡單的郵件來安排會議：

  嘿，想問下你明天有空簡單碰個頭嗎？

「粗糙的演示」智慧體獲得的上下文很貧乏。 它只能看到使用者的請求，別的什麼都不知道。

它的代碼可能功能齊全——調用一個 LLM 並獲得回應，但輸出的結果卻毫無説明，而且非常機械化：

感謝您的消息。 我明天可以。 請問您想約在什麼時間？

  接下來，再看看由豐富的上下文加持的驚豔智慧體。

其代碼的主要任務並非是思考如何回復，而是去收集 LLM 達成目標所需的資訊。 在調用 LLM 之前，你會將上下文擴展，使其包含：

代碼的主要工作，不是決定如何回應，而是收集 LLM 完成目標所需的資訊。

  在調用 LLM 之前，你會擴展上下文，包括：

  日曆信息：顯示你全天都排滿了

與此人的過去郵件：用來判斷應該使用何種非正式語氣

  聯繫人清單：用來識別出對方是一位重要合作夥伴

用於 send_invite 或 send_email 的工具

  然後，你就可以生成這樣的回復：

嘿，Jim！ 我明天日程完全排滿了，會議一個接一個。 週四上午我有空，你看方便嗎？ 邀請已經發給你了，看這個時間行不行哈。

這種驚豔的效果，其奧秘不在於模型更智慧，或演算法更高明，而在於為正確的任務提供了正確的上下文。

  這正是「上下文工程」將變得至關重要的原因。

所以說，智慧體的失敗，不只是模型的失敗，更是上下文的失敗。

要構建強大而可靠的 AI 智慧體，我們正逐漸擺脫對尋找「萬能提示詞」，或依賴模型更新的路徑。

  這一點，深得網友的認同。

其核心在於對上下文的工程化構建：即在恰當的時機、以恰當的格式，提供恰當的資訊和工具。

這是一項跨職能的挑戰，它要求我們深入理解業務用例、明確定義輸出，並精心組織所有必要資訊，從而使 LLM 能夠真正「完成任務」。

最後，借用網友一句話，「記憶」才是 AGI 拼圖的最後一塊。

  參考資料：

https://www.philschmid.de/context-engineering

https://news.ycombinator.com/item?id=44427757

  編輯：桃子

本文來自微信公眾號 “新智元”，作者：新智元，36 氪經授權發佈。