前面這篇介紹了，何謂 Context Engineering(上下文工程)

接下來要介紹其核心概念與如何應用，包括如何讓 AI 學會「記筆記」以維持專注，並介紹上下文管理的四大核心策略：撰寫、選擇、壓縮與隔離。

記筆記(代辦清單與規範)

讓 AI 學會記筆記是管理長上下文、確保 AI 在多步驟任務中不「失憶」或「跑題」的關鍵方法。

其原理是透過 Function Calling 或工具使用的能力，為 AI Agent 提供一個專門用於記錄、更新和讀取筆記的工具。

在執行一個複雜任務時，AI Agent 可以主動調用這個工具來記錄關鍵資訊。為了讓這個過程更可靠，我們通常會在系統提示詞（System Prompt）中明確地定義筆記的使用策略

• 任務分解：在行動前，先將複雜的總體目標分解成一系列具體、可執行的小步驟。
• 清單建立：將分解後的步驟寫入筆記，形成一個任務清單（To-Do List）。
• 循序執行：嚴格按照筆記中的任務清單來執行任務。
• 狀態更新：每完成一項任務，就調用工具更新筆記中該項目的狀態（例如，從 pending 改為 completed）。

運作流程解析：
當 AI 收到一個任務時，它會先進行「內部思考」或「頭腦風暴」，產出一個任務清單，然後調用筆記工具將其記錄下來。這份筆記接著會被 Agent 策略性地插入到每一次提交給 LLM 的上下文的開頭或結尾。

現代 LLM 主要基於 Transformer 架構，Transformer 架構的自注意力機制，對序列開頭和結尾的資訊具有較高的關注度，特別是在長序列時，邊緣位置的向量因位置編碼而有助於模型優先捕捉此類「任務重點」。即使中間的對話歷史和工具調用結果變得非常冗長，模型仍然能輕易地注意到位於開頭或結尾的核心任務清單，從而確保它始終記得最初的目標。

筆記的內容也不僅限於任務清單，還可以包含從外部工具（如網路搜尋）中獲取的關鍵事實、用戶的偏好設定、中間計算結果等，便於後續進行總結和決策。這項技術的本質，就是開發者透過提示詞工程，指導 AI 如何自我管理記憶，再透過將這份「記憶」放在上下文中最顯眼的位置，來間接引導 AI 的整個處理流程。

範例 1: VSCode 程式開發應用

在 VSCode 或任何整合了 AI 功能的 IDE 中，上下文工程的「靜態選擇」策略可以透過一個專案級的設定檔來實現。例如，開發者可以在專案根目錄下建立一個名為 Gemini.md 或類似的檔案。

這個檔案的功能是定義整個專案的「核心背景」，其內容可能包含：

• 編碼規範：例如「所有 Python 程式碼必須遵循 PEP 8 規範」、「JavaScript 變數命名使用駝峰式命名法」。
• 架構模式：例如「本專案採用微服務架構」、「後端使用 NestJS 框架」。
• 重要依賴庫：列出專案的核心函式庫和其版本。
• 檔案結構：簡述關鍵模組的目錄位置。

當 AI 需要執行如「新增功能」或「修復 Bug」等任務時，它會被指示總是先讀取這個檔案的內容，並將其作為最高優先級的上下文。這確保了 AI 生成的任何程式碼都能符合專案的既定規範，避免產生風格不一或違反架構的程式碼。

而使用Android也是同理。

上下文管理

上下文管理是指如何策略性地修改、篩選和組織提交給 LLM 的完整歷史記錄。一個優秀的管理策略是打造高效、穩定且符合成本效益的 AI 應用的基石。其主要可分為四大策略：

1. 撰寫 (Writing) / 保存 (Saving)

「撰寫」上下文可以理解為「保存 Context」，其核心是為本質上無記憶的 LLM 創建一個持久化的記憶層。這表示我們會將對話中的關鍵資訊進行篩選和總結，並將其儲存起來（例如，儲存在 session 記憶體、Redis 快取或資料庫中），在後續的對話中，再根據需要將這些記憶重新載入到上下文中。

一個典型的例子是 AI 助理的記憶功能。當用戶告知 AI 自己的姓名、偏好或特定專案的細節時，系統可以將這些資訊結構化地存儲起來。這個保存動作是 Context Engineering 的第一步，它解決了資訊持久化的問題，讓 AI 能夠提供更具個人化和連貫性的體驗。

2. 選擇 (Selection)

「選擇 Context」是從所有可用的資訊（包括對話歷史、文件、工具說明等）中，智慧地挑選出與當前任務最相關的內容放入上下文。一個好的選擇策略是整個系統高效運作的保障。

選擇策略主要分為兩類：

• 靜態選擇 (Static Selection)：將一些全域性、永遠重要的資訊（如系統角色、核心指令、專案規範）在每一次請求時都固定地放入上下文中。這就像是為 AI 植入了不可動搖的核心原則。
• 動態選擇 (Dynamic Selection)：根據用戶的當前問題，即時地從外部知識庫中檢索相關資訊並注入上下文。這不像靜態選擇那樣一成不變，而是像一個聰明的圖書館員，為你精準地找到當下最需要的那幾頁資料。目前最主流的動態選擇技術就是 RAG (Retrieval-Augmented Generation)，它透過向量搜尋從大量文件中找到與問題最相關的片段，然後將其提供給 LLM 作為回答的依據。

3. 壓縮 (Compression)

當對話持續進行，或 AI Agent 執行多步工具調用時，上下文會迅速膨脹，很快就會超出模型的 Token 限制，同時也帶來高昂的 API 成本。「壓縮 Context」就是為了解決這個問題。

常見的壓縮方法包括：

• 總結歷史訊息：定期將較早的對話記錄提取出來，讓另一個 LLM 呼叫（或使用更精簡的模型）將其總結成一段精簡的摘要，然後用這段摘要替換掉原來冗長的對話記錄。
• 滑動窗口 (Sliding Window)：只保留最近的 N 輪對話，直接捨棄更早的歷史記錄。這是一種簡單暴力但有效的方法，適用於對長期記憶要求不高的場景。
• 向量化儲存與查詢：對於非常長的外部文件（例如一篇上萬字的 PDF），Agent 不會將全文放入上下文，而是先將其處理後存入向量資料庫。當需要時，AI 只查詢與任務最相關的片段，並將這些片段放入上下文。這樣，一個巨大的文件就被壓縮成了幾個關鍵段落的資訊。
• 優化工具返回值：從源頭上減少注入上下文的資訊量。例如，當 AI 調用網頁瀏覽工具時，Agent 可以先去除網頁中所有不必要的 HTML 標籤、廣告和導航欄，只將最核心的正文內容返回給 LLM。

4. 隔離 (Isolation)

「隔離 Context」是指在複雜的系統（特別是 Multi-Agent 系統）中，為不同的任務或 Agent 維護獨立、互不干擾的上下文。這可以防止「上下文污染」，即一個子任務的資訊洩漏並干擾到另一個不相關的子任務。

例如，一個負責規劃行程的 AI 系統可能包含多個 Sub-agents：一個負責搜尋航班，一個負責預訂飯店，另一個負責查詢當地天氣。每個 Sub-agent 都有自己獨立的工具、運行歷史和記憶體系。航班 Agent 的上下文只包含與航班相關的資訊，而不會被飯店預訂的細節所干擾。主控的 Lead Agent 則負責在這些被隔離的 Sub-agents 之間傳遞必要的最終結果，並進行協調。

推薦資源:
https://ihower.tw/blog/12817-context-engineering
https://zhuanlan.zhihu.com/p/1938967453951571269