上下文工程（Context Engineering，又譯脈絡工程或情境工程）

是近年隨著 AI 代理（AI Agents）與複雜工作流程興起，超越傳統「提示工程（Prompt Engineering）」的下一代 AI 系統設計方法論
如果把 Prompt Engineering 比喻為「寫好一封信或下達精準指令」，那麼 Context Engineering 就是「建構整座郵遞系統與資訊供應鏈」

一、 為什麼需要 Context Engineering？（從提示工程的侷限談起）

在過去簡單的問答時代（早期直接與 ChatGPT 聊天），我們只要寫好一段固定的 Prompt，AI多半就能給出不錯的答案。但當 AI 應用進入多步驟、長流程、企業級自動化（AI 寫程式、自動客服、企業內部知識庫查詢）時，傳統提示工程開始暴露出明顯缺限：

• 資訊過載與「注意力盲區」：即使現在的 AI 視窗很大（如 200k+ tokens），研究顯示 AI 對長文本中段的資訊容易忽略（Lost in the Middle）
• 動態任務的落差：AI 代理在執行複雜任務時，狀態會一直改變，靜態的 Prompt 無法應付即時變化的環境
• 資訊碎片化：企業的資料散落在資料庫、API、歷史對話與外部文件中，如何即時且精準地把「對的資訊」在「對的時間」塞給模型，是個巨大的系統挑戰
  Context Engineering 的核心目的，就是透過系統化、動態化的方式管理與編排輸入到大模型上下文視窗（Context Window）的所有資訊

二、 Context Engineering 的核心組成架構

一個成熟的上下文工程系統，通常包含以下幾個關鍵維度：

• 上下文編排層（Context Orchestration）
  決定哪些資訊（系統指令、對話歷史、檢索結果）應該被放進視窗，並透過層級式結構（Hierarchical Context）排列，讓模型先看到最核心的任務與高權重資訊
• 動態檢索與 RAG（Retrieval-Augmented Generation）
  不再只是死板地丟整份文件，而是透過精準的向量檢索、重排序（Re-ranking）與分塊策略，只抓取當前步驟最需要的知識片段。
• 記憶系統（Memory Systems）
  建立類似人類的記憶機制，區分短期工作記憶（Working Memory）、長期知識庫（Semantic Memory）與事件記憶（Episodic Memory），讓 AI 在多輪對話或跨任務時不會「失憶」
• 工具與環境狀態（Tools & Environment）
  動態提供 AI 可以呼叫的 API Schema、工具描述以及當前程式或系統的即時狀態，讓 AI 知道「現在有哪些工具可以用、剛剛執行的結果是成功還是失敗」

三、 Prompt Engineering vs. Context Engineering 比較表

🏗️ Context Engineering 運作架構圖解

[ 1. 多源資料擷取層 (Data Sources & Ingestion) ]
  ├── 用戶即時輸入 (User Query)
  ├── 對話歷史與記憶 (Chat History & Episodic Memory)
  ├── 企業知識庫 / RAG (Vector DB / Documents)
  └── 即時外部環境與 API 狀態 (Live Data & Context)
           │
           ▼
[ 2. 上下文處理與優化層 (Context Processing & Optimization Engine) ]
  ├── 檢索與重排 (Retrieval & Re-ranking) ── 挑選最相關片段
  ├── 資訊壓縮與摘要 (Token Compression) ── 移除雜訊、長文濃縮
  ├── 動態組合與過濾 (Dynamic Injection & Pruning) ── 依 Token 視窗裁剪
  └── 隱私與安全清洗 (Sanitization & PII Masking) ── 過濾敏感個資
           │
           ▼
[ 3. 結構化組裝層 (Context Assembly) ]
  ├── 系統指令與角色 (System Instructions)
  ├── 長期與短期記憶區 (Memory Slots)
  └── 當前任務與知識上下文 (Active Context Window)
           │
           ▼
[ 4. 模型推理與執行層 (LLM Inference Layer) ]
           │
           ▼
[ 5. 狀態更新與回饋循環 (State Update & Loop) ]
  ├── 將新對話與狀態寫回記憶庫 (Memory Persistence)
  └── 依據輸出品質動態調整上下文策略 (Adaptive Tuning)

🧩 核心組件與運作階段解析

1. 多源資料擷取層 (Ingestion)

上下文工程的核心在於「在對的時間提供對的資訊」。資料來源包含：

• Episodic Memory（情境記憶）：使用者過去的偏好、先前的對話紀錄

• Semantic Memory（語意/知識庫）：透過 RAG（檢索增強生成）從向量資料庫（Vector DB）中抓取的企業文件

• Dynamic State（動態狀態）：智能體在執行任務時產生的中間結果、API 回傳的即時數據

2. 上下文處理與優化層 (Processing Engine)

這是上下文工程最核心的「大腦」，專門解決 Token 限制與資訊過載（Lost in the Middle）的問題：

• Re-ranking（重排機制）：透過交叉編碼器（Cross-Encoder）將最核心、高相關的資料排在最前面與最後面

• Token Compression（壓縮與摘要）：對冗長的歷史對話進行自動摘要，或者使用KV Cache優化，避免超過模型的上下文視窗（Context Window）

• Sanitization（安全與隱敏）：在送入模型前，自動遮蔽敏感個資（密碼、信用卡號）

3. 結構化組裝層 (Assembly)

將處理好的碎片化資訊，按照模型最容易理解的結構（例如:XML 標籤、階層式 Markdown）進行排列，確保模型能清晰分辨「指令」、「背景知識」與「用戶需求」

4. 狀態更新與閉環迴圈 (State Update Loop)

隨著互動進行，系統會即時更新狀態：

將本次對話的重要資訊萃取後存入長期記憶

刪除過期或無效的暫存上下文，保持系統輕量與高效

四、 總結

如果說 Prompt Engineering 讓學會了如何和 AI 愉快對話，Context Engineering 則是將 AI 應用推向企業級生產力的關鍵基石。它讓開發者從「寫好一句話」的思維，提升到「打造一個能隨時供應正確脈絡給 AI 的智慧生態系統」