Guides-Context Engineering(語境工程)

pinting · August 4, 2025, 9:40am

Guides-Context Engineering(語境工程)

當前的大型語言模型（LLMs）越來越強大，能夠協助人們處理各種任務，但模型的表現往往高度依賴「上下文」的設計與提供，這正是「語境工程（Context Engineering）」的核心。

本篇將帶你深入了解這項新興技能，涵蓋從提示語優化到多代理人系統的上下文設計、從結構化輸入到歷史狀態管理，並透過實際案例說明、清晰的步驟與範本，幫助你在實作上少走彎路。

本篇目標

什麼是 Context Engineering（語境工程）？

Context Engineering 是設計與優化 LLMs（大型語言模型）上下文的過程，以幫助模型更有效地完成任務，它是 Prompt Engineering（提示工程）的進階與擴展，涵蓋更多結構性、系統性的設計工作。

關於 Context Engineering（語境工程），已有不少文章可以參考，例如: Ankur Goyal、Walden Yan、Tobi Lutke 和 Andrej Karpathy 等。
以下是由 Dex Horthy 所繪製的圖示，將以此為基礎說明語境工程以及其核心概念。

與 Prompt Engineering 的差異

面向	Prompt Engineering	Context Engineering
核心	著重在設計單一提示語	著重在整體上下文架構設計
關注點	常為單次提問（blind prompting）	包含提示鏈設計、記憶管理、工具指令優化等
對象	LLM 的單次生成	LLM 在一段任務流程中的行為
工具依賴	純文字與模型 API 參數	API、外部資料庫、工具調用、對話管理
其他		具有系統性驗證

核心任務與技巧

提示設計
- 設計與管理提示鏈（prompt chains）
- 調整系統提示與指令語句（system prompts）
動態管理
- 管理動態元素（如使用者輸入、日期、時間等）
知識處理
- 搜尋與準備相關知識（RAG）
- 查詢增強（Query augmentation）
工具定義
- 定義代理系統中的工具與操作說明
示範優化
- 準備並優化 few-shot 示範案例
資料格式結構
- 結構化輸入與輸出格式（如分隔符、JSON schema）
記憶管理
- 管理短期記憶（狀態與歷史脈絡）
- 管理長期記憶（向量資料庫檢索相關知識）
其他優化技巧
- 其他可用於優化 LLM 系統提示語、達成任務的技巧

適用範圍

純文字 LLMs
多模態模型（圖像、語音等）
AI Agents 系統
任務導向型應用（如客服、輔助寫作、診斷系統等）

Context Engineering的核心目標

在有限的 context window 中，提供最有用、最有效的訊息組合，同時過濾雜訊，使模型產出更加可靠。

Context Engineering 實務應用

應用場景

目的：用於個人用途的「多智能體深度研究應用」（Multi-agent Deep Research Application）。
技術領域：Context Engineering 應用於 Agentic Workflow 設計。

實作工具

使用 n8n 建立整體的智能體工作流程。
強調：工具本身並非重點，重點是設計出的智能體架構（Agent Architecture）。

架構概要

涵蓋多個智能體、提示優化（Prompt Optimization）、訊息流轉等設計。

工作流程中的 搜尋規劃代理（Search Planner agent） 負責根據使用者查詢來產生搜尋計畫。

系統提示

這裡以一個子代理（subagent） 系統提示的設計作為範例：

你是一位專業的研究規劃員。你的任務是將一個複雜的研究查詢（以 <user_query></user_query> 標示）拆解成具體的搜尋子任務，每個子任務聚焦於不同面向或資料來源類型。

目前的日期與時間是：{{ $now.toISO() }}

對於每個子任務，請提供以下資訊：

1. 子任務的唯一字串 ID（例如：subtask_1、news_update）
2. 具體的搜尋查詢語句，聚焦於主查詢的一個特定面向
3. 資料來源類型（web、news、academic、specialized）
4. 時間範圍相關性（today、last week、recent、past_year、all_time）
5. 主題領域焦點（如：technology、science、health），若無則可為 null
6. 優先級等級（1 = 最高，5 = 最低）

每個子任務的所有欄位（id、query、source_type、time_period、domain_focus、priority）都是必要的，其中 time_period 和 domain_focus 若無適用可為 null。

請建立2 個子任務，它們能共同全面涵蓋此主題。請聚焦於不同面向、觀點或資訊來源。

每個子任務請包含以下資訊欄位：

id: 字串
query: 字串
source_type: 字串 # 例如 "web", "news", "academic", "specialized"
time_period: 選填字串 # 例如 "today", "last week", "recent", "past_year", "all_time"
domain_focus: 選填字串 # 例如 "technology", "science", "health"
priority: 整數 # 1（最高）到 5（最低）

完成上述欄位後，請為每個子任務額外新增兩個欄位：start_date 與 end_date，根據所選的 time_period  推論出對應的日期區間。

請使用以下格式輸出這兩個欄位（範例）：

