Context Engineering 上下文工程指南：RAG、記憶系統與企業知識庫

一、從 Prompt Engineering 到 Context Engineering：典範轉移

過去三年，Prompt Engineering（提示工程）是企業與大型語言模型（LLM）互動的核心技能。透過精心設計的提示語，開發者可以在不修改模型權重的前提下，顯著提升輸出品質。然而，隨著 AI 應用從簡單的問答機器人進化為複雜的多步驟工作流程與自主代理（autonomous agents），一個根本性的問題浮現了：僅靠「寫好提示」遠遠不夠。

Context Engineering（上下文工程）正是為了回應這一挑戰而誕生的系統性方法論。它關注的不只是提示語本身，而是在 LLM 推論的那一刻，如何確保模型擁有完成任務所需的全部上下文——包括正確的知識、相關的歷史、適當的工具描述、以及結構化的指令。如果 Prompt Engineering 是「寫好一封信」，那麼 Context Engineering 就是「建構整個郵遞系統」。

Gao 等人在 2024 年的 RAG 綜述研究^[2]中指出，現代 LLM 應用中超過 70% 的錯誤並非源自模型能力不足，而是源自上下文不完整、不相關或結構不良。這一數據揭示了一個反直覺的事實：在模型能力已足夠強大的 2026 年，決定 AI 應用成敗的關鍵瓶頸，已從「模型側」轉移到「上下文側」。

1.1 Context Engineering 的核心組成

一個完整的 Context Engineering 系統包含四大支柱：

• 知識檢索層（Knowledge Retrieval）：透過 RAG、GraphRAG 等技術從外部知識庫即時檢索相關資訊
• 記憶管理層（Memory Management）：管理對話歷史、使用者偏好與跨會話的長期記憶
• 上下文編排層（Context Orchestration）：決定哪些資訊以何種順序、何種格式注入 context window
• 工具與環境層（Tools & Environment）：為 LLM 提供可呼叫的工具描述、API schema 與環境狀態

1.2 Prompt Engineering vs. Context Engineering

二、RAG 架構深度解析：從基礎到進階

檢索增強生成（Retrieval-Augmented Generation, RAG）是 Context Engineering 最核心的技術元件。自 Lewis 等人於 2020 年提出 RAG 概念以來^[1]，這項技術已從學術論文中的原型，發展為企業 AI 應用的標準架構。然而，真正理解 RAG 的全貌——從 Naive RAG 到 Advanced RAG 再到 Agentic RAG——對於建構企業級系統至關重要。

2.1 RAG 的三代演進

第一代：Naive RAG（2020-2023）。最基礎的 RAG 實作遵循「索引-檢索-生成」的線性管線。文件被切割為固定長度的 chunks，透過 embedding 模型轉換為向量並儲存於向量資料庫^[10]。查詢時，系統以語義相似度檢索 top-k chunks，直接拼接為 LLM 的上下文。這種方式簡單直覺，但面臨三個核心問題：分塊語義斷裂、檢索精準度不足、以及缺乏對檢索結果品質的驗證。

第二代：Advanced RAG（2023-2025）。為解決 Naive RAG 的問題，社群發展出一系列強化技術：query rewriting（查詢改寫）、hybrid search（混合語義+關鍵字搜尋）、re-ranking（重排序）、parent-child chunking（父子分塊）、以及 self-query（讓 LLM 自行決定檢索策略）。LlamaIndex^[6] 與 LangChain^[5] 等框架將這些技術封裝為可組合的模組，大幅降低了企業導入門檻。

第三代：Agentic RAG（2025-現在）。Agentic RAG 是一次本質性的躍遷——它將 RAG 從被動的「檢索管線」升級為主動的「智慧代理」。RAG 代理能夠：自主判斷是否需要檢索、動態選擇檢索來源（向量庫、知識圖譜、Web 搜尋、API）、評估檢索結果的品質並決定是否需要二次檢索、在生成後自我驗證答案的正確性。這種架構借鑒了 Shinn 等人提出的 Reflexion 框架^[8]中的自我反思機制，使 RAG 系統具備了自我修正的能力。

2.2 三代 RAG 架構比較

2.3 Agentic RAG 架構模式

Agentic RAG 的核心在於以 LLM 作為「推理引擎」驅動整個檢索-生成流程。以下是一個典型的 Agentic RAG 決策流程：

Agentic RAG 決策流程:

