上下文工程是什麼？提示詞工程的升級版

上下文工程（context engineering）是提示詞工程在 2025 年升級出來的說法。一句話講清：不再只打磨「這個問題怎麼問」，而是去設計模型回答時看到的一切——指令、檢索來的資料、工具回傳的結果、對話歷史、之前工作階段留下的筆記。這個詞在 2025 年年中火起來，到現在，Anthropic、LangChain 這些一線廠商的官方文件都在正經使用它。你只要做過超出「玩具聊天框」的 LLM 應用，這就是決定你的東西能不能用的那門手藝。

名字是新的，問題不新。下面我把這個術語的來歷、什麼算上下文、為什麼模型視窗越大這件事反而越重要、以及實務層面到底怎麼做，按順序講一遍。

上下文工程是什麼，這個詞從哪來

先把時間線捋清楚，因為它能告訴你當時大家在煩什麼。

2025 年 6 月，Shopify 的 CEO Tobi Lütke 在一份後來公開的內部備忘錄裡用了這個說法，定義是「為任務提供全部所需上下文、讓它對 LLM 來說可合理解決的藝術」。幾天後，Andrej Karpathy 轉發放大：他更喜歡上下文工程這個詞，定義是「用恰好正確的資訊填滿上下文視窗、支撐下一步的精細藝術與科學」。注意 Karpathy 列的動作清單：少樣本示例、RAG、工具、狀態、歷史、壓縮。全是從業者做好幾年、卻一直沒有合適名字的事。

2022 年造出「提示詞工程」這個詞的 Simon Willison，點破了舊詞為什麼失效：它的實際含義已經滑向「往聊天框裡打字」這種自命不凡的說法。新詞描述的才是真實的工作內容。到 2025 年 9 月，Anthropic 發布工程指南，明確說上下文工程是提示詞工程的自然演進。詞彙的換代至此完成。

還有一個我常用的解釋，來自一個綜述了 1400 篇論文的 GitHub 儲存庫：提示詞工程管的是「你說什麼」，上下文工程管的是「模型看到的其餘一切」。給聽過提示詞的人解釋這個概念，這句最快。

什麼算上下文：七類東西搶一個視窗

直接上清單。任意時刻，上下文就是視窗裡的一切，大致七類：

系統提示詞（穩定的指令）
你當前這則訊息
短期狀態（進行中的任務、到目前為止的對話）
長期記憶（從之前工作階段帶過來的內容）
檢索來的知識（RAG 的那個 R，查詢時現拉進來的文件）
工具定義和工具回傳結果
要求的輸出格式

七類東西擠同一個固定容量。這是多數人漏掉的部分：視窗是一份共享預算（容量機制本身，我們講上下文視窗那篇有完整拆解），每多加一類，剩下各類分到的注意力就被稀釋一分。上下文工程，本質上就是管這份預算。

為什麼偏偏現在冒出來：視窗越大，越要少放

這是整個概念裡最反直覺的一環，也是這個行業需要新詞的真實原因。

照直覺想，模型都能吃一百萬 token 了，還挑什麼，全塞進去不就完了。研究結論正好相反。一篇標題就叫 Context Rot（上下文腐爛）的論文測了輸入 token 變多會發生什麼：召回和推理雙雙下滑。背後有機制：注意力是一份預算，每加一個 token，其他所有 token 分到的注意力就薄一分；而注意力建模的是 token 兩兩之間的關係，長度翻倍，關係數按平方漲。東西越多，每件東西被看得越模糊。

你可能會說，那些長上下文模型不是把大海撈針測試考滿分了嗎？考了，而這恰恰是陷阱。那個測試把一個事實藏在長文件裡，提問的措辭和事實本身幾乎一樣，本質是詞面比對，接近字串查找，不需要推理。研究者把「針」改寫一下，讓答案需要關聯一句間接表述才能得出，或者加進幾條看起來相關但不是答案的干擾項，成績就隨長度斷崖式下跌。真實任務——「給你一堆程式碼，找出為什麼跑掛」——恰恰是模糊加干擾的那種，不是字串比對那種。

有一個數字我建議你記住：在一組對照測試裡，對著約 12 萬 token 的完整對話歷史回答，效果不如對著一份只有 300 token、只保留相關資訊的精簡版。token 少了四百倍，答案反而更好。過了一個點之後，篩選不是錦上添花，是全部。上下文工程的一半功夫，就是在決定不放什麼。

上下文工程和提示詞工程的關係

這是大家搜得最多的問法，值得認真回答。誠實的說法，也是 LangChain 共同創辦人的立場：提示詞工程沒有死，它變成了子集。他有句話很準：智慧代理人的失敗，多數時候不是模型失敗，是上下文失敗。你的 AI智慧代理人幹了蠢事，模型拿到的輸入往往「配得上」這個蠢答案——一堆臃腫的歷史、檢索錯的文件、三個職責重疊的工具。

	提示詞工程	上下文工程