"start_date": "2024-06-03T06:00:00.000Z",
"end_date": "2024-06-11T05:59:59.999Z"

有效語境工程的核心概念（Context Engineering Essentials）

設計提示語不只是「寫一段指令」，而是需要系統性地設計語境（Context）來幫助模型高效執行任務。

核心構面拆解（Core Components）

構面	說明
目標明確性	清楚界定代理的任務是什麼，例如：搜尋規劃、資料整理、決策判斷。
語境提供	提供必要的背景資訊，例如使用者查詢、任務限制、資料格式等。
分工設計	每個子代理（sub-agent）要有清楚職責，避免語境混淆。
提示結構	設計合理的 prompt 架構，例如包含目標、角色、輸入格式、輸出要求。
反覆實驗	不斷測試與優化提示語與語境內容，以提升準確性與穩定性。

實作提醒

不是單靠自然語言的提示就足夠，語境的完整性會大幅影響任務表現。
多代理系統中特別重要，每個 agent 都需獲得適當上下文。
需針對不同任務設計不同的語境策略。

說明

這部分是提供給系統的高階指令，目的是明確告訴它該執行什麼任務。

你是一位專業的研究規劃員。你的任務是將一個複雜的研究查詢（以 <user_query></user_query> 標示）拆解成具體的搜尋子任務，每個子任務聚焦於不同面向或資料來源類型。

從上面完整的提示語（prompt）來看，要讓系統按照我們的期望運作，還需要提供更多的背景資訊(上下文說明)，這就是「情境工程（context engineering）」的核心——讓系統更清楚了解問題的範圍，以及我們具體想要它產出的內容。

使用者輸入

使用者輸入不會在系統提示中直接呈現，以下範例呈現及說明:

<user_query> OpenAI 最新的開發消息是什麼？ </user_query>

請注意使用分隔符（delimiters）是為了更好地結構化提示語，可以避免混淆，並且讓系統更清楚知道哪些是用戶輸入、哪些是我們希望系統生成的內容，有時我們輸入的信息類型會和我們希望模型輸出的內容相關聯（例如:查詢是輸入，而子查詢則是輸出）。

結構化的輸入與輸出

除了高層次的指令和用戶輸入之外，在規劃代理人需要產生的子任務細節上也需要注意。
以下是提供給規劃代理人的詳細指示，可以根據用戶查詢創建子任務:

對於每個子任務，請提供以下資訊：

1. 子任務的唯一字串 ID，例如：subtask_1、news_update
2. 具體的搜尋查詢語句，聚焦於主查詢的一個特定面向
3. 資料來源類型（web、news、academic、specialized）
4. 時間範圍相關性（today、last week、recent、past_year、all_time）
5. 主題領域焦點（如：technology、science、health），若無則可為 null
6. 優先級等級（1 = 最高，5 = 最低）

每個子任務的所有欄位（id、query、source_type、time_period、domain_focus、priority）都是必要的，其中 time_period 和 domain_focus 若無適用可為 null。

請建立2 個子任務，它們能共同全面涵蓋此主題。請聚焦於不同面向、觀點或資訊來源。

仔細看上面的指示，目的是希望規劃代理產生的必要資訊整理成清單，並附上一些提示或範例幫助更好地引導資料生成過程，這對於讓規劃代理理解預期內容非常關鍵，舉例來說如果你說明優先級是用1到5的等級，可能會使用1到10的等級，因此上下文非常重要！

接著是結構化輸出，為了讓規劃代理輸出結果更一致，我們也會提供一些關於子任務格式和欄位類型的上下文，以下是我們提供給代理的範例，這會給代理提示和線索，並產出更符合我們期待的輸出結果：

每個子任務請包含以下資訊欄位：

id: 字串
query: 字串
source_type: 字串 # 例如 "web", "news", "academic", "specialized"
time_period: 選填字串 # 例如 "today", "last week", "recent", "past_year", "all_time"
domain_focus: 選填字串 # 例如 "technology", "science", "health"
priority: 整數 # 1（最高）到 5（最低）

另外在 n8n 中你也可以使用一個 工具輸出解析器（tool output parser），這個功能主要用來結構化最終的輸出結果，以下是一個 JSON 範例：

{
  "subtasks": [
    {
      "id": "openai_latest_news",
      "query": "OpenAI 最新公告與新聞",
      "source_type": "news",  // 資料來源類型為新聞
      "time_period": "recent",  // 時間範圍為近期
      "domain_focus": "technology",  // 主題聚焦為科技
      "priority": 1,  // 優先順序為最高
      "start_date": "2025-06-03T06:00:00.000Z",  // 開始日期
      "end_date": "2025-06-11T05:59:59.999Z"  // 結束日期
    },
    {
      "id": "openai_official_blog",
      "query": "OpenAI 官方部落格近期文章",
      "source_type": "web",  // 資料來源類型為網頁
      "time_period": "recent",
      "domain_focus": "technology",
      "priority": 2,
      "start_date": "2025-06-03T06:00:00.000Z",
      "end_date": "2025-06-11T05:59:59.999Z"
    }
    ...
  ]
}