使用者查詢 → LLM 路由判斷
  │
  ├─ 判斷 1: 是否需要外部知識？
  │   ├─ 否 → 直接以模型內建知識回答
  │   └─ 是 → 進入檢索階段
  │
  ├─ 判斷 2: 選擇檢索來源
  │   ├─ 事實查詢 → 向量資料庫 (Pinecone/Weaviate)
  │   ├─ 關係推理 → 知識圖譜 (Neo4j GraphRAG)
  │   ├─ 即時資訊 → Web Search API
  │   └─ 結構化數據 → SQL / API 查詢
  │
  ├─ 判斷 3: 檢索結果是否充分？
  │   ├─ 否 → 查詢改寫 / 擴展 → 二次檢索
  │   └─ 是 → 進入生成階段
  │
  └─ 判斷 4: 生成後自我驗證
      ├─ 答案與來源一致 → 回傳使用者
      └─ 發現矛盾 → 觸發 Reflexion → 重新檢索

三、Context Window 管理：200K+ Token 時代的策略

2025-2026 年間，主流 LLM 的 context window 經歷了爆發性增長：Claude 支援 200K tokens^[3]、Gemini 3 Pro 達到 200 萬 tokens^[4]、GPT-4.5 提供 256K tokens。這種超長上下文能力看似消除了 RAG 的必要性——為何不直接把所有文件塞進 context window？然而，實務經驗告訴我們，超長 context 帶來的不只是機會，更是全新的工程挑戰。

3.1 「Lost in the Middle」問題

研究表明，LLM 在處理超長上下文時存在明顯的注意力分布不均——模型對文本開頭與結尾的關注度顯著高於中段。Anthropic 在其長上下文使用指南中^[3]明確建議，應將最關鍵的資訊放置於上下文的開頭或結尾，避免重要內容被「埋沒」在中段。這一現象意味著，即使 context window 足夠大，資訊的排列順序仍然至關重要。

3.2 Context Window 最佳化策略

有效的 context window 管理需要在「資訊完整性」與「注意力分配」之間取得平衡。以下是經過實務驗證的四大策略：

策略一：層級式上下文結構（Hierarchical Context）。不要將所有內容以扁平列表的方式注入 context。取而代之，建構一個層級結構：頂層放置 system prompt 與任務定義；第二層放置最直接相關的檢索結果（經過重排序）；第三層放置補充性的背景知識；最底層放置工具描述與格式指令。這種結構讓模型能「先看到最重要的資訊」。

策略二：動態上下文壓縮（Dynamic Context Compression）。在資訊量超過 context window 限制時，使用 LLM 或專門的壓縮模型對低優先級的上下文進行摘要。例如，對話歷史中較早的訊息可以被壓縮為摘要；檢索到的長文件可以被提取為關鍵段落。這種做法保留了資訊的語義，同時節省了寶貴的 token 空間。

策略三：選擇性注入（Selective Injection）。並非所有上下文都需要同時存在於 context window 中。透過 LLM 驅動的路由邏輯，系統可以根據當前查詢的性質，動態決定注入哪些知識片段。例如，當使用者詢問財務問題時，系統注入財務相關文件與對話歷史；當話題轉向技術問題時，動態替換為技術文件。

策略四：結構化標記（Structured Tagging）。在注入的上下文中使用明確的 XML 或 Markdown 標記來區分不同來源與類型的資訊。例如：

<context>
  <system_instructions>
    你是一位金融法規顧問...
  </system_instructions>

  <retrieved_knowledge source="法規資料庫" relevance="0.94">
    金管會 2025 年第 42 號公告：關於虛擬資產...
  </retrieved_knowledge>

  <conversation_history compressed="true">
    [摘要] 使用者先前詢問了加密貨幣監管的基本框架...
  </conversation_history>

  <tool_definitions>
    search_regulations: 搜尋金融法規資料庫...
    calculate_penalty: 計算違規罰款金額...
  </tool_definitions>
</context>

3.3 Long Context vs. RAG：何時用哪個？

超長 context window 與 RAG 並非互斥的技術選擇，而是互補的策略。以下是我們在實務中歸納的決策框架：

• 文件總量 < 50 頁且更新頻率低：直接放入 long context，無需 RAG 架構的額外複雜度
• 文件總量 50-500 頁：使用 RAG 檢索 + long context 的組合——先透過 RAG 篩選出最相關的段落，再利用 long context 能力同時處理多個段落
• 文件總量 > 500 頁或持續增長：必須使用 RAG（搭配向量資料庫或 GraphRAG），long context 僅用於承載單次查詢的檢索結果
• 需要精確引用來源：RAG 優於 long context——RAG 架構天然支援來源追蹤，而 long context 中的資訊來源較難追溯

