編譯 | 蘇宓

出品 | CSDN（ID：CSDNnews）

繼“氛圍編碼”（Vibe Coding）之后，AI 圈又迎來一個爆火的新名詞——“上下文工程”（Context Engineering）。

相比大模型剛崛起時出現的“提示詞工程”這個廣為人知的說法，“上下文工程”正逐漸被認為是更準確、更專業的替代詞，背后也反映出整個大語言模型（LLM）應用范式的轉變。

“上下文工程”一詞的由來

這個說法最早引起廣泛關注，是因為 Shopify CEO Tobi Tobi Lutke 在 X（原 Twitter）上發了一個帖子：“我更喜歡用‘上下文工程’來代替‘提示詞工程’這個詞。它更貼切地描述了核心技能：為任務提供足夠的上下文，讓大語言模型有可能得出合理解答的藝術。”

這條推文迅速引發共鳴，連 AI 界技術大牛、前 OpenAI 研究員 Andrej Karpathy 也轉發附上了“+1”以示認同。

Andrej Karpathy 寫道：

同意！“上下文工程”比“提示詞工程”更合適。

大多數人一聽到“提示詞”，想到的只是平時用 LLM 時輸的一小段任務描述。而在真正工業級的 LLM 應用中，上下文工程才是關鍵所在——一門既講科學又講直覺的技術活，要把上下文窗口精確地填入下一步所需的信息。

說它是“科學”，是因為你得處理清晰的任務描述、示例、外部信息檢索（RAG）、相關數據（可能還是多模態的）、工具、狀態和歷史，還要考慮怎么壓縮信息……這些環節做對并不簡單。如果信息太少或形式不對，大模型就無法獲取足夠的上下文，性能大打折扣；信息太多或太無關，成本會上升，性能反而可能下降。做好這件事，絕非易事。

它之所以是“藝術”，是因為你得有對“大模型心理學”的直覺判斷，知道人類期望它怎么理解信息、怎么回應。

當然，除了上下文工程本身，構建一個真正的 LLM 應用還涉及很多其它工作，比如：

• 如何把大問題拆解為合適的控制流程

• 如何精準打包上下文窗口

• 如何調度調用不同能力、不同類型的模型

• 如何設計生成-驗證的 UI/UX 流程

• 還有一整套包括安全控制、性能評估、并行執行、預取機制等在內的復雜邏輯……

因此，上下文工程只是整個 LLM 應用系統中，一個小而復雜的組成部分。它屬于正在迅速發展的一整層“厚重軟件?！保@個軟件棧負責協調每一次模型調用（以及遠不止如此），從而構建出真正可用的大模型應用。

所以，“ChatGPT 包裝器”這個說法，早就不合時宜，而且嚴重低估了這項工作的復雜性。

到底什么是“上下文”？

那么，對于普通 AI 從業者而言，該如何理解與運用“上下文工程”，它是否和“提示詞工程”一樣，只是寫幾句指令就行？

對此，來自 DeepMind 的高級 AI 關系工程師 Philipp Schmid 給出了深刻的解讀。他指出，「隨著智能體（Agent）技術的發展，我們越來越意識到，什么信息被放入模型“有限的工作記憶”中，才是決定任務成功與否的關鍵。如今很多 Agent 的失敗，不再是模型能力不足，而是上下文沒設計好。」

要真正理解“上下文工程”，我們首先得重新認識“上下文”這個詞。它并不僅僅是你輸入給模型的一句話，而是模型在生成回答之前，所能看到的全部信息。

可以把上下文理解為以下這些組成部分：

• 系統指令（System Prompt）：開場設定，告訴模型這次對話應該怎么表現?？梢园纠?、規則等等。

• 用戶輸入：用戶的提問或任務指令。

• 對話歷史（短期記憶）：本輪對話中模型和用戶的所有來回內容。

• 長期記憶：跨會話保存的信息，比如用戶偏好、過往項目的總結、或明確告訴模型要記住的事實。

• 外部檢索信息（RAG）：從文檔、數據庫或 API 獲取的最新資料，用來輔助模型回答。

• 可用工具：模型可以調用的工具或函數（例如 check_inventory、send_email）。

• 結構化輸出格式：指定模型回答的格式，比如一個 JSON 對象。

你寫的代碼復雜不復雜，反而沒那么重要。重要的是你給模型準備了什么樣的上下文。

打個比方，假設你做了一個智能助理，用來安排會議。當用戶發來一封簡單郵件：

“嘿，明天你有空開個小會聊聊嗎？”

版本一：廉價演示級別的 Agent

它拿到這句話就直接丟給大模型，沒有別的上下文輔助。結果模型生成一個死板的回應：

“謝謝你的信息。明天可以。請問你希望幾點呢？”

看似沒問題，但毫無“智能”。

版本二：魔法般的 Agent

這個 Agent 會在調用模型前，把相關背景信息都準備好：

• 查你的日歷（發現你明天全天都排滿了）

• 看你跟這位聯系人過往的郵件（判斷你們說話可以用輕松語氣）

• 識別對方是重要合作伙伴

• 配好發邀請的工具（send_invite）

于是模型生成的回復是這樣的：

“嘿 Jim！我明天全都排滿了，一整天都在開會。周四上午有空，合適嗎？我發了個邀請，看看行不行。”

看出來了嗎？這不是模型變聰明了，而是你喂給它的信息更好了。真正的“魔法”，其實是“上下文”變了。

從“提示詞”走向“上下文工程”

那到底什么是“上下文工程”？如果說提示詞工程是寫一段聰明的指令讓模型盡可能給出好結果，那上下文工程做的事情要更復雜：

上下文工程，是設計和構建一整套動態系統，讓大模型在正確的時間，看到正確的信息和工具，以完成目標任務。

更具體來說：

• 不是一句話，而是一個系統：上下文不是靜態模板，而是模型調用前動態生成的一整套輸入。

• 按需生成，實時定制：每次請求生成的上下文都不同。有時是日歷信息，有時是用戶郵件，有時是最新網頁搜索結果。

• 關鍵在于“信息+工具”的時機與精度：模型輸出質量好不好，核心是你給它的東西準不準、夠不夠。如果給的上下文本身就是錯的或沒用的，那結果自然也好不到哪去。

• 信息呈現方式也很重要：一堆亂七八糟的原始數據，遠不如一個清晰的摘要；一段模糊的提示，不如一個結構明確的工具調用說明。

總結

現在，想做出真正靠譜、強大、實用的 AI Agent，關鍵不在于模型換沒換新、提示詞寫得多高級，而是上下文工程做得怎么樣：你有沒有把正確的信息、工具、格式，在正確的時機送到模型面前。

這不僅是工程問題，更是一個跨領域的系統設計問題。你需要懂業務場景、定義好目標輸出，然后用“上下文”把一切都準備好，讓模型有條件完成任務。

來源：https://www.philschmid.de/context-engineering

AI 產品爆發，但你的痛點解決了嗎？

2025 全球產品經理大會

8 月 15–16 日

北京·威斯汀酒店

互聯網大廠、AI 創業公司、ToB/ToC 實戰一線的產品人

12 大專題分享，洞察趨勢、拆解路徑、對話未來。

立即掃碼領取大會PPT

搶占 AI 產品下一波紅利