這個工具會自動根據這些範例產生對應的資料結構（schema），這樣系統就能解析並生成正確的結構化輸出，如下方範例所示：

[
  {
    "action": "parse",
    "response": {
      "output": {
        "subtasks": [
          {
            "id": "subtask_1",
            "query": "OpenAI 近期公告 或 新聞 或 更新",
            "source_type": "新聞",
            "time_period": "近期",
            "domain_focus": "科技",
            "priority": 1,
            "start_date": "2025-06-24T16:35:26.901Z",
            "end_date": "2025-07-01T16:35:26.901Z"
          },
          {
            "id": "subtask_2",
            "query": "OpenAI 官方部落格 或 新聞稿",
            "source_type": "網路",
            "time_period": "近期",
            "domain_focus": "科技",
            "priority": 1.2,
            "start_date": "2025-06-24T16:35:26.901Z",
            "end_date": "2025-07-01T16:35:26.901Z"
          }
        ]
      }
    }
  }
]

這些東西看起來很複雜，但如今許多工具本身就支援結構化輸出功能，因此不需要自己實作，且n8n 讓這部分的脈絡工程變得輕而易舉，這也是許多 AI 開發者常忽略的一個重要技巧。
語境工程是一種非常強大的方法，當代理模型產生的輸出格式不一致，而又需要將資料以特定格式傳遞給下一個流程元件時，就非常適用。

工具

使用 n8n 來建立代理流程，需要在上下文中加入目前的日期和時間，可以這樣做：

目前的日期與時間是：{{ $now.toISO() }}

在 n8n 中，可以用簡單的函式動態取得當前日期時間，提升流程靈活性。
語境工程的核心：明確決定什麼時候、傳遞哪些上下文給 LLM，避免錯誤與不準確。

日期、時間是關鍵語境，缺少它會讓系統對「近期」等時間相關查詢無法準確回應，以「搜尋OpenAI上週最新消息」為例，若無準確日期時間，系統只能憑猜測定義查詢範圍，影響搜尋結果準確度，傳入正確日期時間，能協助系統推斷正確時間區間，優化搜尋和工具操作結果，我把這部分當作語境傳入，讓 LLM 可以依此產生合適的日期範圍：

完成上述欄位後，請為每個子任務額外新增兩個欄位：start_date 與 end_date，根據所選的 time_period  推論出對應的日期區間。

請使用以下格式輸出這兩個欄位（範例）：

"start_date": "2024-06-03T06:00:00.000Z",
"end_date": "2024-06-11T05:59:59.999Z"

目前聚焦於系統架構中的「規劃代理（planning agent）」，不需要添加太多工具，保持簡潔，唯一適合額外加入的工具是「檢索工具」。
檢索工具的功能是根據用戶查詢，檢索出相關的子任務（subtasks），接下來將針對檢索工具的設計與應用進行討論。

其他沒有在這個範例系統提示詞(System Prompt)中的還有：

Rag檢索增強生成與 Memory記憶

系統雖不必具備短期記憶，但可快取（cache）先前的子查詢結果，加速處理流程。當出現類似查詢時，直接從向量資料庫檢索過去結果，避免重新生成子查詢，降低延遲與API成本。
建立向量資料庫保存歷史子查詢與結果，並在新查詢時檢索相似內容重用。此屬於動態上下文工程，可讓應用更快、更省、更高效；同時可優化儲存與檢索策略，靈活將既有結果帶入新上下文，形成優勢。

狀態與歷史語境

系統在產出最終報告前，常需要多輪修正，因此必須回顧過往任務狀態，例如：子任務進度、修正版紀錄與各代理的輸出結果，才能在修正階段做出更佳判斷。

因此需建立狀態保存機制記錄歷史資料，並依優化目標動態傳遞必要的上下文，最後透過評估機制檢驗引入歷史資料是否確實提升結果品質。

進階語境工程

仍舊有許多關於語境工程的部份沒有在這篇文章中涵蓋，例如：語境壓縮、管理、語境安全與效能評估等技術，此外語境也可能因過時或雜訊而失效，需要專門評估流程。
語境工程是AI開發者的重要技能，除了手動的上下文工程之外，還有機會開發能自動化實施並優化上下文工程的技術方法。

References

Prompt Engineering Guide_Guides context-engineering-guide

Guides-Context Engineering(語境工程)

Guides-Context Engineering(語境工程)

本篇目標

什麼是 Context Engineering（語境工程）？

與 Prompt Engineering 的差異

核心任務與技巧

適用範圍

Context Engineering的核心目標

Context Engineering 實務應用

應用場景

實作工具

架構概要

系統提示

有效語境工程的核心概念（Context Engineering Essentials）

核心構面拆解（Core Components）

實作提醒

說明

使用者輸入

結構化的輸入與輸出

工具

Rag檢索增強生成 與 Memory記憶

狀態與歷史語境

進階語境工程

相關資源

References

Rag檢索增強生成與 Memory記憶