四、記憶系統設計：讓 AI 擁有真正的「記憶」

人類的認知能力很大程度上仰賴記憶系統——我們能回想昨天的對話、運用多年累積的專業知識、並在工作中維持對當前任務的短期記憶。然而，標準的 LLM 是「無狀態」的：每次推論都從零開始，沒有任何對先前互動的記憶。Context Engineering 的記憶管理層正是為了填補這一根本性的缺口。

4.1 三層記憶架構

Park 等人在 2023 年發表的 Generative Agents 研究^[9]中，為 AI 代理設計了受認知科學啟發的記憶架構。我們在此基礎上，提出適用於企業 AI 系統的三層記憶模型：

Working Memory（工作記憶）。工作記憶對應當前對話的上下文。它包含當前對話輪次中的所有訊息、檢索到的知識片段、以及工具呼叫的結果。工作記憶受限於 context window 的大小，是「最昂貴」但也「最精確」的記憶形式。管理工作記憶的核心挑戰是：在有限的 token 預算中，決定保留哪些資訊、壓縮哪些資訊、丟棄哪些資訊。

Episodic Memory（情節記憶）。情節記憶儲存的是過去互動的「經歷」——之前對話的摘要、使用者曾提出的問題、系統曾犯過的錯誤與修正。這類記憶儲存在外部資料庫中，並在需要時透過檢索注入工作記憶。情節記憶讓 AI 助理能夠「記住」使用者的偏好（如報告格式、語言風格）以及先前建立的決策上下文，實現跨對話的連續性。

Semantic Memory（語義記憶）。語義記憶對應系統的「知識庫」——企業文件、領域知識、政策規範等結構化與非結構化知識。這是 RAG 系統所管理的核心層。語義記憶是最穩定、更新頻率最低的記憶形式，但其品質直接決定了 AI 系統的專業能力上限。

4.2 記憶系統的工程實踐

在工程層面，每一層記憶都需要對應的儲存與檢索機制：

記憶系統架構:

Working Memory（工作記憶）
├─ 儲存: LLM context window（in-memory）
├─ 容量: 200K - 2M tokens（依模型而定）
├─ 策略: 對話歷史壓縮、滑動視窗、重要性加權保留
└─ 延遲: 0ms（已在 context 中）

Episodic Memory（情節記憶）
├─ 儲存: 向量資料庫 + 結構化資料庫
├─ 容量: 無上限
├─ 策略: 對話結束時自動摘要存檔、按相關性檢索注入
└─ 延遲: 50-200ms（檢索延遲）

Semantic Memory（語義記憶）
├─ 儲存: 向量資料庫 + 知識圖譜 + 文件系統
├─ 容量: 無上限
├─ 策略: RAG 管線（分塊 → 嵌入 → 索引 → 檢索 → 重排序）
└─ 延遲: 100-500ms（檢索 + 重排序延遲）

4.3 Reflexion：讓記憶驅動自我改進

Shinn 等人提出的 Reflexion 框架^[8]展示了記憶系統最令人興奮的應用之一：讓 AI 代理從自身的失敗中學習。在 Reflexion 架構中，代理在完成任務後會自我評估結果的品質；若發現錯誤，代理會生成一段「反思」文本——分析失敗的原因與改進策略——並將這段反思存入情節記憶。在下一次面對類似任務時，系統會檢索相關的反思記錄，避免重蹈覆轍。

這種機制在企業場景中極具價值。例如，一個處理客戶投訴的 AI 助理在錯誤分類了一筆投訴後，系統自動記錄：「將退貨要求錯誤分類為產品諮詢——原因：客戶使用了間接表述，未明確提及退貨。改進策略：當客戶提及不滿意、不符合預期等詞彙時，優先考慮退貨/退款意圖。」這段記憶在後續類似場景中被自動檢索，使系統的分類準確率持續提升。

五、Multi-Agent 系統中的 Context 管理

隨著 AI 應用從單一代理進化為多代理協作系統（Multi-Agent System），Context Engineering 面臨全新的挑戰：如何讓多個代理在共享資訊的同時保持各自的專注度？如何避免上下文污染？如何設計高效的代理間通訊協議？

5.1 Multi-Agent Context 架構模式

在多代理系統中，每個代理都有自己的 context window，但它們需要協作完成共同的任務。我們觀察到三種主流的 context 共享模式：

