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

本講深入探討了 **Context Engineering (上下文工程)** 的概念，這是在 AI Agent 時代為了讓模型能處理複雜任務、長時間運作而衍生的關鍵技術。課程首先釐清其與 Prompt Engineering 的異同，接著詳細解構一個完整的 Context 應包含的七大要素（從 Prompt 到工具使用、長期記憶等）。隨後，課程分析了長 Context 面臨的技術挑戰（如 Lost in the Middle），並提出了三大 Context Engineering 的核心策略：**選擇 (Selection)**、**壓縮 (Compression)** 與 **多代理人 (Multi-Agent)**，旨在有效管理有限的 Context Window，提升模型表現。

<br>

## 01. Context Engineering 的概念與演變

### 01-01. 從 Prompt Engineering 到 Context Engineering

* **核心論點**：語言模型可視為一個函式 ，其中 是模型參數， 是輸入 (Context/Prompt)。由於我們通常無法修改模型參數 （那是訓練/學習），因此 Context Engineering 專注於優化輸入 ，以獲得預期的輸出 。
* **關鍵細節**：
1. **新瓶裝舊酒**：本質上與 Prompt Engineering 相同，但在 Agent 時代更強調「自動化管理輸入」。
2. **咒語時代的終結**：早期 GPT-3 時代依賴「神奇咒語」（如 "Let's think step by step"、"給小費"、"深呼吸"）來提升效能。數據顯示，隨著模型變強（如 GPT-4），這些咒語帶來的邊際效益已大幅遞減，現代模型應在無咒語下也能表現良好。


:::success
**💡重點筆記**：舉例

早期實驗發現，若在 Prompt 中告訴 AI「如果你做得好，就能達成**世界和平**」，ChatGPT 的表現會顯著提升（勝過給小費或讓母親驕傲）。但這類 Trick 在新模型中已不再是關鍵。
:::

### 01-02. 為什麼需要 Context Engineering？

* **核心論點**：雖然模型能力變強，但因為 AI Agent 需要處理多步驟、長時間的任務，Context 的管理變得至關重要。
* **關鍵細節**：
1. 目標是讓 AI 自動決定解題步驟，並根據環境回饋靈活調整。
2. 核心精神：**避免塞爆 Context**，只放需要的資訊，清理不需要的雜訊。

<br>

## 02. Context (上下文) 的組成要素

### 02-01. User Prompt 與前提設定

* **核心論點**：除了任務指令，必須提供詳細指引（格式、語氣、長度）與「前提情境」，否則模型會誤解。
* **關鍵細節**：
1. **消除歧義**：同樣的詞彙在不同情境有不同意義。
2. **提供範例 (In-Context Learning)**：給予明確的 Input-Output 範例，能讓模型在不更新參數的情況下學會新任務（如火星文轉換、新語言翻譯）。


:::success
**💡重點筆記**
* **歧義**：問 AI「要用載具嗎？」，它可能以為是交通工具。若加上前提「在超商結帳時」，它就知道是指電子發票載具。
* **情境**：一張在河裡看起來像鱷魚的照片，若沒給前提，AI 說是鱷魚；若告知「這是在泰國曼谷運河」，AI 會修正為「水巨蜥 (Water Monitor)」，因為那是當地的特有生物。
* **In-Context Learning**：Gemini 1.5 透過閱讀教科書與字典的 Context，就能學會冷門語言「卡拉蒙語 (Kalamang)」，關鍵在於教科書中的**例句**。

:::

### 02-02. System Prompt (系統提示詞)

* **核心論點**：由開發者預設，定義模型的身份、限制與行為準則。
* **關鍵細節**：
1. **Claude Opus 案例**：System Prompt 長達 2500+ 字。包含身份（Claude）、日期、回答風格（不要說 "Good Question"）、知識截止日期，以及如何應對人類糾正（不要盲目認錯）。
2. 這解釋了為何模型知道自己是誰或今天的日期。

### 02-03. 記憶機制 (Memory)

* **核心論點**：分為短期記憶（對話歷史）與長期記憶。
* **關鍵細節**：
1. **短期記憶**：將過去的對話紀錄串接在新的 Prompt 前。
2. **長期記憶**：如 ChatGPT 的 Memory 功能，能跨對話記住使用者的偏好或特定事實。

:::success
**💡重點筆記**：舉例

