生成式人工智慧與機器學習導論2025 — 為什麼上下文工程（Context Engineering）是 AI Agent 時代的關鍵技術？

生成式人工智慧與機器學習導論2025 — 為什麼上下文工程（Context Engineering）是 AI Agent 時代的關鍵技術？¶

在生成式 AI 的浪潮中，我們最初學會的是 Prompt Engineering（提示工程）。當時，大家熱衷於尋找「神奇咒語」，像是加上「讓我們一步一步思考」或是給模型一點「小費」，來誘發模型不可思議的力量。然而，隨著模型能力提升，這些咒語的邊際效應正在遞減。

進入 AI Agent（AI 代理人） 的時代後，技術核心已經轉向了更為系統化的 Context Engineering（上下文工程）。

什麼是上下文工程？

簡單來說，如果將語言模型看作一個函式 f，輸入是 X，輸出是 f(X)。當輸出不符合預期時，我們若無法修改模型（f）本身，就必須改進輸入（X）。

上下文工程與提示工程本質上非常相似，但關注點不同。 過去提示工程專注於格式（如 JSON）或咒語；而上下文工程則強調「自動化地管理模型的輸入」，透過動態調整，確保模型在長時運作中仍能保持高效。

一個完整的「上下文」包含什麼？

在現代 AI 應用中，餵給模型的輸入早已不只是你問的那句話，它是一個極其複雜的集合體，包含：

1. 使用者指令 (User Prompt)：具體的任務說明、條件限制或參考範例（In-context Learning）。

2. 系統提示 (System Prompt)：定義模型的人設（如：你叫 Claude）、行為準則（如：不要隨便認錯）及知識截止日期。

3. 對話歷史與長短期記憶：作為模型的短期記憶，現在甚至有隱藏的長短期記憶機制（如 ChatGPT 的 Memory 功能）。

4. 外部資訊 (RAG)：透過搜尋引擎或資料庫檢索出的最新資訊。

5. 工具執行結果：模型呼叫外部工具（如計算機、氣象查詢、甚至控制滑鼠鍵盤）後回傳的數據。

6. 思考過程 (Reasoning)：模型內部的「腦內小劇場」，在給出答案前進行的規劃與驗證。

為什麼上下文需要「工程化」？：避開塞爆的陷阱

上下文工程的核心目標只有一個：避免塞爆上下文 (Context Window)，並清除不需要的內容。

雖然像 Gemini 1.5 這樣的模型已支持高達 200 萬個 token 的輸入，但「能輸入」不代表「能讀懂」。研究顯示，模型會面臨以下挑戰：

• Lost in the Middle：模型通常只記得開頭跟結尾，容易遺忘中間的資訊。

• Context Rot（上下文腐爛）：當輸入過長或互動過於冗長，模型的理解能力會大幅下降。

上下文工程的三大常用招數

為了管理有限且珍貴的上下文空間，開發者通常採用以下三種策略：

1. 選擇 (Selection)： 不把所有資料塞進去，而是精挑細選。例如利用 RAG (檢索增強生成) 只撈取最相關的文獻；或是針對「記憶」進行篩選，只留下最重要或最近發生的事件。值得注意的是，有研究發現給予模型「過去錯誤的經驗」有時反而會降低表現，給予正確範例的效果通常更好。

2. 壓縮 (Compression)： 當對話過長時，利用另一個語言模型對過去的歷史進行「摘錄」或「遞迴式壓卡」。這在 Computer Use（模型控制電腦）的場景尤為重要，因為大量的滑鼠移位指令極度瑣碎，必須濃縮成具體的任務狀態（如：餐廳已訂好）。

3. 多代理人架構 (Multi-agent)： 這是一種有效的管理手段。將複雜任務拆分給不同的 Agent（如：CEO 下令、Programmer 寫 code）。每個 Agent 只需要掌管自己負責部分的上下文。 這樣能確保每個節點的上下文都保持短小、乾淨且精確，避免單一 Agent 因為資訊過載而崩潰。

結語

AI Agent 的強大並非來自全新的黑科技，而是依賴於模型現有的接續能力。上下文工程 就像是 AI 的「環境清理者」與「記憶管理員」，透過精準控制輸入，讓 AI 能夠在複雜的長程任務中，依然保持清晰的思維。

註：本文內容參考自 Hung-yi Lee YouTube 頻道《生成式人工智慧與機器學習導論 2025》課程。

生成的介紹短影音請參閱 上下文工程：強大AI代理人背後的秘密