模式一：共享黑板（Shared Blackboard）。所有代理共用一個中央「黑板」（通常是一個結構化的文件或資料庫），每個代理將自己的中間結果寫入黑板，並從黑板讀取其他代理的輸出。這種模式的優點是簡單透明，缺點是容易造成上下文膨脹——每個代理都看到所有資訊，包括與自身任務無關的內容。

模式二：訊息傳遞（Message Passing）。代理之間透過精簡的訊息進行通訊，每條訊息只包含接收代理所需的最少量資訊。這種模式有效控制了上下文膨脹，但需要精心設計訊息格式與路由邏輯。LangChain 的 LangGraph 框架^[5]正是採用這種模式。

模式三：層級式委派（Hierarchical Delegation）。一個「主管代理」（Supervisor Agent）負責接收任務、拆解子任務、並分配給專門的「工作代理」。主管代理維護全局上下文，而工作代理只接收與其子任務相關的局部上下文。任務完成後，工作代理將結果回報給主管代理，由主管代理整合並產出最終回應。這是目前企業 Multi-Agent 系統中最成熟的模式。

5.2 Agent Context 的隔離與共享

在設計 Multi-Agent 的上下文架構時，關鍵的設計決策是：哪些資訊應該共享，哪些應該隔離。我們建議以下原則：

• 共享：任務目標、全局約束條件、最終輸出格式要求、共用的知識庫存取權限
• 隔離：各代理的專屬 system prompt（定義角色與行為）、工具呼叫的中間結果（除非其他代理明確需要）、各代理的推理過程（避免推理干擾）
• 選擇性共享：經壓縮的中間結果摘要（而非原始推理過程）、錯誤報告與修正記錄、代理間的協調狀態

Multi-Agent Context 架構範例:

Supervisor Agent [context: 全局任務 + 子任務狀態]
  │
  ├─ Research Agent [context: 研究指令 + 知識庫存取]
  │   ├─ 語義記憶: 企業文件向量庫
  │   └─ 輸出: 結構化研究報告摘要 → Supervisor
  │
  ├─ Analysis Agent [context: 分析指令 + Research 結果]
  │   ├─ 工具: 數據分析 API、圖表生成
  │   └─ 輸出: 分析結論 + 數據視覺化 → Supervisor
  │
  └─ Writing Agent [context: 寫作指令 + 分析結論]
      ├─ 情節記憶: 使用者風格偏好
      └─ 輸出: 最終報告 → 使用者

六、企業知識庫建構與 Context 最佳化實務

將上述的理論架構落地為企業可用的系統，需要一套系統化的工程方法論。這一節從向量資料庫選型、embedding 策略、分塊最佳化、到端到端的品質監控，提供一份完整的企業知識庫建構指南。

6.1 向量資料庫選型

向量資料庫是 Context Engineering 的基礎設施。Pinecone 在其企業 RAG 最佳實踐報告^[10]中指出，選擇向量資料庫時需考量五大面向：查詢延遲、可擴展性、過濾能力、營運成本、以及與現有技術棧的整合度。以下是主流方案的比較：

• Pinecone：全託管服務，零運維負擔，適合快速啟動的中小型專案。支援 metadata filtering 與 hybrid search，但定價隨規模增長較快。
• Weaviate：開源 + 雲端雙模式，內建 BM25 + 向量混合搜尋，支援 GraphQL 查詢介面。適合需要自訂部署的企業。
• Milvus / Zilliz：高效能開源向量資料庫，專為十億級向量規模設計。適合資料量大、對效能要求極高的場景。
• Qdrant：Rust 語言實作，極低延遲，支援豐富的過濾條件。適合需要在邊緣裝置部署的場景。
• pgvector（PostgreSQL 擴充）：直接在現有 PostgreSQL 中啟用向量搜尋，無需額外基礎設施。適合已使用 PostgreSQL 且資料量中等的團隊。

6.2 Embedding 策略

Embedding 模型的選擇直接影響檢索品質。目前業界的最佳實踐是：

選擇專為檢索最佳化的模型。通用語言模型（如 GPT-4）的 embedding 並非最佳檢索選項。專為語義搜尋設計的模型——如 OpenAI text-embedding-3-large、Cohere embed-v4、BGE-M3——在檢索任務上的表現通常優於通用模型 15-25%。

考慮多語言需求。對台灣企業而言，知識庫通常包含繁體中文、英文、甚至簡體中文的混合文件。選擇支援多語言的 embedding 模型（如 BGE-M3 或 Cohere embed-v4）至關重要，否則跨語言的語義匹配將嚴重失準。