如果你在某次對話教 ChatGPT「隔壁老王姓法，叫法老王」，開啟長期記憶後，即便開新對話，它仍能回答隔壁老王是法老王。
:::

### 02-04. 外部資訊與 RAG

* **核心論點**：透過搜尋引擎檢索外部資訊 (Retrieval-Augmented Generation)，補充模型知識的不足與過時。
* **關鍵細節**：
* **AI 幻覺風險**：即便有搜尋引擎，模型仍可能誤信網路上的錯誤資訊。


:::success
**💡重點筆記**：舉例

Google AI Overview 曾建議使用者用「1/8 的無毒膠水」來解決起司從披薩滑落的問題，這是因為它誤信了 Reddit 上的玩笑貼文。
:::
>
### 02-05. 工具使用 (Tool Use / Function Calling)

* **核心論點**：模型可透過輸出特定的文字指令來呼叫外部工具（計算機、日曆、API）。
* **運作原理**：
1. 在 Prompt 定義工具格式（如 `<tool>name</tool>`）。
2. 模型輸出工具指令（純文字）。
3. 程式攔截該指令，執行 `eval()` 或 API 呼叫。
4. 將工具執行結果（Output）塞回 Context。
5. 模型根據結果生成最終回應。


* **Computer Use**：進階的工具使用，讓 AI 直接操控滑鼠與鍵盤，像人一樣操作電腦介面（如訂高鐵票、玩貪食蛇）。



* **實作演示**：透過 Colab 示範 Gemma 模型呼叫 `multiply` 和 `divide` 函式進行運算，以及使用 Gemini CLI 刪除檔案或開啟投影片。


#假設我們有兩個小工具: multiply, devide，他們會把兩個輸入的數字 a 和 b 進行相乘或是相除

def multiply(a,b):
  return a*b

def devide(a,b):
  return a/b

#理論上，只要呼叫上面這兩個工具就可以做乘法和除法
#但不要忘了，語言模型基本上輸出的是文字，例如他頂多只能產生 "multiply(3,4)"，這只是一串文字不會有任何效果
#在 colab 上，如果要讓一串文字被執行，需要用 eval("一串文字")，所以我們需要用 eval("使用工具指令") 才能使用工具

eval("multiply(3,4)")

#真的來使用工具

tool_use = """
      有必要可以使用工具，每一個工具都是函式。
      使用工具的方式為輸出 "<tool>[使用工具指令]</tool>"。
      你會得到回傳結果 "<tool_output>[工具回傳的結果]</tool_output>"。
      如果有使用工具的話，你應該告訴使用者工具回傳的結果。

      可用工具：
      multiply(a,b): 回傳 a 乘以 b
      devide(a,b): 回傳 a 除以 b
      """

#user_input = "111 x 222 / 777 =? " #正確答案是 31.71428...
user_input = "你好嗎?"

messages = [
             {
        "role": "system",
        "content": [
            {"type": "text", "text": tool_use}
        ]
    },
                   {
        "role": "user",
        "content": [
            {"type": "text", "text": user_input}
        ]
    }
]

while True:

  outputs = pipe(messages, max_new_tokens=1000) #跑語言模型

  response = outputs[0]["generated_text"][-1]['content'] #語言模型實際的輸出

  if ("</tool>" in response): #如果輸出有要「使用工具」，我們需要剖析語言模型要用甚麼工具，並且幫忙執行工具
    commend = response.split("<tool>")[1].split("</tool>")[0] #從字串 response 中，抓取第一個 <tool> 和 </tool> 之間的內容，並把它存到變數 commend 裡
    print("呼叫工具:", commend)
    tool_output = str(eval(commend)) #eval(commend) 才能真的去執行 commend 這段程式碼
    print("工具回傳:", tool_output)

    response  =  response.split("</tool>")[0] + "</tool>" #把</tool>之後的內容截掉
    messages.append(      {
        "role": "assistant",
        "content": [
            {"type": "text", "text": response} #使用工具
        ]
    }
    )

    output = "<tool_output>" + tool_output + "</tool_output>"   #加入把工具執行結果
    messages.append(      {
        "role": "user",
        "content": [
            {"type": "text", "text": output} #工具回傳
        ]
    }
    )
  else:
    print("LLM的輸出(不顯示使用工具的過程)：", response)
    break

### 02-06. 深度思考 (Reasoning / Inner Monologue)

