情境工程登場：從提示到情境
寫小抄的年代結束了——現在你要經營的，是一整間隨時湧入新資訊的辦公室
一個新詞，正在取代大家嘴邊的老詞
這幾年，提示工程 prompt engineering 幾乎是應用 AI 圈的顯學——大家都在琢磨怎麼把一句指令寫得更精準。但最近，另一個詞悄悄爬上檯面： 情境工程 context engineering。
用語言模型打造產品，重點正在從「幫 prompt 找到對的字句」，慢慢轉移到一個更大的問題：「此時此刻，怎樣的 情境 context 組合，最可能引出模型想要的行為？」
提示工程像是考前寫一張小抄——絞盡腦汁把它寫到最精簡好用，寫完工作就結束了，一次性、靜態。情境工程更像在經營一間辦公室，每天、每小時都有新信件、新會議紀錄湧進來，你得不斷決定什麼留桌上、什麼收進檔案櫃、什麼乾脆丟掉。
直接讀原文，旁邊就是白話
這篇文章是 Anthropic 工程團隊寫的。我們一樣把最關鍵的定義句原文放左邊、白話中文放右邊——一句對一句，讓你順手練一下原文的講法。
應用 AI 圈的焦點在提示工程上打轉了幾年後，一個新詞正悄悄崛起：情境工程（context engineering）。
情境工程指的是：在 LLM 推論過程中，持續策展、維護一組最佳 token（資訊）的策略，範圍涵蓋提示之外，所有可能被放進去的其他資訊。
一個在迴圈裡運作的 Agent，會不斷產生「可能對下一輪推論有用」的新資料，而這些資料必須被循環式地整理、取捨。
上下文視窗裡的 token 數量越多，模型能準確回憶其中資訊的能力就越差。
LLM 建立在 Transformer 架構上，這套架構讓每個 token 都要跟其他所有 token 互相「關注」——n 個 token 之間，就會產生 n² 量級的配對關係。
文章開頭就講白了：「我們把情境工程看作提示工程很自然的下一步演進」——不是取代，是視野變大了：從「這句話寫得好不好」，變成「此刻餵進模型的整包 token，配得對不對」。
兩個工程，管的範圍差多大？
提示工程跟情境工程常被混著講，但它們管的「地盤」大小完全不同——一個管一份文件，一個管一整座持續變動的資訊倉庫。
專注在「怎麼把指令寫好」——尤其是系統提示的措辭、排版、範例。這是一次性、靜態的任務：寫完、調好，工作就結束了。早期 LLM 多半用在分類、生成這類單次任務，寫好一個 prompt 幾乎就是全部工作。
管理 Agent 運作全程要放進上下文視窗的一切：系統提示、工具定義、少量範例、訊息歷史、檢索到的外部資料……每一輪推論前都要重新策展一次。這是持續性、動態的過程，因為 Agent 在迴圈裡運作，會不斷生出新的候選資訊。
可以這樣記：提示工程是「寫一份文件」，情境工程是「經營一整座持續變動的資訊倉庫」——寫指令只是情境工程要處理的其中一塊。當我們開始打造在多輪推論、長時間運作的 Agent（寫程式的、做研究的），問題就不再是「這句話寫得好不好」，而是系統指令怎麼設計、工具怎麼給、外部資料何時載入、舊對話哪些該留哪些該丟。
為什麼要斤斤計較？因為情境會「腐化」
研究者用「大海撈針」式的測試發現一個現象：上下文視窗裡的 token 數量越多，模型準確回憶其中資訊的能力反而越差。這個現象叫 context rot（情境腐化）。
重點是：這不是某個模型的個別缺陷，而是所有模型都會出現的特性，只是退化速度有快有慢。所以上下文必須被當成一種 邊際效益遞減的有限資源——塞進去的 token 越多，每多加一個帶來的幫助就越小，甚至開始變成干擾。
就像人類的工作記憶是有限的，LLM 也有一份「注意力預算」——每多塞一個 token 進來，就會消耗掉一部分。
Transformer 架構讓每個 token 都要跟其他所有 token 互相「關注」，n 個 token 兩兩配對，就是 O(n²) 量級的關係數——n 越大，關注負擔以平方速度暴增。
模型在長上下文中依然很有能力，只是精準度、長距推理的表現會逐漸打折扣——是一條慢慢下滑的坡，不是瞬間掉下懸崖。
視窗容量上限提高，不代表模型能同等精準地運用裡面每一段資訊。這正是 context rot 背後的機制：Transformer 讓每個 token 都要兩兩互相關注，配對關係是 n² 量級，n 一大，注意力自然被稀釋、拉得更薄——就像一場擠滿人的酒會，人越多，每一段對話反而越難聽清楚。
動手策展：這些「情境元素」該精簡，還是該完整保留？
知道 context rot 之後，面對 Agent 運作中冒出來的各種資訊，你得學會取捨。把下面幾種情境元素，拖到它該去的那一區。
好的情境工程，就是找出「最小可能的高訊號 token 集合」，讓它們最大化引出你要的行為的機率。每加一段資訊前，先問自己：這真的值得消耗一部分注意力預算嗎？
小試身手
把提示工程、情境工程、context rot 這幾個概念串起來，來兩題檢查一下：
知道情境會腐化之後，該怎麼把系統提示、工具、範例這些「情境元素」本身打磨到位？往下捲，我們一項一項拆開來看。
打造有效情境的解剖學
系統提示、工具、範例——三個常駐零件，決定 Agent 的上限與下限
先解剖，再組裝
上一模組留下一句提醒：情境是有限的注意力預算，要找到最小可能、卻高訊號的 token 組合。這一站，我們把「情境」這個大概念拆開，看看它最常駐的三個零件—— 系統提示 system prompt、 工具 tools、 few-shot 範例——每一個都各自有一套「調得剛剛好」的手感。
把 Agent 想成一位剛到職的員工：系統提示是他的職務說明書，工具是他桌上的設備，範例是前輩留下的參考案例。三樣東西任何一項沒調好，這位員工都會做得七零八落——這正是這一站要逐一校準的。
直接讀原文：黃金高度與工具合約
這幾句話，是整篇文章裡最常被工程師拿來對照自己提示的段落。原文放左邊，白話放右邊，一句對一句：
系統提示應該要極度清楚，用簡單直接的語言，把想法放在對這個 Agent 剛剛好的「高度」上說話。
一個極端是：工程師把複雜又死板的邏輯硬寫進提示裡，想精準控制 Agent 每一步該怎麼做。
因為工具定義了 Agent 跟它的資訊、行動空間之間的「合約」，工具的設計必須非常講究效率——回傳的資訊要精簡，還要引導 Agent 採取有效率的行動。
如果連人類工程師都無法明確判斷該用哪個工具，就不能指望 AI Agent 能做得更好。
對 LLM 來說，一個範例往往就是「一張圖勝過千言萬語」。
第一、二句講系統提示的「高度」；第三、四句講工具是一份「合約」；第五句講範例的份量。接下來我們一個一個拆開玩。
點點看：情境的三個零件，各自的設計要訣
下面是這一章的招牌互動——點每個零件，看它的核心設計原則是什麼。
系統提示的三種高度
先聚焦系統提示。文中把「恰到好處的具體程度」稱為 黃金高度 right altitude， 它落在兩個失敗模式之間：
把一堆「如果 A 就做 B、如果 C 就做 D」的 if-else 邏輯硬寫進提示，想精準控制每種情境。結果提示變得 脆弱 brittle ——情境一變就失效，還得不斷手動補新規則，維護成本越滾越大。
只給模糊的高層次指示，例如「請妥善處理」，卻沒給模型具體訊號知道預期輸出長怎樣，甚至誤以為模型跟自己有共同的背景知識。模型缺乏依據，只能瞎猜。
具體到能有效引導行為，但又保留彈性，讓模型能運用推理能力類推到沒教過的情境，而不是照本宣科。建議先用最強模型測試一份精簡提示，再依實際失敗案例逐步補上指令與範例。
文中特別提醒：「minimal does not necessarily mean short」——精簡指的是「沒有多餘無效的內容」，不是字數少。把必要的背景資訊講清楚，有時反而需要更多文字；每一段話都該有它存在的理由。
工具設計：一份「合約」該有的樣子
再看工具。工具讓 Agent 能跟外部環境互動、拉入新資訊，也因此定義了它「能知道什麼、能做什麼」的邊界——這正是為什麼文中把工具比喻成一份 合約 contract。 設計工具要顧好兩件事：
回傳的資訊要精簡，不要塞一堆無關雜訊。工具就像一位師傅的工具箱——每樣工具功能單一、標籤清楚，彼此不重疊，師傅幾乎不用思考就知道該伸手拿哪一個。
最常見的失敗模式是 工具集膨脹 bloated tool sets ——功能重疊、決策點模糊。如果連設計者自己都要猶豫幾秒才能決定「這情境該用工具 A 還是 B」，就是警訊，該考慮合併或刪減，收斂成 最小可行工具集。
輸入參數要描述清楚、不含糊，並發揮模型本身擅長的能力——例如讓模型寫它擅長的自然語言描述，而不是硬要它精確計算複雜座標。精簡的工具集不只讓單次任務更有效率，也讓長時間互動裡的上下文維護與清理更容易。
範例：少量、多樣、具代表性，勝過堆邊界案例
最後是範例。 Few-shot prompting 是業界公認的最佳實踐，文中也持續強力推薦——但常見的誤區，是把「每一種可能的邊界情況」都寫成規則塞進提示，變成一份落落長的清單。
這本質上是另一種「過度死板」：提示會變得臃腫難維護，卻仍難以真正涵蓋所有情況。更好的做法是精心挑選一組 具代表性的範例 canonical examples ——多樣化、能有效傳達核心行為模式，而不是逐一覆蓋每個枝微末節。
把系統提示、工具、範例、訊息歷史全部想像成一個行李箱：你想帶夠東西讓旅程順利，但不想拖著一個塞爆到拉鍊快壞掉的行李箱到處走。這正是文中收斂出的整體原則——保持情境 資訊豐富但精簡 informative yet tight。 每一件放進去的東西，都該有明確存在的理由。
小試身手
三個零件都拆開看過了，來兩題檢查一下手感：
下一站：情境元素備好了，但資料該「先塞好」還是「需要才查」？進入即時檢索的世界。
即時檢索與探索式搜尋
Agent 不必先背下整座圖書館——它只要記得書在哪一櫃
上下文要「先查好」還是「用到再查」？
上一模組談的是怎麼把 system prompt、工具、範例這些「常駐」的上下文修剪到位。這一站要談的，是另一大類上下文——那些不是隨時都在，而是要在執行當下才決定「要不要查、查哪裡」的資料。
作者群觀察到，領域正在往更 agentic 的方向移動，也連帶讓「怎麼取得上下文」出現兩派做法：
在推論之前，先用 embedding 把可能相關的資料一次全撈出來，準備好交給模型參考。
不預先處理全部資料，而是維護一些輕量識別碼，執行當下才透過工具動態把資料載入上下文。
人類通常不會把整座圖書館的書都背下來，而是靠檔案系統、收件匣、書籤這類外部索引，需要時再去查。Just-in-time 檢索就是把這套「人類的偷懶智慧」搬進 Agent 設計。
原文最關鍵的一段，直接對照著看
這段話幾乎是本節的核心主張，值得逐句對照原文：
用「即時」做法打造的 Agent，不會預先把所有相關資料處理好，而是維護一些輕量識別碼（檔案路徑、存好的查詢語句、網址連結等），在執行當下用工具動態把資料載進上下文。
Anthropic 自家的 agentic 寫程式工具 Claude Code，就是用這一招來對大型資料庫做複雜的資料分析。
模型自己寫出精準的查詢、把結果存起來，再靠 head、tail 這類 Bash 指令去分析大量資料——完全不必把整份資料物件塞進上下文。
這方式其實很像人類的認知習慣：我們通常不會把整套知識庫都背下來，而是靠檔案系統、收件匣、書籤這類外部組織與索引系統，需要時再去查。
原文舉了一個很妙的例子：同樣叫 test_utils.py 的檔案，放在 tests 資料夾和放在 src/core_logic/，暗示的用途完全不同。資料夾結構、命名慣例、時間戳記，都是幫 Agent（也幫人類）判斷「這東西該怎麼用」的重要訊號。
跑一遍：Agent 怎麼「即時」找資料
不是把整個資料庫塞進上下文，而是先查索引、再判斷、才動態載入。按「下一步」看這五個角色怎麼接力。
人類記得的是「書在哪一櫃」，不是整本書的內容。輕量索引就是那張「書在哪一櫃」的卡片——Agent 只要在真正需要的那一刻，才走過去把書抽出來翻。
天下沒有白吃的午餐：即時探索也有代價
Just-in-time 檢索很強，但原文也老實列出取捨——執行時才探索天生比較慢，還需要用心設計的工具與判斷準則，否則 Agent 可能誤用工具、走進死胡同，白白燒掉上下文額度。
優點：速度快，到用的時候資料已經在手邊。缺點：像出差把整個行李箱塞滿——很多東西根本用不到，還可能讓上下文塞爆、變得又雜又難調用（呼應第一章的 context rot）。
優點：上下文乾淨，只留下真正用得到的片段，還能漸進式揭露——像剝洋蔥一層層建立理解。缺點：現場查比較慢，工程沒設計好，Agent 可能迷路。
Claude Code 正是混合模式的代表：CLAUDE.md 這種「幾乎每次都會用到」的背景資訊，直接「天真地」預先塞進上下文；至於檔案內容這種多變的東西，就交給 glob、grep 這類基礎工具在執行時即時查——順便繞開了「索引過時（stale indexing）」和維護複雜語法樹索引的麻煩。原文也提到，這種混合策略在法律、財務這類內容相對穩定的領域特別好用。
小試身手
把「輕量索引 → 即時載入 → 混合策略」這條線抓穩，來兩題檢查一下：
CLAUDE.md 與 glob／grep 分別扮演什麼角色？任務一拉長，上下文視窗遲早會塞滿——三個撐住長任務的關鍵技巧。
長任務的情境工程三大技巧
當任務長到一個上下文視窗裝不下——Agent 要靠壓縮、筆記、分工，撐過馬拉松
「等更大的上下文視窗」，救不了長任務
像是大型程式碼庫搬遷，或是橫跨數十分鐘到數小時的深度研究專案，這類任務要消耗的 token 總量，遠遠超過單一上下文視窗能裝的範圍。它們要求 Agent 在一長串行動裡，持續維持 連貫性、 上下文，以及朝目標前進的行為。
直覺會想：那就把上下文視窗做得更大不就好了？本節先給一個提醒：無論視窗多大，只要追求最強的 Agent 表現，就仍然會遇到 情境污染 與資訊相關性的問題——這正是呼應前面提過的 context rot。
短任務像百米衝刺，一口氣衝完不用補給。長任務像跑馬拉松——沿途得有補給站、配速策略、甚至分段接力，光靠「肺活量更大」（視窗更大）撐不完全程。
因此 Anthropic 發展出三個處理長任務情境污染的具體技巧：壓縮（compaction）、結構化筆記（structured note-taking），以及子代理架構（sub-agent architectures）。這一站，我們把三個都拆給你看。
技巧一：Compaction——把快滿的對話，蒸餾成精華
先看原文怎麼定義這個技巧，旁邊配上白話。
Compaction（壓縮）：把一段快要超過上下文視窗上限的對話做摘要，然後用這份摘要重新開一個新的上下文視窗，繼續任務。
模型會保留架構決策、還沒解決的 bug、實作細節；丟掉重複的工具輸出結果，或已經不重要的訊息。
調校訣竅是先求「不漏掉任何重要資訊」（高召回率），再回頭刪掉多餘的內容（提升精確度）——順序不能反過來。
一個工具的呼叫結果，一旦已經被埋進訊息歷史的深處，Agent 通常也不需要再看一次原始回傳——這正是最安全、影響最小的壓縮方式。
用白話說：Compaction 通常是情境工程裡拉長期連貫性的第一道防線。它不是「全部記住」也不是「全部忘記」，而是用高保真度的方式，蒸餾出對話的精華，讓 Agent 能以最小的表現折損繼續工作。
在 Claude Code 裡，做法是：把訊息歷史交給模型摘要，保留關鍵決策與未解 bug，丟棄過時雜訊，再讓 Agent 帶著這份摘要＋最近存取過的五個檔案，繼續任務——使用者感覺就是「無縫接軌」，完全不必擔心視窗爆掉。
如果每次開會都要把過去所有逐字稿重讀一遍，你會被早就解決的小事淹沒，真正的決議反而找不到。厲害的會議記錄員只留「最終決議、未解爭議、待辦事項」，這正是 compaction 的精神。而「清除工具結果」就像丟棄已經討論完、結論已經寫進紀要的舊附件 Excel——不必再翻出來。
技巧二：結構化筆記——把記憶寫到視窗之外
結構化筆記，也叫 代理式記憶（agentic memory）， 核心做法是：Agent 定期把筆記寫下來，存在上下文視窗之外的地方；這些筆記會在之後需要的時候，被重新讀取、拉回上下文中。常見的具體例子，是 Claude Code 建立的待辦清單，或自訂 Agent 維護的一份 NOTES.md 檔案。
本節用一個很有趣的非程式碼案例展示這招的威力：Claude 玩《精靈寶可夢 Pokémon》。Agent 在數千個遊戲步驟中，維持精確的計數與追蹤——而且是在完全沒有被明確教導任何記憶結構的情況下，自己發展出探索過區域的地圖、記得已解鎖的關鍵成就、還維護著戰鬥策略筆記。上下文重置之後，它讀回自己先前寫下的筆記，接著繼續長達數小時的訓練或地城探索。
把待辦事項、進度、關鍵決策寫在便利貼上貼在桌前，即使去開了一整天會，回來看一眼，馬上就想起「我剛才做到哪裡了」。NOTES.md 對 Agent 來說，就是這面便利貼牆。
這個技巧也已經正式產品化：作為 Sonnet 4.5 發布的一部分，Anthropic 推出了公開測試版的 記憶工具（memory tool）， 透過檔案系統式機制，讓 Agent 能隨時間累積知識庫、在多個工作階段之間維持專案狀態、不必把一切塞進上下文，也能參考先前的工作。
技巧三登場：三招放在一起比一比
三個技巧不是互斥的選項，而是各自解決情境污染的不同切面。先看第三招—— 子代理架構 ——再把三張卡片攤開來對比。
對話快要塞滿視窗時，先摘要出精華（架構決策、未解 bug），再開一個新視窗接著往下做。適合需要大量來回對話、講究流暢性的任務。
把進度、依賴關係寫進上下文視窗之外的檔案（像 NOTES.md），需要接續時再讀回來。適合有清楚階段性里程碑的迭代式開發任務。
主代理只管高層計畫與協調，把深入探索分給多個子代理，各自用乾淨上下文深挖，只回傳精簡摘要。適合複雜的研究與分析任務，平行探索能帶來明顯價值。
子代理架構達成清楚的 關注點分離： 細節搜尋的上下文被隔離、封裝在子代理內部，不會外溢污染主代理的上下文；主代理可以專心綜合分析各個子代理回報的結果，不需要背負每個子代理探索過程的所有細節雜訊。這個模式在《How we built our multi-agent research system》一文中有詳細討論，該研究顯示：在複雜的研究任務上，多代理系統相較單一代理系統，有顯著的表現提升。
動畫演給你看：子代理架構怎麼跑
按「下一步」，看任務怎麼從主代理拆給子代理、又怎麼濃縮回來。
需要大量來回對話、講究流暢性的任務——優先想壓縮。有清楚階段性里程碑的迭代式開發——優先想結構化筆記。需要平行深挖多個方向的複雜研究與分析——優先想子代理架構。三者也可以組合使用，而不是只能三選一。
小試身手
三招都看完了，用兩題檢查一下有沒有抓到重點。
你要打造一個 Agent，同時對五個競爭對手做深入市場調查，每個方向都要大量閱讀分析，最後彙整成一份報告。三招之中，最適合的是哪一個？
讀完 Agent 怎麼被「餵養」情境之後，換個角度——來看外界的人們，怎麼感受這一整波 AI 能力的變化。往下捲。