Prompt Engineering 轉變成 Context Engineering ，重點不在於 Context Windows 大小，而在於 Context 品質，尤其當LLM Agent 從之前的被動回應轉向成主動執行複雜任務後更被體現出來，從傳統 RAG 的內容檢索向關係建模演進，所以一個好的 Context Management （上下文管理），就顯得很重要。
Context Windows 是什麼?
Context Windows （上下文窗口）不是越大越好嗎?
確實更長的上下文，可以提供更長的文件與更多回合的對話（對話記憶）等，但別忘了 LLM 是基於 Transformer 架構，其中最重要的 Attention 機制會讓 LLM 在長序列中，更偏好處理最近的 token，導致較遠的資訊權重被稀釋也就是所謂注意力衰減 (Attention Decay)，當然現在也有一些新的架構如（Longformer, FlashAttention, Mamba）。
計算成本
那直接加大 Context 大小不就好了嗎?
計算成本大幅增加，別忘了 Transformer 的 self-attention 計算量是 O(n²)，所以當 Context 長度翻倍時計算量幾乎翻四倍，最直觀的感受是現在的 LLM API 收費大部分是按 Token 計價的，所以當你的 Context 越多（Token 也越多）那費用也會越高，更何況更長的上下文 LLM 也不一定能很好的完全使用，只會有更多的干擾資訊導致汙染（Context Pollution）與延遲增加。
所以除了改進現有架構之外，實務上也會將記憶的需求外包（在 Context Windows 以外的地方存放，有需要時再取回來），像是使用 RAG 技術或是開發 Agent 時會設計的長短期（Long / Short-term）記憶，可以理解成當我們的 Prompt 放不下了就需要將一些沒那麼重要或是冗長的訊息移除，但挑選的依據又是什麼?
- 改進架構：長注意力機制 (Longformer, FlashAttention, Mamba)。
- 外部記憶：RAG、Vector db（向量資料庫）、Agent 記憶模組（Long-term memory 等）。
Reasoning Model 與 MCP Tool
現在越來越多模型都開始會推理（Reasoning Model <- 這部分之後可以找機會聊聊），以及越來越多 MCP Tool 加入，這些都很容易讓 Context Windows 爆炸，下圖是 Claude 官方文件的說明，要如何管理與放置這些資訊就是所謂的 Context Management。
Context Window with extended thinking and tool use
LLM Agent and Context
LLM 的 Context Window 是 Agent 設計中的一個挑戰，可以理解成如果你一次只能處理有限的資訊與記憶（工作記憶 Working memory），無法無限容納所有歷史資訊、對話記錄與工具回饋，無限制的累積只會導致上面提到的問題。
Memory Bank
在最基本的層面上，LLM Agent 的記憶體可被分為兩種主要類型
- 短期記憶（Short-Term Memory）： 負責處理單次 LLM 調用中的上下文資訊。屬於短暫且有限的，如前幾篇提到的（in-context learning），像是將近期對話歷史直接放入 Prompt 中。但此方法受限於上下文視窗的固定大小，無法處理冗長的歷史記錄。
- 長期記憶（Long-Term Memory）： 用於儲存 Agent 需要長期保留和重新取用資訊，這段記憶的生命週期超過單次對話或任務。可以透過外部儲存機制，如前面提到的向量資料庫或知識圖譜，透過檢索來提供相關資訊 ，如筆者的 MemTask MCP 專案。
當然如果仔細往下深挖還有情節記憶（Episodic memory）、用戶專屬記憶（User-specific memory）或是將長短期記憶結合的混合記憶（Hybrid Memory）等等，現在先回到此篇討論的重點：上下文管理（Context Management）
傳統 RAG 問題
說到 Context 就不得不提 RAG（檢索增強生成），RAG 是一種允許 LLM 取用外部知識庫的框架，一開始出現的原因是為了在不重新訓練模型的前提下，提供 LLM 最新或特定領域知識從而有效減少 LLM 幻覺。
但傳統的 RAG 機制有一個明顯的缺陷，基於餘弦相似性（cosine similarity）進行向量檢索最相關的資料並生成回應，這種方法本質上是基於「相關性」，但缺乏對資訊間「關係」的理解。因此很容易將語義上相似但實際無關的資訊注入上下文，這樣會導致上述提到的「上下文污染」，尤其難以處理需要多步推理、跨越多個文件才能回答的複雜問題，這從根本上限制了 Agent 的複雜推理能力。
隨著需求後來也發展出了基於知識圖譜的（Graph-Based Memory - GraphRAG），以及分層記憶體（Hierarchical Memory - G-Memory）概念，未來有機會再針對這部分細說，而 G-Memory 與 GraphRAG 的出現，使得上下文管理從單純的內容檢索向關係建模的轉變，Agent的推理能力不僅取決於它看到什麼資訊，更取決於它對這些資訊之間「關聯」的理解。
從 ReAct 到 Reflexion
ReAct
之前文章有介紹過 ReAct（Reasoning + Acting）是一種常見的通用 Agent 架構，透過「思考」（Thought）、 「行動」（Action）和「觀察」（Observation）循環，讓 Agent 能夠解決複雜任務。在 ReAct 中記憶體在循環中起著關鍵作用，用於保留過去步驟的資訊，以便 Agent 在下一步決策時能夠回溯軌跡。
ReAct（Reasoning + Acting）
Reflexion
ReAct 在本質上是一種單步決策的框架。為了賦予 Agent 更強的學習與自我修正能力，發展出了 Reflexion 框架，加入了「自我反思」（Self-Reflection）機制，將Agent的記憶從被動的「儲存」轉化為主動的「學習」工具。
- Actor： 根據環境觀察與歷史記憶生成行動 。
- Evaluator： 評估 Actor 的行動軌跡，提供獎勵分數或簡單的「正確/錯誤」判斷 。
- Self-Reflector： 一個專門的LLM，根據 Evaluator 的獎勵信號與當前軌跡，產生「語言式反饋」（linguistic feedback），並將其儲存在長期記憶中。
Reflexion 概念
實際情境
透過類似迭代學習的機制，可以使 Agent 能夠從過去的錯誤中學習，並將其轉化為可供未來決策參考的知識。Reflexion 將 Agent 從單純的狀態管理（ReAct）演進到一個具備自我修正與迭代學習能力的認知架構。
Context Management 應具備的關鍵功能
在前面的介紹可以看出，不管對於哪一種類型的 Agent 架構，Memory 都是最關鍵的部分，可以說如果沒有辦法提供好/正確的記憶給 LLM，他將無法給予理想的回應，下面列出幾個主要的功能分類。
短期記憶 (Short-term Memory)
能夠自動管理 LLM 的上下文窗口
- 動態裁剪 (Dynamic Truncation): 根據重要性（如時間、關鍵詞、對當前任務的相關性）來裁剪或總結舊的對話歷史。
- 避免在窗口中迷失： 採用專門策略（如將重要資訊放在開頭或結尾）來減輕此問題。
- 上下文窗口預測與優化： 估計剩餘窗口大小，並提前進行總結或壓縮。
長期記憶 (Long-term Memory)
- Episodic Memory：存儲過去的特定事件、對話，以便 Agent 能夠「記住」過去的具體經歷。
- Semantic Memory：存儲關於世界、領域的通用知識（類似於 RAG 的檢索知識庫，但更結構化）。
- Procedural Memory：存儲 Agent 如何完成特定任務的步驟或策略，類似於技能和習慣。
工作記憶 (Working Memory)
臨時存儲 Agent 在思考、規劃和執行任務過程中需要頻繁訪問的資訊。
檢索與路由 (Retrieval & Routing)
- 情境感知檢索 (Context-Aware Retrieval)：根據當前 Agent 的狀態、意圖和任務，從不同層次的記憶中檢索最相關的資訊。
- 混合檢索策略 (Hybrid Retrieval Strategies)：結合關鍵詞匹配、向量相似度搜索（如使用嵌入式向量庫）以及圖搜索（如 GraphRAG）。
上下文壓縮與總結 (Context Compression & Summarization)
- 動態總結 (Dynamic Summarization)：對過去的對話、文件或觀察到的資訊進行分層、總結，以節省上下文空間。
- 重點提取 (Key Information Extraction)：自動識別並提取對 Agent 的決策至關重要的資訊片段。
所以說建構一個好的 Context Management 在當前 LLM Agent 的發展階段是一個必要的趨勢的，能夠解決現有 Agent 系統面臨的核心挑戰，為開發更強大、更智能的 Agent 提供關鍵的支持。