打磨對象	一條指令的措辭	進入視窗的一切
形態	靜態範本	按任務動態組裝的系統
核心問題	怎麼問	放什麼、不放什麼、用什麼格式
典型動作	改措辭、加少樣本示例	接 RAG、裁歷史、設計工具、記筆記

舉個例子最直觀。你對模型說「我想退貨」。只有這一句話時，它機械回答「請在 7 天內提交申請」。現在把上下文配上：客戶是誰、訂單明細、商城退貨規則、前面對話裡承諾過什麼。同一個模型，同一個問題，回答變成「您買的耳機還在退貨期內，退貨申請已提交」。差別從來不在問題怎麼問。想看更完整的路線版圖（微調、純提示各在什麼位置），可以讀我們那篇微調 vs RAG vs 提示詞。

實操原則：放什麼，不放什麼

Anthropic 的工程指南是我讀過最實用的一份，它的總綱壓縮得極漂亮：追求最小的高訊號 token 集。每一次互動，你都在問：這條資訊配得上它占的預算嗎。

幾條值得直接抄的原則：

按需取用。 不預載入模型「可能要用」的一切，在需要的那一刻精確取。指南自己舉的例子是 Claude Code：讀檔案只讀開頭幾行或結尾幾行，用 glob 看目錄結構、grep 定位模式，而不是把整個程式碼庫塞進上下文。資訊按需到達，而且到達時已經收窄過。

系統提示詞寫在合適的高度。 太泛（「做個有用的助手」）模型沒有方向；窮舉每種情況怎麼處理，規則之間會打架。甜點位是往上一層：寫穩定的行為原則，不寫逐案規則。

把工具設計給一個會犯迷糊的人用。 工具輸出保持緊湊、工具職責別重疊、名稱體現意圖。指南說得很直白：人類工程師都分不清該用哪個工具時，就別指望智慧代理人分得清。我恰好除錯過這種故障：兩個幾乎一樣的內部工具，agent 老選錯那個，所有人都在怪模型。

還有一條是 demo 和產品的分水嶺：「AI 幫我約會議」的 demo，一個系統提示詞就能跑。能用的版本，餵進去的是可用時段、時區、會議室容量、公司預訂規則、上週會議的紀要。從 demo 到產品，模型沒變聰明，它的上下文變了。這也解釋了為什麼上下文工程和 AI 智慧代理人是一起長大的——智慧代理人是上下文壓力最大的場景：跑得久、工具多、狀態一攢幾個小時。

長任務的三個技術

任務跑得夠久之後，上下文問題就從「放什麼」變成「攢了一堆怎麼辦」。Anthropic 指南給了三個技術，各自對準一種失敗：

壓縮（compaction）。 歷史太長時主動摘要清場。不顯然的部分是留什麼：最近的檔案、架構決策、沒解決的 bug 留下，已經處理完的工具輸出清掉。壓縮是分診，不是無腦截斷。

結構化筆記（structured note-taking）。 讓智慧代理人把要記住的東西寫下來——一個 NOTES.md 檔案、一個步數計數器（那個讓 Claude 玩寶可夢的著名設定，就是用千步計數器當記憶）——而不是指望它一直活在大模型上下文的視窗裡。筆記活得下來，視窗內容活不下來。

子智慧代理人架構（sub-agent）。 開自己視窗的分身。一個子智慧代理人可能燒掉幾萬 token 幹一場髒活，然後只交回一兩千 token 的結論摘要。髒的部分永遠碰不到主上下文。

指南的收尾建議我很喜歡，就因為它樸素：先做最簡單的能用的。多數任務用不上三件套。RAG 本身，你細想的話就是上下文工程最流行的動作——在剛好相關的時刻把檢索到的知識拉進來。從這裡起步，哪裡真壞了再上機械。

快答

上下文工程和提示詞工程的區別是什麼？ 打磨對象不同：提示詞工程打磨一條指令的措辭，上下文工程設計進入模型視窗的全部資訊（檢索、工具、記憶、歷史都在內）。後者是前者的超集。

提示詞工程死了嗎？ 沒有，降級成了子集。措辭依然重要，只是不再占全部工作量。

普通人需要懂上下文工程嗎？ 你其實已經在輕量地做了：傳檔案、貼對的那段程式碼、發現對話糊塗了就新開一個聊天。你只是沒叫它這個名字。

RAG 算上下文工程嗎？ 算，而且是最高頻的一招：讓模型在對的時刻看到緊湊形態的檢索結果。

這個領域如果你只帶走一個想法：對面的模型是固定的，但它看到什麼，是你設計的。把 LLM 用得好的團隊，靠的不是什麼魔法提示詞，而是把上下文當工程系統對待——可度量、有預算、下得去刀。

Edward Wang