Context Engineering
為什麼重要
深度解析
上下文工程將上下文視窗視為需要管理的資源，具有預算、生命週期及已知失敗模式。一次典型 LLM 呼叫會從許多來源組合上下文：定義行為的系統提示詞、少樣本範例、透過檢索取得的文件、工具定義及其結果、長期記憶，以及持續累積的對話紀錄。這門學科要決定哪些內容值得放入視窗、採用什麼格式與順序、何時更新或壓縮，以及如何排除無關或錯誤資訊。提示詞工程詢問如何表達指示，上下文工程則詢問模型在收到指示時應該已經知道什麼。
上下文預算
上下文視窗已從數千個 token 成長至數十萬個甚至更多，但空間從來不是免費的。每增加一個 token，都會提高每次呼叫的延遲與成本，而注意力也難以有效擴展：長上下文模型研究顯示，埋在長提示詞中段的資訊，使用可靠度低於靠近開頭或結尾的內容，這種模式稱為「迷失於中間」。因此，實用的上下文工程必須編列預算。團隊會將較早的對話輪次壓縮成滾動摘要、把冗長工具輸出縮減至重要欄位、刪除重複的樣板內容，並將參考資料從提示詞移至檢索系統，只在相關時取回。目標是建立最小的上下文，同時包含模型完成目前步驟所需的一切。
執行階段組合上下文
現代應用程式會動態建立上下文，而非手動撰寫。RAG 管線會檢索與使用者問題相關的文件，並在呼叫時注入內容；記憶系統可跨工作階段保留關於使用者的長期事實；工具使用和 MCP 等協定，則讓模型在對話途中取得即時資料，並將每項結果加入下一步的上下文。智能體迴圈將這種做法推至極致：每項觀察、動作與中間結果都會進入上下文，因此上下文實際上成為代理的工作狀態，將短期記憶與計畫合而為一。這正是上下文工程在代理設計中特別重要的原因——在 50 個步驟的執行過程中，決定哪些內容要保留、摘要或捨棄，往往就是代理維持任務方向或逐漸偏離的關鍵。
更大的視窗並非解方
常見的誤解，是認為百萬 token 上下文視窗讓上下文工程不再必要——只要將所有內容放進去，讓模型自行整理即可。實務上，長上下文會產生自己的失敗模式。上下文腐化是指視窗逐漸填滿時，效能緩慢降低：即使模型宣稱支援極長上下文，隨輸入長度增加，檢索型問題的準確率仍會下降。上下文中毒更為棘手：一旦幻覺產生的主張、過時事實或遭注入的指示進入上下文，模型便容易將其視為事實並繼續推演；將自身輸出寫回上下文的代理，還可能把早期的一次錯誤放大至所有後續步驟。相關失敗模式還包括上下文干擾，也就是無關資料讓模型偏離任務；以及上下文衝突，也就是視窗內的矛盾資訊導致模稜兩可的回答或任意選擇。整理輸入、驗證寫回內容、防禦提示注入，並定期重置上下文，都是標準因應措施。
從提示詞工程到上下文工程
較早出現的提示詞工程著重措辭：指示文字、少樣本範例選擇與角色提示。它假設由人類面對幾乎空白的視窗撰寫單一提示詞。當應用程式發展成管線與代理後，瓶頸便轉移了——困難之處變成管理資訊如何流入由指示、資料、工具及歷史紀錄共同使用的視窗，而且大部分內容由軟體組合，而非使用者輸入。「上下文工程」一詞於 2025 年在實務人員間流行，正好為這項轉變命名，也因為描述了團隊原本就在進行的工作而沿用至今。提示詞技巧依然重要，上下文學習也仍是所有方法所依賴的機制；但措辭如今只是更廣泛工程範圍中的一項元件，這個範圍還包括檢索品質、記憶設計、工具輸出格式及上下文生命週期管理。