20251115筆記 內容可能有錯誤，請參考原始影片

[李宏毅【生成式人工智慧與機器學習導論2025】](https://www.youtube.com/playlist?list=PLJV_el3uVTsMMGi5kbnKP5DrDHZpTX0jT)

[生成式人工智慧與機器學習導論2025】第 2 講：上下文工程 (Context Engineering) — AI Agent 背後的關鍵技術](https://www.youtube.com/watch?v=lVdajtNpaGI&t=45s)

### 生成式人工智慧與機器學習導論2025】第 2 講：上下文工程 (Context Engineering) — AI Agent 背後的關鍵技術 大綱

I. **上下文工程 (Context Engineering) 概述**

A. 定義與核心概念
B. 和提示工程 (Prompt Engineering) 的關係
C. 提示工程（Prompt Engineering）的演變
D. 語言模型 (LM) 的運作方式
II. **上下文 (Context) 應包含的內容**

A. 使用者提示 (User Prompt)
B. 系統提示 (System Prompt)
C. 對話歷史記錄與記憶
D. 外部資訊（搜尋與 RAG）
E. 工具的使用
F. 模型的自我思考過程 (Reasoning)
III. **AI Agent 時代下 Context Engineering 的必要性**

A. AI Agent 的工作流程
B. 上下文窗口限制與性能退化
IV. **上下文工程 (Context Engineering) 的基本操作與策略**

A. 選擇 (Selection)
B. 壓縮 (Compression)
C. 多代理人 (Multi-Agent) 設計

### I. 上下文工程 (Context Engineering) 概述

**A. 定義與核心概念**
1. 語言模型 (Language Model) 本質上是在做**文字接龍**。它是一個函數 $f$，給定輸入 $X$（即 Prompt），輸出 $f(X)$。
2. 若輸出結果不符合預期，解決方法有兩種：
* **改變 $f$（訓練/學習）：** 改變語言模型函數內部的參數，使其行為改變。這屬於機器學習 (Machine Learning) 領域。
* **改變 $X$（上下文工程）：** 幫 $f$ 準備合適的輸入 $X$，讓最終得到的 $f(X)$ 是預期的結果。
3. 上下文工程（Context Engineering）的目標是**自動化地管理語言模型的輸入 (X)**。
4. 上下文工程的核心目標是**避免塞爆上下文 (Context)**，想辦法只放入需要的東西，並清理掉不需要的內容。

**B. 與提示工程 (Prompt Engineering) 的關係**
1. 演講者認為 Context Engineering 和 Prompt Engineering **沒有本質上的不同**。Context Engineering 只是給 Prompt Engineering 取了一個更潮的新名字，就像早期「類神經網路 (Neural Network)」後來改名為「深度學習 (Deep Learning)」一樣。
2. 雖然概念相同，但兩者關注的重點有所差異：
* **傳統 Prompt Engineering 關注點：** 特定格式（如 JSON 格式、用井字號分隔段落）或尋找神奇咒語 。
* **當代 Context Engineering 關注點：** 自動化管理 LM 的輸入，特別是在 AI Agent 時代。

**C. 提示工程（Prompt Engineering）的演變**
1. **格式的重要性下降：** 早期需要特定的格式來提示 LM，但隨著語言模型越來越強，通常人類看得懂的格式，模型也看得懂。
2. **神奇咒語的效果減弱：** 在早年 LM 較弱、輸入輸出關係無厘頭時，可能找到神奇咒語來操控模型。
* *早期 GPT-3 案例：* 在 Prompt 中加入一連串 "Ways" 可以使回答長度顯著增加。
* *廣為人知的咒語：* 「一步一步地思考 (Let’s think step by step)」(Chain of Thought, CoT)。
* *奇怪的因素：* 告訴模型「請確保你的答案是正確的」、「請深呼吸」，或「如果你答對了，我就給你一點小費」都能提升正確率。甚至有實驗指出，告訴 ChatGPT「如果你做得好，就可以達成世界和平」會讓它表現最好。
3. **咒語效果遞減：** 隨著模型發展，這些神奇咒語的效果越來越低。模型本來就應該使盡全力做到最好，不應需要額外提示（如給小費或叫它思考）。

### II. 上下文 (Context) 應包含的內容

上下文是語言模型輸入的總稱，包含多個層面：

**A. 使用者提示 (User Prompt)**
1. **基本任務：** 使用者對語言模型下達的指令。
2. **詳細指引與限制：** 除了任務說明，還需提供額外條件，讓輸出更接近所需。
* *範例：* 寫信給老師請假，需交待「開頭先道歉」、「說明遲到理由（身體不適）」、「之後會更新進度」、「信件在 100 字以內」、「講話嚴肅」等。
3. **前提資訊 (Contextual Information)：** 講清楚前提可幫助 LM 做出更好的回答。
* *範例 1：* 詢問「載具是什麼意思？」。如果沒有情境，LM 可能回答是交通工具或電子設備。若說明情境是在「超商結帳時，店員問我要用載具嗎？」，LM 則能精確回答是指「電子發票的儲存工具」。
* *範例 2：* 曼谷運河照片中的動物。如果僅提供圖片，LM 可能判斷為鱷魚。若加上情境「現在在泰國曼谷」，LM 則能回答是**水巨蜥 (Water Monitor)**，並解釋其在泰國是吉祥的象徵。
4. **範例 (Examples, In-Context Learning)：** 在 User Prompt 中加入範例會影響 LM 的答案。
* *範例：* 要求 LM 將文章改寫成「火星文」。如果沒有給範例，LM 可能自行定義火星文（如將「台」放入框框）。若給出範例（如將「要去冒險的人來找我哦」改寫為「要ㄑ冒險ㄉ來找我哦」），LM 就能理解並正確使用注音符號替換文字的火星文。
* *In-Context Learning：* 這是指透過提供範例來改變 LM 輸出的方法。這不是傳統意義上的機器學習，因為**模型參數沒有改變**。
* *Gemini 1.5 神蹟：* 證明 In-Context Learning： 能力的經典案例是 Gemini 1.5 翻譯卡拉蒙語 (Kalamang)。這種語言資料稀少，單獨提問 LM 無法翻譯。但若將卡拉蒙語的教科書和字典放入 Context 中，LM 就能進行翻譯。研究顯示，真正使模型具備翻譯能力的是教科書中的**例句**，而非文法說明。

**B. 系統提示 (System Prompt)**
1. System Prompt 是開發 LM 平台的人，認為模型在每次互動時都需要知道的資訊。
2. **內容極度複雜：** 一個好的服務，其 System Prompt 可能非常長。例如，Claude Opus 4.1 的 SP 長度超過 2500 個字。
3. **System Prompt 包含的設定 (以 Claude 為例)：**
* **身份定義：** 它叫 Claude，由 Anthropic 打造。
* **時間資訊：** 告知今天是幾月幾號。
* **使用說明與限制：** 例如詢問 API 用法時，應引導使用者閱讀特定網頁。
* **互動方式：** 如使用者不滿意，應請其按倒讚符號。
* **禁止事項：** 如不告訴使用者如何合成化學物質或製造核武器。
* **風格設定：** 不要在回答開頭說「好問題 (Good question)」。
* **知識截止日期：** 告知其知識僅到 2025 年 1 月。
* **自我定位：** 不要說自己是人類或有意識。
* **錯誤處理：** 即使人類糾正錯誤，也不要馬上承認，應仔細思考後再回答。

**C. 對話歷史記錄與記憶**
1. **對話歷史記錄 (Dialogue History)：** 相當於 LM 的**短期記憶**。LM 透過延續 Context 中的歷史記錄來做文字接龍。
* *誤解提醒：* 在對話中傳授新知識**無法改變模型參數**，也無法訓練它或改變其內部的真正行為。一旦開啟新的對話，短期記憶就會消失。
2. **長期記憶 (Long-Term Memory)：** 2024 年 9 月之後，ChatGPT 開始具備長期記憶功能。
* *運作方式：* 長期記憶會被植入到你的問題之前，但使用者通常看不到。LM 會利用過去互動的歷史記錄來形成長期記憶，並根據此記憶回答問題。
* *啟動方式：* 在 ChatGPT 的「自定 ChatGPT」—「個人化」欄位中開啟「記憶」選項。

**D. 外部資訊（搜尋與 RAG）**
1. LM 的知識可能有限且過時。我們希望**自動提供額外的相關資訊**。
2. **RAG (Retrieval Augmented Generation)：** 最常用做法是透過搜尋引擎。在問 LM 問題前，先丟到網路或資料庫搜尋，將額外資訊放入 Context 中。
* *RAG 挑戰：* 即使結合了搜尋引擎，LM 仍只是在做文字接龍，有可能犯錯。
* *經典錯誤範例：* Google AI Overview 在測試期，曾有人問「我的起司黏不在披薩上怎麼辦？」，模型根據搜尋結果（可能是 Reddit 上的玩笑話），建議「用四分之一杯**無毒的膠水**」。

**E. 工具的使用 (Tool Usage)**
1. LM 可以搭配多種工具使用，例如搜尋 Gmail、閱讀 Google Calendar，甚至直接修改 Google Calendar (如 Gemini)。
2. **工具調用原理：** 必須在 Context 中（通常是 System Prompt）寫好工具的使用方法、格式和範例。
3. **步驟詳解：**
* LM 讀取 Context 中定義的工具說明。
* LM 透過文字接龍**輸出**一段「想使用工具的指令」 (e.g., `<tool>multiply(3,4)</tool>`)。
* **此輸出本身只是一串文字**，無法真正驅動工具。
* 平台需要一個**外部程式**（如使用 `EVAL` 函數）將這串文字指令取出並執行。
* 執行後得到工具的輸出結果 (e.g., `output: 12`)。
* 平台將**工具的指令和輸出的結果**重新放回 Context 中，讓 LM 繼續做文字接龍。
* 最終 LM 根據最新的 Context 輸出答案。呼叫工具和輸出的過程可以隱藏，不給使用者看。
4. **Computer Use (電腦使用)：**
* 這是最通用且強大的工具。LM 可以使用滑鼠和鍵盤操作電腦。
* 原理與工具使用一致：給予 LM 螢幕畫面，並告知其可用的工具是「鍵盤輸入」、「移動滑鼠」和「點擊滑鼠」。

**F. 模型的自我思考過程 (Reasoning)**
1. **深度思考 (Deep Thinking)：** 許多模型聲稱具備深度思考能力 (如 CoT, DFINK)。
2. **腦內小劇場：** 當被詢問問題時，模型會先在腦中演練解法，進行規劃、嘗試和驗證，然後再給出最終答案。
3. **Context 的一部分：** 模型自我產生的思考過程（腦內小劇場）也可以視為 Context 的一部分，儘管使用者通常只能看到摘要或選擇不看。

### III. AI Agent 時代下 Context Engineering 的必要性

**A. AI Agent 的工作流程**
1. **一問一答 (傳統)：** 簡單的提問和回答。
2. **Workflow (SOP)：** 為複雜任務設定固定的標準操作程序 (SOP)，讓 LM 分多個步驟完成。
3. **AI Agent (LLM 決定步驟)：** 讓 LM **自己決定解決問題的步驟**，並根據解題過程中的變化靈活調整計畫。
* *Agent 循環：* 人類設定目標 $\rightarrow$ LM 根據當前 Observation 採取 Action (如調用工具、寫程式) $\rightarrow$ Action 影響環境 $\rightarrow$ 環境產生新的 Observation $\rightarrow$ LM 根據新 Observation 採取新 Action，持續循環。
4. **優勢：** LM 輸出的 Action 具有近乎無限的可能性，並能用人類語言提供回饋和控制。

**B. 上下文窗口限制與性能退化**
1. **挑戰：** AI Agent 任務複雜且步驟多，需要長時間運作，導致輸入 Context 過長。
2. **Context Window：** 這是模型可以接受的輸入長度上限。
* LM 在訓練時只能看最長 Context Window 範圍內的輸入，超過長度可能會導致模型發瘋。
* 現代模型（如 Gemini 1.5 Pro）號稱能支持 200 萬個 Token，長度極長（可讀完《哈利波特》全集加三本《魔戒》）。
3. **長度不等於理解：** 能輸入長 Context **不代表能讀懂**所有內容。
* **Context 飽和：** 許多實驗顯示，在達到 Context Window 上限之前，模型就已開始對輸入感到困惑。
* *RAG 失敗：* Databricks 實驗顯示，RAG 資訊越多，正確率通常先上升，但資料太擁擠時，正確率會先升後降，甚至低於給予最少資料的情況。
* **Lost in the Middle：** 模型對於長 Context，通常比較記得**開頭和結尾**的資訊。如果正確答案出現在中間的文章，模型很容易答錯，甚至可能不如讓模型憑藉自身知識直接回答。
* **冗長互動導致能力下降：** 在冗長的互動中，如果採取「擠牙膏式」的方法，將問題拆解成多個小問題，模型的表現會比一次給予完整輸入時更差，且表現不穩定 (unreliable)。
* **Context Rot：** 隨輸入長度增加，模型的複述（重複輸入文字）等基礎任務的正確率會快速下降。即使輸入遠未達到 C-Window 上限，模型也會開始感到困惑。

### IV. 上下文工程 (Context Engineering) 的基本操作與策略

Context Engineering 策略的宗旨是：將需要的東西放進 Context，並將不需要的東西清出來，保持 Context 的整潔。

**A. 選擇 (Selection)**
1. **原理：** 不要將所有東西都放入 Context，只挑選有用的資訊。
2. **RAG 選擇：** RAG 本身就是 Context Engineering 的一種重要技術。
* **Prompt 轉關鍵字：** 可以透過另一個 LM 協助，將使用者任務轉化成合適的關鍵字，用於 Google 搜尋。
* **Reranking (重新排序)：** 搜尋引擎給予的文章不一定都相關。可以使用一個較小的 LM 再次篩選，只選擇與使用者 Prompt 最相關的文章放入 Context。
* **選句子 (Sentence Selection)：** 利用一個參數小於 300M 的快速模型來判斷每個句子與 User Prompt 的相關性。
3. **工具選擇 (Tool Selection)：**
* 如果模型有 1000 個工具，不能將所有工具的使用說明都放入 SP，否則會塞爆 Context。
* 應將每個工具的使用說明視為一篇文章，根據使用者需求，執行**工具版 RAG**，只搜尋出相關的工具說明，放入 Context 中。
* 給予 LM 過多工具會使其發瘋。
4. **記憶選擇 (Memory Selection)：**
* 長久記憶不能將過去發生的一切瑣碎小事都放入 Context。
* 透過對記憶做 RAG，將記憶儲存在外部（如硬碟），只在必要時搜尋出最相關的記憶。
* *史丹佛小鎮案例：* Agent 的瑣碎記憶（如「桌子、床、衣櫃、冰箱沒發生任何事」）儲存在硬碟中。
* *記憶評分標準：* 判斷記憶重要性可依據三個指標：
* **最近性 (Recency)：** 越近發生的事分數越高。
* **重要性 (Importance)：** 記憶剛生成時，Agent 需反思其重要性（如「有人跟他告白」重要性為 9，「有張床」重要性為 0）。
* **相關性 (Relevance)：** 記憶與當前問題的相關程度。
* *負面範例的傷害：* 實驗顯示，如果給模型過去**答錯的記憶**，模型的表現反而會大幅受損；只給答對的記憶表現最好。給予負面例子可能就像是叫人「不要想白熊」，反而更容易想到。

**B. 壓縮 (Compression)**
1. **原理：** 當 Context Window 被塞滿時，將過去的歷史記錄進行**摘要或壓縮**。
2. **遞迴式壓縮 (Recursive Compression)：**
* 使用一個專門做摘要或壓縮的 LM，讀取過去的歷史記錄，只抽取最關鍵的部分，當作長期的、概略的歷史記錄。
* 可以設定每互動 100 次或 Context 達到 90% 飽和時，就進行一次壓縮。
* 越久遠的記憶會隨時間慢慢消失。
3. **應用：**
* **Chatbot 記憶：** ChatGPT 的記憶系統可能有兩種，一種是明確記錄的筆記本（永不消失），另一種是會隨時間慢慢消失的記憶，可能就是利用類似遞迴式壓縮技術。
* **Computer Use 摘要：** 在 Computer Use 過程中會產生大量瑣碎的互動細節（如滑鼠移動、彈出廣告後按 X）。這些細節應被壓縮，只需保留最終結果（如「A 餐廳訂位成功，9 月 19 號下午 6 點，10 個人」）。
4. **壓縮與儲存：** 如果擔心摘要會丟失關鍵資訊，可以在摘要前將完整的內容存入可長期儲存的外部空間（如硬碟），日後需要時再用 RAG 讀取。

**C. 多代理人 (Multi-Agent) 設計**
1. **原理：** 讓多個 Agent 各司其職（如 Context EngineeringO、Programmer、Tester），每個 Agent 負責一部分工作。
2. **Context 管理優勢：** Multi-Agent 系統是管理 Context 的有效方法，即使 Agent 沒有不同的專長，也能帶來幫助。
* **Context 分段：** 複雜的任務（如組織出遊，需規劃行程、訂餐廳、訂旅館）會產生大量 Computer Use 互動，快速塞爆單一 Agent 的 Context。
* **分工與隔離：** 透過多 Agent 分工，總招 Agent 只需知道「餐廳訂好了」和「旅館訂好了」，而不需要知道訂位或訂房過程中的所有細節。
* 負責訂餐廳的 Agent 不需知道訂旅館的事，反之亦然。每個 Agent 的 Context 裡都只包含與自己任務相關的內容，使其 Context 保持較短和高效。
3. **學術界應用：**
* **撰寫 Overview Paper：** 寫一篇綜述論文需要閱讀上百上千篇論文。如果讓一個單一 Agent 閱讀所有文獻，會超出 Context Window 上限。
* 可採用 Multi-Agent 設計，讓不同的 Agent 閱讀不同的論文，各自寫出摘要，最後再交由一個總負責的 Agent 撰寫最終的 Overview Paper。
4. **性能比較：** 在任務比較簡單時，Single Agent 表現可能比 Multi-Agent 好。但當任務**非常複雜**時，Multi-Agent 能佔到巨大的優勢。