維度 vs. 品質的取捨。更高維度的 embedding（如 3072 維）通常具有更豐富的語義表示能力，但也帶來更高的儲存成本與查詢延遲。對多數企業場景，1024 維的 embedding 已能提供足夠的檢索品質，是成本效益的甜蜜點。

6.3 智慧分塊策略

文件分塊（chunking）是 RAG 品質的最大決定因素之一，卻常被低估。以下是經實務驗證的分塊原則：

• 語義邊界優先：以段落、章節、條款為分割點，而非固定 token 數。使用 NLP 工具偵測語義邊界。
• 上下文保留：每個 chunk 應包含足夠的上下文資訊（如章節標題、文件名稱），使其在脫離原始文件時仍然可理解。
• 重疊策略：相鄰 chunks 保持 10-15% 的重疊，防止語義斷裂。
• 父子分塊（Parent-Child Chunking）：將大段落作為「父 chunk」、其子段落作為「子 chunk」。檢索時搜尋子 chunk（精準度高），但回傳父 chunk（上下文完整性高）。LlamaIndex^[6] 原生支援這一模式。
• 多粒度索引：對同一文件建構多個粒度的索引——句子級、段落級、文件級——在查詢時根據問題的性質選擇適當粒度的檢索。

6.4 端到端品質監控

企業級 Context Engineering 系統必須具備持續的品質監控能力。我們建議追蹤以下五項核心指標：

• Retrieval Precision@k：在 top-k 檢索結果中，有多少是真正相關的？目標：> 85%。
• Answer Faithfulness：生成的答案有多少內容可以在檢索到的來源中找到依據？目標：> 90%。
• Context Utilization：注入 context 的資訊中，有多少被模型實際用於生成？低利用率意味著上下文中存在大量噪音。
• Latency P95：從使用者提問到系統回應的端到端延遲（第 95 百分位）。目標：< 3 秒。
• Hallucination Rate：生成的回答中包含無法在任何來源中驗證的資訊的比例。目標：< 5%。

七、Context Engineering 的前沿趨勢

Context Engineering 是一個快速演進的領域。以下三個趨勢將在未來 12-18 個月內重塑企業 AI 的知識架構。

7.1 自適應 Context 編排

下一代 Context Engineering 系統將不再依賴預定義的規則來決定上下文組成，而是使用 LLM 自身作為「context 控制器」——根據每個查詢的特性，動態決定需要檢索哪些知識、注入多少對話歷史、啟用哪些工具。這種 meta-cognitive（後設認知）能力讓系統能夠「思考自己需要什麼資訊」，而非被動地執行固定的檢索管線。

7.2 多模態 Context

隨著 Gemini 3^[4] 等多模態模型的成熟，Context Engineering 正從純文本擴展至圖像、影片、音訊與結構化數據的融合。企業知識庫不再僅包含文件，還包括工程圖紙、產品照片、會議錄音與儀表板數據。如何為這些多模態資訊建構統一的索引與檢索機制，是下一個重大技術挑戰。

7.3 個人化記憶網絡

未來的 AI 助理將為每位使用者維護一個專屬的「記憶網絡」——不僅記住使用者說過什麼，更能推斷使用者的工作模式、決策偏好與知識盲區。這種個人化記憶將使 AI 從「通用工具」進化為「個人化智慧夥伴」。Park 等人的 Generative Agents 研究^[9]已經展示了這一方向的初步可行性。

八、結語：上下文決定智慧的上限

在 LLM 能力已足夠強大的 2026 年，一個令人深思的事實是：模型的「聰明程度」越來越少受限於模型本身，而越來越多取決於我們為它提供的上下文品質。這正是 Context Engineering 作為一門獨立工程學科興起的根本原因。

一個精心設計的 Context Engineering 系統——結合 Agentic RAG 的智慧檢索、三層記憶架構的知識累積、Multi-Agent 的協作能力、以及嚴謹的品質監控——能夠將同一個基礎模型的表現從「勉強可用」提升至「企業級可靠」。這不是漸進式的改善，而是質變。

對台灣企業而言，Context Engineering 的建構能力將成為 AI 競爭力的核心護城河。模型可以透過 API 購買，但知識架構、記憶系統與上下文管線必須根據企業的獨特知識資產量身打造。率先完成這一建構的企業，將在 AI 賦能的效率與決策品質上，拉開與競爭者的顯著差距。