* **核心論點**：模型在回答前先進行「腦內小劇場」（Chain of Thought），自我規劃、驗證假設。
* **關鍵細節**：這些思考過程也是 Context 的一部分（雖然使用者未必看得到），模型是根據自己的思考過程來生成最終答案。


<br>

## 03. AI Agent 面臨的挑戰：Context Window

### 03-01. 無限增長的 Context 與副作用

* **核心論點**：AI Agent 長時間運作會累積大量 Context，雖然模型宣稱支援百萬級 Token（如 Gemini 1.5, Llama 4），但「能輸入不代表能讀懂」。
* **關鍵細節**：
1. **Lost in the Middle**：模型對長文本的開頭和結尾記憶較好，中間的資訊容易被忽略。
3. **Context Rot (上下文腐爛)**：隨著輸入變長，模型複製文字等簡單任務的準確度會下降。
4. **資料量的倒 U 型曲線**：RAG 檢索過多資料反而會導致模型混淆，準確率下降。
5. **拆解任務的代價**：將問題拆成太多小步驟（Salami slicing）有時反而降低模型的可靠性 (Unreliability)。


<br>

## 04. Context Engineering 的三大操作策略


### 04-01. 策略一：選擇 (Selection)

**核心論點**：不要把所有資訊塞進 Context，只挑選最相關的。

**關鍵細節**：
- **RAG 與 Reranking**：先搜尋，再用小模型對搜尋結果進行二次篩選 (Reranking)，甚至只挑選相關的「句子」。


* **Tool RAG**：若工具有上千個，只檢索與當前任務相關的工具說明放入 Context。


* **Memory Selection (史丹佛小鎮機制)**：依照三個指標篩選記憶：
1. **Recency** (最近發生的)
2. **Importance** (重要性，如告白 > 看到床)
3. **Relevance** (與當前問題的相關性)



* **StreamBench 發現**：提供類似的「成功案例」對模型有幫助，但提供「負面案例（錯誤經驗）」反而可能造成傷害（白熊效應）。



### 04-02. 策略二：壓縮 (Compression)

* **核心論點**：對歷史紀錄進行摘要，避免 Context 過長。
* **關鍵細節**：
1. **遞迴式壓縮**：每互動 100 次或 Context 滿了，就將過去內容摘要成重點，舊的細節隨風而逝。
2. **過濾瑣碎資訊**：在 Computer Use 中，滑鼠移動軌跡、廣告視窗關閉等過程不需要保留，只需留下「訂位成功」的結果。
3. **分層儲存**：被壓縮/丟棄的細節可存入硬碟（無限空間），需要時再透過 RAG 找回。

### 04-03. 策略三：多代理人 (Multi-Agent)

* **核心論點**：透過分工合作，讓每個 Agent 只需維護自己相關的 Context，避免單一 Agent Context 爆炸。

**關鍵細節**：
- **Context 分流**：
1. 「總召 Agent」只管大方向（餐廳訂沒？旅館訂沒？），Context 簡短。
2. 「訂餐廳 Agent」只管跟餐廳網頁互動，不需要知道旅館的資訊。

* **平行處理**：撰寫 Overview Paper 時，讓不同的 Agent 分別閱讀不同的論文，最後再彙整。這樣每隻 Agent 的 Context 都不會超載。

* **效能比較**：簡單任務 Single-Agent 較好；極度複雜任務 Multi-Agent 優勢顯著（LangChain 研究）。

:::success
**💡重點筆記**：比喻

如同軟體公司（ChatDev），CEO、工程師、測試員各司其職。CEO 不需要知道每一行程式碼怎麼寫（Context 分離），只需知道功能是否完成。
:::

<br>

## 🎯 總結 (Key Takeaways)

* **關鍵術語表**：
1. **Context Engineering**：管理語言模型輸入的技術，核心在於選擇與壓縮，確保模型在有限 Context Window 下高效運作。
2. **In-Context Learning**：透過在 Prompt 中提供範例，讓模型在不更新參數下學會新任務。
3. **RAG (Retrieval-Augmented Generation)**：檢索增強生成，結合搜尋引擎與語言模型。
4. **Lost in the Middle**：長文本輸入中，模型容易忽略中間段落資訊的現象。
5. **Computer Use**：AI Agent 直接操控電腦介面（滑鼠、鍵盤）來完成任務。

* **總結**：Context Engineering 是 AI Agent 的大腦管理術，透過精準的**選擇**、智慧的**壓縮**與**多代理人分工**，克服模型記憶短板，實現複雜且長時間的任務執行。